Inaccessible vmware что делать

Обновлено: 07.07.2024

Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal

Зависшая блокировка файлов виртуальной машины VMware

Симптомы:
Внезапно пропал доступ к виртуалке на vmware, нет ни пинга, ни RDP.

В vCenter виртуалка vm-name в состоянии «недоступна», на вкладке Tasks&Events – ошибка «файл конфигурации недоступен». Состояние виртуалки меняется на разные степени недоступности (unknown/unaccessible) туда и обратно каждые секунд 10.

Лечение:
1) При попытке зайти в Browse Datastore – DS_name – каталог и файлы виртуалки есть. При попытке скопировать файлы виртуалки vm-name.vmx или vm-name.vmxf – тупит и говорит «ошибка копирования», без подробностей. Кроме того, есть файл блокировки vm-name.vmx

. Предполагая блокировку файлов, выводим в maintenance хост ESXi где она лежала (host13) – нормальные виртуалки с него съезжают, а эта так и остаётся. Перезагружаем, не дожидаясь завершения входа в режим обслуживания – результата нет. Видимо, это не тот хост.

2) Включаем (configuration – security profile – services) ssh и ESXi shell на произвольном хосте, в автостарт переводить не надо, просто запустить (options – start). Заходим на хост по ssh, смотрим что файлы точно есть:

vm-name-flat.vmdk vm-name_1-flat.vmdk
vm-name.nvram vm-name_1.vmdk
vm-name.vmdk vmware-1.log
vm-name.vmsd vmware-2.log
vm-name.vmx vmware.log
vm-name.vmx.lck vmx-vm-name-2489500763-1.vswp

Но все они заблокированы:

: Device or resource busy
touch: vm-name_1-flat.vmdk: Device or resource busy
touch: vmware.log: Device or resource busy
touch: vmx-vm-name-2489500763-1.vswp: Device or resource busy

Последний набор цифр из длинного GUID – это mac-адрес заблокировавшего хоста, 00:25:b5:06:0a:0e. Причем это, похоже, адрес первого адаптера eth0 – он не обязательно вообще участвует в сетевом трафике. Если вместо GUID одни нули – файл не заблокирован.

4) Методом перебора руками по Configuration – Network Adapters по всем хостам ESXi находим нужный хост, бывший владелец виртуалки, который никак её не отпустит. У нас это оказался host16. По идее, можно было бы его тоже перезагрузить и виртуалку бы отпустило, но мы пойдём более правильным путём. Не всегда перезагрузка хоста возможна из-за других виртуалок с RDM и т.п.

5) Де-регистрируем (не удаляем. 11!1), т.е. Remove from inventory, проблемную виртуалку. Зарегистрировать назад через vCenter оно не даёт – правой на .vmx файл, Add to inventory – неактивно. Заходим на хост, где пытались виртуалку запустить host13 при помощи vSphere Client напрямую. В виртуалках присутствует Unknown (unavailble) – так и должно быть по статье, смело дерегистрируем её, но никаких результатов это не даёт, ничего не меняется и зарегистрировать её по прежнему нельзя. Заходим на хост – последний владелец виртуалки host16 при помощи vSphere Client напрямую. На нём (и только на нём, а не на другом хосте или vCenter!) виртуалку можно зарегистрировать, что мы и делаем. Однако она, вместо нормального имени, регистрируется как Unknown (unavailble), включить её не получается, потому дерегистрируем назад.

6) Идём по статье дальше, включаем SSH и ESXi Shell на проблемном хосте – последнем владельце виртуалки host16, заходим на него по SSH. Смотрим, не осталось ли процессов, которые держат файлы виртуалки. Набор процессов конкретной виртуалки в терминологии VMware называется World. Запускаем:
esxcli vm process list
видим кучу запущенных виртуалок, в т.ч. нашу vm-name, здесь оно ещё помнит её по имени:

(…)
some-vm-1
World ID: 7100719
Process ID: 0
VMX Cartel ID: 7100718
UUID: 42 20 e7 a6 8b 37 ed 57-c8 c9 d5 1c 79 a1 c3 ba
Display Name: some-vm-1
Config File: /vmfs/volumes/549030ba-7ff1cf81-677b-002 5b5060a27/some-vm-1/some-vm-1.vmx

vm-name
World ID: 7100994
Process ID: 0
VMX Cartel ID: 7100993
UUID: 42 20 c4 55 06 c4 f6 a9-30 6e 61 a9 d2 39 d4 d5
Display Name: vm-name
Config File: /vmfs/volumes/549030ba-7ff1cf81-677b-002 5b5060a27/vm-name/vm-name.vmx

some-vm-2
World ID: 7100730
Process ID: 0
VMX Cartel ID: 7100727
UUID: 42 20 2d 16 90 d2 b1 4b-7d 79 d5 3c 38 48 45 ac
Display Name: some-vm-2
Config File: /vmfs/volumes/5490305f-51759a8e-fcd9-002 5b5060a27/some-vm-2/some-vm-2.vmx
(…)

Видим идентификатор мира, по которому можно убить все процессы виртуалки, что мы и делаем:
vm process kill --type=soft --world-id=7100994

процесс так сразу не убивается (soft), надо подождать пару минут.

8) Де-регистрируем (Remove from inventory) виртуалку на проблемном хосте, теперь с ней всё ок и её надо зарегистрировать на vCenter, что мы и делаем, в этот раз правой на файл .vmx – Add to inventory там активно. При регистрации vCenter ругается, что виртуалка с таким именем уже была, но зарегистрировать даёт. При включении виртуалки оно предупреждает, что он такую уже знал когда-то – и что вы с ней сделали? Ответ Move, который надо выбрать, сохраняет ID виртуалки и какие-то связанные с ним события для Operations Manager и т.п., в то время как ответ Copy (который выбирать не надо) сгенерирует новый ID.

9) Готово, виртуалку можно включать, мигрировать и т.п. – теперь с ней всё хорошо. Не забываем остановить ESXi Shell и ssh где запускали.

Однажды, ясным декабрьским днём, решила наша Компания приобрести новое «железо». Нет, конечно, это не случилось в одночасье. Решение было принято раньше. Намного раньше. Но, как водится, не всегда наши желания совпадают с возможностями акционеров. И денег не было, и мы держались. Но наконец-то наступил тот радостный момент, когда приобретение было одобрено на всех уровнях. Всё было хорошо, «белые воротнички» радостно аплодировали, надоело им на серверах 7-ми летней давности ежемесячно обрабатывать документы по 25 часов и они очень настойчиво просили Департамент ИТ придумать что-нибудь, чтобы подарить им больше времени для других, не менее важных дел.

Мы пообещали сокращение времени обработки документов в 3 раза, до 8 часов. Для этого выстрелили из пушки по воробьям. Этот вариант казался единственным, поскольку в нашей команде нет, и никогда не было, администратора баз данных для применения всевозможных оптимизаций запросов (DBA).

Конфигурация выбранного оборудования была, конечно, заоблачной. Это были три сервера от компании HPE — DL560 Gen10. Каждый из них мог похвастаться 4-я процессорами Intel Xeon Platinum 8164 2.0Ghz по 26 ядер, 256 DDR4 ОЗУ, а также 8 SSD 800Gb SAS (SSD 800Gb WD Ultrastar DC SS530 WUSTR6480ASS204) + 8 SSD 1,92Tb (Western Digital Ultrastar DC SS530).

Значит, приобрели мы данное оборудование и решили заменить давно устаревшее. Применили последний SPP к каждому новому серверу, установили в каждый из них по две сетевые карты Ethernet 10G (одну для пользовательских сетей, а вторую — для SAN, 656596-B21 HP Ethernet 10Gb 2-port 530T). Да, в комплекте с каждым новым сервером шла сетевая карта SFP+ без модулей, но у нас сетевая инфраструктура подразумевала Ethernet (два стэка коммутаторов DELL 4032N для сетей LAN и SAN), а модулей HPE 813874-B21 у дистрибьютора HP в Москве не оказалось и мы их так и не дождались.

Когда наступила пора установки ESXi и включения новых узлов в общий датацентр VMware, случилось «чудо». Как оказалось, HPE ESXi Custom ISO версии 6.5 и ниже не предназначен для установки на новые серверы Gen10. Только «хардкор», только 6.7. И пришлось нам невольно следовать заветам «виртуальной компании».

