Public bug reported: I encountered this bug in my daily test. I found when volume initialize connection failed at dest host, the rollback process will misdisconnect other's volume on dest host. my test step is as follows:
1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 with volume vol01(vm01) 3) live-migrate vm01 from host#1 to host#2 4) vol01 initialize connection failed on host#2 5) live-migrate rollback and disconnect volume on host#2 6) some volume on host#2 was disconnected by mistake The issue is that in rollback process, nova disconnect volume from the block_device_mapping table, which was supposed to be update on dest host host#2 when volume initialize connection succeed. In this bug, the volume initialize connection failed at dest host host#2, and the record in block_device_mapping table was not updated, remaining the origin one which created on source host host#1, the difference between records of dest and source host may be the lun-id mapped on host, that's the point why other volume was disconnected by mistake on host#2. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1633955 Title: live migrate rollback disconnect other's volume Status in OpenStack Compute (nova): New Bug description: I encountered this bug in my daily test. I found when volume initialize connection failed at dest host, the rollback process will misdisconnect other's volume on dest host. my test step is as follows: 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 with volume vol01(vm01) 3) live-migrate vm01 from host#1 to host#2 4) vol01 initialize connection failed on host#2 5) live-migrate rollback and disconnect volume on host#2 6) some volume on host#2 was disconnected by mistake The issue is that in rollback process, nova disconnect volume from the block_device_mapping table, which was supposed to be update on dest host host#2 when volume initialize connection succeed. In this bug, the volume initialize connection failed at dest host host#2, and the record in block_device_mapping table was not updated, remaining the origin one which created on source host host#1, the difference between records of dest and source host may be the lun-id mapped on host, that's the point why other volume was disconnected by mistake on host#2. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1633955/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp