On Tue, Feb 17, 2015 at 8:47 AM, Laine Stump <laine@laine.org> wrote:
On 02/16/2015 08:46 PM, Antoni Segura Puimedon wrote:
From: Antoni Segura Puimedon <toni@midokura.com>
Midonet is an opensource virtual networking that over lays the IP network between hypervisors. Currently, such networks can be made with the openvswitch virtualport type. With this patch, one will be able to setup such configurations by binding vNICs to Midonet overlay ports.
Signed-off-by: Antoni Segura Puimedon <toni@midokura.com> --- configure.ac | 4 ++ docs/schemas/networkcommon.rng | 12 +++++ src/Makefile.am | 1 + src/conf/domain_conf.h | 1 + src/conf/netdev_vport_profile_conf.c | 3 +- src/libvirt_private.syms | 5 ++ src/qemu/qemu_hotplug.c | 25 +++++++--- src/qemu/qemu_process.c | 13 +++-- src/util/virnetdevmidonet.c | 97 ++++++++++++++++++++++++++++++++++++ src/util/virnetdevmidonet.h | 37 ++++++++++++++ src/util/virnetdevtap.c | 11 ++-- src/util/virnetdevvportprofile.c | 1 + src/util/virnetdevvportprofile.h | 5 +- 13 files changed, 197 insertions(+), 18 deletions(-) create mode 100644 src/util/virnetdevmidonet.c create mode 100644 src/util/virnetdevmidonet.h
Hi Laine!
I haven't checked the rest for completeness yet, but thought I'd point out in advance that you need to also document the new type in formatdomain.html.in.
Oops, I left it for later when doing the patch and submitted it without getting to it. I'll re-send ;-)
Also, I don't see any changes here to the network configuration to support a network of this type. That can be a second step though. (A very useful thing - it would allow migration of a guest from a host using a standard Linux host bridge to a host using this new network connection type, for example).
Sounds interesting, how would the migration work for the required interfaceid in midonet? Does openvswitch do this thanks to the virtualport interfaceid generation?
You may also need to go through the hypervisor drivers other than qemu and put in explicit checks for your new virtualport type and log an UNSUPPORTED message if it's encountered.
True! Is there a lot of adoption of the lxc driver? Cause maybe I can add support as well for that one.
Another thing - for awhile now everyone has been putting the config/doc/schema changes in one patch, the utility functions in a second, and the glue that ties them together in qemu/lxc/etc in a third. That can make it easier to review, test, and also in the case that some other new feature might use the same utility functions it makes it easier to backport one feature without needing to backport the other. etc etc.
That makes a lot of sense, I'll split the patch accordingly.
I'll go through the code that that's here in the morning.
Thanks a lot for the help last night and for these comments! Toni