Testing Multi-Hypervisor Management
Tiered data storage is used in most datacenters today. With tiered data storage, the concept is: Higher priority data needs lower-latency and higher redundancy storage and, as such, is placed on the “gold” level storage tier (which is also the most costly tier). Data that is used less and which is lower priority is put on the much lower-cost “silver” or “bronze” level tiered storage. It makes sense to do this. After all, not all data is equal so you can’t justify it being stored on the most expensive disk arrays when much lower cost arrays work fine for less-used or less-critical company data. It also makes financial sense because organizations that adopt tiered storage save money.
Similar in concept to tiered data storage, tiered hypervisors (or multi-hypervisors) allow you to save money by capitalizing on the latest, but less expensive, hypervisors for lower priority virtual machines (VMs), while keeping the familiar management platform you have in place (along with the hypervisor used for your most critical applications).
In the past, I was opposed to using multiple hypervisors because, at the time, a lack of tools with multiple management silos resulted in a situation that created more management headaches than it was worth. However, with the introduction of new tools such as HotLink’s SuperVISOR, it’s truly possible to have “the best of both worlds” in hypervisors and save money while doing it.
There are a few different approaches to multi-hypervisor management. Of course, the worse case scenario is just managing all the hypervisors in their own silos with their own tools. There are other options like using VMware’s DynamicOps or Microsoft’s System Center to add a management layer on top of all the other hypervisors (usually dubbed “overlay automation”). And, finally, Hotlinks unique approach to manage all hypervisors out of VMware vSphere (as that is the “tier 1” hypervisor that you will use the most).
Thus, Hotlink SuperVISOR and their Hybrid Cloud Express can manage the following hypervisors or clouds through your vSphere client, connected to vCenter-
- Citrix XenServer
- Red Hat Enterprise Linux (KVM)
- Amazon Web Services EC2
Multi-Hypervisor Lab Setup
The thought of creating a multi-hypervisor lab was daunting, at first. Besides the traditional pieces needed for a virtual infrastructure – servers, storage, network, hypervisor, active directory, DNS, virtual machines, and centralized management – I would also need more hypervisors with their own servers, hypervisors, and centralized management. Creating this in a traditional physical server lab would take a lot of work and that was why I decided to do it in a virtual lab.
While a physical lab requires more hardware and time to set up, it’s the recommended option, as you’ll get much better performance (but costs a lot more).
In my case, I evaluated multi-hypervisor management in a virtual lab by using my MacBook laptop running VMware Fusion. My laptop has 8GB of RAM and an SSD drive, giving me the performance to run the multiple VMs required.
I started off with the three VMs that you see in the HotLink folder below, in VMware Fusion.
Figure 1: Fusion 2012 Virtual Machine Library
The three VMs were:
- VMware ESXi 5 VM
- Windows 2008 R2 VM running vCenter and the vSphere Client
- Windows 2008 R2 Hyper-V VM (with a single nested VM already running)
From here, I set off to evaluate Hotlink’s SuperVISOR, as my first ever test of managing multi-hypervisor management (aka “tiered hypervisors).
The basic steps were to:
- Download the Hotlink SuperVISOR evaluation
- Deploy the OVF virtual machine template
- Apply the evaluation license in the web interface of the SuperVISOR VM
- Register the plugin with vCenter and restart the management agents or the VM
- Deploy the management agent on the Hyper-V host (only deployed once per Hyper-V host, not per VM)
- Add a new Hyper-V virtual datacenter and add the Hyper-V host on it (choosing not to install the Hotlink agent on the host as we already installed it)
With everything setup, I had two hypervisors running, each with their own virtual machines, all managed by VMware vCenter, through the vSphere client.
Testing a Multi-Hypervisor Lab
Properly testing a multi-hypervisor lab infrastructure can be tough. You need multiple hypervisors running and one or multiple virtual machines in each of the hypervisors. You need a vCenter server, the vSphere Client, and, in many cases shared storage and AD/DNS. Doing it all, running nested, in a virtual lab is even more of a challenge. However, that’s exactly what I tried.
With my multi-hypervisor lab up and running, I put the lab to the test. The challenge with multiple hypervisors is that everything that you did in hypervisor one should “just work” when you try the exact same thing in hypervisor two. In other words, testing Hotlink (or oher multi-hypervisors) should involve simply doing all the same things that you do every day in the vSphere Client. Examples include accessing the console of a VM, creating a new VM, reconfiguring a VM, cloning a VM, and moving VMs from vSphere to Hyper-V (or from Hyper-V to vSphere). These are exactly the types of things that I tested in my virtual multi-hypervisor lab.
Once I added my Hyper-V host to vCenter, I could see both of my hosts and both of my VMs at the highest level of vCenter (I know that they look the same but one is a Hyper-V host and the other is a VMware ESXi host):
Figure 2: ESXi and Hyper-V Hosts as Seen in vCenter
What the Hotlink “transformation engine” does is to “fool” vCenter into thinking that hosts and VMs from other hypervisors are actually all native VMware vSphere hosts and VMs.
When looking at the vCenter Virtual Machines tab at the vCenter level, I also saw my virtual machines from the two different hypervisors (all appearing as vSphere VMs):
Figure 3: Hyper-V and vSphere Virtual Machines, Shown Together
The top two virtual machines are on the Hyper-V host and the bottom two virtual machines are running on vSphere.
From here, I verified that I could access the console of the Hyper-V virtual machines from inside the vSphere Client. I did this for non-vSphere VMs by right-clicking on the VM, going down to Hotlink, and then clicking Open Console.
Figure 4: Accessing a Hyper-V VM Console Through the vSphere Client
Other typical admin tasks that I could do for the Hyper-V VMs were accessing tasks/events, mapping the virtual infrastructure (all hypervisors and all VMs), viewing performance data, using third-party tools (most of them), taking/managing snapshots, cloning VMs from vSphere to Hyper-V, and more.
In my virtualized multi-hypervisor lab, I was able to run a vSphere host, a Hyper-V host, and a vCenter server. Using just vCenter, I had the ability to perform what are considered vSphere-centric tasks on my Hyper-V host and VMs. For example, host and VM inventory functions work just as they do in vSphere, third-party reporting tools work, and the movement of VMs from Hyper-V to vSphere (or vice versa) functioned exactly as expected.
I really wanted to learn about this now because I feel that this concept of hypervisor tiering may become more and more commonplace. By offering the ability to manage multiple hypervisors and VMs in a single management entity, HotLink enables tremendous efficiencies that make the multi-hypervisor model viable. Like storage, the tiered hypervisor model now makes sense both technically and financially.