VM Conversion or VM Migration?

  • Article

4727323077_12581f0ef5

When I speak to people about moving VMs over to Hyper-V I generally use the term migrate. I actually differentiate the terms “migration” and “conversion”, at least in the context of VMs (Maybe just because I’m a former English major). Alright, so this certainly isn’t any sort of standard or official convention but I find it helpful to have some distinction between the two terms.

Anyway here’s what these terms mean to me and what they mean in the context of this blog as we move forward.

Conversion [kuhn-vur-zhuhn, -shuhn] n.

1. The act or process of adapting a guest virtual machine to run on anothe hypervisor.

Basically, this means anytime I have a VM that I built elsewhere but I want to run that VM on Hyper-V, I will need to convert the VM. Take a moment and think about what it takes to perform a conversion. Quite a bit, right?

Here’s a list of some general features for a conversion tool:

  • Verify the guest VM is a candidate for conversion
  • Uninstall existing hypervisor drivers from guest
  • Modify the disk format/geometry (out with the vmdk, in with the vhd)
  • Create a new VM on the target hypervisor host based on the settings of the original
  • Mount the disk(s) in the new VM
  • Insert or install device drivers to support the new target hypervisor

Reading that list, I’ll bet you are ready to go and create your own conversion tool now. Okay, maybe not.

It’s really a mixed bag. A lot of the steps above can be scripted through PowerShell or by other means. Actually, most of the conversion functions are scriptable, with one obvious exception.

Converting the disk from .vmdk or .xva to .vhd. Hmm. That sounds, well, you know, hard. Understanding the differences in formats and geometry and then actually making those changes is not the providence of most of us. This is why we reply on the conversion tools. So let’s review some examples of Microsoft’s conversion tools:

V2V

The V2V (Virtual to Virtual) function within System Center Virtual Machine Manager is certainly one of the most widely known converters available. V2V is designed to be run from within the VMM UI or it can be invoked from PowerShell. Because V2V is part of VMM, it isn’t freely available unless you own System Center. If you don’t have System Center (which it is pretty darn awesome) V2V isn’t going to be the tool you rely on.

If you are familiar with V2V and you looked at my list you might think, “Hang on, V2V doesn’t remove the previous hypervisor’s drivers”. That’s true. The list above are steps that should happen during the conversion. The V2V documentation makes it clear that you should be removing existing hypervisor drivers before you start the tool. V2V does implement an xml block list to block drivers from starting on the VM after conversion. How that works exactly and what limitations it has are probably a topic for another post.

MVMC

The Microsoft Virtual Machine Converter is a freely downloadable, stand-alone executable that will convert VMware VMs using a UI or a command line. Unlike V2V, MVMC does cover all the steps listed above. It will even connect to VMware to retrieve a list of VMs to convert. Super helpful. The MVMC is currently Microsoft’s most complete migration solution but naturally, it has some limitations. I think the MVMC deserves a much deeper exploration and probably a post dedicated just to how it works.

Bloggers Note: I know that some P2V tools, like the incredibly cool Disk2vhd can also be used to handle V2V scenarios too. Let’s file that concept away for a later blog too. Boy, we are getting a lot of future blog material here – it’s a gold mine of ideas!

Migration [mahy-grey-shuhn] n.

1. The act or process of converting a virtual environment containing many guest virtual machines so that all the virtual machines can be deployed on another hypervisor.

So if you have a host or a cluster (or lots) then you want to perform a migration on the virtual environment. Fundamentally a migration tool is a conversion tool with a management layer that aids in dealing with multiple VMs.

What are some features a migration tool should have?

A method to create a list of VMs (through discover or import)

Protection of the guest VM (you know in case something unpleasant happens) if the converter does not provide this

  • A persistent datastore to track the state of VM being converted and to hold the list
  • A presentation layer, ideally a full User Interface
    • A way to select which VMs to convert
    • A way to start migration
    • A way to stop the migration or individual conversions
    • A view of current progress of conversions
    • A view of the overall migration status
    • Historical data
  • An engine to allow for the queuing of multiple VMs
  • Some way of storing and presenting user credentials
  • A Sandbox to run a copy of the VM without bringing it up on the real network
  • Error handlers

One of the main focuses of this blog will be to explore how to take a conversion engine, like the MVMC, and create enough management around it that we can call the results a migration tool. Stay tuned – that’s where all this is heading.

Come back next week, when I will tell the story of the three bears of VM Conversions: Hot, cold and warm. Which one is just right?