Hi, Atif If you want to natively use Xen API, I will recommend to use it directly. If you want to use archtecture neutral API, You should use libvirt. Libvirt pros and cons pros:any Xen version is supported (like 3.y.z or 2.y) cons:architecuture neutral API. specific functionality is not always supported. And this list may be helpful. http://libvirt.org/hvsupport.html Thanks Atsushi SAKAI "atif bajwa" <atifbajwa(a)gmail.com&gt; wrote: > Hi! > > I am looking to integrate the Xen Management. Please guide me advantages of > using libvirt over XenAPI and please list xen-based-hypervisor > distributions(versions) that will be supported with libvirt. And what is > future of libvirt as XenSource is more focused on XenAPI. > > Regards, > Atif

On Mon, Sep 01, 2008 at 10:59:09AM +0200, atif bajwa wrote: > I am looking to integrate the Xen Management. Please guide me advantages of > using libvirt over XenAPI and please list xen-based-hypervisor > distributions(versions) that will be supported with libvirt. And what is > future of libvirt as XenSource is more focused on XenAPI. There are many benefits to using libvirt instead of XenAPI - Avoids your application being locked into a particular hypervisor allowing you to port your application to KVM, OpenVZ, LXC (native Linux containers) and any hypervisor supported by libvirt in future - livirt works with every version of Xen 3.0.x or later, XenAPI is only usable in Xen 3.1.0 and later and thus not available in some distros such as RHEL-5/CentOS-5 - The same API can be used both locally, and remotely. Local access is highly efficient making direct hypercalls whereever possible giving order of magnitude better response time than XenAPI. - Remote access can be secured using SSL + x509 certificates, SSH tunnel, Kerberos GSSAPI single sign on, username + password - Guarenteed stable API, so applications written against libvirt will continue to work indefinitely into the future There's probably more points I can come up with, but that's enough for now. As for the future, libvirt is now available in every major Linux distro, and used by a wide range of tools developed by numerous companies & has contributors from across the open source community, both independant and vendor sponsered. There is an ever increasing set of language bindings for the API (Python, Perl, Java, OCaml, Ruby) and mappings into the CIM / DMTF framework for virtualzation, and new work to provide an AMQP binding. And of course this is also ongoing work to expand the API functionality and add new hypervisor drivers. There's a healthy todo list of ideas we'll be addressing over the next year or so... http://wiki.libvirt.org/page/Todo 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/<http://search.cpan.org/%7Edanberr/>:| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Mon, Sep 01, 2008 at 12:06:07PM +0200, atif bajwa wrote: > 1. Solaris SPARC 81/9/10 > 2. Solaris x64/x86 9/10 > 3. Red Hat RHEL AS/ES/WS 3/4/5 > 4. Novell SUSE & SLES 8/9/10 Those should all be supported as libvirt clients. To address another point, we'll have better support for Windows in future (ie. you won't need to build it from source). The dependency is this project: http://fedoraproject.org/wiki/SIGs/MinGW See also: http://wiki.libvirt.org/page/TodoWindowsSupport Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df <http://et.redhat.com/%7Erjonesvirt-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/<http://et.redhat.com/%7Erjones/v...

On Mon, Sep 01, 2008 at 01:58:09PM +0200, atif bajwa wrote: > On Mon, Sep 1, 2008 at 1:39 PM, Richard W.M. Jones <rjones(a)redhat.com >wrote: > > To address another point, we'll have better support for Windows in > > future (ie. you won't need to build it from source). The dependency > > is this project: http://fedoraproject.org/wiki/SIGs/MinGW > > See also: http://wiki.libvirt.org/page/TodoWindowsSupport > > Thanks but does libvirt support windows port with any released build or not? You can compile libvirt (client only) on Windows -- see Atsushi's previous email for links to how to do this. If you follow this link you will see the current status of Windows builds (ie, binaries that you can download from libvirt.org): http://wiki.libvirt.org/page/TodoWindowsSupport > > On Mon, Sep 01, 2008 at 12:06:07PM +0200, atif bajwa wrote: > > > 1. Solaris SPARC 81/9/10 > > > 2. Solaris x64/x86 9/10 > > > 3. Red Hat RHEL AS/ES/WS 3/4/5 > > > 4. Novell SUSE & SLES 8/9/10 > > > > Those should all be supported as libvirt clients. > > I am little surprised "should be?". I need to make a decision to use libvirt > or Xen API, (clearly runnable from windows) . If libvirt does windows port, > which of the following distributions "are" supported [...] "should be" as in, we haven't compiled it on every single one of those, but since they are all Un*x distributions, there should be no problem. If you find a problem, please post about it on the mailing list. If you want commercial support, Red Hat support libvirt client & server on RHEL 5, and I guess we either do now or could in the future support libvirt client on RHEL 3/4 too (talk to Red Hat sales or your account manager). Solaris and SUSE are supported by Sun and Novell respectively, so you would need to talk to them. > as remote hosts. I'm a bit confused by what you mean here though. For example RHEL 3/4 don't have any support for virtualization of the host, so there wouldn't be any point in running them as libvirtd servers. Unless you are compiling qemu on them or something like that. Libvirt as a client and libvirt(d) as a server are completely different things. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones <http://et.redhat.com/%7Erjones> Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

