Sure. This came about while experimenting with various configurations of the
Xen hypervisor.
I'll start my making the grand statement, then try to expain my thinking:
'By supporting the Libvirt and XAPI APIs rather than 'KVM' and 'XenServer',
CloudStack would be able to (potentially) orchestrate many more hypervisors.'
I'll summarise my limited knowledge on the subject...
'Xen' is in-fact the Xen hypervisor with a 'toolset' on top (xl, xe, libvirt or
xapi)
Xen + the XAPI toolset being the basis for XenServer and XCP
Libvirt (like XAPI) is an API layer that controls the underlying hypervisor.
(so far so good)....
I'd created a Ubuntu Xen box with the Libvirt API on top thinking that it would
act like a 'KVM' host as CloudStack talks to KVM via the Libvirt API - and
failed miserably.
But this got me thinking and I looked closer into KVM, Libvirt, Xen and XAPI
Libvirt is (like XAPI) an API layer that controls the underlying hypervisor
which could be any of:
Xen
QEMU / KVM
Linux Container
OpenVZ
UML
VirtualBox
VMware ESX
VMware Workstation / Player
Microsoft Hyper-V
Libvirt also supports the following storage:
Directory backend
Local filesystem backend
Network filesystem backend
Logical backend
Disk backend
iSCSI backend
SCSI backend
Multipath backend
RBD (RADOS Block Device) backend
Sheepdog backend
So....
If CloudStack were designed to communicate with XAPI and Libvirt - it would
open quite a few doors.
(maybe??)
Regards,
Paul Angus
S: +44 20 3603 0540 | M: +447711418784
[email protected]
-----Original Message-----
From: Chip Childers [mailto:[email protected]]
Sent: 08 February 2013 16:06
To: Paul Angus
Cc: Dave Cahill; [email protected]
Subject: Re: QEMU support in CloudStack
On Fri, Feb 08, 2013 at 10:47:29AM +0000, Paul Angus wrote:
> Hi Dave,
>
> Your suggestion ties in nicely which a proposal that I have been mulling
> over; and that is further abstraction of the hypervisor, by CloudStack
> becoming more ‘toolset agonistic’ to use Xen parlance, rather than hypervisor
> agnostic?
>
> It seems quite an elegant solution to expanding hypervisor support
> (which easy for me to say as I don't know how to do it)…
>
> The current toolsets / interfaces become something like:
>
> OVM Manager (OVM)
> vCenter (ESXi)
> XAPI (XenServer, XCP, Xen+XAPI)
> Libvirt (KVM, Xen+Libvirt, QEMU)
> WMI/PowerShell (Hyper-V)
>
> + a bit of logic when copying scripts across to put them in the correct
> location for any given hypervisor/distribution.
Paul,
I'm not sure I quite understand what you are suggesting. Can you elaborate?
-chip
ShapeBlue provides a range of strategic and technical consulting and
implementation services to help IT Service Providers and Enterprises to build a
true IaaS compute cloud. ShapeBlue’s expertise, combined with CloudStack
technology, allows IT Service Providers and Enterprises to deliver true,
utility based, IaaS to the customer or end-user.
________________________________
This email and any attachments to it may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of Shape Blue Ltd. If you are not the intended recipient of
this email, you must neither take any action based upon its contents, nor copy
or show it to anyone. Please contact the sender if you believe you have
received this email in error. Shape Blue Ltd is a company incorporated in
England & Wales.
