Owen Reynolds Personal blog

As an IT consultant , I’m asked to assist a wide variety of tasks. Last fall , I worked on a project to convert 21 Hyper-V VMs to ESXi.

Normally, you’d use the VMware vSphere stand-alone converter for such a task, however, VMware pulled the tool in Feb of 2022, only to add it back in October 2022
Read about it here

As such, that left me the third party StarWinds V2V converter. Also great, but not as feature-rich as the VMWare tool. One key feature missing ; is adding VMware tools to the ESXi converted VM. Powershell to the rescue!

The script

I’ve had PS code to automate VMware tools re-installs for about 2 years via my Packer windows build automation work Powershell. See HERE

I’ve been writing PS code since 2015, I’ve done courses, read blogs, free-styled, and made a lot of mistakes along the way. Despite zero background in formal programming, I am a planning based person in all that I do. For scripts I’ll use with clients that are more than a few lines, I’ll create a bullet-point based design to write out what I want to do

For this project, the key functions of the new script were as follows:

Source

• Collect IP / DNS info and log to a CSV for re-entry on converted VM
• ID VM type (Hyper-V or VMware ESXi)
• Create local user & set autologon reg keys
• Gracefully power off the VM

Destination VM

• Detect VM type
• Automate the install of VMware tools
• Add back IP recorded from source VM from saved CSV file
• Remove traces of Hyper-V ghost devices
• Remove AutoLogon once done
• Reboot the VM for a clean VMware tools install

Here is the code

The script requires just 3 files, a recent VMware tools install.exe, the scheduled task XML, and the .ps1 script. The .ps1 script will setup the sched task to run in the system context on the next boot

I won’t post the code in it’s entirety, you can view it on Github here

https://github.com/getvpro/Start-PostV2V

Change the password on line 653, no other edits should be required

High-level steps for Hyper-V to ESXi conversion

• Logon to the source hyper-v VM
• Download the files for the script to c:\admin
• If the source VM is an application server, ensure to review any app config that can be used to test out the application functionality once the VM is converted, think SQL to NIC bindings, services that auto-start, etc
• Take screenshots of attached drives as required
• Run the script, the VM will be gracefully powered off at the end
• Convert the VM via StarWinds V2V or VMware stand-alone converter
• With the VM conversion completed, find the VM within your VMware environment and validate it’s got all the existing drives connected, and is set to the correct network

Notes from the migration

The project I was working on included 21 VMs, 20 windows VMs, 1 Linux VM. Most of the conversions went smooth, a few did not. Here are some issues I noted that you might find useful should you find yourself going through a similar hypervisor VM type conversion

• Domain controllers will generate a LOT of noise when they boot up without a network card installed. Running DCDIAG on converted VMs will show time sync issues , in my case, the errors were resolved after a few hours. If you want to validate the integrity of your AD domain after converting an AD DC , run dcdiag /s OLDSERVERNAMEHERE on one of your existing AD DCs. I didn’t know this before, but running DCDIAG without any switches will AD related event logs from all DCs in the forest, running DCDIAG /S and targeting an existing DC should show a clean result. Open ‘active directory users & computers’ from the converted VM, and create a new AD OU and check that you can see from the newly created OU from an existing DC
• On at least one Oracle server we converted as part of the project, we had failures of services that were previously starting. To resolve it, we set them to ‘automatic (delayed start). Regardless, always check that all custom services installed on application servers are started as they were before
• The Hyper-V converted VHD(x) drives will be VMDK format once converted to an ESXi VM. The drive letters should be the same once the windows VM is booted up again. however, in a few cases, the source Hyper-V VM was gen 1 type, the destination VM was created with an IDE controller, instead, it should have been SCSI (LSI corp to start), re-map the drives on the properties of the ESXI VM to match how they were set before. C drive will be drive 1, D drive will be drive 2, etc. Else, you can run into boot issues if you try to boot windows from a data drive
• Expect the unexpected. During the migration, we had a hardware failure on one of the Hyper-V hosts, it occurred just as we were about to convert a large database VM. My advice is to schedule conversions on critical VMs after-hours
• Benchmark file copy speeds with large files between source and destination hosts ahead of time. In this way, you’ll know how long it should take to copy over each VM, and you can adjust the schedule with your client appropriately Thankfully, my client’s source / destination storage network was running at about 500 MB/sec, which meant for some quick conversion times

A Hyper-V to ESXi conversion is pretty niche, however, I learned a lot on this project and really enjoyed thew work. I hope you find the related script / notes provided useful should you be tasked with a similar work effort

Owen