issue when not using acpi indices in libvirt 7.4.0 and qemu 6.0.0

[Laine Stump]

On 6/23/21 7:37 PM, Riccardo Ravaioli wrote:
> On Wed, 23 Jun 2021 at 18:59, Daniel P. Berrangé <berrange at redhat.com 
> <mailto:berrange at redhat.com>> wrote:
> 
>     [...]
>     So your config here does NOT list any ACPI indexes
> 
> 
> Exactly, I don't list any ACPI indices.
> 
>      > After upgrading to libvirt 7.4.0 and qemu 6.0.0, the XML snippet
>     above
>      > yielded:
>      > - ens1 for the first virtio interface => OK
>      > - rename4 for the second virtio interface => **KO**

(this is reminiscent of what would sometimes happen back in the "bad old 
days" of ethN NIC naming.)

>      > - ens3 for the PCI passthrough interface  => OK

With the older libvirt + qemu, the guest (Debian) was setting the device 
names to ens1, ens2, and ens3 (through some sort of renaming, apparently 
by udev. The names that these interfaces would normally get (e.g. in 
Fedora or RHEL8) would be enp1s1, enp1s2, and enp1s3.

With the newer libvirt + qemu, the guest still has the names set by 
systemd (?) to enp1s1, enp1s2, and enp1s3.

>     So from libvirt's POV, nothing should have changed upon upgrade,
>     as we wouldn't be setting any ACPI indexes by default.

Right. If ACPI indexes had been turned on, I would have expected the 
names to be, e.g., eno1, eno2, eno3. But that would require explicitly 
adding the option to the qemu commandline, but it isn't there (see below).

> 
>     Can you show the QEMU command line from /var/log/libvirt/qemu/$GUEST.log
>     both before and after the libvirt upgrade.
> 
> 
> Sure, here it is before the upgrade: https://pastebin.com/ZzKd2uRJ 
> <https://pastebin.com/ZzKd2uRJ>

-netdev tap,fd=50,id=hostnet0 \
-device 
virtio-net-pci,csum=off,netdev=hostnet0,id=net0,mac=52:54:00:aa:cc:05,bus=pci.1,addr=0x1 
\
-netdev tap,fd=51,id=hostnet1 \
-device 
virtio-net-pci,csum=off,netdev=hostnet1,id=net1,mac=52:54:00:aa:bb:81,bus=pci.1,addr=0x2 
\
[...]
-device vfio-pci,host=0000:0d:00.0,id=hostdev0,bus=pci.1,addr=0x3 \

> And here after the upgrade: https://pastebin.com/EMu6Jgat 
> <https://pastebin.com/EMu6Jgat>

-netdev tap,fd=55,id=hostnet0 \
-device 
virtio-net-pci,csum=off,netdev=hostnet0,id=net0,mac=52:54:00:aa:cc:a0,bus=pci.1,addr=0x1 
\
-netdev tap,fd=56,id=hostnet1 \
-device 
virtio-net-pci,csum=off,netdev=hostnet1,id=net1,mac=52:54:00:aa:bb:a1,bus=pci.1,addr=0x2 
\
[...]


So there is no change in the qemu commandline for the virtio-net 
devices, nor for the hostdev.

(BTW, you say that your vfio-assigned device is SRIOV, but it isn't - 
it's a standard ethernet device - "Intel Corporation I210 Gigabit 
Network Connection" - this has no effect on the current conversation, 
just FYI).

Since the name of the devices hasn't changed to "enoBLAH", I think the 
whole ACPI index thing is a red herring - ACPI indexes aren't being set 
and the device names aren't being set based on the non-existent ACPI 
indexes. There is something else going on (seemingly tied to the device 
renaming that udev (?) is doing from enpXsY to ensZ).

I notice that you're apparently redefining this domain from scratch each 
time it is started.

1) The machinetype changes from pc-i440fx-5.2 to pc-i440fx-6.0, implying 
that each time the domain is started, it is being told to use the 
generic machinetype "pc", which is then canonicalized to "the newest 
pci-i440fx-based machinetype" before starting the guest.

2) The MAC address has been changed for the two virtio-net cards, but 
not to some random number as would happen if you were allowing libvirt.

It's common for OSes to notice a new MAC address and attempt to give the 
interface a new name. Perhaps this is happening and whoever/whatever is 
doing that is screwing things up. Or it's possible there is some minor 
change in the machinetype from pc-i440fx-5.2 to pc-i440fx-6.0 that is 
causing this renaming to behave differently.

If you really need your guests to be stable, you shouldn't just use "pc" 
as the machinetype every time the guest is started, but instead save the 
canonicalized machinetype listed in the XML when you initially define 
the domain, and use that canonicalized machinetype on all future starts 
of the domain. Likewise, you should retain the exact MAC addresses that 
are used for all the NICs when the domain is originally defined and 
started for the first time, and use those exact same MAC addresses in 
subsequent starts. That way you are guaranteed (modulo any bugs) that 
the guest is presented with the exact same hardware each time it boots. 
If you use "virsh define" and "virsh start" (rather than "virsh create" 
- I can't be certain this is what you're doing, but there are clues 
indicating it might be the case) then all these details are 
automatically preserved for you within libvirt's persistent domain 
configuration.

One other comment - I don't remember the exact location, but I recall 
from a long long time ago that udev saves the information about names 
that it gives to NICs "somewhere". You may want to find and clear out 
that cache of info in the guest to get "clean" NIC names with this 
particular guest. You may continue to get odd results until you do this.