"nova volume-attach" is giving wrong device ID

[Techpatron]

Sometimes while attaching volume to the instance using "nova volume-attach" it is giving wrong device ID (mountpoint : /dev/vdb).

root@techpatron:~# nova volume-attach VM1 201b2fe8-7f77-446d-a6e4-5d077914329c
+----------+--------------------------------------+
| Property | Value |
+----------+--------------------------------------+
| device | /dev/vdd |
| id | 201b2fe8-7f77-446d-a6e4-5d077914329c |
| serverId | 2f319155-06d2-4aca-9f0f-49b415112568 |
| volumeId | 201b2fe8-7f77-446d-a6e4-5d077914329c |
+----------+--------------------------------------+

Here it is showing "/dev/vdd", but volume actually attached as "/dev/vdc" to the instance "VM1".

Because of this when I am running some automation scripts (which will perform operations on the attached device with in the instance) facing problem. From the output that script taking the device id as "/dev/vdd" but device is attached to some other mount point.

[John Griffith (john-griffith)]

This is a VERY old and long running issue with how things work on the Nova side of the house. The volumes are going to get attached to the next available drive mapping (vdb, vdc, vdd) based on the Block Device Mapping table in Nova. The specification you provide to attach-volume is really more of a hint than anything else.

Anyway, over the past the answer has been "just use 'auto'" and save yourself the false sense of control here. Not acceptable for some, regardless this is a Nova operation and Cinder actually has no control or input here.

Marking invalid for Cinder and adding Nova.

[Eli Qiao (taget-9)]

i'd like to mark this as invalid in nova.

if you specify an device name, libvirt will use it as just a hint
nova pass this device to libvirt, and libvirt treat is as just a hint. cause it can not know how guest kernel treat it.

2014-11-03 15:10:17.982 DEBUG nova.virt.libvirt.config [req-71da8b06-befb-40e0-8cb3-7553f62eceef admin admin] Generated XML ('<disk type="block" device="disk">\n <driver name="qemu" type="raw" cache="none"/>\n <source dev="/dev/disk/by-path/ip-cloudcontroller:3260-iscsi-iqn.2010-10.org.openstack:volume-3f629777-ccf5-43fa-92e8-da6bd9d8d282-lun-1"/>\n <target bus="virtio" dev="vdd"/>\n <serial>3f629777-ccf5-43fa-92e8-da6bd9d8d282</serial>\n</disk>\n',) from (pid=2970) to_xml /opt/stack/nova/nova/virt/libvirt/config.py:81

see :http://libvirt.org/formatdomain.html#elementsDisks

target
The target element controls the bus / device under which the disk is exposed to the guest OS. The dev attribute indicates the "logical" device name. The actual device name specified is not guaranteed to map to the device name in the guest OS. Treat it as a device ordering hint. The optional bus attribute specifies the type of disk device to emulate; possible values are driver specific, with typical values being "ide", "scsi", "virtio", "xen", "usb", "sata", or "sd" "sd" since 1.1.2. If omitted, the bus type is inferred from the style of the device name (e.g. a device named 'sda' will typically be exported using a SCSI bus). The optional attribute tray indicates the tray status of the removable disks (i.e. CDROM or Floppy disk), the value can be either "open" or "closed", defaults to "closed". NB, the value of tray could be updated while the domain is running. The optional attribute removable sets the removable flag for USB disks, and its value can be either "on" or "off", defaulting to "off". Since 0.0.3; bus attribute since 0.4.3; tray attribute since 0.9.11; "usb" attribute value since after 0.4.4; "sata" attribute value since 0.9.7; "removable" attribute value since 1.1.3