On XenServer (from Citrix), there is no JVM, not sure if you can install it even after the open sourcing.
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 >>>>>> >>> >> >
