Which hypervisor? Why not all of them!

Don’t Lose Control. Take Control!

Portability of applications. No vendor lock-in. These topics have been widely discussed in the cloud industry. Many organizations invested heavily in particular IaaS vendors, may it be a public cloud environment or a private virtualization offering. They are invested to the point where they feel like they are being locked-in, meaning they lose control over what is best for their virtual infrastructure needs, not to mention the burden of increasing costs.

Stackato Platform to the Rescue

Since Stackato can be easily deployed on any hypervisor (and associated IaaS offerings), it can be leveraged to regain control over what infrastructure products your organization should use. Further, instead of spending months and years trying to come up with your virtualization strategy, why not start using Stackato on one hypervisor right away. You could still easily move to a different hypervisor at a later time. Stackato lets you get started right away.

Let’s Play!

Alright, I’m going to do something crazy but not-so-crazy to prove infrastructure agnosticity with Stackato. Okay, agnosticity isn’t really a word, but you get the idea. Below shows you a configuration I would not endorse, and it is definitely not a standard one. However, just to demonstrate the ability to run Stackato on various hypervisor, and for shouting why not instead of why, I’m going to set up a 3-node Stackato cluster that spans multiple hypervisors running simultaneously.

Start with the Core Node

For most of my daily work duties I use my Macbook Pro (MBP) at work, so naturally, I start off with a Stackato micro cloud on my laptop running VMware Fusion. Getting the microcloud to run on my MBP is dead easy. 1. Download. 2. Import. 3. Run. That’s it! I’m pretty sure everyone can do this in under an hour. Check out this PaaS in an Hour webinar or Micro Cloud VM documentation if you need more guidance.

Micro cloud is just the initial step, and we all know that it is easy to get it set up. Now let’s proceed to set up a Stackato cluster. For the cluster setup, a cautionary step is to check the network setup on the hypervisor, ensure that it is Bridged instead of NAT’d so other hosts on the network can reach the guest VM (Stackato server).

On the server, this single command will set it up as a core node:

$ kato node setup core api.192.168.68.200.xip.io

Note: Using xip.io means I don’t have to go to my IT department to ask for a specific DNS entry for name resolution, yay for self-service.

The Other Nodes: Data Services and DEA

I ran around the office, asking some of my colleagues to borrow their local machine’s resource. Let’s take advantage of the fact that our sales team primarily use Windows on their systems. One of my colleague in Sales is tech-savvy enough to have Virtualbox running on his machine, so I have asked him to spin up a Stackato micro cloud there. Similarly, the process is just 1. Download. 2. Import. 3. Run. Make sure to download the proper image for the corresponding hypervisor. When the VM completes its initial start-up, a single command, to attach it to the core node we have set up previously. Ensure there is proper network communication between the two guest Stackato VMs.

$ kato node attach 192.168.68.200 -e dea

Now we have a core node and a dea node. Last but not least, for on-demand provisioning of data services, we will need a data-services node. So here I go again wandering around the office looking for someone to spare me some compute resources. This time, I found someone in our Support group, running Ubuntu desktop for his day-to-day work at ActiveState. I shared to him my goal of this mini project. He willingly spun up a Stackato micro cloud on KVM on this workstation and gave me credentials to it. Perfect! Yes, another 1. Download. 2. Import. 3. Run. Up and running in no time. The last command to make this 3-node Stackato cluster a reality:

$ kato node attach 192.168.68.200 -e data-services