Bug 1228073 - Autostarted libvirt network does not create interface
Summary: Autostarted libvirt network does not create interface
Status: NEW
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: Virtualization:Other (show other bugs)
Version: Leap 15.6
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: James Fehlig
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-17 14:23 UTC by Georg Pfuetzenreuter
Modified: 2024-07-17 14:45 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Georg Pfuetzenreuter 2024-07-17 14:23:41 UTC
Hi,

since upgrading one of our hypervisors to 15.6, we notice the interface for a libvirt network no longer gets created at boot.

The network is started automatically (state active):

```
stonehat:~ # virsh net-list
 Name      State    Autostart   Persistent
--------------------------------------------
 private   active   yes         yes
```

But the interface "private" does not exist, naturally causing VMs to not start automatically either:

```
Jul 16 11:11:31 stonehat virtqemud[5218]: Cannot get interface MTU on 'private': No such device
Jul 16 11:11:31 stonehat virtqemud[5218]: internal error: Failed to autostart VM 'ipx-status1': Cannot get interface MTU on 'private': No such device
Jul 16 11:11:31 stonehat virtqemud[5218]: Cannot get interface MTU on 'private': No such device
...
```

One needs to restart the network with

```
virsh net-destroy private
virsh net-start private
```

- only then the "private" interface is created (shown in `ip l`) and VMs using it can be started again.

Some more potentially useful information:

```
stonehat:~ # virsh net-dumpxml private
<network>
  <name>private</name>
  <uuid>75bb8767-8f3f-4b54-8469-11226d417839</uuid>
  <forward mode='route'/>
  <bridge name='private' stp='on' delay='0'/>
  <mac address='52:54:00:6e:cc:1f'/>
  <dns enable='no'/>
  <ip address='192.168.87.1' netmask='255.255.255.0'>
  </ip>
</network>

stonehat:~ # rpm -qa libvirt*
libvirt-daemon-driver-interface-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-storage-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-config-network-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-secret-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-proxy-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-storage-rbd-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-log-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-nwfilter-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-storage-iscsi-direct-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-storage-core-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-storage-disk-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-plugin-lockd-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-nodedev-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-storage-mpath-10.0.0-150600.8.6.2.x86_64
libvirt-client-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-qemu-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-storage-iscsi-10.0.0-150600.8.6.2.x86_64
libvirt-libs-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-storage-scsi-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-lock-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-storage-logical-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-common-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-storage-gluster-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-driver-network-10.0.0-150600.8.6.2.x86_64
libvirt-daemon-qemu-10.0.0-150600.8.6.2.x86_64
```

Before the upgrade, with 15.5, we did not have this issue.

Any ideas?