Force BIOS setup is not a permanent boot-order policy. It makes the virtual machine enter its firmware on the next power-on so an administrator can save a persistent order there. Once CD/DVD is above the hard disk, the firmware checks optical media first and falls through to the disk when no bootable ISO is connected.
This is safer than forcing CD-ROM as the only allowed class, which can strand the VM when recovery media is removed.
Prepare the VM and ISO
Confirm a current application-consistent backup and a console path. Shut down the guest cleanly; do not use Power Off as a substitute unless the operating system is already stopped.
Edit the virtual CD/DVD drive:
- Select the correct datastore ISO or client/device source.
- Enable Connect at power on for the boot that needs the media.
- Verify the ISO architecture and firmware support.
- Record the current firmware mode and Secure Boot state.
An ISO can be readable as a file but not bootable under the VM’s current UEFI mode. Broadcom documents cases where media lacking a compatible UEFI loader appears as No Media in the EFI boot manager.
Do not switch firmware from UEFI to legacy BIOS simply to make an old ISO boot. Broadcom’s firmware guidance warns that firmware must match the disk partition scheme; changing it can make the installed OS unbootable.
Set the Persistent Order Through Firmware
Broadcom’s current boot-order procedure applies to ESXi 7 and 8:
- Power off the VM.
- Open Edit Settings > VM Options > Boot Options.
- Select Force BIOS setup (the label may still be used for firmware setup).
- Power on and immediately open the VM console.
- In the BIOS or EFI boot section, place CD/DVD before the disk.
- Save changes and exit.
The force-setup selection is consumed for that startup, but the order saved inside firmware persists. Test twice: once with a known bootable ISO and once with the virtual CD disconnected. The second test must boot the normal disk without manual input.
If the firmware screen passes too quickly, set a temporary boot delay under the same vSphere Boot Options. Broadcom documents a maximum delay of 10 seconds for the bios.bootDelay mechanism. Remove unnecessary delay after validation.
Use Advanced Options Only When They Are Justified
For managed fleets, Broadcom documents the legacy BIOS advanced option:
bios.bootOrder = "cdrom,hdd"
It also documents PowerCLI through VirtualMachineBootOptions for BIOS or EFI VMs. These approaches are useful for repeatability, but they deserve the same backup, powered-off state, and readback verification as a GUI change.
Advanced bios.bootOrder and bios.hddOrder values can prevent later changes in the firmware UI until the parameters are removed. Device identifiers also vary with virtual hardware. Do not paste an example containing another VM’s NIC or disk keys.
The bios.bootDeviceClasses option is different. Broadcom states that it controls allowed device classes, not their sequence. Setting it to CD only may force optical boot, but it does not implement the desired “CD first, disk second” fallback.
Avoid an Accidental Reinstallation Loop
Leaving an installer ISO connected above disk can start setup again after a reboot. Many installers prompt before booting from media, but unattended images may not. After maintenance:
- Disconnect the ISO or clear Connect at power on.
- Leave the saved fallback order only if operations require it.
- Verify the guest disk boots normally.
- Record the change in the VM notes or configuration system.
For one-time recovery, the boot menu is usually safer than a permanent change. For a reusable appliance process, automate with PowerCLI and test on a clone.
A Physical Phone Is Not a Bootable VM Image
Cloning a phone into ESXi is a separate problem. A backup of mobile data does not contain a portable x86 or ARM virtual machine with supported drivers, radio hardware, trusted execution environment, secure boot keys, and vendor services. Android emulators and development images can run selected applications, but they are not an exact operational clone of a physical phone.
Treat boot order and mobile emulation as different projects. For the VM, the durable configuration is straightforward: keep the existing firmware type, connect compatible media, enter firmware once through vSphere, save CD/DVD before disk, and prove both media-present and media-absent boots.