Select Page

If you’re new to the whole VMware to Hyper-V game, you might not be aware of several tools that exist to make converting VMware virtual machines (and their components) to Hyper-V as easy as 1-2-3.

Microsoft has recently released the latest version (2.0) of it’s excellent Virtual Machine Converter tool that makes conversion of VMware guests to Hyper-V guests a cinch.

I’m not going to duplicate the material that exists all over the web about how to perform live conversions of running VMware guests (p.s. it’s awesome and works 99% of the time) as I’m more interested in the disk options associated to the conversion of VMware VMDK’s into both Hyper-V and Azure ready disk images that can then be attached to virtual machines either on-premises on a Hyper-V host or in the Cloud on an Azure VM.

In this first post of a 2-post series (ahem!) we can start off easy and look at converting a VMware VMDK to a Hyper-V ready VHD/VHDX.

Let’s assume you’ve installed the converter (download from and that the installation went fine.

Part of the installation is a bunch of PowerShell cmdlets that make interacting with the converter super slick for those of us loving the predictable, repeatable juju of PowerShell.

If we take a peek in the folder where the converter was installed, we can see a PoSh module ready for us to use, so let’s load it!

Import-Module mvmccmdlet

Uh-oh! An error.




We’ve been caught out by the fact that the module is not in the module path. No problemo, PowerShell can rescue us.

Here’s a little helper script I knocked together – it will only move the module to the core PSModulePath location so if this is an issue for you, then alter it to meet your needs…

$modulearray = $env:PSModulePath.Split(";")
 foreach ($modulepath in $modulearray) {
 if ($modulepath -match "v1.0") {
 $moduledest = $modulepath+"MvmcCmdlet"
 New-Item -Path $moduledest -ItemType directory
 Get-Childitem -Path "c:\Program Files\Microsoft Virtual Machine Converter" -filter *.dll -recurse | Copy-Item -destination $moduledest -Force
 Get-Childitem -Path "c:\Program Files\Microsoft Virtual Machine Converter" -filter *.psd1 -recurse | Copy-Item -destination $moduledest -Force

Once run, you can import the module happily straight from the shell and even use a little Get-Command fu to find out what we can do from here:

shell fu




Now we’re good to go to actually perform a conversion…

Let’s use ConvertTo-MvmcVhd to convert our VMDK to a VHD/VHDX

Syntax is simple:

ConvertTo-MvmcVirtualHardDisk [-SourceLiteralPath] <string> [[-DestinationLiteralPath] <string>] [[-VhdType] <VhdType> {DynamicHardDisk | FixedHardDisk}] [[-VhdFormat] <VhdFormat> {Vhd | Vhdx}]


-sourceliteralpath is the full path to the source VMDK (inc. filename)

-destinationliteralpath is the full path to the destination VHD/VHDX (inc. filename)

-vhdtype lets us choose Dynamic or Fixed converting dynamic to fixed or leaving as dynamic as required

-vhdformat lets us choose between VHD (older type) and VHDX (newer type) if you have Hyper-V 3 or later you can use VHDX

Let’s give it a spin:

PS C:\Users\Administrator> ConvertTo-MvmcVhd -SourceLiteralPath d:\bigseb\all-in-one-sp2010.vmdk -DestinationLiteralPath e:\bigseb\hypervdisks\all-in-one-sp2010.vhdx -VhdType DynamicHardDisk -VhdFormat Vhdx

Things to note:

  • Give it a while, especially if your source VMDK is large, the cmdlet uses a nice Write-Progress to give us console output on the conversion so all you have to do is let it marinade
  • Once converted, attach to a Hyper-V VM and let ‘er rip!
    • it helps if the new guest config closely matches the source config (i.e. network interfaces, etc.)
  • You’ll need to uninstall VMtools and add integration services

I’ve used the tool on a bunch of VMware disks now, some of which were quite old (I’ve been using Hyper-V for a while but did have some older legacy VMware images) and have had 99% success. To the best of my knowledge, the one failure I have had was caused by a corrupt source VMDK, not many options here.

In a future post, we’ll walk through a conversion to an Azure disk that can be directly sent to an Azure storage account for mounting. Nice.

more to follow…