Storage Guide
Complete guide to QuantaVirt virtual storage — disk image formats, storage controllers, PQC-encrypted disks, snapshots, shared storage, iSCSI/NFS backends, and I/O performance tuning.
Storage Overview #
QuantaVirt presents virtual disks to guest VMs through emulated or paravirtual storage controllers. Each virtual disk is backed by an image file on the host filesystem, a block device, or a network storage target. The hypervisor mediates all I/O between the guest and the backing storage, translating guest block requests into host filesystem operations.
| Controller | Type | Max Devices | Multi-Queue | Performance |
|---|---|---|---|---|
| VirtIO-blk | Paravirtual | 256 | ✅ Up to 64 queues | ~1M IOPS (4K random read) |
| NVMe | Emulated | 256 namespaces | ✅ Up to 64 queues | ~800K IOPS |
| AHCI (SATA) | Emulated | 32 | ⌠| ~200K IOPS |
| IDE | Emulated | 4 | ⌠| ~50K IOPS |
Disk Image Formats #
Raw Format
Raw images are plain binary files where each byte corresponds directly to a byte on the virtual disk. Raw format provides the highest I/O performance because there is no translation layer. The full disk size is allocated upfront.
# Create a raw disk image
quantavirt storage create \
--name db-data \
--format raw \
--size 100G
# Raw image uses full 100 GB on host immediately
ls -lh /var/lib/quantavirt/images/db-data.raw
# -rw-r--r-- 1 root root 100G Jan 15 10:00 db-data.raw
QCOW2 Format
QCOW2 (QEMU Copy-On-Write version 2) is the default and recommended format for most workloads. It supports thin provisioning (allocate-on-write), snapshots, compression, and PQC encryption. Disk space is consumed only as the guest writes data.
# Create a QCOW2 disk image (thin provisioned)
quantavirt storage create \
--name web-server \
--format qcow2 \
--size 50G
# QCOW2 starts small and grows as data is written
quantavirt storage info web-server
# Name: web-server
# Format: qcow2
# Virtual Size: 50 GiB
# Actual Size: 1.2 GiB
# Snapshots: 0
# Encrypted: no
PQC-Encrypted Format
Encrypted disk images use ML-KEM key wrapping with AES-256-GCM or ChaCha20-Poly1305 bulk encryption. The master encryption key is wrapped with an ML-KEM public key, allowing hardware-backed key unwrapping via the QUAC 100 at boot time.
# Create a PQC-encrypted disk
quantavirt storage create \
--name classified-data \
--format encrypted \
--size 100G \
--kem ML-KEM-768 \
--aead AES-256-GCM
# Encrypted disk info
quantavirt storage info classified-data
# Name: classified-data
# Format: encrypted (qcow2 + PQC)
# Virtual Size: 100 GiB
# Actual Size: 3.4 GiB
# Encrypted: ML-KEM-768 / AES-256-GCM
# Key Backend: QUAC 100 Hardware
| Feature | Raw | QCOW2 | Encrypted |
|---|---|---|---|
| Thin provisioning | ⌠| ✅ | ✅ |
| Snapshots | ⌠| ✅ | ✅ |
| Compression | ⌠| ✅ (zlib, zstd) | ⌠(incompatible) |
| PQC encryption | ⌠| ⌠| ✅ |
| I/O overhead | None | ~2–5% | ~5–10% (hardware), ~30% (software) |
| Live migration | ✅ | ✅ | ✅ (re-key at destination) |
Storage Controllers #
VirtIO-blk (Recommended)
VirtIO-blk is a paravirtual block device that communicates through shared-memory virtqueues, avoiding the overhead of emulating a full hardware controller. Multi-queue support (one queue per vCPU) enables parallel I/O for high-IOPS workloads.
# VM config — VirtIO-blk with multi-queue
"storage": [{
"type": "virtio-blk",
"path": "db-data",
"format": "raw",
"cache": "none",
"io": "native",
"queues": 8,
"discard": true
}]
NVMe
Emulated NVMe controller for guests that expect NVMe hardware (Windows Server, some database appliances). Supports namespaces, multi-queue, and admin/IO queue separation.
# VM config — NVMe controller
"storage": [{
"type": "nvme",
"path": "win-server",
"format": "qcow2",
"cache": "writeback",
"queues": 4
}]
AHCI (SATA) and IDE
AHCI emulates a SATA controller for broad guest compatibility. IDE emulates a legacy ATA controller for very old guest operating systems. Both are single-queue and significantly slower than VirtIO-blk or NVMe.
Disk Management #
# List all disk images
quantavirt storage list
# NAME FORMAT VIRTUAL ACTUAL ENCRYPTED VMs
# web-server qcow2 50 GiB 1.2 GiB no web-01
# db-data raw 100 GiB 100 GiB no db-01
# classified encrypted 100 GiB 3.4 GiB ML-KEM-768 secure-vm
# Resize a disk (grow only — shrink not supported)
quantavirt storage resize web-server --size 100G
# Convert between formats
quantavirt storage convert web-server --target-format raw --output web-server-raw
# Compact a QCOW2 image (reclaim sparse space)
quantavirt storage compact web-server
# Verify disk image integrity
quantavirt storage check web-server
# Delete a disk image (VM must be stopped and detached)
quantavirt storage delete old-backup
Hot-plug Disks
# Attach a disk to a running VM
quantavirt vm disk-attach web-01 \
--storage extra-data \
--controller virtio-blk
# Detach a disk from a running VM
quantavirt vm disk-detach web-01 --storage extra-data
PQC Storage Encryption #
QuantaVirt's PQC storage encryption protects disk images at rest against both classical and quantum attacks. The encryption architecture uses a two-layer key hierarchy: a data encryption key (DEK) that encrypts disk sectors, and a key encryption key (KEK) derived from ML-KEM encapsulation.
/* Encryption architecture */
ML-KEM Public Key ──► ML-KEM Encapsulate ──► Ciphertext (stored in QCOW2 header)
│
â–¼
Shared Secret (32 bytes)
│
â–¼
HKDF-SHA3-256 Key Derivation
│
â–¼
Data Encryption Key (DEK)
│
â–¼
AES-256-GCM encrypt each 4 KB sector with unique IV
/* Decryption (VM boot) */
QUAC 100 loads ML-KEM Private Key from secure key store
QUAC 100 decapsulates ciphertext → shared secret
HKDF derives DEK → hypervisor decrypts sectors on read
Key Management
# Generate a new ML-KEM keypair for storage encryption
quantavirt pqc key-gen \
--algorithm ML-KEM-768 \
--name storage-key-2026 \
--store quac100
# List encryption keys
quantavirt pqc key-list
# NAME ALGORITHM STORE CREATED
# storage-key-2026 ML-KEM-768 QUAC 100 2026-01-15T10:00:00Z
# Re-key a disk (rotate encryption key)
quantavirt storage rekey classified-data --key storage-key-2026
# Export wrapped key for backup (PQC-encrypted key blob)
quantavirt pqc key-export storage-key-2026 --output key-backup.pqc
Snapshots #
QCOW2 and encrypted disk images support internal snapshots — point-in-time captures of the disk state. Snapshots are copy-on-write: only modified sectors after the snapshot consume additional space.
# Create a snapshot (VM can be running or stopped)
quantavirt vm snapshot create web-01 --name before-upgrade
# Full snapshot (disk + memory state — requires running VM)
quantavirt vm snapshot create web-01 --name checkpoint-1 --memory
# List snapshots
quantavirt vm snapshot list web-01
# NAME DATE SIZE MEMORY DESCRIPTION
# before-upgrade 2026-01-15T10:00:00Z 2.1 GiB no —
# checkpoint-1 2026-01-15T14:30:00Z 4.8 GiB yes —
# Restore a snapshot (VM must be stopped unless snapshot includes memory)
quantavirt vm snapshot restore web-01 --name before-upgrade
# Delete a snapshot (reclaims space)
quantavirt vm snapshot delete web-01 --name checkpoint-1
Shared Storage #
QuantaVirt supports shared storage backends for clusters, live migration, and multi-host deployments. Shared storage requires a distributed filesystem or network block device accessible from all hypervisor hosts.
| Backend | Protocol | Live Migration | Shared Access | Use Case |
|---|---|---|---|---|
| Local files | POSIX filesystem | Requires copy | ⌠| Single-host, development |
| NFS | NFSv4.1+ | ✅ Zero-copy | ✅ | General shared storage |
| iSCSI | iSCSI (TCP) | ✅ Zero-copy | âš ï¸ With SCSI reservations | Block storage, SAN |
| Ceph RBD | RADOS | ✅ Zero-copy | ✅ | Scale-out distributed storage |
| GlusterFS | GlusterFS native | ✅ Zero-copy | ✅ | Distributed file storage |
iSCSI & NFS #
# Add an NFS storage pool
quantavirt storage pool-add \
--name nfs-images \
--type nfs \
--server 192.168.1.100 \
--path /exports/quantavirt
# Add an iSCSI target
quantavirt storage pool-add \
--name san-lun \
--type iscsi \
--portal 192.168.1.200:3260 \
--target iqn.2026-01.com.example:storage.lun1
# Create a disk on the NFS pool
quantavirt storage create \
--name shared-vm \
--format qcow2 \
--size 50G \
--pool nfs-images
# List storage pools
quantavirt storage pool-list
Performance Tuning #
| Parameter | Setting | Impact |
|---|---|---|
| Controller type | VirtIO-blk | Paravirtual — lowest overhead, highest IOPS |
| Disk format | raw | Eliminates QCOW2 metadata lookup; +5–10% IOPS |
| Cache mode | none | Guest manages its own cache; safe for databases, best for O_DIRECT |
| Cache mode | writeback | Host caches writes; faster for bursty workloads, risk of data loss on crash |
| Cache mode | writethrough | Host writes through to disk; safe, slower than writeback |
| I/O backend | native (Linux AIO) | Kernel-level async I/O; best for raw + cache=none |
| I/O backend | io_uring | Latest Linux async I/O; best throughput on 5.1+ kernels |
| Multi-queue | queues: N | Parallel I/O across vCPUs; essential for NVMe-backed storage |
| Discard/TRIM | discard: true | Reclaims unused guest space in QCOW2; prevents image bloat |
| Preallocation | prealloc: true | Allocates full image at creation; avoids fragmentation |
Storage Troubleshooting #
| Symptom | Likely Cause | Resolution |
|---|---|---|
| VM fails to start: "disk locked" | Another VM or process holds the image lock | Check quantavirt storage info <name> for lock owner |
| Slow I/O performance | Wrong cache mode, QCOW2 fragmentation | Use cache: "none" + io: "native", compact image |
| QCOW2 image keeps growing | Guest deletes not propagated | Enable discard: true, run fstrim in guest |
| Encrypted disk won't unlock | QUAC 100 not detected, wrong key | Check quantavirt pqc status, verify key name |
| Snapshot restore fails | Corrupted snapshot metadata | Run quantavirt storage check <name> to repair |
| NFS mount timeout | Firewall, NFS server unreachable | Check NFS port (2049), verify exports, test mount manually |