Open Stack

Based on my investigation, I did not find any issue on cinder side. In a situation of failed migration, the volume is properly unmapped from the host and the terminate_connection has been called as expected.
I rebooted the vm after failed migration to make sure LUNs are properly mapped to the host. I didn't see any discrepancy there too.  

However, I did see an issue with the BDM table in Nova where "controller-info" column does not rollback the information about "target-id" properly.
Therefore, I am moving this bug to Nova.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1416314

Title:
  BUG :  when live-migration failed, lun-id couldn't be rollback

Status in OpenStack Compute (Nova):
  In Progress

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_info(lun-id) of bdm at this time then you can find the lun-id of cinder-volume is not be rollback
       - 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1416314/+subscriptions