qemu -net nic -net tap does not start due to qemu-ifXXX scripts

[dl9sau]

Binary package hint: qemu

qemu in ubuntu karmic brings new /etc/qemu-{ifup,ifdown} scripts which do not work well.

Btw, these scripts are symlinks to /usr/bin. Imho it's not a good idea to have environment dependend scripts in a bin or sbin path.

My qemu -net nic -net tap terminates in an early startup stage:
can't add tap0 to bridge eth1: Operation not supported
/etc/qemu-ifup: could not launch network script
qemu: Could not initialize device 'tap'

qemu-ifstart does:
cat /usr/bin/qemu-ifup
#!/bin/sh

switch=$(/sbin/ip route list | awk '/^default / { print $5 }')
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif ${switch} $1

There's really no need to reconfigure my network interfaces. Not only that users often like to have their virtual machine(s) to be routet or NAT'ed behind their real machine. Your startup will not work, like at my notebook, properly if that network interface is a wireless device. Wireless devices are normaly in WLAN client mode, and this does not work -by design- as a bridge.

Ugly fix:
edit /usr/bin/qemu-if* and insert "exit 0" after the first empty line.
Because new qemu versions do bring their new /usr/bin/qemu-if*, you need to put qemu on hold, or chattr +i /usr/bin/qemu-if*.
The correct way would be to ask the user during installation if he likes every qemu process to join a bridge with the NICs the default route, and only then install that qemu-if*. I'd like to see this to be really in /etc and not in /usr/sbin, and not to be touched again by a regular package update.

[Tobias Bradtke (webwurst)]

Similar problem for me.
I set up the following tap device

$ cat /etc/network/interfaces
<<<<
# Loopback device:
auto lo
iface lo inet loopback

# device: eth0
auto eth0
iface eth0 inet static
  address x.x.x.x
  broadcast x.x.x.x
  netmask x.x.x.x
  gateway x.x.x.x

# default route to access subnet
up route add -net x.x.x.x netmask x.x.x.x gw x.x.x.x eth0

auto tap0
iface tap0 inet manual
  tunctl_user root
  uml_proxy_arp x.x.x.x
  uml_proxy_ether eth0
  up ip link set tap0 up
  post-up sysctl -w net.ipv4.ip_forward=1
  post-up sysctl -w net.ipv4.conf.tap0.proxy_arp=1
  pre-down sysctl -w net.ipv4.ip_forward=0
  down ip link set tap0 down
>>>>

When i start the virtual domain, the following happens:

$ sudo virsh start windows-sbs
<<<<
Connecting to uri: qemu:///system
error: Failed to start domain windows-sbs
error: internal error unable to start guest: /etc/qemu-ifup: could not launch network script
qemu: Could not initialize device 'tap'
>>>>

Even when use the "ugly fix" this error persists. I can call /etc/qemu-ifup as a normal user so there should be no problem with acces rights. I also get the same error when i delete /etc/qemu-ifup or comment out its content.

What can i do to avoid this error?

[Olivier Mengué (dolmen)]

@dl9sau: if NAT is enough for you, don't use "-net tap": "-net user" is much simpler to setup.

[dl9sau (thomas-x-berg)]

On 2011-05-03 16:12:53 -0000, Olivier Mengué <email address hidden>
wrote in <email address hidden>:
> @dl9sau: if NAT is enough for you, don't use "-net tap": "-net user" is
> much simpler to setup.

This is no option.

It's generally not a good idea to force a user's network interface to
become reconfigured. There are various reasons, like:
  - security: his firewall filter rules may not apply anymore, the system is open to the world
  - what makes you think that the guess ("use the iface with the default route as bridge") is always right? There may be more other scenarios where the services the qemu instances provide should be offered to the local network, not to the internet..
  - problems if your computer is a WLAN STA (client) -- managed mode and bridging are mutaly exclusive
  - your script only works in the special case that the interface with the default route is already part of a bride. only then you could apply a brctl addif .. This is no normal setup.

