During post_live_migration the nova libvirt driver assumes that the destination connection info is the same as the source, which is not always true
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Undecided
|
Anthony Lee | ||
Juno |
Fix Released
|
Undecided
|
Unassigned | ||
Kilo |
Fix Released
|
Undecided
|
Unassigned | ||
nova (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Trusty |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
The post_live_migration step for Nova libvirt driver is currently making a bad assumption about the source and destination connector information. The destination connection info may be different from the source which ends up causing LUNs to be left dangling on the source as the BDM has overridden the connection info with that of the destination.
Code section where this problem is occuring:
https:/
At line 6038 the potentially wrong connection info will be passed to _disconnect_volume which then ends up not finding the proper LUNs to remove (and potentially removes the LUNs for a different volume instead).
By adding debug logging after line 6036 and then comparing that to the connection info of the source host (by making a call to Cinder's initialize_
http://
Version of nova being used:
commit 35375133398d862
Merge: 83623dd b2c5542
Author: Jenkins <email address hidden>
Date: Thu Jul 16 02:01:05 2015 +0000
Merge "Port crypto to Python 3"
[Test Case]
Live migrate an instance which is connected to a volume through multi-path in which the source and target connection information is not the same. Verify that the correct device/LUN is removed (instead of wrong one).
[Regression Potential]
The regression potential is small as it has run in newer versions of nova for awhile now (since Juno, the release immediately following Icehouse). If a regression were to occur it would likely prevent a live migration from completing (failing in the post processing), leaving the instance in an error state. However, it should be migrated to the target hypervisor with access to the LUN so it would require manual cleanup of the lun at the source hypervisor and a reset of the instance state to active.
Related branches
Changed in nova: | |
assignee: | nobody → Anthony Lee (anthony-mic-lee) |
description: | updated |
tags: |
added: live-migrate removed: live-migration |
tags: | added: kilo-backport-potential |
Changed in nova: | |
milestone: | none → liberty-3 |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | liberty-3 → 12.0.0 |
description: | updated |
tags: |
added: verification-done removed: verification-needed |
Fix proposed to branch: master /review. openstack. org/202770
Review: https:/