kvm-ifup fails to initialize tap networking

Your script is not correct. eth1 is a physical device, not a bridge.

Hello,

I am on Gutsy. The original complaint is likely wrong, in that executing ifconfig tap0 0.0.0.0 up of course won't work, because tap0 will be deleted again after the failure.

But /etc/kvm/kvm-ifup script is also most likely wrong, because it doesn't give a bridge to brctl, but instead the "$switch", which is supposed to be the device with the default router I take. That's my wireless in my case, and far from a bridge.

I tried creating a bridge inside the script and addif the both $switch and $1 (tap0). It seems to work insofar as I can see in tcpdump my packets, for which the WLAN likely will have no friendly words.

Can you clarify, if and where the bridge should be created? tap0 is no bridge. And can you provide a means to say where to bridge to? I would be perfectly happy to bridge to lo device. My only goal is to ssh into the virtual machine from the local machine, but so far I have no succeeded.

I sincerly doubt that the code can possibly work as it is. It's in violation of the man page of brctl and I am the second to experience its failure.

Just to add, given more hints on where to look, I am willing to provide a patch myself.

I had a similar problem (Gutsy/AMD64, 2.6.22-14-generic, kvm 1:16-1ubuntu2), in that tap0 wasn't visible (ifconfig -a) on my host, and kvm reported "can't add tap0 to bridge eth1: Operation not supported" when starting.

However, after my host finished booting and everything network related had finished initializing, tap0 had appeared, and I can configure them both to communicate without issue.

Running Gutsy (7.10) 32bit.

I start the guest with:

kvm -hda guest.img -m 1024 -net nic -net tap

Starting the guest gives the same error:

can't add tap0 to bridge eth1: Operation not supported

But the tap0 device exists:

7: tap0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 500
    link/ether 00:ff:87:13:e9:96 brd ff:ff:ff:ff:ff:ff
    inet 10.20.30.40/8 brd 10.255.255.255 scope global tap0
    inet6 fe80::2ff:87ff:fe13:e996/64 scope link
       valid_lft forever preferred_lft forever

After the guest has started, on the guest, I execute:

ifconfig eth0 10.20.30.50 netmask 255.255.255.0
route add default gw 10.20.30.40
echo "MY-NAMESERVER-IP" > /etc/resolv.conf

and on the host:

ifconfig tap0 10.20.30.40
modprobe ip_tables
modprobe iptable_nat
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

and it works both ways: from the guest I can reach internet and from the host I can ssh into the guest.

Good luck!
Ace

The script assumes that a bridge already exists and is the default route.

Adding this to the /etc/network/interfaces should get past this problem:

auto br0
iface br0 inet dhcp
bridge_ports eth0 eth1
bridge_stp off
bridge_maxwait 5

Replace 'eth0 eth1' with the physical interfaces you want in the bridge.

If the person who writes these scripts every reads this then for crying out loud put a comment in the damn things describing what you are trying to achieve please!!

The script assumes that a bridge already exists and is the default route.

Adding this to the /etc/network/interfaces should get past this problem:

auto br0
iface br0 inet dhcp
bridge_ports eth0 eth1
bridge_stp off
bridge_maxwait 5

Replace 'eth0 eth1' with the physical interfaces you want in the bridge. In my cas

If the person who writes these scripts every reads this then for crying out loud put a comment in the damn things describing what you are trying to achieve please!!

This still seems to be pretty broken in Intrepid. I don't think this script could ever have possibly worked.

Hello Matt,

just for the record, I retract my year old offer "willing to provide a patch", because in the mean time I switched back to Debian.

Should anybody make a statement that Ubuntu is not responsive to bugs, I may consider to mention this bug. The help offers in this bug were ignored all the time, and that while KVM was pronounced as the official virtualization method for Ubuntu. Sad.

Best regards,
Kay Hayen

Our kvm packages are based on Debian's, so you'll find the same script there, I'm afraid.

Indeed, KVM is Ubuntu's recommended hypervisor, and the recommended way to use it is through libvirt. libvirt handles all the networking setup you should need for kvm.

It's quite hard to provide a qemu style ifup script that will suit even a small subset of our users. That said, we should of course strive for something that works for as many people as possible and as seamlessly as possible.

