VM のストレージ I/O は、仮想ディスク形式だけで決まりません。guest filesystem、virtio device、QEMU、cache mode、host filesystem、storage backend、物理ディスクまで含めた経路で見る必要があります。
この記事では、virtio-blk / virtio-scsi、raw / qcow2、cache mode、discard、io_uring、NVMe passthrough を、単なる速い遅いではなく用途ごとの選択として整理します。
ストレージ I/O の経路を分けて見る
| 層 | 見る内容 |
|---|---|
| guest OS | filesystem、I/O scheduler、mount option |
| 仮想デバイス | virtio-blk、virtio-scsi、queue 数 |
| QEMU | cache mode、aio、io_uring、threading |
| 仮想ディスク | raw、qcow2、snapshot、thin provisioning |
| host / backend | filesystem、LVM、ZFS、Ceph、NVMe、RAID |
VM の中でディスクが遅く見えても、原因は guest ではなく host filesystem や backend storage にあることがあります。逆に backend が速くても、仮想ディスク形式や cache mode が合っていなければ性能は伸びません。
virtio-blk と virtio-scsi の違い
virtio-blk はシンプルな block device として扱いやすく、単純な VM では十分なことが多いです。virtio-scsi は SCSI の機能を使えるため、複数ディスク、hotplug、discard、queue などを扱う場合に選択肢になります。
| 方式 | 向く用途 |
|---|---|
| virtio-blk | 単純な仮想ディスク、構成を簡単にしたい VM |
| virtio-scsi | 複数ディスク、hotplug、discard、queue を意識する VM |
raw と qcow2 は性能と機能の交換である
raw は単純なディスクイメージで、余計な変換が少なく性能を読みやすい形式です。qcow2 は snapshot、thin provisioning、圧縮などの機能を持ちますが、その分だけレイヤが増えます。
| 形式 | 特徴 | 注意点 |
|---|---|---|
| raw | 構造が単純で性能を読みやすい | snapshot などの機能は外部で考える必要がある |
| qcow2 | snapshot や thin provisioning を扱いやすい | 機能分のオーバーヘッドと断片化に注意する |
本番 VM では raw、検証やテンプレート運用では qcow2、という単純な分け方もありますが、実際には backup、snapshot、storage backend、運用手順まで含めて決めます。
cache mode は性能だけで決めない
QEMU の cache mode は、性能だけでなくデータ保護と整合性にも関係します。writeback は速く見えることがありますが、障害時のリスクを理解する必要があります。none / directsync / writethrough / writeback などは、storage backend の性質と合わせて判断します。
VM のストレージ設定では、benchmark の数字だけでなく、電源断、host 障害、backend 障害、snapshot、backup といった運用条件を合わせて見ます。
discard は thin provisioning と回収に関係する
discard は、guest 側で不要になった block を backend に伝えるための仕組みです。thin provisioning や SSD / NVMe の回収に関係します。ただし、常時 discard がよいとは限らず、定期的な fstrim の方が扱いやすい場合もあります。
io_uring は I/O 経路を効率化する選択肢
io_uring は Linux の非同期 I/O インターフェースで、QEMU の I/O backend として使える構成があります。従来の native aio や threads と比べて、I/O 経路を効率化できる可能性があります。
ただし、io_uring を使えば必ず速くなるわけではありません。kernel、QEMU、libvirt、storage backend、ワークロードの組み合わせで効果が変わるため、実測と障害時の挙動を合わせて確認します。
NVMe passthrough は最短経路だが制約も大きい
NVMe を PCI Passthrough で VM に渡すと、仮想ディスクレイヤを大きく迂回できます。性能面では有利ですが、デバイスの共有性、移動性、snapshot、backup、host 側からの監視が難しくなります。
これは SR-IOV / PCI Passthrough と同じで、性能と仮想化基盤の柔軟性を交換する選択です。
現在の VM で確認すること
virsh domblklist vm-name
virsh dumpxml vm-name
qemu-img info /path/to/disk.qcow2
iostat -xz 1
lsblk -o NAME,TYPE,SIZE,MODEL,ROTA,DISC-MAX,DISC-GRAN設計時の確認ポイント
- 性能を優先するのか、snapshot や thin provisioning を優先するのか
- raw / qcow2 のどちらが運用に合うか
- virtio-blk / virtio-scsi のどちらが機能要件に合うか
- cache mode と障害時のデータ保護をどう考えるか
- discard / fstrim をどう扱うか
- backend storage の latency と throughput を確認しているか
関連する記事
- VM パフォーマンス ハブ
VM パフォーマンス関連記事の総合入口です。 - VM の性能ボトルネックを見分ける考え方
CPU、メモリ、I/O、ネットワークのどこが詰まるかを見る入口です。 - HugePages / TLB / NUMA で VM メモリ性能を安定させる考え方
ストレージ I/O と合わせて VM の土台になるメモリ配置の記事です。 - Ubuntu 26.04 KVM VM の作成
テンプレート qcow2 から libvirt domain を定義する実装側の記事です。 - Ubuntu 26.04 KVM VM パフォーマンス確認
virtio、HugePages、io_uring などを確認する記事です。
参考書籍
書籍
ハイパーバイザ、CPU 仮想化支援、メモリ仮想化、割り込み、仮想デバイスなど、VM の性能設計を低レイヤから理解したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
まとめ
VM のストレージ I/O は、raw / qcow2 の単純比較だけでは判断できません。virtio-blk / virtio-scsi、cache mode、discard、io_uring、backend storage、snapshot / backup 運用まで含めて見る必要があります。
性能だけを追うと raw や passthrough に寄りやすくなりますが、運用の柔軟性や保護機能を失うこともあります。VM の用途ごとに、性能、機能、運用性のどこを優先するかを決めることが重要です。
関連記事
DPDK で VM ネットワークを高速化する考え方 – dataplane / NFV / kernel bypass を見る
VM パフォーマンス設計ガイド
VM ネットワーク I/O を理解する考え方 – virtio-net と仮想 NIC の性能を見る
vhost-net / vhost-user で VM ネットワークを高速化する考え方 – virtio と kernel bypass の違い
VM の性能ボトルネックを見分ける考え方 – CPU / メモリ / I/O / ネットワークの入口
VM パフォーマンス最適化 – NUMA / CPU / I/O / ネットワークを設計で見る
SR-IOV / PCI Passthrough で VM ネットワークを高速化する考え方 – 仮想化レイヤを迂回する設計
CPU / NUMA / pinning で VM パフォーマンスを安定させる考え方