qemu-kvm should Build-Depends on libvdeplug2-dev (KVM vde2 support not working)

It has been closed in Debian. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494871)

The fixed package is already in Jaunty.

Confirmed: I've also back-ported Jaunty's kvm-83 for Intrepid, Hardy, and Gutsy. They are available from my PPA. The only one I've not tested is Gutsy since I'm in the midst of debugging various Jaunty installation bugs.

I don't think this is solved because kvm-83 doesn't have vde support, it doesn't mention vde in Build-Depends. It was working with kvm-72.

jiribb is correct - not sure what I was doing saying Confirmed!

Although the debian kvm-79 package appears to have VDE enabled, kvm-83 has reverted to the kvm-72 status. I'll upload VDE-enabled versions into my PPA.

If you'd like to try it out the package is now in my PPA for Hardy, Intrepid and Jaunty.

kvm (1:83+dfsg-0ubuntu2~tj~ppa2j) jaunty; urgency=low

  * Add build-depends on libvdeplug2-dev which will cause qemu's configure
    script to enable vde support (LP: #253230).

 -- TJ <email address hidden> Thu, 12 Feb 2009 15:15:00 +0000

Good fix, thanks TJ.

I'll upload this as soon as the Alpha freeze is over.

:-Dustin

This bug was fixed in the package kvm - 1:84+dfsg-0ubuntu4

---------------
kvm (1:84+dfsg-0ubuntu4) jaunty; urgency=low

  [ TJ <email address hidden> ]
  * debian/control: add build-depends on libvdeplug2-dev which will cause
    qemu's configure script to enable vde support, LP: #253230

  [ Dustin Kirkland ]
  * debian/kvm-source.postinst: remove dkms module before installing new
    one, LP: #334177

 -- Dustin Kirkland <email address hidden> Thu, 26 Feb 2009 16:07:57 -0600

Actually, I had to revert this change. libvdeplug2-dev (vde2) is in Universe. We'll need to get an MIR filed/approved before we can have kvm build-dep on it.

Sorry.

:-Dustin

Ooops :)

Maybe we could add documentation to the package to make creating routed connections easier for end-users to avoid the need for vde?

Hi TJ-

I've spoken with KVM/QEMU upstream developers. They're saying that tap is really the 'official', 'supported' networking mechanism for kvm and qemu, and really what they strongly recommend. vde lacks the testing or support base, so I don't think we'd really want to compile against this in Ubuntu until it does.

Sorry about that.... I'm going to make this 'won't fix' for now.

:-Dustin

hi,

I've reopened this bug as it seems that it was fixed into debian

Marking wont-fix against Lucid, as we can't very well go about MIR'ing and enabling VDE in qemu-kvm for Lucid.

However, we should perhaps consider this for Lucid+1, so I've open a task against both qemu-kvm and vde2 for Lucid+1, and triaged it.

Someone will need to write an MIR for this. I suggest that someone who actually has both a vested interest in VDE, as well as experience using it (neither of which I have), write the MIR, per:
 * https://wiki.ubuntu.com/MainInclusionProcess

Thanks,
:-Dustin

FYI... Minimally supported qemu-kvm packages with VDE support are in:
 * https://edge.launchpad.net/~ubuntu-virt/+archive/vde

Thanks Dustin!
Works like a charm for me. kvm even seems to be faster than before.

FYI
I am using vde2 for four production server since intrepid ibex. For my network knowledge (I never managed to understand
tap/tun) it's easy to understand (everyone knows what a switch is) and works stable and flawless.

Just to clarify this, kvm vde2 is not officially supported in karmic?
But I can just use another repo to add this?
Or did I actually do a system upgrade to the next version (probably lucid)?

Hi,

Dustin, could you upload a maverick build with updated version ?

Regards,
Étienne

Hi,

Actually, would it be possible to ship a qemu-kvm-vde package in universe ?

Regards,
Étienne

Ubuntu 10.04

When starting kvm or qemu under vdeq

vdeq qemu -sda1 qemu-image -m 128
NOTE: vdeq is now DEPRECATED -- both QEMU and KVM have native support for
      VDE. This binary will be removed soon from the distribution, consider
      stopping using it.

***Be aware: I don't speak on behalf of VDE team, this is only my personal opinions as kvm user.***

A lot of users need this feature. My projects (see virtualbricks here on lp) are affected by this bug and the only thing I can do is suggest users to install another distribution.

I still see nothing moving on Ubuntu side for this bug. AFAIK "Natty" is still affected.

The known workarounds by now are:

- Compile kvm yourself and enable libvdeplug support
- Switch to a (less blind) distribution. Debian for instance.

Sorry, the average user doesn't care about your universe vs. main repository issues and you are not yet able to provide a solution that makes sense.

