OVMF vs. SeaBIOS: Choosing the Right Firmware for Your Proxmox Virtual Machines

For a long time, this was one of the most annoying little clusters in the Proxmox UI for me.

Not because the options were hidden. They were right there. That was the problem. SeaBIOS, OVMF, q35, i440fx, EFI disks, Secure Boot, passthrough notes — they all lived close enough together to make the whole thing feel like one big “advanced VM compatibility” setting. I kept reading them as variations on the same question, when in reality they belong to two different questions that only happen to meet in the same VM.

That distinction is what finally made the subject calm:

• firmware decides how the VM boots;
• machine type decides what kind of virtual motherboard or chipset the guest sees.

Once those roles separate, the menu stops feeling cryptic and starts feeling reasonable.

For the technical baseline below, I use Proxmox VE documentation and separate documented platform behavior from my own placement and operating recommendations.

I first treated firmware and machine type like one compatibility switch

This was the core mistake.

If the VM had trouble booting, or a feature seemed to want a different configuration, I would start looking at firmware and machine type together as if they were one blurred compatibility layer. The Proxmox documentation is actually much cleaner than that. It explicitly says Proxmox supports different firmware and machine types, namely SeaBIOS and OVMF, while separately describing the i440fx and q35 chipsets as virtual motherboard choices.

That separation matters a lot.

If you keep them mentally fused, you end up asking vague questions like:

• “Should I use q35 instead of SeaBIOS?”
• “Does OVMF replace q35?”
• “Is q35 the UEFI option?”

Those questions feel natural only because the concepts were never fully separated in the first place.

Firmware answers the boot question: BIOS-style or UEFI-style?

This is the cleanest starting point.

The Proxmox VM guide explains that QEMU needs firmware to emulate a computer, and on common PCs this is what we usually call BIOS or UEFI. Proxmox gives x86 guests two choices:

• SeaBIOS
• OVMF

The qm command reference reflects the same thing directly:

--bios <ovmf | seabios> (default = seabios)

That alone tells an important story. Firmware is not the same thing as virtual chipset. It is the early boot environment that initializes the VM and hands control to the operating system.

Once I started from that question instead of from passthrough folklore, the subject became much easier:

"Does this guest want or require a legacy BIOS-style boot path, or a UEFI-style boot path?"

SeaBIOS is the calm default because many standard VMs simply do not need more

The Proxmox documentation says this very plainly: by default, QEMU uses SeaBIOS, and SeaBIOS is a good choice for most standard setups.

That sentence is useful because it pushes back against the feeling that “default” must mean “outdated beginner mode.” It does not.

SeaBIOS is still a reasonable answer when:

• the guest OS does not require UEFI;
• Secure Boot is not part of the plan;
• PCIe passthrough is not driving the design;
• the VM is just meant to boot cleanly and stay uncomplicated.

I like this because it keeps the decision honest. Not every VM needs to become a modern-platform simulation project. A lot of VMs just need to start, stay compatible, and remain easy to understand.

That is exactly the kind of simplicity I also appreciate in early host design choices like installing Proxmox for the first time. The default is not always primitive. Sometimes it is just the least theatrical correct answer.

OVMF becomes necessary when the guest expects UEFI, Secure Boot, or modern passthrough patterns

This is where the other side of the choice becomes clear.

Proxmox documents OVMF as the UEFI implementation for guests and explicitly notes that some operating systems, such as Windows 11, may require a UEFI-compatible implementation. That alone already moves OVMF out of the “advanced optional tweak” category and into “sometimes required.”

The docs also point out other cases where SeaBIOS may not be ideal, such as VGA passthrough. Elsewhere in the passthrough guidance, Proxmox says best compatibility for GPU passthrough is usually reached with:

• q35 as machine type,
• OVMF instead of SeaBIOS,
• and PCIe instead of PCI.

That is an extremely useful trio because it shows how the concepts relate without making them identical.

OVMF is not “the q35 setting.”
q35 is not “the UEFI setting.”
But modern passthrough scenarios often want both.

OVMF asks for a little more ceremony than SeaBIOS

This is one of the most practical differences.

The Proxmox guide says that if you use OVMF, you need an EFI disk so settings such as boot order can be saved. That disk is included in backups and snapshots, and only one can exist per VM.

That alone makes OVMF feel slightly more structured:

• add OVMF;
• add an EFI disk;
• think about efitype;
• think about Secure Boot if it matters.

The documentation is also clear that for new VMs, efitype=4m should be used. It supports Secure Boot and has more room for future development. If distribution-specific and Microsoft keys are pre-enrolled, Secure Boot is enabled by default, although it can still be disabled from within the OVMF menu.

I do not think this makes OVMF difficult. It just makes it more explicit. There is more state to preserve and more platform behavior to care about.

That is appropriate for a UEFI-style environment. It is just worth naming so the extra steps do not feel mysterious.

q35 and i440fx are not firmware choices at all

This is the sentence I wish somebody had burned into my brain much earlier.

The Proxmox documentation describes these as machine types or virtual chipsets. You can choose between the older i440fx and q35, and the key practical distinction Proxmox emphasizes is that q35 provides a virtual PCIe bus.

That is a different job entirely from firmware.

So the better question is:

• firmware: how should this VM boot?
• machine type: what kind of virtual motherboard and PCI layout should the guest see?

That makes the pairings much easier to reason about.

You can have:

• SeaBIOS with i440fx;
• SeaBIOS with q35;
• OVMF with i440fx;
• OVMF with q35.

