cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Likitha Shetty <>
Subject RE: Whats involved in adding an extra hypervisor
Date Fri, 16 Aug 2013 06:42:05 GMT
Ian, with AWS it’s the other way around. The package allows us to spin up VMs in CS using


>-----Original Message-----
>From: Ian Duffy []
>Sent: Friday, August 16, 2013 12:07 PM
>To: CloudStack Dev
>Subject: Re: Whats involved in adding an extra hypervisor
>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