Several weeks back I was chatting with a few of our Engineers from the Core Platform Team (vSphere) and they had shared an interesting tidbit which I thought I was worth mentioning to my readers. When creating a Virtual Machine in either vSphere or Fusion/Workstation, customers have the option to override the default and specify the specific Firmware boot option whether that is BIOS or UEFI.
Like most customers, I do not even bother touching this setting and I just assume the system defaults are sufficient. Interestingly, for Microsoft Windows 10 and Windows Server 2016, there are some important implications to be aware of on whether BIOS or UEFI is used. This is especially important since the default firmware type in vSphere for these OSes are BIOS.
UPDATE (01/07/21) - As of vSphere 6.7 Update 3, the default firmware for creating a Windows 10 and Windows Server 2016 guest OS is now EFI
If you want to enable Secure Boot for Windows or any other OS that supports Secure Boot, UEFI firmware is a requirement. Support for Secure Boot was first introduced in vSphere 6.5 and here is a blog post that gets into more details. In addition to Secure Boot, both Windows 10 and Server 2016 also supports a new security capability from Microsoft called Virtualization-based Security (VBS) which in-turn is used by other features such as Credential Guard for example. To be able to leverage these capabilities, UEFI firmware is also required.
Note: The ESXi Hypervisor also supports Secure Boot for itself, for more details check out this blog post here.
OK, UEFI sounds great, but what if you have Window VMs that had been configured with BIOS firmware? Is it as simple as just reconfiguring the virtual hardware? Well, prior to Windows 10/Server 2016, the answer was no and you had to re-install the Windows OS as you could not simply update the Firmware while preserving the OS. As you can imagine, this was quite painful as you then needed to schedule extensive downtime to transfer the data and then re-build the system. With Windows 10 or newer, Microsoft now has a supported method to convert an OS disks using Master Boot Record (MBR) to a GUID Partition Table (GPT) which UEFI requires. The tool is called MBR2GPT.
Here is the high level workflow for converting a Windows VM from BIOS to UEFI firmware:
- As with any change in your environment, take precaution by performing a backup of the VM and/or taking snapshot to be able to revert changes
- Run the MBR2GPT tool within the Windows OS
- Shutdown the Windows VM (update vHW if required)
- Change the firmware of the Windows VM from BIOS to UEFI
- Power on the Windows VM
In the example below, I will be demonstrating the conversion process for a Windows 10 VM that was deployed using BIOS firmware. Since vSphere currently only supports Secure Boot and not the VBS feature, the instructions below will based on VMware Fusion (but the process to enable Secure Boot is also applicable to vSphere). Both Fusion 10 and Workstation 14 have added support for both Secure Boot and VBS, but vSphere customers can also benefit by enabling Secure Boot for their Windows 10/2016 VMs.
Step 1 - Lets verify that we are using MBR by using PowerShell and the Get-Disk command as shown in the screenshot below:
Step 2 - We can validate the disk using the MBR2GPT tool prior to conversion. Technically, MBR2GPT tool is supposed to run in a WindowsPE environment, but you can override that by passing in /allowFullOS flag by running the following command:
MBR2GPT.EXE /validate /allowFullOS
Step 3 - If validation was successful and no errors were thrown, we can now perform the conversion by running the following command:
MBR2GPT.EXE /convert /allowFullOS
The conversion process pretty quick and once it has completed, go ahead and shutdown the OS.
Step 4 - Reconfigure the VM's firmware from BIOS to UEFI. For vSphere VM, ensure you have vHW13 and for Fusion/Workstation make sure you have vHW14 before you can enable Secure Boot. To enable Secure Boot in Fusion, the settings are located under the Advanced for a VM and for vSphere-based VMs, it is under the "Boot Option" as shown in the screenshot above.
If you are using the latest version of Fusion/Workstation, you also have the option to enable the new VBS feature, simply check the box and the feature can now be consumed within Windows 10 and Server 2016. Once you have saved the changes, go ahead and power on the VM.
Step 5 - Once the VM as started back up, we can login and verify the conversion was successful by using the the Get-Disk cmdlet. As expected, our OS disk should now show GPT instead of MBR
As you can see the process is pretty straight forward and OS re-installation is no longer required if you had defaulted to the BIOS firmware which is currently the default if you create a new Windows 10 or Server 2016 VM in vSphere. I have been told that the default firmware version will change to UEFI in a future update of vSphere but for backwards compatibility purposes, we can not simply change the current default. This is something to aware of when provisioning new Windows 10/2016 VMs by either including this information in a runbook, leverage a VM Template or via Automation in which you can control the firmware type.
Some additional resources:
- VMware vSphere Documentation on configuring/enabling Secure Boot
- VMware Fusion Documentation on configuring/enabling Secure Boot and VBS
- VMware Workstation Documentation on configuring/enabling Secure Boot and VBS
Lastly, if you need a quick way to identify all Windows VM in vSphere that is currently using the BIOS firmware, here is a PowerCLI snippet that you can use:
Get-View -ViewType VirtualMachine -Property Name,Guest,Config -Filter @{"Guest.GuestFamily"="windowsGuest";"Config.Firmware"="bios"} | Select Name
Wolfson says
Be sure to check your storage vender best practices. There is a setting for, I think, maxdiskblocksize. If over 4096 then uefi vm's might not boot.
Eric says
ProTip: Your VM has to be at Workstation 14.x Hardware Compatibility level for the "Enable VBS support" setting to appear in VMware Workstation 14
William Lam says
Excellent point, vSphere requires vHW13 and Fusion/Workstation requires vHW14. I've updated the article to include this along with links to official product documentation for more details
Deji says
Please check the highlevel workflow again. It appears that there is an error in Step 1. If the VM is shutdown in Step 1, you can't do Step 2 :).
William Lam says
Thank for the catch, workflow fixed
mikiefoley says
6.5 doesn't support VBS or Credential Guard.
Thanks for posting the links to the blogs I wrong.
William Lam says
I never said 6.5 supported VBS/Credential Guard 🙂
>> Since vSphere currently **only** supports Secure Boot and **not** the VBS feature, the instructions below will based on VMware Fusion
mikiefoley says
[correction] Thanks for posting the links to the blogs I wrote
Jon Waite says
Hi William, any idea when a BIOS/UEFI option will be added to vCloud Director for Service Providers? Was disappointed to see the newly released v9 still doesn't make this selection available to tenant Organization Administrators, even when the underlying vSphere is 6.5 Update 1.
Joel Gonzalez says
Hi all. Does MBR2GPT.exe work on Server 2016? I'm running version 1607 (build 14393.2035) and MBR2GPT isn't even on the Windows\System32 directory. I tested by copying the file from a Win10 machine, but get the "Layout conversion failed. Error: 0x00000032" error. Curious how others have made this work on Server 2016.
Ken H says
Did you find a way to do this? I have the same issue. No MBR2GPT.exe in Server 2016.
Joel G says
Sadly no.
NeilG says
Yes, but you can't do it from within 2016 OS itself. I tested successfully by booting a 2019 VM into recovery mode (command prompt), attaching the boot disk of the 2016 VM and running MBR2GPT by specifying the correct disk number - use disk part > list disk to check. It validated and converted fine. After detaching the disk from the 2019 VM and switching the 2016 VM to use UEFI it booted up fine with all data intact.
Note that MBR2GPT does appear to create the ESP partition as the last partition, therefore making it harder to expand the boot disk in future.
Cole Byrne says
Thanks for sharing this! All the best!
Rob says
Nice