Был создан новый кластер HA+DRS, создан кластер vSAN, всё в непреклонном соответствии с VMware HCL и данным документом. Все было настроено по «феншую» и вызывали подозрение лишь периодические «тревоги» в мониторинге vSAN о ненулевых значениях параметров в данном разделе:

Мы, со спокойной душой, переместили все виртуальные машины (около 50 штук) на новые серверы и в новое хранилище vSAN, построенное уже на SSD дисках, проверили производительность обработки документов в новой среде (к слову, получилось сэкономить намного больше времени, чем планировали). Пока не перенесли самую тяжелую базу в новый кластер, операция, о которой упоминалось в начале статьи, заняла примерно 4 часа вместо 25-и! Это был весомый вклад в предновогоднее настроение всех участников процесса. Некоторые, наверное, начали мечтать о премии. Потом все радостно ушли на новогодние праздники.

Когда начались будни нового, 2019 года, ничто не предвещало катастрофы. Все сервисы, перенесенные на новые мощности, без преувеличения, взлетели! Только событий в разделе повторной синхронизации объектов стало намного больше. А через пару недель произошла беда. Ранним утром, практически все ключевые сервисы Компании (1с, MSSQL, SMB, Exchange и т.д.) перестали отвечать, либо начали отвечать с большой задержкой. Вся инфраструктура погрузилась в полный хаос, и никто не знал что произошло и что делать. Все виртуальные машины в vCenter выглядели «зелеными», никаких ошибок в их мониторинге не было. Перезагрузка не помогала. Более того, после перезагрузки, некоторые машины даже не смогли загрузиться, выдавая различные ошибки процесса в консоли. Казалось, Ад пришел к нам и дьявол потирал руки в предвкушении.

Находясь под давлением серьезного стресса, удалось определить источник беды. Этой проблемой оказалось распределенное хранилище vSAN. Случилось неконтролируемое повреждение данных на дисках виртуальных машин, на первый взгляд — безо всяких на то причин. На тот момент единственным решением, которое казалось рациональным, было обратиться в техническую поддержку VMware с криками: SOS, спасите-помогите!

И это решение, в последствии, и спасло Компанию от потери актуальных данных, включая почтовые ящики сотрудников, базы данных и общие файлы. В совокупности, речь идет о 30+ терабайтах информации.

Обязан отдать должное сотрудникам поддержки VMware, которые не стали «футболить» обладателя базовой подписки на техническую поддержку, а включили данный кейс в Enterpise сегмент, и процесс закрутился в круглосуточном режиме.

Что произошло дальше:

Технической поддержке VMware были поставлены два главных вопроса: как восстановить данные и как решить проблему «фантомного» повреждения данных в дисках виртуальных машин в «боевом» кластере vSAN. Кстати, данные некуда было восстанавливать, поскольку дополнительное хранилище было занято резервными копиями и разворачивать «боевые» службы было просто некуда.
Пока я, совместными усилиями с VMware, пытался собрать воедино «поврежденные» объекты в кластере vSAN, мои коллеги в срочном порядке добывали новое хранилище, способное вместить все 30+ терабайт данных Компании.
Меня ждали пять, почти бессонных ночей, когда сотрудники круглосуточной поддержки VMware из трех часовых поясов спрашивали меня, почему их встречаю лишь я и беспокоились насчет эффективности такого подхода, мол можно еще больше «накосячить» и совершить много лишних ошибок из-за сверх-сверх нормативного рабочего дня. Но ведь наши реалии вряд ли соответствуют западному пониманию, да?
Я обзавелся готовыми инструкциями в случае повторения данной ситуации.
Пришло понимание, где «собака зарыта» в данной проблеме.
Были восстановлены все виртуальные машины на появившееся благодаря подвигу коллег хранилище, кроме пары несущественных, которые были «воскрешены» из резервных копий на теперь доступное дисковое пространство.
Пришлось временно (на пару дней) пожертвовать работоспособностью почты, ради дополнительных 6 терабайт свободного пространства в хранилище, чтобы запустить ключевые сервисы, от которых зависел доход Компании.
Сохранены «на память» тысячи строк чата с англоязычными коллегами из VMware, вот коротенькая выдержка из наших разговоров:

Как эта проблема проявлялась (помимо наглухо упавших сервисов организации).

Экспоненциальный рост ошибок контрольной суммы (CRC) «на ровном месте» в процессе обмена данными с дисками в режиме HBA. Как это можно проверить — в консоли каждого узла ESXi ввести следующую команду:

