Re: [libvirt] Interface driver and ESX support
by Matthias Bolte
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(a)yahoo.com>:
> I see
> You are making my (coding) life easier : )
> thanks
> ________________________________
> From: Matthias Bolte <matthias.bolte(a)googlemail.com>
> To: Shahar Klein <shaharklein(a)yahoo.com>
> Cc: libvir-list(a)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(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
>>
>>
>
>
15 years, 2 months
[libvirt] [PATCH 0/4] Changes to API/ABI for secrets handling
by Daniel P. Berrange
This series makes two changes to the public API and wire protocol ABI
for the secrets handling support recently committed. As such this is
a must fix before we do the release, since we can't break compatability
once released.
The first patch changes all the code to store UUIDs in raw format
instead of printable format. This is important because it ensures
that e3a9758f-b0c6-7a3a-ebb9-71a69c930289 is treated exactly the
same as e3a9758fb0c67a3aebb971a69c930289, which is not the case
with the currently committed code. It also makes the secrets and
storage encryption XML parsers use the internal UUID handling APIs
The second patch adds a new unique property to virSecretPtr. The
"owner ID" is intended to be unique on a host wrt all secrets with
matching usage type. This entails adding 2 APIs to querying the usage
type, and another API to lookup a secret based on its usage. In
testing the current code I frequently found myself getting into the
situation where there were many secrets for the same volume which was
not at all good. So if defining a secret to be used with a storage
volume this ensures that you only ever have one secret associated with
each storage volume path.
The third patch ensures that when you query the XML for a qcow
encrypted voluem, it will include the UUID of the secret. Previously
if you created a volume, and then restarted libvirtd, the secret
UUID would be lost. This patch is why we need the new API from
the second patch virLookupSecretByUsage - without that it would
be impossible to lookup the secret efficiently.
THe final patch is a minor tweak to the RNG
15 years, 2 months
[libvirt] [PATCH] Fix win32 platform build
by Daniel P. Berrange
* configure.in: Only define WITH_SECRETS if libvirtd is present
* src/Makefile.am: Only build secrets driver if WITH_SECRETS is
defined. Always add SECRET_DRIVER_SOURCES to EXTRA_DIST
---
configure.in | 11 +++++++++++
src/Makefile.am | 3 +++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/configure.in b/configure.in
index 120f7e7..fad1297 100644
--- a/configure.in
+++ b/configure.in
@@ -1062,6 +1062,17 @@ AM_CONDITIONAL([WITH_NETCF], [test "$with_netcf" = "yes"])
AC_SUBST([NETCF_CFLAGS])
AC_SUBST([NETCF_LIBS])
+
+with_secrets=yes
+if test "$with_libvirtd" = "no"; then
+ with_secrets=no
+fi
+if test "$with_secrets" = "yes" ; then
+ AC_DEFINE_UNQUOTED([WITH_SECRETS], 1, [whether local secrets management driver is available])
+fi
+AM_CONDITIONAL([WITH_SECRETS], [test "$with_secrets" = "yes"])
+
+
AC_ARG_WITH([storage-fs],
[ --with-storage-fs with FileSystem backend for the storage driver (on)],[],[with_storage_fs=check])
AC_ARG_WITH([storage-lvm],
diff --git a/src/Makefile.am b/src/Makefile.am
index 14a3a63..69f5ee7 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -461,6 +461,7 @@ endif
libvirt_driver_interface_la_SOURCES = $(INTERFACE_DRIVER_SOURCES)
endif
+if WITH_SECRETS
if WITH_DRIVER_MODULES
mod_LTLIBRARIES += libvirt_driver_secret.la
else
@@ -471,6 +472,7 @@ if WITH_DRIVER_MODULES
libvirt_driver_secret_la_LDFLAGS = -module -avoid-version
endif
libvirt_driver_secret_la_SOURCES = $(SECRET_DRIVER_SOURCES)
+endif
# Needed to keep automake quiet about conditionals
libvirt_driver_storage_la_SOURCES =
@@ -574,6 +576,7 @@ EXTRA_DIST += \
$(NODE_DEVICE_DRIVER_HAL_SOURCES) \
$(NODE_DEVICE_DRIVER_DEVKIT_SOURCES) \
$(SECURITY_DRIVER_SELINUX_SOURCES) \
+ $(SECRET_DRIVER_SOURCES) \
$(VBOX_DRIVER_EXTRA_DIST)
#
--
1.6.2.5
15 years, 2 months
