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
