8:56 a.m.
I'm trying to get a feel of the python binding and the esx driver
Trying to get the number of interfaces hit(as anticipated) a non-support wall:
Traceback (most recent call last):
File "test.py", line 362, in ?
vmm.refresh()
File "test.py", line 189, in refresh
print self.conn.numOfDefinedInterfaces()
File "/usr/lib/python2.4/site-packages/libvirt.py", line 1347, in
numOfDefinedInterfaces
if ret == -1: raise libvirtError ('virConnectNumOfDefinedInterfaces() failed',
conn=self)
libvirt.libvirtError: this function is not supported by the hypervisor:
virConnectNumOfDefinedInterfaces
I'm wondering how to fix it
can I register the esx driver as the interface driver?
so I can use the ESX web-services to handle all the interface issues that normally(?)
netcf would handle?
if yes - how is it done?
I thought that configure --without-netcf would do the trick(it didn't-I think)
Thanks
Shahar
9:20 a.m.
On Tue, Sep 08, 2009 at 06:56:10AM -0700, Shahar Klein wrote:
I'm trying to get a feel of the python binding and the esx
driver
Trying to get the number of interfaces hit(as anticipated) a non-support wall:
Traceback (most recent call last):
File "test.py", line 362, in ?
vmm.refresh()
File "test.py", line 189, in refresh
print self.conn.numOfDefinedInterfaces()
File "/usr/lib/python2.4/site-packages/libvirt.py", line 1347, in
numOfDefinedInterfaces
if ret == -1: raise libvirtError ('virConnectNumOfDefinedInterfaces()
failed', conn=self)
libvirt.libvirtError: this function is not supported by the hypervisor:
virConnectNumOfDefinedInterfaces
I'm wondering how to fix it
/**
* virConnectNumOfDefinedInterfaces:
* @conn: pointer to the hypervisor connection
*
* Provides the number of defined (inactive) interfaces on the
* physical host.
*
* Returns the number of defined interface found or -1 in case of
* error
*/
*on thephysical host*
ESX only support remote access basically, so the whole set of Interface
functions are moot. I think it's not what you're looking for anyway.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
9:26 a.m.
mmm
I would like to get host(i.e. node) interface info
as well as domain(guest) network/interface info
I will probably would like to set/manipulate the node and domains as well
but it is simpler to start with the get functions - isn't it?
Did I totally misunderstood the architecture?
shahar
________________________________
From: Daniel Veillard <veillard(a)redhat.com>
To: Shahar Klein <shaharklein(a)yahoo.com>
Cc: libvir-list(a)redhat.com
Sent: Tuesday, September 8, 2009 5:20:34 PM
Subject: Re: [libvirt] Interface driver and ESX support
On Tue, Sep 08, 2009 at 06:56:10AM -0700, Shahar Klein wrote:
I'm trying to get a feel of the python binding and the esx
driver
Trying to get the number of interfaces hit(as anticipated) a non-support wall:
Traceback (most recent call last):
File "test.py", line 362, in ?
vmm.refresh()
File "test.py", line 189, in refresh
print self.conn.numOfDefinedInterfaces()
File "/usr/lib/python2.4/site-packages/libvirt.py", line 1347, in
numOfDefinedInterfaces
if ret == -1: raise libvirtError ('virConnectNumOfDefinedInterfaces()
failed', conn=self)
libvirt.libvirtError: this function is not supported by the hypervisor:
virConnectNumOfDefinedInterfaces
I'm wondering how to fix it
/**
* virConnectNumOfDefinedInterfaces:
* @conn: pointer to the hypervisor connection
*
* Provides the number of defined (inactive) interfaces on the
* physical host.
*
* Returns the number of defined interface found or -1 in case of
* error
*/
*on thephysical host*
ESX only support remote access basically, so the whole set of Interface
functions are moot. I think it's not what you're looking for anyway.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
9:55 a.m.
Shahar Klein wrote:
mmm
I would like to get host(i.e. node) interface info
as well as domain(guest) network/interface info
I will probably would like to set/manipulate the node and domains as well
but it is simpler to start with the get functions - isn't it?
Did I totally misunderstood the architecture?
More or less, yes (at least for the ESX driver). The ESX driver is a bit
special, and different from some of the other drivers in that you don't run a
libvirtd on the target machine. It accesses the ESX API's via SOAP on the
remote machine. So what the libvirt driver can do is limited by what the ESX
API's can do. If the ESX API's can do the sort of enumeration you are talking
about, then I think it would be possible to implement it, although it would
require an entirely new interface driver.
--
Chris Lalancette
2:06 a.m.
Let me rephrase my question : )
In the current libvirt infrastructure I can do a lot of things with libvirt and a remote
ESX node
I can list all the guests
I can suspend a guest
I can get a lot of node info
and much more....
can I (for example)
1. add NIC to a guest domain
2. list all the physical interfaces on a node
If not - what do I need to develop
should I expand the current driver
or
should I need to develop a new interface driver(like netcf)
or
maybe I can assign the current esx driver as the interface driver and expand it to handle
the relvant requests
10x again
Shahar
________________________________
From: Chris Lalancette <clalance(a)redhat.com>
To: Shahar Klein <shaharklein(a)yahoo.com>
Cc: veillard(a)redhat.com; libvir-list(a)redhat.com
Sent: Tuesday, September 8, 2009 5:55:42 PM
Subject: Re: [libvirt] Interface driver and ESX support
Shahar Klein wrote:
mmm
I would like to get host(i.e. node) interface info
as well as domain(guest) network/interface info
I will probably would like to set/manipulate the node and domains as well
but it is simpler to start with the get functions - isn't it?
Did I totally misunderstood the architecture?
More or less, yes (at least for the ESX driver). The ESX driver is a bit
special, and different from some of the other drivers in that you don't run a
libvirtd on the target machine. It accesses the ESX API's via SOAP on the
remote machine. So what the libvirt driver can do is limited by what the ESX
API's can do. If the ESX API's can do the sort of enumeration you are talking
about, then I think it would be possible to implement it, although it would
require an entirely new interface driver.
--
Chris Lalancette
2:18 a.m.
Shahar Klein wrote:
Let me rephrase my question : )
In the current libvirt infrastructure I can do a lot of things with
libvirt and a remote ESX node
I can list all the guests
I can suspend a guest
I can get a lot of node info
and much more....
can I (for example)
1. add NIC to a guest domain
From looking at the current libvirt ESX driver (in
src/esx/esx_driver.c), it
looks like no, this is not implemented yet.
2. list all the physical interfaces on a node
This is also not implemented yet.
If not - what do I need to develop
should I expand the current driver
For case 1) above, you should certainly expand the current driver (although
again, this all depends on whether the ESX SOAP API supports this operation,
which I can't answer).
For case 2) above, it's a lot more tricky. If you look at
src/interface_driver.c, that is one network interface driver that can enumerate
all of the physical devices on a host (using netcf as the backend). *If* the
ESX SOAP API's provide something similar, then you possibly could write a new
network interface driver for ESX that used the SOAP API's on the backend. This
would be a whole new interface driver, and may require new API's (although I'm
not sure about this, since I don't know the interface driver very well).
--
Chris Lalancette
3:29 a.m.
thanks Chris
I'll try to write somthing
and see how it goes
shahar
________________________________
From: Chris Lalancette <clalance(a)redhat.com>
To: Shahar Klein <shaharklein(a)yahoo.com>
Cc: veillard(a)redhat.com; libvir-list(a)redhat.com
Sent: Wednesday, September 9, 2009 10:18:39 AM
Subject: Re: [libvirt] Interface driver and ESX support
Shahar Klein wrote:
Let me rephrase my question : )
In the current libvirt infrastructure I can do a lot of things with
libvirt and a remote ESX node
I can list all the guests
I can suspend a guest
I can get a lot of node info
and much more....
can I (for example)
1. add NIC to a guest domain
From looking at the current libvirt ESX driver (in
src/esx/esx_driver.c), it
looks like no, this is not implemented yet.
2. list all the physical interfaces on a node
This is also not implemented yet.
If not - what do I need to develop
should I expand the current driver
For case 1) above, you should certainly expand the current driver (although
again, this all depends on whether the ESX SOAP API supports this operation,
which I can't answer).
For case 2) above, it's a lot more tricky. If you look at
src/interface_driver.c, that is one network interface driver that can enumerate
all of the physical devices on a host (using netcf as the backend). *If* the
ESX SOAP API's provide something similar, then you possibly could write a new
network interface driver for ESX that used the SOAP API's on the backend. This
would be a whole new interface driver, and may require new API's (although I'm
not sure about this, since I don't know the interface driver very well).
--
Chris Lalancette
3:37 a.m.
2009/9/9 Shahar Klein <shaharklein(a)yahoo.com>:
Let me rephrase my question : )
In the current libvirt infrastructure I can do a lot of things with libvirt
and a remote ESX node
I can list all the guests
I can suspend a guest
I can get a lot of node info
and much more....
can I (for example)
1. add NIC to a guest domain
The attach/detach device driver functions aren't implemented yet, but
that's on my todo list.
2. list all the physical interfaces on a node
The VI API contains methods and types to do this. It requires a new
interface driver as Chris already said. This is not implemented yet,
but that's on my todo list.
If not - what do I need to develop
should I expand the current driver
or
should I need to develop a new interface driver(like netcf)
or
maybe I can assign the current esx driver as the interface driver and expand
it to handle the relvant requests
10x again
Shahar
The basic question is: How urgent is this for you? Do you need it now
or can you wait some time until I implemented it?
PS: I just finished the implementation of the driver function for
virDomainDefineXML(). I need to cleanup the patches a bit and will
post them by the end of the week, depends on how fast I can get done
some other urgent, university related work.
4:09 a.m.
I think I understand the mechanism of the VI API
and the way esx_vi.c is using it
the surounding is a bit more complex for me
so
can you provide the framework?
I mean
can you put in the esx_interface_driver.c and h
and the registration etc...
and also putting it all into the auto make mechanism(I should learn this sometime...)
I will put in the content into the functions
for the time being I am registering the esx_driver as the interface driver
so I can get a fill of it
something like that:
diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
index 8d1af71..677f778 100644
--- a/src/esx/esx_driver.c
+++ b/src/esx/esx_driver.c
@@ -3018,7 +3018,89 @@ esxDomainMigrateFinish(virConnectPtr dconn, const char *dname,
return esxDomainLookupByName(dconn, dname);
}
+struct interface_driver
+{
+ virMutex lock;
+};
+
+static virDrvOpenStatus esxInterfaceOpenInterface(virConnectPtr conn,
+ virConnectAuthPtr auth ATTRIBUTE_UNUSED,
+ int flags ATTRIBUTE_UNUSED)
+{
+ struct interface_driver *driverState;
+
+ if (VIR_ALLOC(driverState) < 0)
+ {
+ virReportOOMError(conn);
+ goto alloc_error;
+ }
+
+ /* initialize non-0 stuff in driverState */
+ if (virMutexInit(&driverState->lock) < 0)
+ {
+ /* what error to report? */
+ goto mutex_error;
+ }
+
+
+ conn->interfacePrivateData = driverState;
+ return 0;
+mutex_error:
+ VIR_FREE(driverState);
+alloc_error:
+ return -1;
+}
+
+static int esxInterfaceCloseInterface(virConnectPtr conn)
+{
+
+ if (conn->interfacePrivateData != NULL)
+ {
+ struct interface_driver *driver = conn->interfacePrivateData;
+ /* destroy lock */
+ virMutexDestroy(&driver->lock);
+ /* free driver state */
+ VIR_FREE(driver);
+ }
+ conn->interfacePrivateData = NULL;
+ return 0;
+}
+
+static int esxInterfaceNumOfInterfaces(virConnectPtr conn)
+{
+ int count = 7;
+ return count;
+}
+
+static virInterfaceDriver esxInterfaceDriver = {
+ "EsxInterface",
+ esxInterfaceOpenInterface, /* open */
+ esxInterfaceCloseInterface, /* close */
+ esxInterfaceNumOfInterfaces, /* numOfInterfaces */
+ NULL, /* listInterfaces */
+ NULL, /* numOfInterfaces */
+ NULL, /* listInterfaces */
+ NULL, /* interfaceLookupByName */
+ NULL, /* interfaceLookupByMACSTring */
+ NULL, /* interfaceGetXMLDesc */
+ NULL, /* interfaceDefineXML */
+ NULL, /* interfaceUndefine */
+ NULL, /* interfaceCreate */
+ NULL, /* interfaceDestroy */
+#if 0
+ esxInterfaceListInterfaces, /* listInterfaces */
+ esxInterfaceNumOfDefinedInterfaces, /* numOfInterfaces */
+ esxInterfaceListDefinedInterfaces, /* listInterfaces */
+ esxInterfaceLookupByName, /* interfaceLookupByName */
+ esxInterfaceLookupByMACString, /* interfaceLookupByMACSTring */
+ esxInterfaceGetXMLDesc, /* interfaceGetXMLDesc */
+ esxInterfaceDefineXML, /* interfaceDefineXML */
+ esxInterfaceUndefine, /* interfaceUndefine */
+ esxInterfaceCreate, /* interfaceCreate */
+ esxInterfaceDestroy, /* interfaceDestroy */
+#endif
+};
static virDriver esxDriver = {
VIR_DRV_ESX,
@@ -3096,6 +3178,7 @@ int
esxRegister(void)
{
virRegisterDriver(&esxDriver);
+ virRegisterInterfaceDriver(&esxInterfaceDriver);
return 0;
}
________________________________
From: Matthias Bolte <matthias.bolte(a)googlemail.com>
To: Shahar Klein <shaharklein(a)yahoo.com>
Cc: Chris Lalancette <clalance(a)redhat.com>; libvir-list(a)redhat.com
Sent: Wednesday, September 9, 2009 11:37:17 AM
Subject: Re: [libvirt] Interface driver and ESX support
2009/9/9 Shahar Klein <shaharklein(a)yahoo.com>:
Let me rephrase my question : )
In the current libvirt infrastructure I can do a lot of things with libvirt
and a remote ESX node
I can list all the guests
I can suspend a guest
I can get a lot of node info
and much more....
can I (for example)
1. add NIC to a guest domain
The attach/detach device driver functions aren't implemented yet, but
that's on my todo list.
2. list all the physical interfaces on a node
The VI API contains methods and types to do this. It requires a new
interface driver as Chris already said. This is not implemented yet,
but that's on my todo list.
If not - what do I need to develop
should I expand the current driver
or
should I need to develop a new interface driver(like netcf)
or
maybe I can assign the current esx driver as the interface driver and expand
it to handle the relvant requests
10x again
Shahar
The basic question is: How urgent is this for you? Do you need it now
or can you wait some time until I implemented it?
PS: I just finished the implementation of the driver function for
virDomainDefineXML(). I need to cleanup the patches a bit and will
post them by the end of the week, depends on how fast I can get done
some other urgent, university related work.
5:11 a.m.
2009/9/9 Shahar Klein <shaharklein(a)yahoo.com>:
I think I understand the mechanism of the VI API
and the way esx_vi.c is using it
the surounding is a bit more complex for me
so
can you provide the framework?
I mean
can you put in the esx_interface_driver.c and h
and the registration etc...
and also putting it all into the auto make mechanism(I should learn this
sometime...)
I will put in the content into the functions
for the time being I am registering the esx_driver as the interface driver
so I can get a fill of it
Well, if you want to give it a try, here you go.
I attached a patch that adds a basic interface driver with open and
close method. The interface driver doesn't need it's own private
driver struct, it just uses the same context already opened by the
main ESX driver.
Listing the available physical NICs should be easy. You'll need to
obtain the HostSystem object and query for its config.network.pnic
property. This is a list of PhysicalNic objects. You'll need to add a
mapping for the PhysicalNic type to the esx_vi_types.[ch]. There is
plenty of examples in the current ESX driver how to do all these
things.
Matthias
7:14 a.m.
Thank you very much : )
________________________________
From: Matthias Bolte <matthias.bolte(a)googlemail.com>
To: Shahar Klein <shaharklein(a)yahoo.com>
Cc: Chris Lalancette <clalance(a)redhat.com>; libvir-list(a)redhat.com
Sent: Wednesday, September 9, 2009 1:11:47 PM
Subject: Re: [libvirt] Interface driver and ESX support
2009/9/9 Shahar Klein <shaharklein(a)yahoo.com>:
I think I understand the mechanism of the VI API
and the way esx_vi.c is using it
the surounding is a bit more complex for me
so
can you provide the framework?
I mean
can you put in the esx_interface_driver.c and h
and the registration etc...
and also putting it all into the auto make mechanism(I should learn this
sometime...)
I will put in the content into the functions
for the time being I am registering the esx_driver as the interface driver
so I can get a fill of it
Well, if you want to give it a try, here you go.
I attached a patch that adds a basic interface driver with open and
close method. The interface driver doesn't need it's own private
driver struct, it just uses the same context already opened by the
main ESX driver.
Listing the available physical NICs should be easy. You'll need to
obtain the HostSystem object and query for its config.network.pnic
property. This is a list of PhysicalNic objects. You'll need to add a
mapping for the PhysicalNic type to the esx_vi_types.[ch]. There is
plenty of examples in the current ESX driver how to do all these
things.
Matthias
3:21 a.m.
I'm not sure what you mean about mapping
lets take the pnics as a study case for me
do I need to define a structure similar to this:
http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuid...
and also take care for it's allocation?
________________________________
From: Matthias Bolte <matthias.bolte(a)googlemail.com>
To: Shahar Klein <shaharklein(a)yahoo.com>
Cc: Chris Lalancette <clalance(a)redhat.com>; libvir-list(a)redhat.com
Sent: Wednesday, September 9, 2009 1:11:47 PM
Subject: Re: [libvirt] Interface driver and ESX support
2009/9/9 Shahar Klein <shaharklein(a)yahoo.com>:
I think I understand the mechanism of the VI API
and the way esx_vi.c is using it
the surounding is a bit more complex for me
so
can you provide the framework?
I mean
can you put in the esx_interface_driver.c and h
and the registration etc...
and also putting it all into the auto make mechanism(I should learn this
sometime...)
I will put in the content into the functions
for the time being I am registering the esx_driver as the interface driver
so I can get a fill of it
Well, if you want to give it a try, here you go.
I attached a patch that adds a basic interface driver with open and
close method. The interface driver doesn't need it's own private
driver struct, it just uses the same context already opened by the
main ESX driver.
Listing the available physical NICs should be easy. You'll need to
obtain the HostSystem object and query for its config.network.pnic
property. This is a list of PhysicalNic objects. You'll need to add a
mapping for the PhysicalNic type to the esx_vi_types.[ch]. There is
plenty of examples in the current ESX driver how to do all these
things.
Matthias
10:24 a.m.
2009/9/10 Shahar Klein <shaharklein(a)yahoo.com>:
I'm not sure what you mean about mapping
lets take the pnics as a study case for me
do I need to define a structure similar to this:
http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuid...
and also take care for it's allocation?
Yes, you need to implement the mapping (a better word may be
'binding') of this VI API type to a C type, that also includes to care
about its allocation. You'll need to implement at least this set of
function in esx_vi_types.[ch]:
esxVI_PhysicalNic_Alloc()
esxVI_PhysicalNic_Free()
esxVI_PhysicalNic_CastFromAnyType()
esxVI_PhysicalNic_CastListFromAnyType()
esxVI_PhysicalNic_Deserialize()
esxVI_PhysicalNic_DeserializeList()
You could use the binding for the HostCpuIdInfo type, but
unfortunately I haven't published the code for it yet. This code also
includes some essential helper functions for
esxVI_PhysicalNic_CastListFromAnyType().
Beside the PhysicalNic type, you may also have to bind the types of
its members like PhysicalNicLinkInfo, PhysicalNicSpec and
HostIpConfig, if you need or care about the information provided by
them.
The binding for HostCpuIdInfo is part of a larger set of patches that
add some new features to ESX driver, but the patches needs some
cleanup first. I may have some time later this evening to clean them
up and post them.
PS: You should refer to version 2.5 of the VI API [1] and not 4.0,
because the complete VI API mapping is currently based on version 2.5.
At some point I'll have to properly distinguish between version 2.5
and 4.0, but currently I would like to stick to version 2.5 only.
[1] http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/
Matthias
8:23 a.m.
I've defined (among others):
int esxVI_PhysicalNic_CastListFromAnyType(virConnectPtr conn, esxVI_AnyType *anyType,
esxVI_PhysicalNic **pNicList);
but runing it returns somthing like:
Expecting type 'PhysicalNic' but found 'ArrayOfPhysicalNic'
Does it mean I should also implement:
esxVI_ArrayOfPhysicalNic_CastListFromAnyType()
and all the funcs/type definition coming with it?
thanks
Shahar
________________________________
From: Matthias Bolte <matthias.bolte(a)googlemail.com>
To: Shahar Klein <shaharklein(a)yahoo.com>
Cc: libvir-list(a)redhat.com
Sent: Thursday, September 10, 2009 6:24:25 PM
Subject: Re: [libvirt] Interface driver and ESX support
2009/9/10 Shahar Klein <shaharklein(a)yahoo.com>:
I'm not sure what you mean about mapping
lets take the pnics as a study case for me
do I need to define a structure similar to this:
http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuid...
and also take care for it's allocation?
Yes, you need to implement the mapping (a better word may be
'binding') of this VI API type to a C type, that also includes to care
about its allocation. You'll need to implement at least this set of
function in esx_vi_types.[ch]:
esxVI_PhysicalNic_Alloc()
esxVI_PhysicalNic_Free()
esxVI_PhysicalNic_CastFromAnyType()
esxVI_PhysicalNic_CastListFromAnyType()
esxVI_PhysicalNic_Deserialize()
esxVI_PhysicalNic_DeserializeList()
You could use the binding for the HostCpuIdInfo type, but
unfortunately I haven't published the code for it yet. This code also
includes some essential helper functions for
esxVI_PhysicalNic_CastListFromAnyType().
Beside the PhysicalNic type, you may also have to bind the types of
its members like PhysicalNicLinkInfo, PhysicalNicSpec and
HostIpConfig, if you need or care about the information provided by
them.
The binding for HostCpuIdInfo is part of a larger set of patches that
add some new features to ESX driver, but the patches needs some
cleanup first. I may have some time later this evening to clean them
up and post them.
PS: You should refer to version 2.5 of the VI API [1] and not 4.0,
because the complete VI API mapping is currently based on version 2.5.
At some point I'll have to properly distinguish between version 2.5
and 4.0, but currently I would like to stick to version 2.5 only.
[1] http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/
Matthias
8:39 a.m.
No, as I said before you should wait until you can use the unpublished
binding of HostCpuIdInfo as an example. This also includes the code to
handle ArrayOf* types. I'm currently cleaning up this patches (didn't
have time on thursday for that) and will post them today, just wait
for this patches, because they will help you.
Matthias
2009/9/13 Shahar Klein <shaharklein(a)yahoo.com>:
I've defined (among others):
int esxVI_PhysicalNic_CastListFromAnyType(virConnectPtr conn, esxVI_AnyType
*anyType, esxVI_PhysicalNic **pNicList);
but runing it returns somthing like:
Expecting type 'PhysicalNic' but found 'ArrayOfPhysicalNic'
Does it mean I should also implement:
esxVI_ArrayOfPhysicalNic_CastListFromAnyType()
and all the funcs/type definition coming with it?
thanks
Shahar
________________________________
From: Matthias Bolte <matthias.bolte(a)googlemail.com>
To: Shahar Klein <shaharklein(a)yahoo.com>
Cc: libvir-list(a)redhat.com
Sent: Thursday, September 10, 2009 6:24:25 PM
Subject: Re: [libvirt] Interface driver and ESX support
2009/9/10 Shahar Klein <shaharklein(a)yahoo.com>:
> I'm not sure what you mean about mapping
> lets take the pnics as a study case for me
> do I need to define a structure similar to this:
>
>
http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuid...
> and also take care for it's allocation?
>
Yes, you need to implement the mapping (a better word may be
'binding') of this VI API type to a C type, that also includes to care
about its allocation. You'll need to implement at least this set of
function in esx_vi_types.[ch]:
esxVI_PhysicalNic_Alloc()
esxVI_PhysicalNic_Free()
esxVI_PhysicalNic_CastFromAnyType()
esxVI_PhysicalNic_CastListFromAnyType()
esxVI_PhysicalNic_Deserialize()
esxVI_PhysicalNic_DeserializeList()
You could use the binding for the HostCpuIdInfo type, but
unfortunately I haven't published the code for it yet. This code also
includes some essential helper functions for
esxVI_PhysicalNic_CastListFromAnyType().
Beside the PhysicalNic type, you may also have to bind the types of
its members like PhysicalNicLinkInfo, PhysicalNicSpec and
HostIpConfig, if you need or care about the information provided by
them.
The binding for HostCpuIdInfo is part of a larger set of patches that
add some new features to ESX driver, but the patches needs some
cleanup first. I may have some time later this evening to clean them
up and post them.
PS: You should refer to version 2.5 of the VI API [1] and not 4.0,
because the complete VI API mapping is currently based on version 2.5.
At some point I'll have to properly distinguish between version 2.5
and 4.0, but currently I would like to stick to version 2.5 only.
[1]
http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/
Matthias
5549
days inactive
5554
days old
14 comments
4 participants
participants (4)
-
Chris Lalancette -
Daniel Veillard -
Matthias Bolte -
Shahar Klein