Hyper-V Tips and Tricks¶
How to Import and Export TPM-enabled Hyper-V VM certificates with PowerShell¶
TPM requirement, which is a great security feature, was added to Windows 11. On the host, it is managed by the OS and UEFI, but when you create a Virtual Machine (VM) that runs an OS like Windows 11, you have to know how to manage it properly so that your VM will stay secure everywhere and you will maintain your access to your VM even if you import/export it to a different Hyper-V host or reinstall your host OS.
Here is a screenshot of my Hyper-V VM on Windows 11 with the following security features enabled:
- Secure Boot
- Trusted Platform Module (TPM)
When a VM uses TPM, Windows creates 2 certificates in the Local Machine Certificate Store => Shielded VM Local Certificates => Certificates
One of them is for encryption and the other one is for signing. They both contain private keys. If these 2 certificates don't exist in that folder in the Local Machine Certificate store of a Hyper-V host, your VM won't be able to start
What you need to do is to export those 2 certificates (with private keys) and store them in a safe place (such as OneDrive's personal Vault) as a backup.
If you completely reinstall Windows or move the VMs to a different Hyper-V host and Import the certificates, you will be able to continue using your VMs, but when you create new TPM enabled VMs on the new host, 2 more certificates will be added to the Local Machine Certificate Store => Shielded VM Local Certificates => Certificates
, so you will have 4 certificates in total, 2 of which are tied to your old VMs and the other 2 are tied to the new VMs. Each generated certificate has 10 years expiry date from the time it was created.
You can Import/Export the certificates using GUI, but here I'm going to show how to automate it using PowerShell:
Export all the available Host Guardian service certificates with private keys and extended properties¶
$CertificatePassword = ConvertTo-SecureString -String "hotcakex" -Force -AsPlainText
Get-Item "Cert:\LocalMachine\Shielded VM Local Certificates\*" | ForEach-Object {
Export-PfxCertificate -Cert $_ -FilePath ".\$($_.Issuer)-$($_.Thumbprint).pfx" -Password $CertificatePassword -CryptoAlgorithmOption AES256_SHA256}
Import the certificates with private keys¶
$ShieldedCertsPath = 'Cert:\LocalMachine\Shielded VM Local Certificates'
if (-NOT (Test-Path $ShieldedCertsPath)) { New-Item -Path $ShieldedCertsPath -Force }
$CertificatePassword = 'hotcakex' | ConvertTo-SecureString -AsPlainText -Force
Get-Item "C:\Users\$($env:USERNAME)\OneDrive\Desktop\Hyper-V Guardian certificates\*.pfx" | Import-PfxCertificate -CertStoreLocation $ShieldedCertsPath -Password $CertificatePassword -Exportable
You should change the values for $CertificateLocation
and $CertificatePassword
varaibles according to your own needs and environment.
-
You can find more info about those commands here:
- Export-PfxCertificate
How to Enable Nested Virtualization for All the VMs on the Hyper-V Host¶
Use the following command to enable Nested Virtualization for a single VM
Use the following command to automatically enable Nested Virtualization for all VMs
All of the VMs must be in Off state when enabling nested virtualization for them
This is how to verify Nested Virtualization is enabled for all of your VMs
(Get-VM).name | ForEach-Object {get-VMProcessor -VMName $_} | Select-Object -Property VMName,ExposeVirtualizationExtensions
Confidential Computing on Azure¶
Azure confidential computing makes it easier to trust the cloud provider, by reducing the need for trust across various aspects of the compute cloud infrastructure. Azure confidential computing minimizes trust for the host OS kernel, the hypervisor, the VM admin, and the host admin.
Continue reading¶
Shielded VMs are deprecated concepts¶
They are deprecated starting with Windows Server 2022. They were prone to modern attacks such as side-channel.
The following details about Shielded VMs are old and no longer valid
Shielded VMs can't be simply moved to another Hyper-V host and used there, nor can they be de-shielded in another host, if the certificate is not in place on the new host. This results in the error "the key protector could not be unwrapped", which is desired.
Shielding a VM is for keeping bad actors or malware out of the VM, not for keeping malware inside VM. i.e., Shielding a VM is for keeping the VM secure, not for keeping the host secure.
You can use the command below to get details about your Hyper-V host, including checks whether your host runs in local/standalone mode or is part of a Guarded Fabric
Note that this configuration is for standalone systems. an actual shielded virtual machine is a lot more secure because the host's security and health is properly attested in a Guarded Fabric, using Host Guardian Service (HGS) on a Windows Server.
Here is an official video about the feature and how it protects your VMs:
Scenario: Hyper-V, Enhanced session mode, no authentication in the VM's OS¶
When you create a VM in Hyper-V that doesn't have any authentication method for login such as Password or PIN, and use Enhanced session-mode to connect to it, there might be an issue where the RDP disconnects once after each restart of the VM and Hyper-V virtual machine connection asks you to connect to the VM again by clicking/tapping on the connect button. To fix this, set a local password for the user account of the OS in VM.
Native boot Hyper-V VMs, VHDX¶
There are guides for native booting a VHDX and it's very easy to do. If you already have a Hyper-V VM, you can add it to the Windows boot manager so that during a reboot you will have the option to boot the VHDX.
You need to pay attention to a few things though:¶
-
The VHDX should be on a drive that is NTFS formatted, for now booting from ReFS is not supported.
-
The drive that hosts the VHDX file must have more free space than the assigned size of the VHDX. The size you see in the file explorer is not the same as the size of the disk you assigned to the VHDX when creating it. It's easier if you have a fixed size VHDX instead of a dynamically expanding one. To find the real size of the VHDX, you can boot it in Hyper-V and check the drives inside it.
-
Merge all checkpoints and delete them before attempting to native boot VHDX.
VHDX native booting is very easy and flexible, you can do it even if:¶
-
Your host has Secure boot enabled
-
You use Signed WDAC policies
-
Your VM wasn't SysPrepped before natively booting it on physical machine
-
VM has secure boot and TPM
How to make the VHDX bootable:¶
- Double-click/tap on the VHDX file to mount it
- Run this in CMD or PowerShell
Use the /d option to preserve the existing boot order.
Verify the change by running this command¶
The description of the boot entry is the same one you see during OS selection menu. You can change it with this command in PowerShell:
or in CMD:
If {default}
is not the correct identifier, then change it according to the result of the bcdedit /enum
There are three different identifiers: The chosen default OS has identifier {default}, the current OS you are signed in at the moment is {current}. All other entries have a long hexadecimal identifier.
Some Hyper-v Nested Virtualization Screenshots¶
To display how optimized and powerful Hyper-V hypervisor is (including any feature that runs on it such as Windows Sandbox, WSL, WSA, MDAG and more), here are some screenshots taken on a very old hardware, hardware that is not even officially supported by Windows 11, yet you can virtualize 5 operation systems nested in each other, and the last nested virtualized OS still has full functionality including direct file copy from host to guest, full Internet connectivity, ability to listen to music, do tasks and so on.
Hardware specs - All from 2016-2017, couldn't find any older to test¶
- CPU: Intel Core I7 7700k
- RAM: 16GB
- GPU: N/A (Intel IGPU)
- SSD: 256 GB M.2