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 >>>>>>> >>>> >>> >> >
