Виртуальная машина для Windows 11: метод оценки нагрузки

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

У Windows 11 есть дополнительные переменные. Функции безопасности на основе виртуализации могут влиять на работу системы, а активный Hyper-V способен изменить режим работы стороннего гипервизора. Поэтому сравнение VirtualBox и VMware на одном ПК начинается с проверки конфигурации хоста, а не с запуска бенчмарка.

Сначала зафиксировать конфигурацию

Результат имеет смысл только вместе с параметрами теста. Перед запуском виртуальной машины нужно записать редакцию Windows, модель процессора, объём оперативной памяти, тип накопителя, версию гипервизора и состояние функций VBS. Если в системе установлен процессор Intel с производительными и энергоэффективными ядрами, стоит отдельно учитывать их распределение между хостом и гостевой ОС.

В Windows 11 встроенный Hyper-V официально доступен в редакциях Pro, Enterprise и Education. В Home он по умолчанию отсутствует. Это не означает, что пользователь Home не может запускать виртуальные машины: доступны сторонние гипервизоры. Однако набор включённых компонентов Windows и фактический режим работы гипервизора нужно проверить отдельно.

Для повторяемого теста фиксируют:

• число виртуальных процессоров и объём RAM, выделенные гостевой системе;
• формат и расположение виртуального диска: VHDX или VMDK, системный накопитель или отдельный;
• наличие снимков состояния и фоновых операций, например обновления Windows;
• включённые функции «Целостность памяти» и «Платформа виртуальной машины»;
• состояние гипервизора Windows при работе VirtualBox или VMware.

Менять несколько параметров одновременно нельзя. Если после отключения Memory Integrity и смены формата диска тест ускорился, вклад каждого изменения останется неизвестен. Корректная схема проста: базовый прогон, изменение одного параметра, повторный прогон. Затем сравнивают результаты и возвращают прежнюю настройку, если она нужна для следующего измерения.

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

VBS и защитные функции: измерять вместе с безопасностью

VBS использует аппаратную виртуализацию для изоляции отдельных функций безопасности. В Windows 11 с этим связаны, в частности, «Целостность памяти» и «Платформа виртуальной машины» (VMP). Их включение может снижать производительность при высокой нагрузке. Масштаб эффекта зависит от оборудования, задач и конфигурации; универсального процента потери, пригодного для любого ПК, нет.

Для оценки сначала проводят тест в обычном рабочем состоянии Windows. Это главный результат для практического решения: он показывает, как виртуальная среда ведёт себя при реально включённой защите. Затем, если требуется понять вклад VBS, проводят отдельный контролируемый прогон с изменённой конфигурацией. Такой тест не является рекомендацией отключать защиту на постоянной основе. Он изолирует переменную.

Фиксировать нужно не только переключатели в интерфейсе, но и фактическое состояние компонентов после перезагрузки. Изменение настройки без перезагрузки или при работающем гипервизоре может не дать ожидаемой конфигурации. Перед каждым прогоном следует закрыть лишние ВМ, дождаться завершения фоновых задач и проверить загрузку хоста в Resource Monitor или Performance Monitor.

Сравнение двух режимов полезно только при одинаковой нагрузке. Например, запуск одного и того же CPU-теста в одной и той же гостевой ОС при неизменных объёме RAM и числе виртуальных процессоров. Если параллельно обновлялась система или выполнялось индексирование файлов, цифры уже нельзя напрямую связывать с VBS.

Конфликт гипервизоров и режим NEM

Hyper-V относится к гипервизорам первого типа: он интегрирован с уровнем виртуализации Windows. VirtualBox и VMware обычно рассматривают как гипервизоры второго типа, работающие поверх хостовой ОС. Эта классификация описывает архитектуру, но сама по себе не даёт ответа, какой продукт будет быстрее в конкретной задаче.

При активных службах виртуализации VirtualBox может перейти в режим совместимости NEM, использующий Hyper-V API. В таком режиме производительность гостевой ОС может заметно снизиться. Поэтому результат теста VirtualBox нельзя интерпретировать без проверки режима исполнения: нагрузка может отражать особенности совместимости, а не возможности самого компьютера или типичную скорость VirtualBox вне этой конфигурации.

Сравнение гипервизоров для домашнего ПК требует выровнять условия. Следует использовать одну гостевую ОС, одинаковое количество виртуальных процессоров, сопоставимый объём памяти, одинаковую нагрузку и сопоставимый тип дискового хранения. Если один продукт запускает ВМ через Hyper-V API, а другой работает в ином режиме, это нужно отметить в результатах. Иначе таблица скоростей будет сравнивать разные конфигурации.

Таблица не задаёт рейтинга. Для разработки, тестирования приложений или запуска старой ОС могут быть важнее совместимость устройств, снимки состояния и сетевые настройки, чем синтетический результат CPU-бенчмарка. Выбор гипервизора для Windows 11 должен опираться на рабочую нагрузку и требования к защите, а не на одно число из теста.

Набор инструментов: синтетика и мониторинг Windows

