cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@shapeblue.com>
Subject Re: Extend CloudStack for a new hypervisor
Date Fri, 19 May 2017 12:29:00 GMT
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" <terbolous@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.rfx@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 <sweller@ena.com.invalid>
    > wrote:
    >
    >> Which hypervisor are you wanting to implement?
    >>
    >> Simon Weller/615-312-6068
    >>
    >> -----Original Message-----
    >> From: John Smith [john.smith.rfx@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.hoogland@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Mime
View raw message