libvirt-bin hypervisor does not support virConnectNumOfInterfaces / unable to create domain with virt-manager using network bridge

I think this bug also causes the virt-manager configuration of a virtual network with forwarding to fail:

Host config -> Virtual networks -> Create a new virtual network -> Connecting to physical network -> Forwarding to physical network -> Destination:"Any physical device"

Destination is a drop down that should list physical devices, but there are no physical devices listed there. Presumably it uses the same "iface-list" function to discover the actual devices.

also note that virt-manager under karmic will just fail on these operations. virt-manager under lucid warns that "Libvirt version does not support physical interface listing" if you browse to: Add new virtual hardware -> Network -> Host device

Another note: I am using a remote connection over ssh from virt-manager to the kvm system. virt-manager behaves differently when run locally - it finds the interfaces (presumably it detects them directly rather than querying the hypervisor?).

I've also run into this issue and it's a real problem for our company. Not being able to use bridging is a real bummer.

We'd like to deploy a libvirt/KVM solution using Ubuntu, but it's just not possible with such core functionality missing.

Just for kicks, I tried to rebuild the libvirt package to include netcf, but there doesn't seem to be a netcf package for karmic...

Any chance to increase the importance of this issue?

+1 for higher importance

this is a pain at least while experimenting with kvm/libvirt on a lan-server and a roadblock for a newb.

It is indeed a pain. I'd like to see this get fixed eventually. Even the upstream patch that's around somewhere that allows you to simply manually specifiy a bridge would be pretty good.

It's not *impossible* to use libvirt/KVM in these conditions, incidentally, it's just that after defining a new domain you need to manually alter the domain's configuration:

virsh qemu+ssh://<email address hidden>/system edit <domainname> (edit as appropriate), and then to change the default NAT network to bridge simply replace <interface type='network'> with type='bridge' and <source network='default'/> with <source bridge='br0'/>

Not ideal, but not that hard either.

I too would like to see this fixed for Lucid. It's rather tedious to create a domain then have to hand edit the configuration.

+1 for higher importance as well

I think it will not be very easy to integrate virConnectNumOfInterface function. In fact, this function need libnetcf (a library to manage network config via XML), and libnetcf compile fine under ubuntu but libnetcf is created under the fedora network scheme configuration and it is not compatible with ubuntu scheme. Let's see... Anyway +1 for higher importance, I (my office also) really need that to use kvm virtualisation.

+4 importance here.

Four customers also affected by this; and paying me to hand-edit configs.

+1 for higher importance as well

+1 for higher importance.

+1 as kvm isn't much use without bridged networking.

+1 for higher importance too.

+1 for higher importance, i seriously can't believe its it's low priority

+1 for higher importance. We need a friendly UI :)

+1 for higher importance

+1 for higher importance

actually i am using a bridged network device for a virtual guest which serves as a gateway to a virtual network, allthough i run into the same problem as described above. my setup looks now as following:

kvm host
- eth0
- br0
- eth1
the br0 is bridged to eth1

kvm guest
- eth0 (br0 on kvm host)
- eth1 (virtual)

the guest runs as a gateway w/ nat so other virtual servers may be either accessed directly from the local network or from virtual servers. if anybody is interested in a detailed setup (the way i solved it actually) just drop me a mail

basically the trick was to setup the bridge on the host (either local or from remote console) and after a restart to change the client setup by adding a new netwok device to HostDevice eth1 (Bridge br0) and removing the old one. !!! this was done directly at an x session on the kvm-server - using the virt-machine-manager from my desktop connected to the server didnt show the eth1 device !!!

hope this helps anybody who runs into same issue

greets
Chronos

This was a bit of a surprise that core functionality is missing. I spent a good part of the day trying to figure out why the exact same bridging setup under CentOS worked, and it didn't on Ubuntu.

Oh, yeah, and +1 for importance. Seriously, bridging is kinda important in virtualization unless the user wants to NAT every single connection. That just doesn't seem practical.

i went through the hassle of compiling:

virt-manager 0.8.4
virtinst 0.500.3
virt-viewer 0.2.0
libvirt 0.8.1

myself on ubuntu lucid.

I can confirm that the bug is kinda fixed in upsteam (you can at least specify your bridge manually (by name)) and create new vm's that way

please fix this in the repos in some way or another

Isn't this bug also affected by the lack of the macvtap driver in the
standard Ubuntu kernel?

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems
--------------------------------------
Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.696.3428
Email: <email address hidden>

If what they've been doing hasn't solved the problem, tell them to
do something else.
  -- Gerald Weinberg, "The Secrets of Consulting"

On 06/16/2010 03:45 AM, fred wrote:
> i went through the hassle of compiling:
>
> virt-manager 0.8.4
> virtinst 0.500.3
> virt-viewer 0.2.0
> libvirt 0.8.1
>
> myself on ubuntu lucid.
>
> I can confirm that the bug is kinda fixed in upsteam (you can at least
> specify your bridge manually (by name)) and create new vm's that way
>
> please fix this in the repos in some way or another
>
>

This bug was fixed in the package libvirt - 0.8.1-2ubuntu1

---------------
libvirt (0.8.1-2ubuntu1) maverick; urgency=low

  * Merge from debian unstable. Remaining changes:
    - Fixes:
      LP: #522845
      LP: #553737
      LP: #520386
    - debian/control:
      + Build-Depends on qemu-kvm, not qemu
      + Build-Depends on open-iscsi-utils, not open-iscsi
      + Build-Depends on libxml2-utils
      + Build-Depends on libapparmor-dev and Suggests apparmor
      + Bump bridge-utils, dnsmasq-base, netcat-openbsd, and iptables
        to Depends of libvirt-bin
      + Drop qemu-kvm and qemu to Suggests
      + We call libxen-dev libxen3-dev, so change all references
      + Rename Vcs-* to XS-Debian-Vcs-*
    - debian/libvirt-bin.postinst:
      + rename the libvirt group to libvirtd
      + add each admin user to the libvirtd group
      + reload apparmor profiles
    - debian/libvirt-bin.postrm:
      + rename the libvirt group to libvirtd
      + remove apparmor symlinks on purge
    - debian/README.Debian: add AppArmor section based on the upstream
      documentation
    - debian/rules:
      + update DEB_DH_INSTALLINIT_ARGS for upstart
      + add DEB_MAKE_CHECK_TARGET := check
      + use --with-apparmor
      + copy apparmor and apport hook to debian/tmp
    - add debian/libvirt-bin.upstart
    - debian/libvirt-bin.dirs: add /etc/apparmor.d/abstractions,
      /etc/apparmor.d/disable, /etc/apparmor.d/force-complain,
      /etc/apparmor.d/libvirt, /etc/cron.daily and
      /usr/share/apport/package-hooks
    - add debian/libvirt-bin.cron.daily
    - add debian/libvirt-bin.apport
    - debian/libvirt-bin.install: install apparmor profiles, abstractions
      and apport hook
    - debian/apparmor:
      - add TEMPLATE
      - add libvirt-qemu abstraction
      - add usr.lib.libvirt.virt-aa-helper
      - add usr.sbin.libvirtd
    - debian/patches/series:
      + don't apply 0002-qemu-disable-network.diff.patch
      + don't apply 0005-Terminate-nc-on-EOF.patch. Use
        9010-autodetect-nc-params.patch instead
      + 9000-delayed_iff_up_bridge.patch (refreshed)
      + 9001-dont_clobber_existing_bridges.patch
      + 9002-better_default_uri_virsh.patch (updated)
      + 9004-better-default-arch.patch
      + 9005-libvirtd-group-name.patch
      + 9006-increase-unix-socket-timeout.patch (refreshed)
      + 9007-default-config-test-case.patch (updated)
      + 9008-fix-daemon-conf-ftbfs.patch (rewritten)
      + 9009-run-as-root-by-default.patch (refreshed)
      + 9010-autodetect-nc-params.patch (refreshed, formerly 9015)
      + 9011-dont-disable-ipv6.patch (updated)
  * Dropped following packaging changes, no longer required with upgrades
    from Lucid:
    - debian/control:
      + versioned Conflicts/Replaces to libvirt0 for libvirt0-dbg
      + remove Build-Depends on libcap-ng-dev
    - debian/libvirt-bin.postinst: virt-aa-helper profile migration to
      /usr/lib/libvirt
    - debian/libvirt-bin.preinst: added to force complain on certain
      upgrades
  * Dropped the following patches, included upstream:
    - 0010-Use-base-16-for-product-vendor.patch
    - 9003-increase-logoutput-timeout.patch
    - 9010-apparmor-ftbfs...

Is this really fixed? Testing with last libvirt as downloade from https://launchpad.net/ubuntu/+source/libvirt:

$ virsh version
Compiled against library: libvir 0.8.1
Using library: libvir 0.8.1
Using API: QEMU 0.8.1
Running hypervisor: QEMU 0.12.3

$ virsh iface-list
error: Failed to list active interfaces
error: this function is not supported by the hypervisor: virConnectNumOfInterfaces

