cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Angus <>
Subject RE: QEMU support in CloudStack
Date Sun, 10 Feb 2013 20:57:07 GMT
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:
    QEMU / KVM
    Linux Container
    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


If CloudStack were designed to communicate with XAPI and Libvirt - it would open quite a few



Paul Angus
S: +44 20 3603 0540 | M: +447711418784

-----Original Message-----
From: Chip Childers []
Sent: 08 February 2013 16:06
To: Paul Angus
Cc: Dave Cahill;
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.


I'm not sure I quite understand what you are suggesting.  Can you elaborate?


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.
View raw message