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 >
