Vmware esxi остановился при загрузке на nfs4client и дальше не загружается
Ранее установленный софт
Очень часто причиной зависания виртуальной машины на ESXI 6.5 выступает недавняя установка обновлений в системе или различного рода программного обеспечения. Обязательно посмотрите в "Панель управления\Все элементы панели управления\Программы и компоненты" по дате установки, что недавно было проинсталлировано.
Тут же можно посмотреть установленные обновления. Недавно Microsoft выпустило обновление KB4015553 (Со временем может меняться), которое в Windows Server 2012 R2 стало вызывать зависание. Необходимо удалить KB4015553, kb4019215 и kb4019217, перезагрузить ваш сервер.
Сама компания Symantec рекомендует в ветке (https://support.symantec.com/en_US/article.TECH236543.html) Исключите из проверки следующий каталог, включая все подкаталоги: путь зависит от вашей версии SEP: "C:\ProgramData\Symantec\Symantec Endpoint Protection\\Data\Definitions". Пример для SEP 14.0 MP1: C:\ProgramData\Symantec\Symantec Endpoint Protection\14.0.2332.0100.105\Data\Definitions. Если вышеуказанное исключение не решает проблему, также исключите следующий каталог: C:\Windows\rescache.
Эти пути могут отличаться в зависимости от сборки продукта или от того, что каталоги ProgramData или Windows были перемещены на другой диск.
Сделать, это можно в "Change Settings - Exception - SONAR Exception" нажимаем кнопку "Add" и выбираем нужные каталоги.
Описание проблемной виртуальной машины
Как я и писал выше, виртуальная машина намертво зависла, по RDP или ping она была не доступна. Гостевой операционной системой была Windows Server 2012 R2. Попытавшись запустить Web Console из интерфейса vCenter Server, виртуальная машина ни на что не реагировала.
Висит задача create virtual machine snapshot
Еще в своей практике встречал ситуации, что из-за незаконченного задания у меня не выполнялось резервное копирование, задание висело со статусом "create virtual machine snapshot"
Диагностика зависшей виртуальной машины
Первым делом, чтобы восстановить сервис, вам необходимо принудительно перезагрузить виртуальную машины, для этого щелкните по ней правым кликом мыши и выберите пункт "Power - Reset".
После того, как операционная система в ней загрузится, я вам советую начать изучение логов Windows. Открываем просмотр событий и делаем поиск ошибок и предупреждений. Мне удалось найти два события, которые косвенно говорили, что проблема с зависанием виртуальной машины связана непосредственно с операционной системой и возможными проблемами с поврежденными системными файлами или драйверами Vmware Tools. Первое событие:
Так же можно обнаружить и ошибки вот такого рода, которые так же заставляю виртуальную машину флапать, зависать с черным экраном.
Данное событие связано с сетевым интерфейсом типа E1000, советую его поменять на паравиртуализованный VMXNET3. E1000 кушает больше ресурсов процессорных мощностей и так же более капризный, но за то не требует установки Vmware Tools.
Так же вы можете посмотреть логи самой виртуальной машины на уровне Vmware ESXI 6.5. Я нашел там вот такую выборку:
2019-05-14T11:06:41.739Z| vmx| I125: GuestMsg: Channel 0, Cannot unpost because the previous post is already completed
2019-05-14T11:08:48.012Z| svga| I125: MKSScreenShotMgr: Taking a screenshot
2019-05-14T11:08:53.849Z| mks| I125: SOCKET 1396535 (189) Creating VNC remote connection.
2019-05-14T11:08:53.849Z| mks| I125: MKSControlMgr: New VNC connection 1
2019-05-14T11:08:53.912Z| mks| W115: VNCENCODE 1396535 failed to allocate VNCBlitDetect
2019-05-14T11:08:53.912Z| mks| I125: VNCENCODE 1396535 VNCEncodeChooseRegionEncoder: region encoder adaptive. Resolution: 1024 x 768
2019-05-14T11:08:54.289Z| vmx| I125: Tools_SetGuestResolution: Sending rpcMsg = Resolution_Set 1920 863
2019-05-14T11:08:54.630Z| vcpu-7| I125: VMMouse: CMD Read ID
2019-05-14T11:09:54.289Z| vmx| I125: GuestRpcSendTimedOut: message to toolbox timed out.
2019-05-14T11:10:07.476Z| svga| I125: MKSScreenShotMgr: Taking a screenshot
2019-05-14T11:10:19.546Z| mks| I125: SOCKET 1396535 (189) recv error 0: Success
2019-05-14T11:10:19.546Z| mks| I125: SOCKET 1396535 (189) VNC Remote Disconnect.
2019-05-14T11:10:19.546Z| mks| I125: MKSControlMgr: Remove VNC connection 1
2019-05-14T11:10:31.357Z| vmx| I125: VigorTransportProcessClientPayload: opID=HardPowerOpsResolver-applyOnMultiEntity-5384149-ngc:70276545-fb-c5-9d61 seq=2571570: Receiving Sched.SetResourceGroup request.
2019-05-14T11:10:31.357Z| vmx| I125: VigorTransport_ServerSendResponse opID=HardPowerOpsResolver-applyOnMultiEntity-5384149-ngc:70276545-fb-c5-9d61 seq=2571570: Completed Sched request.
2019-05-14T11:10:31.358Z| vmx| I125: VigorTransportProcessClientPayload: opID=HardPowerOpsResolver-applyOnMultiEntity-5384149-ngc:70276545-fb-c5-9d61 seq=2571571: Receiving PowerState.InitiateReset request.
2019-05-14T11:10:31.358Z| vmx| I125: Vix: [8790361 vmxCommands.c:686]: VMAutomation_Reset. Trying hard reset
2019-05-14T11:10:31.358Z| vmx| W115:
2019-05-14T11:10:31.358Z| vmx| W115+
2019-05-14T11:10:31.358Z| vmx| W115+ VMXRequestReset
2019-05-14T11:10:31.358Z| vmx| I125: Vigor_Reset: Attaching to reset.
2019-05-14T11:10:31.358Z| vmx| I125: Stopping VCPU threads.
2019-05-14T11:10:31.360Z| vcpu-0| I125: VMMon_WaitForExit: vcpu-0: worldID=9507337
2019-05-14T11:10:31.360Z| vcpu-7| I125: VMMon_WaitForExit: vcpu-7: worldID=9507347
2019-05-14T11:10:31.360Z| vcpu-3| I125: VMMon_WaitForExit: vcpu-3: worldID=9507343
2019-05-14T11:10:31.360Z| vcpu-1| I125: VMMon_WaitForExit: vcpu-1: worldID=9507341
2019-05-14T11:10:31.360Z| vcpu-5| I125: VMMon_WaitForExit: vcpu-5: worldID=9507345
2019-05-14T11:10:31.360Z| vcpu-10| I125: VMMon_WaitForExit: vcpu-10: worldID=9507350
2019-05-14T11:10:31.360Z| vcpu-9| I125: VMMon_WaitForExit: vcpu-9: worldID=9507349
2019-05-14T11:10:31.360Z| vcpu-8| I125: VMMon_WaitForExit: vcpu-8: worldID=9507348
2019-05-14T11:10:31.360Z| vcpu-6| I125: VMMon_WaitForExit: vcpu-6: worldID=9507346
2019-05-14T11:10:31.360Z| vcpu-4| I125: VMMon_WaitForExit: vcpu-4: worldID=9507344
2019-05-14T11:10:31.360Z| vcpu-2| I125: VMMon_WaitForExit: vcpu-2: worldID=9507342
2019-05-14T11:10:31.360Z| vcpu-11| I125: VMMon_WaitForExit: vcpu-11: worldID=9507351
2019-05-14T11:10:31.360Z| svga| I125: SVGA thread is exiting
2019-05-14T11:10:31.360Z| vmx| I125: MKS thread is stopped
2019-05-14T11:10:31.361Z| vmx| I125:
2019-05-14T11:10:31.361Z| vmx| I125+ OvhdMem: Final (Power Off) Overheads
Алгоритм установки гипервизора VMware ESXI 6.5
Хочу отметить, что существуют несколько методов достижения нашей поставленной цели, которые могут инсталлировать данную операционную систему:
- Первый метод, это установка ESXi 6.5 с помощью установочного диска записанного на болванку. Тут вы вольны использовать любую программу для записи на диск, например, UltraISO. После чего вставляете диск и загружаетесь с него, не забываем его выбрать в качестве основного устройства загрузки в BIOS.
- Второй метод. это использование ISO образа с дистрибутивом. который мы будем использовать в KVM-консоли, доступной на портах управления (IMM, IDRAC, ILO, IPMI), примеры монтирования вы можете посмотреть по ссылкам.
- Третий метод установки Vmware ESXI 6.5, заключается в использовании виртуального CD-ROM Zalman, который умеет монтировать ISO образы, данный метод похож на первый, тут только в качестве основного устройства в BIOS нужно выбрать именно Virtual-Zalman
- Четвертый метод, это использование загрузочной флешки или SD карты, так же подразумевает создание загрузочной флешки Vmware 6.5 1 методом или вторым, с последующей загрузкой в BIOS с нее.
- Пятый метод, это установка по сети, через PXE сервер. Тут вам придется создать специальный сервер, на котором будет выложен дистрибутив с гипервизором, об этом я подробно рассказывал.
Когда вы выбрали метод загрузки дистрибутива Vmware ESXI 6.5, можно приступать к его установке, сама инсталляция во всех методах одинакова. Загрузившись с вашего носителя, у вас появится вот такое синее окно инсталлятора, тут будет два пункта:
- ESXI-6.5.0-standard installer - собственно сама установка, выбираем данный пункт
- Boot from local disk - загрузка с локального диска
У вас появится окно загрузчика "Load ESXi installer", тут можно выбрать старую версию загрузчика или же продолжить установку, нажав Enter.
Начинается процесс подгрузки в оперативную память необходимых файлов Vmware ESXI 6.5 инсталлятора.
Через пару мгновений у вас появится привычный серо-желтый экран, в котором будут загружаться библиотеки и пакеты, тут вы увидите версию релиза, количество вашей ОЗУ и CPU.
Если у вас будет в сервере оперативной памяти меньше, чем 4 ГБ, то вы увидите вот такое пурпурное окно с напоминанием:
The system has found a problem on your machine and cannot continue. Not enough main memory is avaliable to continue. At least 4096 MiB of memory are required.
Если по ресурсам у вас все хорошо, то вы увидите приветственный баннер, на котором нажимаем "Enter".
Читаем лицензионное соглашение и если все вас устраивает, то нажимаем клавишу F11.
Установщик ESXI 6.5, начнет сканирование сервера, на предмет локальный, сетевых или внешних дисков.
В списке дисковых устройств выберите нужные вам, на которое будет устанавливаться ваш гипервизор, хочу отметить, что вы спокойно можете установить на встроенную SD карту, если такая есть или же на внешнюю флешку. Я выбираю локальный диск, размером 5 ГБ.
Задаем язык гипервизора Vmware ESXI 6.5, я оставлю по умолчанию английский, нажимаем Enter.
Указываем пароль от root пользователя, тут требования минимум 7 символов и желательно большие и маленькие буквы.
При нажатии клавиши F11 у вас начинается установка esxi 6.5.
Вот так вот выглядит сам процесс инсталляции гипервизора Vmware ESXI.
Как видим установка Vmware ESXi 6.5, успешно закончена и вам предлагается перезагрузить ваш сервер, соглашаемся.
Начальная настройка VMware ESXI 6.5
После успешной установки ESXI 6.5, у вас после перезагрузки появится вот такое черное окно, в котором у вас будет два возможных варианта развития событий:
- В левом нижнем углу, будет подсказка нажать клавишу F2, для настройки VMware ESXI 6.5
- В правом нижнем углу, будет подсказка, как выключить или перезагрузить хост виртуализации
Обратите внимание, что если у вас в локальной сети присутствует сервер DHCP, то вы получите от него IP-адрес и можете сразу попробовать подключиться к веб-консоли, если его не получили, то делаем все в ручную, хотя я всегда советую настраивать статику и отключать все лишнее , прямо из данного интерфейса
заходим в режим "Customize SystemView Logs", у вас появится окно авторизации, где вы указываете логин root и пароль, который задавали при установке ESXI 6.5.
У вас откроется окно "System Customization". На первом пункте "Configure Password", вы можете поменять пароль от root.
Вы указываете один раз старый пароль и два раза новый.
Переходим к пункту меню "Configure Management Network", тут производится настройка сети управления у ESXI 6.5, справа вы можете так же получить информацию, о IPv-4 адресах. Переходим в данный пункт.
Пункт "Network Adapters", покажет вам ваши сетевые интерфейсы, переходим в него
В моем примере их два, один активный, второй нет, если вы его хотите активировать, то выберите его и нажмите клавишу пробел, на против него появится крестик. Обратите внимание, выделенные сети будут отданы под сеть управления. В идеале для нее лучше назначать минимум два адаптера, для отказоустойчивости. Тут же вы найдете и mac-адреса.
Следующим этапом настройки ESXI 6.5, будет пункт меню "VLAN (options)", отвечающий за указание в каком сегменте VLAN у вас располагается ваш сетевой интерфейс, если у вас их нет, то тут стоит оставить все по умолчанию. Обычно с помощью VLAN и отделяют сеть управления от остальных.
Задается он просто, числом от 1 до 4095
Далее настройка EXI 6.5, позволяет вам в пункте "IPv4 Configuration", изменить ip-адрес на статический или вообще отключить сетевой интерфейс.
На выбор будет три пункта:
- Disable IPv4 configuration for management network - выключить сетевой интерфейс в сети управления
- Use dynamic IPv4 address and network configuration - по сути использовать DHCP сервер, для автоматического получения адреса, выставлено по умолчанию
- Set static IPv4 address network configuration - настройка статического адреса, все активации происходят, через кнопку Enter.
То же самое вы можете выполнить и по отношению к интерфейсу IPv6.
Далее переходим к настройке DNS серверов, через пункт "DNS Configuration"
Тут будет два пункта:
- Obtain DNS server address and hostname automatically- автоматическое получение DNS серверов из DHCP
- Use the following DNS server address and hostname - использовать заданные DNS сервера, ручная настройка.
В пункте "Custom DNS Suffixes", можно задать доменный суффикс.
Выходя из настроек сети ESXI 6.5, необходимо будет сохранить настройки и перезапустить сеть управления.
Отдельно можно перезапустить сеть управления из пункта "Restart Management Network"
Выглядит это вот так, вы соглашаетесь с рестартом.
В итоге сеть управления ESXI 6.5 будет выключена и заново включена.
В момент настройки VMware ESXI 6.5 у вас есть возможность из "System Customization", произвести сетевые тесты, на предмет доступности DNS или шлюза, сделать это можно из пункта "Test Management Network".
Проверяются пинги до нужных адресов и разрешение DNS имен.
Вот так вот выглядят результаты тестирования, тут сразу можно увидеть, есть ли проблемы с DNS или маршрутизацией.
Если вы допустили какие-либо ошибки в момент настройки или работы хоста виртуализации, и не знаете как все восстановить, то можно сбросить сетевые настройки на те, что были по умолчанию и быстро потом все перенастроить, так как появится доступ к сети управления. Делается, это все из меню "Network Restore Options".
09.10.2019
itpro
VMWare
комментариев 7
Иногда сталкиваюсь с тем, что определенная виртуальная машина на хосте VMWare ESXi зависает и ее нельзя никаким средствами выключить или перезагрузить из веб-интерфейса клиента vSphere. Перезагружать целиком ESXi сервер из-за одной виртуальной машины – не совсем целесообразно (особенно, если у вас всего один ESXi хост, или оставшиеся сервера в DRS кластере не потянут дополнительной нагрузки в виде виртуальных машин с перезагружаемого сервера). Рассмотрим основные способы принудительной остановки зависшей виртуальной машины в VMWare ESXi.
Если процесс виртуальной машины на сервере ESXi завис, она перестает реагировать на команды Reset / Power Off, и на любое действие выдает одну из ошибок:
-
The attempted operation cannot be performed in the current state ;
В таких случаях вы можете вручную остановить процесс виртуальной машины на хосте ESXi из командной строки ESXi Shell или PowerCLI.
Сначала определите на каком ESXi хосте запушена зависшая виртуальная машина. Для этого в интерфейсе vSphere Client найдите ВМ. Имя хоста, на котором она запущена, указано на вкладке Summary в секции Related Object -> Host.
Щёлкните по имени хоста ESXi. Вам нужно разрешить доступ к нему по протоколу SSH. Перейдите в Configure -> Services -> SSH -> Start.
Теперь вы можете подключиться к этому ESXi хосту через SSH с помощью клиента putty.
Выведем список ВМ, запушенных на хосте ESXi:
esxcli vm process list
Скопируйте идентификатор нужной виртуальной машины (World ID).
Чтобы завершить процесс зависшей виртуальной машинына хосте ESXi используется следующая команда:
esxcli vm process kill --type=[soft,hard,force] --world-id=WorldNumber
Как вы видите, есть три типа завершения процесса ВМ:
- Soft – самый безопасный способ завершить VMX процесс (похож на kill -SIGTERM);
- Hard – немедленное завершение процесса ВМ (kill -9);
- Force – самый жесткий режим завершения процесса, должен использоваться в последнюю очередь, если ничего другое не помогает.
Убедитесь, что для ВМ нет активных заданий по созданию снапшотов, бэкапов, и подобных операций, а у ВМ нет статуса Virtual Machine disks consolidation is needed. Иначе вы можете сломать свою ВМ и ее придется восставливать из бэкапа.
Попробуем мягко остановить ВМ с указанным ID:
esxcli vm process kill --type=soft -w=25089429
ВМ должна выключиться.
Вы можете остановить зависшую виртуальную машину с помощью PowerCLI (это удобно, т.к. при подключении к vCenter вам не нужно искать хост, на котором запушена ВМ и включать SSH доступ). Проверим, что ВМ запушена:
get-vm “web2" | select name,PowerStates
Принудительно остановите процесс ВМ командой:
stop-vm -kill "web2" -confirm:$false
Также вы можете остановить зависшую виртуальную машину с помощью утилиты ESXTOP.
В SSH сесиии введите команду esxtop, затем нажмите “c” для отображения ресурсов CPU и shift + V, чтобы отображать только процессы вириальных машин
Затем нажмите “f” (выбрать отображаемы поля), “c” (отобразить поле LWID- Leader World Id) и нажмите Enter.
В столбце Name найдите виртуальную машину, которую нужно остановить, и определите номер ее LWID по соответствующему столбцу.
Затем осталось нажать кнопку «k» (kill) и набрать LWID идентфикатор той виртуальной машины, которую нужно принудительно выключить.
Последний способ жёсткого выключения виртуальной машины – воспользоваться утилитой kill. Такой способ позволит остановить не только ВМ, но и все дочерние процессы.
Получим ID родительского процесса ВМ:
kill -9 24288474
После такого “hard reset”, установленная ОС запустится в режиме восстановления. В случае гостевой Windows, скрин будет выглядеть так.
Предыдущая статья Следующая статья
Как расширить диск виртуальной машины в VMWare
Установка VMware Tools на Debian, Ubuntu и CentOS
Сжимаем тонкий (thin) диск в ESXi 5
Создаем собственные правила файервола в ESXi 5.0
+5 Спасибо, очень помог!
А нет ли лекарства, чтобы виртуалки не зависали таким образом ? На сервере крутится единственная включенная вируталка с win2008r2/sql2008r2. Виснет она строго по ночам, без каких либо выявленных закономерностей: может месяцами не виснуть, может 2 раза за ночь. Достало просыпаться по ночам и перезагружать.
Странно — у меня баг с зависанием виртуальной машиной на ESXi встречался не столько часто…
Возможно стоит для начала обновить версию до последней версию ESXi и VMtools на гостевой ОС.
Если ничего не поможет — придется прикручивать какой-нибудь костыль в виде скрипта, периодически запускающегося на хосте ESXi и проверяющий доступность определенного сервиса на виртуалке (хотя бы тем же telnet-ом). Если сервис не отвечает — выполняем скрипт перезапуска виртуалки (по мотивам этого мануала)
Спасибо за инфу!
У меня были случаи подвисания виртуальных машин с Linux, Windows и FreeBSD — так что решение, похоже, не универсальное. Скорее тут какой-то глюх самого ESXi.
В любом случае по результатам, пожалуйста, отпишитесь…
К сожалению не помогла заплатка. зависания всё равно случаются.
Может память или ядра неправильно распределены?
Я заметил что бывают торможения всех виртуалок и начал оставлять запас по мощности.
23.04.2018
Alex Kornev
VMWare
комментариев 8
Наверное, многим приходилось это видеть. Все настроено, автозапуск vCenter разрешен, но … «не запускается».
Запускаем ESXi хост. Ждем пока он загрузится.
Открываем web-клиент хоста и сразу открываем web-консоль vCenter. И видим, что … загрузка идет и все в порядке.
Ждем… ждем и … «не запускается»! Почему-то просит ввести логин … Причем тут это?
Все пропало, шеф! (с) х/ф «Бриллиантова рука»
Нет, конечно же. Не так все грустно.
Щелкаем мышкой в консоли vCenter, потом жмем Alt-F2 и … чудо произошло!
Чтобы совсем убдиться, что все и правда хорошо, можно нажать, например, на пробел, находясь в консоли vCenter
Ура, заработало! (с) кот Матроскин
А вообще, желательно выполнить рекомендации VMWare при установке vCenter Server Appliance 6.5, а именно
- Объем RAM – не менее 10 GB
- Объем места на Storage – не менее 250 GB
- Количество процессоров (ядер) – не менее 4х (про это vMware умалчивает)
Можно ли установить vCenter Server Appliance 6.5 на меньшие ресурсы?
- Нет. Требования по памяти и объему Storage жесткие. Инсталлятор не заработает. По количеству виртуальных процессоров такого ограничения нет
Заработает ли vCenter Server Appliance 6.5 при меньших выделенных ресурсах?
- Да. Но время старта будет увеличиваться пропорционально снижению «аппаратных» мощностей виртуалки.
Предыдущая статья Следующая статья
HPE ESXi: Низкая производительность дисков в кастомных образах HP
Интеграция сторонних драйверов в ISO образ VMWare ESXi 6.7
Установка и базовая настройка бесплатного VMware vSphere Hypervisor
Особенности VMware vSAN 6.5: FAQ и настройка кластера
А вообще, желательно выполнить рекомендации VMWare при установке vCenter Server Appliance 6.5, а именно
Объем RAM – не менее 10 GB
Т.е. чтобы полноценно работать с этим гипером нужна ВМ в этом гипере?!
То ли дело Proxmox. Все делается через веб и нет привязки к брендовому железу. Плюс софт-рейды на ZFS и автобэкапы ВМ (теперь и в облачн. хранилища) сразу из коробки.
Дим. Убери, пожалуйста, комментарии anao.
По делу ни одного комментария.
Спасибо
Может подумать о регистрации и авторизации для добавления комментариев?
Ну зачем же? Само по себе это безвредно. Даже если появляются «бесноватые» комменты — они гаснут моментально сами по себе. Просто люди сюда не за этими комментами приходят. Этот ресурс из тех, где интересна статья, а мои, Ваши или «его» комменты не играют никакой роли.
Евгений, по опыту, в начале 90-х доставали голодные студенты и приезжие, которые сильно сбивали ценник. Потом заказчики удивлялись «а почему так дорого?» На что приходилось объяснять, что это » а) за расчистку того, что натворили дешевые студенты и б) за, собственно, настройку»
А теперь появилось «поколение Pepsi/ЕГЭ». Эдакие «домашние сынки-вундеркинды», нахватавшиеся по верхам … «в форуме прочитал» и везде об этом пишущие. Здесь, например.
Я не против аргументированных доводов, но я категорически против пустых воплей этих «первонахов».
Я задавал вопросы «мальчику anao» — «Сколько хостов на этом Proxmox он поднял? Сколько виртуалок? Какие задачи решались?» Ответа не получил. Отсюда моя реакция.
А еще меня посмешило вот это «Все делается через веб»… Наверное нет необходимости объяснять почему. Пожелать ему посмотреть на *nix или, хотя бы, на Core Edition 🙂 В CLI (любой) я бы ему не рекомендовал соваться 🙂 Не его 🙂 Мышка же не работает 🙂
Лучше вернуть дискуссию в мирное русло. Убрал грязь из комментариев.
Мне, например, одинаково чужды как сторона «Винда масдай / opensource наше все» так и сторона приверженцев корпоративных монстров. Можно накидать камней в оба огорода, но конструктивного диалога из этого не получится.
Системный администартор должен уметь подбирать решение в зависимости от поставленой задачи, требованиям к надежности, SLA и бюджета.
Комментарии ограничивать не буду однозначо, эта важная составляющая сайта, как обратная связь и возможность диалога с обменом мнениями.
Можно не соглашусь. Системный администратор это исполнитель. Он может высказать свое мнение, но решение, окончательное, вырабатывает ИТ Директор (CIO) 🙂 Да, не в нашей дествительности, когда «в целях экономии (жадности) Админ выполняет все функции сразу 🙂
Тут ты прав, так должно буть. У нас тоже есть ИТ архитекторы и директора. Чего-то напридумывают сказочное, но, вот только админить они это не будут :). Поэтому всегда приходится искать компромисс с админами.
Как перезапустить зависшую виртуальную машину
Сразу хочу отметить, что если в графическом интерфейсе у вас не выходит, что либо сделать, то у вас остается только командная строка ssh. Включаем на ESXI хосте SSH службу. Далее подключаемся через Putty или MremoteNG. Я подключаюсь через MremoteNG. Первое, что вам необходимо сделать, это как посмотреть список активных процессов, все как в Windows. Для этого есть команда:
В моем примере, я вижу свою виртуальную машину TERM6. Если системные процессы мозолят вам глаза, то вы можете одновременно нажать SHIFT+V, что оставит отображение только виртуальных машин.
Теперь нам нужно вычислить LWID - Leader World Id, завершив который вы завершите работу нужной виртуалки. ПО умолчанию LWID не отображается, чтобы его включить нажмите клавишу F. У вас откроется меню, где можно добавлять или скрывать поля. Видим, что если нажать клавишу "C", то у вас будет добавлен LWID- Leader World Id. Нажимаем "C" и "Enter".
Теперь зная LWID, нажмите клавишу "K", она вызовет меню "World to kill (WID)", данная операция поможет принудительно завершить процесс LWID. Вбиваем наш LWID и нажимаем "Enter".
Тут у вас два варианта, чудо произошло (80% вероятности) и чудо не произошло, часто бывает в случаях с ошибкой "Another task is already in progress"
Кстати World ID можно вычисли и просто введя команду:
Там вы сможете увидеть World ID, после чего его можно убить командой:
В моем случае чудо произошло, виртуалка перешла в состояние Power OFF, я это вижу в Power-CLI.
Если принудительное завершение процесса вам не помогло, то делаем вот что, по возможности мигрируйте все остальные виртуальные машины с данного хоста, у вас из-за ошибки останется только сбойная. Все в том же SSH. введите:
В итоге у вас будет выведен список, где первая колонка это PID процесса, вторая PID родительского процесса, убиваем его для вашей виртуальной машины.
После чего пишем kill PID-родительского процесса. Если не помогло, то пробуем выполнить вот, что (по возможности перевезите другие сервера с данного хоста на другие хосты)
В результате действий хост стал работать нормально, единственное может быть ситуация, что виртуалку придется удалить из inventory и добавить заново. Если и это не помогло, то попробуйте выполнить:
Алгоритм действий и возможные причины зависания
- Первое, что я вам советую сделать, это избавится от ошибки "Vmware Tools is outdated on this virtual machine" путем обновления Vmware Tools. Напоминаю, что это сделать можно из меню "Guest OS - Update Vmware Tools". Потребуется перезагрузка виртуальной машины.
- Следующим пунктом, я вам советую проверить операционную систему на предмет повреждения системных файлов, сделать это просто. Запустите cmd от имени администратора или откройте Power Shell, кому что привычнее и введите команду:
Программа защиты ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила. Подробные сведения см. в файле CBS.Log, который находится по следующему пути: windir\Logs\CBS\CBS.log.
Если ошибки не были устранены, то советую выполнить команду:
Утилита DISM обратится к внешним репозиториям Microsoft и скачает от туда валидные файлы, чтобы восстановить аналогичные в вашей системе. Процесс так же может занимать некоторое время. Как видим:
Восстановление выполнено успешно. Повреждение хранилище компонентов было устранено. Операция успешно завершена.
Еще одним пунктом диагностики проблем с ошибками ID 111 и ID 129, я вам советую выполнить сканирование ваших дисков на предмет ошибок. Для этого есть два варианта, старая добрая утилита командной строки ChkDsk и ее графический аналог в свойствах диска "Проверка диска на наличие ошибок файловой системы"
Для проверки локальных дисков через командную строку, вы можете воспользоваться командой:
Ключ /f указывает утилите исправлять ошибки на диске, флаг /R обязывает CHDSK искать на диске повреждённые сектора, и попытаться восстановить данные на них. Если диск системный, то вас попросят перезагрузиться, и проверка диска будет перед загрузкой системы.
Невозможно выполнить команду CHKDSK, так как указанный том используется другим процессом. Следует ли выполнить проверку этого тома при следующей перезагрузке системы? [Y(да)/N(нет)]
То же самое вы можете сделать и в свойствах локального диска, для этого щелкните по нему правым кликом и перейдите в его свойства. Найдите там вкладку "Сервис" и на ней пункт "Проверка диска на наличие ошибок файловой системы". Нажмите проверить.
В новом окне нажимаем "Проверить диск".
Будет запущен процесс сканирования диска, обычно он занимает не много времени.
После чего вы получите результат. В моем случае я вижу, что "Диск успешно проверен".
Описание проблемы
The virtual machine might be performing concurrent operations. Actions: Complete the concurrent operation and retry the power-off operation. The virtual machine is in an invalid state. Virtual machines can enter an invalid state for many reasons.
При попытке мигрировать виртуальную машину вы может получить ошибку:
Так же вы можете увидеть ошибку при попытке, выключить или перезапустить виртуалку:
Во всех случаях вам скажут, что данная виртуальная машина имеет некий процесс, который в данный момент не дает выполнить ваши повторные действия. Так же данная виртуалка у меня была членом RDS фермы, при попытке перевода его в режим стока (Drain-Mode) я получил ошибку "Не удалось изменить состояние подключения для сервера".
Читайте также: