RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1167072 - virsh save fails on RHEL6.6 unless CPU type of guest is default/generic
Summary: virsh save fails on RHEL6.6 unless CPU type of guest is default/generic
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python-virtinst
Version: 6.6
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Giuseppe Scrivano
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 1188245 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-23 09:06 UTC by Richard Brittain
Modified: 2019-07-11 08:22 UTC (History)
13 users (show)

Fixed In Version: python-virtinst-0.600.0-26.el6
Doc Type: Bug Fix
Doc Text:
Previously, changing the processor type to "copy from host" caused all CPU extensions to be copied manually, even extensions that were not supported for migration. As a consequence, running the "virsh save" command after reboot failed, and an error message was displayed. With this update, when the "--cpu=host" option is specified, the "cpu mode='host-model'" option is used. As a result, unsupported extensions are not no longer manually copied, and the described error no longer occurs.
Clone Of:
Environment:
Last Closed: 2015-07-22 07:06:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
VM XML as a 'generic' CPU (2.86 KB, text/plain)
2015-01-19 20:45 UTC, Richard Brittain 		no flags Details
VM definition after changing CPU type to match host 'westmere' (4.68 KB, text/plain)
2015-01-19 20:47 UTC, Richard Brittain 		no flags Details
virt-manager --debug output showing errors on 'save' operation (8.26 KB, text/plain)
2015-01-19 20:48 UTC, Richard Brittain 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1372 0 normal SHIPPED_LIVE python-virtinst bug fix update 2015-07-20 17:58:46 UTC

Description Richard Brittain 2014-11-23 09:06:38 UTC 
Description of problem:
After upgrading to RHEL6.6 and latest libvirt/virt-manager/qemu packages, existing 
guest VMs are failing 'virsh save' with a message similar to that in Bug 841629 - (but that is very old).
virsh/virt-manager was working as expected before the reboot.

A newly created VM with the default processor setting (no optional hardware features) works as expected, but selecting 'copy from host' for the CPU type causes the 'virsh save' problem.  Tested on two hosts, with hardware types 'Westmere' and 'SandyBridge'

Version-Release number of selected component (if applicable):
kernel 2.6.32-504.el6.x86_64 #1 SMP Tue Sep 16 01:56:35 EDT 2014 x86_64 x86_64 x86_64 
virt-manager-0.9.0-28.el6.x86_64

How reproducible:


Steps to Reproduce:
1. Define a VM.  Leave the processor default settings at the default.  The guest OS does not seem to matter.
2. 'virsh save' works
3. Change the processor type to 'copy from host' and reboot the guest.
4. 'virsh save' fails.

Actual results:


Expected results:


Additional info:
Comment 2 Ján Tomko 2015-01-19 13:41:07 UTC 
Can you provide the exact libvirt version, the XML of the failing VM and the exact error message? (by running virt-manager with --debug in a terminal)

Without that, I can only guess that 'copy from host' is done by virt-manager and it also includes CPU features that don't work with save.
Comment 3 Richard Brittain 2015-01-19 20:45:40 UTC 
Created attachment 981601 [details]
VM XML as a 'generic' CPU
Comment 4 Richard Brittain 2015-01-19 20:47:41 UTC 
Created attachment 981602 [details]
VM definition after changing CPU type to match host 'westmere'
Comment 5 Richard Brittain 2015-01-19 20:48:35 UTC 
Created attachment 981603 [details]
virt-manager --debug output showing errors on 'save' operation
Comment 6 Ján Tomko 2015-01-20 09:33:19 UTC 
The Westmere XML explicitly lists the 'invtsc' feature which blocks save/migration. Deleting the feature or using <cpu mode='host-model'/> should both produce a CPU that allows save.

