Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1850846

Summary: VM on wrong hypervisor after migration
Product: Red Hat OpenStack Reporter: Brendan Shephard <bshephar>
Component: openstack-novaAssignee: Lee Yarwood <lyarwood>
Status: CLOSED DUPLICATE QA Contact: OSP DFG:Compute <osp-dfg-compute>
Severity: high Docs Contact:
Priority: high    
Version: 13.0 (Queens)CC: dasmith, eglynn, jhakimra, kchamart, lyarwood, nalmond, sbauza, sgordon, vromanso
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-16 12:26:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Brendan Shephard 2020-06-25 03:35:00 UTC 
Description of problem:
After migrating a VM, nova reports that the VM is still on the original hypervisor, rather than the new one where it is actually located. As such, we can't perform any operations on the VM using the openstack / nova CLI

Version-Release number of selected component (if applicable):
RHOSP13

puppet-nova-12.4.0-10.el7ost.noarch                         Wed Nov  7 13:07:51 2018
python2-novaclient-10.1.0-1.el7ost.noarch                   Wed Nov  7 13:03:24 2018
python-nova-17.0.7-2.el7ost.noarch                          Wed Nov  7 13:04:03 2018



How reproducible:
Difficult

Steps to Reproduce:
1. Migrate VM and it doesn't work the first time for various reasons
2. Try migration again, it reports an error but the VM is actually moved
3. Verify VM is actually on new hypervisor using virsh, but nova still reports it on the original

Actual results:
Nova DB is not updated to reflect the new hypervisor location, which subsequently breaks any openstack or nova cli operations against that instance.

Expected results:
Nova DB reflect the location of the VM after a migration

Additional info:
We have a solution article about this:
https://access.redhat.com/solutions/2070503

Since it recommends making a DB update, and this VM does indeed have two Volumes attached to it. We would like engineering to review the situation and provide guidance and recommendations on whether the DB update is the best way to proceed, or should we try to resolve this issue using the placement API?

sosreports will be provided along with Nova database dumps
Comment 6 Lee Yarwood 2020-07-16 12:26:14 UTC 
Closing this out as a duplicate of 1767928.

*** This bug has been marked as a duplicate of bug 1767928 ***