i440fx vs Q35 in Proxmox VE: What the Machine Type Setting Actually Does (And When to Change It)

Open the hardware tab for any VM in Proxmox VE and you'll spot a setting most people click right past: Machine, sitting quietly under Options with a value like Default (i440fx). It doesn't look like much. No warning icon, no red text. But this one dropdown decides what kind of virtual motherboard your VM thinks it's running on, and it's the reason some GPU passthrough guides work perfectly on one VM and fail mysteriously on another.

If you've ever seen a forum post tell you to "just switch to q35" without explaining what that actually changes, this is the article that fills in the gap. We'll go through what i440fx and q35 really are, when the difference matters for a homelab or small business setup, and how to change it without turning a working VM into a boot loop.

What You Will Learn

• What a "machine type" actually is in Proxmox VE and QEMU
• The real differences between i440fx and q35, not just "one is newer"
• When changing it matters — and the far more common cases where it doesn't
• How to change machine type safely, with a rollback plan if it goes wrong
• What the machine version number (like pc-q35-9.2) means and why Windows VMs pin it
• The specific errors this setting causes and how to fix each one

What Is This Feature?

Every VM needs to believe it's running on some kind of physical computer, even though there's no real motherboard underneath. QEMU, the virtualization engine Proxmox VE is built on, handles this by emulating a chipset — the collection of virtual components that make up the VM's "motherboard": how many PCI slots it has, what kind of disk controller it sees, how USB devices attach, that sort of thing. Proxmox VE gives you two chipsets to pick from for x86 VMs.

Intel 440FX (i440fx) is the older of the two, modeled on a chipset Intel shipped in actual desktop PCs back in the late 1990s. It's simple, extremely well tested by nearly every Linux distribution ever released, and it's what Proxmox VE picks by default when you create a new VM — mostly for backward compatibility, not because it's the better choice today.

Q35 is the modern option. It emulates a chipset closer to what real machines shipped from around 2011 onward, and it comes with a genuine PCI Express (PCIe) bus instead of i440fx's older PCI bus. It also gives your VM a native AHCI (SATA) controller and better USB 3.0 support out of the box.

Here's a quick side-by-side of what actually changes:

Feature	i440fx	q35
Bus type	PCI (legacy)	PCIe (modern)
PCIe passthrough (GPUs, NVMe, HBAs)	Not properly supported	Supported
Native SATA controller	No (needs IDE emulation)	Yes (AHCI)
USB 3.0 support	Limited	Better native support
vIOMMU (needed for some passthrough setups)	No	Yes
Proxmox VE default for new VMs	Yes	No — must be selected manually
Best fit	Old Linux distros, VMs that never need passthrough	Windows 11+, GPU/PCIe passthrough, anything modern

Neither chipset changes your VM's CPU performance in any measurable way for typical workloads. This is purely about what virtual hardware the guest operating system can see and talk to.

Why Would You Use It?

Most VMs genuinely don't care which chipset they run on. A Debian file server with a single VirtIO disk and a VirtIO network card will boot and run identically under either one. So why does this setting come up so often in guides and forum threads? A handful of specific situations force the question:

• PCIe passthrough. If you're passing a GPU, an NVMe drive, or a SATA/SAS HBA controller directly into a VM, that hardware needs a PCIe slot to attach to. i440fx only offers legacy PCI slots, so passthrough on i440fx is unreliable at best and often just doesn't work.
• Windows 11 and Windows Server 2022+. These need UEFI, Secure Boot, and a virtual TPM to install at all. While the vTPM device itself isn't strictly tied to q35, Microsoft's own installer checks get fussier on i440fx, and most guides — including the official Proxmox documentation — recommend q35 for modern Windows guests to avoid edge cases.
• More than a handful of SATA-style disks. i440fx handles disks by emulating IDE controllers, which cap out at 4 devices per controller. q35's native AHCI controller supports up to 6 SATA ports without extra fuss.
• Anything that needs a vIOMMU, like certain nested virtualization setups or more granular device isolation for passthrough.

If none of that applies to your VM — say, it's a plain Ubuntu server running Docker containers with VirtIO SCSI disks and a VirtIO NIC — you can leave it on i440fx forever and never notice a thing. I'd only bother changing an already-working VM if you're about to add passthrough hardware to it. Otherwise you're taking on risk for zero benefit.

