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:i...@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.laffe...@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.vit...@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" <i...@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 >>
