Сбой управления ESXi, отказ в подключении после копирования загрузочного диска из резервной копии

В моем случае повреждение могло быть вызвано Windows, но другое программное обеспечение могло вызвать ту же проблему.

Это определенно относится к ESXi 5.0 U3 и, вероятно, к любому ESXi 5.x, и я предполагаю, что возможно к любому ESXi 6.x. Это вряд ли применимо к ESXi 7, в котором используется другая, более простая структура разделов.

Предпосылки исследования

Я был очень близок к выполнению новой установки, когда, наконец, начал разбираться в ней.

Покопавшись в / vmfs / volume , я заметил одну странную вещь: во всех из них были каталоги $ RECYCLE.BIN , и они содержали DESKTOP. INI файлы, содержимое которых соответствует расширениям оболочки Windows Explorer. Это немного странно найти в системных разделах гипервизора, который не основан и никогда не был основан на Windows.

У меня сразу возникло подозрение, что операционная система Windows, которую я использовал для копирования образа диска, что-то с этим сделала. ESXi использует несколько разделов FAT на своем загрузочном диске, поэтому, возможно, Windows может с ними играть. Учитывая, что образ диска был взят из заведомо исправного состояния, но произошел сбой без каких-либо действий в ESXi, это казалось наиболее многообещающим направлением исследования.

Сначала я был встревожен, когда с помощью шестнадцатеричного редактора обнаружил, что эти каталоги $ RECYCLE.BIN также появляются в образе диска. Сначала я решил, что это означает, что ущерб был нанесен еще до того, как изображение было снято - также в Windows Server. Однако они оказались добрыми, хотя и привели меня в правильном направлении.Скорее всего, Windows добавила их, как только увидела исходный логический диск, размер которого еще не был увеличен, и несмотря на то, что диск все время находился в автономном режиме.

Дальнейшее копание в шестнадцатеричном редакторе ( HxD - Hex Editor and Disk Editor , действительно хороший инструмент) выявило одну странную небольшую разницу между таблицей разделов GPT в образе диска и таблицей, живущей на новом. RAID-диск. Это не та разница, которую мог бы показать редактор разделов, потому что , насколько мне известно, на самом деле не имеет никакого значения логически . Это то, что вам нужно будет найти в необработанном шестнадцатеричном дампе.

Основная причина

В обоих случаях в массиве разделов было семь непустых записей. Однако, как и при первоначальной записи массива в ESXi, после первых трех записей был пробел в одну пустую запись (все 128 байтов были обнулены), так что последние четыре действительных записи попадали в свой собственный 512-байтовый сектор. На живом диске, где был запущен ESXi, последние четыре действительных записи были сдвинуты на одну запись вверх, чтобы закрыть пробел. В остальном записи были идентичны.

Я не знаю, кто это сделал, Windows или HDD Raw Copy Tool, но подозреваю Windows. Я проверил его снова, и это изменение будет присутствовать сразу после завершения копирования, даже если логический диск RAID находится в состоянии «Offline» в оснастке Disk Management MMC во время и после копирования. Это явно преднамеренное изменение, потому что все CRC верны, и резервный GPT также изменен.

Моя теория заключается в том, что тот, кто это делает, переписывает GPT, потому что он не соответствует размеру диска, и что вместо того, чтобы просто копировать существующий массив в точности, он запоминает разделы как список в некоторой внутренней структуре и затем просто переписываете массив, что, конечно же, не создает пробелов.

В качестве примечания, записи в массиве, записанные ESXi, не были в том же порядке, что и разделы физически расположены на диске, но какая бы программа ни закрывала пробел, по крайней мере, не позволяла сортировать записи. Тоже к счастью!

Ручное исправление

Я не знаю простого способа воссоздать этот пробел, потому что обычно любой редактор разделов будет делать то же самое: преобразовать существующую таблицу во внутреннее представление, используемое инструментом, выполнить изменения, которые вы запрашиваете в этом представлении, а затем снова запишите таблицу в формате GPT, чтобы в ней были правильные данные. Насколько я знаю, точное расположение записей массива на диске не должно иметь отношения к делу и поэтому не будет частью упомянутых «правильных данных», которые он записывает обратно.

Однако у меня было подозрение, что ESXi может быть привередливым к точному расположению массива, поэтому я решил исправить это вручную, чтобы посмотреть, что произойдет. Процедура была следующей:

1. Убедитесь, что диск находится в «Offline» в оснастке Disk Management MMC (в качестве меры предосторожности).
2. Откройте диск в шестнадцатеричном редакторе. В HxD это под Extras → Open disk ... , и вы должны выбрать его из «Physical disks». Обязательно снимите флажок «Открыть только для чтения», который по умолчанию включен.Вы получите соответствующее предупреждение об опасности.
3. В основном массиве GPT, который обычно начинается с LBA 2 (подтверждение в четвертом слове заголовка на 48h), сдвиньте вниз записи, которые должны быть после пробела, скопировав диапазоны, вставив дальше вниз, а затем обнуляя пробел. .А еще лучше просто скопируйте настоящую таблицу из резервной копии, если она у вас есть; но обратите внимание, что если размер LUN изменился, вы не можете просто скопировать в заголовок GPT, иначе ситуация может повториться, поскольку этот заголовок будет иметь неправильные значения для полей 20h и 30h.
4. Выберите весь диапазон массива GPT. Технически вам нужно определить диапазон, используя произведение двойных слов в 50h и 54h в заголовке GPT, но это число обычно составляет 16 384 байта.
5. Возьмите CRC32 диапазона, выбранного на шаге 4. Я не смог найти математические параметры алгоритма CRC32 в спецификации UEFI, но смог выяснить, что это очень распространенный, тот, что в ISO 802 ‑3 с нормальным полиномом 04C11DB7h. Вы можете вычислить его с помощью онлайн-калькулятора здесь , не забудьте установить «Тип ввода» на шестнадцатеричный. Поместите это в заголовок GPT с прямым порядком байтов в 58h.
6. Временно поместите ноль в четыре байта заголовка GPT в 10h.
7. Возьмите CRC32 заголовка, длина которого указана в самом заголовке двойным словом 0Ch. Поместите это в заголовок на 10ч.
8. Повторите шаги с 3 по 7 для резервного GPT. Массив и его CRC будут такими же, поэтому вы можете просто скопировать их, но заголовок будет другим и, следовательно, будет иметь другой CRC. Заголовок для резервной копии обычно находится в самом последнем секторе диска с массивом непосредственно перед ним, но технически вы должны проверить четверное слово 20h в основном заголовке GPT и четырехслово 48h в заголовке резервной копии для подтверждения.
9. Если вы полностью уверены , что все сделали правильно, нажмите «Сохранить». Опять же, HxD выдаст вам соответствующее предупреждение.

Вы можете обратиться к статье Википедии для получения основных технических деталей формата GPT.

Скриншоты

Вот как выглядела часть «сломанного» массива GPT; обратите внимание, что действительные записи заканчиваются на 77Fh и до этого времени нет длинных серий нулей:

Вот как я это исправил; обратите внимание, что действительные записи теперь заканчиваются на 7FFh:

Outcome

Я не ожидал, что это сработает. Я не изучал это, но ожидал, что спецификация UEFI не придает значения порядку или интервалу записей массива. Фактически, каждый раздел имеет уникальный идентификатор GUID , а именно , так что вам не придется полагаться на такую ​​хрупкую эвристику. Таким образом, в зависимости от того, какие индексы массива были бы такими же, как при написании таблицы, было бы плохой идеей.

^{(Опять же, это не первый раз, когда я вижу, как программное обеспечение и микропрограммное обеспечение корпоративного уровня выдвигает плохие идеи. Кажется, каждый раз, когда я надеваю шляпу системного администратора, я сталкиваюсь с одной еще одна ослепительно глупая часть программирования ... но позвольте мне не разглагольствовать.)}

Итак, я осторожно сохранил измененную таблицу, загрузился обратно на RAID, запустился ESXi, подключился клиент vSphere и все вернулось к норме.

В идеале обычно лучше использовать что-то вроде Veeam Backup, но в некоторых ситуациях могут подойти и другие специальные решения, и в этом случае вы можете столкнуться с этой ошибкой.