| 2016-10-20 01:35:15 |
Bin Zhou |
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. |
I encountered this bug in my daily test. I found in live migration process 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. |
|
