[libvirt] [PATCH] docs: formatdomain: Specify the default value of 'check' attribute

[Kashyap Chamarthy]

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