Proxmox i440fx vs Q35: When to Use Each VM Machine Type for PCIe and GPU Passthrough

If that alphanumeric string triggers a wave of 1990s nostalgia, your instincts are spot on. By leaving that setting alone, you are instructing QEMU to construct your virtual machine around an emulated Intel 440FX chipset—a piece of silicon originally introduced in 1996 for the Pentium Pro era.

At first glance, building modern Windows or Linux workloads on top of a thirty-year-old motherboard architecture sounds like a severe configuration blunder. Why would a modern enterprise hypervisor default to a chipset from the dial-up era when a much newer option sits right next to it in the same menu? As it turns out, that vintage hardware profile is not an oversight or a performance trap; it is a calculated exercise in compatibility. Knowing what the machine type actually governs—and when you actually need to switch to its newer q35 counterpart—can save you from both botched PCIe passthrough setups and unnecessary maintenance headaches.

What the Machine Type Actually Controls​

To understand why an ancient chipset is still doing heavy lifting in modern virtualization, you first have to separate the Machine setting from the options surrounding it. In Proxmox VE, QEMU emulates an entire PC platform in software, including a motherboard, network controllers, and storage interfaces so the guest operating system interacts with them just as if it were installed on physical hardware.

When a guest operating system boots, it probes the system to discover its foundational layout: the chipset, the system buses, and the built-in controllers. The Machine dropdown defines this virtual motherboard. It is easy to conflate this with neighboring settings in the wizard, so keeping their boundaries distinct is essential:

• Machine Type (i440fx vs. q35): Dictates the virtual motherboard, chipset, and bus topology (specifically whether the board uses conventional PCI or PCI Express).
• BIOS / Firmware (SeaBIOS vs. OVMF): Selects the boot environment (legacy BIOS versus UEFI).
• CPU Type (such as x86-64-v2-AES or host): Determines which processor instruction sets and feature flags are exposed to the guest OS.
• Disk and Network Controllers: Act as the expansion cards and drives plugged into the virtual motherboard.

According to official QEMU documentation, the pc-i440fx machine model simulates an Intel i440FX host PCI bridge alongside a PIIX3 PCI-to-ISA southbridge. That virtual board comes wired with conventional PCI slots, two PCI IDE interfaces, PS/2 mouse and keyboard connections, serial ports, USB controllers, and ACPI power management. Crucially, there is no PCI Express (PCIe) bus anywhere on an i440fx virtual board. If you open a terminal inside a Linux VM running on this default profile and run lspci, the top of the device tree will openly report those classic 1990s Intel bridge names.

Changing a VM's machine type is the virtual equivalent of keeping your processor, RAM, and hard drives while ripping out the motherboard underneath them and dropping in a completely different board layout.

Section Summary: The Machine setting in Proxmox defines the virtual motherboard and bus layout (i440fx for conventional PCI, q35 for PCI Express), operating independently of your VM's CPU instruction set or UEFI/BIOS firmware choice.

Why a 1996 Chipset Isn't Throttling Your VM​

If you are running Windows Server or a high-traffic database container on an emulated 1996 motherboard, is your workload secretly bottlenecked by Pentium Pro-era bus speeds?

In short: no. QEMU replicates the logical layout and device IDs of the 440FX chipset so the guest operating system knows how to talk to the board, but it does not emulate the physical electrical limits or clock-speed bottlenecks of 1996 silicon.

Here is why your VM's performance lives elsewhere:

1. Direct CPU Execution via KVM: Your virtual machine’s code is not being translated through an emulated 1990s processor. Through Kernel-based Virtual Machine (KVM), guest instructions execute directly on your physical host CPU. As XDA Developers notes, Proxmox defaults its CPU model to x86-64-v2-AES, which exposes instruction sets dating from Intel's Westmere generation onward—or you can set the CPU type to host on standalone workstations to pass every native instruction flag straight through to the guest.
2. Paravirtualized Storage and Networking (VirtIO): In a virtualized environment, raw I/O throughput comes down to how your storage and network adapters communicate with the hypervisor. Instead of forcing the system to emulate legacy IDE drives or vintage network cards, Proxmox recommends using VirtIO devices. Paravirtualized VirtIO drivers bypass hardware imitation altogether and cooperate directly with the hypervisor. (While XDA Developers attributes VirtIO SCSI single becoming the default for new Linux VMs to Proxmox VE 7.3, Proxmox documentation has long recommended VirtIO SCSI for performance-oriented guests.) Because these VirtIO controllers talk directly to QEMU/KVM over the virtual bus, the historical vintage of the surrounding northbridge barely registers.

Section Summary: Emulating an i440fx chipset only defines how devices are organized on the virtual board; because KVM runs code on your host CPU and VirtIO handles storage and networking via paravirtualization, the age of the chipset does not impose 1990s speed limits.

