Re: [libvirt] libvirt vs XenAPI

["atif bajwa" <atifbajwa@xxxxxxxxx>]

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@xxxxxxxxxx> 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/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list