+1 for importance

quote : This means that a user will be unable to create a new domain using virt-manager if they are using a network bridge.

And this mean that you can't install easily using pxe!!!

Is anyone looking into this?

I tried the most recet version from Maverick, the problem is still there:

~$ virsh iface-list
error: Failed to list active interfaces
error: this function is not supported by the hypervisor: virConnectNumOfInterfaces

~$ virsh version
Compiled against library: libvir 0.8.1
Using library: libvir 0.8.1
Using API: QEMU 0.8.1
Running hypervisor: QEMU 0.12.3

+1 for importance.

comment #28 indicates that the problem is still in maverick, reopening.

please also consider raising the importance of this bug, as it is a serious issue for many common setups.

Will a newer version end up in backports, or is the quick fix getting it from maverick?

popping this bug down to low is a huge mistake, this bug regression is making a lot of customers jump off of ubuntu as a visualization platform.

remote management becomes basically unusable due to this issue.

Please reconsider fixing this, it has been an issue and off for over two years now.

I Agree, KVM without remote management is silly. Fedora seems to have it solved, currently I use KVM/virsh on a Fedora 13 host (libvirt-client-0.8.2-1.fc13.x86_64 libvirt-0.8.2-1.fc13.x86_64) with Ubuntu's 0.8.2 Virt-Manager.

But yes, do give a (much) higher priority!

gdahlman has it right. This issue and the lack of snapshots were the two main reasons that the company I work for left Ubuntu KVM and settled on VMware ESXi.

Hmm, I think importance must be critical, because without this functionality user's can't use KVM at all. Bug is still here in Lucid i386 with latest updates.

Vadmin: You can still use KVM through the command line, or through virt-manager if you ssh in to your VM host, run virt-manager, and connect to localhost. This requires virt-manager and a bunch of X11 type libraries to be installed on your VM host.

So... Does anyone have a workaround for this issue that doesn't require X11 libraries on the host, doesn't require root password on the host?

This is a real pain... every virtualization solution I have tried on Ubuntu requires something to be installed I don't want to, X11, root password etc... Is there not an elegant solution to KVM virtualization that doesn't have a significant limitation? I'm seriously considering trying ESXi although it would be far from ideal.

Please increase importance. It is really annoying.

This is a real showstopper for Ubuntu - increase the importance level to high as it even breaks Ubuntu's own guides on KVM
https://help.ubuntu.com/community/KVM/Networking

+1 Vote more important than low.

This needs to be addressed asap. The company I work for is an avid Ubuntu supporter but is struggling to go ahead with ubuntu for virtualization without this being fixed.

I have validated that netcf works on my precise VM. But to really fix this thing, the libvirt packages have to be configured to link against libnetcf, don't they?

I would really be excited to see this working in Precise, btw. I would be happy to test from PPA or whatever as well.

This is awaiting on the netcf MIR in bug 904014

Good point - I've pushed version 0.9.7-2ubuntu15.ppa1, with netcf enabled, to ppa:serge-hallyn/virt.

Any chance we could get the same changes applied to the version of 0.9.8-2 that Chuck Short recently pushed?

@Martin

uploaded - version 0.9.8-2ubuntu2.ppa1 should be built in ppa:serge-hallyn/virt in a few hours.

It looks like the package failed to build properly. This looks like the relevant error message:

configure: error: You must install libnetcf >= 0.1.4 to compile libvirt
make: *** [debian/stamp-autotools] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2
******************************************************************************
Build finished at 20120119-1601
FAILED [dpkg-buildpackage died]

We are currently in the process of building a webbased gui for the management of virtual machines via libvirt. It would be greate if netcf is included in libvirt, because then the creation of vlans and bridges connected to these vlans could be handled via libvirt.
Please link libvirt to netcf.

It'll be enabled as soon as netcf hits main.

I added ppa and try to install libvirt ppa but virtsh iface-list give me function not supported .

Precise Server

I recompile ppa removing --without-netcf in debian/roule and now it work , thank

@silviop,

sorry, the netcf-enabled package in my ppa had gotten overwritten with another experimental one.

If netcf can't go into main for precise, then perhaps I'll need to create a libvirt-netcf package in ppa:ubuntu-virt/ppa, with a script reliably creating that package every time libvirt is uploaded.

I installed the following packages from Wheezy before installing virt-manager and it is all working no problem