В результате выполнения, вы сможете увидеть ошибки CRC по каждому диску в vSAN кластере данного узла (нулевые значения не будут отображаться). Если у вас имеются положительные значения, и более того, они постоянно растут, значит появилась причина постоянно возникающих задач в разделе Monitor -> vSAN -> Resincing objects, в кластере.

Как восстанавливать диски виртуальных машин, которые никак не клонируются и не мигрируют стандартными средствами?

Кто бы мог подумать, с помощью мощной команды «cat»:

Как узнать naa.хххх… дисков в дисковых группах:

Как узнать UUIDы vSAN по каждому naa.

И самое главное.

Проблема оказалась в некорректной работе прошивки RAID контроллера и драйвера HPE с vSAN.
Ранее, в VMware 6.7 U1, совместимая прошивка для контроллера HPE Smart Array P816i-a SR Gen10 в vSAN HCL значилась версии 1.98 (которая оказалась фатальной для нашей организации), а теперь там указана 1.65.
Более того, версия 1.99, которая решала проблему на тот момент (31 января 2019 года) уже была в закромах HPE, но они ее не передавали ни VMware ни нам, ссылаясь на отсутствие сертификации, несмотря на наши увещевания об отказе от ответственности и всё такое, мол нам главное решить проблему с хранилищем и всё.

В итоге, проблему удалось окончательно решить лишь через три месяца, когда вышла версия прошивки 1.99 для контроллера дисков!

Какие выводы я сделал?

У нас есть дополнительное хранилище (помимо обязательных резервных копий), на которое в случае чего можно мигрировать всем колхозом.
Не буду покупать самое свежее железо! Лучше годик подождать.
Не буду использовать всё доступное пространство ради «хотелок» бизнеса, буду начинать «ныть» о покупке новых «хранилок» сразу после того, как останется менее 30% свободного пространства на всех доступных «железках».
HPE, в лице местного представителя, так и не признала свою ошибку и ничем нам не помогла.
Я считаю, что вина в случившемся лежит полностью на:

HPE -эта компания показала во всей красе качество своей поддержки в критической ситуации. И в целом, количество багов в оборудовании Enterprise сегмента заставляет меня тревожиться за наше будущее. Конечно, это лишь моё мнение, и оно ни к чему не подталкивает).
Мне — не предусмотрел ситуацию, когда может понадобиться дополнительное дисковое пространство для размещения копий всех серверов Компании в случае нештатных ситуаций.

Вот и всё, ребята. Желаю вам никогда не попадать в такие жуткие ситуации.

В этой статье предоставляется решение проблемы, Windows VM не начинается с ошибки "INACCESSIBLE_BOOT_DEVICE" или "Сбой загрузки".

Оригинальная версия продукта: Виртуальная машина, Windows
Исходный номер КБ: 4010143

Признак

Windows не начинается и создает следующие ошибки:

Сбой загрузки. Перезагрузка и выбор правильного устройства загрузки или вставка мультимедиа загрузки в выбранном устройстве загрузки.

Компьютер столкнулся с проблемой, и его необходимо перезапустить. Мы перезапустим для вас. Если вы хотите узнать больше, вы можете найти в Интернете эту ошибку: INACCESSIBLE_BOOT_DEVICE

Причина

Эта проблема возникает по одной из следующих причин:

Данные конфигурации загрузки (BCD) повреждены.
Раздел, содержащий Windows, неактивный.

Остановка (де-выделение) и запуск VM

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

Чтобы устранить проблему, остановитесь (раздайте) и запустите VM, а затем перепроверяйте, сохраняется ли проблема. Если проблема сохраняется, выполните следующие действия:

Убедитесь, Windows раздел помечен как активный

Удаление виртуальной машины (VM). Убедитесь, что при этом выберите параметр Keep the disks.

Прикрепить диск ОС в качестве диска данных к другому VM (устранение неполадок). Дополнительные сведения см. в сайте How to attach a data disk to a VM Windows на портале Azure.

Подключение устранение неполадок. Управление диском open Computer > Management. Убедитесь, что диск ОС находится в сети и что его разделам назначены буквы дисков

Определите раздел Boot и раздел Windows. Если на диске ОС имеется только один раздел, этот раздел является разделом Boot и Windows разделом.

