Been a while since I looked at this stuff. It might be worth it to look at the VSphere implementation as that does something similar to what you're trying to achieve and what Rafael mentions. In effect you could view CloudStack as the federation of multiple VSphere endpoints, in your case one or more OpenStack endpoints (or a combination of multiple!). To Daan's point however with KVM, HyperV and OVM(2|3) the hypervisors are treated as separate entities, under control of CloudStack, and not as a proxied semi-orchestrator. The Xenserver implementation is a bit of both, with the master of the cluster being the point of focus (at least last time I looked at it). Mind you that this is more geared around the bookkeeping done in CS then a real "problem" as such, just something to keep in mind when spelunking the existing hypervisor implementations. Pretty awesome idea though, and reminds me of long discussions on implementing OpenStack Neutron in CloudStack for networking :P
With regard to the VirtualBox desire, which I think is pretty awesome and funny, I really don't see a problem with implementing. VirtualBox has an API which you can talk to. Getting a VM up and running should not pose a major challenge I would think, and is not related to what type of "hypervisor" it is. The host OS might however require some specifics. Cheers, Funs On Fri, May 19, 2017 at 11:22 AM, Rafael Weingärtner < rafaelweingart...@gmail.com> wrote: > 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 >
