Не хватает памяти виртуальной машине: всегда ли нужно увеличивать RAM?

Зависит от причины. Если paging или swap растут только в одной VM, а на хосте нет давления памяти, после проверки утечки и процессов гостя можно увеличить RAM. Но при ballooning, сжатии или swapping на хосте добавление памяти одной VM способно ухудшить ситуацию для соседних машин. Тогда сначала снижают overcommitment или переразмещают нагрузку.

Поможет ли расширение виртуального диска при высокой задержке I/O?

Нет, если проблема именно в высокой задержке storage. Расширение виртуального диска помогает при заполнении файловой системы гостя, но не сокращает latency операций чтения и записи. При медленной работе нужно сопоставить задержку, очередь I/O, IOPS, пропускную способность, состояние datastore и активность других VM на том же хранилище.

Может ли лимит ресурсов замедлять VM при свободном хосте?

Да. Лимит CPU или I/O способен ограничивать VM даже при наличии свободной физической ёмкости на хосте или в хранилище. Перед увеличением vCPU, памяти или изменением размещения проверьте назначенные лимиты: ошибочно заданное ограничение иногда достаточно убрать, чтобы устранить подтверждённый симптом.

Нужно ли уменьшать число vCPU у мало загруженной VM?

Иногда нужно. Если VM стабильно использует малую часть назначенных vCPU, на хосте есть конкуренция и наблюдаются признаки сложного планирования, например Co-stop в vSphere, уменьшение числа vCPU может снизить задержки. Однако это не ускорит одиночный поток и может навредить приложению с реальной параллельной нагрузкой.

Можно ли изменить vCPU или память без выключения виртуальной машины?

Зависит от платформы и конфигурации VM. Поддержка hot-add CPU и памяти определяется гипервизором, версией виртуального оборудования и гостевой ОС; для части машин потребуется выключение. Изменение числа vCPU, топологии сокетов, ядер или виртуального NUMA также может повлиять на лицензирование и поведение приложения, поэтому нужно планировать окно работ.

Производительность виртуализации: ресурсы VM и поиск узких мест

Q: Что контролировать при thin provisioning, чтобы не закончилось место?

Контролируйте не только логический размер виртуальных дисков, но и фактическое потребление, свободную ёмкость datastore или пула, темп роста данных, снимки и операции консолидации. Нехватка места на общем хранилище может затронуть несколько VM. Не удаляйте вручную файлы виртуальных машин, дисков или снимков.

Медленная виртуальная машина не доказывает, что ей нужно больше ресурсов. За один и тот же интервал сопоставьте симптомы сервиса в гостевой ОС, метрики VM, хоста виртуализации, хранилища и сети; только после подтверждения конкретного дефицита меняйте vCPU, память, дисковые параметры или правила распределения ресурсов. Избыточное выделение CPU и памяти тоже способно ухудшить производительность соседних VM.

Диагностический маршрут: от симптома к ресурсу

Начинайте не с изменения конфигурации, а с фиксации симптома: какой сервис стал отвечать медленнее, когда это началось, затронута ли одна VM или несколько, постоянна ли проблема либо появляется на пике. Выберите единый интервал — например, время медленного запроса или пакетной обработки. Для локализации одного эпизода сопоставляйте метрики за один период; данные других часов используйте только как базовый уровень при сходной нагрузке.

Проверка медленной VM

Маршрут подходит для vSphere, Hyper-V, Proxmox VE и KVM/libvirt. Названия экранов, счётчиков, единицы и доступность телеметрии зависят от версии гипервизора, средства управления, лицензирования, гостевых инструментов и настроек сбора статистики. Для конкретного релиза сверяйте названия и смысл показателей с официальным руководством используемой платформы.

1
Зафиксируйте интервал и масштаб
Запишите время, длительность, операцию пользователя и затронутые VM. Проверьте события VM, хоста и хранилища в этот же период. Если одновременно замедлились VM на одном узле или одном datastore, причина вероятнее находится ниже гостевой ОС.
2
Проверьте гостевую ОС и приложение
Смотрите загрузку CPU, использование и paging памяти, задержки и очередь диска, сетевые ошибки и ретрансляции, а также метрики самого приложения: число запросов, пул соединений, блокировки СУБД, время внешних вызовов. Высокая загрузка внутри гостя при отсутствии конкуренции на хосте чаще указывает на профиль приложения или недостаток выделенного ресурса именно этой VM.
3
Сопоставьте показатели VM с хостом
Проверьте фактическое потребление CPU и памяти VM, ожидание CPU у планировщика, наличие лимитов, давление памяти хоста и загрузку других VM. Если у гостя высокий CPU, но ожидания процессорного времени нет и у хоста есть запас, добавление vCPU может помочь только после проверки, что приложение умеет распараллеливаться.
4
Проверьте хранилище и сеть
Сравните задержку чтения и записи, длину очереди, IOPS, пропускную способность, свободное место и активность других VM на том же хранилище. Для сети сопоставьте задержку до зависимого сервиса, потерю пакетов, ошибки интерфейсов и загрузку виртуального и физического пути.
5
Сделайте минимальное изменение
Уберите ошибочно заданный лимит, увеличьте один подтверждённо дефицитный ресурс, перенесите конкурирующую нагрузку либо освободите место на хранилище. Не меняйте одновременно vCPU, память и размещение VM: иначе нельзя понять причину улучшения или ухудшения.
6
Проверьте эффект на сопоставимой нагрузке
Повторите операцию приложения и сравните тот же набор метрик с исходным интервалом. Одновременно убедитесь, что не выросли ожидание CPU, давление памяти, задержки хранилища и проблемы у соседних VM.

Симптомы и первичная локализация

Симптом	Вероятные причины	Что сравнить за один интервал	Возможное действие после подтверждения
Высокий CPU в гостевой ОС	Нагрузка приложения, недостаток вычислительной мощности VM, неэффективный запрос или процесс	CPU гостя, активные процессы, CPU VM, ожидание CPU гипервизора, загрузку хоста	Оптимизировать нагрузку; увеличить vCPU только при запасе на хосте и способности приложения использовать параллелизм
VM медленна при умеренном CPU в госте	Конкуренция за CPU на хосте, задержки диска, ожидание сети или приложения	Ожидание CPU, дисковую задержку и очередь, сетевые ошибки, время внешних зависимостей	Устранить подтверждённое узкое место, а не добавлять vCPU наугад
Память «заканчивается» в госте	Нехватка RAM в госте, утечка, paging гостя, давление памяти хоста	Доступную память и paging гостя, ballooning, сжатие и swapping на хосте	Устранить утечку или увеличить память VM; при давлении хоста снизить overcommitment либо переразместить VM
Медленные операции с файлами или СУБД	Высокая задержка хранилища, очередь, конкурирующая VM, снимки, ограничение пропускной способности	Latency, очередь, IOPS, MB/s, состояние datastore, активность других VM	Устранить конфликт или проблему storage; расширение виртуального диска не лечит latency
Мало места на диске гостя	Заполнена файловая система VM, а не обязательно хранилище	Свободное место внутри гостя, размер виртуального диска, свободную ёмкость datastore	Освободить место либо штатно расширить виртуальный диск и раздел; отдельно контролировать datastore
Медленный удалённый сервис	Сетевая задержка, потери, ошибки адаптера, перегрузка канала или медленный удалённый узел	RTT, потери, retransmits, ошибки vNIC/uplink, загрузку сети и время ответа сервиса	Локализовать участок сети или внешнюю зависимость; настройка VLAN и vSwitch рассмотрена в статье о сетях VM

CPU: нагрузка гостя и конкуренция на хосте — разные сигналы

Высокий CPU utilisation внутри гостевой ОС означает, что процессы гостя используют предоставленное им процессорное время. Это может быть нормальной работой приложения: например, обработкой отчёта, компиляцией или запросом СУБД. Сам по себе этот показатель не говорит, что VM ожидает физический CPU.

В VMware vSphere CPU Ready показывает ожидание готовой к работе vCPU доступа к логическому процессору ESXi. Рост CPU Ready одновременно с загрузкой хоста и замедлением VM — признак конкуренции за CPU. Это не процент загрузки гостевой ОС: интерпретация зависит от представления статистики, длины интервала и единиц, которые выводит конкретный клиент или API.

Для многопроцессорной VM vSphere также может показывать Co-stop: задержку vCPU, нужную планировщику для ограничения рассинхронизации виртуальных процессоров. Повышенный Co-stop не следует читать отдельно от размера VM, CPU Ready и профиля приложения, но он может подтвердить, что VM с большим числом vCPU трудно эффективно планировать на занятом хосте.

