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 :| __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev