libvirt users - Jan 2017 - Re: Controlling the name of the 'tap0' device, in a bridged networking setup

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.

Best,
Govert

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)).

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).

Best,
Govert

2017-01-17 20:46 GMT+01:00 Laine Stump <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/formatdoma
>> in.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)).
>