Bug 833152

Summary:	per-machine-type CPU models for safe migration
Product:	Red Hat Enterprise Linux 6	Reporter:	Eduardo Habkost <ehabkost>
Component:	qemu-kvm	Assignee:	Eduardo Habkost <ehabkost>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.4	CC:	acathrow, areis, bsarathy, dyasny, hui.xiao, iheim, jamorgan, jane.lv, juzhang, jvillalo, jwilleford, mkenneth, qzhang, ruwang, virt-maint, xfu, xiaolong.wang
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	qemu-kvm-0.12.1.2-2.320.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	824991
Clones:	837884 (view as bug list)		Environment:
Last Closed:	2013-02-21 07:37:25 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:
Bug Depends On:
Bug Blocks:	689665, 804161, 804749, 814426, 832177, 832964, 833129, 837884, 837920, 840699, 841379, 853134, 1004299

Description Eduardo Habkost 2012-06-18 17:41:13 UTC

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 13:47:21 UTC

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 13:20:53 UTC

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 17:30:14 UTC

(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 08:37:43 UTC

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 07:37:25 UTC

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