[libvirt] [PATCH] Basic support for VDE networking

I have seen several messages asking for VDE networking support. There is an item also in your todo web page. http://libvirt.org/todo.html I have developed a patch to provide a basic support for VDE. It defines and manages the syntax: <domain ....> <device> <interface type='vde'> ... <switch path='/tmp/vde.ctl'/> </interface> </device> </domain> the switch tag can be omitted: vde uses the default switch. I have tested the qemu/kvm support. user-mode linux support is included but not tested yet. libvirt vde support for virtualbox has not been coded yet (virtualbox itself supports vde). The patch is against libvirt-0.8.7. renzo (designer/developer of VDE, university of bologna, wiki.virtualsquare.org) Signed-off-by: Renzo Davoli <renzo@cs.unibo.it> --- --- a/src/lxc/lxc_driver.c 2011-01-10 11:49:49.000000000 +0100 +++ b/src/lxc/lxc_driver.c 2011-01-10 11:50:03.000000000 +0100 @@ -1083,6 +1083,7 @@ case VIR_DOMAIN_NET_TYPE_INTERNAL: case VIR_DOMAIN_NET_TYPE_DIRECT: case VIR_DOMAIN_NET_TYPE_LAST: + case VIR_DOMAIN_NET_TYPE_VDE: break; } --- a/src/uml/uml_conf.c 2011-01-10 12:03:54.000000000 +0100 +++ b/src/uml/uml_conf.c 2011-01-10 13:26:08.000000000 +0100 @@ -269,6 +269,14 @@ virBufferVSprintf(&buf, "tuntap,%s", def->ifname); break; + case VIR_DOMAIN_NET_TYPE_VDE: + /* ethNNN=vde,vde_switch,macaddr,port,group,mode,description */ + if (def->data.vde.vdeswitch) { + virBufferVSprintf(&buf, "vde,%s", def->data.vde.vdeswitch); + } else + virBufferAddLit(&buf, "vde"); + break; + case VIR_DOMAIN_NET_TYPE_INTERNAL: umlReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("internal networking type not supported")); --- a/src/conf/domain_conf.h 2011-01-10 11:41:07.000000000 +0100 +++ b/src/conf/domain_conf.h 2011-01-10 13:21:08.000000000 +0100 @@ -288,6 +288,7 @@ VIR_DOMAIN_NET_TYPE_BRIDGE, VIR_DOMAIN_NET_TYPE_INTERNAL, VIR_DOMAIN_NET_TYPE_DIRECT, + VIR_DOMAIN_NET_TYPE_VDE, VIR_DOMAIN_NET_TYPE_LAST, }; @@ -336,6 +337,9 @@ int mode; virVirtualPortProfileParams virtPortProfile; } direct; + struct { + char *vdeswitch; + } vde; } data; char *ifname; virDomainDeviceInfo info; --- a/src/conf/domain_conf.c 2011-01-10 11:42:04.000000000 +0100 +++ b/src/conf/domain_conf.c 2011-01-10 14:49:46.000000000 +0100 @@ -182,7 +182,8 @@ "network", "bridge", "internal", - "direct") + "direct", + "vde") VIR_ENUM_IMPL(virDomainChrChannelTarget, VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_LAST, @@ -598,6 +599,10 @@ VIR_FREE(def->data.direct.linkdev); break; + case VIR_DOMAIN_NET_TYPE_VDE: + VIR_FREE(def->data.vde.vdeswitch); + break; + case VIR_DOMAIN_NET_TYPE_USER: case VIR_DOMAIN_NET_TYPE_LAST: break; @@ -2293,6 +2298,7 @@ char *internal = NULL; char *devaddr = NULL; char *mode = NULL; + char *vdeswitch = NULL; virNWFilterHashTablePtr filterparams = NULL; virVirtualPortProfileParams virtPort; bool virtPortParsed = false; @@ -2379,7 +2385,11 @@ xmlStrEqual(cur->name, BAD_CAST "state")) { /* Legacy back-compat. Don't add any more attributes here */ devaddr = virXMLPropString(cur, "devaddr"); - } + } else if ((vdeswitch == NULL) && + def->type == VIR_DOMAIN_NET_TYPE_VDE && + xmlStrEqual(cur->name, BAD_CAST "switch")) { + vdeswitch = virXMLPropString(cur, "path"); + } } cur = cur->next; } @@ -2529,6 +2539,11 @@ break; + case VIR_DOMAIN_NET_TYPE_VDE: + def->data.vde.vdeswitch = vdeswitch; + vdeswitch = NULL; + break; + case VIR_DOMAIN_NET_TYPE_USER: case VIR_DOMAIN_NET_TYPE_LAST: break; @@ -6263,6 +6278,12 @@ " "); break; + case VIR_DOMAIN_NET_TYPE_VDE: + if (def->data.vde.vdeswitch) + virBufferEscapeString(buf, " <switch path='%s'/>\n", + def->data.vde.vdeswitch); + break; + case VIR_DOMAIN_NET_TYPE_USER: case VIR_DOMAIN_NET_TYPE_LAST: break; --- a/src/qemu/qemu_command.c 2011-01-10 13:11:17.000000000 +0100 +++ b/src/qemu/qemu_command.c 2011-01-10 13:26:28.000000000 +0100 @@ -1602,12 +1602,21 @@ case VIR_DOMAIN_NET_TYPE_BRIDGE: case VIR_DOMAIN_NET_TYPE_INTERNAL: case VIR_DOMAIN_NET_TYPE_DIRECT: + case VIR_DOMAIN_NET_TYPE_VDE: case VIR_DOMAIN_NET_TYPE_LAST: break; } type_sep = ','; break; + case VIR_DOMAIN_NET_TYPE_VDE: + virBufferAddLit(&buf, "vde"); + if (net->data.vde.vdeswitch) + virBufferVSprintf(&buf, "%csock=%s", + type_sep, + net->data.vde.vdeswitch); + break; + case VIR_DOMAIN_NET_TYPE_USER: default: virBufferAddLit(&buf, "user");

