Bug 530059 - VDE support in qemu?
VDE support in qemu?
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Glauber Costa
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-21 08:15 EDT by Richard Monk
Modified: 2014-05-28 06:14 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-23 07:22:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard Monk 2009-10-21 08:15:56 EDT
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://www.mailinglistarchive.com/fedora-devel-list@redhat.com/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 08:30:10 EDT
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 09:39:31 EDT
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 07:22:58 EDT
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 06:14:10 EDT
If you are interested in using VDE with QEMU, you can check out this repository:

http://copr.fedoraproject.org/coprs/czaks/qemu-vde2/

Note You need to log in before you can comment on or make changes to this bug.