Proxmox GPU Passthrough With a GeForce 8800 GTS

You can pass an NVIDIA GeForce 8800 GTS through to a Proxmox VM, but the trouble starts when you treat it like a modern RTX card. The 640 MB G80 version dates from 2006, well before UEFI GPU firmware was normal, so VM firmware and VGA option ROM handling matter far more than they do with newer hardware.

In a real homelab test with an ASUS 8800 GTS 640 MB, the physical GPU output worked as long as the Proxmox VM still had an emulated VGA display configured. Setting the VM display to none made the card's DVI output disappear. That's a useful clue: basic passthrough was at least partly working, and the harder problem was getting the legacy card to initialize as the VM's primary display. With old GPUs, you usually hit firmware problems long before performance matters.

Why is an 8800 GTS different from a modern passthrough GPU?

The GeForce 8800 GTS 640 MB is from NVIDIA's G80 generation (2006), so it predates the UEFI GOP firmware model that most modern GPU passthrough guides assume.

The original 8800 GTS used a G80 GPU, 640 MB of GDDR3 memory, and a 320-bit memory interface, and contemporary coverage put its launch in November 2006. The age matters more than the specs, because PC boot firmware changed a lot in the years after.

A modern graphics card often carries an EFI-capable video ROM, which lets UEFI firmware such as OVMF initialize the device before the guest OS loads. A card from the 8800 era normally has a legacy VGA option ROM instead.

That's why a passthrough config copied from a newer GPU can fail in confusing ways. IOMMU may be enabled, VFIO may claim the PCI device, and the Windows driver may even load, yet the monitor stays black during VM startup because the guest firmware never ran the kind of video ROM the card has.

Proxmox supports both SeaBIOS and OVMF for VMs. Its current administration guide generally steers users toward OVMF for PCIe passthrough, which makes sense for modern hardware. For a card this old, the SeaBIOS path is worth serious consideration.

If you're still building the host side, the Proxmox installation guide will help you get the base platform clean before you add GPU passthrough to the mix.

Should you use SeaBIOS for an 8800 GTS?

SeaBIOS is the first VM firmware I'd test for an 8800 GTS. It's a legacy BIOS implementation and can execute legacy VGA option ROMs.

OVMF can sometimes be made to work with an old card, but SeaBIOS matches the card's firmware assumptions better. OVMF provides UEFI firmware to the VM, and ArchWiki's passthrough documentation calls it the preferred modern method when the hardware supports it. Its troubleshooting guidance also notes that UEFI-compatible GPU firmware needs an EFI image in the video BIOS, and the 8800 GTS is years older than that convention. For a retro gaming VM, starting with SeaBIOS removes one big mismatch.

The basic experiment goes like this:

1. Create or clone the VM so you have a safe test copy.
2. Use SeaBIOS instead of OVMF.
3. Pass through the 8800 GTS.
4. Keep an emulated display for now so you can see what Windows is doing.
5. Install the appropriate NVIDIA guest driver.
6. Confirm that Windows detects the physical GPU.
7. Confirm that a monitor attached to the 8800 GTS gets output.
8. Only then try making the card the only display device.

Change one variable at a time, because old hardware brings enough uncertainty on its own.

What does it mean if VGA works but Display none does not?

If the physical 8800 GTS output works while an emulated VGA adapter is present but fails when Display is set to none, the guest OS is probably bringing up the NVIDIA card after boot, even though the VM firmware can't initialize it cleanly as the primary display. That's a much better position than a total passthrough failure.

With an emulated VGA device present, SeaBIOS or OVMF has a display it already knows how to initialize, and the guest boots on it. Later, Windows loads the NVIDIA driver and brings the passed-through card online. Remove the emulated display and the 8800 GTS has to handle more of the boot display itself. If the legacy option ROM isn't being executed correctly, the physical monitor may show nothing.

So troubleshooting should focus on a short list of things:

• VM firmware type
• whether the GPU's option ROM is visible to the guest
• whether the GPU is configured as the primary passed-through display
• whether the host has released the GPU to VFIO
• whether the Windows driver initializes the card
• whether the DVI-to-HDMI path is complicating detection

That leaves you with a far narrower problem than "GPU passthrough does not work."

Do you need a custom VBIOS ROM file?

Not always. A custom ROM file is worth testing when a legacy GPU won't initialize reliably inside the VM.

PCI devices normally expose an option ROM that firmware can execute, but with passthrough the VM sometimes can't obtain or use that ROM cleanly. QEMU lets you supply a ROM file explicitly, and Proxmox exposes ROM-related options for passed-through PCI devices. The community suggestion in this case was to get an 8800 GTS VGA BIOS and reference it manually.

