Problem with starting qemu guest after update

[fibberblank]

After the update, virtual machines with the default network on the virbr0 interface stopped starting automatically. This is because the virbr0 interface starts much later, after the virtual machines. Machines connected to an external network on the br0 interface start normally because it is managed by the system network manager. Any suggestion please?

Here is the list of updated packages: NetworkManager-1:1.42.2-3.0.1.el9_2.x86_64 NetworkManager-libnm-1:1.42.2-3.0.1.el9_2.x86_64 NetworkManager-team-1:1.42.2-3.0.1.el9_2.x86_64 NetworkManager-tui-1:1.42.2-3.0.1.el9_2.x86_64 avahi-libs-0.8-12.el9_2.1.x86_64 glibc-2.34-60.0.2.el9.x86_64 glibc-all-langpacks-2.34-60.0.2.el9.x86_64 glibc-common-2.34-60.0.2.el9.x86_64 glibc-langpack-en-2.34-60.0.2.el9.x86_64 kexec-tools-2.0.25-13.0.1.el9_2.1.x86_64 krb5-libs-1.20.1-9.0.1.el9_2.x86_64 microcode_ctl-4:20220809-2.20230214.1.0.1.el9_2.noarch pcp-6.0.1-4.0.2.el9.x86_64 pcp-conf-6.0.1-4.0.2.el9.x86_64 pcp-libs-6.0.1-4.0.2.el9.x86_64 pcp-selinux-6.0.1-4.0.2.el9.x86_64 qemu-img-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-audio-pa-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-block-rbd-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-common-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-core-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-device-display-virtio-gpu-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-device-display-virtio-gpu-pci-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-device-display-virtio-vga-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-device-usb-host-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-device-usb-redirect-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-docs-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-tools-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-ui-egl-headless-17:7.2.0-14.el9_2.1.x86_64 qemu-kvm-ui-opengl-17:7.2.0-14.el9_2.1.x86_64 qemu-pr-helper-17:7.2.0-14.el9_2.1.x86_64 systemd-252-14.0.1.el9_2.1.x86_64 systemd-container-252-14.0.1.el9_2.1.x86_64 systemd-libs-252-14.0.1.el9_2.1.x86_64 systemd-pam-252-14.0.1.el9_2.1.x86_64 systemd-rpm-macros-252-14.0.1.el9_2.1.noarch systemd-udev-252-14.0.1.el9_2.1.x86_64 kernel-uek-5.15.0-102.110.5.1.el9uek.x86_64 kernel-uek-core-5.15.0-102.110.5.1.el9uek.x86_64 kernel-uek-modules-5.15.0-102.110.5.1.el9uek.x86_64

[totalamateurhour]

@fibberblank: To confirm, the list of packages you provided were the result of an update on an OL9 system running on bare metal and after that virtual machines no longer start. Is that correct?

[fibberblank]

That's correct. The bare metal machine is an Dell PowerEdge R630 machine equipped with four Broadcom 5720 ethernet cards. There is a bond interface on two of them and bridge connected to it, managed with NetworkManager.

The network connections are as follow: NAME TYPE DEVICE bridge0 bridge bridge0 lo loopback lo virbr0 bridge virbr0 vnet1 tun vnet1 vnet2 tun vnet2 bond0 bond bond0 bond0 port 1 ethernet eno1 bond0 port 2 ethernet eno2 eno1 ethernet -- eno2 ethernet -- eno3 ethernet -- eno4 ethernet --

The virbr0 connection is a private network managed with libvirtd. This connection is established with significant delay, after the guest attempting to start. I have second identical machine but without mentioned updates - it's working correctly.

[totalamateurhour]

Looks like a known issue. See doc for workaround: https://docs.oracle.com/en/operating-systems/oracle-linux/9/relnotes9.2/ol9.0-KnownIssues.html#ol9-issues-virtualization

[totalamateurhour]

See also Modular Driver Daemons.

[fibberblank]

Many thanks people. The virtnetworkd service did the job.