Info2soft use cookies to help you have a superior and more admissible browsing experience on our website. Privacy Policy
Loading...
By:
VMware not booting from ISO is a common frustration when setting up a new virtual machine. Instead of launching the installer, the VM might show a black screen, loop into a PXE network boot, or display an error message.
This guide covers the root causes and how to fix them across ESXi, Workstation, and Fusion, plus how to check if your ISO file is actually bootable and avoid this issue going forward.
Most boot failures trace back to one of a small set of causes. Once you know which one applies to your setup, picking the right fix becomes straightforward.
In vSphere environments, tracking down why a VM bypasses its installation media means checking both the guest settings and the firmware configuration. If you’re dealing with ESXi not booting from ISO, a few version-specific quirks are worth knowing before you troubleshoot further.
Since ESXi 7.0, new virtual machines default to UEFI firmware instead of legacy BIOS. If you press ESC during boot expecting the classic blue BIOS selection screen, you’ll see the grey EFI Boot Manager console instead.
This happens because EFI firmware scans for valid EFI system partitions rather than raw boot sectors.
Selecting EFI VMware Virtual SATA CDROM Drive in this menu often does nothing if the mounted ISO doesn’t contain UEFI-compatible bootloader files.
The Fix
If your installer only supports legacy BIOS, you’ll need to change the VM’s firmware setting. This option is greyed out while the VM is running or suspended, so it can’t be changed on the fly.
ESXi gives you two ways to attach an installer image to the virtual CD/DVD drive: Datastore ISO or Client Device. Picking the wrong one for your setup often causes dropped connections or a device that never gets detected.
| Feature | Datastore ISO File | Client Device |
|---|---|---|
| Storage Location | Uploaded to an ESXi datastore | Stored locally on your desktop or workstation |
| Connection Stability | High (handled internally by the ESXi host) | Variable (depends on your network connection) |
| Performance | Fast read/write speeds | Slower (limited by network latency) |
| Best For | Production deployments, standardized templates | Quick testing, local custom ISO files |
If you’re working over a VPN or a slow connection, avoid Client Device. Upload the ISO to an ESXi datastore and map it as a Datastore ISO file for a more reliable mount.
When deploying OVF templates in VMware Cloud Director or vCenter, VMs sometimes power on to a No Operating System Found error. This usually happens because the OVF import creates the disk controller but doesn’t attach the bootable ISO, since VMware Cloud Director doesn’t automatically mount the ISO the way a standard OVA deployment does.
If you’re deploying VMs this way regularly, it’s worth reviewing how to export a VM to OVA from vCenter so your templates carry a properly mounted, bootable ISO reference from the start.
Local developers and lab admins running VMware Workstation on Windows often run into boot failures when spinning up quick test environments. A few adjustments in the Workstation settings usually resolve these startup issues.
The most common reason VMware Workstation won’t boot from ISO is a disconnected virtual optical drive. Even with the correct file path mapped, the VM ignores the media if the drive isn’t active at startup.
Modern hardware boots so fast that clicking into the console window and pressing ESC or F2 in time is genuinely hard. Miss that window and the VM skips the CD/DVD drive and boots straight to the hard disk.
Adding a boot delay makes this easier.
bios.forceSetupOnce = "TRUE" in the .vmx file instead. This forces entry into setup on the next boot rather than extending the POST screen.On UEFI VMs installing a modern OS like Windows 11, you’ll briefly see Press any key to boot from CD or DVD…. This comes from the ISO’s own bootloader, not VMware, and the window to respond is only a few seconds.
To catch it, restart the VM, click inside the console window right away, and tap the spacebar as soon as it powers on.
Mac users running VMware Fusion face a few challenges unique to the platform, especially since the shift to Apple Silicon. Fixing boot failures on macOS usually comes down to matching your installer to your Mac’s chip architecture and knowing where the CD/DVD settings live in Fusion’s interface.
If your VM won’t boot from ISO on an Apple Silicon Mac, architecture mismatch is the most likely cause. M-series Macs use ARM64 processors, and a standard x86 ISO won’t boot on them.
This comes up most often with Windows, since Microsoft didn’t offer an ARM64 ISO for a long time. For Windows 11, use Fusion’s built-in Get Windows from Microsoft option when creating a new VM, it downloads the correct ARM64 ISO with drivers included.
If the VM isn’t booting from ISO for reasons other than architecture, check that the virtual optical drive is properly attached. Fusion’s settings layout looks different from Workstation and ESXi, but the underlying logic is the same.
Sometimes the ISO itself is the problem, not the VM. A quick check rules out media corruption before you dig into VM settings.
How to verify an ISO is actually bootable
file /path/to/image.iso. A bootable ISO ends with (bootable).No boot indicator means the file is likely a data-only archive, and VMware can’t boot from it.
Checksum verification against vendor-published hashes
An interrupted or corrupted download can still mount in your hypervisor but fail to boot. Checking the checksum against the vendor’s published hash confirms the file downloaded correctly.
Get-FileHash -Path C:\path\to\image.iso -Algorithm SHA256 sha256sum /path/to/image.iso shasum -a 256 /path/to/image.isoIf the result doesn’t match the vendor’s SHA-256 hash, redownload the file.
A few workflow standards go a long way toward avoiding these boot failures altogether.
Boot failures don’t only show up when mounting an ISO. They’re just as common after migrating a VM between platforms, especially when the source and target environments use different firmware settings or hardware profiles.
A P2V migration, a cross-hypervisor move, or a shift to a new hardware generation can all leave a VM with a firmware mismatch or missing drivers, the same underlying issues covered earlier in this guide, just triggered by migration instead of a fresh ISO boot.
i2Migration is built to prevent this kind of failure during full machine migration:
If a VM fails to boot after migration, these safeguards mean it’s usually a quick fix rather than a full restart of the migration process.
Q1: Why won’t my Windows 11 ISO boot in VMware (TPM 2.0 issue)?
Windows 11 requires TPM 2.0 and UEFI Secure Boot. Without these, the installer shows a compatibility error or fails to load. Fix this by encrypting the VM and adding a virtual TPM (vTPM) in the hardware settings.
Q2: Can I boot from ISO without detaching it after installation?
Yes, as long as your boot order prioritizes the hard disk over the CD/DVD drive. That said, leaving installer media attached isn’t good practice. Mounted images can lock datastore files and block tasks like vMotion, snapshots, and host maintenance.
Q3: Why does my VM skip the ISO and boot straight into an empty disk?
The boot priority list checks the virtual hard disk before the CD/DVD drive. If the disk is empty, the VM can get stuck attempting a network boot instead of falling back to the optical drive. Enter the BIOS or UEFI setup at startup and move the CD/DVD drive to the top of the boot order.
Q4: Is it safe to boot a production VM from ISO?
Yes, booting a production VM from a recovery or diagnostic ISO is safe when done correctly. Do it during a scheduled maintenance window and unmount the image once you’re done. Leaving virtual media connected indefinitely can restrict VMware HA and cluster failover.
Most VMware boot failures trace back to a handful of causes: a disconnected optical drive, a boot order that skips the CD/DVD drive, a firmware mismatch, or an ISO that was never bootable to begin with. Once you know which one you’re dealing with, the fix is usually quick, whether you’re working in ESXi, Workstation, or Fusion.
Building a few habits into your workflow, like a shared ISO library, a default boot delay, and a documented firmware policy, goes a long way toward preventing these issues before they start.
If boot problems show up after a system migration rather than a fresh install, the cause is often a firmware or driver mismatch between platforms. Info2soft builds i2Migration to handle exactly this kind of transition, so VMs boot correctly on the target environment without manual firmware troubleshooting after the move.
· Enterprise & Mid-market Customers Worldwide
· Support team available to assist you throughout your trial
· Start a 60-day free trial or view demo to see how Info2Soft protects enterprise data.
