IncusをVMware代替として評価する — 機能表より先に移行条件を揃える

結論 — 比較するのは機能の数ではなく，運用責務

VMwareから別の仮想化基盤へ移行するとき，最初に確認したくなるのは機能表です．HAはあるか，ライブマイグレーションはできるか，Web UIや複数ホストの一元管理はあるか．いずれも必要な確認ですが，それだけでは移行を判断できません．

現在VMwareに任せている責務は何か．移行後，その責務を誰が，どの仕組みで担うのか．

ここを決めないまま製品を選ぶと，機能は揃っていても運用できない，ライセンス費用は下がっても復旧リスクが増える，という結果になりかねません．

CoRISEがIncusに注目するのは，NixOS，監視，バックアップ，自動化と組み合わせ，仮想化基盤を再現・検証・改善できるシステムとして構成できるためです．顧客自身にその開発・運用能力を求めるのではなく，専門組織が運用責任を引き受ける運用支援付きのインフラ基盤としての採用も含めて考えます．

本稿では評価軸を整理し，3ノードのIncusクラスターを使う参照構成と試験計画を示します．以下は採用判断のための設計案であり，実測済みのHA性能や移行実績の報告ではありません．

背景 — VMwareに何を任せているか

vSAN，NSX，VCFを深く利用する環境と，VMの実行・保守・復旧が中心の環境では，移行の難所が異なります．まず製品名から離れ，業務が必要とする責務を棚卸しします．

事業会社が必要とするのは，仮想化基盤を内製開発すること自体ではありません．業務システムを安定して動かす基盤と，その状態を維持する運用体制です．評価の単位も，ハイパーバイザー単体ではなく，ストレージやバックアップ，担当組織を含む運用モデルに置きます．

VMware，Proxmox，Incus，クラウド基盤の違い

Incusは，Linux上でシステムコンテナと仮想マシンを管理するOSSです．クラスター，ストレージ，ネットワーク，プロジェクト，API，配置制御などの構成要素を持ち，複数ホストをCLIやREST APIで管理できます．「無料のESXi」と捉えるより，仮想化基盤を組み立てるための構成要素として理解する方が，採用条件を整理しやすくなります．

Proxmox VEは，KVMとLXCに加え，Web UI，クラスター，HA，ストレージ，ネットワーク，バックアップやAPIを統合しており，VMwareからの自然な移行候補の一つです．顧客自身がGUIを使って管理したい場合や，機能を一つのプラットフォームとして扱いたい場合には合理的です．

2026年5月21日公開のProxmox VE 9.2では，Dynamic Load Balancerも追加されています．HA管理下のゲストを，ノードとゲストの実際のリソース利用状況やHAルールを考慮して自動移動できます．「動的な負荷分散がない」という古い比較をそのまま採用してはいけません．[1]

OpenStackやCloudStackは，計算資源だけでなくID，ネットワーク，ストレージなどを束ねるクラウド基盤です．必要なテナント分離やセルフサービスが明確なら有力ですが，数台から数十台のVMを管理する目的に対しては，コントロールプレーンの運用が過大になる場合もあります．台数だけで決めず，利用者へ提供するAPIと責務から判断します．

Incusを選ぶ理由と，引き受ける責任

Incusでは，VMとシステムコンテナを同じ管理モデルで扱い，REST APIを使って周辺の仕組みと接続できます．自動配置やクラスターの負荷再配分に加え，Placement Scriptletによって，インスタンスや配置候補，配置理由を考慮する独自ロジックも記述できます．[2][3]

これは，IncusがvSphere DRSより高度であるという意味ではありません．要件に合わせた制御を設計する余地があり，その分だけ設計・検証・保守の責任も増えるということです．

例えば，標準の配置制御に加え，CPU・メモリ圧迫，ストレージ遅延，ネットワーク帯域，ワークロードの優先度，障害境界，アプリケーションのSLOを参照する制御を考えられます．ただし，それはIncus，観測基盤，独自の自動化処理を組み合わせる開発です．Incus標準機能だけで，これらすべてを最適化できるとは扱いません．

顧客自身がLinuxやIncusの専門家である必要はありません．その責任をMSPが引き受けるなら，顧客は処理能力・容量の変更，保守，バックアップ，障害対応を含む運用支援付きの仮想化基盤を利用する形になります．必要なのは，その責任を曖昧にしないことです．

OpenTofu，NixOS，Incusの責務を分ける

CoRISEではIaCの標準としてOpenTofuを利用しますが，すべてを一つのツールに押し込むことはしません．この参照構成では，次のように分担します．

NixOSを使う目的は，ハイパーバイザーホストを再現可能な構成として扱うことです．構成をGitで管理し，変更をレビューし，同じ条件のホストへ再適用できるようにします．Incusを使うためにNixOSが必須という意味ではありません．

クラスターの初期構築，参加トークン，メンバー構成，実行中の配置は稼働中の状態です．配置方針を宣言的に管理する余地はありますが，動的な状態や秘密情報をFlakeへ直接固定することとは分けます．トークンや鍵は秘密管理の仕組みで扱い，発行・失効・再参加の手順を運用側に持たせます．

3ノードの参照構成

PoCでは，VMを1台起動するだけでなく，クォーラム，計画退避，障害復旧，ストレージ，フェンシング，監視，ホスト再構築を検証します．3台はIncusの仮想マシンを実行するクラスターメンバーの数であり，ストレージや監視も含む全システムが3台で完結するという意味ではありません．

Incusの分散データベースはRaftで状態を複製します．3メンバーであれば，1台を失っても残り2台でクォーラムを維持できる構成を取れます．公式資料は高可用なクラスターに最低3メンバーを求め，メンバー間の遅延は10ms以下としています．時刻同期も必要です．[2]

ただし，コントロールプレーンのクォーラムが残ることと，VMが復旧することは別です．VMの再起動には，データへのアクセス，CPU・デバイスの互換性，残存ノードの余力，ネットワーク接続，旧インスタンスの停止確認が必要です．

共有ストレージ自身や管理ネットワークが単一障害点であれば，計算ノードが3台あっても基盤全体のHAにはなりません．障害時に監視やフェンシングを動かせるよう，それらの依存先も確認します．

ホスト構成をFlakeで揃える

共通モジュールにホストの方針を置き，インターフェースやディスクなどの差分を各ホストへ分離します．

incus-cluster/
├── flake.nix
├── flake.lock
├── modules/
│   └── incus-host.nix
└── hosts/
    ├── incus-01.nix
    ├── incus-02.nix
    └── incus-03.nix

flake.nixの構造例は次のとおりです．flake.lockを管理し，更新時には入力リビジョンとIncusの実際のバージョンを記録します．ブランチ名の指定だけでは，取得するパッケージの版は固定されません．

{
  description = "Three-node Incus cluster reference configuration";

  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05";

  outputs = { nixpkgs, ... }: {
    nixosConfigurations = builtins.listToAttrs (
      map
        (host: {
          name = host;
          value = nixpkgs.lib.nixosSystem {
            system = "x86_64-linux";
            modules = [
              ./modules/incus-host.nix
              ./hosts/${host}.nix
            ];
          };
        })
        [ "incus-01" "incus-02" "incus-03" ]
    );
  };
}

共通モジュールの出発点は以下のようになります．NixOSにはIncusを有効化するvirtualisation.incus.enableがあり，Incusと組み合わせるファイアウォールはnftablesを前提に構成します．[6]

{ pkgs, ... }:

{
  virtualisation.incus.enable = true;
  networking.nftables.enable = true;

  services.prometheus.exporters.node.enable = true;

  environment.systemPackages = with pkgs; [
    incus
    jq
  ];
}

これはホスト方針を示す断片であり，そのまま起動・運用できる完成設定ではありません．ホスト名，起動設定，ファイルシステム，ハードウェア構成，system.stateVersion，管理IP，ボンディング / VLAN，ファイアウォールの許可元，ストレージクライアント，TLS，SSHなどを別途定義します．監視エクスポーターを有効にすることも，収集経路やアラートを設定することとは別です．

また，NixOSで以前のシステム世代（システム Generation）を選べても，Incusのデータベーススキーマやゲストのデータが元に戻るわけではありません．ホスト構成のロールバックと，状態を持つサービスの復旧は別々に試験します．

HAパラメータは復旧時間の保証ではない

以下をPoCの確認表とします．既定値と実験のために選ぶ値を区別し，導入する版の資料と実際の設定値を照合します．[4]

60秒はRTOでも，安全性を保証する推奨値でもありません．実際の復旧時間には，障害検知，フェンシング，退避先の決定，VM起動，アプリケーションの整合性確認が含まれます．再起動の安全条件が成立するまでは，自動復旧を無効のまま評価します．

共有ストレージとフェンシングを一緒に設計する

Incusのクラスター自動復旧は，共有ストレージにあり，ローカルデバイスを利用しないインスタンスが対象です．ホスト内のローカルストレージにしかないVMディスクを，障害後に別ホストからそのまま利用することはできません．[3]

VMの共有ディスク候補として，この参照構成ではCeph RBDを例示します．LINSTORやTrueNASを含む対応バックエンドの採否は，版，ボリューム種別，接続方式，ドライバーの制約を確認して決めます．CephFSも対応ドライバーですが，Ceph RBDと同じVMのブロックストレージとして一括りにはできません．[7]

共有ディスクへ複数ホストから到達できることは，HAの必要条件の一つに過ぎません．通信断で見えなくなった旧ホスト上のVMが実際には動き続けていれば，別ホストで同じVMを起動することで二重書き込みが起こり得ます．

電源断とストレージ側の遮断を重ね，採用した復旧方針の安全条件を確認してから起動を許可します．図の二つの遮断経路は，いずれかの要求が成功すれば十分という意味ではありません．成立条件は次節で分けて整理します．

これは参照構成として実現・検証すべき順序であり，Incus標準の復旧がこの処理をすべて保証するという意味ではありません．公式資料はcluster-member-healedイベントを監視し，BMCやPDUで対象ホストの電源を切る方法を挙げていますが，イベントを受けて電源遮断を要求しただけでは，別ホストでの起動より前に遮断が完了した証拠にはなりません．[3]

必要な順序保証とインターロックを外部制御で実現できるか，遮断失敗時に復旧を停止できるかを試験します．これを確認できない段階では，手動でフェンシング完了を確認してから復旧する運用を選びます．

HAとバックアップも代替関係ではありません．共有ストレージ全体の故障や，論理破壊，認証情報の侵害に備え，別の復旧領域へ保管し，復元試験を行います．

電源断とI/Oフェンシングを，異なる範囲の遮断として重ねる

BMC / PDUによる電源断は，旧ホスト上の処理全体を停止する手段です．Ceph RBDを使う場合は，これにストレージ側で旧クライアントのI/Oを拒否する手段を組み合わせられます．ただし，二つの手段は保護範囲も依存先も異なり，どちらかへ要求を送れたことだけでは復旧を許可できません．

Cephのexclusive-lockは，RBDクライアント間の排他制御を提供します．通常の受け渡しができず，旧クライアントのロックを破棄して引き継ぐ場合，Cephは旧クライアントをブロックリストへ登録し，関連するOSDマップの更新後にロックの引き継ぎと新クライアントの書き込みへ進む仕組みを持ちます．これはストレージ層のフェンシングです．ブロックリストを操作する権限も必要です．[8]

一方，exclusive-lockを有効にするだけでは，二重起動を防げません． Cephの公式資料は，既定ではクライアント間でロックを協調的に受け渡し，二つのクライアントが同じイメージへ交互に書き込めると明記しています．その瞬間のロック所有者が一つであることと，一つのVMだけが継続して書き込めることは別です．[8]

ceph osd blocklistはこの遮断を扱う手段の一つですが，手動コマンドの成功だけをもってフェンシング完了とはしません．採用するIncus，QEMU，librbdまたはkrbdの構成で，イメージの機能，実際のロック方式，旧クライアントの識別，遮断の反映と引き継ぎ順序を確認します．複数のVMディスクや書き込み可能な補助ボリュームがあれば，対象全体を扱います．

ブロックリストは，旧ホストの電源断やCephの認証情報そのものの失効とは異なります．有効期限切れ，別のクライアント識別子での再接続，旧ホストの再参加によって書き込み経路が復活しないかを確認し，復旧中は旧ホストを隔離します．同じホスト上の別VMに影響する範囲も記録します．外部DBへの更新やネットワーク送信など，RBD外の副作用はこの遮断だけでは停止できません．

したがって，BMC経路が停止していても，I/O遮断で対象ディスクを保護できる構成は設計できますが，無条件にVMの自動再起動へ進めるわけではありません． Ceph MONのクォーラム，OSDへの経路，必要な権限，旧クライアントを再び許可しない仕組みが残り，ストレージ以外の副作用も管理できることを，代替復旧の受入条件にします．成立を確認できなければ復旧を保留します．

Pacemakerは，複数のフェンシング手段を代替経路として使う構成と，複数手段の成功をすべて要求する構成の両方を扱います．[9] この考え方は参考になりますが，Incusへ同じ制御が自動的に追加されるわけではありません．BMCとCephのネットワーク，電源，認証情報を含めて共通障害を評価し，どの遮断結果の組み合わせで復旧を許すかを明文化します．

OVNを使うなら，ネットワーク制御面のクォーラムを別に評価する

OVNのマネージドネットワークを採用すると，Incusのデータベースに加え，OVN Northbound DBとSouthbound DBの運用が必要になります．これらをOVSDBのクラスター方式で構成した場合，NBとSBはそれぞれ独立したRaftクラスターです．Incusのクォーラムと共有されるものではありません．OVNには単一サーバー構成もあり，Incusを3ノードにしただけでNB / SBまで高可用になるわけではありません．[10][11]

例えばNBとSBをそれぞれ3メンバーで構成すれば，各クラスターは1メンバーの喪失を許容できます．ただし，同じ3台へIncus DB，NB，SBを同居させれば，独立した論理クォーラムが同じ物理障害を受けます．投票数の表だけで独立性を判断せず，配置，電源，ネットワーク，ディスクの依存を重ねて確認します．

OVNの制御面が停止しても，既に設定された転送処理で通信が続く場合があります．それは，新しいポートの作成，移行先への反映，ACL変更，ゲートウェイ切り替えも成功するという意味ではありません．既存通信の継続と，構成変更・移行後の通信回復を別々の受入条件にします．

NB / SBのバックアップ，OVSDBのスキーマ更新，ovn-northd，各ホストのOVN / Open vSwitch更新は，Incusの更新とは別の手順です．データベースの冗長化だけでは不足し，TLS，接続先の切り替え，監視，復元順序まで含めて評価します．[10][11]

管理APIの認証・認可・失効を，HAと並ぶ基盤要件にする

管理APIを侵害されれば，VMの停止・削除だけでなく，コンソールやファイルへのアクセス，スナップショットの取得，信頼する証明書やネットワークの変更まで影響が広がります．管理権限の一部はホストのroot権限相当として扱う必要があります．基盤が止まらないことと，基盤を乗っ取られないことを，同じ受入表で評価します．

IncusはTLSクライアント証明書による相互認証とOIDCに対応します．本参照構成では，運用者はIdP側のMFA等を組み合わせたOIDC，自動化処理は用途ごとに分けたTLSクライアント証明書を候補にします．管理APIは管理ネットワークや制御された接続経路へ限定し，メトリクス収集用の認証情報と分離します．[12]

認証が成功しても，何を操作できるかは別です．OIDCを有効にするだけでIdPの役割がIncusの最小権限へ対応するわけではなく，公式資料は認可を構成しなければ広い権限を与えることを警告しています．OpenFGAを使う場合は，プロジェクトとインスタンスを単位に，閲覧，操作，構成変更，権限管理を分けて評価します．プロジェクト側の制限も併用します．[12][13]

ここは版の違いにも注意が必要です．Incus 7.0.0の資料ではopenfga.*とTLSクライアント固有の認可経路が説明されています．一方，現行の開発系列の資料にはauthorization.openfga.*とauthorization.client.*による経路選択があります．接続設定を置いただけで，すべての認証方式がOpenFGAを通るとは扱いません． 採用版で，OIDC，制限付きTLS，無制限TLS，Unixソケットのそれぞれに適用される認可を確認します．異なる版の設定を混在させないことが重要です．[13][14]

TLSの信頼を削除する操作はincus config trust removeですが，失効完了の評価はコマンドの成功だけで終えません．OIDCのトークンが即時に使えなくなるかも，発行元とIncus側の検証方法に依存します．新規要求，キャッシュ済みの認可，既存接続，進行中の操作を分けて測定します．[12]

OpenFGAを採用すれば，そのサービスと永続データも可用性・復旧の依存先になります．認可基盤が停止したときに認可を迂回しないことと，管理者が監査可能な緊急経路で復旧できることを両立させます．ローカルrootやincus-adminなどの強い権限，BMCの認証情報，Cephの鍵も同じ脅威モデルへ含めます．監査記録には主体，対象，操作，判定，時刻を残し，秘密鍵やトークン本文は記録しません．

復旧のインターロックを，安全性不変条件として検討する

障害注入の前に，復旧制御をTLA+で小さな状態遷移モデルへ落とすことも検討できます．ここで守りたい条件は，「同じVMの二つの実行個体が，同時に書き込み可能な状態にならない」です．別ホストだけでなく，同じホストで誤って二重起動した場合も対象にします．

VM $v$ の実行個体の集合を $I_v$，保護対象へ書き込める状態を $\mathrm{MayWrite}(i)$ とすると，不変条件の候補は次のように書けます．

MayWriteは，その瞬間にRBDロックを持っていることだけではありません．解放されたロックを再取得して書き込みを再開できる旧実行個体も含め，遮断と再参加の制御が実際に制限する能力として定義します．複数ディスクの権限が新旧の実行個体へ分かれる状態も許さない設計にします．

復旧試行の世代とクライアント識別子を対応付け，遮断の証拠を別の試行へ使い回さず，起動許可を永続化・直列化する方針をモデルへ反映します．安全条件を遷移の前提へ書くだけで終えず，その条件を観測・確認できる手順自体をモデル化します．

安全性と「いつか復旧できる」という進行性も分けます．すべての遮断経路が失われた場合に停止を続けるのは，安全を優先した結果です．復旧の進行性を調べるなら，通信や遮断手段が最終的に回復するなどの仮定を明記します．

TLCで有限の構成を探索すれば，条件を破る反例の探索に使えます．[15] ただし，本稿ではモデルやモデル検査結果をまだ提示していません．モデルの規模と仮定を固定して検査し，得られた反例をPoCの障害シナリオへ移す，という提案です．反例が見つからないことだけでは，実装，Cephの挙動，物理的な電源断，侵害された管理者まで保証できません．

障害領域とライブマイグレーションの条件

3台が同じラック，スイッチ，PDU，電源系統に依存していれば，共通障害でまとめて失われます．物理構成の障害境界を明らかにし，ストレージやフェンシング用ネットワークも含めて対応付けます．

Incusのfailure_domainは，データベースの役割の再割り当て時の選好などに使われる設定です．ラック名を付けるだけでVMの分散配置や電源系統の独立性が実現するわけではありません． ワークロードの分離条件は，クラスターグループや配置方針と合わせて別途設計します．[2]

ライブマイグレーションでは，退避先のCPUが移動元のVMに公開しているCPU機能を扱える必要があります．Incusはクラスター内のCPU機能からベースラインの計算を試みますが，世代やベンダーが混在するすべての環境を保証するものではありません．公式資料も混在環境ではプラットフォームごとのクラスターグループを推奨しています．[2]

PoCではCPUだけでなく，パススルーなどのローカルデバイス，VM設定，ストレージ / ネットワーク帯域，実際のワークロードを含めて確認します．「同一世代を揃える」は試験を単純化する方針であり，互換性試験の代わりではありません．

観測してから負荷再配分を有効にする

IncusはOpenMetrics形式でホストやインスタンスの指標を公開します．クラスターでは各メンバーがそのメンバー上の指標を返すため，Prometheusは各ノードから個別に指標を収集します．VMの指標には，ゲストエージェントなどの条件に依存するものもあります．[5]

8444はこの例で選ぶポートです．core.https_addressとcore.metrics_addressを分け，メトリクス専用の証明書とファイアウォールの許可元を設定します．専用ポートを設けただけで安全になるわけではありません．監視基盤そのものが停止した場合の検知経路も用意します．

Incusの負荷再配分には，cluster.rebalance.batch，cooldown，interval，thresholdがあります．負荷差を基に，安全にライブマイグレーションできるVMを低負荷のメンバーへ移す機能です．intervalの既定値は0で，自動負荷再配分は無効です．[3][4]

導入は「観測 → ワークロードの理解 → 許容する不均衡の定義 → 有効化 → 影響測定」の順に進めます．移行による帯域消費やストレージ遅延，アプリケーションの応答，往復移動を起こす制御の振動も測ります．Placement Scriptletを追加する場合は，対象バージョンでの呼び出し条件と失敗時の挙動まで検証します．

PoCでは「壊して戻せるか」を測る

試験開始前に，許容停止時間，RTO / RPO，データ整合性，操作担当者を決めます．VMwareからの移行では，ゲストOS，ディスク形式，ドライバー，ファームウェア，IP / MAC，ライセンス，バックアップ製品，逆戻り手順も評価表に含めます．変換して起動できたことと，業務として受け入れられることを分けます．

Incusクラスターの更新では，全メンバーを同じバージョンへ更新する必要があります．スキーマやAPIの変更があると，更新済みメンバーが一時的に処理をブロックされた状態となり，API要求を受け付けなくなる場合があります．公式資料はオフラインメンバーがいる状態での更新を避けるよう注意しています．[3]

したがって，段階的な保守は「順番にパッケージを更新すれば無停止になる」という約束ではありません．対象版での更新経路とコントロールプレーンへの影響を確認し，状態のバックアップと失敗時の復旧方法を用意します．

トレードオフ — ライセンス費用を何へ振り向けるか

Incusへの移行でライセンス支出を抑えられても，設計，更新，検証，障害対応の仕事は残ります．比較すべき費用には，移行・教育・検証の初期費用，保守契約，ハードウェアの余力，ストレージ / バックアップ，自動化の仕組みの保守も含まれます．

その投資を，再現可能なホスト，観測，復元可能なバックアップ，明確な運用手順書，ワークロードに応じた配置へ振り向けられるなら，構成を自分たちで制御できることが利点になります．反対に，組み合わせた仕組みを更新・検証する担当者がいなければ，自由度は運用負債になります．

選択の目安は次のように整理できます．

• VMware継続：エコシステムへの依存が強く，統合サポートや移行回避の価値が大きい．
• Proxmox VE：統合された運用体験やWeb UIを重視し，仮想化基盤を製品として導入したい．
• Incus + NixOS：宣言的なホスト管理，API連携，観測，自動化を継続的に改善する体制を持つ，またはMSPへ委託できる．
• OpenStack / CloudStack：VM運用を超え，テナント向けのIaaSを提供する要件がある．

CoRISEが考える運用支援付きのインフラ基盤

CoRISEでは，現状評価から移行先の構成設計，移行PoC，本番移行，継続運用までを一つの問題として扱います．Incusが適していれば，OpenTofu，NixOS，ストレージ，ネットワーク，バックアップ，可観測性を組み合わせた基盤として設計します．

運用では，処理能力・容量の管理，バックアップ，監視，インシデント対応，更新，ホストのライフサイクル管理，セキュリティ，復旧の責任を割り当てます．対応時間，SLA，復旧目標，顧客とCoRISEの分担は，要件と契約で定める事項です．ツールを選んだだけで保証されるものではありません．

顧客に内製化の意向があれば，運用委託から共同運用，知識・技術の移転，顧客による運用へ段階的に移すことも考えられます．引き渡すのは構成だけでなく，判断基準，試験記録，運用手順書，更新と復旧を担える知識です．

制約 — この構成がまだ保証しないこと

本稿の3ノード構成は評価用の設計案です．VMwareからの変換成功率，障害復旧時間，ライブマイグレーションの停止時間，性能，運用コストを実測したものではありません．Flakeとモジュールも構造を示す例であり，完成した参照リポジトリではありません．

採用前には，Incus / NixOS / ストレージ / OVN・Open vSwitch / 認可基盤の版，ゲストOS，物理障害境界，CPU・デバイス互換性，更新経路，サポート条件を固定して試験します．公式資料の既定値や対応機能も，対象版で再確認します．関連事例は基盤設計の文脈であり，このIncus構成の導入実績を示すものではありません．

VMware代替で本当に選ぶもの

最終的に選ぶのは，ESXiの代わりに入れるソフトウェアだけではありません．どの責任を製品に任せ，どの責任をMSPへ任せ，どの責任を自社で持つかという運用モデルです．

今回の参照構成では，再現可能なホスト，クラスター，共有ストレージ，多層のフェンシング，ネットワーク制御面，管理APIの権限，可観測性，バックアップを合わせて評価します．実際に壊しても戻せる基盤を，誰が維持できるかまでが採用条件です．

安価なハイパーバイザーを探すことから，長く運用できる基盤と責任の分担を設計することへ．それが，VMware代替を評価するときの出発点になります．

参考資料

1. Proxmox VE 9.2 release announcement — 2026-05-21
2. Incus: About clustering — クォーラム，障害領域，CPUベースライン，配置制御
3. Incus: How to manage a cluster — 退避，復旧，負荷再配分，更新
4. Incus: Server configuration — クラスター設定と既定値
5. Incus: How to monitor metrics — エンドポイント，認証，各メンバーの収集
6. NixOS 26.05: Incus module
7. Incus: Storage drivers — 対応ボリュームと機能の比較
8. Ceph Tentacle: RBD Exclusive Locks — cooperative transitions and blocklisting
9. Pacemaker 3.0: Fencing — devices, dependencies and topologies
10. Incus: How to set up OVN — standalone and clustered configurations
11. Open vSwitch: ovsdb(7) — clustered service, Raft, backup and upgrades
12. Incus: Remote API authentication — TLS trust, enrollment tokens and OIDC
13. Incus 7.0.0: Authorization — TLS, OpenFGA and project restrictions
14. Incus development documentation: Authorization — client routing
15. TLA+ Toolbox: Running TLC — invariant violations and error traces

関連事例

• 侵害を前提としたインフラストラクチャ

この事例は責務分離や復旧設計を考えるための文脈です．本稿のIncus構成をその案件で導入・検証したことを示すものではありません．