Riccardo Ravaioli
2021-Jun-23 16:49 UTC
issue when not using acpi indices in libvirt 7.4.0 and qemu 6.0.0
Hi everyone,
We have an issue with how network interfaces are presented in the VM with
the latest libvirt 7.4.0 and qemu 6.0.0.
Previously, we were on libvirt 7.0.0 and qemu 5.2.0, and we used increasing
virtual PCI addresses for any type of network interface (virtio, PCI
passthrough, SRIOV) in order to decide the interface order inside the VM.
For instance the following snippet yields ens1, ens2 and ens3 in a Debian
Buster VM:
<interface type="ethernet">
<target dev="0.vSrv"/>
<mac address="52:54:00:aa:cc:05"/>
<address bus="0x01" domain="0x0000"
function="0x0" slot="0x01"
type="pci"/>
<model type="virtio"/>
<driver>
<host csum="off"/>
</driver>
</interface>
<interface type="ethernet">
<target dev="1.vSrv"/>
<mac address="52:54:00:aa:bb:81"/>
<address bus="0x01" domain="0x0000"
function="0x0" slot="0x02"
type="pci"/>
<model type="virtio"/>
<driver>
<host csum="off"/>
</driver>
</interface>
<hostdev managed="yes" mode="subsystem"
type="pci">
<source>
<address bus="0x0d" domain="0x0000"
function="0x0" slot="0x00"/>
</source>
<address bus="0x01" domain="0x0000"
function="0x0" slot="0x03"
type="pci"/>
</hostdev>
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**
- ens3 for the PCI passthrough interface => OK
Argh! What happened to ens2? By running udev inside the VM, I see that
"rename4" is the result of a conflict between the ID_NET_NAME_SLOT of
the
second and the third interface, both appearing as ID_NET_NAME_SLOT=ens3. In
theory rename4 should show ID_NET_NAME_SLOT=ens2. What happened?
# udevadm info -q all /sys/class/net/rename4
P: /devices/pci0000:00/0000:00:03.0/0000:01:02.0/virtio4/net/rename4
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:03.0/0000:01:02.0/virtio4/net/rename4
E: INTERFACE=rename4
E: IFINDEX=4
E: SUBSYSTEM=net
E: USEC_INITIALIZED=94191911
E: ID_NET_NAMING_SCHEME=v240
E: ID_NET_NAME_MAC=enx525400aabba1
E: ID_NET_NAME_PATH=enp1s2
E: ID_NET_NAME_SLOT=ens3
E: ID_BUS=pci
E: ID_VENDOR_ID=0x1af4
E: ID_MODEL_ID=0x1000
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Red Hat, Inc.
E: ID_MODEL_FROM_DATABASE=Virtio network device
E: ID_PATH=pci-0000:01:02.0
E: ID_PATH_TAG=pci-0000_01_02_0
E: ID_NET_DRIVER=virtio_net
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/rename4
E: TAGS=:systemd:
# udevadm info -q all /sys/class/net/ens3
P: /devices/pci0000:00/0000:00:03.0/0000:01:03.0/net/ens3
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:03.0/0000:01:03.0/net/ens3
E: INTERFACE=ens3
E: IFINDEX=2
E: SUBSYSTEM=net
E: USEC_INITIALIZED=3600940
E: ID_NET_NAMING_SCHEME=v240
E: ID_NET_NAME_MAC=enx00900b621235
E: ID_OUI_FROM_DATABASE=LANNER ELECTRONICS, INC.
E: ID_NET_NAME_PATH=enp1s3
E: ID_NET_NAME_SLOT=ens3
E: ID_BUS=pci
E: ID_VENDOR_ID=0x8086
E: ID_MODEL_ID=0x1533
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_MODEL_FROM_DATABASE=I210 Gigabit Network Connection
E: ID_PATH=pci-0000:01:03.0
E: ID_PATH_TAG=pci-0000_01_03_0
E: ID_NET_DRIVER=igb
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/ens3
E: TAGS=:systemd:
Is there anything we can do in the XML definition of the VM to fix this?
The PCI tree from within the VM is the following, if it helps:
(with libvirt 7.0.0 and qemu 5.2.0 it was the same)
# lspci -tv
-[0000:00]-+-00.0 Intel Corporation 440FX - 82441FX PMC [Natoma]
+-01.0 Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
+-01.1 Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
+-01.2 Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II]
+-01.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI
+-02.0 Cirrus Logic GD 5446
+-03.0-[01]--+-01.0 Red Hat, Inc. Virtio network device
| +-02.0 Red Hat, Inc. Virtio network device
| \-03.0 Intel Corporation I210 Gigabit Network
Connection
+-04.0-[02]--
+-05.0-[03]--
+-06.0-[04]--
+-07.0-[05]--
+-08.0-[06]----01.0 Red Hat, Inc. Virtio block device
+-09.0 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port
SATA Controller [AHCI mode]
+-0a.0 Red Hat, Inc. Virtio console
+-0b.0 Red Hat, Inc. Virtio memory balloon
\-0c.0 Red Hat, Inc. Virtio RNG
I see that a new feature in qemu and libvirt is to add ACPI indices in
order to have network interfaces appear as *onboard* and sort them through
this index as opposed to virtual PCI addresses. This is great. I see that
in this case, interfaces appear as eno1, eno2, etc.
However, for the sake of backward compatibility, is there a way to have the
previous behaviour where interfaces were called by their PCI slot number
(ens1, ens2, etc.)?
If I move to the new naming yielded by ACPI indices, I am mostly worried
about any possible change in interface names that might occur across VMs
running different OS's, with respect to what we had before with libvirt
7.0.0 and qemu 5.2.0.
Thanks!
Best,
Riccardo Ravaioli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20210623/017f04c8/attachment.htm>
Daniel P. Berrangé
2021-Jun-23 16:59 UTC
issue when not using acpi indices in libvirt 7.4.0 and qemu 6.0.0
On Wed, Jun 23, 2021 at 06:49:12PM +0200, Riccardo Ravaioli wrote:> Hi everyone, > > We have an issue with how network interfaces are presented in the VM with > the latest libvirt 7.4.0 and qemu 6.0.0. > > Previously, we were on libvirt 7.0.0 and qemu 5.2.0, and we used increasing > virtual PCI addresses for any type of network interface (virtio, PCI > passthrough, SRIOV) in order to decide the interface order inside the VM. > For instance the following snippet yields ens1, ens2 and ens3 in a Debian > Buster VM: > > <interface type="ethernet"> > <target dev="0.vSrv"/> > <mac address="52:54:00:aa:cc:05"/> > <address bus="0x01" domain="0x0000" function="0x0" slot="0x01" > type="pci"/> > <model type="virtio"/> > <driver> > <host csum="off"/> > </driver> > </interface> > <interface type="ethernet"> > <target dev="1.vSrv"/> > <mac address="52:54:00:aa:bb:81"/> > <address bus="0x01" domain="0x0000" function="0x0" slot="0x02" > type="pci"/> > <model type="virtio"/> > <driver> > <host csum="off"/> > </driver> > </interface> > <hostdev managed="yes" mode="subsystem" type="pci"> > <source> > <address bus="0x0d" domain="0x0000" function="0x0" slot="0x00"/> > </source> > <address bus="0x01" domain="0x0000" function="0x0" slot="0x03" > type="pci"/> > </hostdev>So your config here does NOT list any ACPI indexes> 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** > - ens3 for the PCI passthrough interface => OKSo from libvirt's POV, nothing should have changed upon upgrade, as we wouldn't be setting any ACPI indexes by default. Can you show the QEMU command line from /var/log/libvirt/qemu/$GUEST.log both before and after the libvirt upgrade. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|