12:54 p.m.
-----Original Message-----
From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com]
On Behalf Of Laine Stump
Sent: Monday, July 23, 2012 12:43 PM
To: libvir-list(a)redhat.com
Subject: Re: [libvirt] [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(a)hotmail.com>
---
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list