Moving the bug to virt-manager to see if it can stop adding this non-migratable feature.
Comment 7 Giuseppe Scrivano 2015-01-20 11:48:21 UTC 
I don't think virt-manager should get to this level of details and filtering out non-migratable features, virt-manager reads this information directly from the cpu_map.xml file (it has been changed upstream and in RHEL-7).  The easiest way to workaround it is to choose a CPU which hasn't that feature (or manually drop it) from the XML.
Comment 8 Richard Brittain 2015-01-20 20:23:15 UTC 
Great - disabling 'invtsc' explicitly does seem to fix the problem.  I see that RHEL7 doesn't specify it.  It does seem to be a serious portability problem that 'copy from host' results in an un-saveable guest.
Comment 9 Giuseppe Scrivano 2015-01-23 11:10:57 UTC 
that's why virt-manager changed a lot in RHEL-7 and we are late in RHEL-6 to think about back-porting it.  It seems that the best solution is to choose a different model or manually drop "invtsc" as you have done.
Comment 10 Giuseppe Scrivano 2015-02-02 16:11:54 UTC 
*** Bug 1188245 has been marked as a duplicate of this bug. ***
Comment 15 zhoujunqin 2015-03-03 03:33:50 UTC 
I can reproduce this issue with package:
python-virtinst-0.600.0-24.el6.noarch
virt-manager-0.9.0-28.el6.x86_64

steps to reproduce:
1. Use virt-install cmd install a guest with option "--cpu host":
# virt-install -n cpu-test-old -r 1024 --cpu host --disk=/var/tmp/cpu-test-old.img,size=5 --cdrom=/iso/RHEL-6.6-20140926.0-Server-x86_64-dvd1.iso 

Starting install...
Creating storage file cpu-test-old.img                                                                                                | 5.0 GB     00:00     
Creating domain...        
...

Result: Installation finished with no error.
# virsh dumpxml cpu-test-old
...
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>Nehalem</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='avx'/>
    <feature policy='require' name='tsc-deadline'/>
    <feature policy='require' name='dtes64'/>
    <feature policy='require' name='xsave'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='xtpr'/>
    <feature policy='require' name='pcid'/>
    <feature policy='require' name='est'/>
    <feature policy='require' name='monitor'/>
    <feature policy='require' name='smx'/>
    <feature policy='require' name='tm'/>
    <feature policy='require' name='pclmuldq'/>
    <feature policy='require' name='acpi'/>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='osxsave'/>
    <feature policy='require' name='tm2'/>
    <feature policy='require' name='ht'/>
    <feature policy='require' name='pdcm'/>
    <feature policy='require' name='ds'/>
    <feature policy='require' name='invtsc'/>
    <feature policy='require' name='rdtscp'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='pbe'/>
    <feature policy='require' name='ds_cpl'/>
    <feature policy='require' name='x2apic'/>
  </cpu>
...

2. Use virsh cmd to save the guest:
# virsh save cpu-test-old /tmp/cpu-test-old.save
error: Failed to save domain cpu-test-old to /tmp/cpu-test-old.save
error: internal error unable to execute QEMU command 'migrate': An undefined error has ocurred

Then try to verify this bug with new build:
virt-manager-0.9.0-29.el6.x86_64
python-virtinst-0.600.0-26.el6.noarch

steps to verify:
1.
# virt-install -n cpu-test -r 1024 --cpu host --disk=/var/tmp/cpu-test.img,size=5 --cdrom=/iso/RHEL-6.6-20140926.0-Server-x86_64-dvd1.iso 

Starting install...
Creating storage file cpu-test.img                                                                                                    | 5.0 GB     00:00     
Creating domain...                                                                                                                    |    0 B     00:00     
...
Result: Installation finished with no error.

# virsh dumpxml cpu-test 
...
  </features>
  <cpu mode='host-model'>
    <model fallback='allow'/>
  </cpu>
...
2.
# virsh save cpu-test /tmp/cpu-test.save2 

Domain cpu-test saved to /tmp/cpu-test.save2

# virsh restore /tmp/cpu-test.save2 
Domain restored from /tmp/cpu-test.save2

Result: Guest can be saved/restored successfully.
So move this bug from ON_QA to VERIFIED.
Comment 16 errata-xmlrpc 2015-07-22 07:06:20 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.

https://rhn.redhat.com/errata/RHBA-2015-1372.html
Note You need to log in before you can comment on or make changes to this bug.