VMware ESXi and vSphere Cluster Management

Configure Virtual Machine Boot Options in VMware ESXi and vSphere

Learn how to configure VMware VM firmware, boot delay, firmware setup, and failed boot recovery settings in the vSphere Client.

Virtual machine (VM) boot options control what happens after a VM powers on and before its guest operating system begins loading. These settings determine which firmware mode the VM uses, how long startup pauses, whether the firmware setup screen opens, and whether VMware retries after a failed boot.

A VM is a software-defined computer running on ESXi with virtual CPU, memory, storage, network devices, and firmware. Boot options are configured for an individual VM, not as a general ESXi host boot policy. This lets administrators give different VMs different startup behavior.

Why Change VM Boot Options?

  • Install an operating system that requires a particular firmware mode.
  • Enter BIOS or EFI setup to inspect firmware settings and boot-device order.
  • Allow time to interrupt startup and select alternate installation or recovery media.
  • Resolve boot-device problems involving virtual disks, CD/DVD media, controllers, or boot order.
  • Meet guest operating system requirements for BIOS, EFI, MBR, or GPT startup.
  • Retry startup after a temporary failure to detect a bootable device.

Where Boot Settings Are Configured in vSphere

The vSphere Client is the VMware management interface used to administer virtual machines through vCenter Server or an ESXi-managed inventory. The relevant controls are in the VM's Edit Settings interface.

  1. Locate and select the target VM in the inventory.
  2. Open Edit Settings.
  3. Select VM Options.
  4. Expand Boot Options.
  5. Set the required firmware, delay, firmware setup, and failed boot recovery values.
  6. Save the changes and test the result through the VM console.

Some firmware-related changes require the VM to be powered off. If the client does not permit a change while the VM is running, schedule a power-off or restart and follow the change procedure for your vSphere version and environment.

Firmware Selection: BIOS or EFI

Virtual machine firmware is the low-level startup interface that initializes virtual hardware and begins loading the guest operating system. VMware commonly provides two firmware modes: BIOS and EFI.

BIOS

BIOS is a legacy firmware mode. It is commonly used with older operating systems and traditional MBR disk layouts. MBR, or Master Boot Record, is an older disk partitioning and boot scheme associated with legacy BIOS startup.

EFI

EFI, or Extensible Firmware Interface, is a modern firmware mode used by many current operating systems. It is commonly paired with GPT, the modern GUID Partition Table disk format. EFI provides a different startup path and a different firmware setup interface from BIOS.

The selected firmware must match both the guest operating system and the boot disk's layout. Switching firmware on an already-installed VM can make the guest unbootable if its bootloader and partition format support only the original mode. For example, changing a BIOS-installed guest with an MBR boot disk to EFI may fail unless the guest has been deliberately converted to an EFI-compatible boot configuration.

BIOS and EFI Compatibility Comparison

Characteristic: Typical operating system compatibility
BIOS: Older or legacy guest installations
EFI: Many current guest operating systems

Characteristic: Common partition style
BIOS: MBR
EFI: GPT

Characteristic: Firmware setup interface
BIOS: BIOS setup
EFI: EFI setup

Characteristic: Risks when changing an existing VM
BIOS: An EFI-configured guest may not boot in BIOS mode
EFI: A BIOS/MBR-configured guest may not boot in EFI mode

Boot Delay

A boot delay is a pause after VM power-on and before the guest begins its normal boot sequence. VMware interfaces typically express this value in milliseconds.

The operational purpose is to give an administrator time to connect to the VM console and interrupt startup. A temporary delay can help when accessing firmware setup, selecting alternate installation media, or choosing a recovery device. Use a short delay that is long enough for the maintenance task. An unnecessary delay makes every VM startup slower.

Example guidance:
Use a short, purposeful delay while troubleshooting.
Connect to the console before powering on the VM.
Return the value to no delay or a lower value after maintenance.

Force Firmware Setup on the Next Boot

The force-firmware-setup option directs the VM to enter its configured firmware setup screen during the next startup. A BIOS-based VM opens BIOS setup; an EFI-based VM opens EFI setup.