Синтетический бенчмарк отвечает на ограниченный вопрос. Cinebench позволяет оценить вычислительную нагрузку процессора. CrystalDiskMark подходит для измерения дисковых операций на виртуальном диске VHDX или VMDK. PassMark PerformanceTest даёт дополнительные сценарии оценки аппаратной производительности. Ни один из этих инструментов не заменяет мониторинг хоста: бенчмарк показывает итог, а системные счётчики помогают понять, куда ушли ресурсы.

Для наблюдения за Windows используются Performance Monitor (Perfmon) и Resource Monitor. В Perfmon можно собирать счётчики во время теста и сопоставлять временные интервалы с запуском конкретной нагрузки. Resource Monitor помогает увидеть текущую активность процессора, памяти, диска и сети. Важно фиксировать значения на хосте и, где это доступно, внутри гостевой ОС: нагрузка, незаметная в одном слое, может быть очевидной в другом.

Практический цикл измерения выглядит так:

1. Перезагрузить хост, дождаться завершения фоновой активности и зафиксировать исходную загрузку.

2. Запустить ВМ с заданными параметрами и записать потребление CPU, RAM, диска и сети в состоянии простоя.

3. Выполнить один бенчмарк или одну прикладную задачу, сохраняя данные Perfmon и Resource Monitor.

4. Дождаться возврата к исходному состоянию и повторить тот же прогон без изменения конфигурации.

5. Провести отдельный тест после изменения одного параметра, например числа виртуальных процессоров.

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

CPU, память и распределение ядер

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

На процессорах Intel с P- и E-ядрами важна фактическая политика планирования. Назначение виртуальных процессоров не всегда означает простое закрепление за конкретными физическими ядрами. Поведение зависит от гипервизора и планировщика Windows. Для воспроизводимого теста нужно сохранять одну и ту же конфигурацию и не сравнивать результат, полученный при разном числе ВМ или приложений на хосте.

С памятью действует похожее ограничение. Выделенный гостю объём сокращает доступный хосту резерв. При высокой загрузке памяти Windows может активнее обращаться к файлу подкачки, а дисковая активность начнёт влиять на впечатление от скорости ВМ. Поэтому недостаточно записать только объём RAM, назначенный гостевой ОС: нужно наблюдать и за оставшимся ресурсом хоста.

Для оптимизации ресурсов виртуальной среды сначала следует менять параметры, непосредственно связанные с узким местом. Если процессор насыщен, тестируют число виртуальных CPU и параллельность нагрузки. Если растёт дисковая очередь, исследуют виртуальный диск и накопитель. Если хосту не хватает памяти, добавление виртуальных процессоров ситуацию не исправит. Любая оптимизация требует контрольного прогона после изменения.

IOPS, BPS и PPS: что именно измеряется

Три сетевые и дисковые метрики описывают разные стороны работы ВМ:

• IOPS показывает число операций ввода-вывода в секунду. Для виртуального диска это полезный показатель при частых небольших запросах, например при загрузке системы или работе с множеством файлов.
• BPS показывает объём переданных данных в секунду. Метрика помогает оценивать пропускную способность диска или сети, но сама по себе не описывает задержку операций.
• PPS показывает число сетевых пакетов в секунду. При одинаковом объёме трафика различный размер пакетов может давать разный PPS.

Высокая пропускная способность не гарантирует низкую задержку. В сценарии с множеством мелких запросов важны IOPS и стабильность отклика; при передаче крупных файлов информативнее BPS. Для сетевых задач PPS позволяет заметить нагрузку, которую среднее значение байтов в секунду может скрывать.

CrystalDiskMark можно использовать для сопоставления дисковой производительности виртуальных накопителей, но результат зависит от расположения файла ВМ, типа накопителя, режима кэширования и фоновой активности. Чтобы сравнить VHDX и VMDK, нужно сохранить одинаковые условия и указать, на каком физическом диске находятся файлы. Показатель, снятый на системном SSD при параллельном обновлении Windows, не является чистой оценкой формата виртуального диска.

График метрик полезнее итогового среднего числа. Короткие провалы, повторяющиеся задержки и пики нагрузки могут влиять на отзывчивость гостевой ОС, даже если усреднённый показатель выглядит приемлемо. Анализировать следует интервалы нагрузки и простоя, а не только максимальное значение.

Как читать результат без ложной точности

Итог тестирования должен описывать конфигурацию, задачу и ограничение вывода. Формулировка «VirtualBox медленнее Hyper-V» слишком широка, если проверялась одна версия гостевой ОС на одном ПК и только один бенчмарк. Технически корректнее указывать режим запуска, активные функции VBS, параметры виртуальной машины и характер нагрузки.

Для рабочего отчёта достаточно свести рядом состояние хоста, назначенные ресурсы, результат бенчмарка и наблюдения Perfmon. Если нагрузка упирается в CPU, это должно подтверждаться счётчиками и повторным прогоном. Если тест показывает падение дисковой скорости, следует проверить физический накопитель и фоновую активность. Название гипервизора само по себе причину не устанавливает.

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

Производительность виртуальной машины в Windows 11 измеряется не одним баллом. Нужны повторяемая нагрузка, логи хоста, состояние гипервизора и раздельная оценка CPU, памяти, диска и сети. Если режим NEM, VBS или фоновые операции не зафиксированы, тест описывает неизвестную комбинацию факторов. Для технического решения такой результат непригоден.