Bug 803789 - libvirt doesn't work with netcf anymore
Summary: libvirt doesn't work with netcf anymore
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Laine Stump
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-15 16:24 UTC by Hendrik Schwartke
Modified: 2012-03-20 09:04 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Ubuntu precise
Last Closed: 2012-03-19 18:37:21 UTC
Embargoed:


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

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.


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