smolvmのWindows版：導入条件とVMの起動手順

smolvmは、Linux環境を軽量な仮想マシン（microVM）として起動・管理するCLIツールである。カーネルとは、プログラムの実行やメモリ、機器へのアクセスを管理するOSの中核である。smolvmはVMごとに独立したLinuxカーネルを持ち、実行するプログラムをハードウェア仮想化で隔離する。Docker HubなどのOCI形式のコンテナイメージを利用でき、起動にDockerデーモンを必要としない。smolvm v1.16.2の構成説明

本記事ではv1.16.2を対象に、WHPの有効化、配布ファイルの配置、Linuxゲスト内でのコマンド実行の順に説明する。

確認日：2026年9月21日。公式文書とWindows用ZIPの内容に基づく。Windows上でのVM起動は未検証であり、各手順には実測結果ではなく、動作確認の判断基準を記載している。

smolvmの特徴

終了時に削除する一時VMと、ファイルや追加パッケージを保持する永続VMを使い分けられる。ネットワークは既定で無効になっており、必要な場合に有効化する。例えば、取得したコードを一時VMで実行して動作を確認し、継続的な開発には永続VMを使う構成が考えられる。実行例とネットワーク設定

Windows版はx86_64に対応し、Windows Hypervisor Platform（WHP）を介してLinuxゲストを実行する。WSL2の導入は必要ない。

Dockerとの比較

ここでは、Docker Engineによる通常のLinuxコンテナと比較する。WindowsではDocker DesktopのLinuxコンテナ実行環境を対象とし、Windowsコンテナや追加の隔離ランタイムは含めない。

表の根拠：smolvmの構成とSmolfile、DockerのコンテナとVMの説明、Docker DesktopのWindows実行基盤、Composeの構成モデル。

Windows上のDocker Desktopも、Linuxを動かすために仮想化を使う。比較すべきなのは仮想化の有無ではなく、実行環境ごとにカーネルを分けるか、複数のコンテナで共有するかである。

カーネル分離のメリットとデメリット

メリットは、ゲスト側の障害や侵害の影響範囲を限定しやすいことである。 smolvmではVMごとにカーネルが独立しているため、あるゲストのカーネルが停止しても、ほかのVMが同じカーネルの停止に巻き込まれる構成にはなっていない。ゲスト内でカーネルの脆弱性が悪用された場合も、ホストや別のVMとの間には仮想化による隔離境界が残る。smolvmのセキュリティモデル

デメリットは、VMごとにカーネルを起動・保持する負荷が加わることである。 Dockerの通常のLinuxコンテナはカーネルを共有するため、その分の起動処理やメモリの重複を抑えられる。実際の差はVMの実装、アプリケーション、設定に依存する。DockerによるコンテナとVMの説明

カーネルの分離にも限界はある。ホストOSやハイパーバイザーは共有しており、共有フォルダやネットワークとして許可したアクセスも残る。また、カーネルが独立していることと、任意のカーネルを選べることは別である。smolvmではlibkrunfwがゲストカーネルを提供し、コンテナイメージから主にコマンドやライブラリなどの実行環境を取り込む。smolvmの構成説明

用途を選ぶ際は、実行するコードごとにVMの隔離境界が必要ならsmolvm、Webアプリとデータベースなどを複数のコンテナとして定義・管理したいならDockerとComposeを検討できる。これは構成上の違いに基づく判断であり、起動速度やメモリ使用量の優劣を示すものではない。本記事では同条件での性能比較を行っていない。

Windows対応の履歴

Windows x86_64向けの配布は、2026年6月28日公開のv1.3.0から始まっている。以降も起動や配布物に関する修正が続いているため、対応開始時の版と本記事の対象版では導入時の挙動が異なる。

以下は、公式リリースと関連する変更内容から、Windowsでの導入・実行に関係する主な更新を抜粋したものである。日付はリリース公開日（UTC）を示し、実機での検証結果ではない。

古い版の不具合報告を参照する際は、対象バージョンと修正版を照合する必要がある。ただし、個別の修正が含まれることと、手元の環境で起動できることは別である。以下の手順でCLIとVMの起動をそれぞれ確認する。

Windows版の対応範囲

Windows版のv1.16.2ではGPUアクセラレーション、machine branch、machine checkpointが非対応である。これらの機能が必要な用途には、このバージョンのWindows版は使えない。v1.16.2のREADME

1. WHPを有効にする

WHPは、smolvmがWindowsの仮想化機能を利用するための基盤である。公式の導入手順に従い、Windowsの「Windowsの機能の有効化または無効化」で「Windowsハイパーバイザープラットフォーム」を有効にする。再起動を求められた場合は、再起動を済ませてから次へ進む。

2. 配布ZIPを展開し、CLIを確認する

v1.16.2のリリースページから、smolvm-1.16.2-windows-x86_64.zipを取得し、フォルダ構成を保って展開する。

実行にはsmolvm.exeに加え、krun.dll、libkrunfw.dllなどの同梱ファイルが必要になる。実行ファイルだけを移動せず、展開時の配置を維持する。ZIPにはディスク作成用のstorage-template.ext4とoverlay-template.ext4も含まれており、これらを別途作成する必要はない。

smolvm.exeがあるフォルダをPowerShellの作業ディレクトリにして、CLIのバージョンを確認する。

.\smolvm.exe --version

出力に1.16.2が含まれていれば、対象バージョンのCLIが起動している。VMの起動は、次のコマンドで別に確かめる。

3. Linuxゲストでコマンドを実行する

ここでは、軽量なLinuxディストリビューションであるAlpine Linuxを使う。ディストリビューションとは、Linuxを使える環境としてまとめた配布形態で、Ubuntuなどもその一つである。今回のalpineイメージは、VM内で使う基本コマンドやライブラリを提供する。

イメージ選びの注意点

イメージはサイズだけで選ばず、実行したいプログラムの要件と、後から同じ環境を再現できるかを確認する。

1. Windows版でも、選ぶのはLinux用イメージである。 本記事のWindows x86_64環境では、linux/amd64向けのイメージを使う。amd64はAMD製CPU限定という意味ではなく、x86_64に対応する表記である。複数のCPU向けに配布されているイメージでは、この形式が含まれるか確認する。windows/amd64やARM専用イメージは、この手順の対象にならない。smolvmの対応環境、イメージのプラットフォーム表記

2. Alpineの軽量さと、実行ファイルの互換性は別に確認する。 Alpineは、多くのLinuxプログラムが利用するC標準ライブラリとしてmuslを採用している。DebianやUbuntuなどで使われるglibcとは異なるため、glibcを前提に配布された実行ファイルやネイティブ拡張が、そのまま動かない場合がある。例えば、Node.jsの公式イメージでもAlpine版の互換性に注意が示されている。既存アプリケーションを動かす際は、そのアプリケーションが対応するベースイメージを優先する。Node.js公式イメージのAlpine版に関する説明

3. 必要なコマンドやランタイムが含まれるか確認する。 この例ではunameを使うが、最小構成のイメージにはシェルや調査用コマンドが含まれないこともある。Alpineの基本イメージにPythonやNode.jsが入っているとも限らない。起動確認用の環境と、アプリケーションを動かすための環境は、必要なものに合わせて選ぶ。

4. 再現する必要がある環境では、タグとダイジェストを記録する。 下の例は公式の起動例に合わせてalpineとだけ指定しているため、取得時点の違いによって同じ内容になるとは限らない。バージョンタグで対象を明示しても、タグの参照先は更新されることがある。厳密な再現には、内容を識別する値であるダイジェストで対象を固定する。一方、固定したイメージには更新が自動反映されないため、修正版への更新も必要になる。タグとダイジェストの違い

5. 配布元と保守状況を確認する。 プロジェクトの公式文書が案内するイメージや、Docker Official Imagesなどを起点に、公開者、更新状況、対象バージョンのサポートを確認する。smolvmのVM隔離があっても、共有フォルダやネットワークとして与えた権限はイメージ内のプログラムから利用できる。イメージの選定指針、smolvmのセキュリティモデル

起動を確認する

Alpineの環境を使う一時VMを起動し、uname -aでカーネル情報を取得する。

.\smolvm.exe machine run --net --image alpine -- uname -a

--image alpineでゲストのイメージを指定し、--netでネットワークを有効にする。区切りの--以降がゲストに渡すコマンドであり、この例ではLinuxのカーネル情報を取得する。

Linuxのカーネル情報が表示され、コマンドが正常終了すれば、VMの起動とゲスト内でのコマンド実行を確認できる。ただし、uname -a自体は通信を行わないため、ネットワークの疎通確認は別途必要になる。

machine runによる一時VMは、コマンド終了時に削除される。起動確認には一時VMを使い、ファイルや追加パッケージを次回の実行にも残す用途では、machine createによる永続VMを選ぶ。公式のVM実行手順

参考資料

• 公式の導入手順
• v1.16.2リリース
• v1.16.2のREADME