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.

Fixing 'Cannot find wrapper assembly for type library "MSHTML"' After Windows 10 Upgrade

I received the Anniversary update to Windows 10 last week. After doing so, a solution I work on in Visual Studio 2013 would no longer compile.

Visual Studio showed multiple errors along the lines of "Metadata file xxxx.dll could not be found."

Thinking there was more to this than meets the eye, I navigated to Tools->Options. From there, I selected "Projects and Solutions->Build and Run." I increased the MSBuild logging to Normal:



Then, I ran the build and copied the "Output" tab to Notepad++. I searched for "Build Failed" and ran into this line:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(2234,5): warning MSB3283: Cannot find wrapper assembly for type library "MSHTML". Verify that (1) the COM component is registered correctly and (2) your target platform is the same as the bitness of the COM component. For example, if the COM component is 32-bit, your target platform must not be 64-bit.

Thinking that was a bit odd, I opened the references to the project and noticed there was a yellow exclamation mark next to MSHTML. So, I opened the project on my Windows 8.1 virtual machine, and noticed the reference was pointing to an ActiveX control that was registered from a file sitting in the Global Assembly Cache:



Curioius, I wanted to check if this file was in the GAC on my Windows 10 machine. I opened an instance of "Developer Command Prompt for VS2013" (Right-click, Run as Administrator), and entered the following command:

gacutil /l | find "Microsoft.mshtml"

I received a positive hit:


So, I then navigated to C:\Windows\assembly\GAC\Microsoft.mshtml and typed dir to see what folders were there:



I then went into the "7.0.3300.0__b03f5f7f11d50a3a" folder. From there, I registered the assembly using the regasm command:

regasm Microsoft.mshtml.dll

And now my solution compiles once again! Problem solved.

VMWare Workstation SCSI vs SATA Performance

During the many years that I have used VMWare Workstation, I have noticed that there are periodically times where the disk momentarily stops responding and the virtual machines lock up. After the disk has churned for some time, the guest becomes responsive. This may happen several times throughout the day.

I am running a PC with the following specs:

• CPU - Intel Core I7 - 3rd Generation
• RAM - 32 GB
• OS Disk - 256 SATA SSD
• Virtual Machine Disk - 512 SATA SSD
• Operating System - Windows 10
• Hypervisor - VMWare Workstation 12

Today, I decided to try changing out my SCSI virtual disks to SATA virtual disks. I manually modified the .VMX files with the necessary changes.  Much to my surprise, the disk performance increased.

I was previously using the LSI SCSI controller for my virtual disks. But, the periodic freeze behavior was occurring quite often. It was getting so bad that I decided to search the Internet for a solution. My attempt at switching to SATA was a blind stab in the dark.

Having switched to my virtual disks to use the SATA controller, instead of the LSI SCSI controller, I haven't seen as much freezing - almost none. For whatever reason, the higher performing controller was causing my virtual machines to lock up for seconds at a time. The result is that I am achieving far better performance with the SATA controller.