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 models at: * https://help.ubuntu.com/community/KVM/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 release 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, through Hardy->Intrepid->Jaunty->Karmic->Lucid. 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 builds) 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: * https://wiki.ubuntu.com/MainInclusionProcess I have marked your bug a duplicate of another one, marked wont-fix against Lucid, but marked it triaged/high for Lucid+1, at: * https://bugs.edge.launchpad.net/ubuntu/+source/vde2/+bug/253230 > 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 ;-) Cheers, -- :-Dustin Dustin Kirkland Canonical, LTD kirkl...@canonical.com GPG: 1024D/83A61194
signature.asc
Description: This is a digitally signed message part
-- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
