Bug 1167072

Summary: virsh save fails on RHEL6.6 unless CPU type of guest is default/generic
Product: Red Hat Enterprise Linux 6 Reporter: Richard Brittain <richard.brittain>
Component: python-virtinstAssignee: Giuseppe Scrivano <gscrivan>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.6CC: asegundo, dyuan, gscrivan, honzhang, juzhou, mnavrati, mzhan, pbandark, rbalakri, richard.brittain, tlavigne, tzheng, xiaodwan
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-22 07:06:20 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:
Attachments:
Description Flags
VM XML as a 'generic' CPU
none
VM definition after changing CPU type to match host 'westmere'
none
virt-manager --debug output showing errors on 'save' operation none

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