バックアップからブートドライブにコピーした後、ESXi 管理が失敗し、接続が拒否される

Question

私は自分で解決策を見つけたのでこれを書いています。これは非常に奇妙な「落とし穴」だったので、文書化する価値があるからです。

復元中にこの問題に遭遇しましたが、ESXi インストールのブート ドライブがシステムに接続されているときに別のオペレーティング システムを起動する場合、特にディスク サイズが変更された場合に、この問題が発生する可能性があります。

私は最近、VMware ESXi インストールのブート ドライブを復元しました。これには、ほとんどの VM とその仮想ブート/システム ディスクを保持するデータストアも含まれていましたが、この正常な状態が何らかの理由で壊れていることがわかりました。

サーバーのローカル コンソールの表示によると、ESXi は正常に起動しているように見えましたが、多くの問題のある症状が現れていました。

• vSphere Clientでログインできず、「vSphere Clientは接続できませんでした」というメッセージが表示されました。ホスト不明な接続エラーが発生しました。(接続障害のため、要求は失敗しました。(リモート サーバーに接続できません))」。

• vSphere Client のログに次のエラーが含まれていました:

  System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it

• Web ブラウザを使用してサーバーにログインしようとしましたが、ブラウザは接続が拒否されたと報告しました。

• ローカル コンソールでこれを有効にした後でも、サーバーに SSH 接続できませんでした。

• ローカル コンソール経由で管理ネットワークと管理エージェントを再起動しても問題は解決しませんでした。

• ローカル コンソールでは、hostd実行されていないことが検出され、再起動しても修正されませんでした。

• esxcliコマンドは常に次のように与えられました:Connect to localhost failed: Connection failure

• 予想よりもディレクトリが少なく/vmfs/volumes、そのどれもが私のデータストアのいずれでもないように見えました。

• ローカル UI の「システム構成をリセット」でも問題は解決しませんでした。(問題を解決した後に復元できる正常なイメージがあったため、これを試しただけですが、何かが変わったかどうかはわかりません。)

私が復元したバックアップコピーは、サーバーがダウンしている状態で取得したRAID論理ディスクの低レベルイメージでした。破損している可能性のあるRAIDアレイを削除して再作成した後、HBAに接続された別のドライブを使用して物理的なWindows Serverインストールを起動し、イメージを新しいRAIDにコピーしました。ホームページこれは基本的に、Linux コマンドよりも難解で難しいものではない代替手段ですdd。

(これは確かに VMware をバックアップする方法としては野蛮ですが、かなり完全なものです。しかし、このディスクには主に VM のブート/システム ディスクのみが保存され、データは保存されないため、大きな変更を行う場合を除いて、あまり頻繁にバックアップされることはありません。プライマリ データには、はるかに優れたバックアップ システムがあります。)

RAID 内のより大きなドライブにアップグレードしたため、データストアが少しいっぱいになっていたため、新しい RAID 論理ディスクをバックアップしたものよりも大きくしました。バックアップが機能していることを確認した後、データストアを拡張することを計画していました。

生のコピーが完成してすぐに ESXi を起動すると、エラーが発生していました。何が起こったのでしょうか?

これはかなり古い ESXi 5.0 U3 です。(現在のニーズを十分に満たしており、アップグレードのためにアップグレードを管理したり、アップグレードによって頻繁に発生する問題を修正したりするフルタイムの IT スタッフがいません。)

Answer 1

私の場合、損傷は Windows から発生した可能性がありますが、他のソフトウェアでも同じ問題が発生する可能性があります。

これは間違いなく ESXi 5.0 U3 に当てはまり、おそらくすべての ESXi 5.x にも当てはまり、おそらくすべての ESXi 6.x にも当てはまると思います。異なる、よりシンプルなパーティション レイアウトを使用する ESXi 7 には当てはまらない可能性はあります。

調査の背景

ようやく理解し始めたとき、私は新規インストールを実行するところだった。

