[libvirt] Interface driver and ESX support

[Shahar Klein]

Thanks Matthias

works great : )



________________________________
From: Matthias Bolte <matthias.bolte at googlemail.com>
To: Shahar Klein <shaharklein at yahoo.com>
Cc: libvir-list at redhat.com
Sent: Monday, September 14, 2009 3:57:52 AM
Subject: Re: [libvirt] Interface driver and ESX support

Okay, I finally got the patches cleaned up.

I just posted this 12 patches series to the mailing list. Apply them
all to an up to date git clone and apply the attached, updated ESX
interface driver stub patch in the end.

Patch 6 of 12 adds the binding for HostCpuIdInfo and contains the
functions to handle ArrayOf* types.

Matthias

2009/9/13 Shahar Klein <shaharklein at yahoo.com>:
> I see
> You are making my (coding) life easier : )
> thanks
> ________________________________
> From: Matthias Bolte <matthias.bolte at googlemail.com>
> To: Shahar Klein <shaharklein at yahoo.com>
> Cc: libvir-list at redhat.com
> Sent: Sunday, September 13, 2009 4:39:22 PM
> Subject: Re: [libvirt] Interface driver and ESX support
>
> 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 at 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 at googlemail.com>
>> To: Shahar Klein <shaharklein at yahoo.com>
>> Cc: libvir-list at 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 at 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
>>
>>
>
>



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20090914/980f300a/attachment-0001.htm>