> From: Daniel P. Berrange [mailto:[email protected]]
> 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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
