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 <la...@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)). >
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
