|Summary:||VDE support in qemu?|
|Product:||[Fedora] Fedora||Reporter:||Richard Monk <rmonk>|
|Component:||qemu||Assignee:||Glauber Costa <gcosta>|
|Status:||CLOSED CANTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||berrange, dwmw2, gcosta, itamar, jaswinder, jforbes, marcin, markmc, quintela, rjones, virt-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-10-23 11:22:58 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Richard Monk 2009-10-21 12:15:56 UTC
Description of problem: Although qemu has had support for VDE (Virtual Distributed Ethernet) from http://vde.sourceforge.net/ for a time, Fedora does not package vde or vde-devel, and qemu is built without it. VDE allows multiple qemu images to connect to a single TAP interface and function as a virtual switch. This makes it far easier to handle a group of machines that expect to be on the same subnet (stage systems, cluster tests, etc) but also need access to the host or external network. I saw this posting on fedora-devel-list in 2007: http://firstname.lastname@example.org/msg23605.html Is there a reason that VDE is not in fedora (I was unable to find anything in either direction) or should I request it be added so that we can all make use of the VDE tools? Thanks!
Comment 1 Mark McLoughlin 2009-10-21 12:30:10 UTC
If you'd like VDE support, you should really start with submitting a vde package: http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess if there was one, we'd enable support for it in qemu However, I'm unclear as to how useful VDE is - e.g. in your use case, what is wrong with adding a tap interface for each guest to the bridge? Also, if you use VDE rather than a tap interface, the guest cannot take advantage of GSO with virtio-net for increased performance.
Comment 2 Richard Monk 2009-10-21 13:39:31 UTC
Most of the issue with the TAP interfaces is that it grows unwieldy when one host has 10-15 guests. Having a VDE for each 'network' and a single TAP device looks like the host is connected to a network with a bunch of hosts on it, the "feel" is closer to bare metal. tap tap tap -> bridge is similar (but ifconfig still is "messy"). VDE also provides some capabilities as if it was a real switch. I haven't used the tunneling/vlan capabilities, but that could be useful to connect two sets of guests on separate hosts to a single virtualized subnet without needing extra packages or setup like IPv6/OpenVPN would. Also, VDE allows me to specify permissions so that groups X can add hosts to subnets Y and Z but not to A and B, without writing any fancy scripts. I don't have to give users direct access to the tun driver. I haven't done any tests with direct-to-TAP vs VDE throughput. I haven't noticed any "slowness" so far, but I haven't done anything that pushed large chunks of data other than the initial install over NFS and that ran quite fast. I just ran a netcat between a guest and the host over the VDE, and got 22M/sec. the qemu process was at 100% during that time (8 core machine, other processes offloaded to other cores). Should I be able to pull down full 1000Mbit ethernet or more over the raw TAP? I'll test this today.
Comment 3 Mark McLoughlin 2009-10-23 11:22:58 UTC
I mentioned GSO, here's more details: http://blogs.gnome.org/markmc/2008/05/28/checksums-scatter-gather-io-and-segmentation-offload/ At a libvirt level, we should probably think about allowing a virtual network to be plugged to and from a physical NIC - that way you could have all your guests connected to a virtual network and change which NIC is connected to Ignore any implementation details around how we currently implement virtual networks with a bridge - e.g. by moving a network between NICs, we could just be removing all taps from one bridge and adding them to another Summary is: - we'd tend to want to address the requirements you mention not by "let's add VDE support", but rather think about how we properly address those requirements in libvirt and our tools, while still being able to use features like segmentation offload - we're happy to enable VDE support in Fedora's qemu if someone packages vde itself So CLOSING as CANTFIX this "VDE support in qemu" RFE until someone packages up vde
Comment 4 Marcin Łabanowski 2014-05-28 10:14:10 UTC
If you are interested in using VDE with QEMU, you can check out this repository: http://copr.fedoraproject.org/coprs/czaks/qemu-vde2/