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