John, I never implemented one but I am about to investigate the ovm3 one to see
if I can maintain it for a customer. I know the guy that wrote it and he says
it’s fairly simple given the constraint of a hypervisor plugin, so I’d have a
look at that one if I where you.
Important thing to consider is the agent concept, most hypervisors have
directly attached agents, i.e. running in the management server. You might not
want that and have a look at KVM as well (hyperv as alternative but that one is
the odd man out)
This btw sounds like a strategic direction, but indeed not for cloudstack.
Hope to hear a lot about your progress ;)
On 19/05/2017, 13:36, "Erik Weber" <terbol...@gmail.com> wrote:
I can already hear the slogan in my head "CloudStack - making
OpenStack great again" :-p
On Fri, May 19, 2017 at 12:57 PM, John Smith <john.smith....@gmail.com> wrote:
> Ok...so bear with me on this one.
>
> "Hypervisor" was a little white lie. What I actually want to do is
> implement OpenStack as a backend for CloudStack (yo dawg, I hear you like
> cloud in your clouds, etc). I know I can use KVM and OVS as backends for
> CloudStack natively but, as I said, this is for a project with some very
> specific needs...
>
> As OpenStack is completely API driven, I see no issues with the basics of
> communication between CS and OS.
>
> This would, of course, bypass the OS concept of Linux network namespaces
> for routing and I would implement the CS routing VM as a VM (just like in
> VMware or Xen) connected between an OS tenant network and an OS external
> network. CS volumes would be OS volumes. Secondary storage would be a VM
> running NFS.
>
> In principle, I see that the CS concepts of compute, network and storage
> could be implemented on OS. I was hoping that I could basically write a
> "driver" that would do the necessary actions against OS based on standard
> calls to a CS class/method/whatever, based on some assumption that the
> underlying hypervisor in CS was at least some sort of pluggable
> architecture.
>
> Yes, this may sound a little crazy, and I did say this was probably not
> something strategic to the CloudStack direction, but for me it actually
> fits a funny shaped hole I've discovered and I'm interested in at least
> understanding how such a thing could be done.
>
> Thanks,
>
> John.
>
>
>
> On Fri, May 19, 2017 at 12:06 AM, Simon Weller <swel...@ena.com.invalid>
> wrote:
>
>> Which hypervisor are you wanting to implement?
>>
>> Simon Weller/615-312-6068
>>
>> -----Original Message-----
>> From: John Smith [john.smith....@gmail.com]
>> Received: Thursday, 18 May 2017, 5:29PM
>> To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
>> Subject: Extend CloudStack for a new hypervisor
>>
>> Greetings!
>>
>> I have a need to extend CloudStack to support an additional hypervisor.
>> This is not something I consider strategic for CloudStack itself, but I
>> have a project with a very specific need.
>>
>> I have a development background but am not an active developer right now
>> ... so looking forward to getting back in the saddle! I've never
developed
>> against the CloudStack tree before.
>>
>> I can't find any docs on how one would introduce support for a new
>> hypervisor (eg. what classes, methods, etc, need to be implemented,
>> extended, etc) and checking the source tree I can't easily see if there
is
>> a base to build from. I would appreciate any pointers about where to
start
>> looking to save me going through the entire tree from scratch.
>>
>> The standard CloudStack concepts should be easy enough (ha!) to map 1:1
to
>> this additional hypervisor (including primary & secondary storage,
router &
>> secondary storage VMs, the networking concepts, etc) so I'm hoping that I
>> can simply implement it like a VMware or Xen backend ...
>>
>> Thanks in advance!
>>
>> John.
>>
daan.hoogl...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
