При запуске виртуальной машины vmware сильно подтормаживает. Как ускорить работу виртуальных машин VMware Workstation

Медленная работа Windows 10 на виртуальной машине — довольно часто обсуждаемая проблема на Интернет-форумах. Пользователи жалуются на то, что кнопка Пуск, Центр уведомлений и значки программ в панели задач реагируют на клики с большой задержкой, а процесс svchost.exe грузит процессор виртуальной машины на 100% в состоянии бездействия. При этом отклик графического интерфейса бывает настолько медленным, что работать с виртуалкой просто невозможно. Давайте разберемся, как ускорить Windows 10 на виртуальной машине Virtualbox.

Удалите вирусы и вредоносное ПО

Установите Дополнения гостевой ОС

Дополнения гостевой ОС (Guest additions) — это набор драйверов для виртуального железа. Его обязательно нужно установить сразу после установки ОС. Для пакета дополнений периодически выходят обновления, о чем вы будете уведомлены. Для установки щелкните Устройства и выберите Подключить образ диска Дополнений гостевой ОС:

После этого запустите либо вручную запустите файл VBoxWindowsAdditions.exe с виртуального DVD-привода.

Используйте настройки по умолчанию для виртуальной машины

Имеется в виду — для конкретной ОС на виртуальной машине. Естественно, при установке ОС на виртуалку необходимо правильно выбрать тип и версию операционной системы.

Не выделяйте все физические ядра под виртуальную машину. Именно в этом случае часто наблюдается необъяснимая загрузка процессора процессом svchost.exe под 100% в состоянии простоя.
Если у вас 4-ядерный процессор, то в большинстве случаев оптимальным будет выделить 2 ядра под виртуалку. Поэкспериментируйте с количеством ядер и понаблюдайте за тем, как ведет себя система.
Для работы Windows 10 на Virtualbox выделите от 2 до 4 ГБ ОЗУ, в зависимости от того, сколько установлено на компьютере. Помните, что у вас должно остаться 4 ГБ для работы Windows 7, 8 или 10 на носителе (т.е. реальном компьютере).

Не изменяйте никакие настройки машины, если вы не уверены в правильности своих действий. Часто пользователи пытаются ускорить Windows 10 на Virtualbox, добавляя ядра до отказа и изменяя другие параметры, но это наоборот приводит к снижению скорости работы машины.

Переместите файл виртуального жесткого диска на SSD

Используйте фиксированный жесткий диск

Да, они сразу съедают все отведенное для них дисковое пространство, независимо от того, на сколько заполнен виртуальный диск. Однако скорость записи на фиксированный диск будет выше, чем на динамический.

Обновите Virtualbox до последней версии

Нередко устраняются баги. Особенно это касается свежих версих ОС — например, Windows 10 на данный момент. Для обновления Virtualbox на компьютере-носителе выключите все виртуальные машины и выберите Файл — Проверить обновления :

После обновления вы сможете продолжить пользоваться вашими машинами. Никакие данные на них затронуты не будут.

Включите поддержку виртуализации в UEFI / BIOS

Virtualization Technology позволяет виртуальной машине использовать дополнительные возможности железа. Если у вас в BIOS (UEFI) есть такой параметр, обязательно включите его.

Отключите визуальные эффекты Windows 10 в виртуальной машине

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

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

Выполните проверку программами AdwCleaner, Anti-Malware и CureIt.

Установите Дополнения гостевой ОС

После этого запустите либо вручную запустите файл VBoxWindowsAdditions.exe с виртуального DVD-привода.

Используйте настройки по умолчанию для виртуальной машины

Не выделяйте все физические ядра под виртуальную машину. Именно в этом случае часто наблюдается необъяснимая загрузка процессора процессом svchost.exe под 100% в состоянии простоя.
Если у вас 4-ядерный процессор, то в большинстве случаев оптимальным будет выделить 2 ядра под виртуалку. Поэкспериментируйте с количеством ядер и понаблюдайте за тем, как ведет себя система.
Для работы Windows 10 на Virtualbox выделите от 2 до 4 ГБ ОЗУ, в зависимости от того, сколько установлено на компьютере. Помните, что у вас должно остаться 4 ГБ для работы Windows 7, 8 или 10 на носителе (т.е. реальном компьютере).