Not all of those pairings are equally common, but they are conceptually possible because firmware and machine type are separate axes.

q35 becomes especially relevant when PCIe matters

This is where a lot of the confusion comes from, because q35 so often appears next to OVMF in passthrough advice.

Proxmox explicitly says that while PCI passthrough is available for both i440fx and q35, PCIe passthrough is only available on q35 machines. It also says the pcie=on flag requires the q35 machine model.

That is why q35 shows up so often in “modern VM” tutorials. It is not replacing firmware. It is giving the guest a virtual platform that makes PCIe-oriented device presentation possible.

This is especially relevant in advanced setups like GPU passthrough, which is why it connects naturally to the broader logic behind the site’s passthrough-oriented Proxmox pieces.

The ordinary beginner decision is simpler than the internet often makes it look

This is the practical framework I would use now.

I would lean toward SeaBIOS when:

• the guest is ordinary and boots fine that way;
• I do not need UEFI-specific behavior;
• I do not need Secure Boot;
• I want the VM to stay simple and conventional.

I would lean toward OVMF when:

• the guest OS expects or benefits from UEFI;
• Windows 11 is involved;
• Secure Boot matters;
• PCIe or GPU passthrough is part of the plan;
• I want the VM to behave more like a modern UEFI-based machine.

I would think about q35 when:

• I need PCIe-aware virtual hardware layout;
• passthrough guidance points me there for a real reason;
• the guest benefits from a more modern virtual chipset.

I would stay with i440fx when:

• I do not need q35-specific behavior;
• the VM is otherwise happy;
• the simpler or older-compatible virtual platform is enough.

That framework is much calmer than “always use OVMF and q35 because modern is better.”

Windows guests deserve extra respect here

The Proxmox guide quietly reinforces this in several places.

Windows is more sensitive to virtual hardware changes than many Linux guests, and Proxmox even pins the machine version during creation for Windows guests because Windows can be sensitive to changes in virtual hardware enumeration.

That does not mean Windows is fragile. It means platform choices around firmware and machine type are more meaningful, and once the VM is established, unnecessary experimentation is less attractive.

So for Windows especially, I would rather choose intentionally at creation time than “see what happens” after the VM already matters.

The best combination for passthrough is a pattern, not a universal law

I think this is another place where nuance helps.

Proxmox says the best compatibility for GPU passthrough is typically:

• q35,
• OVMF,
• PCIe instead of PCI.

But the docs also note an important exception: if you want to use OVMF for GPU passthrough, the GPU itself needs a UEFI-capable ROM. Otherwise SeaBIOS may still be the correct answer.

That is one of those beautifully grounding Proxmox details. It prevents the conversation from collapsing into simplistic rules.

The better interpretation is:

this modern pairing is often best;
it is not magically correct for every guest and every device combination.

That is a much healthier way to think about the whole platform.

What I would choose now without overcomplicating it

If I were building an ordinary Linux server VM with no special platform requirements, I would not fight the default aggressively. SeaBIOS is often enough.

If I were building a modern Windows guest, a Secure Boot-sensitive guest, or anything that wants a clearly UEFI-shaped environment, I would go OVMF and add the proper EFI disk from the start.

If I were building a passthrough-focused VM, especially one involving PCIe devices or a GPU, I would think in pairs:

• OVMF for the firmware question;
• q35 for the machine-type question.

That is the separation I wish I had sooner. Once the questions split cleanly, the settings panel stops feeling like folklore and starts feeling like configuration.

Firmware is only one part of the virtual machine shape. The guide to vCPUs, physical cores, and sockets covers the topology choices that should be made independently from OVMF, SeaBIOS, q35, or i440fx.

This operating decision also connects to GPU Passthrough in Proxmox: Step-by-Step Guide for LXC Containers, where the same tradeoff appears at a different layer of the homelab.

Conclusion

What finally made this Proxmox choice feel understandable to me was realizing that firmware and machine type are neighbors, not twins. SeaBIOS versus OVMF is the boot-environment decision. i440fx versus q35 is the virtual-chipset decision. They influence each other in real-world designs, especially around Windows, Secure Boot, and passthrough, but they are not interchangeable labels for the same thing.

That distinction makes the right choice much calmer.

Choose SeaBIOS when the VM just needs a good standard BIOS path.
Choose OVMF when the guest wants UEFI, Secure Boot, or modern passthrough habits.
Choose q35 when the guest needs a PCIe-shaped virtual platform.

Once those sentences are separate, the whole menu becomes easier to trust.

FAQ

Is q35 the same thing as OVMF in Proxmox?

No. OVMF is firmware, meaning the UEFI boot environment. q35 is a machine type, meaning the virtual chipset and motherboard layout the guest sees.

When should I use OVMF instead of SeaBIOS?

Usually when the guest OS requires or benefits from UEFI, when Secure Boot matters, or when passthrough guidance specifically expects a UEFI-style guest.

Why is SeaBIOS still the default?

Because Proxmox documents it as a good choice for most standard setups. Many VMs do not need UEFI-specific behavior.

Does OVMF need anything extra?

Yes. Proxmox requires an EFI disk so the VM can persist UEFI-related settings such as boot order. For new VMs, the documentation recommends efitype=4m.

When does q35 matter most?

Mostly when PCIe matters, especially for PCIe passthrough and many GPU passthrough scenarios where the guest benefits from a PCIe-aware virtual machine type.