On 03/22/2016 02:29 PM, Predrag Ivanovic wrote:
Hi.
I'd like to use Openvswitch while running libvirt as an unprivileged user
(qemu:///session).
As expected, system session works just fine with OVS.
When I try to start the domain from user session, with the relevant network part of the
domain xml edited to use openvswitch, like this
---
<interface type='bridge'>
<mac address='52:54:00:4a:ef:bb'/>
<source bridge='ovs-br'/>
<virtualport type='openvswitch'>
<parameters interfaceid='33ec3d9d-a92a-468e-aa48-6c31f7882d6f'/>
</virtualport>
<target dev='veth0-ovs'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x07' function='0x0'/>
</interface>
---
I get this error:
---
start freebsd-10.3
error: Failed to start domain freebsd-10.3
error: internal error: /usr/lib/qemu/qemu-bridge-helper --use-vnet --br=ovs-br --fd=19:
failed to communicate with bridge helper: Transport endpoint is not connected
stderr=failed to add interface `tap0' to bridge `ovs-br': Operation not
supported
---
Now, if I understand correctly, this is Qemu, not libvirt error?
Libvirt prepares the network, passes it to qemu-bridge-helper, which has no idea what to
do with it, since it's not the regular bridge, and barfs?
The reason I ask is because I saw calls to ovs-vsctl in the logs when I did the same
thing using qemu:///system.
My question (finally):
if I reconfigure OVS to not run as root:root, but as ovs:ovs, and add the user to that
group,
will libvirt/virsh automagically figure out that the user has permissions to run
ovs-whatever and
write permission to /var/run/openvswitch/db.sock, so there is no need for
qemu-bridge-helper, and
just set up the network, just like when system sesion is used, or is using
qemu-bridge-helper the only option available for non-root users ?
If it is, due to some Linux constraints, I'll curse a bit and migrate the domains
:)
And, before I forget, I am using libvirt and qemu built from git master, and
openvswitch-2.5.0
What you're trying to do isn't supported and won't work. the
qemu:///session libvirtd runs as a normal user, and doesn't have the
necessary permissions to create tap devices or connect them to either
Linux host bridges or OVS bridges. qemu added the "qemu-bridge-helper"
which is a suid binary that will create a tap device and connect it to
the named Linux host bridge, and the person who wrote that helper also
made a patch to libvirt to automatically call the qemu-bridge-helper
when a request is made in a qemu:///session guest to connect to a
bridge. Unfortunately, qemu-bridge-helper only knows how to connect to
standard Linux host bridges, it knows nothing about OVS.
I believe there is an OVS compatibility module that makes the ioctl used
to connect a tap device to a host bridge also work for OVS bridges. You
may want to look into that. However, note that in that case you won't
want the <virtualport type='openvswitch'> section in your guest config
(as a matter of fact it is ignored in qemu:///session). This will mean
that you won't be able to force a particular interfaceid, which may or
may not be important to you.