Hypervisor migrations done fast, efficient, and easy with NetApp Shift

Originally published 9/8/14.



This post will show how migrations between hypervisors can be done fast, space-efficient and painless with NetApp Shift using the NetApp PowerShell Toolkit.



With the emergence of of Hyper-V, KVM, and XEN there have never been so many viable choices for a hypervisor platform. Hypervisors have become a commodity and many users are far more interested in the overlying management stack as opposed to choice in hypervisor. OpenStack and Apache CloudStack have made it very compelling to go with a single management, multi-hypervisor strategy. While those architectures bring many benefits, migrating between hypervisors can be very slow and time consuming, especially in large environments.

The good news is, that NetApp can help! Not only can NetApp speed up the migration process from hours to seconds but NetApp can also do so without requiring additional data footprint to do the migration. NetApp can even help migrate when you are migrating between two hypervisor platforms which are using non-NetApp storage. Read on, and find out how!


NetApp Shift

Before we get into details of NetApp Shift it is important to understand that a VMDK, VHD, or VHDx file consists of metadata which describes the virtual disk and the actual data. Compared to the raw disk data, the metadata is very small and it is the only thing that actually needs to change in order to do a format conversion. Unlike all other hypervisor migration software, NetApp Shift is the only technology which allows you to convert between different VM formats without copying the raw disk data. Compared to the metadata, the raw disk data is usually very large and a full copy consumes a lot of space, and takes a lot of time to copy. As NetApp Shift brings down the conversion process to seconds, offline VM conversations are not as disruptive as when using conventional methods.


How NetApp Shift Works

NetApp Shift creates a file clone of the VM disk we want to convert. NetApp file clones consume zero space and utilize block pointers, thus no data is copied. A new file is created that references the blocks in the old file that we want to convert. Next, NetApp Shift converts the metadata as necessary in the new file, without changing or copying any of the raw disk data.



How to get NetApp Shift technology

NetApp Shift can be consumed using the NetApp PowerShell Toolkit or MAT4Shift which is a collaboration between Microsoft and NetApp.


NetApp PowerShell Toolkit

The NetApp PowerShell Toolkit is a group of PowerShell cmdlets which integrate NetApp value and technology into PowerShell. There are several cmdlets as part of the toolkit which enable NetApp Shift.


For Clustered Data ONTAP we have the following cmdlets:

  • ConvertTo-NcVmdk
  • ConvertTo-NcVhd
  • ConvertTo-NcVhdx


For Data ONTAP 7g the following cmdlets are offered:

  • ConvertTo-NaVmdk
  • ConvertTo-NaVhd
  • ConvertTo-NaVhdx


In the NetApp PowerShell Toolkit the "Nc"-prefix is used to denote Clustered Data ONTAP and "Na" to denote Data ONTAP 7g. The PowerShell cmdlets only convert the VM disk image format and not the VM configuration.



MAT4Shift is written in PowerShell and consumes the NetApp PowerShell Toolkit. The extra value MAT4Shift provides is that in addition to converting the VM disk format, it also converts the VM configuration, such as networking, memory, CPU settings, etc. MAT4Shift only converts VMs from VMware to Hyper-V, even though the NetApp PowerShell Toolkit could go both ways.


Below is a video demonstrating MAT4Shift in action!


NetApp Shift Requirements

Just a few basic requirements:

  • VM images must be on NFS or SMB storage
  • PowerShell and the NetApp PowerShell Toolkit are required


My Experience

I spent a few hours setting up Hyper-V and experimenting with NetApp Shift myself. My experience was very positive and I can truly say that this is not marketing hype or magic tricks, it truly works. In my setup I had a 2012 Hyper-V server and I mounted a NetApp volume with the VMs via SMB3. This volume was previously an NFS datastore connected to VMware. After installing the NetApp PowerShell Toolkit, I opened a PowerShell window and ran the following commands:


  • Import the NetApp Powershell Toolkit so that the cmdlets are available.


PS M:\> Import-Module DataOntap


  • Check the space (in bytes) of the M: drive where the VM we want to convert is located.


PS M:\> Get-WMIObject Win32_LogicalDisk -filter "DriveType=4"

DeviceID     : M:

DriveType    : 4

ProviderName : \\\shift

FreeSpace    : 33740255232

Size         : 51002736640


  • Connect and authenticate to NetApp controller using Connect-NcController cmdlet.


PS M:\> Connect-NcController -name -vserver svm-keith

Name                 Address           Vserver              Version

----                 -------           -------              -------       svm-keith            NetApp Release 8.2.2RC2 Cluster-Mode: Tue Jun 24 23:05:3...


  • Shift VM from VMware (VMDK) to Hyper-V (VHDx). Note: this operation took 3 seconds, which is pretty fast considering that this was a 16GB VM.


PS M:\> ConvertTo-NcVhdx -SourceVmdk M:\test\test.vmdk -DestinationVhdx M:\test.vhdx

Mode                LastWriteTime     Length Name

----                -------------     ------ ----

-a---          9/3/2014   5:59 AM 1718406348 test.vhdx


  • Check the M: drive where the conversion occurred and we notice only 206331904 bytes (or roughly 197MB) space were taken by the new converted VM.


PS M:\> Get-WMIObject Win32_LogicalDisk -filter "DriveType=4"

DeviceID     : M:

DriveType    : 4

ProviderName : \\\shift

FreeSpace    : 33533923328

Size         : 51002736640


Shifting Non-NetApp Environments


I think it is clear how we can use NetApp Shift within NetApp environments to quickly and efficiently migrate between hypervisor platforms. However, what about environments that don't use NetApp storage? Of course, NetApp storage is required since file cloning is a feature only NetApp storage can do, but let's image we had a NetApp Storage system (or got one) for the purpose of a migration. We could connect our non-NetApp storage and NetApp storage to VMware and Hyper-V. Next we could use VM migration (vMotion or live migration) to move VMs from non-NetApp to NetApp storage. We could now use NetApp Shift to shift our hypervisor platform. Finally, we could once again use VM migration (vMotion or live migration) to move VMs from NetApp to non-NetApp storage. If you don't have NetApp storage, this is the perfect excuse to get your hands on a NetApp storage system and make your hypervisor migration pains go away!



That's awesome.

I had a look on the scripts that does such migration (MAT4SHIFT) and there is something weird:


This line 521

Get-Content ('{0}\{1}' -F $NFSPath, $HardDisk.replace('/','\')) | ?{$_ -match '\"(?<file>\S+.vmdk)\"'} | %{



My question is: Why the MAT scripts that are on a Windows machine needs to access to a NFSPath ? Should the content of the variable $NFSPath  be a real NFSPATH or the variable name is misleading and the get-content is performed on a CIFS share anyway ?


Thank you