The up/down script is mess and should be removed.

Kind regards,
 - Thomas Osterried

[Launchpad Janitor (janitor)]

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

[Sean Channel (sean-channel)]

the script is needed to bring up a tap interface. the user would have to write their own if it does not exist already. perhaps in the interest of a more user-friendly experience the default script should first start a bridge if one does not exist.

Requiring a permanant bridge already setup can conflict with NetworkManager and seems too complex for the occasional desktop user.

[Serge Hallyn (serge-hallyn)]

Presumably the occasional desktop user would use virt manager which will by default attach a veth nic to virbr0?

The reason this bug was raised is that /etc/qemu-ifup assumes the default route has been bridged.

For the moment, we always create a virbr0, so perhaps qemu-ifup should attach tap0 to virbr0? In fact it is quite easy to check whether the nic on the default route is a bridge. And/or perhaps the switch should be configurable in /etc/default/qemu-kvm?

So /etc/default/qemu-kvm could contain:

# Uncomment this if you want to specify a bridge to use for tap devices
# TAPBR=virbr0

Then /etc/qemu-ifup could read:

#!/bin/sh

[ -f /etc/default/qemu-kvm ] && . /etc/default/qemu-kvm
if [ -z "$TAPBR" ]; then
 switch=$(ip route list | awk '/^default / { print $5 }')
 if [ -z "${TAPBR}" -o ! -d "/sys/class/net/${TAPBR}/bridge" ]; then
  switch=virbr0
 fi
fi
ifconfig $1 0.0.0.0 up
brctl addif ${switch} $1

[Serge Hallyn (serge-hallyn)]

@Patsev,

you assigned this bug to yourself. Do you intend to push a fix?

If not, I think I'll push the change I detailed in comment #6.

[Sean Channel (sean-channel)]

I agree with the fix proposed in comment #6, though I question the dependency on the "ip" utility (from package "iproute") and using bash-specific syntax, vs. the more standard "route" command (from "net-tools") e.g.:

 switch=`route | awk '/^default / { print $8 }'`

Also I would caution against assuming which front-end GUI is being used, if any (I use none).

[Serge Hallyn (serge-hallyn)]

Quoting Sean Channel (<email address hidden>):
> I agree with the fix proposed in comment #6, though I question the
> dependency on the "ip" utility (from package "iproute") and using bash-
> specific syntax, vs. the more standard "route" command (from "net-
> tools") e.g.:
>
> switch=`route | awk '/^default / { print $8 }'`

I could be wrong, but I thought "they" actually wanted us to switch
from route/ifconfig etc toward using ip for everything. (not really
my cup of tea, I prefer your version)

[Sean Channel (sean-channel)]

I really don't know who "they" are, but chances are good that you know something I do not, Serge, e.g.: plans, specs, requirements, etc..

Just my $.02 that iproute seems very useful for "digging deeper", but looks more like an optional package than anything standard. It is however a dep. of other pkgs as well. Perhaps I should be using BSD. :) Perhaps "they" want to get away from net-tools, for some reason. I wouldn't throw myself on the tracks over it.

Re: bash syntax: the script header begins with "#!/bin/sh", so I would expect it to either have bourne shell / posix compatible syntax, or start with "#!/bin/bash" instead. Not that it would likely ever be a problem.

[Launchpad Janitor (janitor)]

This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu5

---------------
qemu-kvm (1.0+noroms-0ubuntu5) precise; urgency=low

  * define_AT_EMPTY_PATH.patch: Make sure AT_EMPTY_PATH is defined.
   (LP: #930181)
  * Be smarter about what bridge to attach a TAP device to (LP: #475327):
    - qemu-ifup-choosebridge.patch: Don't use the default nic as a
      bridge, if it isn't a bridge.
    - debian/qemu-ifdown: use same logic as qemu-ifup to determine
      the bridge
    - debian/qemu-kvm.default: add commented TAPBR option
 -- Serge Hallyn <email address hidden> Wed, 15 Feb 2012 15:47:57 -0600