仮想ディスクの深淵：VMDK、VHD、QCOW2が「物理」と「論理」の境界線でやっていること
クラウドインフラの設計やKubernetesのノード管理をしていると、ふと「仮想ディスクって結局、何をやっているんだ？」と立ち止まる瞬間がありますよね。
ストレージ仮想化は、物理的なHDDやSSDのブロックを、ハイパーバイザーという「通訳」を介して、ゲストOSに「あんたの専用ディスクだよ」と嘘をつく技術です。今日は、現場でよく耳にする VMDK、VHD、QCOW2 という3つのフォーマットの正体と、それらが実務でどう化けるのか、泥臭い知見を交えて解説します。
—
1. 仮想ディスクの「皮」を剥ぐ：なぜフォーマットが重要なのか
ストレージ仮想化の本質は抽象化です。物理デバイス上のどこにデータがあるかをOSから隠蔽し、スナップショットやシンプロビジョニングといった「魔法」を提供します。
代表的なフォーマットの性格
- VMDK (VMware Virtual Machine Disk): 圧倒的な安定感。メタデータとデータを分離でき、大規模なエンタープライズ環境での実績は随一です。
- VHD/VHDX (Virtual Hard Disk): Hyper-Vの標準。VHDXは最大64TBまで扱え、電源断時の破損耐性が高いのが特徴。Azureに持っていくならこれ一択です。
- QCOW2 (QEMU Copy On Write): KVM/OpenStack界の旗手。最大の特徴は「Copy on Write」にあり、書き込みが発生したタイミングでブロックを確保する効率の良さが光ります。
—
2. QCOW2の「Copy on Write」をハックする
実務で最も面白いのは QCOW2 です。シンプロビジョニング（必要な分だけ容量を使う）とスナップショットの挙動を理解するために、qemu-img コマンドでその裏側を覗いてみましょう。
仮想ディスクの作成と確認
まず、実務でよく使う「差分ディスク」の作成フローです。
# 1. ベースとなるマスターイメージ（10GB）を作成
qemu-img create -f qcow2 base.qcow2 10G
# 2. ベースを親として、差分だけを記録する「オーバーレイ」を作成
# これにより、元のイメージを汚さずにOSのテスト環境が作れる
qemu-img create -f qcow2 -b base.qcow2 -F qcow2 overlay.qcow2
# 3. 仮想ディスクの詳細情報を確認（ここで論理サイズと実サイズを見る）
qemu-img info overlay.qcow2ここで qemu-img info を実行すると、virtual size と disk size が表示されます。disk size が小さいのは、まだ書き込みが発生していないからです。この「遅延確保」こそが、クラウド事業者が利益を出すための重要な仕組みの一つです。
—
3. Web APIから仮想ディスクを操る：Pythonの実例
クラウド基盤を自動化する際、REST API を通じて仮想ディスクのステータスを取得することは日常茶飯事です。例えば、OpenStackの Cinder APIを叩くようなイメージで、Pythonによるステータスチェックの断片を見てみましょう。
import requests
def check_volume_status(volume_id, auth_token):
"""
仮想ディスクのメタデータを確認するシミュレーション
"""
url = f"https://cloud-api.example.com/v3/volumes/{volume_id}"
headers = {
"X-Auth-Token": auth_token,
"Content-Type": "application/json"
}
try:
response = requests.get(url, headers=headers)
response.raise_for_status()
volume = response.json()
# 重要なパラメーター: bootableか、どのフォーマットか
print(f"Volume Name: {volume['name']}")
print(f"Format: {volume['disk_format']}") # 'qcow2' や 'raw' 等
return volume['status']
except requests.exceptions.RequestException as e:
print(f"API Error: {e}")
return None
# 実行例: 実際の現場ではここからさらにスナップショットの作成トリガーへ繋ぐ
# check_volume_status("vol-12345", "gAAAAABk...")—
4. 現場でハマる「落とし穴」とデバッグTips
最後に、SREとして現場で直面する「仮想ディスクのトラブル」への心構えを共有します。
1. パフォーマンスの壁: QCOW2 はスナップショット機能が強力ですが、バックグラウンドで頻繁にブロックの割り当て（CoW処理）が発生するため、高負荷環境では Raw フォーマットに比べてIOレイテンシが跳ね上がることがあります。DBサーバーのディスクには Raw を選ぶのが「大人の選択」です。
2. 容量の逆転現象: シンプロビジョニングを使いすぎると、物理ストレージが枯渇してもゲストOS側は気づかない「オーバープロビジョニング」が発生します。監視の際は df コマンドではなく、ハイパーバイザー側のストレージプール使用率を監視対象にしてください。
3. ヘッダーの破損: qcow2 のヘッダーが壊れると、ディスク全体がマウントできなくなります。qemu-img check を定期的にcronで回し、早期発見する仕組みは必須です。
—
まとめ：技術は「仕組み」を知れば怖くない
VMDKもQCOW2も、結局のところ「物理的な0と1をどう並べるか」というルールの違いに過ぎません。しかし、その違いがシステムの可用性やコストに直結します。
教科書を暗記するのではなく、qemu-img で遊んだり、APIのレスポンスを眺めたりして、「パケット（データ）がどう動いているか」を想像できるようになれば、あなたはもう一人前のインフラエンジニアです。
次回の障害対応では、ぜひこの「ディスクの裏側」を思い浮かべてみてください。きっと、解決への最短ルートが見えてくるはずです。それでは、また現場でお会いしましょう。
コメント