をいろいろ調べていると、奇妙なことに、すべてのディレクトリにファイルが含まれていて、その中にWindows エクスプローラーのシェル拡張と一致する内容が含まれてい/vmfs/volumesたことに気づきました。これは、Windows ベースではない、またこれまで Windows ベースになったことのないハイパーバイザーのシステム パーティションで見つかるというのは、少し奇妙です。$RECYCLE.BINDESKTOP.INI

ディスクイメージにコピーしたWindows OSが何かしたのではないかとすぐに疑いました。ESXiはブートディスクに複数のFATパーティションを使用しているため、Windowsがそれらを操作している可能性があります。ディスクイメージは既知の正常な状態から取得されたものの、何もせずに失敗したことを考えると、内でESXi の場合、これが最も有望な調査方法であるように思われました。

16 進エディターでこれらの$RECYCLE.BINディレクトリがディスク イメージにも表示されていることに気付いたとき、最初はがっかりしました。最初は、イメージが作成される前から Windows Server ですでに損傷が発生していたのだと思いました。しかし、これらは無害であることが判明しましたが、正しい方向に導いてくれました。Windows は、まだサイズアップされていない元の論理ディスクを見つけるとすぐにこれらを追加した可能性があります。しかも、ディスクはずっと「オフライン」に保たれていたにもかかわらずです。

16進エディタでさらに調べてみると（HxD - 16 進エディターとディスク エディター（本当に優れたツール）は、ディスクイメージのGPTパーティションテーブルと新しいRAIDディスク上のGPTパーティションテーブルの間に奇妙な小さな違いがあることを明らかにしました。これはパーティションエディタでは表示されない違いです。実際には論理的に違いはない私の知る限りでは、これを見つけるには、生の 16 進ダンプ内を探し回らなければなりません。

根本的な原因

どちらの場合も、パーティション配列には 7 つの空でないエントリがありました。ただし、ESXi が最初に配列を書き込んだ方法では、最初の 3 つのエントリの後に 1 つの空のエントリ (128 バイトすべてがゼロ) のギャップがあり、最後の 4 つの有効なエントリが独自の 512 バイト セクターに収まっていました。ESXi が壊れたライブ ディスクでは、ギャップを埋めるために最後の 4 つの有効なエントリが 1 つ上にシフトされていました。エントリはそれ以外は同一でした。

これをWindowsが行ったのか、HDD Raw Copy Toolが行ったのかは分かりませんが、Windowsが原因だと疑っています。再度テストしたところ、この変更は存在するようです。すぐにコピー中およびコピー後にディスク管理 MMC スナップインで RAID 論理ドライブが「オフライン」になっている場合でも、コピーが完了すると、RAID 論理ドライブは自動的にバックアップされます。CRC はすべて正しく、バックアップ GPT も同様に変更されているため、これは明らかに意図的な変更です。

私の理論では、これを実行している人は、ディスクのサイズと一致しないため GPT を書き換えており、既存の配列を正確にコピーするのではなく、パーティションを何らかの内部構造のリストとして記憶し、配列を直接書き換えているため、もちろんギャップは生成されないということです。

補足として、ESXi によって書き込まれた配列内のエントリは、パーティションがディスク上で物理的に発生する順序と同じではありませんでしたが、そのギャップを埋めたプログラムが何であれ、少なくともエントリを勝手に並べ替えることはなかったのはありがたいことです。

手動修正

このギャップを再現する簡単な方法は知りません。一般的に、どのパーティション エディターでも同じことを行うからです。つまり、既存のテーブルをツールが使用する内部表現に変換し、その表現に対して要求された変更を行い、正しいデータが含まれるようにテーブルを GPT 形式で書き戻します。私の知る限り、配列エントリのディスク上の正確な位置は関係ないはずなので、書き戻される「正しいデータ」の一部にはなりません。

しかし、ESXi は正確なアレイ レイアウトに関して気難しいかもしれないという予感がしたので、手動で修正して何が起こるか確認することにしました。手順は次のとおりです。

1. ディスク管理 MMC スナップインでディスクが「オフライン」になっていることを確認します (予防措置として)。
2. ディスクを16進エディタで開きます。HxDでは、特典→ディスクを開きます...「物理ディスク」から選択する必要があります。デフォルトでオンになっている「読み取り専用で開く」のチェックを必ず外してください。これが危険であるという適切な警告が表示されます。
3. プライマリ GPT の配列は通常 LBA 2 から始まり (ヘッダーの 48h のクワッドワードで確認)、範囲をコピーし、さらに下に貼り付けてギャップをゼロにすることで、ギャップの後にあるはずのエントリをスライドダウンします。さらに良い方法は、バックアップ イメージがある場合は、そこから実際のテーブルをコピーすることです。ただし、LUN のサイズが変更されている場合は、GPT ヘッダーをコピーするだけでは不十分であることに注意してください。そうしないと、ヘッダーのフィールド 20h と 30h の値が誤っているため、状況が繰り返される可能性があります。
4. を選択全体GPT の配列の範囲。技術的には、GPT ヘッダーの 50h と 54h のダブルワードの積を使用して範囲を決定する必要がありますが、この数値は通常 16,384 バイトになります。
5. 手順4で選択した範囲のCRC32を取得します。UEFI仕様でCRC32アルゴリズムの数学的パラメータを見つけることができませんでしたが、ISO 802-3の04C11DB7hという通常の多項式を持つ非常に一般的なものであることがわかりました。オンライン計算機で計算できます。ここ「入力タイプ」を必ず 16 進数に設定してください。これをリトルエンディアン形式で 58h の GPT ヘッダーに配置します。
6. GPT ヘッダーの 10h の 4 バイトに一時的にゼロを配置します。
7. ヘッダーの CRC32 を取得します。その長さは、ヘッダー自体の 0Ch のダブルワードによって指定されます。これをヘッダーの 10h に配置します。
8. バックアップ GPT についても手順 3 から 7 を繰り返します。アレイとその CRC は同じなので、これらをコピーするだけでかまいませんが、ヘッダーが異なるため CRC も異なります。バックアップのヘッダーは通常、ディスクの最後のセクターにあり、アレイはその直前にありますが、技術的にはプライマリ GPT ヘッダーのクワッドワード 20h とバックアップ ヘッダーのクワッドワード 48h をチェックして確認する必要があります。
9. もしあなたが〜なら完全に確信しているすべて正しく実行したら、[保存] をクリックします。ここでも、HxD は適切な警告プロンプトを表示します。

ご相談はウィキペディアの記事GPT 形式の基本的な技術的詳細については、こちらをご覧ください。

スクリーンショット

「壊れた」 GPT 配列の一部は次のようになります。有効なエントリは 77Fh で終了し、それより前にはゼロが長く続かないことに注意してください。

これを修正した方法は次のとおりです。有効なエントリが 7FFh で終了することに注意してください。

結果

私はこれがうまくいくとは思っていませんでした。勉強はしていませんが、UEFI仕様では配列エントリの順序や間隔に意味がないと予想しています。実際、すべてのパーティションには一意のGUIDがあります。正確にそうすればしないこのような脆弱なヒューリスティックに頼らざるを得ません。したがって、テーブルを書き込んだときと同じ配列インデックスに依存するのは、悪い考えです。

^{(そうは言っても、エンタープライズ レベルのソフトウェアとファームウェアが誤ったアイデアを採用しているのを見るのはこれが初めてではありません。システム管理者の立場でいると、毎回、目もくらむほど愚かなプログラミングに直面することになりますが... 文句を言うのはやめておきます。)}

そこで、慎重に調整したテーブルを保存し、RAID を再起動して ESXi を起動し、vSphere Client を接続すると、すべて正常に戻りました。

理想的には、Veeam Backupのようなものを使用する方が良いのですが、状況によってはこのために解決策が適切である可能性があり、その場合、このバグに遭遇する可能性があります。