概要
HITSC / hitto Troubleshooting Contest は、Firecracker microVM 上に Linux の障害対応問題環境を用意するための検証用基盤。
現時点では公開コンテストとして稼働しているものではなく、1 worker VM 内で問題環境の発行、起動、採点、reset、cleanup を扱う MVP として開発している。
問題テンプレートである problem.yaml と rootfs.base.ext4 をもとに、ticket ごとに専用の Firecracker microVM を起動する。参加者は SSH で guest に入り、問題を修復し、外部の check.sh によって自動採点される想定。
できること
problem.yamlを読み込み、単一 VM / 複数 VM の問題定義を扱う- ticket ごとに rootfs を provision し、Firecracker microVM を起動する
- 単一 VM 問題では ticket ごとに network namespace と TAP を作る
- 複数 VM 問題では ticket namespace 内に bridge / TAP を作り、複数 node を接続する
ticket start / ssh / score / reset / stop / destroyなどの CLI 操作を提供する- SQLite と
state.jsonに ticket / instance / score attempt の状態を保存する check.shによる外部採点を行う- rootfs の full copy / reflink clone / snapshot restore を比較できる
技術的な見どころ
worker 上で Firecracker を直接管理するため、実装は Go の単一バイナリを基本にしている。
Firecracker API socket 経由で machine config、boot source、drive、network interface を投入し、InstanceStart で microVM を起動する。通常起動用の DirectFirecrackerRuntime に加え、実験用に snapshot restore backend も用意している。
network は ticket ごとに Linux network namespace を分ける。単一 VM では namespace 内に TAP を 1 つ作り、複数 VM では network ごとの bridge と node/interface ごとの TAP を作る。これにより、複数 ticket で同じ guest IP / host IP を安全に再利用できる。
rootfs provisioning では、互換用の current、明示的な full copy 用の copy、CoW 必須の reflink backend を分けている。reflink を使うことで、ticket ごとの rootfs を高速に作りつつ、実データ block の大部分を base rootfs と共有できる。
snapshot restore では、起動済み VM から Firecracker snapshot を作成し、同じ snapshot memory file から複数 VM を restore する。PSS を使った検証では、Memory CoW による page sharing の効果も確認している。
推したいポイント
一番大事にしているのは、コンテナだけでは再現しにくい Linux サーバの壊れ方を、実 VM に近い形で扱えること。
systemd、sshd、networkd、iptables、Docker、複数 NIC、複数 VM 間の通信などを、Firecracker microVM の中でそのまま問題化できる。参加者は SSH で入って普通の Linux サーバとして調査するので、練習環境としての手触りが現実に近い。その上で、VM 展開の高速化や worker 資源効率の改善にも取り組み、実 VM に近い問題環境を気軽に扱える基盤にしたい。
もう一つ面白いのは、ticket ごとに network namespace を分けて、同じ問題・同じ IP アドレス帯を何度も安全に発行できるところ。単一 VM 問題だけでなく、server / client1 / client2 のような複数 VM 問題も、ticket namespace 内の bridge と TAP で閉じた topology として作れる。
HITSC では、問題環境は長期運用する VM ではなく、ticket ごとに何度も発行・破棄・再発行される消耗品である。そのため、VM 展開が遅い・重いと、練習体験、並列性、reset 運用、worker 資源効率のすべてが悪化する。
だから、Storage CoW と Memory CoW は単なる最適化ではなく、HITSC を「気軽に何度も問題環境を作れる基盤」にするために必要な機能だと考えている。rootfs は reflink clone で Storage CoW を使い、snapshot restore では同じ snapshot memory file 由来の page sharing を PSS で観測できた。実 VM に近い問題環境を扱いながら、発行コストを下げられるのがこの基盤の強みだと思っている。
問題作者側の体験もできるだけ単純にしたい。問題作者は problem.yaml と rootfs.base.ext4、必要なら build.sh / check.sh を用意する。worker 側はそれを ticket として発行し、起動・SSH・採点・reset・cleanup を CLI で扱う。将来的には Ansible 対応や rootfs template 作成支援も入れて、作問者が問題の中身に集中できるようにしたい。
関連ログ(2026-06-03 時点)
- Firecracker 上の Ubuntu 24.04 で Docker を動かすまでに詰まったこと
- Firecracker rootfs の Storage CoW を reflink で検証した
- Firecracker snapshot restore で Memory CoW の効果を PSS で確認した
- Firecracker snapshot clone 後の一意性をどう戻すか考える