qemu-kvm vde networking [was Re: Sorry to bother you]
kirkland at canonical.com
Wed Mar 31 15:41:42 BST 2010
On Wed, 2010-03-31 at 10:32 +0200, Christian Rößner wrote:
> excuse me please that I contact you directly. Before I go building my
> own kvm package with vde support I want to ask you, if you could give
> me detailed arguments, why vde is not in main repo and why you
> consider it not secure (enough; you said _more secure than_).
> I wait from release to release always missing the vde support and I
> can not understand why you do not include it. Where are the reasons?
> And why is vde not in main?
> I have really good experiences with vde and kvm for years now. I use
> KVM for several minor internet service providers here in Germany and
> all the servers use vde, cause it is ingenious.
> Seperating local guest communication from outside. And!!!: You do not
> need bridging network, which makes firewalling so much easier. And you
> still can reach the host operating system from the guests, which gives
> you are real intranet.
> So there are so many arguments FOR vde. Any other solution is really a
> pain. And I tested them all! I am not a newie.
> So if security is an argument, then I would say ok.
Hi Christian, thanks for the kind, detailed email. I hope you don't
mind that I'm CC'ing this response to the ubuntu-server@ and
ubuntu-devel@ mailing lists, as this has come up a few times, and I'd
like to collate a single response here...
Okay, let me eat my words on the security aspect of VDE... I can't say
that VDE is more or less secure than the other recommended networking
What I can say is that:
a) Per discussions with upstream QEMU, tap is the 'official',
'supported', 'recommended' networking mechanism for QEMU and KVM
* Upstream also says that VDE performance is poor because it doesn't
support offloading, tap networking should suffice for vast majority of
users, VDE security is mostly untested for things like mac flooding and
ip spoofing, and upstream does virtually no testing of VDE before they
b) The required library, libvdeplug2-dev and its source package, vde2
are in Ubuntu Universe, while qemu-kvm is in Ubuntu Main (Main packages
cannot build against libraries in Universe)
c) Canonical-long-term-supported KVM in Ubuntu's Lucid Main repository
will not differ from Upstream's recommendation on this point
d) The other networking models (ie, through KVM/Libvirt) are *far* more
heavily tested over the last 2 years of Ubuntu Hypervisor development,
What we can offer is this:
1) A qemu-kvm package in a PPA managed by ~ubuntu-virt in Launchpad
that does build against libvdeplug2-dev
* We can try to keep this package "in sync" with what goes into Lucid
(ie, upload at the same time and just enable vde in the PPA build)
* But any problems or issues caused by or related to VDE will be
supported on a best-effort, wishlist-priority basis (as are most PPA
2) If someone who has interest in, and experience with VDE will write
the Main Inclusion Report (MIR) for vde2, we can propose vde2 for
inclusion in Main for Lucid+1, and I'll enable VDE in the qemu-kvm
builds for Lucid+1 if the MIR is approved. See:
I have marked your bug a duplicate of another one, marked wont-fix
against Lucid, but marked it triaged/high for Lucid+1, at:
> But please include it. It is an LTS version, so big chance to make
> this pain an end ;-)
I understand your concern. But this is the precise reason why we cannot
just enable VDE networking at this time. We're at a Beta2 freeze for
our LTS release. I appreciate your confidence in VDE -- that will
support the MIR process for Lucid+1. But the vast majority of testing
and stabilization of Ubuntu's Hypervisor stack has been intensely
focused on the KVM+Libvirt networking model. Slipping VDE networking
into Ubuntu 10.04 LTS at Beta2, and then committing to supporting that
code for 5 years is simply not something we can do, I'm sorry.
> As you read, I am from Germany. Sometimes my English may sound a
> little bit rough, but I do not mean it like this.
No problem ;-)
kirkland at canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100331/3954dcfb/attachment.pgp
More information about the ubuntu-devel