This is useful for reviewing virtual boot-device order, checking whether firmware detects a virtual disk or CD/DVD device, and changing firmware-level settings. You need console access to interact with the setup screen.

This option is intended as a next-boot action. Clear it, or allow it to reset according to the client behavior, after completing the task. Otherwise, a later restart may unexpectedly return to firmware setup instead of starting the guest operating system.

Failed Boot Recovery

Failed boot recovery is a retry mechanism used when the VM cannot find a bootable device. After a configured or default waiting period, commonly 10 seconds, the VM attempts startup again.

Recovery can help with transient timing issues involving virtual disks, boot media, or attached devices. It does not repair a missing operating system, an invalid boot order, a disconnected boot disk, an incompatible firmware mode, or a damaged guest bootloader.

During troubleshooting, disabling failed boot recovery can be useful because it leaves the VM at the failure state long enough to inspect console messages. Repeated automatic retries can hide the original error or create a confusing startup loop.

VM Boot Options Reference

Option: Firmware: BIOS
What It Controls: Uses legacy VM firmware for startup
Typical Use Case: Older guest OS or BIOS/MBR installation
Key Caution: May not boot an EFI/GPT-configured guest

Option: Firmware: EFI
What It Controls: Uses modern VM firmware for startup
Typical Use Case: Current guest OS or EFI/GPT installation
Key Caution: May not boot a BIOS/MBR-configured guest

Option: Boot delay
What It Controls: Pauses startup after power-on
Typical Use Case: Gives console users time to interrupt startup
Key Caution: Unnecessarily increases startup time

Option: Force firmware setup
What It Controls: Opens BIOS or EFI setup on the next boot
Typical Use Case: Review boot order or firmware device detection
Key Caution: Clear or reset it after the maintenance task

Option: Failed boot recovery
What It Controls: Retries startup after no bootable device is found
Typical Use Case: Recover from a temporary device-detection timing issue
Key Caution: Does not fix an underlying boot configuration problem

Safe Change Procedure

  1. Confirm that the VM has a current backup or an appropriate snapshot and rollback policy for the environment. A snapshot is not a substitute for an independent backup.
  2. Document the current firmware mode, boot delay, firmware-setup behavior, failed boot recovery behavior, boot order, and connected boot devices.
  3. Plan a maintenance window if the VM must be powered off.
  4. Open the VM in the inventory and choose Edit Settings.
  5. Select VM Options, expand Boot Options, and make the smallest necessary change.
  6. If changing firmware, power off the VM first and confirm that the guest OS, bootloader, and disk partitioning support the target mode.
  7. Save the settings.
  8. Open the remote console before powering on or restarting the VM.
  9. Validate the result: confirm the expected firmware screen, startup delay, boot-device choice, or guest boot path appears.
  10. If the guest fails to start, revert the changed option when possible. For a firmware change, restore the original firmware mode before investigating a longer-term conversion.

Practical Examples

Install a Modern Operating System That Requires EFI

  1. Power off the VM or configure the new VM before first startup.
  2. Set its firmware to EFI.
  3. Attach the installation ISO through the virtual CD/DVD device.
  4. Start the VM and use the console to confirm that the installer launches.
  5. Verify that the installer creates or uses an EFI-compatible GPT disk layout.

Review Firmware Boot Order

  1. Open Edit Settings, select VM Options, and expand Boot Options.
  2. Enable the option to enter firmware setup on the next power-on.
  3. Open the remote console and start the VM.
  4. Review detected virtual disks, CD/DVD media, and other boot devices.
  5. Make the needed firmware-level adjustment, then clear or allow the next-boot setup action to reset.

Give an Administrator Time to Interrupt Startup

  1. Configure a short boot delay, measured in milliseconds where shown by the interface.
  2. Connect to the VM console before powering on.
  3. During the delay, use the available prompt or key sequence to enter firmware setup or select another boot device.
  4. Remove or reduce the delay after maintenance.

