[Openstack] [Nova] [Cinder] Block device name / ordering

Daniel P. Berrange berrange at redhat.com
Thu Feb 18 09:03:40 UTC 2016


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 :|




More information about the Openstack mailing list