В Linux-госте на KVM иногда доступен steal time: время, когда vCPU был готов работать, но не получил процессор. Его наличие и точность зависят от гостевой ОС, режима виртуализации и источника статистики. Steal time полезно сопоставлять с загрузкой CPU хоста и очередями выполнения, но нельзя механически приравнивать к CPU Ready vSphere: это метрики разных уровней и реализаций.

Как читать CPU-симптомы

Наблюдение	Что оно скорее означает	Что проверить дальше
Высокий CPU гостя, ожидание CPU гипервизора низкое	Приложение активно использует выделенные CPU; физический хост может не быть узким местом	Процессы и потоки приложения, способность масштабироваться, лимит CPU VM
CPU гостя может быть невысоким, но ожидание CPU растёт	Гость часто не получает процессор вовремя и может простаивать в ожидании планирования	Загрузку хоста, число и размер соседних VM, CPU limit, размещение нагрузки
Высокие CPU Ready и Co-stop у крупной VM	Возможна конкуренция и сложность планирования нескольких vCPU	Нужны ли все vCPU приложению, NUMA-топологию, активность соседних VM
Высокий steal time в Linux-госте	Возможна конкуренция за CPU на уровне гипервизора	Статистику KVM/хоста, CPU других гостей, лимиты и квоты

Когда увеличивать и когда уменьшать vCPU

Увеличивать число vCPU имеет смысл, если приложение действительно ограничено CPU, умеет использовать дополнительные потоки, у VM нет выраженного ожидания CPU, а на хосте или в кластере есть вычислительный запас. До изменения проверьте CPU limit: лимит может сдерживать VM даже при свободных ядрах.

Уменьшение vCPU стоит рассматривать, когда VM стабильно использует лишь малую часть назначенных процессоров, на хосте есть конкуренция, а у VM наблюдаются признаки сложного планирования, включая Co-stop в vSphere. Маленькая VM обычно проще размещается планировщиком. Это не правило «чем меньше, тем лучше»: сокращение vCPU само по себе не ускоряет отдельный поток и может навредить сервису с реальной параллельной работой. Однако уменьшение завышенного числа vCPU способно улучшить работу VM, если оно снижает задержки планирования, Co-stop или неблагоприятное влияние виртуальной NUMA-топологии.

Изменение CPU и NUMA

Изменение числа vCPU, топологии сокетов и ядер, виртуального NUMA и горячее добавление CPU зависят от гипервизора, версии виртуального оборудования и поддержки гостевой ОС. Для части VM потребуется выключение, а изменение топологии может повлиять на лицензирование и поведение приложения. Планируйте окно работ и сверяйтесь с документацией своей платформы.

Память: нехватка в госте, давление хоста и overcommitment

Нехватка памяти внутри VM проявляется прежде всего в гостевой ОС: уменьшается доступная память, растёт paging или swap, процессы могут ждать ввода-вывода, а приложение — завершаться из-за невозможности выделить память. Причина может быть в малом объёме RAM, утечке памяти, слишком большом кеше, росте числа пользователей либо изменении профиля нагрузки.

Давление памяти на хосте — другое состояние. При overcommitment суммарно назначенная память VM превышает физическую RAM хоста в расчёте на неполное одновременное потребление. Пока пики не совпадают, это может работать приемлемо; если совпадение потребления создаёт дефицит физической памяти, гипервизор может применить собственные механизмы возврата или экономии памяти, а задержка способна затронуть несколько VM.

В vSphere следует различать потребление памяти VM, давление памяти хоста, балунирование памяти, сжатие и swapping гипервизора. Ballooning требует работающего гостевого драйвера и предлагает гостю освободить память; гостевая ОС может ответить собственным paging. Сжатие и особенно swapping на уровне гипервизора означают более жёсткое давление и способны заметно увеличить задержки. Нулевое ballooning само по себе не является проблемой, а ненулевое значение нужно оценивать вместе с состоянием гостя и хоста.

В Hyper-V проверяйте память отдельно на хосте, в гостевой Windows и по данным VM. Динамическая память Hyper-V изменяет объём памяти VM в заданных пределах; она не равна механизму ballooning vSphere и не отменяет потребность приложения в предсказуемой RAM. Полезно сопоставить доступную память и paging гостя с назначенной, demand и состоянием Dynamic Memory VM, а также с доступной памятью самого Windows Server-хоста.

