[libvirt] Libvirt - Xen Enterprise - Koan
Hi I hope me "replying" this way does not break anyone's mail sorting, I only now subscribed to the list.
Thanks for this - this sounds like the most likely issue. The problem is that Citrix seems to move things around somewhat as that config file does not exist. There is a xensource directory that contains the following but other than that i am a bit stuck.
They might have overriden the config file to point somewhere else. Try and find the file "XendOptions.py" and see where it loads the config from. Or see if anything sets $XEND_CONFIG env variable at startup. In regular upstream xen code, it XendOptions.py has: class XendOptionsFile(XendOptions): """Default path to the config file.""" config_default = "/etc/xen/xend-config.sxp" I did a find . -name *.py > temp.gg and then 141 cat temp.gg | xargs grep -i xendoptions 142 cat temp.gg | xargs grep -i xend 144 cat temp.gg | xargs grep -i XEND_CONFIG 148 cat temp.gg | xargs grep -i config_default All of these searches gave me absolutely no results. I am sure that the config files are in : /etc/xensource/ xapi.conf xapi-ssl.conf the contents of xapi.conf is: schema_filename = /etc/xensource/db_schema.sql license_filename = /etc/xensource/license http-port = 80 use-ssl = true ssl-cert = /etc/ssl/certs/xensource-rio.pem ssl-port = 443 # dom0-mem = 128 and of xapi-ssl.conf is: pid = /var/run/xapi.ssl.pid socket = r:TCP_NODELAY=1 socket = a:TCP_NODELAY=1 socket = l:TCP_NODELAY=1 [xapi] accept = 443 connect = 80 cert = /etc/xensource/xapi-ssl.pem I am thinking that maybe only ssl connections are allowed ... which is why virsh can't connect? we are running "XenServer release 4.1.0-7843p (xenenterprise)" and I am trying to get spacewalk to get the necessary domain details when registering a xen host. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
There's an assumption that XenEnterprise actually uses xend. Is that the case? ('ps' might tell you) dme. -- David Edmondson, Sun Microsystems, http://dme.org
No it does not use xend.
-----Original Message----- From: David Edmondson [mailto:dme@dme.org] On Behalf Of David Edmondson Sent: 06 January 2009 11:53 To: Gerhardus Geldenhuis (GTA-LON) Cc: libvir-list@redhat.com Subject: Re: Libvirt - Xen Enterprise - Koan
There's an assumption that XenEnterprise actually uses xend. Is that the case? ('ps' might tell you)
dme. -- David Edmondson, Sun Microsystems, http://dme.org
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On Tue, Jan 06, 2009 at 11:57:34AM -0000, Gerhardus.Geldenhuis@gta-travel.com wrote:
No it does not use xend.
That's pretty much game over then. Someone will have to write a new libvirt driver specifically for XenEnterprise to get it to work. 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 :|
Daniel P. Berrange wrote:
On Tue, Jan 06, 2009 at 11:57:34AM -0000, Gerhardus.Geldenhuis@gta-travel.com wrote:
No it does not use xend.
# ps auxwww | grep xen root 21 0.0 0.0 0 0 ? S< 2008 0:00 [xenwatch] root 22 0.0 0.0 0 0 ? S< 2008 0:00 [xenbus] root 5240 0.0 0.1 2076 908 ? S 2008 0:00 /usr/sbin/xenstored root 5243 0.0 0.0 12232 532 ? Sl 2008 0:00 /usr/sbin/xenconsoled root 5254 0.0 0.0 2608 444 ? S 2008 0:00 /opt/xensource/libexec/cdrommon /dev/xapi/cd/hda root 5269 0.0 0.4 19156 3800 ? S< 2008 0:00 /opt/xensource/bin/xapi -daemon -writereadyfile /var/run/xapi_startup.cookie -writeinitcomplete /var/run/xapi_init_complete.cookie -onsystemboot root 5271 0.0 1.3 178612 10056 ? S<l 2008 1:00 /opt/xensource/bin/xapi -daemon -writereadyfile /var/run/xapi_startup.cookie -writeinitcomplete /var/run/xapi_init_complete.cookie -onsystemboot root 5561 0.0 0.4 21580 3720 ? Sl 2008 0:00 python /opt/xensource/sm/snapwatchd/snapwatchd -d /var/log/SMlog root 6181 0.0 0.7 12380 5592 ? Ss 2008 1:19 python /opt/xensource/bin/perfmon --daemon root 6405 0.0 0.1 4756 1524 ? Ss 2008 0:00 /usr/lib/xen/bin/vncterm -v 127.0.0.1 -r -x /local/domain/0/serial/0 -c /usr/lib/xen/bin/dom0term.sh root 10301 0.0 0.1 2424 1024 pts/0 Ss+ Jan05 0:00 /bin/bash /usr/lib/xen/bin/dom0term.sh
That's pretty much game over then. Someone will have to write a new libvirt driver specifically for XenEnterprise to get it to work.
damn - that really scuppers me trying to forge ahead with the cobbler route as XenEnterprise will be around here for a while much to my annoyance. Is that really it ?
Damm, Well at least a conclusive answer. I am assuming it would be relatively big undertaking to write a new driver? Regards
-----Original Message----- From: libvir-list-bounces@redhat.com [mailto:libvir-list- bounces@redhat.com] On Behalf Of Daniel P. Berrange Sent: 06 January 2009 12:00 To: Gerhardus Geldenhuis (GTA-LON) Cc: libvir-list@redhat.com Subject: Re: [libvirt] RE: Libvirt - Xen Enterprise - Koan
On Tue, Jan 06, 2009 at 11:57:34AM -0000, Gerhardus.Geldenhuis@gta- travel.com wrote:
No it does not use xend.
That's pretty much game over then. Someone will have to write a new libvirt driver specifically for XenEnterprise to get it to work.
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 :|
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On Tue, Jan 06, 2009 at 12:08:14PM -0000, Gerhardus.Geldenhuis@gta-travel.com wrote:
Damm, Well at least a conclusive answer. I am assuming it would be relatively big undertaking to write a new driver?
No idea, look at other drivers, some are simple enough, others are more complex. But basically since it's not open-source the amount of interested people will shink, there is also the problem of connecting libvirt and the XenE management depending on the Licencing terms of their own stack. It's not game over, but it sounds like restarting from scratch... 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/
Daniel Veillard wrote:
On Tue, Jan 06, 2009 at 12:08:14PM -0000, Gerhardus.Geldenhuis@gta-travel.com wrote:
Damm, Well at least a conclusive answer. I am assuming it would be relatively big undertaking to write a new driver?
No idea, look at other drivers, some are simple enough, others are more complex. But basically since it's not open-source the amount of interested people will shink, there is also the problem of connecting libvirt and the XenE management depending on the Licencing terms of their own stack. It's not game over, but it sounds like restarting from scratch...
Daniel
Ouch, no xend? Another option is for someone to add another additional virt-type to koan and install it "some other way" (wrap xm create?), but I agree, if it's not open source it's not that interesting for many of us to work on, so it runs the risk of going unmaintained unless you'd want to own it. (We do some of that for VMware already -- see koan's source tree for details) --Michael
Hello, Just one question. How about using XenAPI for XenEnterprise? I am not familiar with XenEnterprise. But It should have some API for a developer. Thanks Atsushi SAKAI Daniel Veillard <veillard@redhat.com> wrote:
On Tue, Jan 06, 2009 at 12:08:14PM -0000, Gerhardus.Geldenhuis@gta-travel.com wrote:
Damm, Well at least a conclusive answer. I am assuming it would be relatively big undertaking to write a new driver?
No idea, look at other drivers, some are simple enough, others are more complex. But basically since it's not open-source the amount of interested people will shink, there is also the problem of connecting libvirt and the XenE management depending on the Licencing terms of their own stack. It's not game over, but it sounds like restarting from scratch...
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/
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Jan 07, 2009 at 09:55:18AM +0900, Atsushi SAKAI wrote:
Hello,
Just one question. How about using XenAPI for XenEnterprise? I am not familiar with XenEnterprise. But It should have some API for a developer.
Well the public XenAPI list seems mostly dead but there are reports of incompatibilities between their proprietary and old open sounce versions. Check the archives, it doesn't look good. 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/
Daniel Veillard wrote:
Well the public XenAPI list seems mostly dead but there are reports of incompatibilities between their proprietary and old open sounce versions. Check the archives, it doesn't look good.
nope - not good at all - and the really annoying thing is that its quite likely that in > 6months from now we'd not be using XenEnterprise but in the meantime i have to try to come up with something that just works. Alas it seems thats not going to be possible.
We should really as customers demand better integration/support. I have started enquiring about this but am not too hopefull about my requests being heard/listened to. Regards
-----Original Message----- From: Tom Brown [mailto:tom@ng23.net] Sent: 07 January 2009 12:36 To: veillard@redhat.com Cc: Atsushi SAKAI; libvir-list@redhat.com; Gerhardus Geldenhuis (GTA- LON) Subject: Re: [libvirt] RE: Libvirt - Xen Enterprise - Koan
Daniel Veillard wrote:
Well the public XenAPI list seems mostly dead but there are reports of incompatibilities between their proprietary and old open sounce versions. Check the archives, it doesn't look good.
nope - not good at all - and the really annoying thing is that its quite likely that in > 6months from now we'd not be using XenEnterprise but in the meantime i have to try to come up with something that just works. Alas it seems thats not going to be possible.
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
We should really as customers demand better integration/support. I have started enquiring about this but am not too hopefull about my requests being heard/listened to.
Quite true - as from my POV forcing the customer to use a single product for provisioning as well as virtualization makes that product less desirable. I dont want to feel locked in.
Hi I have managed to make some noise with our supplier... if there is any positive results I will let you know. Regards
-----Original Message----- From: Tom Brown [mailto:tom@ng23.net] Sent: 07 January 2009 13:04 To: Gerhardus Geldenhuis (GTA-LON) Cc: libvir-list@redhat.com Subject: Re: [libvirt] RE: Libvirt - Xen Enterprise - Koan
We should really as customers demand better integration/support. I have started enquiring about this but am not too hopefull about my requests being heard/listened to.
Quite true - as from my POV forcing the customer to use a single product for provisioning as well as virtualization makes that product less desirable. I dont want to feel locked in.
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
FYI - The XenAPI has some similarities with XenEnterprise's API - but they forked away from the open source model a while ago. I agree with you that the XenAPI list is mostly dead. I haven't seem anyone contributing to it in a while... Daniel Veillard wrote on 01/07/2009 07:20 AM:
On Wed, Jan 07, 2009 at 09:55:18AM +0900, Atsushi SAKAI wrote:
Hello,
Just one question. How about using XenAPI for XenEnterprise? I am not familiar with XenEnterprise. But It should have some API for a developer.
Well the public XenAPI list seems mostly dead but there are reports of incompatibilities between their proprietary and old open sounce versions. Check the archives, it doesn't look good.
Daniel
Hi Here is a response we received from Citrix: Please see below the reply I had from one of the XenServer Systems Engineers: Back in November we released a number SDKs to interface with our existing and feature rich XAPI. We have a number of customers and partners using this API for the management of their virtual infrastructures. Forgive my ignorance but I have never heard of the libvirt library which is not even part of the VMAN DMTF which is meant to be an industry standard. http://www.dmtf.org/standards/mgmt/vman/. Is libvirt a more of a Redhat focused initiative and is the customer asking this question focused on Linux and Windows or just Linux? The completion of the XenServer 5.0 SDK Refresh project, culminating in a release-to-web of * A completely new PowerShell snap-in for XenServer (XS-PS). This is a one-to-one exposure of the existing XenServer API as PowerShell cmdlets, exposing the complete XenServer API to PowerShell users for the first time. * libxenserver: The XenServer C SDK * XenServer.NET: The XenServer C#.NET SDK * XenServerJava: The XenServer Java SDK * XenAPI.py: The XenServer Python module * Tidied-up versions of the XenServer API Javadoc and PDF. All this can be downloaded from CDN at http://community.citrix.com/display/xs/Download+SDKs I will drop a line to one of our engineers that leads the development of the SDK tools for the XenServer API and see what comes back. Please encourage your customer to check out the enclosed link to the XenServer SDKs and provide some feedback. Please let me know if this helps in any way. Regards, From: Ben Guthro [mailto:bguthro@virtualiron.com] Sent: 07 January 2009 20:39 To: veillard@redhat.com Cc: Atsushi SAKAI; libvir-list@redhat.com; Gerhardus Geldenhuis (GTA-LON) Subject: Re: [libvirt] RE: Libvirt - Xen Enterprise - Koan FYI - The XenAPI has some similarities with XenEnterprise's API - but they forked away from the open source model a while ago. I agree with you that the XenAPI list is mostly dead. I haven't seem anyone contributing to it in a while... Daniel Veillard wrote on 01/07/2009 07:20 AM: On Wed, Jan 07, 2009 at 09:55:18AM +0900, Atsushi SAKAI wrote: Hello, Just one question. How about using XenAPI for XenEnterprise? I am not familiar with XenEnterprise. But It should have some API for a developer. Well the public XenAPI list seems mostly dead but there are reports of incompatibilities between their proprietary and old open sounce versions. Check the archives, it doesn't look good. Daniel ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
One more response: I have just had this response from Citrix XS engineering in the US: "libvirt is Red Hat's offering and although the original query states that "unfortunately the Citrix implementation has departed from the standard" Red Hat are the ones who wrote the standard in the first place. What's actually happened is the open-source Xen toolstack has fallen behind the Xen-API work, because no-one's putting anything into OSS at that level in the stack now (possibly with the exception of Red Hat). To my knowledge there is no effort ongoing to make a libvirt-Citrix driver, though such a thing wouldn't be hard. The SDKs that you've already referred to are the right place to start. In general, libvirt is basically a "lowest common denominator" library -- it will let you talk to multiple virtualization platforms with the same API. If you want to do that, great, but the downside is always that you lose functionality on the way. If the customer wants to use this Red Hat product, then writing a libvirt-Citrix driver would be fine (and they are free to open-source it too). On the other hand, if they're starting more or less from scratch (and the version number "0.3" suggests that), then you're going to get a much tighter integration if you use our SDKs directly, and the result will be significantly better." ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On Thu, Jan 08, 2009 at 01:11:27PM -0000, Gerhardus.Geldenhuis@gta-travel.com wrote:
One more response:
I have just had this response from Citrix XS engineering in the US:
What's actually happened is the open-source Xen toolstack has fallen behind the Xen-API work, because no-one's putting anything into OSS at that level in the stack now (possibly with the exception of Red Hat).
Sad but true - there's basically no active development on the open source Xen userspace anymore - watching xen-devel the only active work is on the hypervisor itself, and the upstream Linux kernel merge.
In general, libvirt is basically a "lowest common denominator" library -- it will let you talk to multiple virtualization platforms with the same API. If you want to do that, great, but the downside is always that you lose functionality on the way.
Just to reassure people this is *not* true. libvirt does NOT force you to the 'lowest common denominator'. Our goal is to provide a consistent representation of configuration & a consistent API across all hypervisors. We are more than happy to implement features that are only present in particular hypervisors - the only point is to make sure they have a generic representation. This is the same goal of the DMTF/CIM virtualization schema too. Neither is forcing you to the lowest common denominator, merely a common representation.
If the customer wants to use this Red Hat product, then writing a libvirt-Citrix driver would be fine (and they are free to open-source it too).
We would welcome & support anyone wishing to implement a new driver for libvirt that can talk to the XenEnterprise API / SDK. Writing new drivers for libvirt is much easier than it usde to be, since we have lots of generic infrastructure for handling XML formatting/parsing. There is no requirement that you implement all the public APIs at once - its is perfectly feasible to only write a small subset of public libvirt APIs in a new driver. For the purposes of the original question in thsi thread - Koan support - there would be few APIs required - ability to list VMs, get host information / capabilities, and create new VMs.
On the other hand, if they're starting more or less from scratch (and the version number "0.3" suggests that), then you're going to get a much tighter integration if you use our SDKs directly, and the result will be significantly better."
And nicely locked into the Xen specific API, making it very hard for you to switch hypevisor vendors in the future. Of course that is entirely what proprietry software vendors in general like :-) 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 :|
On Thu, Jan 08, 2009 at 12:53:51PM -0000, Gerhardus.Geldenhuis@gta-travel.com wrote:
* libxenserver: The XenServer C SDK [..] All this can be downloaded from CDN at http://community.citrix.com/display/xs/Download+SDKs
I took a look at the C library: * It's LGPLv2+, so there is no license issue that I can see with linking it to libvirt. * It presents each XenServer API call as a C function. Each C function constructs an XML document (XMLRPC, I think), dispatches it to the server, gets the reply, and unpacks the resulting XML. * Uses libxml2 to do the XML construction and parsing. * You have to supply your own HTTP library to pass the data to the server. The examples use libcurl for this. * Compiles with -Wall -Werror without warnings or errors. It seems reasonably sensible. It still requires the proprietary XenEnterprise to be installed for testing of course. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
On Fri, Jan 09, 2009 at 03:18:36PM +0000, Richard W.M. Jones wrote:
On Thu, Jan 08, 2009 at 12:53:51PM -0000, Gerhardus.Geldenhuis@gta-travel.com wrote:
* libxenserver: The XenServer C SDK [..] All this can be downloaded from CDN at http://community.citrix.com/display/xs/Download+SDKs
I took a look at the C library:
* It's LGPLv2+, so there is no license issue that I can see with linking it to libvirt.
* It presents each XenServer API call as a C function. Each C function constructs an XML document (XMLRPC, I think), dispatches it to the server, gets the reply, and unpacks the resulting XML.
* Uses libxml2 to do the XML construction and parsing.
* You have to supply your own HTTP library to pass the data to the server. The examples use libcurl for this.
* Compiles with -Wall -Werror without warnings or errors.
It seems reasonably sensible. It still requires the proprietary XenEnterprise to be installed for testing of course.
It is possible that it might work with the XenAPI impl in the open source XenD too - worth a try if you want to develop something 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 :|
One thing to know about the open source xend XenAPI - it does not come configured by default. you must enable it in the xend_config.sxp file If I recall my brief foray into the open source XenAPI - it uses the same transport mechanisms, but the open source one is not ver heavily tested, and just plain broken in some versions of xen (especially for HVM guests) However, you might be able to share some code under these two paths Daniel P. Berrange wrote on 01/09/2009 10:30 AM:
On Fri, Jan 09, 2009 at 03:18:36PM +0000, Richard W.M. Jones wrote:
On Thu, Jan 08, 2009 at 12:53:51PM -0000, Gerhardus.Geldenhuis@gta-travel.com wrote:
* libxenserver: The XenServer C SDK
[..]
All this can be downloaded from CDN at http://community.citrix.com/display/xs/Download+SDKs
I took a look at the C library:
* It's LGPLv2+, so there is no license issue that I can see with linking it to libvirt.
* It presents each XenServer API call as a C function. Each C function constructs an XML document (XMLRPC, I think), dispatches it to the server, gets the reply, and unpacks the resulting XML.
* Uses libxml2 to do the XML construction and parsing.
* You have to supply your own HTTP library to pass the data to the server. The examples use libcurl for this.
* Compiles with -Wall -Werror without warnings or errors.
It seems reasonably sensible. It still requires the proprietary XenEnterprise to be installed for testing of course.
It is possible that it might work with the XenAPI impl in the open source XenD too - worth a try if you want to develop something
Daniel
participants (9)
-
Atsushi SAKAI -
Ben Guthro -
Daniel P. Berrange -
Daniel Veillard -
David Edmondson -
Gerhardus.Geldenhuis＠gta-travel.com -
Michael DeHaan -
Richard W.M. Jones -
Tom Brown