cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: Whats involved in adding an extra hypervisor
Date Mon, 19 Aug 2013 17:38:37 GMT

On Aug 19, 2013, at 1:25 PM, Chiradeep Vittal <Chiradeep.Vittal@citrix.com> wrote:

> I thought libvirt supports xen as well? Why "modify libvirt calls to talk
> to xl" ?
> 

what I meant is that I believe our current Xen support makes use of xapi not libvrit.

So I would think we could "copy" the KVM agent and modify the "libvirt calls" -not libvrt
itself- to use the xl tool.

That said I have not looked at the code for our Xen support.


> On 8/19/13 6:40 AM, "Sebastien Goasguen" <runseb@gmail.com> 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
>> CloudStack
>> 
>> Any takers ? or anyone telling me I got this completely wrong ?
>> 
>> -Sebastien
>> 
>> On Aug 16, 2013, at 2:42 AM, Likitha Shetty <likitha.shetty@citrix.com>
>> wrote:
>> 
>>> 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 [mailto:ian@ianduffy.ie]
>>>> 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 <donal.lafferty@citrix.com>
>>>> 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 [mailto:Chiradeep.Vittal@citrix.com]
>>>>>> Sent: 15 August 2013 02:51
>>>>>> To: dev@cloudstack.apache.org
>>>>>> 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" <ian@ianduffy.ie> 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
>>>>> 
>> 
> 


Mime
View raw message