Prerequisites

Before touching this setting on an existing VM, make sure you have:

• A Proxmox VE 8.x or 9.x host (the process is the same on both)
• A snapshot or a fresh backup of the VM you're changing — this is the one step people skip and then regret
• Shell access to the Proxmox node, either through the web UI's >_ Shell button or SSH, if you want to use the command line instead of the GUI
• The VM's ID number, visible in the left-hand resource tree (for example, 105)

If you're setting this on a brand-new VM you haven't installed an OS on yet, you can skip the backup — there's nothing to lose.

Step-by-Step Tutorial

1. Check the current machine type

Open the Proxmox web interface, click your VM in the left tree, then go to Hardware or Options depending on your version — machine type lives under Options → Machine. It'll show either Default (i440fx) or a specific q35 version.

You can also check it from the shell without opening the GUI at all:

qm config 105 | grep machine

If there's no machine line at all, the VM is using the Proxmox default, which is i440fx.

2. Back up the VM

From the VM's summary page, click Backup Now, or take a snapshot if your storage supports it (ZFS and most network storage do; plain LVM without thin-provisioning doesn't). This is the step that turns "uh oh, it won't boot" into a five-minute fix instead of a reinstall.

3. Change the machine type — GUI method

Shut the VM down completely first; this isn't a live-editable setting. Then:

