Migrating from VMWare Workstation to Hyper-V

My Reason For Migrating From VMWare Workstation to Hyper-V

I am a long-time user of VMWare Workstation. I have been using it since version 6.0. It has been used to run my personal domain controller, my various development computers, and some test environments. Needless to say, I depend heavily on virtualization. I was very disappointed at some news I recently heard about VMWare.

With the announcement of layoffs at VMWare that took place in January, I began forming a plan for the migration to Hyper-V. VMWare later announced they would continue to maintain their products. However, their plan is to completely outsource the development of those products.

Having worked with large companies that have outsourced some of their development, I have learned first-hand how the quality of a product decreases as the development force of that product is moved off site. My decision to move away from VMWare is to ensure that I continue to experience a hypervisor that is considered a first-class citizen by its owners, and will continue to receive the best attention from the most-skilled developers available. It is my experience that this is an objective that is simply not possible when the development of a product is completely outsourced.

This month, I finally completed my migration of over 20 virtual machines. It was a lot of work. Here are some of the challenges I ran into:

Converting the Virtual Machine

1. The first challenge is to convert the hard disk. I found the easiest method is to do this is to use StarWind V2V Converter. Run it from the command-line, or it will require that there is enough free space for expanded virtual disks - even if they are dynamic.

Note that it was not necessary for me to uninstall VMWare Tools prior to the conversion. I just shut down the guests and ensured there were no snapshots.

Setting Up Networking

The networking set up is not quite so simple if you are using Network Address Translation (NAT). Using Windows 10, it is necessary to set this up using PowerShell:

1. New-VMSwitch -SwitchName "SwitchName" -SwitchType Internal

2. New-NetIPAddress -IPAddress <NAT Gateway IP> -PrefixLength <NAT Subnet Prefix Length> -InterfaceIndex <ifIndex>

3. New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceIndex 24

4. New-NetNat -Name <NATOutsideName> -InternalIPInterfaceAddressPrefix <NAT subnet prefix>

Working With DPI

Windows prevents users from changing DPI settings in a Remote Desktop session. Annoyingly, this also happens to extend to Hyper-V sessions. In order to change DPI, it is necessary to either hack the registry, or to gain access to the console session. I personally prefer the second option.

To gain access to the console session, install TightVNC. After installing the server and setting it up, install the client on another machine. With the client, log into the server. It will then be possible to change DPI settings.