3:59 a.m.
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
4:09 a.m.
New subject: [libvirt] Re: libvirt vs XenAPI
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
4:12 a.m.
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> wrote:
4:23 a.m.
On Mon, Sep 01, 2008 at 10:59:09AM +0200, atif bajwa wrote:
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 :|
5:06 a.m.
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(a)redhat.com>wrote:
6:39 a.m.
On Mon, Sep 01, 2008 at 12:06:07PM +0200, atif bajwa wrote:
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/
6:58 a.m.
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(a)redhat.com>wrote:
7:23 a.m.
On Mon, Sep 01, 2008 at 01:58:09PM +0200, atif bajwa wrote:
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
"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
7:40 a.m.
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(a)redhat.com>wrote:
8:10 a.m.
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
8:33 a.m.
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(a)redhat.com>wrote:
9:09 a.m.
On Mon, Sep 01, 2008 at 03:33:11PM +0200, atif bajwa wrote:
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/
8:24 a.m.
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/
2:56 a.m.
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(a)jp.fujitsu.com> wrote:
3:06 a.m.
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/
7:49 a.m.
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(a)redhat.com> wrote:
7:53 a.m.
On Mon, Sep 08, 2008 at 01:49:53PM +0100, atif bajwa wrote:
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 :|
3:10 a.m.
atif bajwa wrote:
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
3:47 a.m.
On Mon, Sep 08, 2008 at 08:56:49AM +0100, atif bajwa wrote:
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 :|
6031
days inactive
6038
days old
22 comments
7 participants
participants (7)
-
Alain Barthe -
atif bajwa -
Atsushi SAKAI -
Chris Lalancette -
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones