層構造の全体像
smolvmのアーキテクチャは、大きく4つの層で構成されています。最上位のCLI層がユーザーとの接点となり、その下でlibkrun（最小VMM）とlibkrunfw（専用カーネル）がマイクロVMを構成し、各OSのネイティブハイパーバイザを介してハードウェアのCPU仮想化支援機構を利用する、という積み重ねです。従来の仮想化スタックと比べて特筆すべきは、QEMUのような汎用エミュレータ層が存在しないことです。
この構造により、VMの構成要素は「ワークロードの実行に本当に必要なもの」だけに絞り込まれます。BIOSエミュレーションも、レガシーデバイスも、汎用OSのブートローダも不要です。結果として、軽量仮想マシンでありながら200ミリ秒未満という起動時間と、小さな攻撃面（アタックサーフェス）を同時に達成しています。
libkrunとlibkrunfw：最小VMMと専用カーネル
libkrunは、プロセスに「仮想化ケーパビリティ」を組み込むためのライブラリ型VMM（Virtual Machine Monitor）です。QEMUが独立したプロセスとして多種多様なデバイスをエミュレートするのに対し、libkrunはアプリケーションにリンクされるライブラリとして動作し、virtioベースの準仮想化デバイスのみを提供します。smolvmはこのlibkrunを核に採用することで、「VMを起動する」という重い操作を「関数を呼ぶ」程度の軽さに変えています。
libkrunfwは、libkrunとペアで使われる専用のゲストカーネルです。汎用ディストリビューションのカーネルとは異なり、マイクロVMでのワークロード実行に必要な機能だけを組み込んだ最小構成のLinuxカーネルで、ライブラリとしてバンドルされます。カーネルのロードと初期化が極小化されているため、ゲストの起動は一瞬で完了します。
ここで重要なのは、smolvmではワークロードごとに専用カーネルが割り当てられるという点です。コンテナのようにホストカーネルを共有しないため、あるVM内でカーネルレベルの問題（クラッシュや脆弱性の悪用）が発生しても、影響はそのVMに閉じます。この性質はセキュリティとAIコードサンドボックスで解説するサンドボックス用途の土台となっています。
3つのOSとネイティブハイパーバイザ
smolvmは、各OSが標準で備えるハイパーバイザAPIを直接利用します。追加のカーネルモジュールやサードパーティ製ハイパーバイザのインストールは不要です。
| OS | ハイパーバイザ | 備考 |
|---|---|---|
| macOS | Hypervisor.framework | Apple公式の仮想化API。コード署名とentitlementsが必要（公式バイナリは設定済み） |
| Linux | KVM | カーネル標準の仮想化基盤。サーバー・CI環境での利用に最適 |
| Windows | WHP | Windows Hypervisor Platform。GPU・fork・スナップショットは現状未対応 |
この「ネイティブハイパーバイザ直結」という設計は、Firecracker（KVM専用）やKata Containers（Linux前提）が持つプラットフォーム制約を回避し、開発者のmacOSラップトップと本番のLinuxサーバーで同一の操作体験を提供するという、smolvmの際立った差別化要因になっています。
virtio balloonによる弾性メモリ
従来のVMでは、割り当てたメモリをホストが事前に確保してしまうため、「VMを立てるほどホストが痩せる」という問題がありました。smolvmは既定で4 vCPU・8GiB RAMをVMに割り当てますが、virtio balloonデバイスによる弾性メモリにより、ホストが実際にコミットするのはゲストが本当に消費している分だけです。
vCPUについても同様に、アイドル状態のvCPUはスリープするため、稼働していないVMがホストのCPUを浪費することはありません。この2つの仕組みにより、1台のホストに多数のマイクロVMをオーバープロビジョニングしてもほぼ無コストという、コンテナ的な集積密度をVMの分離性のまま実現しています。SREの視点では、ワークロードごとにVMを分ける運用が現実的なコストで成立することを意味します。
起動シーケンス：200ミリ秒未満の内訳
smolvmのVM起動が高速な理由は、起動シーケンスの各段階から「省略できるもの」を徹底的に省いている点にあります。BIOS/UEFIの初期化、ブートローダの探索、initramfsの展開といった汎用VMの儀式は存在せず、libkrunfwのカーネルがメモリに直接ロードされ、即座にワークロードのエントリポイントへ到達します。
この起動速度は単なる快適さ以上の意味を持ちます。VMが使い捨てられるほど軽くなることで、「タスクごとに新品のVMを起動し、終わったら破棄する」というイミュータブルな実行モデルが現実的になるからです。CIジョブやAIエージェントのコード実行のように、大量の短命タスクを安全に捌く用途で真価を発揮します。
GPUアクセラレーションの仕組み
smolvmはvirtio-gpuとVenusプロトコル（Vulkan over virtio）により、ゲスト内からホストGPUを利用できます。ゲストのVulkanコマンドはvirtio-gpu経由でホストに転送され、ホスト側のレンダラで実行されます。
- macOS: virglrendererとMoltenVK（Vulkan→Metal変換層）が同梱されており、追加インストールなしでGPUを利用できます。
- Linux: virglrendererに加えて、ホスト側にVulkanドライバの導入が必要です。
- Windows: GPUアクセラレーションは現時点で未対応です。
利用方法はsmolvm machine run --gpuとフラグを1つ追加するだけです。機械学習の推論や画像処理といったGPUワークロードを、ハードウェア分離を保ったまま実行できるため、マルチテナントなAI実行基盤の構成要素としても検討する価値があります。実践的なコマンド例はインストールと基本操作で紹介しています。
