You just clicked "Create VM," and now Proxmox is asking you to pick a "Bus/Device" for your hard disk: IDE, SATA, SCSI, or VirtIO Block. There's no explanation on the screen, and the dropdown next to it — SCSI Controller — has six cryptic options like LSI 53C895A and VirtIO SCSI single. Most tutorials skip right past this screen. That's a mistake, because this one setting affects how fast your VM's disk actually performs, and getting it wrong is one of the most common reasons a fresh Windows VM won't boot after someone "optimizes" it later.
This guide walks through what each bus type actually is, which one you should pick for a new VM, and how to safely change it on a VM that's already running — without ending up staring at a blue screen.
What You Will Learn
- What a disk "bus" is and why Proxmox makes you choose one
- The real differences between IDE, SATA, SCSI, and VirtIO Block
- Why VirtIO SCSI single is the default for a reason
- How to set the bus type when creating a new VM
- How to safely switch an existing VM to VirtIO SCSI without breaking the boot
- What "IOThread" does and when to leave it on
- Common errors people hit when changing this setting, and how to fix them
What Is This Feature?
Every virtual disk you attach to a VM has to be presented to the guest operating system as some kind of hardware. On a real computer, a hard drive talks to the motherboard over a specific interface — SATA on most desktops, NVMe on newer machines, SCSI on older servers. A VM doesn't have real hardware, so Proxmox has to emulate one of these interfaces (or a paravirtualized one) so the guest OS sees something it knows how to talk to.
That's what the "Bus/Device" dropdown is: it decides which virtual disk controller QEMU (the hypervisor engine underneath Proxmox) presents to your VM. You have four choices:
| Bus Type | What It Emulates | Max Disks | Needs Drivers? |
|---|---|---|---|
| IDE | An old-school PATA hard drive controller | 4 (0-3) | No — every OS has this built in |
| SATA | A standard modern desktop hard drive interface | 6 (0-5) | No — every OS has this built in |
| SCSI | A server-grade disk controller (several sub-types) | 31 (0-30) | Sometimes, depending on controller |
| VirtIO Block | A paravirtualized, Linux-native fast disk | 16 (0-15) | Yes on Windows, no on modern Linux |
"Paravirtualized" is the important word in that table. IDE and SATA are full emulation — Proxmox pretends, in painstaking detail, to be a real IDE or SATA controller, and the guest OS talks to it exactly like it would talk to physical hardware. That's compatible with everything, but it's slow, because both sides are doing extra work translating instructions that don't need to exist in a virtual environment. VirtIO skips that translation. The guest OS talks almost directly to QEMU using a protocol built specifically for virtualization, which means far less CPU overhead and noticeably better throughput.
Why Would You Use It?
Picking the right bus type is a five-second decision that has a real, measurable effect on disk performance — and it's one of those settings that's much easier to get right at VM creation than to fix later.
Here's the short version: use VirtIO SCSI for almost every VM you create. Use SATA only when you're stuck with an OS or installer that can't see VirtIO drives. Use IDE basically never, except for very old legacy guests or the occasional installer ISO. Plain SCSI (the LSI-emulated kind) sits in the middle — better than SATA, still slower than VirtIO.
Real numbers, not vague ones: on a typical NVMe-backed ZFS pool, it's common to see 30-60% better sequential write throughput and noticeably lower CPU usage on the Proxmox host itself when a VM uses VirtIO SCSI instead of SATA. The gap is smaller on spinning disks, but it's still there, and the CPU savings matter more the more VMs you're running on one node.
There's a second reason this matters: some features only work on certain bus types. Discard (TRIM, for reclaiming space on thin-provisioned storage) and IOThread (running disk I/O in its own thread instead of sharing the main VM thread) are both available on SCSI and VirtIO, but not on IDE. If you're running a VM on ZFS or Ceph and you want TRIM to actually free up space when you delete files inside the guest, you need to be on SCSI or VirtIO from the start.
Prerequisites
- A working Proxmox VE installation (this guide was written against 8.x and 9.x, but the concepts go back years)
- At least one VM already created, or ready to create — either works, we'll cover both
- Root or a user with VM.Config.Disk permission on the VM you're changing
- A few minutes of downtime if you're changing the bus type on an existing VM, since it needs a reboot
- For Windows VMs specifically: the VirtIO driver ISO downloaded from the Proxmox wiki (more on this below)
Step-by-Step Tutorial
Setting the bus type on a brand-new VM
If you're creating a VM from scratch, this is the easy path — you never have to touch an already-installed OS.
- Click Create VM in the top-right of the Proxmox web interface.
- Walk through the General and OS tabs as usual, selecting your ISO.
- On the Disks tab, look at the Bus/Device dropdown. Since Proxmox VE 7.3, this defaults to SCSI, and the SCSI Controller field (visible up on the System tab) defaults to VirtIO SCSI single. For a modern Linux guest, just leave both alone.
- For a Windows guest, you still want SCSI here, but Windows doesn't ship with VirtIO drivers, so tick Add another CD-ROM device further down and point it at the VirtIO driver ISO — you'll need it during install.
- Also on the Disks tab, tick Discard if your storage backend is thin-provisioned (ZFS, LVM-thin, most cloud/SAN backends) — this lets the guest tell Proxmox when space can be reclaimed.
- Leave IO thread checked. It's on by default for VirtIO SCSI single and there's rarely a reason to turn it off.
- Finish the wizard and install the OS normally. Linux distributions will see the VirtIO disk immediately during install. Windows needs a driver load — more on that in a moment.
Installing Windows on a VirtIO SCSI disk
This trips people up the first time, so here's the exact sequence:
- Boot the VM with both the Windows ISO and the VirtIO driver ISO attached.
- When the Windows installer asks where to install, the disk list will be empty — Windows doesn't know how to see a VirtIO disk yet.
- Click Load driver, browse to the VirtIO CD (usually
D:orE:), and go intovioscsi\w11\amd64(adjust the folder for your Windows version — there are separate folders per release). - Once the driver loads, your virtual disk appears in the list. Select it and continue the install as normal.
Switching an existing VM from SATA/IDE to VirtIO SCSI
This is the part where people get an "INACCESSIBLE_BOOT_DEVICE" blue screen if they rush it — mostly on Windows. Linux guests are much more forgiving because the VirtIO driver is usually already built into the kernel.
For Linux guests
- Shut the VM down completely (not just a reboot).
- Go to Hardware, select the boot disk, click Edit, wait — actually you can't change the bus type of an existing disk directly. Instead, note the disk's storage and size.
- Go to Options → SCSI Controller and set it to VirtIO SCSI single if it isn't already.
- Detach the disk, then re-add it as SCSI using qm set from the shell (covered below), pointing at the same underlying volume.
- Boot the VM. Modern Linux kernels have the virtio_scsi module built in or as an initramfs module, so it should come up without extra steps. If it doesn't, you may need to regenerate the initramfs from a rescue environment first.
For Windows guests
Windows won't boot on a new controller type it doesn't have a driver for. The safe sequence is:
- Shut the VM down.
- Attach the VirtIO driver ISO as a CD-ROM if it isn't already attached.
- Add a small temporary disk (1 GB is plenty) as a SCSI disk on the VirtIO SCSI single controller. This is the trick: Windows needs to discover a SCSI device and install the driver for it before its boot disk becomes one.
- Boot the VM. Windows will detect new hardware and prompt for a driver, or you can install it manually from Device Manager, pointing at the VirtIO CD's
vioscsifolder. - Once the driver installs and Windows recognizes the temporary disk, shut down again.
- Now change your actual boot disk's bus type using
qm set(see below) from IDE or SATA to SCSI. - Boot the VM. It should come up cleanly since the driver is already installed.
- Remove the temporary disk once you've confirmed everything works.
- Check Options → Boot Order and make sure your (now-SCSI) disk is still ticked as bootable — this gets missed constantly.
Commands Explained
Most of this can be done from the GUI, but a couple of shell commands are worth knowing, especially if you're scripting VM changes or working over SSH.
qm config 101Shows the full configuration of VM 101, including every disk's current bus assignment (look for lines starting with ide0, sata0, scsi0, or virtio0). Always run this before changing anything, so you know exactly what you're working with.
qm set 101 -scsi0 local-zfs:vm-101-disk-0,discard=on,iothread=1Attaches the existing volume vm-101-disk-0 on storage local-zfs as SCSI disk 0, with TRIM/discard and IOThread both enabled. Swap local-zfs and the disk name for whatever qm config showed you. The VM must be stopped for this kind of change.
qm set 101 -scsihw virtio-scsi-singleSets VM 101's SCSI controller model to VirtIO SCSI single. Other valid values are lsi (the old default), lsi53c810, megasas, pvscsi, and virtio-scsi-pci — but for a new setup, VirtIO SCSI single is the one you want.
qm unlink 101 --idlist ide0Detaches disk ide0 from VM 101 without deleting the underlying storage — useful when you're re-attaching the same volume under a different bus name.
Common Errors
| Error / Symptom | Cause |
|---|---|
INACCESSIBLE_BOOT_DEVICE blue screen | Windows boot disk switched to SCSI/VirtIO without the driver already installed |
| New disk doesn't appear during Windows install | VirtIO driver ISO not attached, or wrong driver folder selected for the Windows version |
| VM won't boot after changing scsihw on Linux | Older kernel or missing initramfs module for virtio_scsi |
| "discard" option grayed out or ignored | Storage backend doesn't support TRIM (e.g. plain LVM without thin provisioning), or bus type is IDE |
| Disk missing from boot order after bus change | Boot order list still references the old device name (e.g. ide0) instead of the new one |
Troubleshooting
If a Windows VM blue-screens right after you change its boot disk to SCSI, don't panic and don't delete anything. Change the bus type back to what it was before (SATA or IDE), boot the VM, install the VirtIO driver properly using the temporary-disk method above, then try the switch again. The data on the disk is untouched the whole time — only the presentation to the guest changed.
If a Linux VM won't boot after the switch and you see it hang at a black screen or drop to an emergency shell, boot it from a rescue ISO, mount the root filesystem, and run update-initramfs -u (Debian/Ubuntu) or dracut -f (RHEL/Fedora-based) with the virtio_scsi module explicitly included, then reboot normally.
If discard/TRIM doesn't seem to be reclaiming space, check two things: that the bus is SCSI or VirtIO (not IDE), and that the guest OS is actually issuing TRIM commands — on Linux that usually means an fstrim timer is enabled, and on Windows it means the optimization scheduled task for that drive is turned on.
If you can't find where a disk's device name changed after editing it in the GUI, run qm config <vmid> — it's the fastest way to see the ground truth of what's actually attached and how.
Best Practices
- Default to SCSI with the VirtIO SCSI single controller for new VMs. It's already the Proxmox default since 7.3 for a reason — don't second-guess it without cause.
- Keep IOThread enabled on VirtIO SCSI single disks. It lets disk I/O run outside the main VM thread, which helps most under heavy or mixed workloads.
- Enable Discard whenever your storage supports thin provisioning. Skipping this on ZFS or LVM-thin means your pool slowly fills up with data the guest thinks it already deleted.
- Always download the VirtIO driver ISO from the official Proxmox wiki, not a random mirror. It's built and signed specifically to match what QEMU on your Proxmox host expects.
- Test the boot after any bus change before you consider the job done. Don't assume it worked just because the change saved without an error.
- Only reach for plain SCSI (LSI-emulated) or SATA when you're dealing with an OS or appliance image that genuinely can't load VirtIO drivers. Most of the time that's an older or vendor-locked appliance, not a normal Linux or Windows install.
Frequently Asked Questions
Is VirtIO Block the same as VirtIO SCSI?
No. VirtIO Block is an older, simpler paravirtualized disk driver. VirtIO SCSI wraps disks in a SCSI layer instead, which unlocks features like IOThread and better handling of large numbers of disks. Proxmox's own documentation notes VirtIO Block may eventually be deprecated, so stick with VirtIO SCSI for anything new.
Do I need to install anything for a Linux VM to use VirtIO?
Usually no. Every mainstream distribution released in the last decade ships the virtio_scsi and virtio_blk kernel modules already, so a fresh install just sees the disk and uses it.
Can I change the bus type without reinstalling the OS?
Yes, but only with care — see the "Switching an existing VM" steps above. The underlying data is never touched, only how it's presented to the guest, but Windows in particular needs the right driver in place before you flip the switch.
Why does my SCSI controller say "lsi" instead of "VirtIO SCSI single"?
That means the VM was created before Proxmox VE 7.3, or was imported from an older config. You can change it under Options → SCSI Controller, but treat it like any other bus change — shut the VM down first and check drivers on Windows guests.
Does the bus type matter for CD-ROM drives?
Less so. Most people leave the CD-ROM on IDE since it's only used during install or for mounting an occasional ISO, and the performance difference is irrelevant for a drive that isn't doing sustained I/O.
Conclusion
The Bus/Device dropdown looks like an afterthought on the VM creation screen, but it decides how efficiently your disk actually performs and which storage features you get to use. For anything new, SCSI with the VirtIO SCSI single controller is the right call — it's fast, it supports Discard and IOThread, and it's been the Proxmox default since version 7.3. Save IDE and SATA for guests that genuinely can't handle anything else, and if you're moving an existing VM over to VirtIO, take the extra five minutes to get the driver installed first. That's the difference between a clean switch and an afternoon spent staring at a blue screen wondering what went wrong.