Open Stack

> From: Daniel P. Berrange [mailto:berrange at redhat.com]
> On Wed, Aug 15, 2012 at 03:49:45PM +0100, John Garbutt wrote:
> > You can see what XenAPI exposes here:
> >  http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/api/?c=VBD
> >
> > I think the only thing you can influence when plugging in the disk is the
> “userdevice”
> > which is the disk position: 0,1,2…  When you have attached the disk
> > you can find out the “device” name, such as /dev/xvda
> >
> > I don't know about Xen with libvirt. But from the previous discussion
> > it seems using the disk position would also work with KVM?
> 
> No, this doesn't really work in general. Virtio disks get assigned SCSI device
> numbers on a first-come first served basis. In the configuration you only have
> control over the PCI device slot/function. You might assume that your disks are
> probed in PCI device order, and thus get SCSI device numbers in that same order.
> This is not really safe though. Further more if the guest has any other kinds of
> devices, eg perhaps they logged into an iSCSI target, then all bets are off for
> what SCSI device you get assigned.
>
> All the host can safely say is
> 
>   - Virtio-blk disks get PCI address domain:bus:slot:function
>   - Virtio-SCSI disks get SCSI address A.B.C.D
>   - Disks have an unique serial string ZZZZZZZZZZZ
> 
> As a guest OS admin you can use this info get reliable disk names in
> /dev/disk/by-{path,id}.
Doh, I guess my plan doesn't work then. After checking, apparently the same problem is also present with how Xen deals with exposing the "position" to the guest VM.

> Relying on /dev/sdXXX is doomed to failure in the long term, even on bare
> metal, and should be avoided wherever possible.
I agree, long term, this is not the way forward. I was just thinking in terms of backwards compatibility.

> If your disk has a filesystem on it, you can also get a unique UUID and /or
> filesystem label, which means you can refer to the device from /dev/disk/by-
> {uuid,label} too.
That sounds the interesting for those attaching volumes that have a file system on it. Would it be reasonable to make this the best practice way for users to discover where the volume has been attached?

Maybe we should simply leave nova to report where the disk has been attached? XenAPI driver can simply attach in the next available slot, and report back what it can about the device location. Sounds like the libvirt driver could do the same?

We could document the current device (or whatever we call it) as a driver specific "hint". Although this doesn't seem very satisfying.

Cheers,
John