Re: [libvirt] ask for help to explain the network about tap

Hi Eric, Thanks for the reply. I have a new question. I found I cannot ping the VM with predefined tap device in domain xml from other host:    <interface type='ethernet'>       <mac address='f6:19:e0:6c:84:c3'/>       <script path=''/>       <target dev='tap10'/>       <alias name='net0'/>       <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>     </interface> But I can ping the VM with libvirtd defined tap device in domain xml from other host:     <interface type='bridge'>       <mac address='52:54:00:e4:2e:c1'/>       <source bridge='br200'/>       <target dev='vnet0'/>       <model type='virtio'/>       <alias name='net0'/>       <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>     </interface> [root@robinlinux ~]# brctl show bridge name    bridge id        STP enabled    interfaces br100        8000.0021cc6d4440    no        eth0 br200        8000.0021cc6d4443    no        eth0.1000                                                                   gw200                                                                   tap10                                                                    vnet0 And I can ping both of VMs from local host. What does libvirtd do to allow the bridge to forward the packet to the tap device attached by target VM? As far as I know all the packets destined to the bridge's ports from outside will be consumed by bridge itself, not xmit to particular port. Thanks Yong Sheng Gong -----Eric Blake <eblake(a)redhat.com&gt; wrote: ----- To: Yong Sheng Gong/China/IBM@IBMCN From: Eric Blake <eblake(a)redhat.com&gt; Date: 06/15/2012 12:36PM Cc: libvir-list(a)redhat.com Subject: Re: [libvirt] ask for help to explain the network about tap On 06/14/2012 08:49 PM, Yong Sheng Gong wrote: <snip> That's libvirtd that opened the tap file, and passed it by inheritance to the new qemu process.  Unfortunately, this means that you can't recreate the same qemu process without also opening the tap device yourself the same way that libvirtd would do it.  But this approach of fd passing is essential to security, since libvirtd intentionally removes capabilities that prevent qemu from opening the tap itself, so libvirtd must pass in the fd pre-opened. Did you have specific questions about which functions in libvirt source code open the tap device? Also, note that libvirtd will issue an audit log event for every tapfd that it opens and gives to qemu.  The fd number is unpredictable, but the fact that an fd was opened as backed by a tap device is pretty easy to follow in the audit logs. -- Eric Blake   eblake(a)redhat.com    +1-919-301-3266 Libvirt virtualization library http://libvirt.org [attachment "signature.asc" removed by Yong Sheng Gong/China/IBM]