September 2009 - Devel - Libvirt List Archives

[libvirt] ANNOUNCE: perl bindings Sys-Virt release 0.2.2

by Daniel P. Berrange

FYI I have just uploaded a new release 0.2.2 of the libvirt perl bindings, Sys-Virt, to CPAN. http://search.cpan.org/dist/Sys-Virt/ Direct download link http://search.cpan.org/CPAN/authors/id/D/DA/DANBERR/Sys-Virt-0.2.2.tar.gz Changes since 0.2.1: - Add all new APIs upto libvirt 0.7.0 APIs (listing defined network interfaces) - Add missing APIs for looking up storage volumes based on path and key - Fix lookup of network interfaces based on MAC address - Add missing APIs for defining network interfaces and starting defined interfaces There will of course shortly be another release to cover the soon to be released APIs in libvirt 0.7.1 Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

15 years, 6 months

1
0
0 / 0

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, 6 months

3
3
0 / 0

[libvirt] [PATCH]: Bug when you try to start machines made will older VBox versions

by Pritesh Kothari

Hi All, Thanks to Florian, who pointed out the bug, due to which you can't start domains defined with older builds or with empty "FRONTEND/Type" tag in their xml files. Fixed it in the following patch. Regards, Pritesh

15 years, 6 months

2
1
0 / 0

[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, 6 months

3
13
0 / 0

[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, 6 months

2
1
0 / 0

[libvirt] ESX [07/12]: Whitespace cleanup

by Matthias Bolte

Subject says it all.

15 years, 6 months

2
1
0 / 0

[libvirt] ESX [05/12]: Also strip (C) and (TM) from the CPU model string

by Matthias Bolte

* src/esx/esx_driver.c: also strip (C) and (TM) from the CPU model string

15 years, 6 months

2
1
0 / 0

[libvirt] ESX [11/12]: Reorder some function calls to avoid potential virDomainPtr leaks

by Matthias Bolte

* src/esx/esx_driver.c: avoid potential virDomainPtr leaks

15 years, 6 months

2
1
0 / 0

[libvirt] [PATCH]: API Change patch for VBox 3.0.6

by Pritesh Kothari

Hi All, VirtualBox 3.0.6 was released few days ago and there were some minor API changes in it. I have created a patch for the same and posting it here. Regards, Pritesh

15 years, 6 months

2
1
0 / 0

[libvirt] ESX [12/12]: Remove phantom mode

by Matthias Bolte

* src/esx/esx_driver.c: remove phantom mode

15 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Devel September 2009