Created attachment 570344 [details] Workaround Description of problem: libvirt doesn't use the netcf driver although libvirt is linked to netcf. "virsh iface-list" for example results: Fehler: Failed to list active interfaces Fehler: this function is not supported by the connection driver: virConnectNumOfInterfaces The bug is introduced in commit e3ba402581c102d4b5e5ddb185cdae355d54a315 "util: Add netlink event handling to virnetlink.c". A workaround for the bug is not to call virNetlinkEventServiceStart, which was added in this commit. This is done in the attached patch. The call which causes the trouble seems to be nl_connect in virNetlinkEventServiceStart. If a return statement is added right befor nl_connect everything works fine. If it's placed right behind nl_connect libvirt shows the behaviour described above. "ldd libvirtd" shows: linux-vdso.so.1 => (0x00007fff99bff000) libvirt-qemu.so.0 => /usr/local/lib/libvirt-qemu.so.0 (0x00007f3206b29000) libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f320686d000) libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f3206511000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f32062f2000) libdevmapper.so.1.02.1 => /lib/libdevmapper.so.1.02.1 (0x00007f32060cf000) libnetcf.so.1 => /usr/lib/libnetcf.so.1 (0x00007f3205ebc000) libvirt.so.0 => /usr/local/lib/libvirt.so.0 (0x00007f3205a5e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3205841000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3205485000) libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007f3205274000) libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f3204ff6000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3204dde000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f3204bcc000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f32049c8000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f32046cd000) /lib64/ld-linux-x86-64.so.2 (0x00007f3206d3e000) libudev.so.0 => /lib/x86_64-linux-gnu/libudev.so.0 (0x00007f32044c0000) libaugeas.so.0 => /usr/lib/libaugeas.so.0 (0x00007f320427c000) libexslt.so.0 => /usr/lib/x86_64-linux-gnu/libexslt.so.0 (0x00007f3204066000) libxslt.so.1 => /usr/lib/x86_64-linux-gnu/libxslt.so.1 (0x00007f3203e2b000) libnl-route-3.so.200 => /usr/lib/libnl-route-3.so.200 (0x00007f3203be6000) libnl-3.so.200 => /lib/libnl-3.so.200 (0x00007f32039cd000) libyajl.so.1 => /usr/lib/x86_64-linux-gnu/libyajl.so.1 (0x00007f32037c5000) libnl.so.1 => /usr/lib/x86_64-linux-gnu/libnl.so.1 (0x00007f3203574000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f320336b000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3203168000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f3202f63000) libfa.so.1 => /usr/lib/libfa.so.1 (0x00007f3202d52000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3202b3c000)
Using the current version of netcf (commit d340f2dfcd6461c9743dccdabe3b610f5fbc8fe8) the problem doesn't exist!
What platform are you running on, and what version/build of netcf was previously on your system? (btw, the output of ldd isn't very useful, as the version numbers given there rarely change, and do not give any information that could reliably correlate a particular set of source. the output of "rpm -q $packagename" is much more useful (if you're on a system that uses rpm)
Ah, I just now connected your name with the other bug you reported (Bug 804575) and see that you are running on ubuntu. Apparently the ubuntu netcf build (a fairly new thing) is based on upstream git sources of netcf rather than a release (since the ubuntu port hasn't been in a release yet). If this bug is reproducible, you should file a bug against netcf in the ubuntu bug system to give them a heads-up that they'll need to do a new build. I'm closing the bug here, since it's apparently fixed upstream.
Yes, you're right. I will post bug to the ubuntu team. Thanks.