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
following.)
[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,
check='partial'.
--
/kashyap
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
