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.