You installed a Windows 11 VM, uploaded the ISO, clicked through the wizard, and hit start. Instead of the installer, you got a black screen that says "No bootable device found" - or worse, the installer keeps launching over and over even after you finished setup. Nine times out of ten, this isn't a broken VM. It's the boot order.
Boot order tells the virtual machine's firmware which device to try first when it powers on: a disk, a CD/DVD drive, or the network. Get it wrong and the VM either can't find anything to boot from, or it keeps booting the installer instead of the operating system you just installed. It's a five-minute fix once you know where to look, and it trips up nearly everyone the first time they build a VM in Proxmox VE.
What You Will Learn
- What boot order actually controls, and why VMs have more than one bootable device
- The difference between SeaBIOS and OVMF (UEFI), and why it matters for Windows 11
- How to change boot order from the Proxmox VE web interface
- How to do the same thing from the command line with
qm set - Why VMs get stuck reinstalling the OS over and over, and how to break the loop
- What "No bootable device found" actually means and how to fix it
What Is This Feature?
Every VM in Proxmox VE has a list of devices it's allowed to boot from, and an order it tries them in. That list usually includes a hard disk (like scsi0 or virtio0), a CD/DVD drive (usually ide2, used for your install ISO), and sometimes a network interface (net0) for PXE booting.
When you power on a VM, its virtual firmware walks down that list from top to bottom. The first device it finds with something bootable on it wins. If your disk is empty and the ISO is first in line, it boots the installer. If the disk already has an OS on it but the ISO is still first, it boots the installer again - even though you're done installing.
This is exactly the same concept as changing boot order in a physical PC's BIOS to boot from a USB stick instead of the internal hard drive. Proxmox VE just gives you a GUI for it instead of mashing F12 during POST.
SeaBIOS vs OVMF (UEFI): Why It Matters Here
Before you touch boot order, it helps to know which firmware your VM is using, because it changes what "bootable" even means.
| Firmware | What It Is | When You'd Use It |
|---|---|---|
| SeaBIOS | Legacy-style BIOS emulation, the Proxmox VE default for new VMs | Most Linux distros, older Windows versions, general homelab use |
| OVMF (UEFI) | Open-source UEFI firmware implementation | Windows 11 (it's a hard requirement), some newer Linux installers, Secure Boot setups |
Here's the part that catches people off guard: if you pick OVMF, Proxmox VE also needs a small extra disk called an EFI disk (efidisk0) to store UEFI variables like the boot entries themselves. Without it, the VM can boot fine once but "forget" its boot configuration on the next restart. The VM creation wizard adds this automatically when you choose UEFI - you generally don't need to add it by hand unless you're editing an existing VM's firmware type after the fact.
If you're planning a Windows 11 VM specifically, know that boot order is only half the story. Windows 11 also checks for a TPM device and, depending on the ISO, Secure Boot. Those are separate settings from boot order (they live under the same Options tab, as EFI Disk and TPM State), but they're worth mentioning here because a VM that boots the installer fine can still get rejected partway through setup with "This PC can't run Windows 11" if the TPM device is missing. That's a different problem from anything covered in this guide - just don't confuse the two when something goes wrong.
Why Would You Use It?
You'll end up changing boot order for one of a few reasons:
- You just finished installing an OS and need the VM to boot from disk instead of looping back into the ISO installer
- You're troubleshooting a VM that won't start and want to rule out boot order as the cause
- You added a second disk or NIC and Proxmox is now trying to boot from the wrong one
- You're setting up network (PXE) booting for something like an automated OS deployment
Honestly, most people only ever touch this setting twice per VM: once to boot the installer, and once to switch back to the disk when installation is done. It's not something you need to think about day to day.
Prerequisites
Before you start, make sure you have:
- A working Proxmox VE installation (this guide applies to both 8.x and 9.x - the Boot Order interface hasn't changed between them)
- At least one VM already created, with a disk attached
- Access to the Proxmox VE web interface at
https://your-server-ip:8006, or SSH access to the host if you'd rather use the command line - The VM's ID number (visible in the left-hand resource tree, shown in parentheses next to the VM name, like
100)
You don't need the VM to be running for any of this. In fact, changing boot order on a running VM won't take effect until the next restart anyway.
Step-by-Step Tutorial
Method 1: Using the Web Interface
This is the method most beginners should use - it's visual, and it's harder to make a typo that breaks things.
- Log in to the Proxmox VE web interface and click the VM you want to change in the left-hand tree.
- Click Options in the VM's menu on the left.
- Find the row labeled Boot Order and double-click it (or select it and click Edit at the top).
- A dialog opens showing every possible boot device for that VM: your disk(s), the CD/DVD drive, and any network interfaces. Each one has a checkbox next to it.
- Drag devices up or down to set the order you want. The device at the top is tried first.
- Make sure the checkbox is ticked for any device you actually want to boot from. An unchecked device gets skipped completely, even if it's at the top of the list.
- Click OK to save.
For a fresh install, you'd put the CD/DVD drive (your ISO) first, disk second. Once the OS is installed and working, come back to this same dialog, drag the disk to the top, and either uncheck the CD/DVD drive or eject the ISO entirely (right-click the CD/DVD device under Hardware and choose Eject CD/DVD Media).
Method 2: Using the Command Line
If you're comfortable with SSH, or you're scripting VM setup, you can set boot order directly with qm, Proxmox VE's command-line tool for managing VMs.
First, check the VM's current configuration:
qm config 100Look for a line starting with boot:. On a fresh VM it typically looks something like:
boot: order=scsi0;ide2;net0To set the disk first and the CD/DVD drive second, run:
qm set 100 --boot order=scsi0;ide2Notice that net0 is missing from this second example - anything left out of the list simply isn't a boot option anymore, which is a clean way to disable network booting if you don't need it. Replace scsi0 and ide2 with whatever device IDs actually apply to your VM; check qm config first so you're not guessing.
Commands Explained
| Command | What It Does |
|---|---|
qm config <vmid> | Prints the full configuration of a VM, including disks, network interfaces, and the current boot order line |
qm set <vmid> --boot order=... | Sets the boot order for the VM. Devices are listed in priority order, separated by semicolons |
qm start <vmid> | Starts the VM so you can confirm the new boot order actually works |
qm monitor <vmid> | Opens the QEMU monitor for the VM, useful if you need to check hardware state while debugging a boot issue |
One thing worth knowing: qm set changes take effect on the next boot, not immediately. If the VM is already running, you'll need to restart it (a reboot from inside the guest OS is not enough if you changed boot order - do a full stop and start from Proxmox, or at least a reset).
Common Errors
"No bootable device found"
This means the firmware walked through every device in the boot order and didn't find anything it recognized as bootable. Usual causes:
- The disk is genuinely empty because the OS install never finished
- The disk device is unchecked in the Boot Order list
- You're using OVMF (UEFI) but the OS was installed in a way that only wrote a legacy BIOS boot record, so UEFI firmware can't find anything to hand off to
VM keeps booting into the installer again
This is the classic one. It means your CD/DVD drive (with the install ISO still attached) is ranked above your disk in the boot order. The disk has your finished OS on it, but the firmware never gets that far because it stops at the ISO first. Fix: move the disk above the CD/DVD drive, or eject the ISO.
A quick real example: say you install Ubuntu Server 24.04 on VM 100, the install finishes, and the VM reboots itself as part of the installer's normal flow. You watch it boot straight back into "Try or Install Ubuntu" instead of your fresh login prompt. Nothing is wrong with the install. The boot order still lists ide2 (the ISO) ahead of scsi0 (the new disk), so that's exactly what it does every single time. Ninety percent of "my install won't finish" reports on the Proxmox forums turn out to be this.
"Guest has not initialized the display (yet)"
Not strictly a boot order problem, but it shows up around the same time for beginners. It just means the VM hasn't reached the point where it renders video output yet - give it a few more seconds, especially on a VM's very first boot.
Troubleshooting
If changing boot order didn't fix things, work through these in order:
- Confirm the change actually saved. Run
qm config <vmid>again and check theboot:line matches what you expect. - Check that the ISO is actually mounted if you're trying to boot from it. Under Hardware, click the CD/DVD device and confirm it points at your ISO file, not "do not use any media."
- Verify the disk isn't actually empty. If the OS install crashed partway through, the disk may have no valid boot record at all, and no boot order setting will fix that - you'll need to reinstall.
- Match the firmware to the OS. If you're installing Windows 11 and the VM's BIOS type under Options is set to SeaBIOS instead of OVMF, the install will either refuse to proceed or behave strangely. You'll need to recreate the VM with OVMF selected, since firmware type isn't something you should switch on a VM that already has an OS installed.
- Full stop, not reboot. Stop the VM completely from the Proxmox summary page, then start it again, rather than rebooting from inside the guest. Some boot-order changes don't apply cleanly through a soft reboot.
Best Practices
- Eject the ISO once installation is done. Leaving it attached "just in case" is exactly how reinstall loops happen months later after an unrelated reboot.
- Keep the boot order list short. If a VM only ever boots from one disk, there's no reason to leave the CD/DVD drive or network interface checked in the list.
- Decide on firmware (SeaBIOS or OVMF) before you install the OS, not after. Changing it later usually means a fresh install.
- If you're building a lot of VMs from a template, set the boot order once on the template with the disk first and CD/DVD drive unchecked - clones will inherit it, and you won't repeat this step for every new VM.
Frequently Asked Questions
Do I need to change boot order every time I create a VM?
Only if you're installing from an ISO. You'll set the CD/DVD drive first for installation, then switch back to the disk afterward.
What happens if I leave the network interface first in boot order by accident?
The VM will try to PXE boot over the network before checking the disk. If there's no PXE server on your network, it usually just times out after a delay and moves to the next device, so it's not harmful, just slower to start.
Can I set boot order before the VM has ever been started?
Yes. Boot order is just a configuration value; it doesn't depend on the VM having run before.
Does boot order affect LXC containers too?
No. Containers don't have virtual firmware the way VMs do - they share the host's kernel directly, so there's no BIOS or UEFI boot sequence to configure.
My VM has multiple disks. Which one should be first?
Whichever one has your operating system installed on it. A second data disk should generally stay unchecked in the boot list entirely, since it has nothing to boot from anyway.
I set the boot order correctly but nothing changed. Why?
Almost always because the VM was only rebooted from inside the guest OS instead of stopped and started from Proxmox. Some boot-order and firmware changes only get picked up on a cold start. Stop the VM fully, wait a second or two, then start it again.
Is there a risk to experimenting with boot order on a production VM?
Not really, as long as you don't uncheck the disk the OS actually lives on while the VM is running something important. Worst case if you get it wrong is the VM won't start until you fix the order again - it won't touch or damage any data on the disks themselves.
Conclusion
Boot order is one of those settings that looks intimidating the first time you see the dialog, but it really only has two states you'll use in practice: ISO first while installing, disk first once you're done. Once that clicks, "No bootable device found" and endless reinstall loops mostly stop being mysteries and start being a thirty-second fix in the Options tab.
If you're still getting stuck after working through the troubleshooting steps here, double-check that the firmware type (SeaBIOS vs OVMF) actually matches what your OS installer expects - that mismatch causes more boot order confusion than almost anything else.