If you can't just promote libvdeplug to main, then place qemu-kvm in universe as well. I don't care, but this is becoming ridiculous.

Hi,

> - Compile kvm yourself and enable libvdeplug support
> - Switch to a (less blind) distribution. Debian for instance.
>
> Sorry, the average user doesn't care about your universe vs. main
> repository issues and you are not yet able to provide a solution that
> makes sense.

Don't use vde, use openvswitch.

Christian

Sorry, but I don't get the point.
The openvswitch does not even have half of the features vde provides, it is just a switch!

Also, it is not for me, it's for my users I am complaining. My Debian has full kvm+vde support since this has been closed a while ago.

I know there are different solutions for the average Joe, but Ubuntu cannot simply ignore the request of thousands of users.The role of a *complete* distribution should be to provide different tools for similar purposes.

Qemu and KVM have been supporting libvde2 for years now, and most distro out there come with a fully featured kvm/qemu package.

Am 14.07.2011 15:25, schrieb Danielinux:
> Sorry, but I don't get the point.
> The openvswitch does not even have half of the features vde provides, it is just a switch!

First of all, I am not belonging to Ubuntu. So what they do or not is
out of my scope ;-) My suggestion is to use openvswitch. Vde is running
in userspace, while openvswitch uses kernel modules and has much better
performance. And I guess, you do not really know about the fetures that
ovs has (sorry, don't feel attacked, Just my guess).

The good thing with ovs is that it has a bridge-replacement module. So
for kvm, nothing changes.

I have to stop now, because this is a bug tracker and people are getting
angry, if it is used as forum or discussion platform. Feel free to
contact me personally.

Christian

I am replying here because I think this discussion is still adherent to the topic, and also because I don't mind spamming this bug report. It's been open for years and lead to nothing.

I am not here to say what is better between ovs, vde or any other similar tool. The super-partes role of a distribution must be to include every (popular) solution and this is the real advantage of free/OS. Ubuntu is just living on a different planet here.

For the sack of completeness, I must say vde has a kernelspace version as well, but it is less popular since vde is designed to run on other OSes too. I would be interested to benchmark the two tools anyway.

As a matter of fact, I don't see any counterpart for most of the vde tools in ovs, in particular most of the time I have to recreate complex network topologies, integrate emulated channels, use encrypted tunnels, connect local/remote real/virtual machines with maximum flexibility.

OVS is a VDE competitor as well as OpenVPN is, from my point of view. VDE is just a "broader" tool, and for me (and several other people) it is just nice to use the native integration with qemu and kvm, even if workarounds like bridging a kvm tap or even "capturing" it with vde_pcap are still possible nowadays with the lame official Ubuntu package.

My point is that OVS for sure does a great job, most likely from what you say it is even better than VDE for the features they have in common, but VDE is a set made of a larger number of tools for different purposes, that's why I am insisting that much here. Sorry if I was too direct in my previous reply: I am trying to explain why "use X instead of Y if Y is not supported in the distro" was not an acceptable answer.

I don't have any objection to enabling vde support. However, vde2 is in universe, and qemu-kvm is in main. That means someone needs to do a main inclusion request (MIR) for vde2 before we can depend on it in qemu-kvm.

Anyone who would like to see this support enabled can pursue the MIR. Please see https://wiki.ubuntu.com/MainInclusionProcess for details.

I RTFMed and created a MIR some time ago and nothing has happened yet. I'm still pushing for this.

See bug 776818.

The latest suggestion in the MIR report was that we file a bug against kvm. Oh my!

I got qemu with vde working as follows. I built the qemu-kvm from quantal
with the attached qemu-vde.debdiff applied. Then set up the qemu vde nic
and started qemu as follows:

cat >> /etc/network/interfaces << EOF
auto qemutap
  iface qemutap inet static
  address 10.0.5.1
  netmask 255.255.255.0
  vde2-switch -
EOF

ifup qemutap

dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/qemutap.dnsmasq.pid --conf-file= --listen-address 10.0.5.1 --dhcp-range 10.0.5.2,10.0.5.254 --dhcp-lease-max=253 --dhcp-no-override --except-interface=lo --interface=qemutap

iptables -A POSTROUTING -s 10.0.5.0/24 -t nat -j MASQUERADE

cat >> /etc/dnsmasq.d/qemu << EOF
bind-interfaces
except-interface=qemutap
EOF
restart dnsmasq

kvm -net nic -net vde,sock=/var/run/vde2/qemutap.ctl -m 1024 -hda x.img -cdrom ubuntu-12.04-alternate-amd64.iso -vnc :1

So perhaps a qemu-vde package should set up a qemuvdetap network as above.