BUG : when live-migration failed, lun-id couldn't be rollback
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Confirmed
|
Low
|
Unassigned |
Bug Description
Hi, guys
I'm testing live-migration with openstack Juno.
when live-migrate failed with error, lun-id of connection_info in bdm table couldn't be rollback
my test version is following :
Openstack Version : Juno ( 2014.2.1)
Compute Node OS : 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2
backend storage : EMC VNX 5400
test step is :
1) create 2 Compute node (host#1 and host#2)
2) create 1 VM on host#1 (vm01)
3) create 2 cinder volumes (vol01, vol02)
4) attach 2 volumes to vm01 (vdb, vdc)
5) host#2's iscsi interface down
- this situation can be occurred frequently in production
6) live-migrate vm01 from host#1 to host#2
7) live-migrate fails
- please check connection_
- please check lun's storage_group by using unisphere then you can find lun has two storage groups.
This Bug is very critical because the VM can have different lun mappings when this case is occurred, so that filesystem of volume can be break.
Actually this case was occurred and my vm's filesystem was broken.
and I think every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process.
please fix this bug ASAP.
Thank you.
tags: | added: vnx |
Changed in cinder: | |
assignee: | nobody → Hahyun (hfamily15) |
assignee: | Hahyun (hfamily15) → nobody |
Changed in cinder: | |
assignee: | nobody → Hahyun (hfamily15) |
status: | New → In Progress |
Changed in cinder: | |
assignee: | Hahyun (hfamily15) → Robert Esker (esker) |
assignee: | Robert Esker (esker) → NetApp (netapp) |
tags: | added: security |
Changed in nova: | |
status: | In Progress → Confirmed |
importance: | Undecided → Low |
tags: | added: libvirt live-migration |
tags: | added: volum |
tags: |
added: volumes removed: volum |
Rob,
This was assigned to NetApp. Is anyone from NetApp looking into this? Thanks.