9:49 p.m.
Hi,
I don't know who helps qemu-kvm to create and open the tap file and when if I define
an interface of a kvm vm like:
<interface type='bridge'>
<mac address='52:54:00:e4:2e:c1'/>
<source bridge='br200'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</interface>
The qemu-kvm process's command line will be:
/usr/libexec/qemu-kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1
-name test -uuid 4b39bb5e-3994-9529-b554-2610f905945d -nodefconfig -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/test.monitor,server,nowait -mon
chardev=charmonitor,id=monitor,mode=control -rtc base=utc -drive
file=/var/lib/libvirt/images/test.img,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=threads
-device
virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device
ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e4:2e:c1,bus=pci.0,addr=0x3
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device
usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device
intel-hda,id=sound0,bus=pci.0,addr=0x4 -device
hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
Note the -netdev tap,fd=24
If I use predefined tap dev name to define:
<interface type='ethernet'>
<mac address='f6:19:e0:6c:84:c3'/>
<script path=''/>
<target dev='tap10'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</interface>
The process will be run as:
/usr/libexec/qemu-kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1
-name test-clone -uuid c188ef83-82a4-23bb-dd81-b364e0b4d055 -nodefconfig -nodefaults
-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/test-clone.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -drive
file=/var/lib/libvirt/images/test-clone.img,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=threads
-device
virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device
ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev
tap,ifname=tap10,script=,id=hostnet0 -device
rtl8139,netdev=hostnet0,id=net0,mac=f6:19:e0:6c:84:c3,bus=pci.0,addr=0x3 -chardev
pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device
usb-tablet,id=input0 -vnc 127.0.0.1:1 -vga cirrus -device
intel-hda,id=sound0,bus=pci.0,addr=0x4 -device
hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
please note the -netdev tap,ifname=tap10
Thanks
Yong Sheng Gong
11:36 p.m.
On 06/14/2012 08:49 PM, Yong Sheng Gong wrote:
Hi,
I don't know who helps qemu-kvm to create and open the tap file and when if I define
an interface of a kvm vm like:
<interface type='bridge'>
<mac address='52:54:00:e4:2e:c1'/>
<source bridge='br200'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</interface>
The qemu-kvm process's command line will be:
<snip>
Note the -netdev tap,fd=24
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
10:11 p.m.
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> wrote: -----
To: Yong Sheng Gong/China/IBM@IBMCN
From: Eric Blake <eblake(a)redhat.com>
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:
Hi,
I don't know who helps qemu-kvm to create and open the tap file and when if I define
an interface of a kvm vm like:
<interface type='bridge'>
<mac address='52:54:00:e4:2e:c1'/>
<source bridge='br200'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</interface>
The qemu-kvm process's command line will be:
<snip>
Note the -netdev tap,fd=24
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]
4543
days inactive
4545
days old
2 comments
2 participants
participants (2)
-
Eric Blake -
Yong Sheng Gong