On Mon, Sep 01, 2008 at 02:40:38PM +0200, atif bajwa wrote: > 2. List of distributions supported by libvirt as server. The list refers to > this part of question. This part doesn't make sense. There is no hypervisor support in RHEL 3 or 4 (for example) so running libvirtd on RHEL 3 or 4 may be possible, but would be pointless. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones <http://et.redhat.com/%7Erjones> Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

On Mon, Sep 01, 2008 at 03:33:11PM +0200, atif bajwa wrote: > Yes, you are correct for RHEL 3 but Xen 3.x is download-able for RHEL 4.1, > 4.4, 4.5, 5, 5.1, 5.2 and similarly for Novell SLES 9.2, 9.3, 10, 10 SP1, 10 > SP2 and OpenSUSE 10, 10.3, 11 > > Additionally, I got similar information from Sun xVM Ops Center managed > systems which integrates libvirt. OK, so I understand now, you mean this: http://www.xen.org/download/index_3.1.html. The answer is yes, you should be able to compile and run libvirt client & server on all of those platforms. If you find a specific compile problem, report it on this list. I guess you should be aware that you or your customers may have a hard time getting commercial support for (eg) running non-standard Xen kernels on RHEL 4. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones <http://et.redhat.com/%7Erjones> 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/<http://et.redhat.com/%7Erjones/v...

On Tue, Sep 02, 2008 at 06:09:43PM +0200, atif bajwa wrote: > Just quick question, > what version of Xen/XenApi is packaged in RHEL 5.1/5.2. Can I remotely > access it using XML-RPC API or not? RHEL-5.2 has xen-3.0.3, and that will stay the same for the lifetime of RHEL5. There is no XenAPI for this, as Dan Berrange told you already. And for remote access you have libvirt support.

Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Hi, Alain I guess Daniel says xend issue.(since it relates to XenAPI) As for hypervisor, You are correct in RHEL5.2 and CentOS5.2. Current RHEL/Xen is very complex compared to upstream Xen. Thanks Atsushi SAKAI "Alain Barthe" <ab266061(a)gmail.com&gt; wrote: > 2008/9/4 Daniel Veillard <veillard(a)redhat.com&gt; > > > On Tue, Sep 02, 2008 at 06:09:43PM +0200, atif bajwa wrote: > > > Just quick question, > > > what version of Xen/XenApi is packaged in RHEL 5.1/5.2. Can I remotely > > > access it using XML-RPC API or not? > > > > RHEL-5.2 has xen-3.0.3, and that will stay the same for the lifetime > > of RHEL5. There is no XenAPI for this, as Dan Berrange told you > > already. And for remote access you have libvirt support. > > > On CentOS-5.2 (same as RedHat, IFAIK), xen is 3.1.2. Don't believe rpm > version, check "xm info" instead. > > > > > > > > Daniel > > > > -- > > Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ > > daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ > > http://veillard.com/ | virtualization library http://libvirt.org/ > > > > -- > > Libvir-list mailing list > > Libvir-list(a)redhat.com > > https://www.redhat.com/mailman/listinfo/libvir-list > > -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On Mon, Sep 08, 2008 at 08:56:49AM +0100, atif bajwa wrote: > So the question is, > Is there any particular reason that RHEL 5.2 did not upgrade Xen user space > tools/libs. Yes that's called API and ABI compatibility in a RHEL product lifetime! And by definition this will remain for all RHEL 5, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

So the question is, Is there any particular reason that RHEL 5.2 did not upgrade Xen user space tools/libs. Novell SLES/SLED 10 SP2 and Oracle VM 2.1.x have upgraded the user space libs for remote management of Xen infrastructure.