Bug 1517781 - Nova live migration fail for different CPU Model
Summary: Nova live migration fail for different CPU Model
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Eoghan Glynn
QA Contact: Joe H. Rahme
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-27 13:03 UTC by Md Nadeem
Modified: 2023-09-07 19:02 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-14 16:11:13 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-28176 0 None None None 2023-09-07 19:02:10 UTC

Description Md Nadeem 2017-11-27 13:03:34 UTC
Description of problem:
Nova live migration fail for different CPU Model, however the cold migration gets completed successful. So from user point of view if instance cold migrated
successfully and running as expected on a compute node having higher model of the same CPU vendor, then live migration should also not blocked it.

[heat-admin@ ~]$ openstack server migrate --live hostname uuid
Unacceptable CPU info: CPU doesn't have compatibility.

Configuration Details:

/etc/nova/nova.conf:53: cpu_mode=host-model

CPU Details:

model name      : Intel(R) Xeon(R) CPU E5-2698 v4 @ 2.20GHz
model name      : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:


The SOS report is  there with the attached case.

Comment 1 Sahid Ferdjaoui 2017-11-28 13:19:00 UTC
Can you confirm the version used for libivrt and QEMU? When using cpu mode host-model some issues have been noticed for libvirt/QEMU during migration and so prior to libvirt 3.2.0 and QEMU 2.9.0 detection of the host CPU model via QEMU seems to be not supported.

  https://libvirt.org/formatdomain.html#elementsCPU

Comment 2 Md Nadeem 2017-11-30 08:31:59 UTC
>> libvirt-2.0.0-10.el7_3.9.x86_64

>> cat installed-rpms | grep -i qemu
ipxe-roms-qemu-20160127-5.git6366fa7a.el7.noarch            Thu Jun 15 20:40:54 2017
libvirt-daemon-driver-qemu-2.0.0-10.el7_3.9.x86_64          Thu Jun 15 20:46:50 2017
qemu-img-rhev-2.6.0-28.el7_3.9.x86_64                       Thu Jun 15 20:44:32 2017
qemu-kvm-common-rhev-2.6.0-28.el7_3.9.x86_64                Thu Jun 15 20:46:22 2017
qemu-kvm-rhev-2.6.0-28.el7_3.9.x86_64                       Thu Jun 15 20:52:25 2017

Note: Cu has confirmed that after making these changes in nova.conf, the Issue is fixed.

cpu_mode=custom
cpu_model=IvyBridge

After restarting the instances so they take the new flags into account, they can now be migrated between computes with different CPUs.

Comment 3 Sahid Ferdjaoui 2017-11-30 08:38:14 UTC
(In reply to Md Nadeem from comment #2)
> >> libvirt-2.0.0-10.el7_3.9.x86_64
> 
> >> cat installed-rpms | grep -i qemu
> ipxe-roms-qemu-20160127-5.git6366fa7a.el7.noarch            Thu Jun 15
> 20:40:54 2017
> libvirt-daemon-driver-qemu-2.0.0-10.el7_3.9.x86_64          Thu Jun 15
> 20:46:50 2017
> qemu-img-rhev-2.6.0-28.el7_3.9.x86_64                       Thu Jun 15
> 20:44:32 2017
> qemu-kvm-common-rhev-2.6.0-28.el7_3.9.x86_64                Thu Jun 15
> 20:46:22 2017
> qemu-kvm-rhev-2.6.0-28.el7_3.9.x86_64                       Thu Jun 15
> 20:52:25 2017
> 
> Note: Cu has confirmed that after making these changes in nova.conf, the
> Issue is fixed.
> 
> cpu_mode=custom
> cpu_model=IvyBridge
> 
> After restarting the instances so they take the new flags into account, they
> can now be migrated between computes with different CPUs.

I don't see any action in Nova side and the issue seems to be fixed with libvirtd 3.2.0 and QEMU 2.9.0. Cu found workaround by configuring the exact cpu model. I guess we can just close the bug or do you have other request?

Comment 4 Matthew Booth 2017-12-14 16:11:13 UTC
I have closed this bug as it has been waiting for more info for at least 2 weeks. We only do this to ensure that we don't accumulate stale bugs which can't be addressed. If you are able to provide the requested information, please feel free to re-open this bug.


Note You need to log in before you can comment on or make changes to this bug.