ハクソク

世界を動かす技術を、日本語で。

Show HN: Smolマシン – サブ秒コールドスタート、ポータブル仮想マシン

8時間前原文(github.com)

概要

smolvmは、ソフトウェアをデフォルトで分離して実行できるCLIツール。
超高速なLinux仮想マシン（VM）をローカルで管理・実行可能。
クロスプラットフォーム対応で、単一ファイルに状態をパックして持ち運びも容易。
サンドボックスやポータブル実行ファイルの作成、開発環境の永続化に最適。
シンプルなTOMLファイルで環境構成も宣言的に管理。

smolvmとは

  • 独立した仮想マシンをローカルで管理・実行できるCLIツール
  • サブ秒（<200ms）での高速起動、macOS/Linux両対応
  • メモリ消費の弾力的最適化、必要分だけホストから確保
  • 単一ファイル（.smolmachine）へのパッキング、どこでも再現可能
  • 状態を持つVMの作成・停止・再起動、パッケージの永続化

インストール方法

  • macOS/Linux両対応のインストールスクリプト
    • curl -sSL https://smolmachines.com/install.sh | bash
  • GitHub Releasesからのダウンロードも可能
  • コマンド一覧の確認
    • smolvm --helpで利用可能な全コマンドを表示

基本的な使い方

  • 一時的なVMでコマンド実行（終了後自動クリーンアップ）
    • smolvm machine run --net --image alpine -- sh -c "echo 'Hello world from a microVM' && uname -a"
  • 対話的シェル起動
    • smolvm machine run --net -it --image alpine -- /bin/sh
  • VM内でのパッケージ追加・実行例
    • apk add sl && sl && exit

主なユースケース

  • サンドボックス：未検証コードの安全実行
    • ホストのファイルシステム・ネットワーク・認証情報をハイパーバイザーで隔離
    • デフォルトでネットワーク無効、許可ホストのみ通信可
      • 例: --allow-host registry.npmjs.org
  • ポータブル実行ファイル化：依存関係込みの自己完結型バイナリ生成
    • 例: smolvm pack create --image python:3.12-alpine -o ./python312
  • 開発用永続VM：パッケージや設定の永続化
    • VM作成、起動、コマンド実行、停止を個別に管理
  • SSHエージェント転送：ホストのSSH鍵をVM内で安全に利用
    • 鍵がゲストに渡らず、ハイパーバイザーで厳格管理
  • Smolfileによる宣言的環境構築：TOML形式でVM設定を記述
    • 例: イメージ、ネットワーク、ボリューム、SSHエージェント等を一括管理

仕組み・特徴

  • 各ワークロードごとに独立カーネル・VMを割り当て
    • macOS: Hypervisor.framework、Linux: KVMを利用
  • libkrun + カスタムカーネル（libkrunfw）による高速VMM
  • .smolmachineファイルでアーキテクチャ一致ホスト間の完全移植
  • デフォルト: 4 vCPU、8 GiB RAM（--cpus, --memで変更可）
  • virtio balloonによる動的メモリ割当・自動回収
  • アイドル時はvCPUスリープ、オーバープロビジョニングも低コスト

他ソリューションとの比較

| 項目 | smolvm | Containers | Colima | QEMU | Firecracker | Kata | |---------------------|------------|------------|------------|------------|-------------|-------------| | 隔離方式 | ワークロード毎VM | 名前空間 | 名前空間+1VM | 独立VM | 独立VM | コンテナ毎VM | | 起動時間 | <200ms | ~100ms | ~秒 | ~15-30s | <125ms | ~500ms | | macOSネイティブ | 対応 | Docker VM経由 | krunkit経由 | 対応 | 非対応 | 非対応 | | ポータブル成果物 | .smolmachine | イメージ | 非対応 | 非対応 | 非対応 | 非対応 |

対応プラットフォーム・要件

  • macOS: Apple Silicon (arm64), Intel (x86_64), macOS 11+（未検証含む）
  • Linux: x86_64, aarch64（KVM必須）
  • ゲストアーキテクチャはホストと一致必須

既知の制限事項

  • ネットワークは明示的に有効化（--net指定）
    • TCP/UDPのみ対応、ICMP非対応
  • ボリュームマウントはディレクトリ単位のみ
  • macOSではバイナリ署名とHypervisor.framework権限が必要
  • --ssh-agentはホストでSSHエージェント稼働必須（SSH_AUTH_SOCK設定）

開発・ライセンス

  • Apache-2.0ライセンス、作者: @binsquare
  • 詳細・開発ドキュメント: docs/DEVELOPMENT.md参照
  • Twitter・GitHubで最新情報発信

Hackerたちの意見

こんにちは！コンテナのエルゴノミクスとサブ秒の起動時間を持つ仮想マシンで、Dockerコンテナの代替品を作ってるんだ。以前はAWSでコンテナ関連やファイアクラッカーに関わってたけど、コンテナは必要のないレイヤーで、物事を遅くしてることに気づいたんだ。ファイアクラッカーはAWSの組織構造とユースケースのために設計された技術だったしね。だから、コンテナの良いところとファイアクラッカーの良いところを組み合わせたハイブリッドを作ることにしたんだ。意見を聞かせてね、ありがとう！
└
+1。shuru.runっていう似たようなものを作ったよ。AIアプリを動かすためのマイクロVMサンドボックスを簡単にセットアップしたかったから。ファイアクラッカーはmacOSでは使えなかったし、君が言った通り、普通のユーザーレベルのワークロードには重すぎるんだよね。
└
比較表にOrbStackも追加したらいいよ。
└
こんにちは、素晴らしいプロジェクトだね！でも、Windowsのサポートが全然足りないのが残念。今、サンドボックス化されたLLMをたくさん扱ってるけど、Windowsでのサンドボックス化の選択肢は本当に乏しいんだ。サポートする予定はある？
└
これ、めっちゃクールだね！AIのサンドボックスソリューションのためにこういう技術を調べてたんだけど、Lima+Incusにたどり着いたよ。 https://github.com/JanPokorny/locki マイクロVMの問題は、通常DockerやKubernetesが動かないことなんだ。Kubernetesクラスター全体で構成されるアプリを扱ってるから、そのサンドボックスにはそれを全部含めたいんだ。君のソリューションは、例えばk3sを動かすことができるの？
└
ライブマイグレーションのサポート状況はどうなってるの？似たようなシステムでいつも抜け落ちる機能だよね。理由はわかるけど、「クラウドネイティブ」なワークロードには優先順位が低いんだよね。でも、世の中にはクラウドネイティブじゃないワークロードもあって、それは高コストがかかるし、これからもそうだと思う。だから、もしマイクロVMプラットフォームに本当に価値を加える差別化要素が欲しいなら、これだよ。それ以外はかなり魅力的に見えるね。
└
このコードの何パーセントがLLM/AIによって書かれたの？
└
VMを設計してサブセカンドの起動時間を実現する上での最大の課題は何だった？さらに起動時間を短縮するための現在のボトルネックは何？
比較表、すごく良くできてるね！最初に「お、ファイアクラッカーみたいだな」って思ったけど、表を見てどこが似ててどこが違うのか確認できた。簡単だね！いい仕事してる！これ、めっちゃクールだよ。
└
ありがとう！
自己完結型のバイナリを作成できる機能は、GraalVM NativeよりもJVMアプリをパッケージする簡単な方法になりそうだね。他にも面白いユースケースがたくさんありそう。 smolvm pack create --image python:3.12-alpine -o ./python312 ./python312 run -- python3 --version # Python 3.12.x — 隔離されてて、pyenv/venv/condaは不要
└
そうだね、Electronに似てる。Electronはウェブアプリをブラウザと一緒にバンドルして出荷するけど、Smol machinesはソフトウェアをLinuxのVMと一緒にパッケージして出荷するんだ。依存関係の管理や互換性の問題がないから、すべてが組み込まれてる。正直、CodexやClaude Codeもデフォルトでこうやって出荷すれば、孤立の問題を避けられると思う。
└
そうだよね、みんな「開発環境をめちゃくちゃにしちゃった」って経験あるよね？この「マシン」は、正しく設定できたら誰でもすぐに使えるようにしたいんだ。
smolvmは最高だね。チームはすごく反応が早くて、経験豊富だし、明らかに何をしてるか分かってる。今、自分のプロジェクトでsmolvmを評価中なんだけど、https://withcave.aiで隔離のためにIncusを使ってるんだ。初期の統合結果はすごく期待できそうだよ！
└
本当にありがとう！一緒に協力して、Caveをもっと簡単にできる方法を見つけよう！
└
これ、めっちゃすごいね！オープンソース化する可能性があるのが楽しみ。特定のユースケースに合わせてカスタマイズしたり拡張したいから。smolvmと実際の使用についてだけど、smolvmがうまく機能しても、/dev/kvmにアクセスできないVMでCaveを使いたい人のために、incusを選択肢として残しておいてもいいんじゃないかな（ユーザーはCaveのデプロイ時にincusかsmolvmを選べるように）。
.smolmachineはデジタル署名されて、実行時に自己認証できるのかな？https://docs.sylabs.io/guides/main/user-guide/signNverify.ht...に似た感じで。
https://github.com/CelestoAI/SmolVMと同じ目的で、同じ名前の関係があるの？
└
関係ないけど、彼らはFirecrackerを使ってサンドボックスサービスを作ってるよ。俺はFirecrackerやコンテナの代わりになる仮想マシンを作ってるんだ。
これはすごくワクワクするね。プラットフォームを超えた、言語に依存しないプラグインシステムを実現できるし、特にエージェントにとっては安全にVM内で動作するんだ。
これ、めっちゃ面白いね！ベンチマークとか、強いアイソレーションが必要なところで使ってみたいな。Dockerはちょっと重すぎて遅いからね。でも、残念ながら自分のWindowsノートではこれをネイティブで動かせないと思う。WSLにも対応してくれるといいな！頑張って、ローンチおめでとう！
└
フィードバックありがとう！ぜひ試してみて、感想教えてね。ディスコードもあるから、参加したいならどうぞ。GitHubでもディスコードでも、何か問題があったら気軽に報告してね。よろしく！
コンテナのいいところは、リソース（例えばRAM制限）を指定しなくてもすぐに立ち上げられることなんだよね。これもそうできるといいな。
CLIドキュメントにalpineとpython:3.12-alpineのイメージがあるね。これらはどこから来てるの？Dockerみたいなレジストリから？それとも内蔵されてるの？自分のイメージを作成することはできるの？それともsmolfileだけで完結してるの？Ubuntuのイメージはあるのかな？見た目もすごくいいね。メモリやCPUのホットリサイズもできるといいな。これ、顧客ごとにバックエンドを持つインフラオーケストレーターとしていい技術になりそうだね。