On Tue, Jan 11, 2011 at 04:12:57PM +0100, Renzo Davoli wrote:
I have seen several messages asking for VDE networking support. There is an item also in your todo web page. http://libvirt.org/todo.html I have developed a patch to provide a basic support for VDE. It defines and manages the syntax:
<domain ....> <device> <interface type='vde'> ... <switch path='/tmp/vde.ctl'/> </interface> </device> </domain>
the switch tag can be omitted: vde uses the default switch. I have tested the qemu/kvm support. user-mode linux support is included but not tested yet. libvirt vde support for virtualbox has not been coded yet (virtualbox itself supports vde).
I was actually thinking that VDE should be supported in a slightly different, more integrated manner. libvirt has a set of APIs for 'virtual networking'. When libvirt runs privileged, we make use of a isolated bridge device + ip forwarding/NAT for this. My plan was that when running unprivileged, we'd make use of VDE for the implementation instead of a bridge. eg, so you'd be able to create/delete/manage VDE daemon instances using the 'virsh net-XXX' command set. The guest domains would be connected to VDE using the existing <interface type='network'> syntax, and not expose any 'vde' syntax in the guest XML directly. I think letting apps manage VDE daemon instances via the libvirt APi would make this functionality much more friendly & useful Daniel

On 12/01/2011, at 11:29 PM, Daniel P. Berrange wrote:
On Tue, Jan 11, 2011 at 04:12:57PM +0100, Renzo Davoli wrote:
I have seen several messages asking for VDE networking support. There is an item also in your todo web page. http://libvirt.org/todo.html I have developed a patch to provide a basic support for VDE. It defines and manages the syntax:
<domain ....> <device> <interface type='vde'> ... <switch path='/tmp/vde.ctl'/> </interface> </device> </domain>
the switch tag can be omitted: vde uses the default switch. I have tested the qemu/kvm support. user-mode linux support is included but not tested yet. libvirt vde support for virtualbox has not been coded yet (virtualbox itself supports vde).
I was actually thinking that VDE should be supported in a slightly different, more integrated manner. libvirt has a set of APIs for 'virtual networking'. When libvirt runs privileged, we make use of a isolated bridge device + ip forwarding/NAT for this. My plan was that when running unprivileged, we'd make use of VDE for the implementation instead of a bridge.
eg, so you'd be able to create/delete/manage VDE daemon instances using the 'virsh net-XXX' command set. The guest domains would be connected to VDE using the existing <interface type='network'> syntax, and not expose any 'vde' syntax in the guest XML directly. I think letting apps manage VDE daemon instances via the libvirt APi would make this functionality much more friendly & useful
That's potentially interesting from the OSX point of view as well. The VDE website (wiki) has conflicting info on it, but mentions in the notes for its System Requirements that it works on OSX.

That's potentially interesting from the OSX point of view as well.
The VDE website (wiki) has conflicting info on it, but mentions in the notes for its System Requirements that it works on OSX.
We do not release VDE binaries for MacOSX (our team maintains the packets only for Debian) but the source code can be compiled on MacOSX. We do have MacOSX users of VDE (and FreeBSD, NetBSD, too). We do not test the source distribution on MacOSX, so if you'll run into some issue on the latest versions of OSX, let us know. We'll be glad to update the code to satisfy all possible VDE users. renzo

On 13/01/2011, at 10:35 PM, Renzo Davoli wrote:
That's potentially interesting from the OSX point of view as well.
The VDE website (wiki) has conflicting info on it, but mentions in the notes for its System Requirements that it works on OSX.
We do not release VDE binaries for MacOSX (our team maintains the packets only for Debian) but the source code can be compiled on MacOSX. We do have MacOSX users of VDE (and FreeBSD, NetBSD, too). We do not test the source distribution on MacOSX, so if you'll run into some issue on the latest versions of OSX, let us know. We'll be glad to update the code to satisfy all possible VDE users.
Just as a data point, VDE 2.3.1 is now officially included in the Homebrew packaging system for OSX. Well, as of two days ago. (Homebrew is a popular packaging system for OSX) It means that to install vde, OSX Homebrew users can now just go: $ brew install vde And voila, it pulls down the source, compiles, and installs. Note that it doesn't also pull down nor install tuntap, as that package seems to require installation into hard coded system locations. But... vde seems to autodetect if tuntap is installed when it compiles. So I suspect tuntap support would be compiled into vde automatically, if tuntap was installed manually first. Hope that helps at least a bit. Regards and best wishes, Justin Clift
participants (3)
-
Daniel P. Berrange
-
Justin Clift
-
Renzo Davoli