I wonder how you plan to present the OpenStack environment to CloudStack; a huge host with lots of resources? Or, do you intend to present all of the clusters and hosts that the OpenStack system may have?
I think you would be better with a direct attach solution; meaning, CloudStack calling directly the API of OpenStack to execute its job. I think system VMs might be a little tricky to handle, but let´s wait to see what you come up with. When you have a draft of a development proposal, please count on us to discuss this further. Have Fun ;) Side note; are you able to share a bit more details for such necessity? On Fri, May 19, 2017 at 8:29 AM, Daan Hoogland <daan.hoogl...@shapeblue.com> wrote: > 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 > > > > -- Rafael Weingärtner