Не изменяйте никакие настройки машины, если вы не уверены в правильности своих действий.

Часто пользователи пытаются ускорить Windows 10 на Virtualbox, добавляя ядра до отказа и изменяя другие параметры, но это наоборот приводит к снижению скорости работы машины.

Переместите файл виртуального жесткого диска на SSD

Windows 10 рассчитана на работу со скоростными накопителями, поэтому увеличить скорость чтения и записи с накопителем никогда не будет лишним. Читайте руководство о том, как переместить файл виртуального диска.

Используйте фиксированный жесткий диск

Обновите Virtualbox до последней версии

Включите поддержку виртуализации в UEFI / BIOS

Отключите визуальные эффекты Windows 10 в виртуальной машине

Возможно, будет интересно:

Добрый вечер!

Давно играюсь с виртуализацией, в т.ч. и на боевых серверах. Сейчас обнаружил, что описанное ниже проявляется и в KVM тоже (до сих пор считал, что нет). А именно, если выполняются следующие условия: 1) количество виртуальных процессоров во всех гостевых системах больше, чем физических процессорных ядер; и 2) какая-либо из виртуальных машин сконфигурирована более чем с одним процессором/ядром — то в этой машине, да и в системе в целом, наблюдаются жуткие тормоза и неадекватная загрузка процессора (-ов). Впервые столкнулся с таким в WMWare Workstation, затем в VMWare Server, и считал это багом или особенностью VMWare, а сейчас увидел это и на KVM.

Почему тормозит виртуальная машина?

Немного погуглив, нашёл следующее:

> Virtualized CPUs are overcommitted best when each virtualized guest only has a single VCPU. The Linux scheduler is very efficient with this type of load. KVM should safely support guests with loads under 100% at a ratio of five VCPUs.

Что, собственно, и наблюдается — на машине с одним двухъядерным процессором может висеть полтора десятка слабо нагруженных виртуалок, и работать нормально, но только если каждая из них — однопроцессорная.

> Assigning guests VCPUs up to the number of physical cores is appropriate and works as expected. For example, running virtualized guests with four VCPUs on a quad core host. Guests with less than 100% loads should function effectively in this setup.

А вот здесь не очень понятно. То, что не надо делать виртуалку с числом процессоров больше, чем их физически есть, это понятно. Но означает ли эта фраза, что физических процессоров/ядер должно хватать на _все_ запущенные виртуалки? Мне как-то казалось, что это было бы не очень логично, но на практике получается, что это так и есть. К примеру, одна двухпроцессорная виртуалка на двухъядерном процессоре работала нормально, пока не добавилась ещё одна двухпроцессорная виртуалка. После этого — перманентные тормоза и 100% загрузка процессора. Примерно то же наблюдалось, когда к куче нормально работающих однопроцессорных виртуалок (в количестве, намного превышающем количество физических ядер) добавилась одна двухпроцессорная.

Вопрос состоит в следующем: это дело принципиально можно как-то победить в линуксе? Если это принципиально непобедимо в KVM, может какой-то другой гипервизор справится? Как с этим обстоит в VirtualBox, к примеру?

Я знаю один гипервизор, который такую ситуацию пережёвывает хорошо. Это VMWare ESXi. Но это не совсем линукс, к сожалению. А хочется именно его.

Выбираем виртуальную машину — VMware ESXi

Октябрь 31, 2011

Производительность современных компьютеров давно уже превосходит стандартные потребности большинства организаций и отдельных индивидуумов. И все чаще вместо нескольких серверов место в стойке занимает один единственный, который затем уже «нарезается» на несколько машин. С выбором железа обычно проблем нет, а вот систему виртуализации подобрать ближе к своим задачам сложнее.

VMware ESXi

