バックアップ障害と XOA-HL のトラブルシューティング

症状と、その直前に行った操作から調べ始め、該当する確認手順に進みます。ほとんどの確認は情報を読むだけです。ブラウザーで XOA-HL アプライアンスに管理者としてログインして行います。一部の確認には、アプライアンスのコンソールやゲストのコンソールが必要です。失敗した更新、インポート、バックアップを再試行する前に、エラーとログを保存してください。

症状から調べる

操作ボタンが使えない、画面が空白や固まったままなど、コンソールの問題は VM のコンソールを使うを参照してください。

ネットワーク接続を診断する

既存の通常のゲストネットワーク、または検証用 VLAN を、読み取り専用で確認します。すべての VM、プール、ホストを見られるよう、XOA-HL の管理者としてログインします。

始める前に

• ゲスト内の確認には、ゲストのコンソールで許可されたセッションが必要です。スイッチ、DNS、ファイアウォールは、それぞれの管理者が確認します。
• ホストへの別のコンソールアクセスを使える状態にしておきます。
• この手順を試すために、障害を起こしたり管理ネットワークを変更したりしないでください。
• ボンド、SDN、ゲスト内の VLAN トランク、緊急時のネットワーク復旧はここでは扱いません。

1. 失敗している経路を見つける

タイムゾーン付きの時刻、最後に成功した操作、正確なエラーを控えます。送信元のマシン、宛先の名前またはアドレス、プロトコル、サービスのポートも控えます。再試行の前に、この開始時の状態を保存します。手元の PC からのテストが成功しても、アプライアンス、ホスト、ゲストから届くことの証明にはなりません。

2. ゲストのインターフェースからホストのアップリンクまでたどる

ここでは画面を読むだけにします。編集できるネットワークや MAC の欄、接続ボタンはクリックしないでください。

1. VM の UUID、電源状態、実行中のホスト、プールを控えます。VM の ネットワーク タブ（/#/vms/<id>/network）を開きます。
2. 行のコピーボタンで、インターフェース（VIF）の UUID をコピーします。デバイス番号、MAC アドレス、ネットワーク、MTU、状態を控えます。
3. プールのネットワーク画面（/#/pools/<id>/network）を開き、名前だけでなく正確なネットワーク UUID を照合します。
4. Connected を読みます。VIF が接続されているかを示します。停止中の VM で VIF が未接続でも、障害ではありません。
5. IP addresses を読みます。ゲストのメトリクスを VIF デバイスごとに表示したものです。アドレスがなくても、ゲストが未設定とは限りません。表示されたアドレスも、現在届くかどうかのテストではありません。ゲストのコンソールとゲストエージェントの確認と照合します。
6. ロックモードの表示と Allowed IPs は、報告されたアドレスとは分けて控えます。これらは通信のルールで、ゲストに IP アドレスを割り当てる入力欄ではありません。警告は保存し、適用されているルールの説明をネットワーク管理者に求めます。近道として、インターフェースのロック解除、制限の削除、MAC や MTU の変更、セキュリティの無効化をしないでください。
7. プールのネットワーク行で PIFs を展開し、VM を実行中のホストを探します。この行の VLAN の概要は、プールのマスターだけの情報です。
8. そのホストの ネットワーク タブ（/#/hosts/<id>/network）を開きます。PIF の UUID、デバイス、MAC、ネットワーク、VLAN、MTU、管理フラグ、IP モードを控えます。承認済みの配線とスイッチの記録と照合します。意図的に物理アップリンクのない内部ネットワークもあります。障害と判断する前に、想定された構成を確認します。
9. 接続状態と物理リンク（キャリア）は分けて読みます。ホストの Connected ボタンは、PIF が接続されているかを示します。物理リンクのアイコンと、プールで展開した PIF の状態は、キャリアを示します。

PIF のメトリクスがない場合も、キャリアなしと表示されることがあります。否定的な表示だけでは、ケーブルが抜けているとは言えません。更新して、ホストとスイッチの表示と照合します。経路を調べるために、PIF の切り替え、VLAN・MTU・IP の設定変更、ネットワークの削除、ネットワークの再起動をしないでください。

3. ゲストの設定とサービスを確認する