Если диск ОС содержит несколько разделов, их можно идентифицировать, просмотрев папки в разделах:

Раздел Windows папку с именем "Windows", и этот раздел больше остальных.

Раздел Boot содержит папку с именем "Boot". Эта папка скрыта по умолчанию. Чтобы увидеть папку, необходимо отобразить скрытые файлы и папки и отключить параметр Hide protected operating system files (Recommended). Раздел загрузки обычно составляет 300 МБ

Запустите следующую команду в качестве администратора, которая создаст запись загрузки.

Используйте DISKPART, чтобы проверить, активен ли Windows раздел:

Запустите следующую команду, чтобы открыть diskpart:

Перечислить диски в системе, а затем выбрать присоединенный диск ОС:

Перечислить том, а затем выбрать том, содержащий Windows папку.

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

Просмотр состояния раздела:

Если раздел активен, перейдите на шаг 2.

Если раздел не активен, запустите следующую командную строку для ее актива:

Затем снова detail partition запустите, чтобы проверить, активен ли раздел.

Отсоединить восстановленный диск от устранения неполадок. Затем создайте VM с диска ОС.

Восстановление данных конфигурации загрузки

Запустите следующую командную строку в качестве администратора для проверки целостности файловой системы и устранения логических ошибок файловой системы.

Запустите следующую командную строку в качестве администратора и зафиксировать идентификатор Windows загрузки (не Windows Boot Manager). Идентификатор — это код с 32 символами и выглядит так: xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxx. Этот идентификатор будет применяться на следующем шаге.

Ремонт данных конфигурации загрузки, задав следующие командные строки. Эти места необходимо заменить фактическими значениями:

Этот шаг применяется к большинству проблем с развращением данных конфигурации загрузки. Этот шаг необходимо выполнить, даже если устройство и OSDevice указывают на правильный раздел.

<Windows partition>это раздел, содержащий папку с именем "Windows".
<Boot partition> это раздел, содержащий скрытую папку системы с именем "Boot".
<Identifier>— идентификатор Windows загрузчик загрузки, найденный на предыдущем шаге.

Отсоединить отремонтированный диск ОС от устранения неполадок. Затем создайте новый VM с диска ОС.

05.02.2020

VMWare

комментариев 9

Довольно часто администраторы VMWare сталкиваются с тем, что в списке виртуальных машин присутствуют виртуальные машины со статусом Invalid (Unknown). Как правило эта проблема встречается после удаления виртуальной машиной, данные о которой почему-то остались в конфигурации vSphere/ESXi. Это также может случится при ручном удалении файлов виртуальной машины из VMFS хранилища, после выполнения VMotion и в ряде других случаев. Удалить такую ВМ из клиента vSphere Web Client штатными средствами не получится (пункт удаления в мeню Actions неактивен).

Единственный способ удалить такую ВМ – через SSH консоль хоста ESXi.

Также вы можете вручную удалить проблемную ВМ из файла конфигурации хоста /etc/vmware/hostd/vmInventory.xml. Для этого достаточно с помощью текстового редактора удалить секцию с данными проблемной ВМ в файле vmInventory.xml (предварительно создайте резервную копию этого файла) и перезапустить службы хоста: services.sh restart

В том случае, если статус Invalid появился у работающей виртуальной машины, скорее всего это значит, что поврежден файл конфигурации ВМ. Для исправления проблемы нужно:

Удалите ВМ из инвентари и перезагрузите ESXi хост.
После этого создайте новую ВМ и подключите к ней виртуальные диски старой ВМ (Use an existing disk).
Сделайте Storage VMotion, чтобы собрать все файлы новой ВМ в одной папке,
Включите новую ВМ и проверьте, что она работает.
Удалите файлы старой ВМ.

Если проблема с Invalid ВМ возникла после пропадания доступа к VMFS хранилищам, то после восстановления доступа включенные ВМ продолжат свою работу, а выключенные виртуальные машины станут изолированными. Такие ВМ нужно вручную удалить из Inventory и вручную зарегистрировать, найдя vmx файл виртуальной машины на VMFS хранилище, щелкнув ПКМ по ВМ и выбрав пункт Register VM. После этого включите ВМ и проверьте, что она доступна.

Читайте также: