[libvirt] ESX network functionality

[Matthias Bolte]

Sorry, I forgot to reply to your follow up question on the users list.

2011/4/6 James Barkley <james.barkley at gmail.com>:
> Greetings:
> I've added code to the ESX driver to support some basic network
> functionality. I'm pretty new to this list, so please tell me how to proceed
> with code review and patch submission (yes I've read the contributor
> guidelines on the wiki). It seems like people are emailing a patch file for
> every file they've changed, each in separate emails with [1 of N] in the
> subject, is that right? Or is it better to paste in code, get some feedback,
> and eventually attach the patch to the bug tracker item?

The normal approach is to have one commit/patch per logical
self-contained change. After each commit/patch the codebase has to be
in a compilable stage. For example you cannot add the code using the
generated SOAP bindings, before you actually added them to the
esx_vi_generator.input file.

The [1 of N] style patch series are typically used for large changes
that are split in several logical, self-contained parts. Splitting
like this simplifies reviewing and later on figuring out bugs using
git bisect.

You typically don't split on a per file basis.

In your case I'd suggest to create a single commit/patch for your
addition, as it is one logical piece of work. You _could_ (but I don't
recommend to) split it in multiple patches. For example one for the
esx_vi_generator.input addition, one for the VI helper function
additions and one for the actual driver functions, but I'd consider
this to be too fine grained.

> I've updated the code for the ESX driver to be able to handle the following
> functions :
> - virNetworkLookupByName
> - virConnectNumOfDefinedNetworks
> - virConnectNumOfNetworks
> - virConnectListNetworks

Is this sufficient to make virsh net-list work?

> I basically mapped the VMware Managed Object Reference for networks into a
> few data structures and added the following functions to the internal driver

You mean the managed object called Network? They _seem_ to be the
natural fit. But I'm not sure if that's the correct approach, as you
cannot directly create/destroy such objects and they are bound in some
way to the port groups on a virtual switch. Also I'm not sure about
the exact semantics of networks and port groups.

That's what I meant as I said about the mapping between libvirt and
VMware. We need to be sure to use the right approach from the start to
avoid making breaking changes across releases later on.

> API:
> - esxNumOfNetworks
> - esxListNetworks
> - esxNumOfDefinedNetworks

I assume you made esxNumOfDefinedNetworks return 0 to get virsh
net-list working as there network in the VMware context are always
active.

> - esxNetworkLookupByName
> - esxVI_LookupNetworkList
> - esxVI_LookupNetworkByName
> These functions were modeled after existing functions from the domain and
> storage libraries. The following files were touched:
> - esx_network_driver.c
> - esx_vi.c
> - esx_vi.h
> - esx_vi_generator.input

Apart from the question whether the Network managed object is the
correct match, the next step is to send your patch to this list to get
a review. The recommended way for sending patches is git send-email.

Matthias