Bug 803789

Summary: libvirt doesn't work with netcf anymore
Product: [Community] Virtualization Tools Reporter: Hendrik Schwartke <hendrik>
Component: libvirtAssignee: Laine Stump <laine>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: berrange, crobinso, ralf, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Ubuntu precise
Last Closed: 2012-03-19 18:37:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Workaround none

Description Hendrik Schwartke 2012-03-15 16:24:28 UTC
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)

Comment 1 Hendrik Schwartke 2012-03-19 15:21:10 UTC
Using the current version of netcf (commit d340f2dfcd6461c9743dccdabe3b610f5fbc8fe8) the problem doesn't exist!

Comment 2 Laine Stump 2012-03-19 17:59:20 UTC
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)

Comment 3 Laine Stump 2012-03-19 18:37:21 UTC
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.

Comment 4 Hendrik Schwartke 2012-03-20 09:04:51 UTC
Yes, you're right. I will post bug to the ubuntu team. Thanks.