Различение проблем с памятью

Признак	Вероятная причина	Проверка	Корректирующее действие
Paging или swap растёт только в одной VM, хост без давления	VM не хватает выделенной памяти или есть проблема приложения	Доступную память, page faults и процессы гостя; память других VM и хоста	Устранить утечку или увеличить RAM этой VM после оценки запаса
Несколько VM медленнее, есть ballooning или сжатие на хосте	Давление памяти из-за консолидации или совпадения пиков	Метрики памяти хоста, VM и гостей за один период	Снизить плотность размещения, перераспределить нагрузки, пересмотреть назначение памяти
Растёт объём памяти, выгруженной гипервизором, или активны swap-in и swap-out	Текущее сильное давление памяти хоста	Динамику swap за исследуемый интервал, задержки VM, доступную RAM хоста и профиль нагрузки	Уменьшить нагрузку или overcommitment, освободить физическую память и затем проверить эффект
Dynamic Memory Hyper-V меняет память VM	Работа механизма по заданным минимуму, максимуму и спросу	Параметры VM, память гостя и хоста, поведение приложения	Скорректировать границы только при подтверждённой потребности и достаточной памяти хоста

Не путайте назначенную и реально доступную память

Увеличение памяти одной VM при дефиците RAM на хосте может усилить давление на остальные VM. Изменение RAM и hot-add памяти поддерживаются не каждой комбинацией гипервизора, версии виртуального оборудования и гостевой ОС; иногда VM необходимо выключить. После изменения обязательно проверьте paging гостя и давление памяти хоста.

Диск: задержка важнее одного значения IOPS

IOPS показывает число операций ввода-вывода, но не отвечает, были ли они выполнены быстро. Для диагностики дисковой производительности нужны как минимум задержка чтения и записи, длина очереди, IOPS, пропускная способность, тип операций и состояние хранилища. У СУБД или файлового сервиса рост latency часто важнее абсолютного числа IOPS: одинаковое значение IOPS может быть нормальным для одной нагрузки и проблемным для другой.

Сравнивайте метрики диска внутри гостя с метриками виртуального диска и общего хранилища. Если очередь и задержка высоки уже в гостевой ОС, а на datastore или томе в тот же момент растёт latency, проблема вероятно ниже приложения. Если задержка видна только в одной VM, проверьте её собственный профиль I/O, снимки, лимиты и конкурирующие процессы. Длительные снимки способны увеличивать нагрузку на операции с диском; их жизненный цикл рассмотрен в статье о клонах, шаблонах и снимках.

Недостаток свободного места внутри файловой системы VM и медленное хранилище — разные проблемы. Расширение виртуального диска помогает, когда заполнен раздел гостя, но не сокращает задержку операций на storage. И наоборот, свободное место в госте не гарантирует свободную ёмкость datastore. Для VMware связь размещения VM, свободного пространства и типов хранилища разобрана в материале о datastore и vSAN.

Что проверять при дисковой медлительности

Показатель	Что помогает отличить	Как реагировать
Latency чтения и записи	Задержку storage от простого роста объёма операций	Сопоставить с обычным уровнем сервиса и метриками datastore или массива
Очередь I/O	Накопление запросов перед медленным устройством или при перегрузке	Проверить вместе с latency, а не использовать как универсальный порог
IOPS и MB/s	Характер нагрузки: много мелких операций или потоковая передача	Найти пики, совпадение с резервным копированием, обработкой данных или соседней VM
Свободное место в госте	Заполнение раздела VM	Освободить место или штатно увеличить диск, затем расширить файловую систему
Свободная ёмкость datastore	Риск заполнения общего хранилища, особенно при thin provisioning и snapshot	Высвободить или увеличить ёмкость контролируемым способом
Активность других VM на том же storage	Конкуренцию за общее хранилище	Перенести или разнести подтверждённо конфликтующие нагрузки с учётом возможностей платформы

Сеть и сама гостевая нагрузка

Медленный ответ приложения может быть вызван сетью, но высокая задержка TCP не доказывает проблему виртуального коммутатора. Сопоставьте время ответа от VM до зависимого сервиса, потери пакетов, TCP retransmits, ошибки и сбросы на vNIC, uplink и физическом адаптере, а также загрузку канала. Если ошибки отсутствуют, а удалённая СУБД отвечает медленно, причина может быть на стороне СУБД или её хранилища.