(copied pagkages over and used dpkg -i

ii libvirt-bin 0.9.9-3+b2 programs for the libvirt library
ii libvirt0 0.9.9-3+b2 library for interfacing with different virtualization systems
ii libnetcf1 0.1.9-2 cross-platform network configuration library
ii libyajl2 2.0.4-2 Yet Another JSON Library

guys, I still have this issue on a debian 6 squeeze

how to solve it? can I use some PPA where this fix is pushed? can you point me to the right repositories? I REALLY need the fix to deploy guests on my bridged network

thanks

Quoting Angelo Pantano (<email address hidden>):
> guys, I still have this issue on a debian 6 squeeze

Sorry, what do you mean by this? A debian 6 squeeze host will not be
affected by what we do in the ubuntu libvirt package.

> how to solve it? can I use some PPA where this fix is pushed? can you
> point me to the right repositories? I REALLY need the fix to deploy
> guests on my bridged network

Good idea.

Perhaps I can create a new ppa under ppa:ubuntu-virt with libvirt-bin
compiled for netcf. Do you want this for precise (I hope)?

Angelo, I was able to connect my guests to the physical newtwork whithout netcf.

I've added the follwing to host's /etc/network/interfaces

auto br0
iface br0 inet static
        address 192.168.2.2
        netmask 255.255.255.0
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0

eth0 interface does not have a separate /etc/network/interfaces entry, br0 is the interface the host is using to connect to the physical network. The bridged interface has a static address in my case but I think that DHCP would work also.

After a reboot, I can use the bridged interface in virt-manager. When configuring the Virtual Network Interface for a guest, I can choose 'Host device eth0 (Bridge br0)' as the source device. With this setting, guest can access the physical network, acquire an IP address from the DHCP server and contact physical machines in my network and also other guests.

It would be nice to be able to configure the bridges in the host machine from virsh / virt-manager but it's not strictly required to get it working :)

I endend up doing the same, I configured the bridge manually and (risking to be a bit OT) if you try to setup BONDING at the same time this post helped me out HUGELY:

http://forum.proxmox.com/threads/2676-bonding-bridging-freez

I've been watching this bug for a while cause i was going to upgrade my home server to ubuntu 11.10. So far, even with the bridge configured above, the interface doesnt appear in virt-manager. If i manually specify the bridge while creating a vm, it does attach on boot but cant network boot from it. Looking at the ubuntu-virt ppa it doesnt appear to contain anything for 11.10 either. Is there another ppa i should be using? Im fine with it not appearing in the interface list if it would work from a VM (though im a little lost as to why it is connecting to the bridge, but not booting from the network - seems to ignore the boot options entirely)

The thing im getting at (i've been using ubuntu on my desktop for quite some time, i haven't done so for servers as yet) is there supposed to be another tool people use on ubuntu instead of virt-manager/libvirt? It just seems to me that lacking the ability to do virtualisation is a huge problem for a servers os? or is virt'n not much of a focus for ubuntu?

it just occurred to me it doesnt have the pxe boot roms, didnt realise they were a separate package, so yes, i can boot from the network.

@Paul,

note that netcf isn't packaged for 11.10, we can't do a netcf-enabled libvirt in the ubuntu-virt ppa for oneiric.

Glad that you got the vm net-booting.

I can confirm what Rafal and Angelo said. I successfully assigned a manually preconfigured bridge to a VM on a lucid server with virt-manager on precise desktop by just giving the bridge name ("br0" in my case).

I can also add a +1 for higher than low, as this is a problem for checking out ubuntu as a basis for virtualization. I'm trying to do a comparison between a couple of solutions, and I can't even get this one going.

+1
Precise.

I`ve rebuilt the source Serge Hallyn`s libvirt with netcf for Presice and backport to Lucid.

We can get it on my ppa.
http://ppa.launchpad.net/p-p/ppa/ubuntu

Bump, this is ridiculous. Definitely won't be deploying our virtual environment on Ubuntu.

Finally found this bug after 3 attempts to get virt-manager working. I eventually switched to CentOS but went back to Ubuntu when 12.04 was released to give it another shot. No problems under CentOS but still the same problem with Ubuntu. After a while finally managed to find this page using Google.

Any guess as to when this issue will be resolved?

Same question. Using x forwarding over ssh to manage virtual machines is becoming a problem, especially on a performance point of view.

mike-e and the rest,

You may be interested in following along with our MIR (https://wiki.ubuntu.com/MainInclusionProcess) for this particular bug. Please see: https://bugs.launchpad.net/ubuntu/+source/netcf/+bug/904014.

This was also stated in #63 and has made a lot of progress since then. Please be aware this issue is on our radar and understand the impact it is having on those affected. Constant communication is being held with upstream to have an official 0.2.0 release which include the necessary bits to resolve this bug[1]. From that point it is just process to get it packaged and released.

[1] https://fedorahosted.org/pipermail/netcf-devel/2012-June/000755.html

Thank you
Adam

Status changed to 'Confirmed' because the bug affects multiple users.

This bug was fixed in the package libvirt - 0.9.13-0ubuntu6

---------------
libvirt (0.9.13-0ubuntu6) quantal; urgency=low

  * enable netcf support (LP: #520386)
    - debian/control: build-dep on libnetcf-dev
    - debian/rules: add --with-netcf to configure args
  * add patch netcf-daemon-fix-wrong-macro-name from upstream so netcf support
    can actually work.
 -- Serge Hallyn <email address hidden> Wed, 08 Aug 2012 07:54:16 -0500

May I kindly ask why this bug has been fixed in Quantal, but marked as "won't fix" for Precise - current LTS release that will most likely be used as VM host OS for the next couple of years?

@maciej-puzio - because this would require SRU validation, and due to the nature of the changes, I suspect it would fail due to potential for regressions. Additionally, netcf as a dependency would need to be accepted into precise first, which hasn't happened at this stage (see LP: #904014)

Quoting Maciej Puzio (<email address hidden>):
> May I kindly ask why this bug has been fixed in Quantal, but marked as
> "won't fix" for Precise - current LTS release that will most likely be
> used as VM host OS for the next couple of years?

Because netcf in precise is in universe, not in main. Therefore libvirt,
which is in main, cannot link against it. In quantal, netcf is in main.

Thank you very much for an explanation. I understand that thus is not a trivial fix, but I would nevertheless ask you to reconsider your position. As we can see in this bug report, many users consider this issue important and the workaround problematic. For some users this issue alone is a show stopper that makes them reject Ubuntu as a VM host platform. Taking into account this and the fact that Precise has over 4.5 years of life left, and that the next server-usable (LTS) release won't come until 2014, I would like to ask that you consider fixing this bug in Precise, even if it requires moving netcf into main, performing SRU validation and other not-so-easy tasks.

is there a work around? As an alternative, has anyone gotten this to work on debian stable or testing as a host?

The workaround is to enter the interface name (for example, br0) manually. Due to another bug in virt-manager, this is only possible when running virt-manager locally on the kvm host. If virt-manager connects to the remote kvm host, the edit box is not accessible and the only way to select the interface is through the drop-down list, which is empty (due to the netcf bug). This means that virt-manager must be installed on the kvm host, together with 100+ packages that it pulls for UI support.

Very annoying that this won't be fixed, even by some PPA. I invested a week worth of work to script bootstrapping a Ubuntu 12.04 with a lot of customizations and end up hitting the wall with this problem.

The point about the dependencies is duly noted, but sometimes such issue requires a pragmatic solution rather than a bureaucratic rejection ;)

@Oliver,

One of the awesome things about launchpad is that you can trivially create your own ppa, wherein you could build your own version of netcf and a version of libvirt built against it.

@Serge: thanks ... trivially if you are acquainted with it in the first place. I am not, but if everything else fails I'll take that route and publish the repo details here.

First, note that it may also be possible to get an official
backport of the packages. (https://wiki.ubuntu.com/UbuntuBackports)

> @Serge: thanks ... trivially if you are acquainted with it in the first
> place. I am not, but if everything else fails I'll take that route and
> publish the repo details here.

Sorry, the creation of ppa's is trivial. The packaging aspects are not.
https://wiki.ubuntu.com/UbuntuDevelopment has information, but probably
too much.

Essentially, the steps I would follow would be:

1. pull-lp-source netcf
2. cd netcf-0.2.2; dch -i; create a package version that is the same as
the latest raring one, with '12.04.1' appended, that is 12.04 for precise
release and 1 for your first version (so 1:0.2.2-3.12.04.1), and a message
saying "build in ppa for precise"
3. type debuild -S -sa to generate the package with full source
4. cd ..; dput ppa:~username/ppaname netcf_0.2.2-3_source.changes

Once that builds, do similar for libvirt.

Please feel free to drop by #ubuntu-devel with any questions.

Or you can try:

backportpackage -u ppa:<launchpaduser>/<launchpadrepo> -s quantal -d precise netcf
backportpackage -u ppa:<launchpaduser>/<launchpadrepo> -s quantal -d precise libvirt

However that will only work if there are no specific dependencies on other packages/versions that are only available in Quantal. At that point, you can either go down the dependency chain and backport them all (ugly), or fix the package to work with versions available in Precise (the previous post will start you in vaguely the right direction).