Today Ravello Systems, a company based out of Palo Alto and Israel announced a new beta, a beta that I think is going to go over very well within the VMware community – one that will allow us to spin up vSphere labs, complete with vCenter Server, ESXi hosts, Domain Controllers, Storage and Network services and all the VMs that go with the punch inside of Google and Amazon’s cloud. To be honest I was kind of skeptical when I first started working with Ravello? I mean, come on, an ESXi host in Amazon, let alone and ESXi host running VMs inside of Amazon, an ESXi host running VMs with little to no performance penalty, all running within Amazon – you can see why I might of cringed a bit. But Ravello gave me a shot to try it for myself – and during the introductory chat as they were showing me how things worked I thought, hey, what a use case for the new cross vCenter vMotion capabilities in vSphere 6! A lab in Amazon, a lab in Google Cloud, and VMs migrating between them – how cool is that?
Who and what is Ravello Systems?
Now, before I get into the details of the vMotion itself I want to take a step back and explain a little bit about Ravello Systems themselves, and what they have to offer. Ravello was founded in 2011 with the sole purpose of supporting and driving nested virtualization to the next frontier and did so when they launched their product globally in August of 2013 (You had to of seen the scooters at VMworld 🙂 ) They didn’t just want to simply provide an environment for nested virtualization though, they wanted to make it simple and easy for companies to replicate their data center infrastructure into the public cloud. The core technology behind all of this is their HVX hypervisor – essentially acting as a Cloud VM, sitting in either Amazon or Google and providing overlay networking and storage to the VMs that are placed on top of it.
As per the diagram above the VMs present can be built from scratch or imported via an OVA within Ravello’s very easy to use intuitive interface – but perhaps more interestingly you can utilize the Ravello Import Tool(??), point it to your ESXi host or vCenter, and import VMs directly from your environment into the cloud! But they don’t stop there, Ravello can also detect and create every network your VM is attached to, deploying an exact duplicate of your network infrastructure! Now if this wasn’t good enough for you the beta today announces the ability to support Intel VT through HVX – which means we can now run VMs on top of ESXi on top of HVX on top of Amazon or Google! True inception leaving us with a setup shown in the diagram below.
A great place to break things!
There is a reason why Ravello dubs their technology as having the ability to create “Smart Labs”! Throughout my early access to the solution I broke and fixed so many things within my applications – and Ravello always gave me a way to rebuild or reconstruct my labs in a very efficient manner.
First up we are able to save our VMs to the library – which is essentially a personal set of VMs and images that we can re-use in all of our applications. For example I only had to build my ESXi 6.0 image once – after saving this to the library I was able to simply drag and drop this VM as many times as needed to as many applications as needed, simply re-ip and re-naming after I was done.
Having the ability to re-use VMs is cool but the blueprint functionality that Ravello provides is really where I see value! We are able to take a complete application, in my instance an ESXi host, domain controller, vCenter Server, etc and save the entire application as a blueprint. Blueprints are then available to be used as starting points for new applications – meaning I can build a complete lab on Amazon, save as a blueprint, and then publish a new application to Google which is an exact identical copy, networks and all. Blueprints are an excellent way to test out the different public clouds as well as version or snapshot your entire lab before making any major changes – if things go awry you can simply republish your saved blueprint to a new application.
Enough talk – Let’s see the vMotion!
Alright! Let’s get to it! Let me first warn you, the environment I built to do this was quick and dirty – not a lot of polishing going on here.
The two applications we will be using are Google-vxlan and EC2-vxlan – I’ll let you guess which public clouds each is published to.
As shown above these applications are pretty similar; each containing an Ubuntu server (used to establish the vxlan tunnel between EC2 and Google), a pfSense appliance that provides a VPN for my vMotion networks, a vCenter Server (the Windows version), and an ESXi host (just one for now). The EC2 application also contains a jumpbox VM which provides entry into the local network as well as DNS services.
As far as networking goes the setup at both Amazon and Google is almost identical with the exception of the jumpbox. The 192.168.0.0/24 network is available at both EC2 and Google. The 10.0.0.0/24 network is the only network that is routed to the internet, therefore my only access into the labs outside of the Ravello GUI – this is why the jumpbox also has a connection to this network – to act as an RDP gateway of sorts. The two Ubuntu servers have an elastic public IP attached to them in order to ensure the public IP doesn’t change and mess up my vxlan config. The free trial of Ravello gives you two elastic IPs, and four other DCHP public IPs (subject to changing every now and then). The vxlan tunnel is established between the two elastic IPs in order to provide Layer 2 connectivity between Amazon and Google. The pfSense boxes each have a dynamic public IP attached to them with an IPSEC tunnel established between the 192.168.1.0/24 and the 192.168.2.0/24 networks.
On the VMware side of things I have two vCenters with embedded PSCs (i know – bad practice) – one in Amazon and one in Google, which are attached to the same SSO domain and configured in Enhanced Linked Mode. Therefore whatever is at Google can be seen at Amazon and vice versa. As far as vMotion goes I’ve simply enabled this one my existing management interfaces (more bad practice – but hey, it’s a lab). There is local storage attached to the ESXi hosts and one VM named EC2-VM1 present.
So my goal was to migrate this VM from Amazon to Google and back again, taking both the compute and storage with it. Now just writing about a vMotion is not that exciting so I included a video below so you too can see it move 🙂 It’s my first attempt at a video and had some screaming kids while I made it so yeah, no narration – I’ll try and update with a little tour of the Ravello environment later 🙂
So there you have it – a VM moving from Amazon to Google and back, all while maintaining its’ ping response – pretty cool!
Is Ravello worth it?
So, with all this the question now remains is Ravello worth the cost? Well, considering as how Ravello estimates the cost of a two ESXi Node, vCenter and Storage lab to be on average $0.81 – $1.71 per hour (usage based, no up front costs) I would certainly say it is! The ability to run nested ESXi hosts on top of the public cloud provides a multitude of use-cases for businesses – but honestly I see this being a valuable tools for the community. I plan on using Ravello solely for my home lab usage over the next year or so – it’s just so much nicer to break things and simply re-publish an application than it is to try and rebuild my lab at home. If you want to give Ravello a shot you can sign up for the beta here – Even after the beta expires you simply swipe your credit card and pay Ravello directly – no Amazon accounts, no Google bills – just Ravello! You will be limited during the beta’s and free trials in the amount of CPU, RAM and concurrent powered on VMs but they definitely give you enough resources to get a decent lab setup.
Ravello has a great solution and certainly expect more from me in regards to my lab adventures in the public cloud.