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 <[email protected]>: > 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 <[email protected]>: > >> 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)). >> > > >
_______________________________________________ libvirt-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvirt-users
