Error starting domain: virDomainCreate() failed Failed to add tap interface 'vnet%d' to bridge 'br0' : Permission denied

[Seria]

Binary package hint: virt-manager

Description: Ubuntu 8.04.1
Release: 8.04

virt-manager:
Installiert: 0.5.3-0ubuntu10

************************
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 480, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 379, in startup
    self.vm.create()
  File "/usr/lib/python2.5/site-packages/libvirt.py", line 240, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: virDomainCreate() failed Failed to add tap interface 'vnet%d' to bridge 'br0' : Permission denied

************************
/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
 address 192.168.2.101
 netmask 255.255.255.0
 gateway 192.168.2.1

auto br0
iface br0 inet static
        address 192.168.2.10
        network 192.168.2.0
        netmask 255.255.255.0
        broadcast 192.168.2.255
        gateway 192.168.2.1
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

********************

groups
... kvm libvirtd ...

[TJ (tj)]

What is the output of:

grep tun /etc/group

groups | grep tun

ls -l /dev/net/tun

[Seria (andreas-boettger)]

andreas@sturm:~$ grep tun /etc/group
andreas@sturm:~$

andreas@sturm:~$ groups | grep tun
andreas@sturm:~$

andreas@sturm:~$ ls -l /dev/net/tun
crw------- 1 root root 10, 200 2008-04-29 23:05 /dev/net/tun
andreas@sturm:~$

[TJ (tj)]

It looks as if you don't have non-root permissions to use the tun device. Do the following:

$ sudo addgroup tun
$ sudo adduser $(id -un) tun

log-out and log-in again to effect the new group membership, then check "tun" is listed in the user's groups:

$ groups

Now follow the instruction in my 'Virtual Machines with VDE Networking' tutorial, in the section "Give New Devices tun Group Ownership"

http://tjworld.net/wiki/Linux/Ubuntu/VirtualMachinesWithVDENetworking#GiveNewDevicestunGroupOwnership

You can manually set the permissions to avoid requiring a system restart:

$ sudo chown :tun /dev/net/tun
$ ls -l /dev/net/tun
crw-rw---- 1 root tun 10, 200 2008-07-02 10:49 /dev/net/tun

Now try the virt-manager procedure again.

You *might* need to reboot to ensure the permissions are set correctly by the udev rule in the future.

[Seria (andreas-boettger)]

andreas@sturm:~$ grep tun /etc/group
tun:x:1002:andreas

andreas@sturm:~$ groups | grep tun
tun

andreas@sturm:~$ ls -l /dev/net/tun
crw------- 1 root root 10, 200 2008-04-29 23:05 /dev/net/tun
andreas@sturm:~$ sudo chown :tun /dev/net/tun
[sudo] password for andreas:
andreas@sturm:~$ ls -l /dev/net/tun
crw------- 1 root tun 10, 200 2008-04-29 23:05 /dev/net/tun

and with read and write access for group tun:
crw-rw---- 1 root tun 10, 200 2008-04-29 23:05 /dev/net/tun

The same problem:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 480, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 379, in startup
    self.vm.create()
  File "/usr/lib/python2.5/site-packages/libvirt.py", line 240, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: virDomainCreate() failed Failed to add tap interface 'vnet%d' to bridge 'br0' : Operation not permitted

[saron (saron)]

This may be a problem related to virt-manager (the GUI for libvirt).

I've just experienced the same problem with virt-manager, and managed to circumnavigate the issue by booting the VM using the command line tools.

Here's what I did:
Connect: virsh --connect qemu:///system
Start the VM: start myvirtmachine
Connect to the machine using VNC (if configured)

I also reloaded the XML file for my virtual machine (define myvirtmachine.xml), but that was to fix another problem, but I'm noting this.

[Spang (hetkot)]

That's because virsh uses the root libvirtd and virt manager uses the userspace one.
The same result is achieved by running virt-manager with sudo.

Still, thanks a lot for the information because I was experiencing the same problem, but then on a personal Ubuntu server I access remotely. X-forwarding and sudo aren't the best of friends and so virsh is a very welcome alternative to virt-manager.

I do believe that this means that the userspace virt-manager is isn't able to bridge.
So I guessing that bug
https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/192605 is still or again an issue.

[Spang (hetkot)]

If you use this
  virt-manager -c qemu:///system
You can even skip the sudo's.

Make sure you are part of the libvirtd group.

[Mario Manno (manno)]

The userspace libvirt (qemu:///session) cannot add interfaces to a bridge device.

This won't get fixed unless virt-manager provides a helper script to run something like "sudo brcrtl addif br0 tap0".
Or just put "You need root privileges to use bridged interfaces with virt-manager" into the documentation and be done with it.

[sakhi (selouw)]

I have the same problem with the following command.

virt-manager -c qemu:///system

Unable to open connection to hypervisor URI 'qemu:///system':
<class 'libvirt.libvirtError'> virConnectOpenReadOnly() failed could not connect to qemu:///system
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 332, in _open_thread
    self.vmm = libvirt.openReadOnly(self.uri)
  File "/usr/lib/python2.5/site-packages/libvirt.py", line 144, in openReadOnly
    if ret is None:raise libvirtError('virConnectOpenReadOnly() failed')
libvirtError: virConnectOpenReadOnly() failed could not connect to qemu:///system

[Marc Deslauriers (mdeslaur)]

Thanks for reporting this issue.

As said in this bug report, you need to use "localhost (QEMU)" in virt-manager and not "localhost (QEMU Usermode)" in order to connect to qemu:///system.

Can you still reproduce this issue with a recent virt-manager, such as the one in Karmic or Lucid?

[Marc Deslauriers (mdeslaur)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to 'New'. Thanks again!