I agree that assuming people's default gateway is a bridge is currently not a very good assumption. On the other hand, I'm not terribly interested in spending a whole lot of time on writing an extensive script that will inspect your network configuration, set up a bridge if one does not yet exists, and hook up the kvm instance to that bridge, since we already have a very good solution in libvirt. All our virtualisation documentation says to use libvirt. If you've been misled by any documentation, I'd love to see it, so that it can be corrected.

Thank you.

Hello Soren!

My concern was neither the non-existance or _your_ interest to write a better solution, nor the fact that you inherit the bug from upstream. Not even that it exists, bugs are perfectly fine.

My disappointment that I was interested in writing a better solution, offered so, but lacked response in any form. That's a loss, even if not to you.

Also, more than one year ago, the documentation certainly wasn't clear that libvirt was the only supported way to run kvm.

Best regards,
Kay Hayen

Okay, the fix for this bug will be to update the kvm-ifup script.

It's determination of the bridge device is quite simply broken.

For now, let's hardcode and require the bridge device to be "br0" for this script to operate properly. That should be the case in most reasonable setups. We can consider something more dynamic if necessary.

:-Dustin

This bug was fixed in the package kvm - 1:84+dfsg-0ubuntu3

---------------
kvm (1:84+dfsg-0ubuntu3) jaunty; urgency=low

  [ Reviewed Ubuntu patches with KVM/QEMU upstream, Anthony Liguori ]
  * debian/patches/03_bios_no_ssp.patch: DROPPED, included upstream
  * debian/patches/06_no_system_linux_kvm_h.patch: DROPPED, no longer
    necessary, kvm kernel header file is now generally available
  * debian/patches/from-debian-qemu/22_net_tuntap_stall.patch: DROPPED,
    no longer necessary; this patch was to work around a bug in
    2.6.11-rc1; this patch could be causing network packet drop issues;
    definitely WRONG at this point with modern QEMU
  * debian/patches/from-debian-qemu/62_linux_boot_nasm.patch: DROPPED,
    dead code in modern QEMU; completely rewritten to not require an
    external assembler; now built dynamically in pc.c
  * debian/patches/SECURITY_CVE-2007-1321+1322+1366+2893.patch: DROPPED
    * CVE-2007-1321: Fixed upstream
      - QEMU svn commit: r3019
    * CVE-2007-1322: Fixed upstream
      - QEMU svn commit: r5921
    * CVE-2007-1366: Fixed upstream
      - QEMU svn commit: r3012
    * CVE-2007-2893: Not related to QEMU
    * dma.c: Non-CVE fix, r3917
    * block.c: Incorrect patch (negative offset IS allowed, switches
      between block and byte offset)
    * Remainder of the patch was split into: net-socket.patch
      (should be sent upstream)
  * debian/patches/series: updated accordingly
  * debian/patches/do-not-install-bios.patch: DROPPED
    added --disable-blobs to configure in debian/rules
  * debian/patches/reenable_audio_drivers.patch: DROPPED
    added --audio-drv-list="oss alsa sdl" to debian/rules
  * debian/patches/anon_inodes_fix.patch: DROPPED, this is already
    upstream
  * debian/patches/ppc-build.patch: DROPPED, not necessary
  * debian/rules: remove references to non-existant linux_boot.bin

  [ Remaining Patches ]
  * debian/patches/01_use_bios_files_in_usr_share_kvm.patch -p0
    debian/patches/04_use_etc_kvm_kvm-ifup.patch -p0
    debian/patches/07_change_qemu_docdir.patch
    |-----> merged to a single patch, rename_qemu_kvm.patch
  * debian/patches/CVE-2008-0928.patch: upstream work in progress
  * debian/patches/evdev_keycode_map.patch: upstream work in progress
  * debian/patches/02_fix_kernel_Makefile.patch: merged into dkmsify.patch
  * debian/patches/dkmsify.patch: Ubuntu-specific (should validate if
    still necessary...)
  * debian/patches/net-socket.patch: to be sent upstream

  [ Other Changes ]
  * scripts/qemu-ifup: bridge device determination was broken, required
    br0 to be present for this script to operate properly, LP: #125302

 -- Dustin Kirkland <email address hidden> Fri, 20 Feb 2009 16:11:06 -0600