1. ゲストのコンソールで、MAC アドレスからインターフェースを特定します。ゲスト内の名前は、ホストのデバイス名と異なる場合があります。
2. ゲストの OS のツールで、アドレスとプレフィックス、経路、DNS の設定を読みます。ネットワーク管理者が承認した、重複しないアドレスとサブネットと照合します。検証用 VLAN では、ゲストには通常タグなしのインターフェースが見えます。
3. ゲストまたはネットワークの管理者に、このゲストから、合意した相手とアプリケーションのサービスをテストしてもらいます。DNS の応答、使われたアドレスファミリー、宛先、プロトコルとポート、結果を分けて控えます。
4. 名前でのテストとアドレスでのテストの結果が違う場合は、判断する前に DNS と、アプリケーションや TLS の識別情報を確認します。HTTPS に IP アドレスだけでアクセスすると、証明書や仮想ホストが変わることがあります。成功と判断するために証明書の検証を回避しないでください。

ping が成功しても、サービスが動いている証明にはなりません。ping が失敗しても、隔離の証明にはなりません。承認された宛先だけをテストします。隔離が必要な場合は、管理者が決めた接続禁止先もテストします。

同じホスト上の相手とのテストでは、物理アップリンクはテストできません。ホスト間やホスト外へのテストには、特定済みの相手と、承認されたスイッチの経路が必要です。その場しのぎのテストのためにワークロードを移行しないでください。本番環境への想定外のアクセスに気づいたら、証拠を保存し、テスト用ゲストを通常どおりシャットダウンします。管理やストレージに影響がある場合は、ほかの変更をする前に、別のホストコンソールと管理者の復旧計画を使います。

4. 修正を確認する

1. 正確な対応関係、時刻、エラー、照合の結果を管理者に渡します。
2. 合意した修正を、ゲスト、ストレージ、ホスト、ネットワークのうち該当する手順で適用します。この手順は、一般的なリセットを指示するものではありません。
3. 一覧を更新します。同じ送信元から同じ宛先への、同じサービスのテストを繰り返します。
4. 必要な隔離の確認を繰り返し、管理とストレージへのアクセスを確認します。
5. 変更した内容と結果を控えます。

確認: 同じテストが成功するようになりました。緑色の表示だけでは、問題が解決したとは言えません。経路がまだ不明な場合は、障害を未解決のままにし、機密情報を除いた内容で問題を報告してください。

失敗した NFS バックアップを調べる

チュートリアルの NFS へのフルバックアップのジョブだけを対象に、XOA-HL の管理者としてログインして行います。作業はブラウザーで行います。ストレージの確認は、そのストレージの管理者が担当します。障害を起こす必要はありません。

始める前に

• ジョブとスケジュールの ID、元の VM の UUID、リモートの ID、タイムゾーン付きの予定実行時刻、最後の隔離復元の結果を控えます。
• 差分チェーン、レプリケーション、本番環境の復旧はここでは扱いません。ほかのバックアップのテストは、差分バックアップとチェーンの復旧、差分バックアップから 1 ファイルを取り出す、別のプールへのレプリカ、Windows Server の SMB リモートを参照してください。

1. 実行を見つけて詳細を保存する

1. バックアップ → オーバービュー（/#/backup/overview）を開き、ジョブを探します。その下の Logs 表を見ます。
2. 必要に応じて、ログの検索と状態のフィルターを消します。ジョブと開始時刻から実行を探します。表のジョブ ID は短縮表示です。名前だけでなく、詳細にある完全な ID を使います。
3. 実行の状態ボタンを選び、詳細を開きます。実行の id、jobId、scheduleId、開始・終了時刻、状態を控えます。
4. 何かを変更する前に、クリップボードのボタンか Download log で JSON を非公開で保存します。ダウンロードしたログから機密情報は削除されていません。報告には、機密情報を除いた抜粋を作ります。
5. 詳細の検索を消し、すべてのタスク状態を選びます。最初は実行中、失敗、中断のタスクだけが、1 ページ 5 件で表示されることがあります。全ページを確認します。
6. VM の UUID を探し、そのスナップショット、リモート、エクスポート、転送のタスクを確認します。各階層のエラー、スキップの理由、警告を保存します。生のタスクがすべて表示されるとは限りません。ツリーが不完全に見えるときは、保存した JSON を読みます。

確認: 控えた内容から、特定の 1 回の実行と、対象の VM とリモートが分かります。ログやタスクがなくても、何も実行されなかった証明にはなりません。

2. 再試行の前に状態を読む

3. 失敗した段階と残ったデータを分ける

バックアップ → 復元（/#/backup/restore）を開き、復元ポイントと復元ログを確認します。

確認: 失敗した段階、残った復元ポイント、状態がまだ分からないオブジェクトを区別できます。ファイルや一覧のポイントだけでは、データを復旧できる証明にはなりません。

