背景とXCP-ngへの移行が必要な理由
深夜2時、PagerDutyのアラートがけたたましく鳴り響きました。本番環境の6ノードクラスタで稼働していた1台のESXiホストがvCenterとの通信をロスト。容量800GB超のMySQLデータベース仮想マシン4台が瞬時に孤立しました。さらに追い打ちをかけるように、VMwareがCPUコア単位のサブスクリプション体系へ移行したことを受け、経営陣からはインフラコストの40%削減が命じられていました。SANのSCSI reservation lockエラーでフリーズしたvSphere Clientの画面を前に、当直チーム全員が途方に暮れていました。
ホームラボ規模であれば、Proxmox VEは非常に優れたソリューションです。筆者自身も3ノードクラスタを構築し、20台のVMをスムーズに運用した経験があります。しかし、150台規模のVMを抱えるエンタープライズ環境では、より厳格な基準が求められます。きめ細やかなRBAC権限管理、複数ホスト間でのシームレスなLive Migration、そしてスナップショットベースの確実なDelta Backupなどです。Proxmoxでは、システム管理者が手動スクリプトで対処しなければならない場面も少なくありません。そこで、ESXi＋vCenterの組み合わせに代わる理想的な解として浮上するのが、XCP-ng（XenServerベースのオープンソースハイパーバイザ）とXen Orchestra (XO)のコンビです。
アーキテクチャ面において、XCP-ngはベアメタル上で直接稼働するType-1ハイパーバイザ（ESXiに相当）の役割を果たします。一方のXen Orchestraは、Webベースの集中管理コンソール（vCenterに相当）です。各仮想マシンに重いエージェントを導入することなく、XOのREST APIを介してクラスタ全体、テンプレート、仮想ネットワーク、バックアップスケジュールをすべて一元管理できます。
XCP-ngとXen Orchestraのインストール
1. 事前準備とベアメタルへのXCP-ngインストール
公式サイトからXCP-ng 8.2 LTS（または8.3）のISOイメージをダウンロードし、Rufusやddコマンドを使ってUSBインストールメディアを作成します。サーバー（例：Dell PowerEdge R640）を起動してBIOSに入り、ハードウェア仮想化支援機能（Intel VT-x/VT-d、またはAMD-V/IOMMU）を有効化してください。USBメディアを挿入し、ncursesベースのインストーラー画面を起動します。
設定時の主な注意点は以下の通りです：
- キーボードレイアウト（USなど）を選択し、GPLv2オープンソースライセンスに同意します。
- OSインストール先ドライブの選択：VM格納領域と分離するため、ハードウェアRAID-1構成のSSD/SASドライブ2本（120GB以上を推奨）を使用することをおすすめします。
- 複雑な
rootパスワードの設定：このパスワードはSSH接続および今後のAPI連携の両方で使用されます。 - 管理インターフェース（Management Interface）への静的IPアドレス割り当て（例：
192.168.10.50/24、ゲートウェイ：192.168.10.1）：本番環境ではDHCPの使用を避けてください。
サーバーの再起動後、管理用IPが表示されたxconsole画面が立ち上がります。SSH経由でホストの状態を確認してみましょう：
ssh [email protected]
# ホストの状態およびdom0のリソース状況を確認
xe host-list
xentop2. Xen Orchestra Appliance（XOA）のデプロイ
管理コンソールを構築する最も確実かつ迅速な方法は、dom0からVates公式のデプロイコマンドを直接実行することです：
# Xen Orchestra Appliance（XOA）仮想マシンのクイックデプロイ
curl -sL https://xoa.io/deploy | bashエンタープライズ機能が100%アンロックされた無料版（Xen Orchestra Community Edition）を利用したい場合は、Debian 12の仮想マシン（2 vCPU、4GB RAMを割り当て）を作成し、ソースからビルドします：
# Debian 12仮想マシン上での作業：
sudo apt update && sudo apt install -y curl git build-essential
# Xen Orchestra Community Editionの自動ビルドスクリプトを実行
curl -sL https://raw.githubusercontent.com/ronivay/XenOrchestraInstallerUpdater/master/xo-install.sh | bashビルドには約5〜7分かかります。完了後、ブラウザからhttp://<XOAまたはVMのIPアドレス>にアクセスしてください。初期アカウントはユーザー名[email protected]、パスワードadminです。ログイン後、直ちにSettings > Usersからパスワードを変更してください。
インフラの詳細設定
1. XCP-ngホストをXen Orchestraに接続
XOの管理画面でSettings > Serversへ進み、Add Serverをクリックします：
- Label: 識別用の名前を設定（例：
Node-01-DellR640）。 - Host: XCP-ngホストのIPアドレスを入力（
192.168.10.50）。 - Username:
root - Password: ホストの管理者パスワード。
- Auto-connectにチェックを入れてConnectをクリック。アイコンが緑色に変われば、XOによるクラスタ管理の準備は完了です。
2. CLIによるStorage Repository（SR）の設定
ダウンタイムなしのLive Migrationを実行するには、共有ストレージ（NFS/iSCSI）が必須要件となります。Webインターフェース経由でSAN/NASへの接続エラーが発生する場合は、CLIを使用して迅速にStorage Repositoryを作成できます：
# SynologyやTrueNASなどのNASからNFSストレージリポジトリ（SR）を作成
xe sr-create \
name-label="NFS-Production-Pool" \
type=nfs \
device-config:server=192.168.10.20 \
device-config:serverpath=/volume1/xcp-vms \
shared=trueコマンドの実行結果としてSRのUUIDが返されれば、ストレージ領域がプール内の全ホストへ正常にマウントされたことを示します。
3. VLANおよび仮想ネットワークの構成
エンタープライズシステムでは、管理用トラフィック、バックアップ、本番通信を適切に分離することが推奨されます。10GbEネットワークカードを使用してVLANインターフェースを作成します：
# 物理NIC eth1（10GbEアップリンク）のUUIDを取得
PIF_UUID=$(xe pif-list device=eth1 --minimal)
# データベースVM専用のVLAN 100を作成
xe vlan-create pif-uuid=$PIF_UUID vlan=100検証とモニタリング
1. ゼロダウンタイムLive Migrationの検証
Node 1上にテスト用のUbuntu 22.04仮想マシンを作成します。作業用端末からVMのIPアドレスに対して高頻度で連続pingを実行します：
ping -i 0.2 192.168.10.105Xen Orchestra上で該当のVMを選択し、Migrateボタンをクリックして移行先にNode 2を指定します。メモリ（RAM）の同期処理がバックグラウンドで実行されます。実機検証の結果、ホスト切り替え時に欠落したパケットはわずか1パケットのみ（レイテンシ80ms未満）であり、VM内で動作するWebサーバーはvMotionと遜色なくリクエストを処理し続けました。
2. リソース監視とボトルネックのトラブルシューティング
dom0はハイパーバイザ全体のI/Oパフォーマンスを左右する制御ドメイン（Control Domain）です。VMでディスクI/Oのボトルネックが発生した場合は、速やかにdom0を確認してください：
# 各VMのリアルタイムなCPU、メモリ、I/Oステータスを確認
xentop
# ストレージ管理ログを監視し、VDIロックエラーを検出
tail -f /var/log/SMlog | grep -E "ERROR|WARNING"あわせて、Xen OrchestraのBackup > Newから、MinIO S3またはバックアップ用NFSサーバーへの4時間ごとのDelta Backupスケジュールを設定しましょう。Changed Block Tracking（CBT）メカニズムのおかげで、転送データ量は毎回わずか数百メガバイト程度に抑えられ、本番ネットワークに負荷をかけることなく2〜3分でバックアップが完了します。
