If you've ever installed a Windows VM in Proxmox VE and hit a screen that says "We couldn't find any drives" during setup, you've already met the reason VirtIO drivers exist. Windows doesn't know how to talk to Proxmox's virtual hardware out of the box, and that one missing piece trips up more new users than almost anything else on this platform.
This guide walks through what VirtIO actually is, why it matters for a Windows guest specifically, and exactly how to get the drivers installed — both during a fresh install and on a VM you already built with the wrong disk settings.
What You Will Learn
By the end of this article you'll know how to download the official VirtIO driver ISO, attach it to a Windows VM, load the storage driver at the right moment during setup, and install the rest of the driver set afterward with the guest tools installer. You'll also see the two most common ways this goes wrong — a Windows installer that sees no disks at all, and a working VM that blue-screens after you change its disk bus — and how to fix both.
What Is VirtIO?
VirtIO is a standard for paravirtualized devices. That's a mouthful, so here's the short version: instead of Proxmox pretending to be a real, physical disk controller or network card and your VM's OS talking to that fake hardware the slow way, VirtIO gives the guest OS a driver that knows it's running in a VM and can talk to the hypervisor directly.
Linux already ships with VirtIO drivers built into the kernel, so an Ubuntu or Debian VM just works with VirtIO disks and network cards with zero extra steps. Windows has no idea what VirtIO is unless you teach it, which is what this whole guide is about.
The drivers themselves come from the Fedora Project's virtio-win package, built and tested against QEMU (the emulator Proxmox is built on top of). Proxmox doesn't bundle these drivers with the hypervisor — you download an ISO separately and hand it to the Windows installer like a second disc.
Why Would You Use It?
Two reasons, really: speed and correctness of information.
An emulated disk controller like IDE or SATA has to fake being real hardware, which means every read and write goes through extra translation. VirtIO SCSI skips most of that. On a decent NVMe-backed Proxmox host, it's common to see disk throughput roughly double or triple compared to IDE, and CPU usage on the host drops too, since the host isn't spending cycles emulating a chipset nobody actually has.
The network side is similar. The default emulated NIC in Proxmox is an Intel E1000, which caps out well below gigabit speeds in practice even on fast hardware. Switch to a VirtIO network adapter and you'll typically see multi-gigabit throughput between VMs on the same host, limited more by CPU than by the fake wire.
Then there's the guest agent, which rides along with the VirtIO driver package. Without it, Proxmox has no idea what IP address your Windows VM has, can't do a clean shutdown from the GUI (it just sends a hard power-off signal), and can't freeze the filesystem for a consistent snapshot. Install the guest agent and all of that starts working from the Proxmox web interface.
Prerequisites
Before you start, make sure you have:
- A Proxmox VE host running version 8.x or 9.x, with a Windows ISO already uploaded to local storage.
- Enough free space for a second ISO — the virtio-win ISO is roughly 500 MB depending on the release.
- A working internet connection on whatever machine you're downloading the ISO on (it doesn't need to be the Proxmox host itself, though downloading directly on the host is often simpler).
- Ten to fifteen minutes, most of which is Windows Setup copying files.
You do not need any prior Windows driver experience. You're mostly clicking through a wizard at one extra screen it doesn't usually show you.
Step-by-Step Tutorial
Step 1: Download the VirtIO driver ISO
Go to the official Fedora-hosted VirtIO Windows drivers page and grab the latest stable ISO, named something like virtio-win-0.1.271.iso (version numbers change over time). There's also a "latest" symlink if you don't care about pinning a specific version. Stick to the stable build rather than the "latest-virtio" development builds unless you have a specific reason to test bleeding-edge drivers.
Step 2: Upload the ISO to Proxmox storage
In the Proxmox web interface, click your storage (usually local) in the left sidebar, open the ISO Images tab, and click Upload. Pick the virtio-win ISO you just downloaded. On a typical home connection this takes a minute or two.
Step 3: Create the VM with VirtIO hardware selected
Click Create VM and work through the wizard with these settings:
- On the OS tab, select your Windows ISO and set the guest OS type to the matching Windows version.
- On the System tab, for Windows 11 use machine type q35 and BIOS OVMF (UEFI) — Windows 11 requires UEFI and TPM, and Proxmox can add a virtual TPM here too. For Windows 10 either machine type works, but q35 is the more modern default.
- On the Disks tab, set Bus/Device to VirtIO SCSI single, and make sure the SCSI Controller on the System tab is set to VirtIO SCSI single as well.
- On the Network tab, set the Model to VirtIO (paravirtualized).
Don't click Finish yet — you still need to attach the driver ISO.
Step 4: Add the VirtIO ISO as a second CD drive
On the Confirm screen (or afterward through the VM's Hardware tab), add a new CD/DVD Drive and point it at the virtio-win ISO you uploaded. You'll end up with two optical drives attached: one with the Windows installer, one with the drivers.
Step 5: Boot the VM and load the storage driver
Start the VM and boot into Windows Setup as normal. When you reach the "Where do you want to install Windows?" screen, it will show no drives at all — that's expected, and it's exactly the moment VirtIO matters.
Click Load driver, then Browse, and navigate to the second CD drive. Go into the vioscsi folder, then the folder matching your Windows version (for example w11 or w10), then amd64. Select it, click Next, and Windows will load the SCSI driver. Your virtual disk should now appear in the list.
Continue the install normally from here — partition the disk, and let Windows copy files and reboot a couple of times.
Step 6: Install the remaining drivers after Windows boots
Once you're at the Windows desktop, open the second CD drive in File Explorer and run virtio-win-guest-tools.exe. This installs the network driver, the balloon driver (used for dynamic memory), the QXL or VirtIO GPU display driver, and the QEMU guest agent, all in one pass. Reboot when it asks.
Back in Proxmox, edit the VM's Options tab and make sure QEMU Guest Agent is set to enabled — the guest tools installer only puts the service on the Windows side, Proxmox still needs to know to expect it.
Commands Explained
This particular workflow is mostly GUI-driven, but a couple of command-line pieces are worth knowing if you manage VMs from the shell or want to check things after the fact.
| Command | What it does |
|---|---|
qm config <vmid> | Prints the VM's configuration, including the disk bus and network model, so you can confirm scsi0 is actually using virtio-scsi-single and net0 is using virtio. |
qm agent <vmid> ping | Checks whether the QEMU guest agent inside the VM is responding. If this hangs or errors, the agent service isn't running or isn't installed yet. |
qm set <vmid> --agent enabled=1 | Enables the guest agent option on the VM configuration from the shell, equivalent to flipping the toggle in the Options tab. |
None of these are required if you're comfortable in the web GUI — they're just handy for confirming a setting stuck, especially over SSH when you're managing a headless server.
Common Errors
The two errors below cover the vast majority of VirtIO problems people run into.
"We couldn't find any drives. To get a storage driver, click Load Driver." This isn't actually an error — it's Windows Setup correctly telling you it has no idea how to see a VirtIO SCSI disk. It means you either forgot to attach the virtio-win ISO as a second CD drive, or you haven't clicked Load Driver and browsed to the vioscsi folder yet. Go back to Step 5 above.
INACCESSIBLE_BOOT_DEVICE (0x0000007B) after changing an existing VM's disk bus to VirtIO. This happens when you take a VM that was installed with an IDE or SATA disk and switch it to VirtIO SCSI afterward. Windows never loaded the VirtIO driver during install, so when it boots and the disk controller has changed underneath it, it can't find the boot device and blue-screens immediately. The fix is to install the VirtIO driver while the disk is still on its original bus (attach the ISO, install the driver through Device Manager), then shut down and switch the bus setting in Proxmox. Switching the bus first and installing the driver second is the wrong order and it will not boot.
Troubleshooting
If qm agent ping times out even after installing guest tools, check the Windows Services panel for "QEMU Guest Agent" and make sure it's set to Automatic and running — occasionally the installer finishes but the service doesn't start on first boot, and a manual start clears it up.
If the network adapter shows up in Device Manager as an unknown device with a yellow warning icon after install, the guest tools installer sometimes misses it on older Windows builds. Right-click it, choose Update driver, browse to the ISO's NetKVM folder, and pick the folder matching your Windows version manually.
If the VM feels sluggish even with VirtIO configured, double check the SCSI Controller type on the System tab actually says VirtIO SCSI single and not the default LSI 53C895A — it's easy to create the VM before changing that setting and end up with a VirtIO disk sitting behind a controller that isn't VirtIO at all.
Best Practices
Keep the virtio-win ISO attached to the VM even after installation finishes, rather than removing it right away. When a new Windows feature update rolls around, you may need to reinstall or update a driver, and it's convenient to have the ISO already sitting there in the drive.
Update the driver ISO every few months if you're building new VMs regularly. Fedora ships new virtio-win releases periodically with bug fixes, and running a two-year-old driver version on a brand-new Windows build is a common source of odd, hard-to-diagnose glitches.
For anything performance-sensitive, use VirtIO SCSI single (not plain VirtIO SCSI) and enable the IO thread checkbox on the disk. It gives each virtual disk its own thread on the host side instead of sharing one, which matters once you're running more than a couple of VMs on the same node.
Frequently Asked Questions
Do I need VirtIO drivers for Linux VMs too?
No. Modern Linux distributions build VirtIO support directly into the kernel, so Ubuntu, Debian, and similar guests work with VirtIO disks and network cards without any extra driver installation.
Will my VM still work if I skip VirtIO and just use IDE and the default network card?
Yes, it'll boot and run fine — it'll just be noticeably slower on disk and network, and Proxmox won't get guest agent features like IP reporting or clean shutdowns.
Can I add VirtIO drivers to a Windows VM that's already installed on IDE?
Yes, but install the driver first while the disk is still on IDE, then switch the bus to VirtIO in the VM's hardware settings afterward. Switching the bus before the driver is installed causes the boot failure described above.
Where do I get the virtio-win ISO from?
From the official Fedora-hosted VirtIO Windows drivers project. Avoid downloading it from random third-party mirrors — it's a driver that runs at a low level inside your VM, so the source matters.
Conclusion
VirtIO looks intimidating the first time Windows Setup shows you an empty drive list, but the fix is really just one extra click during installation. Once it's in place, your Windows VM gets a faster disk, a faster network card, and a guest agent that lets Proxmox actually see what's going on inside it. It's one of those five-minute steps that pays for itself on every VM you build afterward.