Published
Feb 16 2019 12:24 AM
4,093
Views
First published on TECHNET on Mar 03, 2015
~ Giuseppe Di Federico
I’ve had the opportunity to assist many customers who wanted to migrate their infrastructure from VMware to Microsoft Hyper-V so I wanted to take a minute to highlight some of the best practices I learned along the way.
Customers decide to migrate to Hyper-V for many reasons, including the fact that Hyper-V from the 2012 version and above is finally comparable with VMware, and that VMware is no longer necessarily the best choice as it might have appeared to be some time ago. Another consideration is the cost savings which can be evaluated using the official Microsoft Datacenter TCO Analysis Tool ( http://www.datacentertcotool.com/ ).
When you take your infrastructure to Hyper-V, you can take advantage of the entire Microsoft ecosystem. For example, you can leverage System Center 2012 to fully enable the features that the modern datacenter should have, as shown in the picture below (credits to Gianluca De Rossi).
The modern datacenter topic is a wide one, and there are many resources and blogs talking about Private Cloud, Microsoft Azure Pack, or Software defined something. I strongly encourage you to watch to the Microsoft Virtual Academy course about the topic here: http://www.microsoftvirtualacademy.com/training-courses/system-center-2012-transform-the-datacen... .
The purpose of this article is to focus on the very first step of the transition from VMware to a Microsoft based datacenter: The virtual machine migration.
The first thing to understand when you think of a VMware to Hyper-V transition is that migration is not just a matter of a vmdk that gets turned into a vhd or vhdx. When you migrate a virtual machine, you are taking the machine to a different environment and different virtualization technology. This implies that after the transition, the resources available to the guest will be exposed in a different manner, and the hardware that the machine will perceive should differ as well as each virtualization technology used to install a mix of software and drivers packaged in “Integration Tools” to the guest machine to offer additional services. Such tools differ for each virtualization technology. This means that if you simply believe that turning the vmdk into a vhd or vhdx will complete the job, you are going to see unexpected results when the machine wakes up on the Hyper-V side.
Just to complicate the things a little more, each virtualization technology has its own features and limitations. For example, Hyper-V Generation 1 machines do not support boot from SCSI, and above all they do not support having paging files on a vhd that resides on a SCSI partition. Creating Generation 2 machines only is not the solution because you may have Windows 2008 R2 and below guests that cannot be on Gen2 machines. This means that you have to take into account several factors in advance.
Another thing to take into account is that you cannot assume that once you migrate a machine you have found the formula and you can migrate all the others in the same way. Every machine has its own operating system, its services and its workload that can fail or succeed depending on factors that can be hard to calculate. This means that whatever migration technique you choose, you have to consider that it may be quite complicated if not impossible to fully automatize the migration and the post migration checks.
It is obvious that the Hyper-V infrastructure must be prepared in a way that the migrated VMs will find the same network they used to have when on VMware. It is less obvious that you should spend some extra time to carefully plan network management in advance.
To state it differently, we can say that although creating a virtual switch to expose the target network on the Hyper-V should be enough to start with the guest migration, you have to see it from an higher standpoint: You may want a consistent and centralized network control of all the Hyper-V infrastructure. This is where Virtual Machine Manager comes to play and this is where you should spend some extra time before starting with the migration.
VMware and System Center 2012 R2 Virtual Machine Manager (VMM 2012 R2) have different ways to manage the network. During the initial assessment you should translate the VMware model to the new infrastructure and design it in VMM. You should also take into consideration concepts like network virtualization to take the experience even further.
Although in theory it is possible to migrate the machines by creating every single Virtual Switch on the Hyper-V hosts, that is not necessarily the right way to approach it. Managing the switches from VMM by using a logical switch is definitely the way to go, otherwise you may find many difficulties when you attempt to standardize the network after the migration is complete and the Virtual Switches on the hosts are already in place.
The migration techniques available currently (as of February 2015) do not create the virtual machines in Virtual Machine Manager, but they attach to the Hyper-V hosts directly. At first glance this may not appear to be an issue since VMM by design intercepts the VM hosted on the Hypervisor and adds it to its inventory automatically. However, you should keep in mind that unlike VMM, which sees the whole picture from a centralized standpoint, the Hypervisors see themselves as a unique resource pool. This can lead to some implications. For example, unlike VMM that has a unique MAC Address pool to dispatch to the VM, each Hyper-V host has its own MAC address pool. This means that when your infrastructure is distributed on more Hyper-V hosts, you could have MAC address conflicts if you do not take the proper precautions in advance.
The networking plan is another big topic and we don’t want to go astray, but is important to plan it in advance to avoid headaches. For further reference, I strongly suggest this reading:
http://blogs.technet.com/b/scvmm/archive/2013/02/14/networking-in-vmm-2012-sp1-logical-networks-...
All of the considerations above lead us to believe that an initial assessment on VMware is not only suggested but is critical for a successful migration.
Now let us take this one step further and look at the actual migration. I want to quote what I like to call migration rule number one: “Less is more”. This means that the migration of a virtual machine should occur in as little time as possible regardless of its role and its criticality. We will see later that this is important beyond just minimizing the machines’ downtime.
When it comes to talking about the tool available for an on-premise migration, you will find a several tools, techniques and acronyms that may be a bit confusing. If you are migrating your lab server, use what you want, but if we’re talking about a reliable migration you’ll want to go on reading.
When you download a tool for your migration, you are encouraged to evaluate it using the following principles:
Migration Speed
The most important factor of the migration is the speed, as this not only impacts the machine downtime but also the project’s duration and consequently the cost.
Guest operating system supported
Each migration tool has its own set of guest operating systems that it can migrate. Some tools do not migrate Linux machines while some others may not migrate Windows Server 2003 guests. The choice of the tool to use should be affected by the initial assessment where the different operating systems to be migrated were identified.
Host operating system
The ESX version identified during the initial assessment affects the tool you use. Not all the tools migrate all versions of ESX.
VMware tools automatic removal
A good conversion tool must have this feature. For example, a conversion could be done from the VMM console but it does not remove the VMware tools. This is one reason why I suggest to not use VMM for large scale enterprise wide conversions.
Scalability
This feature allows distributing the migration’s load across different servers. Although this factor does not increase the speed of a single conversion (A single server can manage only a single migration process at time) it can become handy to decrease the overall project’s duration by allowing the migration of more than one VM at the same time.
Support
It is suggested, although not necessarily required, to have a supported tool, especially in an enterprise scenario.
Cost
Some tools are free while others are not. Depending on your specific needs you may consider investing some extra cost in a particular tool.
Backup strategy
As with any large IT related project, unexpected issues can arise, and the more machines you migrate the higher the chance that something might go wrong. Do you need your tool to make a VMware backup/snapshot? Some offer this feature and some do not.
According to the assessment you did in the initial phase, some of the aspects above can matter more than others. There is no one tool to rule them all but keep in mind that the invariant factor that does always matter in my experience is the conversion speed.
If you are looking for a technique that does not introduce downtime at all, it honestly does not exist. Any migration process will introduce downtime. Even if you’re using the fastest migration tool that exists to do some sort of “warm migration”, eventually you always have the “cutover” time when you need to shut down the machine from VMware and turn it on in Hyper-V. Depending on the tool you use, the downtime could be incredibly small or very large (you will figure out that it’s hard to find a midway) but even if it is very short there is always a window when the machine will not provision service.
I will not go into detail of all the migration tools available but I will spend some time on the first ones you typically come across when you search on the web:
MVMC
Microsoft Virtual Machine Converter tool is a Microsoft supported tool that can be downloaded for free . The current version available is 3.0 which can be downloaded here. The new version adds the support for P2V (Physical To Virtual) conversion and it comes with a GUI that allows connecting to the VMware environment in order to pick the machine or the machines you intend to convert. If you intend to use it in an Enterprise scenario you can scale it by leveraging some scripts we will describe later in the MAT section. MVMC does remove the VMware tools from the machine being migrated and takes snapshots from the VM before converting it. The only drawback of this solution is that it can be slow, taking up to 100 minutes to convert a 100 GB VMDK to VHDX (the time come from empiric measurement, it’s not easy to predict the real conversion time in advance). It supports the migration of both Windows (not 2003) and Linux servers and it allows for sending the machine on premise or directly to Windows Azure.
Disk2VHD
This is a standalone tool from Microsoft SysInternals that can be downloaded for free right here . However, this tool is not officially supported and does not scale well. The tool is included not for the migration from VMware to Hyper-V but for its usefulness in performing P2V (Physical to Virtual) conversions and generating virtual hard disks. Therefore, if you run it within a VMware guest pretending to be a physical one, you can achieve a V2V (Virtual to Virtual) migration instead by converting the machine to vhdx. Since the tool is not specifically designed for the V2V migration process, it lacks certain features you may need. For example, it does not remove the VMware Tools and it does not provide an automation mechanism by design, so you should run it per VM. It will perform a snapshot of the VMware machine as is, but as a consequence, if you attempt to attach the generated VHD to Hyper-V the machine will wake up and believe to still be in VMware. As a consequence you will have to take several manual remediation activities (e.g. remove VMware tools, fix networks, etc.). The advantage of this tool is that is faster than MVMC and it’s easier to predict the migration time. It supports the migration of Windows machines only. Its usage is discouraged in Enterprise scenarios.
5nine V2V Easy Converter
5nine V2V Easy Converter is faster than MVMC and it comes in two flavors: Free and licensed. It can be downloaded here . The licensed version allows you to automate the migration process using PowerShell. Despite having to pay to have advanced automation functionality, the free version of the tool is pretty good and it allows you to migrate via the GUI. It does not remove the VMware tools.
And what about MAT?
If you do a little research on V2V migration, you’ll probably hear about MAT (Microsoft Automation Toolkit). I did not mention MAT so far because it is not a migration tool . MAT, indeed, it is a collection of PowerShell scripts used to facilitate the automation and control of the entire migration process in enterprise scenarios. You may have heard acronyms like MAT4MVMC, MAT4SHIFT and MAT4MOVE, where each acronym represents a technique that combines an engine (e.g. MVMC) with the MAT scripts. If you’ve already looked at MAT, you need to understand that MAT is not an unique set of scripts, as it does not exist in an unique flavor. This leads to some confusion at first glance so it’s best to keep this in mind from the beginning. Each tool (or we can say each engine) has its own version of the MAT scripts and the one you use for MVMC (for example) will not work with the other engines.
Despite the fact that MAT scripts differ from engine to engine, the way they all work is similar. The major steps the MAT scripts do are as follows:
Collection phase
MAT connects to ESX to collect information about the machine to be migrated. It stores all the information required on a SQL Server (SQL Express works well). The information it stores should differ according to the engine you use. For instance, MAT4SHIFT stores all the VMware network information, portgroup and so on to do a mapping between Hyper-V and VMware. MAT4MVMC by contrast does not.
Queue definition
Once the information is collected and placed into the database, the user interacts with the MAT to determine which virtual machines to migrate and how long the queue should be. Some engines like MVMC allow you to distribute the queue’s load on across different servers to run the migration process in parallel.
Conversion
When the conversion is triggered, the MAT scripts perform a backup of the target virtual machine, uninstall the VMware tools (if the engine used don’t do it on its own) and pre-stages some scripts to be executed at the next logon, when the machine will be converted and started on the Hyper-V host. After that it shuts the machine down and convert the virtual hard disk.
The interesting part is that since MAT is just a collection of PowerShell scripts, you can customize them as you wish according to the environment needs.
MAT scripts are developed to automate the process, and the techniques that can be used in combination with the MAT are the most effectiveness when you have to migrate large volumes of machines in a reliable way.
The suggested techniques that leverage MAT in an enterprise scenario are the following:
MAT4MVMC
When MVMC is used in combination with MAT you add the opportunity to scale the migration up. The core of MAT4MVMC is the conversion server that represent the core of the migration where you collect and define the queue. You also have the possibility to add helper servers that can pick a machine from the queue and migrate it. The more helper servers you have the more you can parallelize the migration process. Moreover, since MAT has its own database that keeps track of the migration’s status, you can have a real time monitoring on all migrations in progress. Keep in mind though that a migration of a single machine still requires a consistent amount of time.
MAT4MOVE
This version of the MAT scripts use Double-Take MOVE for the engine. Double Take is a third party tool released by Vision Solutions and you can get more info on that here . A nice aspect of this engine is that it requires near-zero downtime. Basically it installs the Double-Take agent on the source VMware guest, where the agent works in kernel mode (as a driver) and works within the Operating System and the File System layers to intercept the changes that occur on the OS. These changes are replicated to the target machine which is kept in sync through the network. The technique is very impressive and requires only the downtime needed to turn on the target machine and switch the source one off. Keep in mind that using the Double-Take software requires an agent license (every virtual machine needs an agent) so there could be an additional cost that should be accounted for.
There’s a chance that these MAT scripts may eventually be deprecated for the Double-Take software, as Vision Solution has recently released the System Center Integration Toolkit . System Center Integration Toolkit enables the user to leverage the System Center 2012 suite to handle the entire migration process. To use this solution you need System Center 2012 Service Manager, System Center 2012 Orchestrator, and have the Double-Take software installed.
MAT4SHIFT
The MAT4SHIFT motto is “Cold migration at warm speed”, and from my experience I can state it’s true. MAT4SHIFT is a technique that combines the agility of the MAT script with the power of the NetApp storage.
The cost of the MAT4SHIFT is null if you already have NetApp Storage in place (it’s needed to fill certain requirements). In case the Hyper-V storage is not NetApp, you can use NetApp storage as transitional storage just for migration purposes by combining the VMware vmotion and the Hyper-V storage migration.
In any case, you need to expose the NetApp storage both via SMB and via NFS, and both VMware and Hyper-V need to access it at the same time.
The NetApp storage can take advantage of a low level shifting of the disk’s blocks to convert a vmdk to vhdx form in 5 to 8 seconds regardless of the disk size. This does not mean that you can take a Virtual Machine from VMware to Hyper-V in 8 seconds since you have to perform pre-migration and post-migration activities but it is very quick.
Here is an illustration on how the block shifting technique works:
The acronym MAT4SHIFT may lead you astray at first glance: it is not a combination between the MAT scripts and the shift engine. Actually there is no shift engine as the word simply refers to the ability of NetApp to shift the blocks. The real engine that works behind the scenes is Data ONTAP. Data ONTAP is a PowerShell module that NetApp made available to its customers. Importing the Data ONTAP module provides access to more than 528 cmdlets that allow you to submit commands to the NetApp device from a Windows computer. These cmdlets are used by the MAT scripts to convert the VMDK to VHDX (more specifically the cmdlet ConvertTo-NcVhdx does the magic) in a time that is incredibly fast. Moreover, the Flexclone technique is used to make a backup of the vmdk in constant time (more specifically New-NCClone connects to the storage and can duplicate a file or a volume in milliseconds regardless of its size) and if something goes wrong the backup is restored and the VMware machine left unaffected.
MAT4SHIFT currently can only migrate Windows machines only, but if this fits your needs then this one you’ll really want to take a close look at.
As you probably already knew, the transition to another virtualization platform is a big deal. It’s not just a matter of changing the virtual hard disk, it’s a complex end-to-end process that can be achieved in a few different ways and must be evaluated for each scenario.
The speed of the migration is the most critical factor and you have to apply the concept explained here with the goal to achieve a migration in as little time as possible. In short, it is strongly recommended that you use supported tools only and to not start the conversion until a full assessment has done in advance.
NOTE This articles references certain 3rd party products which may entail additional costs. 3rd party products are not supported under any Microsoft standard support program or service. The information here is provided AS IS without warranty of any kind. Microsoft disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of these solutions remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use this documentation, even if Microsoft has been advised of the possibility of such damages.
Giuseppe Di Federico | Consultant | Microsoft Consulting Services
Get the latest System Center news on Facebook and Twitter :
System Center All Up: http://blogs.technet.com/b/systemcenter/
Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
Data Protection Manager Team blog: http://blogs.technet.com/dpm/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
Microsoft Intune: http://blogs.technet.com/b/microsoftintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The RMS blog: http://blogs.technet.com/b/rms/
App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv
The Surface Team blog: http://blogs.technet.com/b/surface/
The Application Proxy blog: http://blogs.technet.com/b/applicationproxyblog/
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
~ Giuseppe Di Federico
I’ve had the opportunity to assist many customers who wanted to migrate their infrastructure from VMware to Microsoft Hyper-V so I wanted to take a minute to highlight some of the best practices I learned along the way.
Customers decide to migrate to Hyper-V for many reasons, including the fact that Hyper-V from the 2012 version and above is finally comparable with VMware, and that VMware is no longer necessarily the best choice as it might have appeared to be some time ago. Another consideration is the cost savings which can be evaluated using the official Microsoft Datacenter TCO Analysis Tool ( http://www.datacentertcotool.com/ ).
The modern datacenter by Microsoft
When you take your infrastructure to Hyper-V, you can take advantage of the entire Microsoft ecosystem. For example, you can leverage System Center 2012 to fully enable the features that the modern datacenter should have, as shown in the picture below (credits to Gianluca De Rossi).
The modern datacenter topic is a wide one, and there are many resources and blogs talking about Private Cloud, Microsoft Azure Pack, or Software defined something. I strongly encourage you to watch to the Microsoft Virtual Academy course about the topic here: http://www.microsoftvirtualacademy.com/training-courses/system-center-2012-transform-the-datacen... .
The purpose of this article is to focus on the very first step of the transition from VMware to a Microsoft based datacenter: The virtual machine migration.
Ok, let’s transform a bunch of VMDK into VHDX…
The first thing to understand when you think of a VMware to Hyper-V transition is that migration is not just a matter of a vmdk that gets turned into a vhd or vhdx. When you migrate a virtual machine, you are taking the machine to a different environment and different virtualization technology. This implies that after the transition, the resources available to the guest will be exposed in a different manner, and the hardware that the machine will perceive should differ as well as each virtualization technology used to install a mix of software and drivers packaged in “Integration Tools” to the guest machine to offer additional services. Such tools differ for each virtualization technology. This means that if you simply believe that turning the vmdk into a vhd or vhdx will complete the job, you are going to see unexpected results when the machine wakes up on the Hyper-V side.
Just to complicate the things a little more, each virtualization technology has its own features and limitations. For example, Hyper-V Generation 1 machines do not support boot from SCSI, and above all they do not support having paging files on a vhd that resides on a SCSI partition. Creating Generation 2 machines only is not the solution because you may have Windows 2008 R2 and below guests that cannot be on Gen2 machines. This means that you have to take into account several factors in advance.
Another thing to take into account is that you cannot assume that once you migrate a machine you have found the formula and you can migrate all the others in the same way. Every machine has its own operating system, its services and its workload that can fail or succeed depending on factors that can be hard to calculate. This means that whatever migration technique you choose, you have to consider that it may be quite complicated if not impossible to fully automatize the migration and the post migration checks.
Let’s take some wires to the Hyper-V hosts
It is obvious that the Hyper-V infrastructure must be prepared in a way that the migrated VMs will find the same network they used to have when on VMware. It is less obvious that you should spend some extra time to carefully plan network management in advance.
To state it differently, we can say that although creating a virtual switch to expose the target network on the Hyper-V should be enough to start with the guest migration, you have to see it from an higher standpoint: You may want a consistent and centralized network control of all the Hyper-V infrastructure. This is where Virtual Machine Manager comes to play and this is where you should spend some extra time before starting with the migration.
VMware and System Center 2012 R2 Virtual Machine Manager (VMM 2012 R2) have different ways to manage the network. During the initial assessment you should translate the VMware model to the new infrastructure and design it in VMM. You should also take into consideration concepts like network virtualization to take the experience even further.
Although in theory it is possible to migrate the machines by creating every single Virtual Switch on the Hyper-V hosts, that is not necessarily the right way to approach it. Managing the switches from VMM by using a logical switch is definitely the way to go, otherwise you may find many difficulties when you attempt to standardize the network after the migration is complete and the Virtual Switches on the hosts are already in place.
The migration techniques available currently (as of February 2015) do not create the virtual machines in Virtual Machine Manager, but they attach to the Hyper-V hosts directly. At first glance this may not appear to be an issue since VMM by design intercepts the VM hosted on the Hypervisor and adds it to its inventory automatically. However, you should keep in mind that unlike VMM, which sees the whole picture from a centralized standpoint, the Hypervisors see themselves as a unique resource pool. This can lead to some implications. For example, unlike VMM that has a unique MAC Address pool to dispatch to the VM, each Hyper-V host has its own MAC address pool. This means that when your infrastructure is distributed on more Hyper-V hosts, you could have MAC address conflicts if you do not take the proper precautions in advance.
The networking plan is another big topic and we don’t want to go astray, but is important to plan it in advance to avoid headaches. For further reference, I strongly suggest this reading:
http://blogs.technet.com/b/scvmm/archive/2013/02/14/networking-in-vmm-2012-sp1-logical-networks-...
One migration tool to rule them all … or not?
All of the considerations above lead us to believe that an initial assessment on VMware is not only suggested but is critical for a successful migration.
Now let us take this one step further and look at the actual migration. I want to quote what I like to call migration rule number one: “Less is more”. This means that the migration of a virtual machine should occur in as little time as possible regardless of its role and its criticality. We will see later that this is important beyond just minimizing the machines’ downtime.
When it comes to talking about the tool available for an on-premise migration, you will find a several tools, techniques and acronyms that may be a bit confusing. If you are migrating your lab server, use what you want, but if we’re talking about a reliable migration you’ll want to go on reading.
When you download a tool for your migration, you are encouraged to evaluate it using the following principles:
Migration Speed
The most important factor of the migration is the speed, as this not only impacts the machine downtime but also the project’s duration and consequently the cost.
Guest operating system supported
Each migration tool has its own set of guest operating systems that it can migrate. Some tools do not migrate Linux machines while some others may not migrate Windows Server 2003 guests. The choice of the tool to use should be affected by the initial assessment where the different operating systems to be migrated were identified.
Host operating system
The ESX version identified during the initial assessment affects the tool you use. Not all the tools migrate all versions of ESX.
VMware tools automatic removal
A good conversion tool must have this feature. For example, a conversion could be done from the VMM console but it does not remove the VMware tools. This is one reason why I suggest to not use VMM for large scale enterprise wide conversions.
Scalability
This feature allows distributing the migration’s load across different servers. Although this factor does not increase the speed of a single conversion (A single server can manage only a single migration process at time) it can become handy to decrease the overall project’s duration by allowing the migration of more than one VM at the same time.
Support
It is suggested, although not necessarily required, to have a supported tool, especially in an enterprise scenario.
Cost
Some tools are free while others are not. Depending on your specific needs you may consider investing some extra cost in a particular tool.
Backup strategy
As with any large IT related project, unexpected issues can arise, and the more machines you migrate the higher the chance that something might go wrong. Do you need your tool to make a VMware backup/snapshot? Some offer this feature and some do not.
According to the assessment you did in the initial phase, some of the aspects above can matter more than others. There is no one tool to rule them all but keep in mind that the invariant factor that does always matter in my experience is the conversion speed.
I’ve got no problem, so can I do a “warm migration”?
If you are looking for a technique that does not introduce downtime at all, it honestly does not exist. Any migration process will introduce downtime. Even if you’re using the fastest migration tool that exists to do some sort of “warm migration”, eventually you always have the “cutover” time when you need to shut down the machine from VMware and turn it on in Hyper-V. Depending on the tool you use, the downtime could be incredibly small or very large (you will figure out that it’s hard to find a midway) but even if it is very short there is always a window when the machine will not provision service.
An overview on the migration tools
I will not go into detail of all the migration tools available but I will spend some time on the first ones you typically come across when you search on the web:
MVMC
Microsoft Virtual Machine Converter tool is a Microsoft supported tool that can be downloaded for free . The current version available is 3.0 which can be downloaded here. The new version adds the support for P2V (Physical To Virtual) conversion and it comes with a GUI that allows connecting to the VMware environment in order to pick the machine or the machines you intend to convert. If you intend to use it in an Enterprise scenario you can scale it by leveraging some scripts we will describe later in the MAT section. MVMC does remove the VMware tools from the machine being migrated and takes snapshots from the VM before converting it. The only drawback of this solution is that it can be slow, taking up to 100 minutes to convert a 100 GB VMDK to VHDX (the time come from empiric measurement, it’s not easy to predict the real conversion time in advance). It supports the migration of both Windows (not 2003) and Linux servers and it allows for sending the machine on premise or directly to Windows Azure.
Disk2VHD
This is a standalone tool from Microsoft SysInternals that can be downloaded for free right here . However, this tool is not officially supported and does not scale well. The tool is included not for the migration from VMware to Hyper-V but for its usefulness in performing P2V (Physical to Virtual) conversions and generating virtual hard disks. Therefore, if you run it within a VMware guest pretending to be a physical one, you can achieve a V2V (Virtual to Virtual) migration instead by converting the machine to vhdx. Since the tool is not specifically designed for the V2V migration process, it lacks certain features you may need. For example, it does not remove the VMware Tools and it does not provide an automation mechanism by design, so you should run it per VM. It will perform a snapshot of the VMware machine as is, but as a consequence, if you attempt to attach the generated VHD to Hyper-V the machine will wake up and believe to still be in VMware. As a consequence you will have to take several manual remediation activities (e.g. remove VMware tools, fix networks, etc.). The advantage of this tool is that is faster than MVMC and it’s easier to predict the migration time. It supports the migration of Windows machines only. Its usage is discouraged in Enterprise scenarios.
5nine V2V Easy Converter
5nine V2V Easy Converter is faster than MVMC and it comes in two flavors: Free and licensed. It can be downloaded here . The licensed version allows you to automate the migration process using PowerShell. Despite having to pay to have advanced automation functionality, the free version of the tool is pretty good and it allows you to migrate via the GUI. It does not remove the VMware tools.
And what about MAT?
If you do a little research on V2V migration, you’ll probably hear about MAT (Microsoft Automation Toolkit). I did not mention MAT so far because it is not a migration tool . MAT, indeed, it is a collection of PowerShell scripts used to facilitate the automation and control of the entire migration process in enterprise scenarios. You may have heard acronyms like MAT4MVMC, MAT4SHIFT and MAT4MOVE, where each acronym represents a technique that combines an engine (e.g. MVMC) with the MAT scripts. If you’ve already looked at MAT, you need to understand that MAT is not an unique set of scripts, as it does not exist in an unique flavor. This leads to some confusion at first glance so it’s best to keep this in mind from the beginning. Each tool (or we can say each engine) has its own version of the MAT scripts and the one you use for MVMC (for example) will not work with the other engines.
Despite the fact that MAT scripts differ from engine to engine, the way they all work is similar. The major steps the MAT scripts do are as follows:
Collection phase
MAT connects to ESX to collect information about the machine to be migrated. It stores all the information required on a SQL Server (SQL Express works well). The information it stores should differ according to the engine you use. For instance, MAT4SHIFT stores all the VMware network information, portgroup and so on to do a mapping between Hyper-V and VMware. MAT4MVMC by contrast does not.
Queue definition
Once the information is collected and placed into the database, the user interacts with the MAT to determine which virtual machines to migrate and how long the queue should be. Some engines like MVMC allow you to distribute the queue’s load on across different servers to run the migration process in parallel.
Conversion
When the conversion is triggered, the MAT scripts perform a backup of the target virtual machine, uninstall the VMware tools (if the engine used don’t do it on its own) and pre-stages some scripts to be executed at the next logon, when the machine will be converted and started on the Hyper-V host. After that it shuts the machine down and convert the virtual hard disk.
The interesting part is that since MAT is just a collection of PowerShell scripts, you can customize them as you wish according to the environment needs.
MAT scripts are developed to automate the process, and the techniques that can be used in combination with the MAT are the most effectiveness when you have to migrate large volumes of machines in a reliable way.
The suggested techniques that leverage MAT in an enterprise scenario are the following:
MAT4MVMC
When MVMC is used in combination with MAT you add the opportunity to scale the migration up. The core of MAT4MVMC is the conversion server that represent the core of the migration where you collect and define the queue. You also have the possibility to add helper servers that can pick a machine from the queue and migrate it. The more helper servers you have the more you can parallelize the migration process. Moreover, since MAT has its own database that keeps track of the migration’s status, you can have a real time monitoring on all migrations in progress. Keep in mind though that a migration of a single machine still requires a consistent amount of time.
MAT4MOVE
This version of the MAT scripts use Double-Take MOVE for the engine. Double Take is a third party tool released by Vision Solutions and you can get more info on that here . A nice aspect of this engine is that it requires near-zero downtime. Basically it installs the Double-Take agent on the source VMware guest, where the agent works in kernel mode (as a driver) and works within the Operating System and the File System layers to intercept the changes that occur on the OS. These changes are replicated to the target machine which is kept in sync through the network. The technique is very impressive and requires only the downtime needed to turn on the target machine and switch the source one off. Keep in mind that using the Double-Take software requires an agent license (every virtual machine needs an agent) so there could be an additional cost that should be accounted for.
There’s a chance that these MAT scripts may eventually be deprecated for the Double-Take software, as Vision Solution has recently released the System Center Integration Toolkit . System Center Integration Toolkit enables the user to leverage the System Center 2012 suite to handle the entire migration process. To use this solution you need System Center 2012 Service Manager, System Center 2012 Orchestrator, and have the Double-Take software installed.
MAT4SHIFT
The MAT4SHIFT motto is “Cold migration at warm speed”, and from my experience I can state it’s true. MAT4SHIFT is a technique that combines the agility of the MAT script with the power of the NetApp storage.
The cost of the MAT4SHIFT is null if you already have NetApp Storage in place (it’s needed to fill certain requirements). In case the Hyper-V storage is not NetApp, you can use NetApp storage as transitional storage just for migration purposes by combining the VMware vmotion and the Hyper-V storage migration.
In any case, you need to expose the NetApp storage both via SMB and via NFS, and both VMware and Hyper-V need to access it at the same time.
The NetApp storage can take advantage of a low level shifting of the disk’s blocks to convert a vmdk to vhdx form in 5 to 8 seconds regardless of the disk size. This does not mean that you can take a Virtual Machine from VMware to Hyper-V in 8 seconds since you have to perform pre-migration and post-migration activities but it is very quick.
Here is an illustration on how the block shifting technique works:
The acronym MAT4SHIFT may lead you astray at first glance: it is not a combination between the MAT scripts and the shift engine. Actually there is no shift engine as the word simply refers to the ability of NetApp to shift the blocks. The real engine that works behind the scenes is Data ONTAP. Data ONTAP is a PowerShell module that NetApp made available to its customers. Importing the Data ONTAP module provides access to more than 528 cmdlets that allow you to submit commands to the NetApp device from a Windows computer. These cmdlets are used by the MAT scripts to convert the VMDK to VHDX (more specifically the cmdlet ConvertTo-NcVhdx does the magic) in a time that is incredibly fast. Moreover, the Flexclone technique is used to make a backup of the vmdk in constant time (more specifically New-NCClone connects to the storage and can duplicate a file or a volume in milliseconds regardless of its size) and if something goes wrong the backup is restored and the VMware machine left unaffected.
MAT4SHIFT currently can only migrate Windows machines only, but if this fits your needs then this one you’ll really want to take a close look at.
Conclusion
As you probably already knew, the transition to another virtualization platform is a big deal. It’s not just a matter of changing the virtual hard disk, it’s a complex end-to-end process that can be achieved in a few different ways and must be evaluated for each scenario.
The speed of the migration is the most critical factor and you have to apply the concept explained here with the goal to achieve a migration in as little time as possible. In short, it is strongly recommended that you use supported tools only and to not start the conversion until a full assessment has done in advance.
NOTE This articles references certain 3rd party products which may entail additional costs. 3rd party products are not supported under any Microsoft standard support program or service. The information here is provided AS IS without warranty of any kind. Microsoft disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of these solutions remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use this documentation, even if Microsoft has been advised of the possibility of such damages.
Giuseppe Di Federico | Consultant | Microsoft Consulting Services
Get the latest System Center news on Facebook and Twitter :
System Center All Up: http://blogs.technet.com/b/systemcenter/
Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
Data Protection Manager Team blog: http://blogs.technet.com/dpm/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
Microsoft Intune: http://blogs.technet.com/b/microsoftintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The RMS blog: http://blogs.technet.com/b/rms/
App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv
The Surface Team blog: http://blogs.technet.com/b/surface/
The Application Proxy blog: http://blogs.technet.com/b/applicationproxyblog/
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
1 Comment