https://bugzilla.suse.com/show_bug.cgi?id=1178516 https://bugzilla.suse.com/show_bug.cgi?id=1178516#c8 --- Comment #8 from James Fehlig --- (In reply to Lin Ma from comment #6)

From libvirt's perspective: The implementation of ifcfg-list command relies on libudev1 on server side.

Unfortunately, it's a little more complicated...

You experienced the error: this function is not supported by the connection driver: virConnectNumOfInterfaces, So I'm guessing whether the libudev1 package is damaged during upgrade, or the libudev1 package in 20201023 introduced this issue.

Like many drivers in libvirt, the interface driver supports multiple backends. When libvirtd loads the interface driver, it will try all build-time configured backends until one succeeds https://gitlab.com/libvirt/libvirt/-/blob/master/src/interface/interface_dri... But SUSE has long-standing patch to make the netcf driver use libnetcontrol underneath https://build.opensuse.org/package/view_file/Virtualization/libvirt/libvirt-... In fact, the patch predates the udev interface backend. It has been around since the days of SLE11 GA! Note the call to netcf_init() on line 119 of the patch. If NetworkManager is running, that call will fail but netcfIfaceRegister() returns 0. There is never an attempt to load the udev backend. As I said, the patch predates the udev backend and was not correctly forward ported long, long ago when the udev backend was added :-(. We could "fix" the patch to return failure from netcfIfaceRegister() and attempt to load the udev backend, but this would actually be a significant change in behavior. We would suddenly use an interface backend (when NetworkManager is running on the host) that we've never used before and is untested. But IMO, this is all orthogonal to the reporter's problem. Interface management (virsh iface-*) has always been "disabled" when the host uses NetworkManager. And AFAIK, the reporter in not trying to manage interfaces, especially since that functionality was dropped from upstream virt-manager quite a while back. As I understand it, the reporter is just trying to see the <source> for a given <interface> of a VM. The 'virsh dumpxml' output of each VM and output of 'ip addr' on the host might give us some more clues. As mentioned in #5, the output of 'ip addr' from the previously working 20200907 snapshot might help too. -- You are receiving this mail because: You are on the CC list for the bug.