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-virtinst | Assignee: | Giuseppe Scrivano <gscrivan> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 6.6 | CC: | asegundo, dyuan, gscrivan, honzhang, juzhou, mnavrati, mzhan, pbandark, rbalakri, richard.brittain, tlavigne, tzheng, xiaodwan | ||||||||
Target Milestone: | rc | Keywords: | 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
Richard Brittain
2014-11-23 09:06:38 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. Created attachment 981601 [details]
VM XML as a 'generic' CPU
Created attachment 981602 [details]
VM definition after changing CPU type to match host 'westmere'
Created attachment 981603 [details]
virt-manager --debug output showing errors on 'save' operation
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. 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. 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. 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. *** Bug 1188245 has been marked as a duplicate of this bug. *** 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. 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 |