On 01/20/2017 05:47 AM, Govert wrote:
Thanks !! This clarifies completely what is happening. I'll look
into
running virsh as root/attaching to qemu:///system. Or, perhaps I can
'statically' create tun devices, to which the domains attach when
started (although I have no idea weather this is possible).
It isn't just the creationof the tap device that requires privileges,
it's also the opening of the tap, and attaching it to the bridge. There
isn't any way to do the latter two from unprivileged libvirtd (except
via qemu-bridge-helper, which insists on creating a new tap device), so
I think you're going to have to switch to qemu:///system.
Best,
Govert
2017-01-17 20:46 GMT+01:00 Laine Stump <laine(a)laine.org
<mailto:laine@laine.org>>:
On 01/14/2017 06:30 AM, Govert wrote:
Hi,
I'm trying to control the name of the 'tap0' device that gets
created as I start a domain that uses bridged networking. The
XML specification of the domain contains the following
configuration
<interface type='bridge'>
<source bridge='br0'/>
</interface>
The libvirt documentation
(
http://libvirt.org/formatdomain.html#elementsNICSBridge
<
http://libvirt.org/formatdomain.html#elementsNICSBridge>) and
other discussions online tell me that I just need to include
the <target dev='desired_dev_name'/> tag in the XML
specification of the domain under the <interface> tag.
Unfortunately doing so appears to have no effect; the tun
device created and 'enslaved' in the bridge is still called
'tap0'. Interestingly, I never get a tun device with a name
prefixed by 'vnet' or 'vif' which, according to the
documentation, is the default behaviour (?). The host is
running CentOS 7, and virsh is used to start the domain.
This is because you're running virsh as a non-privileged user
(rather than root) and so are connecting to that user's personal
non-privileged libvirtd (aka qemu:///session) rather than the
system's privileged libvirtd (qemu:///system). When using
qemu:///session, libvirtd is unable to create tap devices itself
(because it doesn't have sufficient privilege for it), so it
executes qemu-bridge-helper (from the qemu package) requesting
that a tap device be created and attached to the bridge device
specified on its commandline. Unfortunately, qemu-bridge-helper
doesn't provide any way to specify the tap device name, so you get
what it decides to give you (which happens to be "tap%d").
If you want more control over the name of the tap device (and many
other things), you should look into using qemu:///system. That may
seem less secure, but libvirt actually does a very good job of
confining the qemu process - after setting up all the resources
that will be needed (which are labeled with an selinux context
unique to this particular guest) and setting up cgroups to limit
use of system resources, it switches to a different
(non-privileged) uid and drops all capabilities before exec'ing qemu.
(Note that, even if you're using qemu:///system, any
manually-specified tap device name that starts with "vnet" will be
discarded (it assumes that it is an auto-generated name left over
from a previous run, or from plugging a domain's status XML into
virsh define)).