VMware Operating System Not Found: Check Disk, Boot Order & Firmware

VMware shows “Operating System Not Found” after firmware reaches the boot stage but cannot start a bootable guest from the path it tried. Do not repair a bootloader, switch BIOS/UEFI, or attach another VMDK first. Prove that the intended OS disk is attached and readable, then separate boot-order/media, firmware-layout, and storage-path failures.

VMwareVMware WorkstationLast reviewed Sep 27, 2026
🎯 You’re likely in the right place if:
VMware starts but the guest operating system does not boot.The screen shows “Operating System Not Found”.The VM has or should have a virtual hard disk attached.
Choose the path that matches what you see
Virtual disk is missing from VM settingsStop and identify the correct VMDK/virtual disk before changing firmware or boot order.
Disk is attached, but firmware cannot boot itCheck boot order and whether the attached disk is actually the OS disk.
This is a brand-new VMConfirm an OS was installed, or mount valid installation media for the first boot.
BIOS/UEFI was changed recentlyIf this was accidental, restore the previously working firmware mode. If the change was intentional, the disk layout/bootloader must support the new mode; changing the VM setting alone does not convert it.
Disk is attached but not readable/bootableSeparate guest bootloader damage from an inaccessible/corrupt virtual disk or controller/storage path before repairing the OS.
Difficulty: Easy–ModerateRisk: Low
🔎 First check — prove the intended OS disk is attached

Power off the VM, open its settings, and confirm the expected virtual hard disk is present, connected, and configured to connect at power on. If several VMDKs are attached, identify which one actually contains the guest OS before changing boot order.

VM Settings → Hard Disk → Connected ✓

Verify: Start the VM again. If it reaches the operating-system loader, the disk connection was the cause.

Did Fix #1 work?
ADSENSE · reserved slot after the first useful fix

Why this happens

VM firmware shows this message when it cannot find a bootable system. Common causes include a disconnected virtual disk, an empty disk, an unexpected boot order, or a firmware mode that does not match the installed operating system.

Diagnose before changing more

1
Is the virtual disk listed in VM settings?
If it is missing, stop here and identify the correct virtual disk and backing file before changing firmware settings. Do not create a replacement blank disk.
2
Did this VM boot successfully before?
A previously working VM makes a connection or boot-path change more likely than a missing OS installation.
3
Is this a new VM?
Confirm that an operating system has actually been installed, or that installation media is mounted for the first boot.
4
Did the error start after adding or removing a virtual NIC?
Broadcom documents ESXi cases where a NIC hardware change alters the remembered BIOS boot device and the VM falls through to PXE. Re-check the boot order before touching the disk.
5
Is the disk attached but firmware still cannot read or boot it?
Preserve the disk. Check for datastore/backing-file, virtual controller, disk-integrity or bootloader evidence before attempting guest repair.

Fix #2 — check the boot device and firmware path

If the intended virtual disk is attached, open the VM boot or firmware options and confirm that disk is the device firmware is trying to boot. PXE fallback is especially useful evidence: it often means firmware did not boot the expected disk and moved to the network device.

Next compare firmware with the guest's existing boot layout. Broadcom documents Windows cases where changing EFI/GPT to BIOS/MBR without converting the disk makes the VM fail with “Operating System not found” or “No bootable device.” If the VM booted before and firmware was changed accidentally, restoring the previous known-good mode is different from intentionally migrating firmware. An intentional EFI↔BIOS migration can require a compatible partition layout and bootloader; changing the VM firmware dropdown alone does not perform that conversion.

🟡 Before changing configuration: note the current setting so it is easy to reverse.

Verify: Restart the VM. Success means the expected OS loader appears and the VM no longer falls through to PXE or an “Operating System Not Found” message.

Did Fix #2 work?

Fix #3 — disk is attached, but firmware still cannot boot it

“Attached” does not prove the boot media is healthy or readable. Broadcom documents UEFI boot failures where inaccessible boot media, corrupted partitions, slow storage I/O or virtual-disk controller failures can surface as “Operating System Not Found” or “No Media Found.” If the expected disk is present and the firmware/layout are unchanged, move diagnosis toward the disk/storage path before rewriting the guest bootloader.

Protect the evidence: do not initialize, format, repartition or replace the suspected OS disk. If the data matters, preserve a backup/clone according to your environment before invasive repair.

Verify: confirm the expected backing disk remains accessible and the VM can see it through the intended virtual controller. If storage/controller evidence is clean but the disk still has no valid boot path, only then move to guest-specific bootloader/recovery tooling.

What not to do

Do not switch BIOS ↔ UEFI by trial and error; firmware must match the disk/OS boot layout.Do not attach a random VMDK just because the VM powers on; confirm it is the disk that contains the operating system.Do not edit advanced VMX boot parameters before checking the attached disk and normal boot settings.Do not create or attach a new blank disk when the original OS disk is merely missing from the VM configuration.Do not initialize, format or repartition an attached OS disk just because firmware cannot boot it.Do not repair GRUB/Windows boot files until the intended disk, firmware mode and storage path have been proven.

Still seeing the error?

If the disk is present and boot order is reasonable, identify which layer still fails: firmware cannot read the disk, firmware can read it but finds no compatible boot path, or the guest bootloader starts and then fails. Those are different problems and should not share one repair.

Before escalating, capture:the exact console message or screenshotVMware product/version and host OSwhether this VM booted successfully beforethe virtual-disk filename(s) attached to the VMcurrent firmware mode and any recent hardware/boot changeswhether the console falls through to PXE/network bootvirtual disk controller type and whether the backing disk/datastore is accessiblerelevant vmware.log/storage errors before any bootloader repair

References and related guides

Virtualization failure map

Use the exact failure stage to avoid applying a Hyper-V or VMware fix to the wrong problem.

Still stuck? Ask the community

Share your operating system, software version, exact error text, and which fix you already tried. Another reader may have seen the same setup.

Keep it safe: never post passwords, API keys, access tokens, recovery codes, license keys, private URLs, or confidential logs.
Powered by GitHub DiscussionsSign in with GitHub to comment. Reading comments does not require sign-in.

Loading community discussion…