1. Go to Hardware tab, or on newer Proxmox VE versions, Options
2. Double-click the Machine row
3. Choose q35 from the dropdown (or switch back to i440fx if you're reverting)
4. Click OK, then start the VM

4. Change the machine type — command line method

If you'd rather do it from the shell, this one command does the same thing:

qm set 105 --machine q35

Replace 105 with your actual VMID. To pin a specific machine version instead of always tracking the latest one, specify it directly:

qm set 105 --machine q35-9.2

5. Add an EFI disk if you're also switching to UEFI

Machine type and BIOS type (SeaBIOS vs OVMF/UEFI) are separate settings, but they're often changed together, especially for Windows guests. If your VM doesn't already have one and you're moving to UEFI, add an EFI disk under Hardware → Add → EFI Disk, pick a storage location, and leave Pre-Enroll keys checked if you want Secure Boot support later.

6. Boot the VM and check the console

Open the VM's console (noVNC works fine for this) and watch it boot. Linux guests running a reasonably recent kernel usually come up without any drama. Windows guests are the ones to watch closely — jump to the Common Errors section below if you see a blue screen instead of a login prompt.

7. Confirm the change stuck

Run qm config 105 again once the VM is back up. You should see a line like:

machine: q35

or, if you pinned a version:

machine: pc-q35-9.2+pve0

Commands Explained

A short rundown of every command used above, in case you're copying these into your own terminal without the full context:

• qm config <vmid> — prints the full configuration of a VM, including CPU type, disks, network devices, and machine type. Good for a quick sanity check before and after any change.
• qm set <vmid> --machine q35 — changes the machine type for the given VMID to q35, tracking whatever the latest q35 version is on your Proxmox VE install.
• qm set <vmid> --machine q35-9.2 — same idea, but pins the exact machine version instead of letting it move forward automatically on future Proxmox VE upgrades. This matters most for Windows guests.
• qm showcmd <vmid> --pretty — not required for this task, but genuinely useful if you're curious what QEMU command line Proxmox actually builds behind the scenes, machine type included.

Common Errors

"No bootable device" right after switching to q35

This almost always means the boot order got reset, or the disk controller Proxmox exposes changed in a way the guest doesn't expect yet. Check Options → Boot Order and confirm your disk is still ticked and listed first.

Windows shows a blue screen with STOP code 0x0000007B (INACCESSIBLE_BOOT_DEVICE)

This is the classic one. It happens when Windows was installed with one storage controller driver loaded (say, an emulated IDE or SATA controller under i440fx) and suddenly can't find that controller after the chipset change rearranges the virtual hardware. It's not really a q35-specific bug — it's a general "Windows is picky about storage controller changes" problem, and switching chipset can trigger it the same way switching disk bus type does.

Linux VM boots into an initramfs rescue shell

Less common than the Windows issue, but it happens on older or minimal Linux installs where the initramfs wasn't built with drivers for the new virtual disk controller. Debian and Ubuntu installs from the last several years are usually fine; very minimal or very old images can trip on this.

GPU passthrough still fails after switching to q35

Switching chipset is necessary for PCIe passthrough, but it's not sufficient by itself. You also need IOMMU enabled in your BIOS and on the Proxmox VE kernel command line, plus the GPU correctly isolated to its own IOMMU group. Chipset is one piece of a larger checklist, not the whole fix.

Troubleshooting

If a VM won't boot after the change, don't panic and don't start reinstalling anything yet.

First, just switch the machine type back to what it was before (i440fx, typically) and boot again. If that brings it right back up, you've confirmed the chipset change was the trigger, and you now know exactly what you're dealing with before deciding whether it's worth fixing forward or just leaving it on the old setting.

If you do want to push forward with q35 rather than reverting, for a Windows guest hit with the 0x7B blue screen, boot into Windows Recovery from the installation ISO, open a command prompt, and check that the msahci and storahci services are set to start at boot:

reg load HKLM\OFFLINE C:\Windows\System32\config\SYSTEM
reg add "HKLM\OFFLINE\ControlSet001\Services\storahci" /v Start /t REG_DWORD /d 0 /f
reg unload HKLM\OFFLINE

This forces the AHCI driver to load early during boot, which usually resolves the inaccessible boot device error on the next restart.

For a Linux VM stuck in initramfs, the more reliable fix is usually just reverting the chipset and instead addressing whatever you actually needed q35 for through a different route — or booting a rescue ISO and rebuilding the initramfs with update-initramfs -u after chrooting into the installed system.

And if you were only trying to add passthrough hardware, double-check that the PCIe device actually shows up under Hardware → Add → PCI Device before assuming the chipset switch itself failed — sometimes the chipset change worked fine and the actual issue is IOMMU not being enabled yet.

Best Practices

• Pick q35 when you first create a VM if there's any chance you'll add passthrough hardware later. Retrofitting an existing installation is more annoying than starting on the right chipset from day one.
• Leave i440fx alone for VMs that are working fine and will never need PCIe passthrough. There's no performance reward for switching, only risk.
• Always back up or snapshot before changing chipset on a VM with real data on it. This takes two minutes and turns a possible disaster into a non-event.
• For Windows guests, pin the machine version explicitly (like q35-9.2) rather than leaving it on "Latest." Windows really doesn't like its virtual hardware shifting under it between reboots after a Proxmox VE upgrade.
• For Linux guests, "Latest" is generally fine — most modern kernels handle machine version bumps without complaint.
• Test the switch on a clone of the VM first if it's something you can't afford downtime on. Cloning takes a few minutes and lets you validate the whole process risk-free.

Frequently Asked Questions

Does q35 use more CPU or RAM than i440fx?

No. The difference is which virtual hardware the guest sees, not how much host resource the VM consumes. Performance is effectively identical for the vast majority of workloads.

Is i440fx being removed from Proxmox VE?

Not currently. It stays around mainly for backward compatibility with older guest operating systems and existing VMs that were built on it years ago.

Can I switch back to i440fx if q35 causes problems?

Yes, and it's the fastest fix if a VM won't boot after switching. Set it back with qm set <vmid> --machine i440fx and start the VM again.

Do I need q35 to add a virtual TPM for Windows 11?

Not strictly — the vTPM device itself works on either chipset. But since Windows 11 also benefits from PCIe and native AHCI, most guides pair vTPM with q35 anyway to sidestep other compatibility edge cases.

Why doesn't Proxmox VE just default to q35 for everyone?

Backward compatibility. Changing the default would mean older or more unusual guest operating systems that assume i440fx-style hardware would suddenly behave differently on fresh installs, so the project keeps i440fx as the safe default and leaves q35 as an opt-in choice.

Will changing machine type affect my VM's IP address or network settings?

No, as long as you're still using the same type of network device (VirtIO, for example). The network card model and machine type are independent settings.

Conclusion

Machine type is one of those Proxmox VE settings that stays invisible right up until the moment you need it — usually when a GPU passthrough guide isn't working, or a Windows 11 install refuses to cooperate. Now you know what i440fx and q35 actually represent, which one fits which situation, and how to move between them without losing a VM in the process.

For new VMs where there's any chance of future passthrough hardware, q35 is worth choosing from the start. For everything else already running fine on i440fx, there's no rush — leave it exactly as it is until you have an actual reason to change it.