Bug 803789 - libvirt doesn't work with netcf anymore
libvirt doesn't work with netcf anymore
Status: CLOSED UPSTREAM
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Laine Stump
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-15 12:24 EDT by Hendrik Schwartke
Modified: 2012-03-20 05:04 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Ubuntu precise
Last Closed: 2012-03-19 14:37:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Workaround (421 bytes, patch)
2012-03-15 12:24 EDT, Hendrik Schwartke
no flags Details | Diff

  None (edit)
Description Hendrik Schwartke 2012-03-15 12:24:28 EDT
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 11:21:10 EDT
Using the current version of netcf (commit d340f2dfcd6461c9743dccdabe3b610f5fbc8fe8) the problem doesn't exist!
Comment 2 Laine Stump 2012-03-19 13:59:20 EDT
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 14:37:21 EDT
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 05:04:51 EDT
Yes, you're right. I will post bug to the ubuntu team. Thanks.

Note You need to log in before you can comment on or make changes to this bug.