Disk attachment and I/O backends control how QEMU presents block devices to the guest. -hda is the legacy way; modern QEMU uses -drive for more control.
# Legacy (still works) qemu-system-x86_64 -hda disk.qcow2 -hdb cdrom.iso # Modern (preferred) qemu-system-x86_64 -drive file=disk.qcow2,format=qcow2,if=none,id=root \ -device virtio-blk-pci,drive=root # Even simpler (auto format detection) qemu-system-x86_64 -drive file=disk.qcow2
-hda assumes IDE protocol and ATA controller. Modern VMs often use VirtIO (virtio-blk) for better performance—the guest driver is paravirtual (aware of QEMU), not emulating real hardware.
I/O backend controls how QEMU handles disk operations:
# Asynchronous I/O (default on Linux, faster) -drive file=disk.qcow2,aio=threads # No cache (safest for multi-VM, explicit fsync) -drive file=disk.qcow2,cache=none # Write-back cache (faster, risks data loss on crash) -drive file=disk.qcow2,cache=writeback # Write-through (safe default) -drive file=disk.qcow2,cache=writethrough
cache=none issues explicit fsync() on every write—safe but slow. cache=writeback caches writes in QEMU—fast but risks data loss if QEMU crashes. cache=writethrough is a reasonable middle ground.
For production VMs, use cache=none. For testing and development, cache=writeback is fine.
CD-ROM (read-only disk):
qemu-system-x86_64 -drive file=cdrom.iso,media=cdrom
The guest sees a read-only CD device. Boot from it with -boot d (boot from CD).
Network block device (NBD):
qemu-system-x86_64 -drive file=nbd:localhost:10809
Useful for testing network storage, but slower than local disk.
virtio offers better performance than IDE/SATA emulation, especially for high I/O workloads. On embedded systems or headless servers, prefer -drive with virtio-blk-pci over legacy -hda.