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

Kashyap Chamarthy kchamart at redhat.com
Wed Jan 10 14:54:00 UTC 2018

On Wed, Jan 10, 2018 at 11:17:21AM +0100, Jiri Denemark wrote:
> On Wed, Jan 10, 2018 at 11:03:20 +0100, Kashyap Chamarthy wrote:


> > 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').
> Did they stored the XMLs dumped while the original domain was running
> and used them to start the domains on newer QEMU? 

No, they didn't do something like that.  (But I asked them the

[kashyap] So you didn't do any dumping of guest XMLs and using them to
          start the guests on updated QEMU?
[admin] No.
[admin] These XML files were generated by libvirt.
[kashyap] So you simply updated QEMU, the guest was offline, and
          starting the guest failed w/ the missing CPU features.  Yes?
[admin] At least, for this guest that I was talking about I can't
        guarantee (I'm 99% sure we didn't migrate it; but can't
        say 100%). I can test it with another one if you want

> The XML definition stored in libvirt should still have the original
> check='partial' and the domain should start fine after upgrading QEMU.
> But even with check='full' the domain should start fine since QEMU
> shouldn't be adding new features unless they also changed machine type
> in the XML.
> If the check='full' is stored in the inactive XML in
> /etc/libvirt/qemu, then this is something we need to look at.

The admin reports that: "So, I am pretty sure that it was stored in the
inactivce XML at some point, because of the fact that I had the error"

I'll mention them to keep an eye on it.  

But he could confirm that with libvirt 3.2.0 and QEMU 2.9.0, creating
new guests with `virt-install` does give him, correctly,


More information about the libvir-list mailing list