What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Yes, you can attempt to boot VMware ESXi inside a Hyper-V virtual machine, but treat it as a disposable lab only. Microsoft says that virtualization applications other than Hyper-V are not supported in Hyper-V virtual machines and are likely to fail. Broadcom likewise says ESXi nested inside a third-party hypervisor is not supported in production. The practical use is learning, demonstrations, training, experiments, and configuration testing—not a supported platform for workloads that need a vendor-backed recovery path.
This guide shows the Hyper-V settings that expose hardware virtualization to a nested ESXi installer, the minimum troubleshooting baseline Microsoft recommends, the networking choices for two virtualization layers, and the failure modes you should expect.
As an Amazon Associate I earn from qualifying purchases.
What “ESXi in Hyper-V” actually means
In this arrangement, a physical computer runs Windows with Hyper-V enabled. Hyper-V creates a first-level virtual machine (VM). ESXi is installed inside that VM, making ESXi a second-level hypervisor. Any VMs created by ESXi are therefore nested VMs.
Recommended Free Tools
The outer Hyper-V layer must emulate or pass through enough processor virtualization behavior for ESXi to start. It also controls memory, virtual CPUs, storage, and the first virtual network connection. ESXi then tries to provide those resources again to its own guests. Every extra layer adds a support boundary and can affect performance, timing, device access, and networking.
#1 Best Overall
Microsoft’s documented nested-virtualization feature is designed primarily for Hyper-V guests. Its explicit warning is: “Virtualization applications other than Hyper-V aren’t supported in Hyper-V virtual machines, and are likely to fail.” Read the full statement in Microsoft’s nested virtualization overview. Broadcom’s position is similarly restrictive: “Broadcom does not support ESXi as a guest operating system nested within a virtual machine in production environments.” Its knowledge-base article describes learning, demonstrations, training, experiments, and configuration testing as possible reasons to try it; it does not turn the design into a supported production deployment.
When this lab is appropriate—and when it is not
Reasonable uses
- Practicing the ESXi installer and basic host administration.
- Demonstrating a hypervisor inside another hypervisor.
- Testing configuration ideas that can be discarded and rebuilt.
- Training where a physical ESXi host or supported VMware platform is unavailable.
Situations to avoid
- Production services, customer workloads, or data that needs vendor support.
- Performance benchmarking or capacity planning. The nested layers add overhead, and the supplied documentation does not establish a benchmark for ESXi on Hyper-V.
- Designs that depend on PCI passthrough, vGPU, or direct hardware access.
- Any assumption that enabling one Hyper-V switch setting makes ESXi a supported guest.
If supportability matters, use a physical ESXi installation or a VMware platform that Broadcom supports for the intended version and workload. A nested Hyper-V experiment is not an equivalent substitute.
Prerequisites and a safe baseline
Physical host
Use a supported Windows Server or Windows client edition with the Hyper-V role available. Hardware virtualization must be enabled in the physical computer’s firmware. Microsoft’s current procedure calls for Intel VT-x with EPT on Intel systems. It also specifies a VM configuration version of 8.0 or later for Intel; AMD systems have newer version requirements, so check the current Microsoft procedure for the host and processor combination rather than assuming the Intel number applies to AMD.
Free tools Windows power users keep installed
One-click scans. No signup required.
These requirements are documented in Microsoft’s “Enable nested virtualization” procedure. Firmware names vary by manufacturer, but the relevant setting is the processor’s hardware-virtualization feature. If firmware virtualization is disabled, Hyper-V cannot expose it to the nested guest.
First-level VM
Create a Generation 2 Hyper-V VM. For troubleshooting, Microsoft recommends starting with at least two virtual CPUs and 4 GB of memory. Those values are a practical baseline for diagnosing nested virtualization; they are not an ESXi vendor support promise and do not make the installation production-ready.
Leave enough resources for Windows, Hyper-V, and the nested ESXi process. If the physical host is already under memory or CPU pressure, an ESXi installer failure may be a resource problem rather than a missing virtualization extension.
Installer media and storage
Obtain the ESXi installer ISO appropriate to the lab exercise and attach it to the VM’s virtual DVD drive. Keep the lab’s virtual disks and configuration files on storage with adequate free space. No specific ESXi release, disk size, or licensing term is established here, so do not treat a particular version or capacity as universally required.
Step-by-step: create the Hyper-V VM and expose virtualization
- Enable hardware virtualization on the physical host. Enter the system firmware setup, enable the processor virtualization feature, save, and boot Windows. Confirm that the Hyper-V role is installed and operational.
- Create a Generation 2 VM. In Hyper-V Manager, choose New > Virtual Machine, select Generation 2 when prompted, assign at least two virtual processors, and start with 4 GB of RAM as Microsoft’s troubleshooting baseline. Connect a virtual network adapter to the virtual switch you intend to use.
- Check the VM configuration version. Intel hosts should meet Microsoft’s documented version 8.0-or-later requirement. AMD hosts have newer requirements documented on the same Microsoft page; follow those platform-specific instructions.
- Power the VM off completely. The nested-virtualization processor setting cannot be changed while the VM is running. A saved or paused state is not a substitute for a clean powered-off state.
- Run the processor command on the physical Hyper-V host. Replace the placeholder with the VM’s exact name:
Set-VMProcessor -VMName "<VMName>" -ExposeVirtualizationExtensions $trueRun this in an elevated PowerShell session on the host, not inside the guest. Microsoft documents the command and the powered-off requirement in its nested-virtualization procedure.
Rank #3
- Attach the ESXi ISO. Open the VM’s settings, select the virtual DVD drive, choose the ISO image, and apply the change. Keep the VM Generation 2 configuration intact.
- Boot from the virtual DVD drive. Start the VM and use the Generation 2 firmware boot option if the ISO is not selected automatically. Proceed through the ESXi installer as you would for a disposable test host.
- Record the lab’s limitations. Note the Hyper-V host, VM configuration version, assigned vCPUs and memory, virtual switch type, and ESXi build. This makes later troubleshooting repeatable, but it does not create a support entitlement.
Networking across two virtual switches
A nested ESXi host has a virtual network adapter supplied by Hyper-V. Any VM inside ESXi adds another virtual switch and another layer of packet forwarding. A connection that works from Windows to the first-level VM can therefore fail when a nested VM sends traffic.
Use NAT for the simplest outbound connection
NAT is the simplest choice when nested guests mainly need outbound access. The first-level VM receives an address from the Hyper-V-side network, and traffic from the nested layer is translated before leaving the host. NAT avoids requiring the outer switch to forward the nested guests’ individual MAC addresses, but inbound access to nested services requires deliberate port-forwarding or another routing design. The Microsoft nested-virtualization procedure describes NAT as the straightforward outbound option: Microsoft Learn.
Enable MAC address spoofing when nested packets must cross the switch
If nested VMs must appear on the surrounding network rather than being hidden behind NAT, enable MAC address spoofing on the first-level Hyper-V VM’s network adapter. In Hyper-V Manager, open the VM’s settings, select Network Adapter > Advanced Features, enable MAC address spoofing, and apply the change while the VM is stopped when required by the host’s configuration workflow. The setting allows traffic using the nested guests’ MAC addresses to traverse the outer virtual switch. Microsoft documents this approach in the same nested-virtualization guide.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteChoose one approach deliberately. NAT is usually easier for an isolated lab; MAC spoofing is relevant when the nested network must participate directly in the upstream layer. Neither option changes ESXi’s unsupported status on Hyper-V.
Troubleshooting the common failures
“The processor does not have required virtualization capabilities”
Work through the checks in this order:
- Confirm the VM is Generation 2.
- Shut the VM down; do not attempt to change the processor setting while it is running or suspended.
- Run
Set-VMProcessor -VMName "<VMName>" -ExposeVirtualizationExtensions $trueon the physical Hyper-V host. - Verify that the physical host’s firmware virtualization feature is enabled.
- Use at least two vCPUs and 4 GB of RAM as the initial troubleshooting baseline.
- Check that the VM configuration version meets Microsoft’s requirement for the processor platform.
Microsoft lists these checks in its nested-virtualization troubleshooting guide. Passing them only proves that Hyper-V is exposing the requested extensions; it does not guarantee that ESXi will install or that its own guests will run.
ESXi installs, but a nested VM will not start
This usually indicates a support boundary rather than a missing ESXi menu option. The outer Hyper-V layer may not pass every hardware-virtualization behavior that ESXi expects to expose again. Microsoft warns that non-Microsoft virtualization applications in Hyper-V VMs are unsupported and likely to fail. Test with a minimal disposable guest, remove unnecessary devices, and verify that the first-level VM still has adequate CPU and memory. If the nested guest remains unable to start, move the exercise to physical hardware or a supported VMware platform instead of treating the failure as a production configuration problem. See Microsoft’s nested virtualization guidance.
Network works in the first-level VM but not in nested guests
First identify whether the nested guests need only outbound access or must be reachable from the surrounding network. Use NAT for the former. For the latter, enable MAC address spoofing on the first-level Hyper-V adapter and verify that the upstream network permits the resulting traffic. Recheck the ESXi virtual switch and port-group configuration after the outer switch is corrected. Microsoft’s procedure covers both NAT and MAC spoofing: Microsoft Learn.
Trying to add PCI passthrough or a vGPU
Do not assume that nested virtualization and direct device assignment can be combined. Broadcom explains that passthrough gives a device directly to a guest by bypassing the hypervisor, while nested virtualization requires the hypervisor to mediate access for another hypervisor. Those models conflict. Avoid designing this lab around PCI passthrough or vGPU behavior; the limitation is described in Broadcom’s passthrough and nested-virtualization article.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How the lab compares with supported alternatives
The following comparison keeps the decision focused on supportability and technical behavior rather than implying that the nested arrangement is equivalent to a supported deployment.
| Criterion | ESXi inside a Hyper-V VM | Physical ESXi host or supported VMware platform |
|---|---|---|
| Vendor support | Microsoft does not support non-Hyper-V virtualization applications in Hyper-V VMs; Broadcom does not support nested ESXi on third-party hypervisors in production. | Support depends on the specific VMware platform, hardware, and version combination. |
| Nested VMs | Possible as an experiment, but ESXi may be unable to pass required virtualization behavior to its guests. | Uses the platform’s documented virtualization capabilities; exact nested support still depends on the vendor’s compatibility rules. |
| Networking | Two virtual-switch layers require NAT or MAC address spoofing for the desired traffic path. | Does not inherently have the extra Hyper-V switch layer. |
| Performance | Additional scheduling and translation layers introduce overhead; no numeric performance result is established here. | Fewer virtualization layers generally simplify capacity planning, subject to the chosen hardware and platform. |
| Hardware-device access | Do not plan on PCI passthrough or vGPU features; the nested and passthrough models conflict. | Hardware access is governed by the supported platform’s compatibility and device-assignment documentation. |
| Licensing and cost | No universal cost or license requirement is established by the available documentation; use the licenses applicable to your Windows, Hyper-V, and ESXi editions. | Hardware, platform, and license costs depend on the selected supported deployment. |
| Recovery | Best treated as disposable: keep the ISO and VM configuration available so the lab can be rebuilt after an unsupported failure. | Use the supported platform’s documented backup, recovery, and vendor-support processes. |
Rebuilding or abandoning the experiment
Because this is an unsupported combination, recovery should favor a clean rebuild over trying to turn a failed nested host into a dependable service. Save any scripts, ESXi configuration notes, and test results outside the VM. If the installer or a nested guest leaves the lab in an unusable state, power off the first-level VM, detach or replace its virtual disks as appropriate for your test, and repeat the documented processor and networking checks before creating a fresh instance.
Do not migrate a working demonstration into production merely because it boots. The support statements from Microsoft and Broadcom remain unchanged when the lab happens to function. Move to physical ESXi or a supported VMware deployment before placing data or services on it.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Key decisions before you start
- Need a supported production host? Do not use ESXi inside Hyper-V; choose physical or supported VMware infrastructure.
- Need a disposable learning lab? Use a Generation 2 VM, expose virtualization extensions while it is powered off, and begin with two vCPUs and 4 GB RAM.
- Need simple outbound networking? Choose NAT.
- Need nested guests visible through the outer switch? Enable MAC address spoofing on the first-level Hyper-V adapter.
- Need passthrough or vGPU? Redesign the lab; Broadcom identifies a conflict between direct passthrough and nested hypervisor mediation.
The Bottom Line
VMware ESXi can be installed inside a Hyper-V VM as an educational experiment when Hyper-V exposes virtualization extensions to a powered-off Generation 2 guest. It remains unsupported for production, may fail to run nested VMs, and should be replaced with physical or supported VMware infrastructure whenever reliability or vendor assistance matters.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
