virtio
準仮想化(paravirtualization)デバイスの標準規格。ゲストOS側のデバイスドライバが「本物のハードウェアを模倣したフリ」をせず、最初から仮想環境向けに設計された軽量なプロトコルでホスト(VMM)と直接やり取りする。OASISが管理するオープン標準。 #virtualization
成り立ち
2007年、Rusty RussellがIBM研究所在籍時に、自身のlguestハイパーバイザー向けに開発した。その後KVMの準仮想化I/Oデバイスの事実上の標準として広く採用されるようになった。
なぜ必要か: フルデバイスエミュレーションとの対比
QEMUのようなVMMは、実在するNICやディスクコントローラ(例: Intel e1000)のレジスタ挙動までソフトウェアで再現する「フルデバイスエミュレーション」も可能だが、これはゲストのI/Oアクセスのたびに細かい互換性の再現が必要でオーバーヘッドが大きい。virtioは「どうせゲスト側もハイパーバイザー前提で動くなら、実機を装うのをやめて効率重視のインターフェースにしよう」という発想で設計されている。
仕組み: virtqueue
ゲストのドライバとホスト側のデバイス実装は、virtqueueと呼ばれる共有メモリ上のリングバッファを介して通信する。ゲストはバッファをキューに積み、ホストに「ドアベル」で通知する。処理が終わるとホストはゲストに割り込みで通知する。ポーリングを避けつつ、データコピーやトラップの回数を最小限に抑える設計になっている。
主なデバイス種別
virtio-net(ネットワーク)・virtio-blk(ブロックデバイス)・virtio-console(シリアルコンソール)・virtio-fs(ファイルシステム共有)・virtio-vsock(ホスト-ゲスト間ソケット通信)など。Firecrackerが提供する実質5種類のデバイスも、その大半がvirtioベース。
rust-vmm/crosvmでの扱い
rust-vmmはvirtioデバイス関連クレートを共通部品として提供しており、Firecracker・Cloud Hypervisor・crosvmなど複数のVMMがそれを利用してvirtioデバイスを実装している。crosvmは各virtioデバイスを個別プロセスにforkする「process-per-device」設計を取っている。
実際に動かしてみる
KVMの生ioctl実験の上に、virtqueueの核心(共有メモリ+バッチ化+1回の通知)だけを再現したトイ実装を作り、1バイトごとに通知する前回実験と比べてVM exit回数がどれだけ減るかをvirtqueue風トイ実験で確認した。
コンテナ向け軽量VM技術の中での位置づけ
KVMがCPU仮想化の土台であるのと同様に、virtioはI/O仮想化の共通土台。Firecracker・Cloud Hypervisor・crosvm・QEMUが共通して採用している。microVMが高速に起動・動作できる理由の一つは、フルデバイスエミュレーションではなくvirtioのような軽量なI/Oに絞っていることにある。