Smol machines – 1秒未満のコールドスタートとポータブルな仮想マシン

 (github.com/smol-machines)
7 ポイント 投稿者 GN⁺ 12 일 전 | 1件のコメント | WhatsAppで共有
  • smolvm は、macOS と Linux で動作する CLI ベースの仮想マシン管理ツール で、隔離された環境でソフトウェアを実行
  • サブ秒未満のコールドスタート、弾力的なメモリ管理、単一ファイルのポータビリティ をサポートし、高速で軽量な VM 実行が可能
  • VM は Linux カーネルベースのマイクロVM として動作し、.smolmachine ファイルにパッケージ化して 依存関係なしで再実行 可能
  • ハイパーバイザー境界による隔離、SSH エージェント転送、Smolfile ベースの環境宣言 などにより、開発・セキュリティ環境を統合的にサポート
  • Docker デーモンなしで OCI イメージを起動 でき、200ms 未満の起動時間とハードウェアレベルの隔離 により、軽量仮想化の代替案を提示

概要

  • smolvm は、隔離された環境でソフトウェアを実行 するための CLI ベースの仮想マシン管理ツール
  • macOS と Linux で動作し、サブ秒コールドスタート、弾力的なメモリ使用、移植可能な単一ファイルパッケージ化 をサポート
  • 各ワークロードは Linux カーネルベースのマイクロVM で実行され、ハードウェアレベルの隔離 を提供
  • .smolmachine ファイルとしてパッケージ化された VM は、同一アーキテクチャのプラットフォームで 依存関係なしに再実行可能

主な機能

  • ローカル仮想マシンの管理と実行

    • smolvm machine run コマンドでカスタム Linux VM を実行
    • コールドスタートは 1 秒未満で、macOS と Linux の両方をサポート
    • メモリは virtio balloon により弾力的に管理され、実際の使用量だけがホストに割り当てられる

  • 移植可能な単一ファイルパッケージ化

    • VM の状態を含む .smolmachine ファイルとしてまとめ、別プラットフォームで再生成可能
    • すべての依存関係が内蔵されており、インストールなしで即時実行可能、起動時間は 200ms 未満

  • 信頼できないコードのサンドボックス化

    • ハイパーバイザー境界を通じて、ホストのファイルシステム、ネットワーク、認証情報 を完全に分離
    • デフォルトではネットワークは無効で、--allow-host オプションで特定ホストのみ許可可能

  • 永続的な開発用 VM

    • machine create、start、stop コマンドで VM を作成・管理
    • インストールしたパッケージは再起動後も保持され、開発環境として利用可能

  • SSH エージェント転送

    • ホストの SSH エージェントを VM 内に転送するが、秘密鍵はゲストにコピーされない
    • --ssh-agent オプションにより、ホストの SSH 認証を安全に利用可能

  • Smolfile ベースの環境宣言

    • TOML 形式の Smolfile で VM 設定を宣言
    • イメージ、ネットワーク、初期化コマンド、ボリューム、認証オプションなどを指定し、再現可能な環境構成 が可能

使用例

  • 一時 VM の実行

    • smolvm machine run --net --image alpine -- sh -c "echo 'Hello world'"
    • 終了時に VM が自動的にクリーンアップされるワンショット実行方式

  • パッケージ化された実行ファイルの作成

    • smolvm pack create --image python:3.12-alpine -o ./python312
    • 生成された実行ファイルで独立した Python 環境を実行可能

  • ネットワーク制御

    • デフォルトのネットワークは無効
    • --allow-host オプションで特定ドメインのみアクセスを許可

  • SSH と Git の利用

    • smolvm machine run --ssh-agent --net --image alpine
    • ホストの SSH キーを安全に使って Git リポジトリにアクセス可能

内部構造と動作方式

  • 各ワークロードは Hypervisor.framework(macOS) または KVM(Linux) 上で 独立したカーネル を実行
  • libkrun ベースの VMM と カスタムカーネル(libkrunfw) を使用
  • OCI イメージフォーマット をサポートし、Docker Hub、ghcr.io などからイメージを直接取得して実行可能
  • Docker デーモン不要 で、標準 OCI イメージをそのまま起動可能
  • デフォルト設定は 4 vCPU、8GiB RAM で、--cpus、--mem オプションで調整可能
  • vCPU スレッド はアイドル時にハイパーバイザーで自動的に省電力状態になり、オーバーコミットのコストがほとんどない

比較

項目 smolvm Containers Colima QEMU Firecracker Kata
分離レベル ワークロードごとの VM 名前空間（共有カーネル） 名前空間（単一 VM） 個別 VM 個別 VM コンテナごとの VM
起動時間 <200ms 約 100ms 数秒 15〜30秒 <125ms 約 500ms
アーキテクチャ ライブラリ(libkrun) デーモン VM 内デーモン プロセス プロセス ランタイムスタック
ワークロードごとの VM 対応 非対応 共有 対応 対応 対応
macOS ネイティブ 対応 Docker VM 経由 krunkit ベース 対応 非対応 非対応
SDK 内蔵 対応 非対応 非対応 非対応 非対応 非対応
移植可能なアーティファクト .smolmachine デーモンが必要なイメージ 非対応 非対応 非対応 非対応

プラットフォーム対応

ホスト ゲスト 要件
macOS Apple Silicon arm64 Linux macOS 11 以降
macOS Intel x86_64 Linux macOS 11 以降（テスト未完了）
Linux x86_64 x86_64 Linux KVM(/dev/kvm) 必須
Linux aarch64 aarch64 Linux KVM(/dev/kvm) 必須

