Bug 530059
| 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> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | berrange, dwmw2, gcosta, itamar, jaswinder, jforbes, marcin, markmc, quintela, rjones, virt-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-10-23 11:22:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Richard Monk
2009-10-21 12:15:56 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. 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. 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 If you are interested in using VDE with QEMU, you can check out this repository: http://copr.fedoraproject.org/coprs/czaks/qemu-vde2/ |