attach volume action does not honor the specified mountpoint

[Patrick Crews]

The attach_volume action does not honor the user-specified mountpoint and instead mounts the volume to the next available (example: mounting to /dev/vdb if only /dev/vda exists)

In the attached example, we have a test server with no volumes mounted (only /dev/vda exists) and a test volume.
We attach the volume to the instance and specify /dev/vdc as the mountpoint.
The system says /dev/vdc is the mountpoint on the return data and in the database.
The volume is actually mounted on /dev/vdb.

[Patrick Crews (patrick-crews)]

# Listing our test servers
 nova --os-auth-url=http://192.168.0.5:5000/v2.0 list
+--------------------------------------+--------------+--------+------------+-------------+------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+--------------+--------+------------+-------------+------------------+
| 9991ead8-8a88-45c3-83d0-a2ac5e7fb232 | test_server1 | ACTIVE | - | Running | private=10.0.0.2 |
| 44d13e4b-a218-46b8-a714-c96e9cff2066 | test_server2 | ACTIVE | - | Running | private=10.0.0.3 |
+--------------------------------------+--------------+--------+------------+-------------+------------------+

# Listing our test volume
pcrews@erlking-dev:~/git/rannsaka$ cinder list
+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+
| ID | Status | Display Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+
| 41dcbd0b-ac6b-477e-84f9-bbe62da29a6a | available | test_volume1 | 1 | lvmdriver-1 | false | |
+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+

# Listing what exists on test_server1
pcrews@erlking-dev:~/git/rannsaka$ ssh cirros@10.0.0.2
The authenticity of host '10.0.0.2 (10.0.0.2)' can't be established.
RSA key fingerprint is 05:ca:d6:08:fc:78:a2:c7:a7:d5:d1:46:db:ca:90:61.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.2' (RSA) to the list of known hosts.
cirros@10.0.0.2's password:
$ ls /dev
bsg loop5 ram1 root tty18 tty33 tty49 tty7 ttyS21 ttyS9
bus loop6 ram10 rtc0 tty19 tty34 tty5 tty8 ttyS22 ttyprintk
console loop7 ram11 sg0 tty2 tty35 tty50 tty9 ttyS23 uinput
cpu_dma_latency mapper ram12 shm tty20 tty36 tty51 ttyS0 ttyS24 urandom
ecryptfs mcelog ram13 snapshot tty21 tty37 tty52 ttyS1 ttyS25 usbmon0
full mem ram14 sr0 tty22 tty38 tty53 ttyS10 ttyS26 usbmon1
fuse net ram15 tty tty23 tty39 tty54 ttyS11 ttyS27 vcs
hpet network_latency ram2 tty0 tty24 ...

[Duncan Thomas (duncan-thomas)]

Please don't set your own bug to confirmed, that is for independent confirmation of the bug.

I'm assuming you're using KVM as your hypervisor. If so, this is a known issue, there is no way to tell kvm to use a specific device. The device serial number inside the guest will be a truncated version of the cinder volume id, which can be used to uniquely identify a specific volume.

[John Griffith (john-griffith)]

yep, it doesn't work that way unfortunately. You get what's next in the BDM table from Nova. This is documented and comes up again and again.

I know it's a lame answer, but that's how it works.