既知の制限事項

  • ネットワークはデフォルトで無効、--net オプションでのみ有効化可能
  • TCP/UDP のみサポート、ICMP は非対応
  • ボリュームマウントは ディレクトリ単位のみ可能 で、単一ファイルは不可
  • macOS では Hypervisor.framework 権限で署名されたバイナリ のみ実行可能
  • --ssh-agent 使用時はホストで SSH エージェントが実行中である必要がある（SSH_AUTH_SOCK の設定が必要）

開発関連

  • 開発ガイドラインは docs/DEVELOPMENT.md で確認可能
  • Apache-2.0 ライセンス で公開されており、@binsquare が開発

関連記事

1件のコメント

 
GN⁺ 12 일 전
Hacker News のコメント

  • 私は Docker コンテナを置き換える仮想マシン を作っています
    コンテナの使い勝手はそのままに、1秒未満の起動時間 を目標にしています
    AWS で Firecracker 関連の仕事をする中で、コンテナは不要なレイヤーだと気づき、Firecracker は AWS の内部構造に合わせて設計された技術でした
    そこで、コンテナの利点と Firecracker の利点を組み合わせたハイブリッドな形を自分で作ることにしました
    意見を聞かせてほしいです

    • これは本当にすごい。私も AI サンドボックスソリューションを調べていて、Lima+Incus の組み合わせで Locki を作りました
      microVM は普通 Docker や Kubernetes を動かせないので悩みどころでした
      私は Kubernetes クラスター全体をサンドボックスの中に入れたいです。k3s の実行 もサポートしているのか気になります
    • ライブマイグレーション の対応状況が気になります
      似たようなシステムではいつも抜けがちな機能ですが、クラウドネイティブなワークロード以外にも、まだそうした機能が必要な環境は多いです
      もしこれを実装できれば、本当に差別化ポイントになると思います
    • コードのうち、どの程度が LLM/AI によって書かれた部分 なのか気になります
    • 私も似たようなものを作りました — 名前は shuru.run です
      Firecracker は macOS で動かないので、AI アプリ向けの microVM サンドボックスを簡単に作りたかったのです
      一般ユーザーの立場では Firecracker は重すぎます
    • 1秒未満のブート時間 を達成するために、最も難しかった設計上の課題は何だったのか気になります
      そして、それをさらに短縮するには、現時点でどんな ボトルネック があるのかも知りたいです

  • このプロジェクトは、いくつかの unikernel 実装 に似ているように聞こえます — たとえば Unikraft のようなものです

    • Unikraft の内部はオープンソースではないので、詳しくは分かりません
      ただ、Smol Machines は unikernel 実装ではなく、Linux カーネルをスリム化したバージョン です
      そのため、大半のソフトウェアと高い互換性があります

  • 自己完結型バイナリ生成機能 は、JVM アプリを GraalVM Native よりも簡単にパッケージできる方法のように見えます
    例のコマンド:
    smolvm pack create --image python:3.12-alpine -o ./python312
    ./python312 run -- python3 --version
    → Python 3.12.x が完全に隔離された状態で実行され、pyenv/venv/conda は不要です

    • これは Electron に似た考え方です
      Electron が Web アプリをブラウザごと配布するように、Smol Machines はソフトウェアを Linux VM と一緒にパッケージ します
      依存関係の管理や互換性の問題を避けられます
      個人的には Codex や Claude Code のようなツールも、この方法で配布されると良いと思います
    • 誰でも一度くらいは「開発環境を壊してしまった経験」があるはずです
      これはそうした問題を解決するための 「配布可能なマシン」 という考え方です
      一度きちんと設定すれば、誰にでもすぐ共有して実行してもらえます

  • .smolmachine ファイルが デジタル署名および自己認証 をサポートしているのか気になります
    Sylabs の署名/検証ドキュメント のように動作できるのか知りたいです

  • zeroboot のアイデアを適用すれば、さらに高速化できるのか気になります

  • 比較表が本当に良くできています
    最初は「Firecracker と似ているな」と思いましたが、表を見て違いがはっきり分かりました
    見やすかったですし、全体として 非常に印象的な仕事 です

    • ありがとうございます

  • CLI ドキュメントで alpine と python:3.12-alpine のイメージを見かけましたが、これがどこから来るのか気になります
    Docker レジストリのような所から取得するのか、組み込みなのか、それとも smolfile で自分で作るのか知りたいです
    Ubuntu イメージもあるのか気になります
    メモリ/CPU のホットリサイズ 機能が追加されると良さそうですし、顧客ごとのバックエンドインフラのオーケストレーションにも使えそうです

  • ほとんどのオープンソースプロジェクトは Docker Compose でコンテナを立ち上げますが、Smol Machines は microVM の中で Docker をサポートしていません
    また、Vagrant のような ネストされた VM もサポートしていないので残念です

    • Docker は対応予定です。次のリリースで、必要なカーネルフラグを含む 互換カーネル を配布する計画です
    • Vagrant はローカルで VM を起動するため、ネスティングが必要なのだと思います
      その代わり、トランポリン方式 で Vagrant VM の兄弟 VM として実行するのはどうかと提案します

  • Docker サンドボックスの代わりに Smol Machines を使うべき 核心的な理由 は何なのか、短く説明してもらえると嬉しいです

  • 本当に素晴らしい成果です。おめでとうございます