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@googlemail.com>
To: Shahar Klein <shaharklein@yahoo.com>
Cc: libvir-list@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@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/ReferenceGuide/vim.host.PhysicalNic.html
> 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