cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Duffy <>
Subject Re: Whats involved in adding an extra hypervisor
Date Fri, 16 Aug 2013 06:36:23 GMT
Hi Donal and Chiradeep,

Thanks for your comments. It was an interesting read.

I might be missing something here but I will ask anyways. If I
understand correctly, at current with awsapi we are able to submit our
aws api credentials to Cloudstack and spin up VMs on aws correct? Is
there a reason the communication with aws could not be provided like a
standard hypervisor? what is the reasoning behind keeping it as an
almost separate package?

The reason I'm asking is because I'm wanting to do something
Cloudstack based for a college project next year. However there is a
hard 1 month deadline. I was interested to see could a base(or
something of demoable quality) for supporting Google Compute Engine be
completed in such a short deadline.

On 15 August 2013 09:29, Donal Lafferty <> wrote:
> Definitely possible to add new Hypervisor types, if that's what you're asking.
> How easy it is depends on how much existing CloudStack infrastructure you can exploit.
 Let me out line the task with the help of some planning questions:
> 1. What will be your agent model?  Will you talk directly to the hypervisor (direct connect
agent), or will you install a remote agent on the hypervisor (connected agent).  This comes
down to whether the hypervisor exposes a high level API remotely.
> 2. What will be your secondary storage model?  Secondary storage provides low IOPS storage
accessible to all hypervisors in the zone.  Thus, we store the templates in secondary storage.
 IIRC, CloudStack supports NFS, S3 and Swift.  Does one of these options suit your data centre,
or do you need to expand the list?  Will your agent be able to download disk images in secondary
storage to the hypervisor?
> 3. What will be your primary storage model?  Typically, primary storage is high IOPS
storage specific to a hypervisor or cluster of hypervisors.  The easiest to setup is local
storage, which can be a hard disk or storage you mount manually on the hypervisor.  Alternatively,
you may want to automate mounting storage on the hypervisor.
> 4.  What will be your system VM model?  System VMs offload the following functionality
from the management server:  VM console access, networking services, and secondary storage
(upload) service.  You could skip system VMs and run these services in the management server's
host using QuickCloud.  You could run system VMs on an existing hypervisor type, or you could
add a new system VM type for your hypervisor.  Keep in mind that QuickCloud can't run your
networking services.  Also, if you want to create a new system VM type, you have to come up
with VM image.
> The tricky bits:
> 5. What language will your agent use?  A direct connect agent sits in the CloudStack
process, so it is written in Java.  Alternatively, there is infrastructure for a Java-based
remote agent, which handles all your communications.  If you need a non-Java remote agent,
you are better off sending the kernel commands over HTTP, which looks more like an RPC mechanism
than REST.
> 6. How will you know what instructions to implement?  You can look at an existing ServerResource
class for a hypervisor to know what command types there are.  The relevant pieces of data
in each command can be found out from existing hypervisor implementations.  Alternatively,
you can look at test logs, which contain the data from each command.  Eventually you'll want
to try your plugin with CloudStack itself.
> Chiradeep's comments relate to #6 above.
>> -----Original Message-----
>> From: Chiradeep Vittal []
>> Sent: 15 August 2013 02:51
>> To:
>> Subject: Re: Whats involved in adding an extra hypervisor
>> Yes, it is a hypervisor plugin. While the extension method may be simple, the
>> impedance mismatch between the CloudStack virtual model and the
>> hypervisor API is what causes the most pain.
>> E.g., CloudStack will hand a VirtualMachineTO object (consisting of
>> cpu/mem/nic) and then you have to use the hypervisor API to construct it.
>> For XS, it involves calling a bunch of XS APIs to 'construct' the VM. For KVM, it
>> involves constructing an XML file and passing it to libvirt, etc.
>> I'd say stuff like snapshots, stuff that involves a lot of firewall configuration
>> tends to be harder.
>> On 8/14/13 3:28 PM, "Ian Duffy" <> wrote:
>> >Hi Guys,
>> >
>> >Just asking this off the top of my head with no research done at all.
>> >Its a pure "Just out of interest" query.
>> >
>> >Would it be a difficult task to add an interface to Cloudstack in order
>> >to enable it to communicate with some REST based API that goes back to
>> >some hypervisor?
>> >
>> >Can anybody point in the direction of code/files I should look at to
>> >get an idea of the amount of work involved? Is the plugin model in such
>> >a state where such functionality could be abstracted out as a plugin?
>> >With my previous experiences of dealing with the cloudstack code base I
>> >recall seeing a hypervisor folder in the plugins folder, is it just as
>> >simple as extending a few classes in there?
>> >
>> >Thanks,
>> >
>> >Ian

View raw message