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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