Investigate a No-Bootable-Device Message

  1. Observe and record the exact firmware message in the VM console.
  2. Confirm that the expected operating system disk is present and connected.
  3. Confirm that the selected BIOS or EFI mode matches the guest installation.
  4. Review firmware boot order and the virtual storage controller configuration.
  5. Use failed boot recovery only when a retry is appropriate after the underlying condition has been understood.

Boot Troubleshooting Considerations

Firmware settings and the guest OS bootloader are different layers. VMware firmware decides how to initialize virtual hardware and where to look for a boot device. The guest bootloader then loads the operating system. A correct vSphere setting cannot repair a missing or damaged guest bootloader.

  • Firmware mismatch: BIOS and EFI expect different guest boot arrangements.
  • Boot order: Firmware may try an empty CD/DVD device, network device, or another disk before the intended system disk.
  • Virtual disk attachment: The boot disk must exist in the VM hardware configuration and be connected.
  • Controller availability: The guest's storage controller and virtual disk must be presented in a way the guest can use during startup.
  • Boot partition format: MBR and GPT layouts commonly correspond to BIOS and EFI startup respectively, although guest conversion methods and operating-system support must be verified.
  • Console evidence: Use the VM console to capture firmware messages, bootloader errors, and prompts that are not visible from ordinary vSphere inventory views.

Boot Failure Diagnostic Checklist

Observed Symptom: No boot device detected
Likely Area to Check: Boot disk, boot order, firmware mode, or controller
Suggested Verification: Confirm the disk is present and connected, inspect firmware boot order, and compare BIOS/EFI with the guest layout

Observed Symptom: Guest does not start after firmware change
Likely Area to Check: Guest bootloader and partition format
Suggested Verification: Revert to the original mode, then validate a supported guest conversion before trying again

Observed Symptom: VM repeatedly retries boot
Likely Area to Check: Failed boot recovery and unresolved boot-device failure
Suggested Verification: Stop or disable repeated recovery during diagnosis and inspect the console failure

Observed Symptom: Unable to enter firmware setup in time
Likely Area to Check: Console timing and startup speed
Suggested Verification: Enable force firmware setup for the next boot or configure a temporary boot delay, then connect the console before power-on

Common Problems and Resolutions

The VM Reports No Bootable Device

Likely causes include a missing or disconnected operating system disk, an incorrect boot order, an incompatible firmware mode, or an unavailable virtual disk controller. Inspect the console output, verify the boot disk in VM hardware settings, enter firmware setup to inspect boot order, and validate BIOS versus EFI compatibility.

The VM Fails After Switching BIOS and EFI

The existing guest installation may have been configured for the previous firmware mode, or its partitioning and bootloader may not support the selected mode. Restore the original firmware mode when possible. If migration is required, plan a supported guest conversion or rebuild and test it in a recovery or non-production workflow first.

The Administrator Cannot Open Firmware Setup Quickly Enough

The VM may start faster than the console can be connected, or the console may have been opened after the startup window. Use force firmware setup for the next boot, or configure a temporary boot delay. Connect the console before powering on the VM.

The VM Loops Through Startup Retries

Failed boot recovery may be enabled while the underlying boot-device problem remains unresolved. Temporarily disable or avoid repeated recovery behavior, inspect the console, and correct the disk, boot order, firmware, controller, or guest OS problem. Re-enable recovery only when repeated attempts are operationally useful.

Key Terms

  • Virtual machine: A software-defined computer running on ESXi.
  • vSphere Client: The VMware management interface for vCenter Server or ESXi-managed VMs.
  • Edit Settings: The configuration interface for changing VM hardware and VM-level options.
  • VM Options: The settings area containing VM behavior and startup controls.
  • Boot Options: Controls for firmware mode, startup timing, firmware setup entry, and failed boot retries.
  • Boot device: A virtual disk, CD/DVD device, network interface, or another device from which firmware can attempt startup.
  • Guest operating system: The operating system installed inside the VM.

For a concise reference, return to VM Boot Options.