Where i440fx Holds You Back: The Case for q35​

If i440fx is stable and fast when paired with VirtIO, why does the Q35 option exist in the dropdown?

Selecting q35 instructs QEMU to emulate Intel’s Q35 Express chipset paired with an ICH9 southbridge, an architecture XDA Developers notes dates back to 2007. While 2007 hardware is hardly bleeding-edge either, it introduces one vital capability that i440fx lacks: a virtual PCI Express (PCIe) bus.

There are three concrete scenarios where choosing q35 matters:

1. GPU and PCIe Hardware Passthrough​

When you configure PCI passthrough (VFIO) to hand a physical host device—such as a discrete graphics card, an NVMe controller, or a high-speed NIC—directly to a virtual machine, bus topology becomes critical. While passing a device through to an i440fx VM is technically possible, the guest sees that hardware attached as a conventional PCI card. Modern GPU drivers (especially on Windows and Linux) frequently expect to communicate with the card over a PCIe root port and access PCIe extended configuration space. As XDA Developers points out, Proxmox’s option to present a passed-through device on a virtual PCIe port only functions when the VM uses q35. Of course, q35 alone does not guarantee passthrough success—you still need proper host IOMMU groups, VFIO binding, and compatible guest drivers—but it is the right foundation.

2. Emulated IOMMU Requirements​

If your workload requires an emulated Input-Output Memory Management Unit inside the guest—for instance, for nested virtualization, advanced DMA remapping, or specific guest security features—QEMU’s official manual is unequivocal: the -device intel-iommu (Intel VT-d emulation), amd-iommu (AMD-Vi emulation), and virtio-iommu-pci options are only supported on x86_64 when using -machine q35.

3. Windows 11 Guest Presets​

If you have deployed a Windows 11 virtual machine on Proxmox recently, you might already be using q35 without realizing it. According to XDA Developers, when you set the Guest OS type to Windows 11 in the Proxmox creation wizard, Proxmox automatically selects q35 alongside OVMF (UEFI) firmware and a virtual TPM 2.0 module.

Section Summary: You should choose q35 when building VMs that require a virtual PCIe bus—most notably for GPU passthrough, Windows 11 deployments, or workloads requiring QEMU's emulated IOMMU devices.

Why You Shouldn't Flip Existing VMs to q35​

Once administrators learn that q35 is more than a decade newer than i440fx, the immediate temptation is to open every running VM in the cluster, flip the Machine dropdown to q35, and reboot.

Resist that urge. Unless an existing VM specifically needs a PCIe bus or virtual IOMMU, swapping the virtual motherboard underneath an already-installed operating system invites unnecessary downtime.

• Linux Network Interface Renaming: Modern Linux distributions use "Predictable Network Interface Names" (via systemd/udev), which assign interface names based on where the virtual NIC sits on the system's PCI bus topology. When you switch a VM from i440fx (conventional PCI) to q35 (PCIe), the bus layout changes. As XDA Developers illustrates, an interface originally named ens18 might suddenly reappear after reboot as something like enp6s18. If your /etc/network/interfaces or Netplan configuration is hardcoded to the old interface name, the VM will boot up completely disconnected from the network, forcing you to log in through the Proxmox web console to repair the config.
• Windows Driver and Boot Reconfiguration: Windows guests can be even more sensitive to having their underlying chipset swapped out from under them. Because moving from an i440FX/PIIX3 layout to a Q35/ICH9 layout alters the fundamental bridge and storage controller hierarchy, a Windows VM may trigger extensive hardware re-detection, demand driver repairs, or fail to boot cleanly if its storage path changes.
• Why the Default Stays Put: As XDA Developers observes, Proxmox keeps i440fx as the baseline default largely for backward compatibility and predictability—and because VMs without an explicitly pinned machine type rely on the system default, altering that global default would unexpectedly swap the virtual board underneath older configurations.

Practical Checklist Before Changing a VM's Machine Type​

If you have an existing VM that genuinely needs to move from i440fx to q35 (for example, you are adding a passed-through GPU to an existing server), follow a strict maintenance routine:

1. Take a full Proxmox backup or snapshot of the VM before touching the Hardware tab.
2. Ensure VirtIO drivers are installed and healthy (especially the Fedora/Red Hat VirtIO Windows drivers if migrating a Windows guest).
3. Verify your out-of-band console access (noVNC or SPICE in the Proxmox web UI) so you can log in locally if the network adapter changes its bus address.
4. Update network configurations immediately after first boot on Linux guests by running ip link to check whether the interface name shifted.

Section Summary: Switching an established VM from i440fx to q35 alters the guest-visible PCI bus layout, which can rename Linux network interfaces and trigger hardware repair prompts in Windows. Leave working VMs on i440fx unless you have a concrete requirement for PCIe features, and always take a snapshot before making the change.