4. 原因を直して結果を確認する

1. 今後の実行を止めるには、オーバービュー で対象のラボ用スケジュールを無効にし、更新して状態を確認します。これでは実行中のバックアップはキャンセルされません。この版では、オーバービュー のキャンセルボタンが無効です。xo-server を再起動しても、バックアップのキャンセルや後片付けにはなりません。
2. アクセス、容量、選択の問題を、担当者と一緒に直します。その後、ジョブ、スケジュール、VM、リモートを再確認します。
3. 古いバックアップを最初に削除する はオフのままにし、必要な復旧用のコピーは、このジョブの保持対象の外に置きます。処理がまだ実行中かどうか、途中まで作られたオブジェクトの所有者が誰か分からない場合は、証拠を保存し、再試行の前に支援を求めます。
4. 実行中の処理がなく、状態を把握できたら、チュートリアルのとおり、この 1 VM のラボ用ジョブを手動で実行します。詳細画面の再実行ボタンと強制ボタンはバックアップを実行します。ゲストを再起動するボタンでも、読み取り専用の確認でもありません。強制実行は使わないでください。再試行では、古いポイントに保持設定が適用されることもあります。
5. 新しい実行と復元ポイントを確認します。次に、停止したコピーを復元し、NIC をすべて削除して、確認用のデータを照合します。
6. ラボ用スケジュールは無効のままにします。予定された実行を再開する前に、元のエラー、修正内容、新しい実行とポイントの ID、復元の結果を控えます。

確認: 新しい実行、残っている復元ポイント、ゲストのデータの隔離復元がすべて成功します。成功しない場合は、障害を未解決のままにし、機密情報を除いた証拠で問題を報告してください。

コンソールからアプライアンスを確認する

これらのコマンドは状態を読むだけです。ハイパーバイザーのホストではなくアプライアンス内で、許可されたコンソールまたは SSH セッションから実行します。一部のコマンドには root 権限が必要です。

rpm -q xoa-hl nodejs
timedatectl
df -h
systemctl status xo-server redis xoa-hl-update.service --no-pager
systemctl list-timers 'xoa-hl-*'
journalctl -u xo-server -u xoa-hl-check-update.service -u xoa-hl-update.service -u xoa-hl-auto-update.service --since '1 hour ago' --no-pager
tail -n 100 /var/log/xoa-first-boot.log
tail -n 100 /var/lib/xoa-hl/update.log
cat /run/xoa-hl/status
cat /var/lib/xoa-hl/auto-update.status

• 最初の確認の前や再起動の後に状態ファイルがなくても、それだけでは障害ではありません。
• systemctl status は、停止中や失敗したユニットでは 0 以外を返します。表示された状態を読んでください。
• 自動更新の状態は、過去の実行のものである場合があります。UTC の時刻を照合します。
• 各状態の意味と、更新や再起動の判断については、アプライアンスの保守を参照してください。

エラーを消すために、データベースのファイル、ログ、ロックを削除しないでください。ディスクがいっぱいの場合は、増えているファイルを特定し、証拠を保存してから、何を片付けるかを決めます。

管理者アクセスを復旧する

管理者が誰もログインできないときに使います。パスワードをなくした、ワンタイムコードの端末をなくした、LDAP や SAML のログインが動かなくなった、といった場合です。復旧コマンドは アプライアンスの中 で、アプライアンスのコンソールまたは SSH から root として実行します。アプライアンスの root 権限があれば誰でもこの方法で XO アカウントを奪えるため、その権限を守ってください。

コマンドは指定したアカウントを次のように変更します。

• 新しいパスワードを設定します。
• アカウントのワンタイムコードを解除します。
• アカウントを Admin にします。
• アカウントの LDAP や SAML とのリンクを外し、ローカルアカウントにします。
• アカウントのその他の設定と、既存の認証トークンは残します。

その名前のアカウントがない場合は、新しいローカル管理者を作成します。

1. XO Lite からアプライアンスのコンソールを開くか、SSH で接続し、root になります。

2. データベースが動いていることを確認します。systemctl is-active redis が active と表示します。

3. アカウントの正確なユーザー名（通常はメールアドレス）を指定してコマンドを実行します。xo-server を止める必要はありません。

   node /opt/xo/packages/xo-server/dist/recover-account-cli.mjs admin@example.net

