3

I set up a Fedora VM using GNOME Boxes. I can launch it, everything's OK.

I'm using virt-manager and I want to create a bridge so that I can get the VM on the network, but every time I attempt switching the NIC mode from usermode networking to specify shared device name an error is returned.

I do have virbr0 and virbr0-nic up.

The error is:

Error starting domain: internal error: /usr/lib/qemu/qemu-bridge-helper --use-vnet --br=virbr0 --fd=26: failed to communicate with bridge helper: Transport endpoint is not connected
stderr=failed to parse default acl file `/etc/qemu/bridge.conf

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 82, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1508, in startup
    self._backend.create()
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1062, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: /usr/lib/qemu/qemu-bridge-helper --use-vnet --br=virbr0 --fd=26: failed to communicate with bridge helper: Transport endpoint is not connected
stderr=failed to parse default acl file `/etc/qemu/bridge.conf'
Daniel
  • 213

2 Answers2

6

Update: I got it working. (On the same day, but forgot to circle back here and report back).

Note: read the answer above first

The setup is not exactly smooth and rather plagued by errors - especially when compared with virtualbox, which just works out of the box, as it were.

Anyway, to avoid repeating myself, I'm picking up from where I was when I kept getting the error I posted in the question above. In my case, /etc/qemu/bridge.conf didn't even exist, so I had to create both the directory and the file myself.

The error returned boils down to permissions. Make sure the file has the read bit turned on.

sudo touch /etc/qemu/bridge.conf # If the file does not exist yet
sudo chmod u+r /etc/qemu/bridge.conf

Note: the file should contain a line indicating which bridge interfaces are allowed.

allow virbr0 # according to your qemu command

or, alternatively,

allow all

You also want to make sure the /usr/lib/qemu/qemu-brdige-helper has the setuid bit set.

sudo chmod u+s $(locate -r /usr/.*/qemu-bridge-helper$)

So far so good, but it still wouldn't work, returning socket-related errors. And it's because of apparmor, which is blocking communication - source: a comment on this post.

ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/

apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd

This ultimately did the trick.

SebMa
  • 2,927
  • 5
  • 35
  • 47
Daniel
  • 213
3

gnome-boxes uses qemu:///session which has some benefits (own instance per user, per-user data, ...) but also drawbacks compared to the usual Ubuntu default of qemu:///system - in particular it is rather low on permissions since it runs in user context.

Therefore to do any sophisticated network (and some other things) you need helpers and setup changes. For networking you need qemu-bridge-helper which for many reasons is considered insecure and therefore needs to set suid and a configure file that whitelists devices to allow.

This blog is a nice summary of the usual steps needed, but I haven't retested them recently, so they might slightly differ these days and if so I beg your pardon (speak up here so we can mention it).

P.S. if you have connected it to virtbr0 it can reach out to the network, but this is a NAT bridge, so you will then still be unable to connect from the outside to your VM unless you define e.g. port forwarding. If you want it externally reachable you need to define a non-nat bridge and couple that with your guest - here is a great netplan example how to do so.

Christian Ehrhardt
  • 2,195
  • 16
  • 22