Troubleshoot a faulty Azure VM by using nested virtualization in Azure
Applies to: ✔️ Windows VMs
This article shows how to create a nested virtualization environment in Microsoft Azure, so you can mount the disk of the faulty VM on the Hyper-V host (Rescue VM) for troubleshooting purposes.
Prerequisites
In order to mount the faulty VM, the Rescue VM must use the same type of Storage Account (Standard or Premium) as the faulty VM.
Step 1: Create a Rescue VM and install Hyper-V role
Create a new Rescue VM:
Operating system: Windows Server 2016 Datacenter or newer versions of Windows Server Datacenter.
Size: Select a series that supports nested virtualization. For example: Dv3 or Dv4.
Same location, Storage Account, and Resource Group as the faulty VM.
Select the same storage type as the faulty VM (Standard or Premium).
Image: Choose either a Generation 2 image or a Generation 1 image.
Security type: Change the security type to Standard. By default, the security type is Trusted launch virtual machines that doesn't support nested virtualization. If you set the security type to Trusted launch virtual machines, and attempt to add server roles on the Rescue VM, you'll encounter the following error message:
Hyper-V cannot be installed because virtualization support is not enabled in the BIOS.
Note
This error occurs because the hypervisor isn't enabled in the BCDEdit configuration of the VM. To fix this error, set the option before installing the Hyper-V role.
To check the
hypervisorlaunchtype
option on the VM, run the following cmdlet from an elevated PowerShell command prompt:bcdedit /enum
Here's an output example. In this example, the hypervisor parameter isn't included, indicating that the hypervisor isn't enabled.
Windows Boot Manager -------------------- identifier {bootmgr} device partition=\Device\HarddiskVolume3 path \EFI\Microsoft\Boot\bootmgfw.efi description Windows Boot Manager locale en-US inherit {globalsettings} bootshutdowndisabled Yes default {current} resumeobject {24089230-1111-2222-3333-6045bd34a71d} displayorder {current} toolsdisplayorder {memdiag} timeout 30 Windows Boot Loader ------------------- identifier {current} device partition=C: path \Windows\system32\winload.efi description Windows Server locale en-US inherit {bootloadersettings} recoveryenabled No isolatedcontext Yes allowedinmemorysettings 0x15000075 osdevice partition=C: systemroot \Windows resumeobject {24089230-1111-2222-3333-6045bd34a71d} nx OptOut bootstatuspolicy IgnoreAllFailures ems Yes
To set the
hypervisorlaunchtype
option toauto
and restart the VM, run the following cmdlet:bcdedit /set hypervisorlaunchtype auto Restart-Computer -Force
After the Rescue VM is created, remote desktop to the Rescue VM.
In Server Manager, select Manage > Add Roles and Features.
In the Installation Type section, select Role-based or feature-based installation.
In the Select destination server section, make sure that the Rescue VM is selected.
Select the Hyper-V role > Add Features.
Select Next on the Features section.
If a virtual switch is available, select it. Otherwise select Next.
On the Migration section, select Next
On the Default Stores section, select Next.
Check the box to restart the server automatically if required.
Select Install.
Allow the server to install the Hyper-V role. This takes a few minutes and the server will reboot automatically.
Step 2: Create the faulty VM on the Rescue VM's Hyper-V server
Create a snapshot disk for the OS disk of the VM that has problem, and then attach the snapshot disk to the Rescue VM.
Remote desktop to the Rescue VM.
Open Disk Management (diskmgmt.msc). Make sure that the disk of the faulty VM is set to Offline.
Open Hyper-V Manager: In Server Manager, select the Hyper-V role. Right-click the server, and then select the Hyper-V Manager.
In the Hyper-V Manager, right-click the Rescue VM, and then select New > Virtual Machine > Next.
Type a name for the VM, and then select Next.
Select Generation 1 or Generation 2 according to the faulty VM generation.
Set the startup memory at 1024 MB or more.
If applicable select the Hyper-V Network Switch that was created. Else move to the next page.
Select Attach a virtual hard disk later.
Select Finish when the VM is created.
Right-click the VM that you created, and then select Settings.
Select IDE Controller 0 for generation 1 VMs or SCSI Controller for generation 2 VMs, select Hard Drive, and then click Add.
In Physical Hard Disk, select the disk of the faulty VM that you attached to the Azure VM. If you do not see any disks listed, check if the disk is set to offline by using Disk management.
Select Apply, and then select OK.
Double-click on the VM, and then start it.
Now you can work on the VM as the on-premises VM. You could follow any troubleshooting steps you need.
Step 3: Replace the OS disk used by the faulty VM
After you get the VM back online, shut down the VM in the Hyper-V manager.
Detach the repaired OS disk.
Replace the OS disk used by the VM with the repaired OS disk.
Next steps
If you are having issues connecting to your VM, see Troubleshoot RDP connections to an Azure VM. For issues with accessing applications running on your VM, see Troubleshoot application connectivity issues on a Windows VM.
Contact us for help
If you have questions or need help, create a support request, or ask Azure community support. You can also submit product feedback to Azure feedback community.
Feedback
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Submit and view feedback for