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

Question

Я пишу это после того, как сам нашел решение, потому что это была настолько странная «ошибка», что она заслуживает того, чтобы ее задокументировать.

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

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

Судя по отображению на локальной консоли сервера, ESXi загружается нормально, но при этом наблюдается множество проблемных симптомов:

• Не удалось войти в систему с помощью vSphere Client, который выдал сообщение: «vSphere Client не удалось подключиться кхозяин. Произошла неизвестная ошибка соединения. (Запрос не выполнен из-за сбоя соединения. (Не удалось подключиться к удаленному серверу))”.

• В журнале клиента vSphere обнаружена ошибка:

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

• При попытке входа на сервер с помощью веб-браузера браузер сообщил, что соединение отклонено.

• Не удалось подключиться к серверу по SSH даже после включения этой функции на локальной консоли.

• Перезапуск сети управления и агентов управления через локальную консоль не помог.

• На локальной консоли discover hostdне был запущен, и перезагрузка не помогла исправить ситуацию.

• esxcliкоманды всегда давали:Connect to localhost failed: Connection failure

• Каталогов оказалось меньше, /vmfs/volumesчем ожидалось, и ни один из них не был похож на мое хранилище данных.

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

Резервная копия, с которой я восстанавливался, была низкоуровневым образом логического диска RAID, сделанным при выключенном сервере. После удаления потенциально поврежденного массива RAID и его повторного создания я использовал отдельный диск, подключенный к HBA, для загрузки физической установки Windows Server, чтобы скопировать образ на новый RAID. Я использовал HDD Raw Copy Tool изhddguru.com, которая по сути является менее загадочной и сложной альтернативой команде Linux dd.

(Это, безусловно, варварский — хотя и довольно полный — способ резервного копирования VMware, но этот диск в основном хранит только загрузочные/системные диски VM, а не данные, так что его резервное копирование в любом случае выполняется нечасто, за исключением случаев внесения серьезных изменений. У нас есть гораздо лучшие системы резервного копирования для основных данных.)

Я сделал новый логический диск RAID больше, чем тот, который был скопирован, так как мы перешли на более крупные диски в RAID, и хранилище данных было немного заполнено. Я планировал увеличить хранилище данных, после того как убедился, что резервное копирование работает.

Не успел я сделать сырую копию, как загрузился в ESXi и обнаружил, что он сломался. Что случилось?!

Это довольно старый ESXi 5.0 U3. (Он прекрасно удовлетворяет наши текущие потребности, и у нас нет штатного ИТ-персонала, который мог бы управлять обновлениями ради обновлений, устранять часто возникающие из-за них проблемы и т. д.)

Answer 1

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

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

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

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

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

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

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

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

Первопричина

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

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

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

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

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

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

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

1. Убедитесь, что диск находится в состоянии «Автономный» в оснастке «Управление дисками» консоли MMC (в качестве меры предосторожности).
2. Откройте диск в шестнадцатеричном редакторе. В HxD он находится подДополнительно→Открыть диск...и вам нужно выбрать его из «Физических дисков». Обязательно снимите флажок «Открыть как только для чтения», который включен по умолчанию. Вы получите соответствующее предупреждение об опасности.
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. Вы можете вычислить его с помощью онлайн‑калькулятораздесь, обязательно установите «Тип ввода» на hex. Поместите это в заголовок GPT в little-endian в 58h.
6. Временно поместите ноль в четыре байта заголовка GPT по адресу 10h.
7. Возьмите CRC32 заголовка, длина которого указана в самом заголовке двойным словом в 0Ch. Поместите это в заголовок в 10h.
8. Повторите шаги с 3 по 7 для резервной копии GPT. Массив и его CRC будут такими же, поэтому вы можете просто скопировать их, но заголовок будет другим и, следовательно, иметь другой CRC. Заголовок для резервной копии обычно находится в самом последнем секторе диска, с массивом непосредственно перед ним, но технически вы должны проверить quadword 20h в основном заголовке GPT и quadword 48h в резервной копии заголовка для подтверждения.
9. Если выполностью уверенвы все сделали правильно, нажмите Save. Опять же, HxD выдаст вам соответствующее предупреждение.

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

Скриншоты

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

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

Исход

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

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

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

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