-----Original Message----- From: libvir-list-bounces@xxxxxxxxxx [mailto:libvir-list-bounces@xxxxxxxxxx] On Behalf Of Laine Stump Sent: Monday, July 23, 2012 12:43 PM To: libvir-list@xxxxxxxxxx Subject: Re: [PATCH 1/2] ESX: Add routines to interface driver On 07/20/2012 05:20 PM, Ata E Husain Bohra wrote: > Add following routines to esx_interface_driver: > esxNumOfInterfaces, > esxNumOfDefinedInterfaces, > esxListInterfaces, > esxListDefinedInterfaces, > esxInterfaceLookupByMACString, > esxInterfaceGetXMLDesc, > esxInterfaceUndefine, > esxInterfaceCreate, > esxInterfaceDestroy > > Signed-off-by: Ata E Husain Bohra <ata.husain@xxxxxxxxxxx> > --- > src/esx/esx_interface_driver.c | 506 +++++++++++++++++++++++++++++++++++++++- > src/esx/esx_vi.c | 126 ++++++++++ > src/esx/esx_vi.h | 10 + > src/esx/esx_vi_generator.input | 227 ++++++++++++++++++ > src/esx/esx_vi_generator.py | 31 ++- > src/esx/esx_vi_types.c | 18 +- > 6 files changed, 913 insertions(+), 5 deletions(-) > > diff --git a/src/esx/esx_interface_driver.c > b/src/esx/esx_interface_driver.c index 5713137..b1ba5e2 100644 > --- a/src/esx/esx_interface_driver.c > +++ b/src/esx/esx_interface_driver.c > @@ -23,6 +23,9 @@ > */ > +static int > +esxNumOfInterfaces(virConnectPtr conn) { > + esxPrivate *priv = conn->interfacePrivateData; > + esxVI_HostVirtualNic *virtualNicList = NULL; > + const esxVI_HostVirtualNic *virtualNic = NULL; > It's a bit disconcerting to see these called "virtual" NICs, when > virInterface is all about configuring interfaces on the *physical* host. >This i my biggest concern here too, and also that's the reason why I didn't implement the network driver yet. Because I'm not sure what is the proper mapping between libvirt and vSphere API here. >As far as I understand this, a HostVirtualNic seems to be the best match for a virInterface. A HostVirtualNic is connected to HostVirtualSwitch, that is connected to the physical network via a PhysicalNic. >There is not much one can do about the PhysicalNic. It just sits there and is connected to the HostVirtualSwitch. The HostVirtualNic is also the one that has the external IP address of the ESX server >assigned. >Also a HostVirtualNic is not part of the virtual hardware of a VM. A VirtualEthernetCard is the type in the vSphere API representing the virtual network interface of a virtual machine [AB]: I have developed the driver based on the same understanding; the only thing that I could not map vSphere API <--> Libvirt API was how to allow user application to configure end-end networking on ESX server that includes: creating vSwitches, attaching them to physical network and then configuring HostVirtual Nics. I am still working on the "interfaceCreateXML" that would allow addition of HostVirutalNic and associated portGroup if not present, but could not find any mapping API to add vSwitches. > Being unfamiliar with the vmware API, I'm not sure which of these > functions are things you've added to libvirt and which are part of > vmware, but please rename any that are defined in libvirt to use > "physical" or "host" or "p/h" as appropriate, rather than "virtual" > and/or "v". We want to make sure nobody gets the wrong idea about > these functions. >I don't think that this is a good idea, we should really stick exactly to the naming of things in the vSphere API otherwise there will be much more confusion. >Therefore, > esxVI_HostVirtualNic *virtualNicList = NULL; >should be > esxVI_HostVirtualNic *hostVirtualNicList = NULL; > Apart from that I'll do a more detailed review soon. [AB]: Will modify the names such that HostVirtualNic should read same in vSphere API documentation. > +static int > +esxNumOfDefinedInterfaces(virConnectPtr conn) { > + conn->interfacePrivateData = NULL; >Setting interfacePrivateData to NULL is equivalent to closing the driver. I don't think you really want to do this. Possibly it was an error in cut/paste from somewhere else (esxInterfaceClose()?). [AB]: Patch 2/2 rectified this issue. > + > + // ESX interfaces are always active > + return 0; > +} > + > + > + > +static int > +esxListDefinedInterfaces(virConnectPtr conn, char **names, int > +maxnames) { > + conn->interfacePrivateData = conn->privateData; > + *names = NULL; > + > + /* keeps compiler happy */ > + VIR_DEBUG("max interfaces: %d", maxnames); > + > + // ESX interfaces are always active > + return 0; > +} >As I'll be mentioning in PATCH 2/2, just do this right the first time, rather than having a followup patch to fix code you've just added. [AB]: I will be more careful in the future to avoid such mistakes. Thanks for the advice. > + > +static int > +esxInterfaceCreate(virInterfacePtr iface, unsigned int flags) { > + iface->conn->interfacePrivateData = NULL; >Again - you don't want to NULL this out - it's the same as closing the driver. [AB]: Will remove it. > + > + virCheckFlags(0, -1); > + > + /* ESX interfaces are always active */ > + return 0; > +} > + > + > + > +static int > +esxInterfaceDestroy(virInterfacePtr iface, unsigned int flags) { > + iface->conn->interfacePrivateData = NULL; >And again - don't NULL this. [AB]: Ditto. > * A required property must be != 0 (NULL for pointers, "undefined" > == 0 for >A general comment - I didn't see any kind of mutexes in here. Is this code really threadsafe? (it looks like the toplevel functions just call into your utility functions to get a snapshot of the current state of >interfaces in vmware, then work with that snapshot during the rest of the call; I didn't look into the utility functions in detail, because the chance of me understanding them is fairly low anyway :-) [AB]: I do not think mutex is needed to protect the routines, as ESX server can be operated from multiple vSphere Client interface (management console using vCenter or standalone) and best I know it allows the operation simultaneously. As said this is something I would also like to be discussed in the community, so far reading ESX storage driver where the workflow and driver model remains the same, I do not see any use of mutex to protect such operations. The only places mutexes are used are while using CURL sessions. -- libvir-list mailing list |
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list