On Aug 27, 2013, at 3:15 PM, Darren Shepherd <darren.s.sheph...@gmail.com> wrote:
> 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. > Opennebula has already demoed it, so I think we should try to do it asap :) But my knowledge of Xen is limited. So yes I was kind of fishing for someone to step in ! > 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. 3 months might be a bit long for the xen timeline, I know they are eager to show good stuff for ARM. But hey, better than 12. To be honest, I was thinking of something a bit dirty to show POC, using the existing KVM agent and patching a few libvirt commands. But I am not sure if it would work due to restrictions of xen on arm. > > 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 >>
