[libvirt-users] How to explain this libvirt oddity w.r.t machine types?

[Kashyap Chamarthy]

Context: The baremetal host previously had QEMU 2.11. But I manually
downgraded the QEMU version (via `dnf downgrade qemu-system-x86`); now
it is at 2.10:

$ rpm -q qemu-system-x86
qemu-system-x86-2.10.2-1.fc27.x86_64

The guest is offline. Let's see (in a couple of ways) what machine type
it has while it is dormant:

# virsh dumpxml cirros | grep -i machine=
<type arch='x86_64' machine='pc-i440fx-2.10'>hvm</type>

# grep machine= /etc/libvirt/qemu/cirros.xml
<type arch='x86_64' machine='pc-i440fx-2.10'>hvm</type>

Okay, now edit the guest XML and carefully remove the
"machine='pc-i440fx-2.10'" bit---to see what machine type will libvirt
(libvirt-daemon-kvm-4.0.0-2.fc27.x86_64) default to:

# virsh edit cirros
Domain cirros XML configuration edited.

Now check the machine type again. Bizarrely enough, libvirt "helpfully"
auto-adds QEMU *2.11* machine type, which is obviously no longer on the
system!

# grep machine= /etc/libvirt/qemu/cirros.xml
<type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type>

# virsh dumpxml cirros | grep -i machine=
<type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type>

How to explain this? Is this even a "valid test"?

(To undo the nuisance, obviously, I had to `virsh edit cirros` again and
change it to 2.10.)

Note, I *don't* have 2.11 QEMU on the system:

# rpm -qa | grep -E 'qemu.*2.11'
# echo $?
1

* * *

It's getting late, and I should stop staring at screens.

[Andrea Bolognani]

Post by Kashyap Chamarthy
Context: The baremetal host previously had QEMU 2.11. But I manually
downgraded the QEMU version (via `dnf downgrade qemu-system-x86`); now
$ rpm -q qemu-system-x86
qemu-system-x86-2.10.2-1.fc27.x86_64
The guest is offline. Let's see (in a couple of ways) what machine type
# virsh dumpxml cirros | grep -i machine=
<type arch='x86_64' machine='pc-i440fx-2.10'>hvm</type>
# grep machine= /etc/libvirt/qemu/cirros.xml
<type arch='x86_64' machine='pc-i440fx-2.10'>hvm</type>
Okay, now edit the guest XML and carefully remove the
"machine='pc-i440fx-2.10'" bit---to see what machine type will libvirt
# virsh edit cirros
Domain cirros XML configuration edited.
Now check the machine type again. Bizarrely enough, libvirt "helpfully"
auto-adds QEMU *2.11* machine type, which is obviously no longer on the
system!
# grep machine= /etc/libvirt/qemu/cirros.xml
<type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type>
# virsh dumpxml cirros | grep -i machine=
<type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type>
How to explain this? Is this even a "valid test"?
(To undo the nuisance, obviously, I had to `virsh edit cirros` again and
change it to 2.10.)
# rpm -qa | grep -E 'qemu.*2.11'
# echo $?
1
* * *
It's getting late, and I should stop staring at screens.

If I had to guess, I would say the <emulator> element of your guest
is probably pointing to a custom-built QEMU 2.11 binary rather than
the default one installed from RPMs.

[Kashyap Chamarthy]

[...]

Post by Andrea Bolognani

Post by Kashyap Chamarthy
Now check the machine type again. Bizarrely enough, libvirt "helpfully"
auto-adds QEMU *2.11* machine type, which is obviously no longer on the
system!
# grep machine= /etc/libvirt/qemu/cirros.xml
<type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type>
# virsh dumpxml cirros | grep -i machine=
<type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type>
How to explain this? Is this even a "valid test"?
(To undo the nuisance, obviously, I had to `virsh edit cirros` again and
change it to 2.10.)

[...]

Post by Andrea Bolognani
If I had to guess, I would say the <emulator> element of your guest
is probably pointing to a custom-built QEMU 2.11 binary rather than
the default one installed from RPMs.

Your guess made me curious enough to check the remote machine one last
time before I went to sleep, but unfortunately the <emulator> element is
pointing to the plain `/usr/bin/qemu-kvm`, which in turn exec()'s
`/usr/bin/qemu-system-x86_64`.

(I attached the nothing-special, full guest XML.)

[Andrea Bolognani]

Post by Kashyap Chamarthy

Post by Andrea Bolognani
If I had to guess, I would say the <emulator> element of your guest
is probably pointing to a custom-built QEMU 2.11 binary rather than
the default one installed from RPMs.

Your guess made me curious enough to check the remote machine one last
time before I went to sleep, but unfortunately the <emulator> element is
pointing to the plain `/usr/bin/qemu-kvm`, which in turn exec()'s
`/usr/bin/qemu-system-x86_64`.
(I attached the nothing-special, full guest XML.)

Interesting. What is the output of 'virsh capabilities'?

More interesting still is the fact that the guest XML you shared
looks like an *active* XML, ie. one taken from a running guest...
Does that mean the guest can start even though it's using the 2.11
machine type?

[Kashyap Chamarthy]

On Mon, Oct 15, 2018 at 09:05:16AM +0200, Andrea Bolognani wrote:

[...]

Post by Andrea Bolognani
Interesting. What is the output of 'virsh capabilities'?

In attachment.

Post by Andrea Bolognani
More interesting still is the fact that the guest XML you shared
looks like an *active* XML, ie. one taken from a running guest...
Does that mean the guest can start even though it's using the 2.11
machine type?

No, of course it doesn't; the guest is running because I `virsh-edit`ed
it to use 2.10 machine type :-)

[Andrea Bolognani]

Post by Kashyap Chamarthy

Post by Andrea Bolognani
Interesting. What is the output of 'virsh capabilities'?

In attachment.

Looks reasonable enough.

Post by Kashyap Chamarthy

Post by Andrea Bolognani
More interesting still is the fact that the guest XML you shared
looks like an *active* XML, ie. one taken from a running guest...
Does that mean the guest can start even though it's using the 2.11
machine type?

No, of course it doesn't; the guest is running because I `virsh-edit`ed
it to use 2.10 machine type :-)

Should have noticed that.

Welp, I'm fresh out of ideas then :/