Re: Controlling the name of the 'tap0' device, in a bridged networking setup

Laine Stump <laine@xxxxxxxxx> · Fri, 20 Jan 2017 11:20:30 -0500



    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@xxxxxxxxx>:

          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/formatdomain.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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users