On Tue, Jan 09, 2018 at 08:28:20PM +0100, Jiri Denemark wrote:
On Tue, Jan 09, 2018 at 19:44:18 +0100, Kashyap Chamarthy wrote:
[...]
I'm not saying there's nothing to be clarified. Just that explicitly specifying the default value will not help at all since it's complicated and confusing by itself especially because of backward compatibility.
Yeah, that I agree with you. It was just a v1 :-) (It would've been clearer if youd've said: "NACK — needs some fixing". [...]
$> virt-install --name vm1 --ram 2048 \ --disk path=./vm1.qcow2,format=qcow2 --nographics \ --import --os-variant fedora27
$> virsh dumpxml vm1 | grep check <cpu mode='custom' match='exact' check='full'>
(You might, fairly, argue here that: "Well, that's a bug in `virt-install`, go complain there.")
I guess it's just the default behavior of virt-install and it automatically passes the host CPU model to domain XML (without check attribute, relying on the default) when creating new domains. After all, any CPU model is going to be better than the default qemu64.
Right.
Background for others reading: The admin who reported this was confused when he was creating guests with `virt-install`, which adds check='full' (as noted earlier), and the guest throws:
error: Failed to start domain foo.org error: operation failed: guest CPU doesn't match specification: extra features: vme,arat
If this really happens when creating a domain with virt-install,
Right, it doesn't happen on domain start (I worded it poorly). The error occurred only after QEMU was updated (from 2.6.5 to 2.9).
then it's clearly a bug. But I don't believe it's what happened. The dumpxml above says check='full', which means the domain was successfully started and its CPU def was updated according to QEMU and thus the check attribute was changed to 'full'.
Noted.
The vme and arat features are added because libvirt's and QEMU's vision of the particual CPU model differs. Libvirt specifies it without vme and arat while QEMU has them both included in the CPU model. Thus when libvirt asks for that CPU model, QEMU enables these extra features too and libvirt adds them to the domain XML so that it can make sure they don't disappear when the domain is migrated or save/restored.
Thanks for that explanation.
So "somehow" QEMU added the CPU features 'vme' and 'arat' by itself, now you have to specify them in libvirt. So the admin ended up with a `sed` one-liner that updates the guest XML with the missing features:
sed -i -e "s-</cpu>-<feature policy='require' name='vme'/></cpu>-" sed -i -e "s-</cpu>-<feature policy='require' name='arat'/></cpu>-"
This is some strange mangling of the XML by the admin for unclear reason.
It was necessary mangling (the same as running `virt-xml`), as without adding the 'vme' and 'arat' features to their libvirt CPU definition, their guests wouldn't start anymore.
It would be nice to finally see what the admin wanted to achieve, what steps they did, and what result they saw.
I just double-confirmed with the admin, this was what happened: - They were running QEMU 2.6.5, VMs were starting fine. - Once they upgraded QEMU to 2.6.9, "suddenly" none of their VMs were starting, throwing the error about mismatch of guest CPU defintion (and the missing 'extra features'). - It was fixed once they explicitly added the two features ('vme' and 'arat') to the CPU guest XML.
Versions: libvirt 3.2 and QEMU 2.9
It's certainly possible there was a bug in 3.2 which got fixed since then (there were several of them), but it's impossible to guess without seeing what they're doing.
Noted above. -- /kashyap