Все кто работал с виртуальными машинами с начала века, хорошо знает продукты VMware, пользовавшиеся популярностью благодаря своим возможностям и производительностью. Да и сегодня на десктопах не редко можно найти VMware Workstation и VMware Player. Последний появился как ответ MS VirtualPC и является бесплатной версией Workstation. Работает он из под установленной ОС, то есть в промышленной среде не совсем подходит. Для установки на «голое железо» предлагается VMware ESXi – самостоятельный продукт являющийся основой для установки гостевых ОС и совместно с VMware vSphere (подробнее в статье Виртуальная сфера в ][ 08.2010) средством для построения виртуальной инфраструктуры и управления виртуальными ресурсами. По сути ESXi это сильно урезанная версия Linux содержащая гипервизор (VMkernel) и консоли управления vCLI (vSphere CLI), PowerCLI (PowerShell интерфейс к vCLI), SSH и DCUI (Direct Console User Interface).
Ранее ESXi считался “младшим братом” в линейке продуктов VMware. Был бесплатным вариантом урезанным по функциональности другого решения ESX. Но время ESX прошло, следующие версии VMware VSphere будут включать поддержку исключительно ESXi (предложено также его альтернативное название — VMware vSphere Hypervisor), а все преимущества ESX над ESXi сведены на нет. Поэтому разработчики рекомендуют переходить с ESX на ESXi.
Главное отличие ESXi vs ESX состоит в архитектуре. Основой ESX служит полноценная версия Linux, на которую можно устанавливать при необходимости свои приложения, агенты VMware работают через COS (Console OS), то есть через дополнительный уровень. В итоге мы имеем больший размер дистрибутива ~2 Гб, по сравнению с 350 Мб ESXi (на хард ставится всего 70Мб). В ESXi агенты работают прямо в VMkernel, при необходимости модули сторонних разработчиков (мониторинг, драйвера) также выводятся на гипервизор. Уменьшение слоев означает большую надежность и безопасность, меньше возможности для атак. Дистрибутив можно записать на флэшку или вообще вшить в firmware сервера.

Из-за особенности официальный список совместимого оборудования у ESXi (clck.ru/9xlp) меньше чем ESX, который поддерживается и старыми серверами, но со временем он увеличится. Кроме этого добровольцами создан неофициальный список компьютеров ESXi Whitebox HCL (clck.ru/9xnD) на которых работает VMware ESXi. Системы из этого списка используются на свой страх и риск, но обычно проблем не возникает.
Продукт от VMware отличает поддержка большого количество гостевых ОС. Здесь полный фарш — Windows, Linux, Solaris, FreeBSD, Netware и многие другие, полный список доступен на сайте.
Функциональность последних релизов ESXi уже «подтянули» под возможности ESX — появилась интеграция с Active Directory (любая учетная запись будет проверяться в каталоге), функции расширенного управления памятью (неиспользованные ресурсы освобождаются), совместная работа с системами хранения данных VMware vStorage VMFS/Storage VMotion и SAN, настройка приоритетов трафика, технология безопасности VMsafe Security API. Гибкое распределение ресурсов позволяет «на горячую» добавить CPU, ОЗУ, жесткий диск, в том числе и изменить размер текущего без перезагрузки. Установка дистрибутива на голое железо очень проста (стандартный вариант с привода или через PXE), с версии 4.1 к тому же поддерживаются сценарии позволяющие автоматизировать процесс инсталляции ПО, настройку сети и подключения к vCenter Server. Через VSphere API интегрировано управления резервного копированием ESXi.
Не маловажно наличие специального конвертера VMware vCenter Converter (vmware.com/products/datacenter-virtualization/converter), позволяющего использовать в ESXi образы MS Virtual Server, Virtual PC, Hyper-V, физические серверы и образы дисковых разделов созданных такими программами как Acronis True Image, Norton Ghost и другими.
Кроме этого помочь в развертывании ESXi может и бесплатный веб-сервис VMware Go (go.vmware.com), позволяющий протестировать физический сервер на совместимость, установить ESXi и создать новые VM.

В этой статье мы рассмотрим то, как ускорить работу Ubuntu 16.04 и 17.04 в VirtualBox и, сделать систему намного производительней чем до руководства. Знаете ли вы, почему Ubuntu работает так медленно в VirtualBox? Обычно Основная причина заключается в том, что графический драйвер по умолчанию, установленный в VirtualBox, не поддерживает 3D-ускорение. Чтобы ускорить работу системы Ubuntu в VirtualBox, вам нужно установить специальные дополнения, которые содержат более мощный графический драйвер, поддерживающий 3D-ускорение.

Как проверить, поддерживается ли 3D-ускорение?

Запустите свою виртуальную машину и соответственно операционную систему Ubuntu. Затем в окне «Терминала» введите следующую команду:

/usr/lib/nux/unity_support_test -p

Это выход на недавно установленный драйвер.

