[libvirt] libvirt vs XenAPI
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
Hi! I am looking to add support for Xen. Please guide me which is best method to connect to remote system(host) from windows client. What privileges and binaries will be required for client program to read data only. If possible please list supported libvirt versions that can be port to windows. Also list xen-based-hypervisor distributions that I can get remote access with libvirt windows based client. Regards, Atif
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@gmail.com> 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
Thanks, Please guide me list of supported distributions with versions that I can use libvirt with. Regards, Atif On Mon, Sep 1, 2008 at 11:12 AM, Atsushi SAKAI <sakaia@jp.fujitsu.com>wrote:
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@gmail.com> 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/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Thanks, You mentioned that libvirt works with every version of Xen 3.0.x or later, if you can list me list of Linux distros or verify if following list if ok with remote access. 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 Regards, Atif On Mon, Sep 1, 2008 at 11:23 AM, Daniel P. Berrange <berrange@redhat.com>wrote:
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 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/
Thanks but does libvirt support windows port with any released build or not? 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 as remote hosts. Regards, Atif On Mon, Sep 1, 2008 at 1:39 PM, Richard W.M. Jones <rjones@redhat.com>wrote:
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/virt-df/>
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@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 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
Thanks Rich, My original question has two parts 1. I want to access the host (a xen-based-hypervisor with libvirt server intalled) from windows client. 2. List of distributions supported by libvirt as server. The list refers to this part of question. So part of my question is still unanswered. Is the list provided for libvirt servers (or libvirt managed hosts) is correct? Regards, Atif On Mon, Sep 1, 2008 at 2:23 PM, Richard W.M. Jones <rjones@redhat.com>wrote:
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@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 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
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. Regards, Atif On Mon, Sep 1, 2008 at 3:10 PM, Richard W.M. Jones <rjones@redhat.com>wrote:
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 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/
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? Regards, Atif On Mon, Sep 1, 2008 at 4:09 PM, Richard W.M. Jones <rjones@redhat.com>wrote:
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/virt-df/>
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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
2008/9/4 Daniel Veillard <veillard@redhat.com>
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@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
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@gmail.com> wrote:
2008/9/4 Daniel Veillard <veillard@redhat.com>
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@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
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. Regards, Atif On Mon, Sep 8, 2008 at 8:49 AM, Atsushi SAKAI <sakaia@jp.fujitsu.com> wrote:
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@gmail.com> wrote:
2008/9/4 Daniel Veillard <veillard@redhat.com>
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
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
-- Libvir-list mailing list Libvir-list@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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Thanks, With Xen 3.3, the Xen Client Initiative (XCI) is out, a Xen.org community effort to accelerate and coordinate the development of fast, free, compatible embedded Xen hypervisors for laptops, PCs and PDAs. Don't you think the XenApi or similar technologies be right choice for remote management of these. Regards, Atif On Mon, Sep 8, 2008 at 9:06 AM, Daniel Veillard <veillard@redhat.com> wrote:
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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, Sep 08, 2008 at 01:49:53PM +0100, atif bajwa wrote:
Thanks, With Xen 3.3, the Xen Client Initiative (XCI) is out, a Xen.org community effort to accelerate and coordinate the development of fast, free, compatible embedded Xen hypervisors for laptops, PCs and PDAs.
Don't you think the XenApi or similar technologies be right choice for remote management of these.
As developers of libvirt, we believe that users, admins & developers are best served by an API which is independant of the underlying virtualization technology. The choice of which hypervisor to use is a deployment question, and as such applications should not be looked into one particular choice. XenAPI as an application development API will irrevocably lock you into the Xen hypervisor. 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 :|
atif bajwa wrote:
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.
Yes. We needed to keep backwards compatibility with the userspace tools shipped in RHEL 5.0, which was based on 3.0.3. For that reason, we can't take wholesale the upgraded userland; and in point of fact, we don't really need to, since libvirt provides us with the functionality that XenAPI would. Chris Lalancette
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. Novell SLES/SLED 10 SP2 and Oracle VM 2.1.x have upgraded the user space libs for remote management of Xen infrastructure.
Novell does not provide the same user ABI/API stability guarentees that we do in RHEL. The change from Xen 3.0.x series to Xen 3.1.0 changes a number of user facing APIs / changes semantics of existing commands. This is not acceptable to drop into a minor update of RHEL because it can cause functional regressions for people deploying tools built on Xen. 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 :|
participants (7)
-
Alain Barthe -
atif bajwa -
Atsushi SAKAI -
Chris Lalancette -
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones