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

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

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