You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Ian Duffy <ia...@ianduffy.ie> on 2013/08/15 00:28:14 UTC
Whats involved in adding an extra hypervisor
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
Re: Whats involved in adding an extra hypervisor
Posted by Nguyen Anh Tu <ng...@gmail.com>.
2013/8/19 Sebastien Goasguen <ru...@gmail.com>
> 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 ?
>
Xen on ARM or ARM hypervisor, can be supported for mobile devices, sound
like interesting. If we have plan to do it, I'm willing to contribute.
Anything related to Xen makes me excited.
A short demo about Xen on ARM cloud with OpenNebula:
http://www.youtube.com/watch?v=xZP9YKv3P_E
--
N.g.U.y.e.N.A.n.H.t.U
Re: Whats involved in adding an extra hypervisor
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Aug 27, 2013, at 3:15 PM, Darren Shepherd <da...@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 <ru...@gmail.com> wrote:
>
>>
>> On Aug 27, 2013, at 11:21 AM, Darren Shepherd <da...@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 <ru...@gmail.com> wrote:
>>>
>>>>
>>>> On Aug 19, 2013, at 3:09 PM, Chiradeep Vittal <Ch...@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" <ru...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> On Aug 19, 2013, at 1:25 PM, Chiradeep Vittal
>>>>>> <Ch...@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" <ru...@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 <li...@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:ian@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 <do...@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.Vittal@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" <ia...@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
>>
Re: Whats involved in adding an extra hypervisor
Posted by Darren Shepherd <da...@gmail.com>.
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.
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.
Darren
On Aug 27, 2013, at 8:42 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> On Aug 27, 2013, at 11:21 AM, Darren Shepherd <da...@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 <ru...@gmail.com> wrote:
>>
>>>
>>> On Aug 19, 2013, at 3:09 PM, Chiradeep Vittal <Ch...@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" <ru...@gmail.com> wrote:
>>>>
>>>>>
>>>>> On Aug 19, 2013, at 1:25 PM, Chiradeep Vittal
>>>>> <Ch...@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" <ru...@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 <li...@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:ian@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 <do...@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.Vittal@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" <ia...@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
>
Re: Whats involved in adding an extra hypervisor
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Aug 27, 2013, at 11:21 AM, Darren Shepherd <da...@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 <ru...@gmail.com> wrote:
>
>>
>> On Aug 19, 2013, at 3:09 PM, Chiradeep Vittal <Ch...@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" <ru...@gmail.com> wrote:
>>>
>>>>
>>>> On Aug 19, 2013, at 1:25 PM, Chiradeep Vittal
>>>> <Ch...@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" <ru...@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 <li...@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:ian@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 <do...@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.Vittal@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" <ia...@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
>>
Re: Whats involved in adding an extra hypervisor
Posted by Darren Shepherd <da...@gmail.com>.
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
On Aug 27, 2013, at 7:10 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> On Aug 19, 2013, at 3:09 PM, Chiradeep Vittal <Ch...@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" <ru...@gmail.com> wrote:
>>
>>>
>>> On Aug 19, 2013, at 1:25 PM, Chiradeep Vittal
>>> <Ch...@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" <ru...@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 <li...@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:ian@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 <do...@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.Vittal@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" <ia...@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
>
Re: Whats involved in adding an extra hypervisor
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Aug 19, 2013, at 3:09 PM, Chiradeep Vittal <Ch...@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" <ru...@gmail.com> wrote:
>
>>
>> On Aug 19, 2013, at 1:25 PM, Chiradeep Vittal
>> <Ch...@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" <ru...@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 <li...@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:ian@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 <do...@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.Vittal@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" <ia...@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
>>>>>>>
>>>>
>>>
>>
>
Re: Whats involved in adding an extra hypervisor
Posted by Chiradeep Vittal <Ch...@citrix.com>.
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" <ru...@gmail.com> wrote:
>
>On Aug 19, 2013, at 1:25 PM, Chiradeep Vittal
><Ch...@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" <ru...@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 <li...@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:ian@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 <do...@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.Vittal@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" <ia...@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
>>>>>>
>>>
>>
>
Re: Whats involved in adding an extra hypervisor
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Aug 19, 2013, at 1:25 PM, Chiradeep Vittal <Ch...@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" <ru...@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 <li...@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:ian@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 <do...@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.Vittal@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" <ia...@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
>>>>>
>>
>
Re: Whats involved in adding an extra hypervisor
Posted by Chiradeep Vittal <Ch...@citrix.com>.
I thought libvirt supports xen as well? Why "modify libvirt calls to talk
to xl" ?
On 8/19/13 6:40 AM, "Sebastien Goasguen" <ru...@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 <li...@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:ian@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 <do...@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.Vittal@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" <ia...@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
>>>>
>
Re: Whats involved in adding an extra hypervisor
Posted by Sebastien Goasguen <ru...@gmail.com>.
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 <li...@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:ian@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 <do...@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.Vittal@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" <ia...@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
>>>
RE: Whats involved in adding an extra hypervisor
Posted by Likitha Shetty <li...@citrix.com>.
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:ian@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 <do...@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.Vittal@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" <ia...@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
>>
Re: Whats involved in adding an extra hypervisor
Posted by Ian Duffy <ia...@ianduffy.ie>.
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 <do...@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.Vittal@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" <ia...@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
>
RE: Whats involved in adding an extra hypervisor
Posted by Donal Lafferty <do...@citrix.com>.
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.Vittal@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" <ia...@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
Re: Whats involved in adding an extra hypervisor
Posted by Chiradeep Vittal <Ch...@citrix.com>.
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" <ia...@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