Re: [libvirt] FW: [PATCH 1/4] Addition of XenAPI support to libvirt
On Fri, Feb 19, 2010 at 11:33:36AM +0000, Sharadha Prabhakar (3P) wrote:
thanks for the patch, just started to look at it.
I assume that by libxenserver you mean the code to be added under src in a following patch, right ?
-> libxenserver is a library which provides APIs for performing various Operations on the hypervisor. You can download it from http://community.citrix.com/download/attachments/38633496/libxenserver-5.5.0... libxenserver folder should be in the same directory level of libvirt.
Sorry that's not possible. Either the code is in libvirt, and in that case it doesn't have to be downloaded, but part of the patch submission (and managed on this list) , or it's a new external dependancy and it's availability must be checked by configure.ac. If we add a new dependancy, it must also be checked for Licence compatibility. So far we have always refused to use a third party library to access the hypervisor itself, libvirt(d) talking directly to the hypervisor components or launching it directly. For example we don't rely on the VMWare libraries to talk to ESX.
[...]
+endif +#libvirt_driver_xenapi_la_LIBADD = $(XENAPI_LIBS) +libvirt_driver_xenapi_la_CFLAGS = $(XEN_CFLAGS) \ + $(shell xml2-config --cflags) \ + $(shell curl-config --cflags) +libvirt_driver_xenapi_la_LDFLAGS = -L@top_srcdir@/../libxenserver/ -lxenserver -g $(shell xml2-config --libs) \ + $(shell curl-config --libs)
Hum, libxml2 is already fully detected in configure.ac, use the LIBXML_* variables instead of trying to exec xml2-config.
-> I've added the LIBXML_ flags in Makefile.am and posted the patch.
okay, we will review this, but note that we start the feature freeze for 0.7.7 this week-end, so next week is more likely to be focused on bug fixes for already commited features.
Similary libcurl i looked at in configure.ac for ESX, this need to be modified to be checked more generally and the LIBCURL_* variables need to be used here too.
-> I didn't quite understand the libcurl part you mentioned. I too noticed that ESX has a piece of code in configure.ac to set the libcurl flags, do you want me to do add a similar bit of code in configure.ac for XenAPI that defines LIBCURL flags and then add in my Makefile.am?
the code to look for libcurl in configure.ac is currently only activated if esx support is on. It must be run if either esx or xen-api are selected, the ESX portion need to be modified accordingly, and your parts and Makefiles patches too. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Fri, Feb 19, 2010 at 03:56:56PM +0100, Daniel Veillard wrote:
Similary libcurl i looked at in configure.ac for ESX, this need to be modified to be checked more generally and the LIBCURL_* variables need to be used here too.
-> I didn't quite understand the libcurl part you mentioned. I too noticed that ESX has a piece of code in configure.ac to set the libcurl flags, do you want me to do add a similar bit of code in configure.ac for XenAPI that defines LIBCURL flags and then add in my Makefile.am?
the code to look for libcurl in configure.ac is currently only activated if esx support is on. It must be run if either esx or xen-api are selected, the ESX portion need to be modified accordingly, and your parts and Makefiles patches too.
Hmm.. is XenAPI the correct name? At least earlier it was used to refer to the xend stuff in the traditional Xen. 'XAPI' name has been used for the newer XenServer/XCP xapi/xe stuff? Or am I confused here? -- Pasi
On Tue, Mar 23, 2010 at 12:43:09PM +0000, Pasi Kärkkäinen wrote:
On Fri, Feb 19, 2010 at 03:56:56PM +0100, Daniel Veillard wrote:
Similary libcurl i looked at in configure.ac for ESX, this need to be modified to be checked more generally and the LIBCURL_* variables need to be used here too.
-> I didn't quite understand the libcurl part you mentioned. I too noticed that ESX has a piece of code in configure.ac to set the libcurl flags, do you want me to do add a similar bit of code in configure.ac for XenAPI that defines LIBCURL flags and then add in my Makefile.am?
the code to look for libcurl in configure.ac is currently only activated if esx support is on. It must be run if either esx or xen-api are selected, the ESX portion need to be modified accordingly, and your parts and Makefiles patches too.
Hmm.. is XenAPI the correct name? At least earlier it was used to refer to the xend stuff in the traditional Xen.
'XAPI' name has been used for the newer XenServer/XCP xapi/xe stuff?
xapi is the name of the daemon in XenServer/XCP. The API itself is called XenAPI, and yes, there is a implementation in xend too. XenAPI is the correct name, because it's the API that we're meeting, not a specific implementation of it. Ewan.
On Tue, Mar 23, 2010 at 01:21:55PM +0000, Ewan Mellor wrote:
On Tue, Mar 23, 2010 at 12:43:09PM +0000, Pasi Kärkkäinen wrote:
On Fri, Feb 19, 2010 at 03:56:56PM +0100, Daniel Veillard wrote:
Similary libcurl i looked at in configure.ac for ESX, this need to be modified to be checked more generally and the LIBCURL_* variables need to be used here too.
-> I didn't quite understand the libcurl part you mentioned. I too noticed that ESX has a piece of code in configure.ac to set the libcurl flags, do you want me to do add a similar bit of code in configure.ac for XenAPI that defines LIBCURL flags and then add in my Makefile.am?
the code to look for libcurl in configure.ac is currently only activated if esx support is on. It must be run if either esx or xen-api are selected, the ESX portion need to be modified accordingly, and your parts and Makefiles patches too.
Hmm.. is XenAPI the correct name? At least earlier it was used to refer to the xend stuff in the traditional Xen.
'XAPI' name has been used for the newer XenServer/XCP xapi/xe stuff?
xapi is the name of the daemon in XenServer/XCP. The API itself is called XenAPI, and yes, there is a implementation in xend too. XenAPI is the correct name, because it's the API that we're meeting, not a specific implementation of it.
Thanks for clearing that up! -- Pasi
participants (3)
-
Daniel Veillard -
Ewan Mellor -
Pasi Kärkkäinen