Open Stack

Thanks Daniel, Tim and Matt. Good food for thought here.

The most important thing I have learned from this discussion is that even
though libvirt generated names are generally correct, there is no guarantee
that the guest OS has assigned these names to the devices.

I had a play with an instance and tried to attach / detach a bunch of
volumes to it. In this experiment the device names displayed by OpenStack
were correct all the time. That said, a friend of mine recently resized an
instance with multiple volumes attached (that he was mounting by device
name) and the order of the devices changed and the mount points got messed
up. Actually it was this incident that triggered my original question to
the mailing list.

My take away is: when using KVM set 'can_set_mount_point' to False in
Horizon, document users should not pass a device name to API calls (it will
be ignored) and recommend users to mount devices by UUID or file system
label.

Cheers,
Bruno

Catalyst Cloud
http://www.catalyst.net.nz/catalyst-cloud


On Thu, Feb 18, 2016 at 10:03 PM, Daniel P. Berrange <berrange at redhat.com>
wrote:

> On Wed, Feb 17, 2016 at 08:11:11PM -0600, Matt Riedemann wrote:
> >
> >
> > On 2/17/2016 6:49 PM, Bruno L wrote:
> > >Hi everyone,
> > >
> > >Could not figure this one out based on docs, wiki, or previous posts on
> > >the mailing list.
> > >
> > >We use KVM as our hypervisor on the Catalyst Cloud in New Zealand.
> > >Unlike Xen, KVM does not support setting the device name (eg: /dev/vdc)
> > >of a cinder volume within the guest. If a user specifies the device name
> > >it is ignored and cinder will display the device name that has been
> > >assigned.
> > >
> > >To what extent is the device name (mountpoint) displayed by Cinder /
> > >Nova reliable? Is Cinder just naming attachments in alphabetical order
> > >hoping that it is correct, or actually obtaining the device name from
> > >the hypervisor?
> > >
> > >If a user attaches 2 volumes with the same size to a compute instance
> > >(eg: one for a database and one for media assets), how can he or she
> > >identify which one is what? From what I can see on our compute
> > >instances, the device ID or UUID does not match the volume name or UUID
> > >displayed by OpenStack. What is the best way to ensure you are dealing
> > >with the correct device?
> > >
> > >Do you know if there is work going on in KVM to allow a device name to
> > >be specified like in Xen?
> > >
> > >Cheers,
> > >Bruno
> >
> > It's not actually cinder that's picking the device name (mountpoint),
> it's
> > the libvirt driver (more specifically, the nova.virt.libvirt.blockinfo
> > code).
> >
> > The change to ignore the user-supplied device name for the libvirt driver
> > went into liberty [1]. I don't know all of the details behind it, but my
> > understanding was requesting a specific device was not reliable with
> > libvirt, so it's best to let libvirt pick the mountpoint for you.
> ndipanov
> > and/or danpb in the #openstack-nova freenode channel would be able to
> give
> > more information.
>
> User specified device names are a broken concept with the exception of Xen
> paravirt disks, because the device names are never exposed to the guest
> operating system. The guest merely sees a PCI device or a SCSI device,
> with some PCI/SCSI address. There is no mechanism for exposing a desired
> device name. The guest will assign device names itself basd on the order
> in which it probes the devices.
>
> Now libvirt still accepts device names, but since there's no wa to expose
> them to the guest, the device names are not used for anything other than
> to imply a relative ordering of disks to be attached. For this reason
> Nova wil ignore user specified device names and generate device names
> which correspond to the ordering of devices in the block device mapping.
> Even the libvirt generated names are *not* guaranteed to match the names
> thed guest OS will assign, it is purely showing ordering of devices.
>
> > As for figuring out which mountpoint the attachments are on, you have to
> > wait for the volume status to go to 'in-use' and then from the volume GET
> > you can get the attachment information (there should be a list of dicts
> in
> > the response that have the attachment IDs and mountpoints in them). I
> > believe since we don't support multiattach for volumes yet in nova, there
> > would only be one attachment in the list.
> >
> > As for figuring out what's what, if you are naming the volumes that
> you're
> > attaching to something like 'db' and 'media', then you should know which
> is
> > which, right? Then just get the mountpoint from the volume attachment
> meta
> > that's available via the Cinder REST API.
>
> If the volume has a filesystem in it, then the best thing todo is to just
> mount-by-uuid, since that's totally independant of the device name.
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org              -o-             http://virt-manager.org
> :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc
> :|
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160219/471fcb26/attachment.html>