VMWare ESXi: Перезапуск зависшей виртуальной машины
Иногда сталкиваюсь с тем, что определенная виртуальная машина на хосте VMWare ESXi зависает и ее нельзя никаким средствами выключить или перезагрузить из веб-интерфейса клиента vSphere. Перезагружать целиком ESXi сервер из-за одной виртуальной машины – не совсем целесообразно (особенно, если у вас всего один ESXi хост, или оставшиеся сервера в DRS кластере не потянут дополнительной нагрузки в виде виртуальных машин с перезагружаемого сервера). Рассмотрим основные способы принудительной остановки зависшей виртуальной машины в VMWare ESXi.
Если процесс виртуальной машины на сервере ESXi завис, она перестает реагировать на команды Reset / Power Off, и на любое действие выдает одну из ошибок:
В таких случаях вы можете вручную остановить процесс виртуальной машины на хосте ESXi из командной строки ESXi Shell или PowerCLI.
Теперь вы можете подключиться к этому ESXi хосту через SSH с помощью клиента putty.
Выведем список ВМ, запушенных на хосте ESXi:
esxcli vm process list
Скопируйте идентификатор нужной виртуальной машины (World ID).
Чтобы завершить процесс зависшей виртуальной машинына хосте ESXi используется следующая команда:
Как вы видите, есть три типа завершения процесса ВМ:
Попробуем мягко остановить ВМ с указанным ID:
ВМ должна выключиться.
Вы можете остановить зависшую виртуальную машину с помощью PowerCLI (это удобно, т.к. при подключении к vCenter вам не нужно искать хост, на котором запушена ВМ и включать SSH доступ). Проверим, что ВМ запушена:
get-vm “web2″ | select name,PowerStates
Принудительно остановите процесс ВМ командой:
Также вы можете остановить зависшую виртуальную машину с помощью утилиты ESXTOP.
В SSH сесиии введите команду esxtop, затем нажмите “c” для отображения ресурсов CPU и shift + V, чтобы отображать только процессы вириальных машин
Затем нажмите “f” (выбрать отображаемы поля), “c” (отобразить поле LWID- Leader World Id) и нажмите Enter.
В столбце Name найдите виртуальную машину, которую нужно остановить, и определите номер ее LWID по соответствующему столбцу.
Затем осталось нажать кнопку «k» (kill) и набрать LWID идентфикатор той виртуальной машины, которую нужно принудительно выключить.
Последний способ жёсткого выключения виртуальной машины – воспользоваться утилитой kill. Такой способ позволит остановить не только ВМ, но и все дочерние процессы.
Получим ID родительского процесса ВМ:
После такого “hard reset”, установленная ОС запустится в режиме восстановления. В случае гостевой Windows, скрин будет выглядеть так.
Зависает виртуальная машина vmware
Добрый день! Уважаемые читатели и гости одного из популярных IT блогов рунета Pyatilistnik.org. В прошлый раз мы с вами подробно разобрали тему починки и диагностики интернет соединения. Сегодня мы разберем случай с гипервизором Vmware. У меня есть кластер ESXI 6.5, построенный на серверах Dell R740. На нем крутится приличное количество виртуальных машин. В какой-то из дней приходит оповещение от системы мониторинга, что одна виртуалка перестала отвечать по сети. Зайдя в веб-интерфейс vCenter Server, я обнаружил, что виртуальная машина завислаа и ни на что не реагировала. Давайте разбираться в чем дело и как такое диагностировать.
Описание проблемной виртуальной машины
Как я и писал выше, виртуальная машина намертво зависла, по RDP или ping она была не доступна. Гостевой операционной системой была Windows Server 2012 R2. Попытавшись запустить Web Console из интерфейса vCenter Server, виртуальная машина ни на что не реагировала.
Так же в веб интерфейсе vCenter, у виртуальной машины было предупреждение «Vmware Tools is outdated on this virtual machine». Такое сообщение мы уже видели ранее, при попытке обновления VMware Tools.
Диагностика зависшей виртуальной машины
После того, как операционная система в ней загрузится, я вам советую начать изучение логов Windows. Открываем просмотр событий и делаем поиск ошибок и предупреждений. Мне удалось найти два события, которые косвенно говорили, что проблема с зависанием виртуальной машины связана непосредственно с операционной системой и возможными проблемами с поврежденными системными файлами или драйверами Vmware Tools. Первое событие:
Так же можно обнаружить и ошибки вот такого рода, которые так же заставляю виртуальную машину флапать, зависать с черным экраном.
Данное событие связано с сетевым интерфейсом типа E1000, советую его поменять на паравиртуализованный VMXNET3. E1000 кушает больше ресурсов процессорных мощностей и так же более капризный, но за то не требует установки Vmware Tools.
Так же вы можете посмотреть логи самой виртуальной машины на уровне Vmware ESXI 6.5. Я нашел там вот такую выборку:
Алгоритм действий и возможные причины зависания
Процедура проверки целостности данных может занять некоторое время, по результатам вы увидите были ли ошибки, и удалось ли их исправить. В моем случае утилита sfc смогла определить поврежденные файлы и выполнить процедуру восстановления.
Если ошибки не были устранены, то советую выполнить команду:
Утилита DISM обратится к внешним репозиториям Microsoft и скачает от туда валидные файлы, чтобы восстановить аналогичные в вашей системе. Процесс так же может занимать некоторое время. Как видим:
Еще одним пунктом диагностики проблем с ошибками ID 111 и ID 129, я вам советую выполнить сканирование ваших дисков на предмет ошибок. Для этого есть два варианта, старая добрая утилита командной строки ChkDsk и ее графический аналог в свойствах диска «Проверка диска на наличие ошибок файловой системы»
Для проверки локальных дисков через командную строку, вы можете воспользоваться командой:
Ключ /f указывает утилите исправлять ошибки на диске, флаг /R обязывает CHDSK искать на диске повреждённые сектора, и попытаться восстановить данные на них. Если диск системный, то вас попросят перезагрузиться, и проверка диска будет перед загрузкой системы.
То же самое вы можете сделать и в свойствах локального диска, для этого щелкните по нему правым кликом и перейдите в его свойства. Найдите там вкладку «Сервис» и на ней пункт «Проверка диска на наличие ошибок файловой системы». Нажмите проверить.
В новом окне нажимаем «Проверить диск».
Будет запущен процесс сканирования диска, обычно он занимает не много времени.
После чего вы получите результат. В моем случае я вижу, что «Диск успешно проверен».
Ранее установленный софт
Очень часто причиной зависания виртуальной машины на ESXI 6.5 выступает недавняя установка обновлений в системе или различного рода программного обеспечения. Обязательно посмотрите в «Панель управления\Все элементы панели управления\Программы и компоненты» по дате установки, что недавно было проинсталлировано.
Тут же можно посмотреть установленные обновления. Недавно Microsoft выпустило обновление KB4015553 (Со временем может меняться), которое в Windows Server 2012 R2 стало вызывать зависание. Необходимо удалить KB4015553, kb4019215 и kb4019217, перезагрузить ваш сервер.
Еще могу по своему опыту сказать, в некоторых случаях виртуальная машина с Windows, может зависать из-за антивируса Sumantec Endpoint Protection, вот пример ветки обсуждения на сайте Microsoft (https://social.technet.microsoft.com/Forums/ie/en-US/330179d1-a252-4c0f-962c-6a639ca6b373/windows-server-2012-r2-vmware-vm-freezes-randomly-no-event-logs?forum=winserver8gen или https://communities.vmware.com/thread/535938). Как вариант попробуйте его удалить, или переустановить заново.
Сама компания 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.
Как ускорить работу виртуальных машин VMware Workstation
10 способов, как можно ускорить работу с виртуальными машинами в среде гипервизора VMware Workstation.
VMware Workstation – один из лучших гипервизоров для Windows. Это не самая производительная, но самая стабильная программа, с помощью которой можно виртуально исследовать различные операционные системы (ОС). VMware не конфликтует с другими гипервизорами (как Microsoft Hyper-V), в ней всегда работают дополнения гостевых ОС и прочие функции (в отличие от нестабильной VirtualBox), она функциональная и настраиваемая. Ну а что касается производительности, то здесь можно кое-что предпринять. Как ускорить работу виртуальных машин (ВМ) VMware?
1. Аппаратная часть
При использовании любого гипервизора, как и в случае с физическим компьютером, аппаратная оптимизация первична, программная – вторична. Для работы с VMware не принципиально, но желательно иметь на борту физического компьютера четырёхъядерный процессор, чтобы двое ядер оставались хост-системе (основной ОС), а двое могли бы быть задействованы ВМ.
Для базовых целей типа исследования ОС и тестирования несложного софта будет достаточно 2 Гб оперативной памяти. Разве что гостевым Windows 8.1 и 10 можно выделить 3 Гб, если у физического компьютера имеется 6 или 8 Гб. Выделять больший объём без конкретных целей использования памяти нет надобности.
ВМ, размещённая на одном и том же HDD, где установлена хост-система, будет тормозить даже при мощном процессоре и отсутствии недостатка оперативной памяти. HDD – слабое звено в конфигурации и физических, и виртуальных компьютеров из-за медленной скорости чтения и записи данных. Если в наличии нет SSD, для размещения ВМ желательно выделить отдельный HDD – жёсткий диск, к которому не будет обращаться хост-система. Ну или пойти путём универсального аппаратного апгрейда – реализовать RAID 0 (как минимум). Без последнего задействовать два HDD в работе ВМ можно, если разбросать её файлы по разным дискам.
2. Файлы ВМ на разных HDD
При использовании ВМ и по завершении работы с ней происходит запись данных во все эти файлы. За исключением снапшотов, если они не задействуются. Чтобы распределить нагрузку, можно файл виртуального диска VMDK (или VHD) хранить на одном HDD, а файлы конфигурации ВМ – на другом HDD, в частности, на том же, где размещается хост-система. Для всех ВМ указываем расположение по умолчанию – каталог на одном HDD.
При создании же каждой отдельной ВМ используем выборочную настройку.
И на этапе задания параметров виртуального диска указываем его месторасположение на разделе другого HDD.
Применить такую схему к уже имеющихся ВМ можно путём удаления используемого виртуального диска в параметрах машины. А затем добавления этого же диска по-новому, когда его файл VMDK (или VHD) уже будет перемещён на другой HDD.
3. Фиксированные виртуальные диски
Немного ускорить работу ВМ на HDD можно путём работы с фиксированными, а не назначенными по умолчанию в VMware динамическими виртуальными дисками. Для этого при создании ВМ на этапе указания размера диска необходимо выбрать его сохранение в одном файле и установить галочку опции выделения всего места.
При таком раскладе будет создан виртуальный диск фиксированного типа. Его файл со старта займёт указанный объём, и ресурс HDD при непосредственной работе с ВМ не будет распыляться ещё и на операцию по выделению места на физическом диске.
4. Дефрагментация HDD
Ускорить работу ВМ на HDD можно традиционным методом оптимизации этого типа жёстких дисков – дефрагментацией. В среде хост-системы Windows желательно время от времени проводить эту процедуру с использованием эффективных сторонних программ.
5. Тормоза после приостановки ВМ
Работающие с VMware наверняка замечали, что в большинстве случаев после приостановки одной ВМ сразу же оперативно запустить другую нереально. Нужно немного подождать. Естественно, речь идёт о случаях расположения ВМ на HDD. Как только мы приостанавливаем ВМ, сразу же начинается активная запись данных на диск с его загрузкой вплоть до 100%. И так может длиться несколько минут. При приостановке ВМ содержимое оперативной памяти гостевой ОС каждый раз записывается в файл «.vmem». Он находится в числе прочих файлов конфигурации ВМ и планировано занимает столько места на диске, сколько машине выделено «оперативки». По факту же размер файла варьируется в зависимости от записанных в него в последний раз данных.
Активная запись в файл «.vmem» сильно нагружает HDD. Назначение такой операции – запуск гостевой ОС в сохранённом состоянии при возможных сбоях в работе ВМ. Нужна ли эта возможность такой ценой – решайте сами. Если не нужна, запись данных в файл «.vmem» можно отключить. И тем самым ускорить переключение между приостановленными ВМ. Для этого необходимо открыть в любом TXT-редакторе файл конфигурации ВМ «.vmx», дописать в конце такую строчку:
mainMem.useNamedFile = «FALSE»
6. Обрезка страничной памяти
В дополнительных параметрах ВМ есть изначально неактивная опция отключения обрезки страничной памяти. Если её активировать, фактическое выделение оперативной памяти ВМ будет происходить быстрее.
7. Плеер VMware
В состав компонентов VMware Workstation входит приложение Player. Это упрощённый вариант гипервизора, ограниченный функционально, но также и более лёгкий. Создавать и настраивать ВМ лучше, конечно же, с использованием основного компонента VMware Workstation. А вот непосредственно проводить работу с гостевыми ОС можно внутри более шустрого плеера.
8. ПО EFI
ВМ с ПО EFI эмулируют устройства, соответственно, с BIOS UEFI. Они включаются и перезапускаются немного быстрее, чем ВМ, эмулирующие устройства с обычным BIOS. Плюс к этому, EFI-машины могут быть запущены с UEFI-флешек без помощи сторонних средств.
9. Оптимизация гостевых ОС
Ускорить работу ВМ можно за счёт оптимизации гостевых Windows. В числе таковых в частности: отключение анимации, обоев, неиспользуемых служб, телеметрии, обновлений, Timeline (для версии 10). В качестве платформы для тестирования только стороннего софта можно и вовсе в качестве гостевой ОС выбрать Windows 7 или 8.1 Embedded – урезанные сборки этих версий, заточенные под работу со слабым железом.
В гостевых Windows можно смело работать с отключённым Защитником и без стороннего антивируса. За безопасность будет отвечать антивирус хост-системы. А вот для последней желательно подобрать такой антивирусный продукт, чтобы защищал, но при этом не мешал.
10. Правильный антивирус для хост-системы
Активность ВМ – это непаханое поле азарта для антивирусов. VMware Workstation, как и любой другой гипервизор, активно работает с записью данных. Причём работает с большими объёмами данных. И все эти данные антивирусы проверяют в рамках проактивной защиты. Чтобы не создавать лишней нагрузки при работе с ВМ, для хост-системы желательно подобрать хороший антивирус – эффективный в плане обнаружения реальных угроз, при этом минимально использующий аппаратные ресурсы компьютера.
Базовый траблшутинг в среде VMware vSphere или что делать, если тормозит ВМ
Что-то в последнее время технические статьи о виртуализации (да и не только о виртуализации) скатываются к формату «в новой версии ожидается такая фича». Складывается ощущение, что разбор механизмов и описание опыта, проблем и решений интересны только зарубежным экспертам. С другой стороны, есть такая проблема у экспертов — если что-то изучил, оно становится элементарным и воспринимается само собой разумеющимся, настолько, что писать об этом как-то глупо. Особенно если уже было кем-то описано где-то. Когда-то. На каком-то языке. Ниженаписанное — плод консолидации личных заметок, сначала предназначавшийся для личного упорядочивания мыслей, но наупорядочив значительный объём текста, подумал, что кому-то может пригодиться.
Типовая проблема «виртуализаторов» — владелец сервиса, заказчик или пользователь жалуется, что у него «тормозит» виртуальная машина. Так как виртуализация предполагает консолидацию большого количества ВМ на базе одного комплекта аппаратных ресурсов, переподписку (overprovision — когда мы предполагаем, что серверы не затребуют одновременно максимум своих ресурсов, а значит, например, в 40 ГБ физической памяти мы можем натолкать не 10 серверов по 4 ГБ RAM, а 15, используя Dynamic Memory), а кроме того, серверы могут тормозить и из-за ошибок в программных компонентах и их настройках, то каждый раз приходится решать за что хвататься и куда смотреть в первую очередь. Особенно, если с таким ёмким описанием проблемы, как «тормозит машина» не предоставлено никакой диагностической информации, как чаще всего и бывает. Под катом небольшое руководство для этого случая.
Конечно, всё зависит от специфичности реализации конкретной инфраструктуры, но практика показывает, что в большинстве случаев имеет смысл следующая последовательность анализа подсистем ВМ:
На практике, до 4-го этапа почти никогда не доходит, после третьего (а то и после первого) имеет смысл запускать (или запрашивать) параллельную диагностику гостевой ОС, но диски стоит проверить сразу — самая значительная часть инцидентов с жалобами на производительность связано с ними. Если, конечно, у вас не All-Flash массив.
А теперь чуть подробнее по каждому пункту.
1. Диски (подсистема хранения)
Самый ключевой тут показатель — это Latency. Задержка времени отклика. Она складывается из большого количества промежуточных элементов и зависит от большого количества факторов. Сюда входит время отклика гипервизора, время прохождения сигнала по кабелям и промежуточным устройствам (коммутаторы, адаптеры и контроллеры), время нахождения в очередях на всех этих устройствах, если нагрузка на них превышает норму и ещё некоторые нюансы, такие как повреждения оборудования. Однако, оставив нюансы для расширенной диагностики, требуемой в редких случаях, можно выделить простой общий показатель — время задержки от ВМ до дисков.
Perfomance Tab
(закладка Perfomance в vSphere Client и счетчики производительности).
Наиболее часто используемые счётчики группы Disk:
Highest Latency — норма до 10-15 мс. Если регулярно выше, надо что-то менять, хотя разовые пики не страшны;
Average write requests per second;
Average read requests per second.
Наиболее часто используемые счётчики группы Virtual Disk:
Read/Write latency;
Average number of outstanding read/write requests — количество одновременных IO-запросов (если их число держится выше 30 в сумме на датастор или на сервер, это будет приводить к дополнительным задержкам);
ESXTop
Консольная утилита ESX/ESXi. Выдаёт целую кучу диагностической информации об отдельно взятом ESXi. Базовую информацию по использованию можно получить, нажав h после запуска утилиты.
В плане диагностики дисковой подсистемы будет полезен контекст виртуальных дисков (нажать v) и контекст HBA-адаптеров (нажать d). В последнем случае стоит обратить внимание на следующие показатели:
KAVG (Kernel Latency Avg) — время отклика гипервизора (норма — до 1 мс);
DAVG (Device Latency Avg) — время отклика от HBA до дисков (норма — 10-15мс);
GAVG (Guest Latency Avg) — время отклика для гостевой системы = сумма KAVG и DAVG
Кстати, в этой же области исследований стоит сразу проверить нет ли у ВМ снапшота. А то и нескольких. Они могут стать проблемой не только паденрия производительности, но и сбоев операций резервного копирования, клонирования и миграции.
2. Процессор
Здесь аналогичный по важности дисковым задержкам показатель — CPU Ready. Также стоит обращать внимание на Used, Wait и Co-Stop. Мониторить можно также через Perfomance Tab или ESXtop.
CPU Ready (%RDY) — % времени, когда ВМ готова производить какие-то вычисления, но физические процессоры в данный момент заняты другими процессами (системными или другими ВМ) и vCPU виртуальной машины находятся в режиме ожидания. Нормой считается значение до 10%. При росте этого показателя выше 40% развивается высокая вероятность сбоев и зависаний гостевой ОС. Причиной вынужденного простоя может стать:
Wait (%WAIT) — % времени, в течение которого ВМ ждёт окончания какой-то активности VMkernel. Чаще всего это дисковая IO-активность. Высокие показатели этого счётчика могут говорить о недостаточно быстром отклике от датастора. Также проблему могут вызывать некорректная работа USB или COM-портов или виртуальный CD/DVD-приводы, в который замонтирован отсутствующий ныне ISO.
Used (%USED) — % времени, в течение которого машина реально работала. Если он около нуля, значит машина просто стоит или её пересайзили процессорами. Если он около 100 (на каждый vCPU), значит или недосайзили, или в ней что-то зациклилось (если она ещё и не откликается при этом), или сейчас там лопатится какой-то квартальный отчёт. Этот показатель стоит изучать при размышлении на тему «дать ли ВМ ещё процессоров, чтоб быстрее работала?». Если у неё 4 ядра и ни одно не задействовано более чем на 50%, то 8 ядер её скорее всего не ускорят. Возможно даже замедлят (см. CPU Ready).
Инструменты диагностики те же.
Perfomance Tab
Удобно, что можно посмотреть данные не только по машине в целом, но и по каждому ядру. Кроме того, доступна статистика за период. Однако, информация предоставляется не в процентах, а в миллисекундах. Так как данные собираются не в real-time, а за определённый интервал, отображается, сколько именно mc процессор находился в том или ином состоянии. Перевести в проценты можно разделив значение на длину интервала и умножив на 100%.
Пример: на рисунке диаграмма с интервалом 20 секунд (real-time), то есть 20 000 мс. То есть среднее CPU Ready будет 50288 / 20000 * 100% = 251.44%. Так как у машины 4 ядра, а не одно, то результат делим на 4 и получаем почти 63%. Машина очень страдает. А всё потому, что лежит на третьем уровне вложенности Resource Pools с низкими shares на каждом.
Ещё раз, формула преобразования: / / * 100%. Получается 5% на 1000 мс для одного ядра.
ESXTop
Тут значение указано сразу в %. Только оно указано сразу в сумме для всех ядер, так что не стоит пугаться чисел больше 100. Делите на количество vCPU машины.
3. Оперативная память
Базовая диагностика здесь простая — да или нет. Если есть факт balooning’а значит хосту не хватает памяти и процессы гостевых ОС страдают, потому что активно используется файл подкачки. Если есть факт свопинга на уровне гипервизора, надо срочно принимать меры — машина попавшая в своп впадает в кому в 100% случаев (по крайней мере моей практики). Вышеуказанные факты позволяют определить такие счётчики как
Balloon (MCTLSZ) — количество памяти, вытянутое baloon-драйвером из гостевых ОС.
4. Сеть
Чтобы проблемы были на уровне сети, в случае жалоб на отдельную виртуальную машину, я в своей практике помню только один случай — когда в VDI использовалась какая-то дешёвая веб-камера, гнавшая несжатый поток видео и забивавшая все 100 Мб/с.
Стоит мониторить такие счётчики:
Transmit Dropped Packets (%DRPTX) — количество (или процент в случае esxtop) отброшенных отправленных пакетов;
Receive Dropped Packets (%DRPRX) — количество (процент) отброшенных принятых пакетов.
Ненулевое их значение, возникающее на регулярной основе говорит о некорректной работе сетевых устройств или некорректной их настройке.
Для базовой диагностики, покрывающей более половины (пожалуй, до 90%) обращений или собственных потребностей при диагностике и тестировании, этого достаточно.