Bug 833152 - per-machine-type CPU models for safe migration
per-machine-type CPU models for safe migration
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.4
All Linux
high Severity high
: rc
: ---
Assigned To: Eduardo Habkost
Virtualization Bugs
:
Depends On:
Blocks: 832177 837920 689665 804161 804749 814426 832964 833129 837884 840699 841379 853134 1004299
  Show dependency treegraph
 
Reported: 2012-06-18 13:41 EDT by Eduardo Habkost
Modified: 2014-06-18 08:23 EDT (History)
17 users (show)

See Also:
Fixed In Version: qemu-kvm-0.12.1.2-2.320.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 824991
: 837884 (view as bug list)
Environment:
Last Closed: 2013-02-21 02:37:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eduardo Habkost 2012-06-18 13:41:13 EDT
We need to implement this on 6.4, too.

+++ This bug was initially created as a clone of Bug #824991 +++

Sometimes we want to update an existing QEMU CPU model, because of a new feature, or because a bug needs to be fixed. But existing virtual machines using the CPU model can't change under the guest's feet when live-migrated. To make this work, we need to implement:

- Versioned CPU models, so new CPU models can get the fixes or new features while the existing CPU models keep the same.
- Per-machine-type CPU model aliases, so users can get the latest version of a CPU model automatically, but keep the same CPU when live-migrating to a newer QEMU version.
Comment 6 Eduardo Habkost 2012-07-20 09:47:21 EDT
So, the current plan is:

- Make per-machine-type CPU model changes, but only essential and minimal ones, not visible to libvirt (such as the bugs caused by wrong "level" field)
- The only exception for the "minimal and not visible to libvirt" rule will be TSC-deadline. libvirt will require TSC-deadline support on the host even for "-M rhel6.3.0 -cpu SandyBridge"
- The QEMU<=>libvirt API for CPU model and feature probing won't be implemented in 6.4.
Comment 8 Itamar Heim 2012-07-23 09:20:53 EDT
just to make sure i understand correctly:
On a 6.3 host
-cpu SandyBridge with -M rhel6.3.0 does not have TSC

on a 6.4 host
-cpu SandyBrdige with -M rhel6.3.0 does not have TSC[1]
-cpu SandyBridge with -M rhel6.4.0 does have TSC


[1] libvirt will require the host to have it, but it will not be exposed to the guest, so live migration to a rhel 6.3 host will work.
Comment 9 Eduardo Habkost 2012-07-24 13:30:14 EDT
(In reply to comment #8)
> just to make sure i understand correctly:
> On a 6.3 host
> -cpu SandyBridge with -M rhel6.3.0 does not have TSC
> 
> on a 6.4 host
> -cpu SandyBrdige with -M rhel6.3.0 does not have TSC[1]
> -cpu SandyBridge with -M rhel6.4.0 does have TSC
> 
> 
> [1] libvirt will require the host to have it, but it will not be exposed to
> the guest, so live migration to a rhel 6.3 host will work.

That's correct.

(But, please, don't call the feature just "TSC", it's called "TSC deadline", or "TSC deadline timer")
Comment 15 Qunfang Zhang 2012-10-11 04:37:43 EDT
Reproduction on qemu-kvm-0.12.1.2-2.316.el6:

1. Boot a guest with "-M rhel6.4.0 -cpu SandyBridge" on a SandyBridge host.
2. Check cpuinfo after guest boot up.

Result: There's no "tsc_deadline_timer" flag inside guest. 

========================
Verification on qemu-kvm-0.12.1.2-2.320.el6:

1. Boot a guest with "-M rhel6.4.0 -cpu SandyBridge" on a SandyBridge host and check cpuinfo after guest boot up.
==> There's "tsc_deadline_timer" flag inside guest. 

2. Boot a guest with "-M rhel6.3.0 -cpu SandyBridge" on a SandyBridge RHEL6.4 host and check cpuinfo after guest boot up.
==> There's no "tsc_deadline_timer" flag inside guest. 

3. Ping-pong migration beween two RHEL6.4 host with "-M rhel6.4.0 -cpu SandyBridge".
==> Migration finished successfully. Guest cpu flag keeps the same before and after migration (have "tsc_deadline_timer" flag). No time drift inside guest after migration.

4. Ping-pong migration between RHEL6.3 and RHEL6.4 host with "-M rhel6.3.0 -cpu SandyBridge". (Both hosts are SandyBridge)
==> Migration finished successfully. Guest cpu flag keeps the same before and after migration (have NO "tsc_deadline_timer" flag). No time drift inside guest after migration.

So, this bug is verified pass.
Comment 17 errata-xmlrpc 2013-02-21 02:37:25 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0527.html

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