# QEMU Disk I/O

**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.

```bash
# 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:

```bash
# 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):

```bash
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):

```bash
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`.