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