Проверьте и прикладной уровень: очереди веб-сервера, блокировки базы данных, исчерпание пула подключений, лимиты API, сборку мусора, фоновые задания. Гипервизор показывает распределение инфраструктурных ресурсов, но не объясняет сам по себе медленный SQL-запрос или последовательный алгоритм. Настройка VLAN, vSwitch и bridge не входит в эту диагностику; она описана в статье о виртуальных сетях.

Overcommitment, thin provisioning и политики распределения

Overcommitment CPU и памяти оправдан не суммой «малых» VM, а наблюдаемым профилем: когда известны обычное и пиковое потребление, есть физический запас и понятна реакция на совпадение пиков. Для CPU допустима определённая конкуренция, но рост ожидания процессорного времени на критичных VM означает, что плотность размещения или профиль нагрузки нужно пересматривать. Для памяти риск выше: давление может привести к paging в гостях или swapping гипервизора.

Thin Provisioning экономит начальную физическую ёмкость, выделяя место по мере записи. Поэтому контролируют не только логический размер виртуальных дисков, но и фактическое потребление, свободное пространство datastore или пула, темп роста данных, снимки и операции консолидации. Нехватка места на общем хранилище способна затронуть несколько VM; не удаляйте вручную файлы VM, дисков или снимков.

Политики ресурсов применяют при конкретной цели

Механизм	Когда уместен	Последствия и проверка
Лимит ресурсов	Нужно сознательно ограничить потребление VM или группы, например для защиты общего пула от некритичной нагрузки	Может замедлять VM даже при свободной физической ёмкости. Проверьте, не является ли лимит причиной CPU- или I/O-симптома
Резервирование ресурсов	Критичной VM нужен гарантируемый минимальный объём CPU или памяти	Уменьшает незарезервированную ёмкость и гибкость размещения; при недостатке ресурсов может помешать запуску или миграции других VM
Доли ресурсов	Нужно задать относительный приоритет среди конкурентов одного уровня	Обычно влияют только при дефиците; сами по себе не создают ресурс и не являются фиксированной гарантией
CPU weight, quota или аналог в KVM/Proxmox	Нужно управлять относительным доступом или ограничением CPU в конкретном стеке	Семантика зависит от механизма: не переносите настройки и ожидания VMware в Linux cgroups или Proxmox без проверки документации
Dynamic Memory Hyper-V	Подходящая гостевая нагрузка допускает динамическое изменение памяти в заданных границах	Не тождественна reservation или shares; оцените совместимость гостя и поведение приложения при изменении памяти

Лимит не является защитой от всех последствий

Лимит CPU или памяти может защитить соседние VM от одной прожорливой нагрузки, но одновременно создать искусственное узкое место для самой VM. Резервация гарантирует минимальный объём ресурса и уменьшает незарезервированную ёмкость для размещения других машин; относительный приоритет при конкуренции задают доли ресурсов. Перед изменением оцените влияние на запуск, миграцию, отказоустойчивость и соседние сервисы.

Метрики и термины в vSphere, Hyper-V, Proxmox VE и KVM/libvirt

Сходные задачи не означают одинаковые метрики

Платформа	CPU и конкуренция	Память	Диск и сеть	Особенности интерпретации
VMware vSphere	CPU usage VM и хоста, CPU Ready, для многопроцессорных VM — Co-stop	Потребление VM, давление хоста, ballooning, compression, swapping; limits, reservations и shares	Метрики виртуальных дисков, адаптеров и datastore	CPU Ready и Co-stop зависят от интервала и представления статистики. Набор счётчиков и функции управления зависят от релиза, лицензирования и средств vCenter/ESXi
Hyper-V и Windows Server	Данные Hyper-V и системные счётчики Windows хоста, показатели CPU гостя	Память хоста и гостя, параметры и спрос Dynamic Memory при её использовании	Счётчики виртуальных дисков и сетевых адаптеров Hyper-V, системные данные Windows	Разделяйте счётчики родительского раздела, VM и гостевой ОС; названия и доступность зависят от версии Windows и способа сбора
Proxmox VE	Встроенные графики потребления CPU виртуальной машиной и узлом; загрузка CPU внутри гостя и steal time, если он доступен, проверяются в гостевой ОС	Статистика узла и настройки памяти VM; отображение данных ballooning зависит от конфигурации и драйвера VirtIO Balloon в госте	Графики диска и сети VM и узла, состояние настроенного хранилища	Proxmox VE использует KVM/QEMU для VM, но собственные настройки и отображение статистики не следует считать прямым аналогом vSphere. График памяти VM не заменяет проверку доступной памяти и paging внутри гостевой ОС
KVM/QEMU/libvirt	Статистика процесса QEMU, хоста Linux, cgroups; данные гостя и steal time при доступности	Память процесса и хоста, cgroup-ограничения, данные гостевой ОС	Статистика блочных устройств и интерфейсов через libvirt, ОС и хранилище	Набор данных зависит от QEMU, libvirt, драйверов, гостевого агента и того, чем управляют VM

