cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: Whats involved in adding an extra hypervisor
Date Mon, 19 Aug 2013 17:25:55 GMT
I thought libvirt supports xen as well? Why "modify libvirt calls to talk
to xl" ?

On 8/19/13 6:40 AM, "Sebastien Goasguen" <> wrote:

>Kind of on that same vein:
>Anyone interested in modifying the KVM agent to support "pure" Xen
>without xapi.
>I think it might be possible to just use the kvm agent and modify the
>libvirt calls to talk to xl , that way there would be no need for xapi...
>Which if I am not mistaken would give us Xen on ARM support instantly in
>Any takers ? or anyone telling me I got this completely wrong ?
>On Aug 16, 2013, at 2:42 AM, Likitha Shetty <>
>> Ian, with AWS it¹s the other way around. The package allows us to spin
>>up VMs in CS using AWS EC2 API's.
>> -Likitha
>>> -----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
>>> correctly, at current with awsapi we are able to submit our aws api
>>> 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
>>> Google Compute Engine be completed in such a short deadline.
>>> On 15 August 2013 09:29, Donal Lafferty <>
>>>> 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
>>> can exploit.  Let me out line the task with the help of some planning
>>>> 1. What will be your agent model?  Will you talk directly to the
>>> (direct connect agent), or will you install a remote agent on the
>>> (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
>>> low IOPS storage accessible to all hypervisors in the zone.  Thus, we
>>>store the
>>> templates in secondary storage.  IIRC, CloudStack supports NFS, S3 and
>>> 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
>>> manually on the hypervisor.  Alternatively, you may want to automate
>>> storage on the hypervisor.
>>>> 4.  What will be your system VM model?  System VMs offload the
>>> functionality from the management server:  VM console access,
>>> 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
>>> CloudStack process, so it is written in Java.  Alternatively, there is
>>> 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
>>> over HTTP, which looks more like an RPC mechanism than REST.
>>>> 6. How will you know what instructions to implement?  You can look at
>>> existing ServerResource class for a hypervisor to know what command
>>> 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
>>>>>> 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
>>>>>> 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
>>>>>> 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