- Trim characters from strings in PowerShell - Tue, Mar 14 2023
- Set Chrome, Firefox and Edge as default mail client (mailto handlers) - Mon, Mar 6 2023
- Show or hide users on the logon screen with Group Policy - Thu, Mar 2 2023
There are several reasons why workloads are still being run in first-generation VMs. Often, they have been around for a few years and were created under a version of Hyper-V that only supports Gen 1 VMs. They can still be used under a newer version of the hypervisor and are fully supported.
Conversely, it is also possible that a version of Windows was originally installed in the VM that only supports VMs Gen 1. The guest OS may have been updated in the meantime, but it is trapped in the old VM.
Generation 1 is still preselected in the Hyper V Manager for new VMs
Finally, of course, it can happen that Gen 1 is inadvertently selected when creating a VM, as this is still the default in Hyper-V Manager.
Advantages of Generation 2
One of the most important advantages of the newer VMs is higher performance, because the guest OS "knows" that it is running on a hypervisor and therefore no hardware needs to be emulated. Gen 2 VMs support only virtual SCSI controllers, and VHDs attached to them can be hot-added, removed, and resized at run-time. Network adapters can also be added while the system is active.
If you want to set up a VM based on UEFI, you can only do this with a generation 2 VM, which means that Secure Boot is only available there. Gen 1 virtual machines, on the other hand, only support BIOS and are therefore limited to the MBR layout of the disks. This proves to be the main hurdle during migration.
Finding old VMs
The first step will be to get an overview to see which VMs are still Gen 1. With PowerShell, it is relatively easy to find this out:
Get-VM | select vmname, generation
This command lists all virtual machines on the local host and prints their names and generation.
Listing all VMs on the local host including name and generation
Basically, you can now start to convert the old VMs. However, this is not possible if the guest OS is older than Windows Server 2012 R2 or is a 32-bit version.
Therefore, you have to find out which OS is installed in a VM. If it is switched on, this can be determined relatively easily via WMI:
Get-CimInstance -ComputerName <myComputer> -ClassName win32\_operatingsystem | select Caption, OSArchitecture
Finding out the name and bit width of the guest OS via WMI
If, on the other hand, a VM is switched off, you would have to mount the VHD containing the system partition and look inside.
Changing disk layout to GPT
Once you have determined which VMs are suitable for conversion, you should first update the guest OS to the version of Windows you have intended for the new environment.
Then convert the system drive to GPT. Since Windows 10 1703, Microsoft provides MBR2GPT.exe for this purpose. You access it on a live system like this:
mbr2gpt.exe /convert /allowFullOS
The tool is located in %SystemRoot%\system32 and can easily be copied to other computers if it is not available there. This applies to Windows servers, for example.
In the case of older OS versions, however, Microsoft recommends shutting down the VM, booting from a current Windows PE, and starting the conversion to GPT from there. The command then looks a little different:
mbr2gpt.exe /convert /disk:<disknumber>
The drive numbers can be displayed in diskpart with:
list disk
Transferring VHDs to new VMs
Since it is not possible to convert a Gen 1 VM to a Gen 2, you must now create a new Type 2 virtual machine and connect the VHDs to it.
Subscribe to 4sysops newsletter!
One side effect of this action is that it also raises the VM version up to a current level. This is necessary to take advantage of newer Hyper-V features available in Server 2016 or 2019. However, there is no way back from there either, so the VM will no longer run on an older hypervisor.
Hi Wolfgang,
Thanks for the article. Much easier and quicker to do than the MS version of a few years back.
Some other actions that is needed in certain instances.
All other VHD disks needs to be converted to VHDX as well for the new SCSI controllers to attach to the new VM that is created. Powershell command Convert-VHD very useful and easy to do this. Just takes time to create the new VHDX.
All your previous VM configuration is also lost – especially take not on things like static assigned IP addresses for the network adaptors.
Thank you very much!
These hints worked perfectly for upgrading my Gen1 Win10 pro VM (which itself was derived via Disk2VHD from an elderly HP-PC HW) to a Gen2 VM ready for an upgrade to Win11. Ok – the upgrade assistant to Win11 complains on my Hyper-V Server processor (Xeon E3-1225 v5 @3.3 GHz) although a parallel native ly installed Win11 VM runs fine – but that’s another story.
I am in the middle of refreshing server 2012 to server 2019. I have one VM that is bumping up against the 2TB limit on existing server. Is it possible to create new VM with Gen 2 and attach the vhdx files and then convert them to GPT to allow increasing the size beyond 2TB without formatting and losing data?
I did this once with Windows server 2019. As long as mbr2gpt.exe exists, then you can upgrade it. I recall this is what I did:
1) Shut down the gen 1 VM.
2) Make a backup of the C: vhdx file in case something goes wrong.
3) Boot up the server on the gen 1 VM.
4) Run the mbr2gpt to convert the partition
5) Reboot the VM. At this point it will not boot back up as a gen 1.
6) Make a note of all the resources in the current VM and then create a new VM set as gen 2. Attach the vhdx as the C: drive and any other resources it had in the gen 1 VM.
7) Boot up the VM as gen 2!