В vSphere параметры CPU/memory limits, reservations и shares являются политиками планировщика ресурсов VM, пулов и кластера в рамках возможностей конкретной редакции. В Hyper-V, Proxmox VE и KVM/libvirt есть собственные механизмы ограничений, весов, квот или динамического выделения, но их единицы, область действия и гарантии различаются. Не называйте их взаимозаменяемыми без проверки документации конкретной версии.

Числовые пороги CPU Ready, Co-stop, latency, длины очереди и свободной памяти не универсальны. Их оценивают относительно нормального уровня этого сервиса, характера нагрузки, периода измерения, SLA и рекомендаций производителя платформы или хранилища. Разовый пик при резервном копировании и устойчивый рост в рабочие часы требуют разных решений.

Безопасная коррекция ресурсов VM

Сохраните исходные показатели: время отклика сервиса, CPU гостя и хоста, ожидание CPU, память, disk latency и свободную ёмкость storage.
Проверьте действующие лимиты, резервации, доли, квоты и параметры Dynamic Memory или cgroups. Не считайте настройки по умолчанию нейтральными, если их происхождение неизвестно.
Выберите одно минимальное действие: снять ошибочный лимит, увеличить RAM, изменить vCPU, освободить место, устранить конкурирующую нагрузку или перенести VM.
Проверьте, допускают ли гипервизор, версия виртуального оборудования и гостевая ОС изменение без выключения. Если нет — согласуйте окно, резервное копирование и план отката.
Выполните изменение штатными средствами платформы и повторите проверку на сопоставимой нагрузке.
Если узел перегружен подтверждённо, рассмотрите переразмещение VM или балансировку. Для VMware DRS и HA это отдельная тема: vSphere HA и DRS.

Что не следует менять для ускорения

Без подтверждённой причины не увеличивайте одновременно vCPU и RAM, не назначайте резервации всем VM, не отключайте лимиты без понимания их назначения и не расширяйте виртуальный диск для борьбы с latency. Защита, изоляция и шифрование VM не являются средствами оптимизации производительности; их назначение и ограничения описаны в статье о защите виртуальных машин.

Когда проблема не относится к производительности

Ошибки запуска VM, недоступный диск, потеря сети, сбои миграции и сообщения гипервизора требуют отдельной процедуры: диагностика проблем виртуальных машин и гипервизоров. Если причиной повторяющихся перегрузок оказывается недостаток архитектурного запаса, число хостов или возможности хранилища, переходите к проектированию серверной виртуализации, а не компенсируйте проблему постоянным overcommitment.

Термины в статье

