
2026/06/26 6:22
Proxmox から NixOS と Incus へ移行する
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
著者は、マルチノードの Proxmox クラスターを正式に廃止し、すべてを Incus を動作させる NixOS に移行しました。この移行は、テキストベースの管理への懐疑から、脆弱な GUI ではなく検証可能なファイルを通じてシステムの状態を定義する宣言的パラダイムへ受け入れる転換を象徴します。本移行は、Proxmox の GUI 優先アプローチにおける「状態のドリフト」と AI エージェントに向かない性質が推進要因であり、これに NixOS の原子更新とテキスト定義が対比されています。
具体的な技術的な課題、例えば、 imperative な NVIDIA ドライバーの更新後、atomic な NixOS 更新によって GRUB ブートループを解消し(新規ディスクインストールで同一のリカバリが可能)、systemd オーバーライドを用いて Intel I219-LM ネットワークカードの恒常的なハードウェアハングを修正したことなどが、この手法が imperative コマンドに対する優位性を示しました。移行プロセスでは、
vzdump を用いて LXC コンテナをダンプし、qemu-img convert を用いて VM ディスク形式を変換(ZFS/LVM-thin から QCOW2)することで、Incus へのインポートを行いました。物理的な移動以前に、仮想の NixOS マシンを用いて完全な物理セットアップを再現し、物理的な Proxmox ホストを消去して再構築する前に構成を検証しました。
今後の管理は、
flake.nix といった構成ファイルを読み取るエージェント型 AI ツールによって直接行われます。これはシステムの構築指示を含むものであり、ホスト全体を改変しても壊れることの恐れがありません(例:networking.firewall.allowedTCPPorts を追加)。これにより、git ベースのワークフローを通じた継続的な進化が可能になります。著者は NixOS ホスト上だけで Kodi を直接実行しており、native ハードウェアアクセラレーションを利用しながら同時にバックグラウンドで Incus コンテナ/VM を動作させています。Proxmox/TrueNAS アプライアンスでは任意のコマンドの使用が抑止される一方、NixOS はその宣言的な状態によりホストの完全な改変を可能にします。
究極的に言えば、この移行はユーザーおよび AI エージェントが不透明な Web UI ボタンをクリックする代わりに、読みやすいテキストを用いて複雑な環境を管理することを可能にします。移行ノートとスクリプト(
migrate-lxc.sh、migrate-vm.sh)は、著者の dotfiles リポジトリ内に flake.nix や networking.nix といった構成ファイルと共に保存されています。8 台以上のマシンのための entire 構成は単一の git リポジトリによって管理され、ほとんどのリファクタリングはエージェント型 AI ツールによって行われています。本文
Proxmops から NixOS と Incus への完全移行:懐疑論者から信者へ
数年间、単一の NUC から始まって多ノードクラスターへと拡張してきたホームラボを、完全に NixOS と Incus (インクサス) 環境へ統合・移行しました。Proxmops クラスターも同時に退役させました。
懐疑論者から信者への変容
私はニックスの信奉者になる予定ではありませんでした。当初は言語や構文を嫌い、独自のドットファイル設定(
dotbot や自作ツール dotbins)でシステムを管理していました。
しかし、Mac 上での
使用経験を経て、真の転換はゲーミング PC の購入時に行われました。nix-darwin
- Windows を避けつつゲームをしたいと思い Pop!_OS を採用しましたが、NVIDIA ドライバ問題に直面しました。
- ランダムな impérative コマンドによる修正は復元不可能で、根本解決になりませんでした。
- 間違ったドライバ更新により GRUB ブートループ(破滅)に陥った際、**「原子更新」**という特性を求めて NixOS を導入しました。
移行の驚異: ディスクをクローンせず、設定のみ適用して新規インストールすると、ブート直後からデータまで完全に同一状態となりました。
impérative システムの摩擦点
Proxmops は優秀ですが、GUI 第一・クリック中心のパラダイムに依存しています。自動化ツールとの整合性やステートドリフト(状態の不一致)が現実的な課題です。
- AI エージェントとの相性: 「YOLO モード」のエージェントは、再現不能な未定義状態を作り出してしまいます。
具体的な摩擦事例:
-
ネットワーク設定の手動管理
- HP EliteDesk (Intel I219-LM) でハードウェアオフロードを有効にするとハングする問題がありました。
- NixOS では
と文書化されたコメント (systemd サービス
) を定義し、再インストール時にも自動的に修復されました。tso off gso off - Proxmops ではこの復旧を毎回手動で行う必要がありましたが、NixOS にはその手間がありません。
-
メディア中心とサーバーの両立 (HTPC vs サーバー)
- Proxmops: GPU パススルーは必須ですが、これによりホスト側が GPU にアクセスできず、トラブル時のローカルコンソール利用が不可能になります。二者択一(メディアプレイヤーかデバッグ可能なハイパーバイザーか)でした。
- NixOS + Incus: ホスト OS が Kodi を直接実行しネイティブなハードウェアアクセラレーションを提供しつつ、バックグラウンドで Incus がコンテナをホストします。ヘッドレスホスト制限なしです。
-
哲学の違い:アプライアンス vs オーナーシップ
- Proxmops/TrueNAS はアプライアンス設計であり、ミドルウェアの変更は推奨されません(ステートが失われるリスク)。
- NixOS ではホスト OS を完全に所有でき、Kodi やネットワークドライバーの調整、ローカル LLM 実行も可能です。
- ステートは宣言的であり、100% 明瞭で再現可能。構成破損時は数秒以内に動作可能な状態に戻せます。
エージェントの増幅効果
AI エージェントがタスクを遂行する世界では、CLI 第一・宣言的システムが不可欠です。
- Web UI のボタンクリックは信頼できません。テキストによる決定論が必要です。
- インフラストラクチャとしてのコード化: AI がインフラを読み取り、安全に変更を加えるためにテキストファイルでの定義が必須です。
NixOS の利点:
- オープンブック(透明性)。例:「9000 ポートで Faster Whisper API を公開」するには、GUI ナビゲーション不要。
とsystemd サービス
の追加で済み、networking.firewall.allowedTCPPorts = [ 9000 ];
で変更確認が可能です。git diff - AI に 의한 リファクタリング: 単一マシンから 8 マシンまでを拡張しましたが、構成の大部分は AI エージェントが作成・整理しました。共通モジュールを共有しつつ個別性を保つ再構築を実現しています。
アーキテクチャ:Incus とシミュレーション
堅牢なハイパーバイザーとして、NixOS の管理機能とレガシーワークロード(旧 Ubuntu コンテナなど)の両方をカバーする Incus (LXD コミュニティフォーク) を採用しました。
- Docker Compose 移行: DNS やメディアマネージャなどのサービスは、VM 内の宣言的 Docker Compose ファイルへ移行済みです。
- Home Assistant の解決策: Proxmops のアプライアンス OS が必要だと思いましたが、Incus が NixOS に搭載されているため、QEMU プロセスとして VM で実行し、コンテナ同様にクリーンに管理可能でした。
核破壊への恐怖を克服: Proxmops ホスト終了前に、物理マシンの構成を正確に複製する Incus VM を作成・検証しました。オーバーライド用小ファイルの導入だけで、移行前の動作を保証できました。
移行プロセス
vzdump と qemu-img を活用し、7 年以上のデジタル歴史を失うことなく移行を実行しました。
1. LXC コンテナの移行
コンテナを「テレポート」させました。Proxmops でタールアーカイブ化し、新しいインクサスコンテナにストリーム投入します。
Proxmops 上 (ダンプ作成):
vzdump 101 --dumpdir /var/lib/vz/dump --mode suspend --compress zstd
NixOS 上 (自作スクリプト使用):
./migrate-lxc.sh vzdump-lxc-101-*.tar.zst ubuntu-container
- スクリプトは UID マッピングや machine-id の修正など、混乱する部分を自動処理します。
2. 仮想マシンの移行
ディスク形式の統一(LVM-thin/ZFS zvols から QCOW2)を行いました。
Proxmops 上 (変換):
qemu-img convert -p -O qcow2 /dev/zvol/rpool/data/vm-100-disk-0 vm-100.qcow2
NixOS 上 (インポート):
./migrate-vm.sh vm-100.qcow2 home-assistant
結果と構成
現在はホスト OS、ネットワーク、ストレージ、ハイパーバイザーのすべてを単一の git リポジトリで管理しています。
- 良い部分の融合: 必要な場所に永続的なサービス × 再現可能でバットプルーフなホスト OS。
- ロールバック能力: ホスト消去と再インストールにより数分以内にオンライン復帰可能(チェックボックス記憶不要)。
- エージェントとの相性: 全てがコードであるため、AI エージェントが管理を助けてくれます。
リファレンスと構成ファイル
以下の構成ファイルを GitHub リポジトリで確認できます。
| ファイル名 | 用途 |
|---|---|
| PC, NUC, HP の Fleet を定義するエントリーポイント |
| Intel I219-LM ネットワークハングの宣言的修復 (Tso/Gso オフ) |
| NUC HTPC 用 Kodi 直接実行構成 |
| Faster Whisper API の宣言的サービス定義 |
| Incus VM 内の物理マシンシミュレーション・オーバーライド |
| Proxmops vzdump アーカイブをインクサスへ移行するスクリプト |
| QCOW2 イメージをインクサス VM へ移行するスクリプト |
| 移行の詳細なノートと在庫リスト |