SeaBIOS vs OVMF (UEFI) in Proxmox VE: Which to Choose and How to Switch

Open the Create VM wizard in Proxmox VE and you'll hit a dropdown on the System step labeled BIOS, with two options: Default (SeaBIOS) and OVMF (UEFI). Most people click past it without reading either word twice. Then, three weeks later, they try to install Windows 11 in that same VM and get stuck at "This PC can't run Windows 11" — or they switch an existing VM to the other option and it won't boot at all.

That dropdown is picking which virtual motherboard firmware your VM boots from. It's not cosmetic. It decides whether Secure Boot exists, whether your boot disk can be bigger than 2 TB, whether Windows 11 will even install, and whether flipping the setting later will brick a working VM. None of that is obvious from a two-word dropdown, so let's actually go through it.

What You Will Learn

What SeaBIOS and OVMF actually are, and why Proxmox VE offers both
When you genuinely need OVMF and when SeaBIOS is the simpler, correct choice
How to set the firmware type correctly when creating a new VM
Why switching an existing VM's firmware usually breaks it, and how to fix that safely
The exact qm commands for doing all of this from the shell instead of the GUI
The errors this setting causes most often, and what each one actually means

What Is This Feature?

SeaBIOS is Proxmox's default legacy BIOS emulation. It behaves like the firmware that shipped on PCs from roughly the 1990s through the mid-2010s: it boots from a Master Boot Record (MBR), hands control to whatever bootloader sits in the first sector of the disk, and doesn't know or care about Secure Boot, because Secure Boot didn't exist yet when this boot method was designed.

OVMF stands for Open Virtual Machine Firmware. It's an open-source implementation of UEFI (Unified Extensible Firmware Interface) built for virtual machines, and it's what Proxmox VE uses to give a VM "modern" firmware — the same category of firmware your actual laptop almost certainly has. UEFI boots from a GPT-partitioned disk, reads bootloaders from a dedicated EFI System Partition, and can optionally enforce Secure Boot, which only allows cryptographically signed bootloaders and kernels to run.

There's a third piece that trips people up: the EFI Disk (shown in the config as efidisk0). OVMF needs somewhere to store its NVRAM variables — boot order, Secure Boot keys, and firmware settings — and unlike a real motherboard, a VM has no onboard flash chip for that. Proxmox stores it as a tiny separate disk, usually 1 MB to 4 MB depending on the format. If you pick OVMF and forget to add this disk, the VM has firmware with nowhere to save its state, and things go wrong in ways that are annoying to debug.

Setting	SeaBIOS (Default)	OVMF (UEFI)
Boot method	Legacy MBR	UEFI / GPT
Secure Boot support	No	Yes, optional
Needs an EFI Disk	No	Yes
Boot drive over 2 TB	Not reliably	Yes
Windows 11 / Server 2022+	Won't install	Required
Older Linux ISOs, DOS, legacy appliances	Usually fine	Sometimes unsupported
Recommended machine type	i440fx or q35	q35

Why Would You Use It?

You need OVMF the moment your guest operating system requires UEFI to boot at all. Windows 11 is the big one — Microsoft's installer checks for UEFI firmware and a TPM before it lets Setup continue, and SeaBIOS can't satisfy either. Windows Server 2022 and 2025 behave the same way. Recent Ubuntu Server images and Secure Boot–enforcing distributions also expect UEFI, and some GPU passthrough setups specifically want OVMF because certain cards behave better when they see a real UEFI GOP (Graphics Output Protocol) framebuffer during boot.

SeaBIOS is still the right default for a lot of workloads. If you're spinning up a minimal Debian container-host VM, an old Windows Server 2012 R2 box you're migrating in as-is, or basically anything that was originally installed on legacy BIOS hardware, SeaBIOS is simpler and has one less moving part — no EFI disk to manage, no Secure Boot key state to worry about, no chance of an OVMF firmware update changing boot behavior on you.

Honestly, if you're not sure which one you need, ask what OS you're installing. Windows 11 or Server 2022/2025? OVMF, no argument. Anything else and you're starting fresh? SeaBIOS is fine unless you have a specific reason to want Secure Boot. The one case where it genuinely doesn't matter is a lot of modern Linux distros — most of them boot cleanly under either firmware, so pick whichever matches the rest of your fleet for consistency.

Prerequisites

Proxmox VE 8.x or 9.x (the examples below are from a 9.2 host, but the GUI hasn't changed meaningfully since 8.0)
Root or a user with VM.Config.Hardware and VM.Config.Options permissions on the node
Access to the VM's Hardware and Options tabs in the web interface, or SSH access to the node for the qm commands
A storage location that supports small raw disks for the EFI disk — local-lvm, ZFS, and most other Proxmox storage types all work
For an existing VM: a snapshot or backup taken before you touch this setting, since firmware mismatches can leave a VM unbootable

Step-by-Step Tutorial

Setting firmware correctly on a brand-new VM

This is the easy path, because the OS hasn't been installed yet, so there's nothing that can already be tied to the wrong firmware type.

Click Create VM in the top-right corner of the Proxmox web interface.
On the General tab, name the VM as usual and move on.
On the OS tab, attach your installation ISO and select the correct Guest OS type — this matters more than people expect, since Proxmox tunes some defaults based on it.
On the System tab, set BIOS to OVMF (UEFI) if you're installing Windows 11, Windows Server 2022/2025, or anything else that requires UEFI. Leave it on Default (SeaBIOS) otherwise.
If you chose OVMF, a new field appears: EFI Storage. Pick the storage where the EFI disk will live — a few megabytes is all it needs.
Check the box for Pre-Enroll keys if you want Secure Boot enabled with Microsoft's default certificate authorities already loaded. Windows 11 wants this checked. Most Linux installers work fine either way, though a few Secure Boot–signed kernels expect it too.
Still on the System tab, set Machine to q35 if you picked OVMF. SeaBIOS works with both i440fx and q35, but OVMF is more reliable on q35, particularly for Windows guests.
Finish the rest of the wizard (disk, CPU, memory, network) as you normally would, then start the VM and install the OS.

Changing firmware on an existing VM (and why it usually isn't that simple)

Here's the part that catches people out: an operating system that was installed under SeaBIOS was formatted with an MBR partition table and its bootloader written to the MBR's boot sector. Flip the VM to OVMF afterward, and the new UEFI firmware goes looking for a GPT disk with an EFI System Partition — and finds neither. The disk itself hasn't changed, only the firmware reading it has, so the two no longer agree on how to boot.

If you still want to make the switch, here's the realistic path:

Take a snapshot or full backup of the VM first. This is not optional — if the conversion doesn't go cleanly, you want an easy way back.
Shut the VM down completely (not just a reboot).
Go to the VM's Hardware tab, click Add, and select EFI Disk. Choose a storage location and, if you want Secure Boot, check Pre-Enroll keys.
Go to Options, double-click BIOS, and change it from Default (SeaBIOS) to OVMF (UEFI).
For Windows guests, you generally need to convert the disk from MBR to GPT before this will boot — Windows ships a tool called mbr2gpt.exe for exactly this, run from inside the still-SeaBIOS VM before you flip the firmware setting. Skipping this step is the single most common reason people end up with an unbootable VM.
For Linux guests, you'll typically need to boot from a live ISO after the switch, repartition or add an EFI System Partition, and reinstall the bootloader package (grub-efi-amd64 on Debian/Ubuntu) so it writes the right files to the new EFI partition.
Start the VM. If it doesn't boot straight to the OS, press Esc once during the brief splash screen to reach the OVMF boot menu, where you can inspect and manually add boot entries if the automatic ones aren't there yet.

If reading that made you reconsider, that's a fair reaction. For most people, converting an existing VM's firmware isn't worth the risk — it's usually less work to build a fresh VM with the firmware set correctly from the start and migrate data into it.

Doing all of this from the shell instead

Everything above has a qm equivalent, which is faster once you know it and easier to script if you're building VMs from templates.

qm set 100 --bios ovmf
qm set 100 --efidisk0 local-lvm:1,efitype=4m,pre-enroll-keys=1
qm set 100 --machine q35
qm config 100

Run those against a stopped VM. The qm config line at the end just prints the current configuration so you can confirm the changes actually took.

Commands Explained

qm set 100 --bios ovmf — sets VM 100's firmware to OVMF. Use --bios seabios to go back to legacy BIOS, which is also the default if you never set this flag.
qm set 100 --efidisk0 local-lvm:1,efitype=4m,pre-enroll-keys=1 — creates a 1 MB placeholder request (Proxmox rounds this up to whatever the actual EFI variable store needs) on the local-lvm storage. efitype=4m selects the newer, larger 4 MB variable store, which is the current recommended default and supports Secure Boot properly. pre-enroll-keys=1 loads Microsoft's standard UEFI certificate authorities into that store automatically, which is what Windows 11 expects to find.
qm set 100 --machine q35 — switches the emulated chipset to Q35, a newer PCIe-based virtual motherboard. Not strictly required for OVMF, but it's the combination Proxmox and most guest OSes are tested against most heavily.
qm config 100 — dumps VM 100's full configuration file so you can see exactly what's set, including bios, efidisk0, and machine lines.
qm start 100 — starts the VM after making these changes. It has to be stopped, not just suspended, before qm set will accept firmware changes.

Common Errors

"No bootable device" immediately after switching to OVMF — the disk is still MBR-formatted or has no EFI System Partition. The firmware changed; the disk's layout didn't.
VM boots straight into the "UEFI Interactive Shell" — OVMF started but couldn't find a valid boot entry to hand control to. This is a symptom of the same MBR/GPT mismatch, or an EFI disk that got created but never populated.
Windows 11 installer still says "This PC can't run Windows 11" after you added a TPM — check the BIOS setting itself. A virtual TPM alone doesn't help if the VM is still on SeaBIOS; Windows 11 checks for UEFI first.
"start failed: could not find efidisk0" or similar on VM start — BIOS is set to ovmf in the config but the EFI disk got deleted or never created. Add it back through Hardware > Add > EFI Disk.
GRUB rescue prompt or boot loop after a Linux firmware switch — GRUB was installed for legacy BIOS boot and hasn't been reinstalled in EFI mode. This needs a live-boot repair session, not a config change.

Troubleshooting

For the MBR-to-GPT problem on Windows: boot the VM one more time on SeaBIOS (switch it back if you already flipped it), open an elevated Command Prompt inside Windows, and run mbr2gpt /validate first to check whether the disk layout is even eligible for conversion. If that passes, run mbr2gpt /convert. Only after that succeeds should you shut down, add the EFI disk, and switch bios to ovmf.

For the Linux GRUB problem: attach a live ISO of the same distribution (or a rescue ISO like SystemRescue) to the VM's CD drive, boot from it, mount the root filesystem and any existing EFI partition, chroot into the mounted system, and run grub-install targeting the EFI System Partition, followed by update-grub. If there's no EFI System Partition at all, you'll need to create one with parted or gdisk first — usually a 100–500 MB FAT32 partition flagged as an EFI System Partition.

If you land in the UEFI Interactive Shell and just want to check what OVMF sees, type fs0: (or fs1:, fs2:, and so on) to switch to a detected filesystem, then dir to list its contents. If you can see an EFI folder with a Boot subfolder inside it, the partition is there — the firmware just doesn't have a saved boot entry pointing at it yet, which you can usually fix from the Boot Maintenance Manager in the same shell rather than rebuilding anything.

One more thing worth checking before you assume the firmware is the problem: make sure the EFI disk's storage actually has space. It's tiny, but if the target storage pool is completely full, Proxmox can't write to it, and you'll see a vague storage error rather than anything that mentions EFI directly.

Best Practices

Decide on the firmware type before you install the OS, not after. It costs nothing to pick correctly up front and saves you the MBR/GPT conversion dance entirely.
Default new Windows and Secure-Boot-aware Linux VMs to OVMF with efitype=4m and pre-enroll-keys=1 — the older 2 MB EFI type is a legacy option you don't need on a current install.
Pair OVMF with the q35 machine type unless you have a specific reason not to.
Always snapshot before touching the BIOS setting on a VM that's already running something important. This single habit turns a potential multi-hour recovery into a two-minute rollback.
Keep a short note (a VM description, a tag, whatever you actually check) of which VMs use OVMF and which use SeaBIOS. It matters again the next time you clone, migrate, or restore one of them.
When restoring a backup to new hardware or a new cluster, double check the BIOS setting carried over correctly — it usually does, but it's a five-second check against a very annoying failure mode.

Frequently Asked Questions

Do I need OVMF for a normal Ubuntu or Debian VM?

No. Both boot fine under SeaBIOS. Use OVMF only if you specifically want Secure Boot or GPT-only features like a boot disk over 2 TB.

Can SeaBIOS boot from a disk larger than 2 TB?

Not reliably as the boot/system disk, because MBR partition tables cap addressable space around 2 TB. A large data disk attached separately is fine either way — this limit is specifically about the disk the firmware boots from.

Does Secure Boot work with Linux under OVMF?

Yes, for distributions that ship signed bootloaders and kernels, which covers Ubuntu, Fedora, and most major distros out of the box. Check Pre-Enroll keys when adding the EFI disk so the standard Microsoft/Linux Foundation keys are already present.

Is OVMF slower than SeaBIOS?

Not in any way you'd notice. The firmware only runs for the few seconds before the OS takes over; it has no effect on runtime performance afterward.

What happens to the EFI disk during backup and migration?

It's backed up and migrated along with the rest of the VM's disks automatically — you don't need to handle it separately in vzdump, Proxmox Backup Server, or live migration.

I switched to OVMF by accident before installing anything. Do I need to reinstall?

No — if the OS was never installed yet, there's nothing tied to the old firmware. Add the EFI disk, keep OVMF (or switch back to SeaBIOS if you'd rather), and run the installer fresh.

Conclusion

The BIOS dropdown looks like a throwaway setting, but it's really choosing which era of PC firmware your VM is going to pretend to be. Get it right before you install the guest OS and it's a non-issue. Get it wrong, or need to change it later, and you're dealing with partition table conversions and bootloader repairs instead of a simple toggle. When in doubt: SeaBIOS for anything old or simple, OVMF with a 4 MB EFI disk and pre-enrolled keys for Windows 11 and anything that specifically asks for Secure Boot.

Vormox is an independent virtualization management platform built on Proxmox VE. Proxmox® and Proxmox VE® are trademarks of Proxmox Server Solutions GmbH. Vormox is not affiliated with, endorsed by, or sponsored by Proxmox.

SeaBIOS vs OVMF (UEFI) in Proxmox VE: Which One Should You Choose, and How to Switch Safely