Bug 824991 - per-machine-type CPU models for safe migration
per-machine-type CPU models for safe migration
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.1
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Eduardo Habkost
Virtualization Bugs
:
Depends On:
Blocks: 728045 824987
  Show dependency treegraph
 
Reported: 2012-05-24 14:36 EDT by Eduardo Habkost
Modified: 2014-06-17 23:16 EDT (History)
11 users (show)

See Also:
Fixed In Version: upstream qemu-1.4.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 833152 (view as bug list)
Environment:
Last Closed: 2014-06-13 08:22:54 EDT
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-05-24 14:36:44 EDT
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 1 Eduardo Habkost 2013-02-28 10:55:55 EST
An ad-hoc solution is already available upstream, based on using different machine-type init functions that will set different defaults on different machine-types. The alias system won't be implemented.

A better solution based on global properties should be implemented soon, but the basic functionality of "per-machine-type CPU model definitions" already exists.

To test this bug, just check if the kvm_pv_eoi feature is enabled by default only on pc-1.3 and newer.
Comment 3 Qunfang Zhang 2014-01-16 03:55:53 EST
Verified this bug with kernel-3.10.0-72.el7.x86_64 and qemu-kvm-1.5.3-37.el7.x86_64 packages on host. 

Boot up guest and do migration on SandyBridge host. 

(1) Boot up guest with "-M pc". And check guest cpu flags.

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

(2) Boot up guest with "-M q35" and check guest cpu flags. 

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

(3) Boot up guest with "-M rhel6.5.0" and "-M rhel6.4.0" separately and check guest cpu flags.

Result: There's "tsc_deadline_timer" flag inside guest when boot with rhel6.4.0 or rhel6.5.0 machine types. 

(4) Boot up guest with "-M rhel6.3.0"/"-M rhel6.2.0"/"-M rhel6.1.0"/"-M rhel6.0.0" machine types one by one. Check guest cpu flags each time after guest boots up. 

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

(5) Migrate guest from rhel6.5 host to rhel7.0 host with "-M rhel6.3.0" machine type, check the guest cpu flags before and after migration. 

Result: There's NO "tsc_deadline_timer" flag inside guest before and after migration. Migration could finish successfully. 

(6) Migrate guest from rhel6.5 host to rhel7.0 host with "-M rhel6.5.0" machine type, check the guest cpu flags before and after migration. 

Result: There's "tsc_deadline_timer" flag inside guest before and after migration. Migration could finish successfully. 

Based on above, this bug is fixed.
Comment 4 Ludek Smid 2014-06-13 08:22:54 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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