That can help if you're careful about it. Match the ROM to your actual board, since the GPU family alone isn't enough: an ASUS 8800 GTS 640 MB can have different clocks, memory configuration, subsystem IDs, or board details from another vendor's card, and loading the wrong image adds a variable you don't need.

If you can, dump the ROM from your own card and keep an untouched copy. A known-good ROM database is handy for comparison, but don't let it turn into random firmware swapping.

Supplying a ROM file to the VM and flashing a ROM onto the physical GPU carry very different risks. A ROM file passed to QEMU is easy to undo. Flashing the card can leave it unusable if the image is wrong or the flash fails. For a retro passthrough experiment there's little reason to start by modifying the card permanently.

Do you need to pass every PCI function?

Pass only the functions the card actually exposes and the guest needs.

Modern GPUs often show up as several PCI functions, such as graphics plus HDMI or DisplayPort audio, which is why so many passthrough guides say to pass "all functions." The original 8800 GTS is older than today's HDMI audio conventions, so don't assume it has the same device layout as a modern GeForce card.

Check the host first. Running lspci -nn and lspci -nnk will show how the device appears and which driver currently owns it.

If the GPU has only one relevant PCI function, there's no second audio device to chase. If it exposes more than one related function, consider the IOMMU grouping and guest assignment together. This is one more reason to avoid copying a modern RTX passthrough checklist line by line.

Why does host driver binding still matter?

If the VM is supposed to own the 8800 GTS through VFIO, the Proxmox host must not be using it. The card's age doesn't change that part.

The card needs to be in a usable IOMMU group, and the host needs to bind it to vfio-pci instead of a graphics driver that wants to use it locally. Proxmox's PCI passthrough documentation covers the general IOMMU requirements and how host devices get assigned.

Before blaming SeaBIOS or the guest driver, check the basics:

• IOMMU is enabled in motherboard firmware.
• IOMMU is enabled for the Proxmox kernel.
• The GPU appears in the expected IOMMU group.
• The host is not using it as its active console GPU.
• vfio-pci owns the device before the VM starts.

If any of these are wrong, no amount of firmware experimenting will fix the setup.

For the wider host-side picture, see the Mr.PlanB Proxmox hub. PCI passthrough problems often span firmware, kernel, VM configuration, and guest drivers.

Could the DVI-to-HDMI adapter be the problem?

It could contribute, but if the same adapter already produces output under another VM display configuration, it probably doesn't explain the whole behavior.

Cards from the ASUS 8800 GTS generation usually had DVI outputs, not native HDMI. A passive DVI-to-HDMI adapter is normally simple, but old cards, old drivers, EDID handling, and display timing can all produce edge cases. Still, if the GPU works with Proxmox VGA enabled but not with Display: none, firmware initialization is the stronger clue.

Keep the physical display path simple anyway. Try a native DVI monitor or a different adapter if you have one, and test one output at a time. Leave the AV receiver, KVM switch, capture device, or long HDMI chain out of it until the passthrough config is proven, since retro hardware has enough quirks already.

What about old NVIDIA virtualization blocks?

Older NVIDIA consumer drivers can add another variable, especially when the guest driver notices it's running inside a VM.

Passthrough users have a long history of NVIDIA drivers refusing to run and throwing Code 43 on consumer GeForce cards. Modern NVIDIA drivers are less hostile to ordinary passthrough than older ones were, but an 8800 GTS also needs a driver branch old enough to support it, which is an awkward combination.

If Windows sees the card in Device Manager but the driver reports an error, don't jump to the conclusion that the option ROM is still at fault. Find out which NVIDIA driver version supports both your guest OS and the G80 card, and look at the Device Manager status separately from the VM boot display behavior. Firmware and the Windows driver fail at different stages, and troubleshooting goes much faster when you keep them apart.

Is passing through an 8800 GTS actually worth doing?

For performance, no, but for learning and nostalgia it absolutely is.

A modern integrated GPU can outperform hardware from this era while using less power and putting out less heat. If all you want is to play old Windows games, a dedicated retro PC may be easier.

As a homelab experiment, though, getting a 2006 GPU working in a current Proxmox host makes you understand how legacy BIOS, UEFI, VGA option ROMs, VFIO, guest display devices, driver support, and physical monitor initialization fit together. You learn more from that than from passing through a recent GPU that follows every modern assumption.

Do it in order: prove VFIO first, keep an emulated VGA device while debugging, try SeaBIOS for the legacy card, verify the guest driver, test physical output, and then remove the virtual display. Add a custom ROM only if the evidence points there. The config doesn't need to be elegant, but by the end you should know exactly why a twenty-year-old GPU lights up when the VM starts.