What's your timeframe you'd like to see here? Do you plan on working on this yourself or are you looking for some people from the community to take this up.
I have some interest in this. I'd like to enhance ACS to make adding hypervisors easier and using xen arm as a POC would be good. I want a practical example of how to do it but I'm not interested in creating a fully supported new hypervisor. But the enhancements I'm thinking of may take me 3 months to do. Darren On Aug 27, 2013, at 8:42 AM, Sebastien Goasguen <run...@gmail.com> wrote: > > On Aug 27, 2013, at 11:21 AM, Darren Shepherd <darren.s.sheph...@gmail.com> > wrote: > >> Just to throw in my two cents. I personally think the effort of adding a >> new hypervisor to CloudStack is too difficult. This is an area I'd like to >> focus on, along with another 15 things :) >> >> I personally see a motivation for an xl integration. This is something I've >> researched in the past (and did). Xen is very small, especially if you >> focus on only PV (with no qemu). You can build a Xen busybox system that is >> less that 50mb. This opens up a great new way to look at hypervisors in >> that you can PXE boot them and the whole OS is stateless and in memory. >> Basically what CoreOS is doing. >> >> Supporting a pure xl implementation is far more advanced thing though. >> XenServer handles a lot of nuisances of Xen, plus it makes storage easier >> (but networking more difficult). So if it was easy to add hypervisors I >> could see someone creating a specialized xl integration. If you want to >> support all the various networking and storage stuff, then libvirt or >> XenServer are a better way to go. >> >> Darren > > Thanks for the thought. > > I am interested in having Xen on ARM being supported by CloudStack as a proof > of concept. > XenServer and Xen + xapi are not candidates right now. So we would need to > look at XenProject (formerly xen) without xapi. > > That indeed leaves two choices directly writing an agent to talks to xl or > using libvirt. > > I have not run Xenproject lately so I don't know what would be available. > > Of course there is a short term mindset (getting a POC for Xen on ARM) and a > long term view of better hypervisor (and better xen support) in CloudStack. > > -sebastien > >> >> On Aug 27, 2013, at 7:10 AM, Sebastien Goasguen <run...@gmail.com> wrote: >> >>> >>> On Aug 19, 2013, at 3:09 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> >>> wrote: >>> >>>> On XenServer (from Citrix), there is no JVM, not sure if you can install >>>> it even after the open sourcing. >>> >>> I'd be surprised if you could not do it on Xen Project. >>> >>>> On 8/19/13 10:38 AM, "Sebastien Goasguen" <run...@gmail.com> wrote: >>>> >>>>> >>>>> On Aug 19, 2013, at 1:25 PM, Chiradeep Vittal >>>>> <chiradeep.vit...@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" <run...@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.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 >
