On Wed, Jan 10, 2018 at 11:03:20 +0100, Kashyap Chamarthy wrote:
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:
...
> > 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').
Did they stored the XMLs dumped while the original domain was running
and used them to start the domains on newer QEMU? 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.
Jirka