4. Password (leave empty for random): と表示されたら、新しいパスワードを入力して Enter を押します。パスワードは表示されません。空のままにすると、コマンドがランダムなパスワードを表示します。パスワードマネージャーに保存してから画面を消去してください。パスワードをコマンドラインに書かないでください。シェルの履歴に残ります。

5. user admin@example.net has been successfully updated と表示されるまで待ちます。created と表示された場合は、名前が既存のアカウントと一致していません。ログイン後に 設定 → ユーザー一覧 で名前を確認し、不要なら余分なアカウントを削除します。

6. 新しいプライベートウィンドウで、そのアカウントと新しいパスワードでログインします。ワンタイムコードは求められません。

7. 自分のユーザーページで Authentication tokens を確認します。端末やパスワードをなくした場合は、全ての認証トークン破棄 を選びます。現在のセッションのトークン以外がすべて消えます。

8. アカウントがワンタイムコードを使っていた場合は、自分で管理する端末でもう一度設定します。LDAP や SAML を使っていた場合は、ローカルアカウントになっています。ローカルの復旧用管理者として残すか、ID 管理の担当者に確認してから再びリンクしてください。

確認: アカウントが新しいパスワードでログインでき、設定 → ユーザー一覧 で Admin と表示され、OTP 列が 未設定 で、想定したトークンだけが残っています。

よくある質問

ホストの保守で VM が残ったり、ホストが無効のままになったりしたのはなぜですか？ タスクを保存します。次に、ホストの実際の有効状態と、各 VM が実行されている場所を確認します。保守モードのテストでは、退避と再有効化を分けて扱います。一部だけの退避や早い段階での失敗には、ホストの担当者の復旧計画が必要です。マイグレーションのブロックを回避したり、むやみに切り替えを繰り返したりしないでください。

ホストがプールに参加できなかったのはなぜですか？ タスク、エラー、両方のプールの一覧を保存します。プールへの参加のテストでは、確定の前に、正確な ID、パッチの差分、マスター、ネットワーク、ストレージを確認します。画面からは強制参加が実行されます。原因不明の失敗を消すために、再実行したりホストを外したりしないでください。

委任した VM の作成が拒否されたのはなぜですか？ リソースセットとクォータのテストに従います。正確なユーザー、選んだセット、テンプレート・SR・ネットワークの ID、クォータの Used/Total を照合します。テンプレートやボタンが見えても、サーバーがその操作を許可している証明にはなりません。エラーを保存し、再試行の前に途中まで作られた VM やディスクがないか確認します。原因不明の失敗を消すために、クォータを上げたり、プールの Admin 権限を付与したりしないでください。

更新が表示されているのに、確認コマンドが 100 を返すのはなぜですか？ パッケージの確認スクリプトは、dnf check-update の終了コード 100 を AVAILABLE、0 を UP_TO_DATE、それ以外を ERROR に変換します。更新が表示されることは、インストールの失敗ではありません。

stable に切り替えると testing の更新は取り消されますか？ いいえ。チャネルは、次回以降の確認とインストールで使うリポジトリを選ぶだけです。stable に切り替えても、インストール済みのバージョンはダウングレードされません。

プールメタデータのポイントがあれば、ホストを復旧できますか？ いいえ、それだけでは証明になりません。プールメタデータのテストで確認するのは、エクスポート、保持、ファイルの識別情報だけです。隔離したテスト用プールでの復元は、まだ扱っていません。

設定のエクスポートで、VM のバックアップやアプライアンスのロールバックの代わりになりますか？ いいえ。設定の対象範囲と復旧の制約を読み、ゲストのバックアップは別に保管してください。

問題を報告する

XCP-HL の Issue を作成し、次の情報をテキストで記載します。

• ページの URL と表示言語、または問題が起きたアプライアンス画面のパス。
• イメージのタグ、XOについて に表示されるバージョン、インストール済みの RPM と Node のバージョン、stable または testing のチャネル。
• 操作、正確な手順、期待した結果、実際のエラー。
• タイムゾーン付きの時刻、手動または自動のモード、関係するサービスの状態、機密情報を除いたログの抜粋。
• 使い捨てのアプライアンスで再現するかどうかと、最後に正常に動いたバージョン。

ログやスクリーンショットから、パスワード、トークン、Cookie、非公開のホスト名やアドレス、ユーザーやゲストのデータを削除してください。xo-server と初回起動のログには、認証情報が含まれることがあります。設定のエクスポート、TLS の秘密鍵、設定ファイル全体は、決して添付しないでください。元の証拠は非公開で保管します。