I was hoping to get this post out sooner but I’ve been busy this week taking a perfectly good Surface Pro and turning it into a tablet running Windows Server 2012. Fun stuff! Not only did we install Server 2012 on a Surface Pro we decided to create a cluster of Pros and actually carry out some “Shared Nothing” Live Migrations across a Verizon Mifi device. Why not read about our experience here. Don’t try this at home kids. Seriously.
In this post I want to talk about the different types of VM conversions. There are three of them, and kinda like the three bears they are cold, warm and hot. Which is ‘just right’? That’s for you to decide…
Conversion in general is a darn complicated thing, come to think of it so are virtual machines. Computers running inside of other computers is pretty amazing – if you ask me. I also think digital watches are pretty neat.
I grew up working on cars, now I work on VMs, so I like to compare VMs and cars. It’s a flawed analogy on a number of levels but VMs are such an unusual thing, I haven’t found a better analogy (if you have a better one let me know in the comments section).
Now changing a VM from one hypervisor to another is sorta like changing engines in your car. Not just changing the engine but actually changing it out for a motor from a competing car company. Let’s say you have a 1969 Ford Mustang and you want to replace the Boss 302 (4.9 L) engine with the motor from a newer Corvette, maybe a nice GM LS3 (6 L). Why? I dunno. Look, I said it wasn’t a perfect analogy.
The engine will fit, well mostly, and it will produce power in exactly the same way. A GM engine works exactly the same as a Ford engine. Maybe the distributor cap isn’t in the same spot but they are both internal combustion engines: intake, compression, power, exhaust. What needs to be changed? The motor mounts, wiring, cooling and things like that.
If you can talk a mechanic into swapping engines for you, they will almost certainly chose to do so with the car turned off and in their garage. That just seems prudent, right? Most VM conversions are also going to be done cold. Cold means we need to turn the machine off and then convert the hard drives to the new format, make any other required changes and only then start up the VM in a new hypervisor. The tools that Microsoft provides to convert VMs, MVMC and V2V are both examples of cold conversion tools. We carry out the conversion on a machine that has been turned off. This is certainly the easiest method; the machine is off, the environment is static.
The obvious downside to a cold conversion is that the machine must be off. Depending on how large the VM’s drives are and how quickly you are able to transport them to their destination, your VM will be offline for anywhere between a few minutes and a few hours. If you have a service window that is only two hours long and you need to move a 4Tb drive across an OC3 (156 Mbs), simple math tells you there’s a problem. The physics of this situation simply won’t meet your service window.
Often times I work with customers who run into these limits and they can’t change their infrastructure. Physics can be a harsh mistress. If this is the case, cold conversions won’t help you.
Maybe you’re a car owner who doesn’t have time to stop by the mechanic when its time to swap engines. Can’t we swap engines while the car is still rolling down the road? I’ll just throw it in neutral, you think, come to a stop and then drive off with my new motor. That’s pretty crazy but that’s basically what a warm conversion will provide.
A warm conversion limits the down time to a single restart. How is that possible? The trick in warm conversions is done with a file system agent. You install an agent on your source VM, and the agent will send a copy of the current disk structure to the target. Because the source is still running while the agent sends this information, the process can take as long as it needs. Warm conversions can get us around the problems that physics and infrastructure create. So what if it takes two days to get all the information across to my target, as long as my source is still running – anyone using the VM is still happy.
Once the agent has created a copy of the current disk(s) the conversion requires the source VM be shutdown so you can swap to the newly created VM. As the source VM shuts down any final changes are transmitted to the target and both VMs are then identical. At this point you just start up the target VM. Minimal interruption.
The downside to warm conversion tools is that they aren’t free and they are a little more complicated to setup. Microsoft doesn’t have any warm conversion tools at this point but other vendors do. I know customers that have used DoubleTake’s Move with good success.
For my last trick I’m going to swap engines while racing down the highway without taking my foot off the throttle. Crazy? Yes. At this point in time, this just isn’t possible.
A hot conversion would need to take a VM that is running on one hypervisor and move it to a different hypervisor technology all while the VM is powered on. No disruption, no interruption – no way.
As a matter of fact, the idea that we can move a VM from one host to another host (using the same hypervisor technology) while it is still running is a pretty recent notion. VMware introduced this in vCenter 1.0 and Hyper-V only caught up with Windows Server 2008 R2. But to swap competing hypervisors on the fly is not something I’m expecting to see, maybe ever. We would need an Open Virtualization Format (OVF) that expended well past virtual appliances to the guest OS. So hot conversions are just not in the cards.
What all this comes down to then is Cold or Warm and your choice there will depend on your infrastructure, your tolerance for downtime and your budget.