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

Bug #1153842 reported by Alessandro Pilotti on 2013-03-11
22
This bug affects 5 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Undecided
Unassigned
compute-hyperv
Undecided
Unassigned

Bug Description

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

description: updated
Changed in nova:
assignee: nobody → Alessandro Pilotti (alexpilotti)
tags: added: hyper-v
Changed in nova:
status: New → Confirmed
importance: Undecided → Medium
David Medberry (med) wrote :

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) wrote :

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

Changed in nova:
assignee: Alessandro Pilotti (alexpilotti) → nobody
Changed in nova:
assignee: nobody → Anseela M M (anseela-m00)
Anseela M M (anseela-m00) wrote :

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) wrote :

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

Changed in nova:
assignee: Anseela M M (anseela-m00) → nobody
importance: Medium → Undecided
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers