コンテンツにスキップ
ドキュメント ガイドアップデート

アップデート

XCP-hl も XOA-hl も、署名済みのパッケージを使ってその場でアップデート できます。通常のパッケージ更新では再インストールは不要です。ホスト（XCP-hl）は、標準の XCP-ng と 同じく Xen Orchestra の Patches タブからアップデートします。 アプライアンス（XOA-hl）は、専用の XOA-HL Updates 設定ページから アップデートします。

このページの前半と後半は同じ構成です。Xen Orchestra での手順、 コマンドラインでの同じ操作、内部の仕組み、前のバージョンに戻す方法の 順に説明します。

XCP-hl（ハイパーバイザーホスト）のアップデート

対象: XOA-HL イメージ xoa-image-20261022-a280852、パッケージ v5.113.2_e281c536-ce40（Xen Orchestra 5.113.2）。公開済みのコードに基づく手順で、このバージョンでのホストパッケージの適用と再起動は、検証環境でまだテストしていません。

Xen Orchestra で行う

  1. アップデートがあることを確認します。 Home > Hosts では、 アップデートが保留されているホストに、不足しているパッチの数を示す 赤いバッジが付きます。

    ホストの一覧：ホストの赤いバッジが不足しているパッチの数を示している

  2. ホストの Patches タブを開きます。 ホストを選び、Patches を 開きます。パッケージごとに名前、説明、バージョン、リリース、 ダウンロードサイズが並び、行にある目のアイコンで RPM の変更履歴を 表示できます。プール単位の画面 Home > Pools > <プール> > Patches にも プールマスターで不足しているパッケージが出ます。プール全体の操作前に、 各ホストを個別に確認してください。

    利用できるパッケージが並んだ、ホストの Patches タブ

  3. 対象範囲を選びます。 ホストの Patches タブにある Install all patches はそのホストを対象にします。プールの Patches タブにある Install pool patches はマスターから順にプール内の全ホストを対象にします。確定前にホストとプールの ID を確認してください。

    プールのパッチをインストールしている最中の Patches タブ
    どちらのボタンも XCP-ng のパッケージを個別には選べません。対象ホストごとに updater.py が有効な XCP-ng 標準リポジトリと XCP-hl リポジトリをまとめて yum update し、保留中の標準パッケージも対象になります。一括処理は 原子的なロールバックを保証しません。プールの操作はマスターから 1 台ずつ 処理しますが、VM の退避やホスト再起動は行いません。特定の XCP-hl パッケージだけを更新する場合は、下の別途コマンドライン手順を使います。

  4. タスクの完了を待ち、ホスト接続を更新します。 このバージョンの XO では、 ホストのアップデータープラグインを呼び、適用後にそのホストの XAPI エージェントを再起動します。ホストが一時的に切断される場合があります。 この操作は XOA-HL アプライアンスの更新も xo-server の再起動も呼びません。 接続が戻らない場合はエラーを保存し、再試行前に独立したコンソールでホストを確認します。

  5. 結果を確認します。 対象ホストとプールの一覧、タスク結果、パッケージと バージョン、未適用件数、再起動が必要という表示を更新して照合します。 バッジが消えただけでは、再起動や VM・ストレージの正常性は確認できません。

    ホストが完全に最新になった Patches タブ

単一ホストの検証用プールでホストの更新をテストする

最初のホスト更新は、依存しているプールではなく、作り直せる検証用プールで行います。単一ホストでのテストでは、複数ホストのプールが更新中にどう動くかは分かりません。

始める前に

  • リリースが分かっている単一ホストの検証用プールを使います。通常の VM、実行中のバックアップタスク、HA、そのホスト上で動く XOA-HL アプライアンスがないこと。
  • 別のホストコンソール、ホストとネットワークの復旧計画、別の XOA-HL 接続を用意します。
  • パッケージ全体（標準と HomeLab）について、承認された作業時間を確保します。再起動は別に判断します。
  1. 上記のイメージ、パッケージ、XO のバージョン、ホストとプールの UUID、マスター、管理アドレス、導入済みパッケージのバージョン、有効なリポジトリ ID、ホストの電源と有効状態、保留中のパッケージの正確な一覧を控えます。ホストコンソールで yum check-update を実行し、Patches タブと比べます。確認に失敗した場合や一覧が想定と違う場合は、作業を止めます。更新があると yum check-update は終了コード 100 を返すことがありますが、これは正常です。
  2. XOA-HL のブラウザーで /#/hosts/<host-id>/patches を開き、Install all patches を選び、ホストを確認して 1 回だけ確定します。行を選んでも、更新がそのパッケージに限定されることはありません。タスク ID、開始と終了の時刻、出力やエラーを控えます。一時的に切断されている間にもう一度クリックしたり、同時にコマンドラインで更新を始めたりしないでください。
  3. タスクが終わったら、別のコンソールと更新した XOA-HL の一覧を使い、控えた内容と比べます。導入済みのバージョン、残りのパッチ、ホストへの到達性、有効状態と電源状態、管理ネットワーク、SR の接続です。タスクが失敗した場合や接続が戻らない場合は、ログと実際のパッケージの状態を残します。一部だけ更新された場合は、ホストの担当者の復旧または再構築の計画に従います。元に戻ったと考えないでください。
  4. 再起動が必要と表示された場合は、プールが空の状態で、別途承認された再起動を計画します。VM やバックアップタスクが増えていないことを確認し、ホストの Patches タブで Reboot to apply updates を 1 回だけ選びます。再起動の強制や、ブロックされた一時停止、バックアップ、バージョン確認の回避を求める画面は受け入れないでください。別のコンソールでホストの復帰を待ってから、XOA-HL の接続、パッケージ、再起動の表示、ネットワーク、SR をもう一度確認します。ボタンやタスクの動きが想定と違う場合は、作業を止めて記録します。2 回目の再起動を強制しないでください。

確認: ホストに到達でき、パッケージが想定したバージョンで、残りのパッチも保留中の再起動もありません。更新前後のパッケージ一覧、タスクとコンソールの出力、正確なエラー、再起動の判断、最終的な接続状態を保存します。途中で中断したインストール、復旧、本番や複数ホストのプールでの可用性はここでは扱いません。ホストの保守と VM の退避は、稼働中のテスト VM を使う別の作業です。パッチのボタンでは行われません。

コマンドラインで行う

ホスト上で次のように実行します。

yum check-update                   # 何が利用できるか
yum update xcp-hl-release          # リポジトリの設定そのもの
yum update xo-lite-ce xoa-proxy    # XCP-hl のパッケージだけ
yum update                         # すべて（Patches タブと同じ）

仕組み

XCP-ng には updater.py という XAPI プラグインが同梱されており、Xen Orchestra はこれに利用できるアップデートの一覧を問い合わせます。XOA-hl は この問い合わせに XCP-hl のリポジトリを含めるように変更してあるため、 XCP-hl のパッケージが標準の XCP-ng のものと並んで表示されます。

リポジトリは /etc/yum.repos.d/xcp-hl.repo という 1 つのファイルで定義され、 xcp-hl-release パッケージが所有しています。

リポジトリ ID内容公開元
xcp-hl-basexcp-hl-releasexcp-hl
xcp-hl-xolitexo-lite-cexolite-ce
xcp-hl-xoa-proxyxoa-proxyxoa-proxy
このファイルのセクション名は変更しないでください。Xen Orchestra はこれらの リポジトリ ID を updater.py に渡し、プラグインは渡されたリポジトリの アップデートしか一覧に出しません。セクション名を変えてもエラーにはならず、 そのパッケージが Patches タブから黙って消えるだけです。

リポジトリの設定変更をインストール済みのホストにも届けるため、 一度だけコピーするファイルではなく、パッケージとして配布しています。 設定の変更は yum update xcp-hl-release を通じてホストに届きます。

既存のホストでの初回設定

xcp-hl-release パッケージより前の ISO からインストールしたホストでは、 一度だけ初期設定が必要です。そのあとは設定を yum が管理します。

curl -L -o /etc/yum.repos.d/xcp-hl.repo \
  https://vagrantin.github.io/xcp-hl/xcp-hl.repo

rpm --import https://vagrantin.github.io/xcp-hl/xcp-ng-ce-public.asc

yum clean all
yum install xcp-hl-release

パッケージをインストールすると、いまダウンロードしたファイルはパッケージに 含まれるものに置き換わり、元のファイルは xcp-hl.repo.rpmorig として 残ります。両者の違いは署名鍵をどこから読むかだけです。ダウンロードした方は HTTPS で取得し、パッケージに含まれる方はパッケージが入れるローカルの鍵を 使います。

新しい ISO には最初から xcp-hl-release が入っているため、この手順は 必要ありません。

前のバージョンに戻す

各リポジトリは直近のリリースだけを公開しているため、戻せる範囲はそれに 限られます。以前のビルドに戻すには次のようにします。

yum --showduplicates list xo-lite-ce
yum downgrade xo-lite-ce-<バージョン>

XOA-hl（管理 UI）のアップデート

Xen Orchestra で行う

  1. アップデートのページを開きます。 XOA-hl の Web 画面で Settings > XOA-HL Updates を開きます。インストールされている バージョンが表示されます。一度も確認していないうちは、状態は Update status unknown です。

    まだ確認していない状態の XOA-HL Updates ページ

  2. Check for update をクリックします。 アップデートがあるパッケージが、 バージョンとともに一覧で表示されます。

    確認の結果：利用できるアップデートとパッケージの一覧

  3. Update now をクリックします。 アップデートのログが、進行に合わせて ページに流れます。アップデートの途中で xo-server が再起動するため、 ページには一時的に Reconnecting と表示され、その後は自動で続きます。

    ログが流れている、実行中のアップデート
    ce20 の管理用更新処理では Node.js を除外します。Update now は xoa-hl だけでなく、AlmaLinux やカーネルを含め、 アプライアンスで保留中のすべてのパッケージをインストールします。

  4. 完了です。 アップデートが終わったらもう一度確認してください。 ページに Up to date と表示されます。

    アプライアンスが最新であると表示している XOA-HL Updates ページ

コマンドラインで行う

アプライアンス上で次のように実行します。

dnf check-update         # 何が利用できるか
dnf update xoa-hl        # アプライアンスのアプリケーションのみ
dnf update --exclude=nodejs  # アプリケーションと AlmaLinux のベースをまとめて

仕組み

アプライアンスには専用の yum リポジトリがあり、xoa-hl パッケージ自身が 提供する /etc/yum.repos.d/xoa-hl.repo で定義されています。

リポジトリ ID内容公開元
xoa-hlxoa-hlxoa-hl

アップデートのページにある 2 つのボタンは、それぞれ次の systemd ユニットを 起動します。

ユニット役割
xoa-hl-check-update.servicednf check-update を実行し、結果を /run/xoa-hl/status に書き込みます
xoa-hl-update.servicednf -y --refresh --exclude=nodejs update をすべて実行し、ログを /var/lib/xoa-hl/update.log に書き込みます

自動チェックと自動更新

xoa-hl リリース v5.113.2_e281c536-ce20 では、Settings → XOA-HL Updates → Automatic updates で 3 つのモードを選べます。

モード動作
Manual only管理者がチェックとインストールを開始します。これが既定です。
Check automatically定期チェックで状態を更新します。インストールは手動です。
Install automatically明示的な確認後、指定したメンテナンス時間にチェックとインストールを行います。

頻度、曜日（毎週の場合）、ローカル開始時刻を選び、保存します。時刻はアプライアンスのタイムゾーンを使用し、ランダムな遅延なしで設定時刻に実行します。v5.113.2_e281c536-ce40 以降、失敗した自動実行はページに赤いバナーで表示されます。RPM のインストールや更新によって自動インストールが有効になることはありません。古いパッケージにはこの設定がない場合があるため、まずインストール済みバージョンを確認してください。

管理用の更新処理は Node.js を対象から除外し、対応するメジャーバージョンを維持します。更新により xo-server などのサービスが再起動する場合があります。VM の自動再起動は行いません。実行できなかったインストールを次回起動直後に実行することもありません。結果を確認し、必要な再起動は管理者が計画してください。コマンドライン設定と診断についてはバージョン固定のスケジュール設定資料をご覧ください。

前のバージョンに戻す

現在有効なリポジトリに古いパッケージがあるかを確認できます。

dnf --showduplicates list xoa-hl

利用できるパッケージは変わります。v5.113.2_e281c536-ce40 では、パッケージのダウングレードと異なるバージョン間の設定復旧は、アプライアンス復旧手順として未検証です。ダウングレードはベース OS の更新を取り消さず、XO データや独自のファイルも復元しません。ロールバックを計画する前に、設定ガイドに従ってエクスポートと隔離した復旧テストを準備してください。

検証と信頼

XCP-hl と XOA-hl のどちらのパッケージとリポジトリのメタデータも、XCP-hl の GPG 鍵で署名しています。クライアント側の設定は repo_gpgcheck=1 と gpgcheck=0 です。

RPM は主鍵ではなく GPG のサブキーで署名しています。ここには XCP-ng 8.3 のホスト側にある rpm ツール（バージョン 4.11）の既知の制限があります。 鍵をインポートしたときに主鍵しか登録しないため、サブキーによる署名は NOKEY と報告され、署名自体は正しくてもパッケージを直接検証できません。

そこで信頼はリポジトリのメタデータを経由します。サブキーを理解できる本来の GPG ツールが repomd.xml を検証します。このファイルには primary.xml の チェックサムが記録され、primary.xml にはすべてのパッケージの チェックサムが記録されています。つまり repomd.xml という 1 つのファイルを 検証すれば、リポジトリ内のすべての RPM を検証したことになります。

署名用サブキーは 2027 年 5 月 10 日に期限切れになります。それ以降は、 サブキーの期限を延長し、公開されている鍵を更新し、各ホストで再インポート するまで検証に失敗します。

既知の制限事項

v5.113.2_e281c536-ce40 で確認したアプライアンスの範囲では、中断後の復旧とダウングレードは使い捨て環境での検証が必要です。結果確認と再起動の判断は保守ガイドを参照してください。

このディストリビューションがアルファ版であることを忘れないでください。 アップデートの前にリリースノートを読んでください。リリースのたびに互換性の ない変更が入る前提であり、アップデートに手作業が必要になることもあります。