Storage Guide

QV-STG-001 Rev 1.0 — January 2026

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.

ControllerTypeMax DevicesMulti-QueuePerformance
VirtIO-blkParavirtual256✅ Up to 64 queues~1M IOPS (4K random read)
NVMeEmulated256 namespaces✅ Up to 64 queues~800K IOPS
AHCI (SATA)Emulated32❌~200K IOPS
IDEEmulated4❌~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
FeatureRawQCOW2Encrypted
Thin provisioning❌✅✅
Snapshots❌✅✅
Compression❌✅ (zlib, zstd)❌ (incompatible)
PQC encryption❌❌✅
I/O overheadNone~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.

BackendProtocolLive MigrationShared AccessUse Case
Local filesPOSIX filesystemRequires copy❌Single-host, development
NFSNFSv4.1+✅ Zero-copy✅General shared storage
iSCSIiSCSI (TCP)✅ Zero-copy⚠️ With SCSI reservationsBlock storage, SAN
Ceph RBDRADOS✅ Zero-copy✅Scale-out distributed storage
GlusterFSGlusterFS 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 #

ParameterSettingImpact
Controller typeVirtIO-blkParavirtual — lowest overhead, highest IOPS
Disk formatrawEliminates QCOW2 metadata lookup; +5–10% IOPS
Cache modenoneGuest manages its own cache; safe for databases, best for O_DIRECT
Cache modewritebackHost caches writes; faster for bursty workloads, risk of data loss on crash
Cache modewritethroughHost writes through to disk; safe, slower than writeback
I/O backendnative (Linux AIO)Kernel-level async I/O; best for raw + cache=none
I/O backendio_uringLatest Linux async I/O; best throughput on 5.1+ kernels
Multi-queuequeues: NParallel I/O across vCPUs; essential for NVMe-backed storage
Discard/TRIMdiscard: trueReclaims unused guest space in QCOW2; prevents image bloat
Preallocationprealloc: trueAllocates full image at creation; avoids fragmentation

Storage Troubleshooting #

SymptomLikely CauseResolution
VM fails to start: "disk locked"Another VM or process holds the image lockCheck quantavirt storage info <name> for lock owner
Slow I/O performanceWrong cache mode, QCOW2 fragmentationUse cache: "none" + io: "native", compact image
QCOW2 image keeps growingGuest deletes not propagatedEnable discard: true, run fstrim in guest
Encrypted disk won't unlockQUAC 100 not detected, wrong keyCheck quantavirt pqc status, verify key name
Snapshot restore failsCorrupted snapshot metadataRun quantavirt storage check <name> to repair
NFS mount timeoutFirewall, NFS server unreachableCheck NFS port (2049), verify exports, test mount manually