Кстати, мы уже делали с этой статьей можно ознакомиться здесь.

Посмотрите на последнюю строку, которая говорит нам, что Unity 3D не поддерживается. Мы должны это исправить.

Как ускорить работу Ubuntu 16.04 и 17.04 в VirtualBox путем установки драйверов и дополнений

Добавление гостевых виртуальных машин VirtualBox позволяет вам создавать общие папки, включать двунаправленный общий буфер обмена между хостом и гостем, а также увеличивать графическую производительность вашей гостевой машины. Это набор драйверов устройств (графических и машинных драйверов) и системных приложений, которые будут установлены в вашей ОС.

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

sudo apt update && sudo apt dist-upgrade

Обратите внимание: если установлено новое ядро, то вам нужно перезагрузить Ubuntu. После этого установите необходимые пакеты для сборки модулей ядра.

sudo apt install build-essential module-assistant dkms

Затем подготовьте свою систему для сборки модуля ядра.

Должно появится примерно такое:

В строке меню VirtualBox выберите «Устройства/Devices »> «Вставить гостевой образ CD/Insert Guest Additions CD image ».

Вас могут попросить загрузить CD-диск или флешку с «гостевыми» дополнениями, если его невозможно найти на вашем жестком диске. Нажмите на кнопку «Загрузить». По завершению загрузки нажмите на кнопку «Вставить», чтобы добавить образ компакт-диска в виртуальный оптический дисковод.

Если ранее загруженный образ CD-диска уже был добавлен, то вас попросят запустить содержащееся в нем программное обеспечение, далее нажмите на кнопку «Выполнить».

Затем введите свой пароль, и система начнет компилировать «гостевые» модули ядра VirtualBox. Вам может быть сообщено, что ваша система уже имеет актуальную версию этих дополнений для VirtualBox, но встроенная версия имеет медленную производительность и качество. Поэтому введите «yes», чтобы продолжить.

Затем как установка гостевых дополнений завершится вам нужно будет нажать на кнопку «Ввод», чтобы закрыть окно терминала и завершить работу виртуальной машины Ubuntu. (Перезагрузить Ubuntu лучше потом)

Перейдите к настройкам программы VirtualBox. Нажмите «Display » на левой панели. На вкладке «Экран» выделите видеопамять 128M для виртуальной машины Ubuntu и убедитесь, что включена опция «Включить 3D-ускорение ». Сохраните настройки.

Запустите виртуальную машину Ubuntu. Теперь система должна работать намного быстрее, потому что графические возможности системы и Unity 3D теперь полноценно поддерживаются новым графическим драйвером. Далее, выполните следующую команду в окне терминала:

/usr/lib/nux/unity_support_test -p

Там Вы увидите, что Unity 3D поддерживается.

Выводы

Вы также можете проверить дополнительные подсказки для ускорения работы Ubuntu, которая также подходит для виртуальной машины Ubuntu.

Отлично! Надеюсь, этот урок помог вам ускорить работу Ubuntu в VirtualBox. Как всегда, если вы нашли эту статью полезной, подпишитесь на нашу бесплатную рассылку или расскажите о новой полезной информации в VK, Facebook или Twitter.

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

Если у вас остались вопросы или есть что дополнить по теме «Как ускорить работу Ubuntu 16.04 и 17.04 в VirtualBox» то, пишите в форму комментариев на нашем сайте.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .

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

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

Согласитесь, что при таком раскладе виртуальная машина будет тормозить, по крайней мере это точно будет заметно пользователю. По это причине разработчики стараются применять определенные ухищрения, чтобы как-то ускорить процесс работы виртуальной машины – оптимизировать его. Например, разработчики из компании Parallels придумали следующее ухищрение: они стали предоставлять жесткому диску дополнительный уровень буферизации запросов, что в свою очередь позволило гостевой ОС Windows стартовать гораздо быстрее.

