Gen 2 VM stuck at boot post-Live Migration — Secure Boot template mismatch

Question

Guys, quick check. Live-migrated a Gen 2 VM across nodes in the cluster and it failed to boot up straight after.

Looks like the target node Secure Boot template is out of sync with the source node. To prevent this kind of silent failure, how do you all usually audit the Secure Boot template settings across all cluster nodes programmatically? Any PowerShell cmdlet to quickly dump and cross-check the template alignment across the entire WSFC?

Answer 1

Hello Chang Min, thank you for posting in the Microsoft Q&A community.

When a Gen 2 VM fails to boot immediately following a Live Migration across cluster nodes, it typically points to an asymmetry in the underlying Hyper-V Secure Boot definitions between the source and target hosts. Since the legacy Microsoft Secure Boot certificates began their expiration cycle recently, it is highly likely that your Windows Server Failover Cluster (WSFC) nodes are in a mixed state of patch compliance. If the source node has the updated 2023 Microsoft UEFI CA certificates and the target node does not (or vice versa), the VM's bootloader signature validation will fail silently on the target host. Alternatively, the issue could be a simple configuration mismatch where a Linux VM expecting the MicrosoftUEFICertificateAuthority template lands on a node defaulting to MicrosoftWindows.

To quickly audit the Secure Boot template settings across all your cluster nodes programmatically, you can run the following non-destructive PowerShell script from any node in the cluster. This will query every Gen 2 VM across the WSFC and output its current Secure Boot configuration:

$Nodes = Get-ClusterNode | Select-Object -ExpandProperty Name
Invoke-Command -ComputerName $Nodes -ScriptBlock {
    Get-VM | Where-Object Generation -eq 2 | ForEach-Object {
        $firmware = Get-VMFirmware -VMName $_.Name
        [PSCustomObject]@{
            HostNode           = $env:COMPUTERNAME
            VMName             = $_.Name
            SecureBootEnabled  = $firmware.SecureBoot
            SecureBootTemplate = $firmware.SecureBootTemplate
        }
    }
} | Sort-Object VMName | Format-Table -AutoSize

If the templates match but the VM still refuses to boot, the host-level UEFI certificates are likely out of sync. You can cross-check the deployment status of the 2023 Secure Boot Servicing update across your cluster by querying the HKLM:\System\CurrentControlSet\Control\SecureBoot\Servicing registry path on all nodes:

$Nodes = Get-ClusterNode | Select-Object -ExpandProperty Name
Invoke-Command -ComputerName $Nodes -ScriptBlock {
    Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\SecureBoot\Servicing" -Name "UEFICA2023Status" -ErrorAction SilentlyContinue | 
    Select-Object @{Name="Host";Expression={$env:COMPUTERNAME}}, UEFICA2023Status
} | Format-Table -AutoSize

If any node returns a missing property or a status of NotStarted, that node has not processed the UEFI certificate update. This discrepancy is likely causing the bootloader to fail when the VM is migrated to that specific host. To fix this, you would need to ensure all cluster nodes are fully updated and the scheduled Secure Boot update task has successfully executed on all nodes.

I will follow up on this thread to ensure your issue is resolved. If this helps, please consider hitting 'Accept answer'.

For Microsoft Reference: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/learn-more/generation-2-virtual-machine-security-settings-for-hyper-v