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

[Govert]

Ok, that indeed rules out this other option. Thanks for letting me know.
I'm still discovering the basics of libvirt/qemu/Linux networking, this
definitely prevents some unnecessary experimentation :)

Best,
Govert

2017-01-20 17:20 GMT+01:00 Laine Stump <laine at laine.org>:

> 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 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/20170121/10730794/attachment.htm>