Не стоит делать вывод, что виртуальная машина способна исключительно тормозить работу любимых нами программ и утилит. Может показаться невероятным, но это факт, подтвержденный не одним примером, некоторые приложения работают в виртуальных машинах гораздо быстрее нежели на реальном компьютере. Вы можете сами убедиться в этом, правда для этого вам потребуется компьютер с многоядерным процессором и конечно же требовательное к системным ресурсам приложение, которое по какой-то причине не умеет правильно работать на многоядерном процессоре. Таких программа масса, найти одну из них в Интернете и скачать для эксперимента не составит никакого труда. Если запустить такое приложение в виртуальной среде, выделив для нее не четыре процессорных ядра, а скажем два или один, то оно в виртуальной машине будет работать намного быстрее и стабильнее, нежели на реальном компьютере. Помимо этого, дополнительное кэширование (о котором мы говорили выше) в хосте гостевого жесткого диска может значительно ускорить работу гостевой операционной системы. Стоит отметить, что такой способ ускорения работы виртуальной машины называется опасным, так как грозит потерей всех данных гостевой операционной системы (а возможно и разрушением ее файловой системы), если в момент работы внезапно произойдет отключение питания.

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

Сегодня на этом все, в следующей статье мы вместе с вами попробуем представить себе будущее виртуальных маши, и постараемся побыстрее перейти от теории к практике.

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

Типовая проблема «виртуализаторов» - владелец сервиса, заказчик или пользователь жалуется, что у него «тормозит» виртуальная машина. Так как виртуализация предполагает консолидацию большого количества ВМ на базе одного комплекта аппаратных ресурсов, переподписку (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% развивается высокая вероятность сбоев и зависаний гостевой ОС. Причиной вынужденного простоя может стать:

интенсивное потребление процессорных ресурсов большим количеством ВМ, причём суммарное количество vCPU существенно превышает количество логических ядер (переподписка).
Наличие oversized ВМ (виртуальные машины с большим количеством недозагруженных vCPU, например если у машины 16 ядер, каждое из которых работает на 1-20% мощности). Проблема тут в том, что при большом количестве vCPU, планировщику гипервизора приходится синхронизировать их работу, что приводит к периодическому «замораживанию» некоторых ядер или даже всей машины, пока не освободится полное количество логических ядер, соответствующее количеству vCPU, необходимое для определённой операции. Механизм называется Co-Stop, и соответствующий счётчик будет расти в этом случае. Это главный аргумент против набивания виртуальной машины виртуальными процессорами «про запас» (второй аргумент - NUMA, но он уже за рамками статьи). Лучше 2 ядра, загруженных на 80%, чем восемь ядер по 20%. В большинстве случаев.
Если использование CPU для виртуальной машины ограничено на уровне Resource Pool или самой машины. По достижению определённого порога, машина не получит процессорных ресурсов и будет накапливать CPU Ready. В этом случае будет увеличиваться значение счётчика Max-Limited (%ML).

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 на каждом.

Ещё раз, формула преобразования: <значение CPUReady> /<интервал статистики в мс> / <количество vCPU> * 100% . Получается 5% на 1000 мс для одного ядра.

Тут значение указано сразу в %. Только оно указано сразу в сумме для всех ядер, так что не стоит пугаться чисел больше 100. Делите на количество vCPU машины.

3. Оперативная память

Базовая диагностика здесь простая - да или нет. Если есть факт balooning"а значит хосту не хватает памяти и процессы гостевых ОС страдают, потому что активно используется файл подкачки. Если есть факт свопинга на уровне гипервизора, надо срочно принимать меры - машина попавшая в своп впадает в кому в 100% случаев (по крайней мере моей практики). Вышеуказанные факты позволяют определить такие счётчики как

Balloon (MCTLSZ) - количество памяти, вытянутое baloon-драйвером из гостевых ОС.

Swapped (SWCUR) - количество памяти, помещённое в.vswp (то есть на жёский диск).

4. Сеть

Чтобы проблемы были на уровне сети, в случае жалоб на отдельную виртуальную машину, я в своей практике помню только один случай - когда в VDI использовалась какая-то дешёвая веб-камера, гнавшая несжатый поток видео и забивавшая все 100 Мб/с.

Стоит мониторить такие счётчики:

Transmit Dropped Packets (%DRPTX) - количество (или процент в случае esxtop) отброшенных отправленных пакетов;

Receive Dropped Packets (%DRPRX) - количество (процент) отброшенных принятых пакетов.

Ненулевое их значение, возникающее на регулярной основе говорит о некорректной работе сетевых устройств или некорректной их настройке.

Для базовой диагностики, покрывающей более половины (пожалуй, до 90%) обращений или собственных потребностей при диагностике и тестировании, этого достаточно.