[libvirt-users] Controlling the name of the 'tap0' device, in a bridged networking setup

[Govert]

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 at 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)).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20170120/81cc536d/attachment.htm>