Re: [libvirt-users] Controlling the name of the 'tap0' device, in a bridged networking setup
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) 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)).