Red Hat Bugzilla – Bug 1278416
Regression in support for custom CPU configuration
Last modified: 2015-11-06 05:12:03 EST
Description of problem:
VM's with custom CPU no longer work following an upgrade of the host from Fedora 21 to Fedora 22, 1.2.9-2.fc21 to 18.104.22.168-3
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. have a VM XML file with a custom <cpu> section
2. start it on Fedora 22
"error: unsupported configuration: guest and host CPU are not compatible: host CPU vendor does not match required CPU vendor Intel"
VM starts as on Fedora 21 and earlier.
If I delete the <cpu> element entirely from the XML file, the VM works
This looks to be the same symptoms as at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797513 though the versions differ.
Would you mind sharing more details so that we can actually look at this issue? Please, attach
- full domain XML
- the output of "virsh capabilities"
- the output of "cpuid -1r"
In addition to this, please set
log_filters="1:cpu 1:qemu 1:daemon"
in /etc/libvirt/libvirtd.conf, restart libvirtd service and attach the generated libvirtd.log file.
Created attachment 1090094 [details]
Sure, info attached. Happy to provide more and test as required.
So this is actually very different from the Debian bug report. And everything seems to be working as expected. You host has an AMD CPU, but the domain XML contains <vendor>Intel</vendor>, which is explicitly asking for a host CPU made by Intel. The support for <vendor> element was added to libvirt in 0.8.3 and it was designed to always work the way you see. And on Fedora 21 starting a domain with <vendor>Intel</vendor> on an AMD host should fail in the same way it fails on Fedora 22. There was no CPU vendor related patch between 1.2.9 and 1.2.13 as far as I know. If it worked for you on F21, it was a bug. If you don't really insist on running the domain on Intel CPUs only, just remove <vendor>Intel</vendor> from the domain XML.
Okay, thanks for looking into it. I guess as Fedora 21 is going EOL in a few more days that its bugginess is irrelevant.