Балунирование памяти: Механизм виртуализации, при котором гостевой balloon-драйвер помогает гипервизору вернуть часть закреплённой за ВМ памяти хоста в общий пул.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Виртуальное оборудование: Виртуальное оборудование — логическая аппаратная платформа, которую гипервизор предоставляет ВМ: виртуальные процессоры, память, устройства и системную прошивку.
Виртуальный сетевой адаптер: Виртуальный сетевой адаптер — логический сетевой интерфейс гостевой ВМ, подключаемый к виртуальному коммутатору и имеющий собственные MAC-адрес и настройки.
Виртуальный NUMA: Виртуальный NUMA — механизм гипервизора, представляющий гостевой ОС виртуальные NUMA-узлы, чтобы она учитывала локальность виртуальных процессоров и памяти на NUMA-хосте.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Динамическая память Hyper-V: Динамическая память Hyper-V — механизм Hyper-V, изменяющий объём ОЗУ, выделенный работающей ВМ, в пределах заданных параметров по её потребности в памяти.
Доли ресурсов: Доли ресурсов — относительный вес объекта среди конкурентов одного уровня планирования, определяющий его приоритет при дефиците ресурса.
Лимит ресурсов: Лимит ресурсов — верхняя граница потребления процессора, памяти или другого ресурса виртуальной машиной либо группой, действующая даже при наличии свободной ёмкости.
Процесс: Процесс — экземпляр выполняемой программы в Linux с PID, виртуальным адресным пространством, состоянием и связанными с ним ресурсами.
Резервирование ресурсов: Резервирование ресурсов — настройка минимальной доли CPU, памяти или иных ресурсов, которую гипервизор выделяет виртуальной машине или пулу при конкуренции.
Снимок состояния: Зафиксированное гипервизором состояние поддерживаемых виртуальных дисков и конфигурации ВМ на определённый момент, иногда также памяти, к которому можно выполнить откат.
Утечка памяти: Утечка памяти — ошибка управления жизненным циклом данных, при которой выделенная память больше не нужна, но не освобождается или остаётся достижимой по лишним ссылкам.
Хост виртуализации: Хост виртуализации — физический сервер или вычислительная система, на которой работает гипервизор и размещаются виртуальные машины; его CPU, память, сеть и хранилище распределяются между гостями.
Co-stop: Co-stop — метрика ESXi: время задержки готовой vCPU многопроцессорной ВМ для ограничения рассинхронизации выполнения её виртуальных процессоров.
CPU Ready: CPU Ready — метрика планировщика ESXi, показывающая время, когда готовый к выполнению vCPU ожидает доступа к логическому процессору хоста (pCPU); это не загрузка CPU гостевой ОС.
Datastore: Логический контейнер хранилища в VMware для размещения файлов виртуальных машин (диски, конфигурации, логи)
DRS: Функция VMware vSphere для управления размещением ВМ в кластере и балансировки ресурсов хостов с помощью рекомендаций или автоматических миграций vMotion.
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
Hot-Add: Hot-Add — добавление vCPU, памяти или виртуального устройства к работающей ВМ без её выключения; доступность зависит от платформы, конфигурации ВМ и гостевой ОС.
Hyper-V: Платформа виртуализации Microsoft с гипервизором типа 1, доступная как роль Windows Server и компонент Windows 10/11 Pro, Enterprise и Education.
IOPS: IOPS — число завершённых операций ввода-вывода в секунду, которое накопитель, RAID-массив или СХД обеспечивает при заданном профиле нагрузки.
KVM: Подсистема аппаратной виртуализации ядра Linux, предоставляющая пользовательским мониторам ВМ, обычно QEMU, интерфейс для запуска изолированных виртуальных машин.
libvirt: libvirt — открытый набор библиотек, API, служб и утилит для унифицированного управления ВМ, контейнерами, сетями и хранилищами на платформах виртуализации.
Overcommitment: Практика назначения виртуальным машинам суммарно большего объема CPU, памяти или хранилища, чем физически доступно хосту, в расчете на неполное одновременное потребление.
Proxmox: Открытая платформа серверной виртуализации на базе Debian, использующая QEMU/KVM для виртуальных машин и LXC для системных Linux-контейнеров.
Steal time: Steal time — показатель гостевой ОС: время, когда её vCPU был готов к выполнению, но гипервизор не предоставлял ему процессорный ресурс.
Swap: Swap — область на диске или SSD, используемая ядром Linux для размещения вытесненных страниц памяти, когда RAM требуется более активным данным.
Thin Provisioning: Метод предоставления логической ёмкости LUN, томам или виртуальным дискам, при котором физическое место выделяется по мере записи, а не резервируется целиком заранее.
Uplink: Uplink — соединение или интерфейс, ведущий от устройства либо локального сегмента к вышестоящей сети; в виртуализации — подключение виртуального коммутатора к физической сети.
vCPU: vCPU — виртуальный логический процессор, предоставляемый виртуальной машине; гипервизор планирует его выполнение на процессорных ресурсах хоста.
VMware: VMware — бренд Broadcom и семейство продуктов виртуализации; серверная платформа vSphere объединяет гипервизор ESXi и средства управления vCenter Server.
VMware ESXi: VMware ESXi — гипервизор типа 1, устанавливаемый непосредственно на совместимый физический сервер для запуска и управления виртуальными машинами.
vSphere: Платформа виртуализации VMware, включающая гипервизор ESXi и средства управления vCenter для корпоративной инфраструктуры