Automating VM Migration - VMM and V2V (Part 1)

sheep

I’ve mentioned Microsoft’s two VM conversion tools before but I wanted to spend some time digging a little deeper into both. I’m starting with VMM’s V2V which has been in market (in one version or another) for a few years now.

What is V2V?

V2V is shorthand for System Center Virtual Machine Manager 2012 SP1’s (VMM) ability to convert virtual machines built on a VMware hypervisor.  But you already knew that VMM provides the means to convert a VM from VMware, right? Most folks do. VMM provides a ‘Convert Virtual Machine’ wizard (It’s under Create Virtual Machine/Convert Virtual Machine) that walks you through the process. It’s a nice UI too, feels roomy.

Before I go any further it is only fair to mention that VMM is a component of System Center and that System Center isn’t free. Still, most customers I talk to are moving from a managed VMware environment (which is to say vCenter) so it seems reasonable to assume they will want management of those same assets on Hyper-V. If it turns out you are not in this situation, which is to say you don’t own System Center and you don’t plan to get it, then you should consider using MVMC.exe. I will create a series of posts on automating MVMC once I complete this V2V series.

Before we can automate V2V, we need to understand exactly how it works. So let’s start with the basics.

What happens:

What actually happens when you convert a VM using the V2V Wizard or the New-SCV2V cmdlet? Well there are three stages:

  1. The first stage is that VMM creates a new VM with the parameters you specified, CPU, memory, name, that kinda stuff. This information is stored in the vmx file and we use that to collect this information. Basically step one is about creating a VM “shell” that will accept the disks that will be converted.
  2. Convert the disk(s). Your vmdk files need to be transmogrified into vhds. This is where the disk geometry is converted from the format that VMware uses to the one that Hyper-V uses. As it does this. it also sends the actual file to the destination. So the disk conversion takes the vmdk file from the VMM library and converts it, sending the resulting vhd file to your Hyper-V host. It does this using BITS over HTTPS (not trying to brag or anything, just sayin’).
  3. The last stage is to make the operating system of the guest “virtualizeable”. That’s probably not a real a word. But we need to modify the guest OS so that it can run properly under Hyper-V. What this comes down to is installing the VM components which are a collection of useful things we now call “Integration Services“ these may include:
      • Hyper-V Data Exchange Service
      • Hyper-V Guest Shutdown Service
      • Hyper-V Heartbeat Service
      • Hyper-V Key/Value Pair Exchange
      • Hyper-V Remote Desktop Virtualization Service
      • Hyper-V Time Synchronization Service
      • Hyper-V Virtual Machine Management
      • Hyper-V Volume Shadow Copy Requestor
      • Virtual Machine Connection Enhancements
      • Virtual drivers and Hyper-visor aware kernel

You’ll be glad to know all that is done automatically, because that is quite the list! To do this, Hyper-V will start the VM, install the components. It also tries to block any services or applications that would keep the VM from booting the first time. Then shut the VM back down and you are ready to go. This way as soon as you access the machine after conversion, everything works like it should and you aren’t forced to reboot.

If someone tells you that a V2V is mostly just about converting the vmdk to a vhd, you can tell them… well actually - they’re sorta right. In terms of time spent on the process, the conversion is the hard part. The vmx file has all the details about the machine and tell us how to make another one that looks just like it. Creating a VM is pretty quick and getting integration services running (even if it requires the VM to be booted and shutdown) goes pretty quick. But getting the bits off the VMMLibrary and onto the target server while swapping the disk geometry – that takes a while.

Note: Unless you happen to be using NetApp for your storage. In that case, they have a nifty PowerShell cmdlet. This thing can change vmdk the formats in like 2 seconds, my brother knows a kid who saw them do that on the playground… it was two towns over. Seriously though, the NetApp in-place conversion can convert a 32 Gb flat vmdk to a fixed vhdx in 63 seconds. That’s around 44x faster than just copying a 32 Gb file on the wire. If you’re using NetApp, you should definitely check it out.

Check, Double-Check, Re-Check (requirements):

Before you can start the V2V you need to bring your VM files into a VMM Library. But, naturally, not every VM is supported so here’s a couple of lists with the particulars:

ESX hosts

VMM supports the V2V machine conversion of virtual machines that had been running on the following versions of VMware ESX hosts:

  • ESX/ESXi 3.5 Update 5
  • ESX/ESXi 4.0
  • ESX/ESXi 4.1
  • ESXi 5.1

The V2V process takes the VM files from the VMM Library so the only concern here is a supported ESX host version. What version of vCenter or vSphere doesn’t factor into any of this since we aren’t talking to the management layer for the conversion.

You also need to make sure your source virtual machine contains one of the following operating systems:

  • Microsoft Windows 2000 Server with Service Pack 4 (SP4) or later
  • Windows Server 2003 SP1 or later
  • Windows Server 2003 R2 or later
  • Windows Server 2008 or later
  • Windows XP SP1 or later
  • Windows Vista

 

Automate this!

V2V can either be executed from the Convert Virtual Machine Wizard or via PowerShell. As you have probably noticed, and if you haven’t you really should pay more attention, there’s a “View Script” button at the end of VMM wizards. This means that the wizard is just setting up a PowerShell command or series of commands to execute the action. Clearly you could run the wizard for every VM you want to convert but going in and clicking on one VM at a time is little annoying if you have a big batch to convert. We need to automate our migration.

Migration and automation you say?

Call me Migr-Automation Mark. No wait - scratch that. Migra-mation Mark? Um, okay, maybe not.

Let’s just stick with Migration Mark, I already printed up business cards.

Anyway... the point of this series of posts is all about how you might go about automating conversions (i.e. migrating) with V2V. We have covered what happens with V2V and what versions of everything you need to be sure this works, so let’s start talking about automating. 

Up Next: Removing the VMware components