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

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.

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

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

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

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.

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.

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