nova volume-attach <vmid> <volumeid> auto returns always /dev/sdb on Hyper-V

[Alessandro Pilotti]

To reproduce the issue it's enough to attach two volumes to a VM without providing an explicit mount point.

cinder create 1
cinder create 1

nova boot ... vm1

nova volume-attach vmid <volumeid1> auto
nova volume-attach vmid <volumeid2> auto

As a result:

1) When the machine is deleted only one of the volumes becomes available again on Cinder, the second one figures as still attached.
2) Live migration fails as only one volume is reported in the "block_device_info" dict.

More inconsistent behaviours can happen, for example during cold migration / resize.

Workaround:

Always provide a mount point e.g.:

nova volume-attach vmid <volumeid1> /dev/sdb
nova volume-attach vmid <volumeid2> /dev/sdc

[David Medberry (med)]

Seems like the possibility of data loss would make this higher than medium. No idea if it is still true with Nova/Hyper-V today. Maybe Alessandro could comment on the possibility of this still happening.

[David Medberry (med)]

Does this happen in Azure with multiple attachments? Or is Azure properly attaching vols?

[Alessandro Pilotti (alexpilotti)]

Volumes are always attached in order on Hyper-V on an a SCSI controller.
A direct Linux device naming "/dev/sdb" mapping doesn't apply. There are no data loss scenarios, unless you rely on the naming instead of the order.

We could translate them to SCSI Id numbering if it makes sense, e.g. sga = 1, sgb = 2, etc

[Alessandro Pilotti (alexpilotti)]

By digging further into this issue, we found out that there's a bug in Hyper-V related to the way the SCSI volumes are queried. If LUN0 is not queried (attached in the case of Nova), other volumes are not properly becoming available in the guest.

In practice, you cannot attach a volume to /dev/sdc if a volume hasn't been attached to /dev/sdb before (/dev/sda is the root volume / local disk connected to the IDE channel).

Here's a Linux Kernel patch that works around this issue, although it didn't merge yet:
http://www.spinics.net/lists/linux-scsi/msg65056.html

[Anseela M M (anseela-m00)]

Hi
Currently I am working on this bug. I have some queries regarding the same.
1) which version of openstack are you using?
2) I have tried the first scenario. the steps I executed are.

 a) Created two volume volume1 and volume2
 b) booted the new instance VM1
 c) attached the two volumes to the instance VM1'
 d) checked the cinder status. Both are in use state.
 e) deleted the instance VM1
 f) Checked the cinder status. Both the volumes are in available state.

Please let me know whether I missed any steps.

[Augustina Ragwitz (auggy)]

Hi Anseela, are you still working on this bug? If so please include the "Closes-Bug: #1153842" in your commit message. If you still need your questions answered, please reach out in IRC (#openstack-nova) or send email to the openstack-dev mailing list.

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY