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.she...@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: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 >>>
