Open Stack

On Fri, Jul 17, 2015 at 08:12:18AM +0300, Feodor Tersin wrote:
> The third reason is that at least xen supports them.I know that vdr
> becomes /dev/xvdr, but:1) I believe the main aim of specifying device
> name is to easy distinguish among devices. A last char is enough for
> that. And xen supports that.2) Xen users may use this now.3) We don't
> know about device name support in VMWare and other hypervisors.4) AWS
> in its turn also does not warrant that selected name will be the same
> as requested one [3]
> So i think Nova could look at a specified device name as at a hint.
> If a used hypervisor can follow it even partially, Nova honours it.
> In particular libvirt could sort devices by device name.

If the libvirt XML contains device names, then in fact the *only*
thing that libvirt uses those names for is to represent the relative
sort ordering of the disk devices attached to the same bus.

So if you have two virtio-blk devices with names /dev/vda and
/dev/vdb, libvirt will maintain that relative ordering, in so
much that the /dev/vda will get a PCI device address that is
numerically lower than the PCI device address of the device
with /dev/vdb. Now by convention Linux currently enumerates
block devices in PCI address order, so by luck they will
*probably* end up being named /dev/vda and /dev/vdb in the
guest, but the virtio protocol makes no guarantees about this.

Things get more complicated though when you have a mixture of
block device buses eg virtio-blk and virtio-scsi, or plain
scsi, or IDE, etc. As there's no gaurantee about which bus
type will get enumerated first - in fact its entirely possible
to be enumerated in parallel. Throw in hotplug & unplug and
the mess becomes even worse, eg start with 3 disk vda, vdb
and vdc, now unplug vdb and reboot the guest OS. What used
to be vdc will now appear as vdb in the guest.

NB, none of this is a limitation imposed by libvirt - it is
all just an artifact of the hypervisor virtual hardware model.
Xen paravirt disk is the only case I know of where it is
possible to have the guest OS honour requested device name,
but even that's not guaranteed to be honoured by the guest.

> And obviously i agree with the aim of your patch which persists a
> true device name. I believe an operator must see true names to
> have an easy way to associate devices visible from inside guest
> OS with Cinder volumes and their attributes (like volume type,
> multiattach ability and so on).

There is really no such thing as "true device names". What Nikola's
patch persists is just the libvirt auto-assigned names - the only
thing these tell you is the relative ordering of the devices within
a specific bus. The guest OS is no more likely to honour the libvirt
assigned names, than the user assigned names.

So if you are trying to identify what the guest OS sees as devices
names, you are out of luck in every way.

If users want a reliable way to identify devices, there are really
only two options that work in general

 - Disk serial "numbers" (they're not actually numbers, they are
   arbitrary 32 byte strings). Nova auto-assigns these for cinder
   volumes but its kind of dumb as the values nova assigns are
   unique but longer than 32 bytes, so they get truncated to a
   value which is possibly no longer unique !

   We also don't set the serial for non-cinder volumes. We should
   probably define some sensible generic naming scheme we can use
   for recording serial numbers for all types of disk and apply
   that across all hypervisor drivers in Nova

 - Device address information. eg what PCI device the disk is
   associated with. The users don't get to choose the PCI device
   address though, so its not immediately useful. I have a blueprint
   proposed to make this useful though, by allowing an arbitrary
   string "tag" to be associated with any type of guest device
   (eg NICs as well as disk), and then expose metadata to the guest
   OS associating the tags with the device address info. This will
   let admins reliably associated devices with specific roles

    https://review.openstack.org/#/c/195662/


All this is to say, I think Nikola's proposed patch is fine. The intended
use case for supplying device names is already broken in all cases, with
possible exception of Xen if using Xen paravirt disks and Linux guests.
There are faaar better ways to allow users to identify disks which we
should prioritize.

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