I thought libvirt supports xen as well? Why "modify libvirt calls to talk to xl" ?
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 >>>> >
