О выборе типа планировщика гипервизора Hyper-V

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server версии 1709, Windows Server версии 1803

В этом документе описываются важные изменения по умолчанию Hyper-V и рекомендуется использовать типы планировщика гипервизора. Эти изменения влияют на производительность системы безопасности и виртуализации. Администраторы узлов виртуализации должны просматривать и понимать изменения и последствия, описанные в этом документе, и тщательно оценивать последствия, рекомендуемое руководство по развертыванию и факторы риска, связанные с наилучшим образом понять, как развертывать узлы Hyper-V и управлять ими в условиях быстро меняющегося ландшафта безопасности.

Важно!

В настоящее время известные уязвимости безопасности на стороне канала, обнаруженные в нескольких архитектурах процессора, могут быть использованы вредоносной гостевой виртуальной машиной с помощью поведения планирования устаревшего типа классического планировщика гипервизора при запуске на узлах с включенным одновременным многопотоком (SMT). При успешном использовании вредоносные рабочие нагрузки могут наблюдать за данными за пределами его границы секции. Этот класс атак можно устранить, настроив гипервизор Hyper-V для использования типа планировщика гипервизора и перенастройки гостевых виртуальных машин. При использовании основного планировщика гипервизор ограничивает виртуальные машины гостевой виртуальной машины выполняться на одном физическом ядре процессора, поэтому строго изолируя возможность виртуальной машины получать доступ к данным к границам физического ядра, на котором она выполняется. Это высокоэффективная защита от этих атак на стороне канала, которая предотвращает наблюдение виртуальных машин с любыми артефактами из других секций, будь то корневая или другая гостевая секция. Поэтому корпорация Майкрософт изменяет параметры конфигурации по умолчанию и рекомендуется для узлов виртуализации и гостевых виртуальных машин.

Общие сведения

Начиная с Windows Server 2016 Hyper-V поддерживает несколько методов планирования виртуальных процессоров и управления ими, называемых типами планировщика гипервизора. Подробное описание всех типов планировщика гипервизора можно найти в разделе "Основные сведения" и использовании типов планировщика гипервизора Hyper-V.

Примечание.

Новые типы планировщика гипервизора впервые появились в Windows Server 2016 и недоступны в предыдущих выпусках. Все версии Hyper-V до Windows Server 2016 поддерживают только классический планировщик. Поддержка основного планировщика была опубликована только недавно.

Сведения о типах планировщика гипервизора

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

Классический планировщик

Классический планировщик относится к справедливому ресурсу, методу циклического перебора работы с виртуальными процессорами (VPs) в системе, включая корневые виртуальные машины, а также виртуальные машины, принадлежащие гостевым виртуальным машинам. Классический планировщик был типом планировщика по умолчанию, используемым во всех версиях Hyper-V (до Windows Server 2019, как описано здесь). Характеристики производительности классического планировщика хорошо понятны, и классический планировщик демонстрируется для поддержки чрезмерной подписки рабочих нагрузок , т. е. чрезмерной подписки коэффициента VP:LP узла по разумному маржу (в зависимости от типов виртуализированных рабочих нагрузок, общего использования ресурсов и т. д.).

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

Основной планировщик

Основной планировщик использует свойства SMT для обеспечения изоляции гостевых рабочих нагрузок, которые влияют как на безопасность, так и на производительность системы. Основной планировщик гарантирует, что виртуальные машины из виртуальной машины запланированы на одноуровневые потоки SMT. Это делается симметрично, чтобы если LPs находятся в группах двух, виртуальные машины запланированы в группах из двух, а ядро ЦП системы никогда не совместно используется между виртуальными машинами.

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

Обратите внимание, что если VP запланирован на виртуальную машину без поддержки SMT, этот VP будет использовать весь ядро при запуске, а поток SMT ядра ядра останется бездействия. Это необходимо для обеспечения правильной изоляции рабочей нагрузки, но влияет на общую производительность системы, особенно при превышении подписки на системные LPS- то есть, когда общее соотношение VP:LP превышает 1:1. Поэтому запуск гостевых виртуальных машин, настроенных без нескольких потоков на ядро, является подоптимальным конфигурацией.

Преимущества использования основного планировщика

Основной планировщик предлагает следующие преимущества:

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

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

• Использование SMT на гостевых виртуальных машинах— ОС и приложения, работающие на гостевой виртуальной машине, могут использовать интерфейсы SMT и интерфейсы программирования для управления и распределения работы между потоками SMT, так же, как и при запуске, не виртуализированном.

Основной планировщик в настоящее время используется на узлах виртуализации Azure, в частности для использования строгой границы безопасности и низкой нагрузки variabilty. Корпорация Майкрософт считает, что основной тип планировщика должен быть и будет по-прежнему типом планирования гипервизора по умолчанию для большинства сценариев виртуализации. Таким образом, чтобы обеспечить безопасность наших клиентов по умолчанию, корпорация Майкрософт вносит это изменение для Windows Server 2019 сейчас.

Производительность основного планировщика влияет на гостевые рабочие нагрузки

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

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

Изменения по умолчанию и рекомендуемых конфигураций для Windows Server 2016 и Windows Server 2019

Для развертывания узлов Hyper-V с максимальным состоянием безопасности требуется использование типа планировщика ядра гипервизора. Чтобы обеспечить безопасность наших клиентов по умолчанию, корпорация Майкрософт изменяет следующие параметры по умолчанию и рекомендуется.

Примечание.

Хотя внутренняя поддержка гипервизора для типов планировщика была включена в начальный выпуск Windows Server 2016, Windows Server 1709 и Windows Server 1803, обновления необходимы для доступа к элементу управления конфигурацией, позволяющему выбрать тип планировщика гипервизора. Дополнительные сведения об этих обновлениях см. в статье "Основные сведения о типах планировщика гипервизора Hyper-V".

Изменения узла виртуализации

• Гипервизор будет использовать основной планировщик по умолчанию, начиная с Windows Server 2019.

• Корпорация Майкрософт настраивает основной планировщик в Windows Server 2016. Тип планировщика ядра гипервизора поддерживается в Windows Server 2016, однако по умолчанию используется классический планировщик. Основной планировщик является необязательным и должен быть явно включен администратором узла Hyper-V.

Изменения конфигурации виртуальной машины

• В Windows Server 2019 новые виртуальные машины, созданные с помощью виртуальной машины по умолчанию версии 9.0, автоматически наследуют свойства SMT (включено или отключено) узла виртуализации. То есть, если SMT включен на физическом узле, только что созданные виртуальные машины также будут включены SMT и будут наследовать топологию SMT узла по умолчанию, при этом виртуальная машина имеет то же количество аппаратных потоков на ядро, что и базовая система. Это будет отражено в конфигурации виртуальной машины с HwThreadCountPerCore = 0, где 0 указывает, что виртуальная машина должна наследовать параметры SMT узла.

• Существующие виртуальные машины с виртуальной машиной версии 8.2 или более ранних версий сохраняют исходный параметр процессора виртуальных машин для HwThreadCountPerCore, а для гостей версии 8.2 — HwThreadCountPerCore = 1. Когда эти гости работают на узле Windows Server 2019, они будут рассматриваться следующим образом:

  1. Если виртуальная машина имеет число виртуальных машин, которое меньше или равно количеству ядер LP, виртуальная машина будет рассматриваться как виртуальная машина, не являющаяся SMT, основным планировщиком. Когда гостевая виртуальная машина выполняется в одном потоке SMT, поток SMT ядра будет бездействующий. Это является неоптимальным и приведет к общей потере производительности.

  2. Если виртуальная машина имеет больше виртуальных машин, чем ядра LP, виртуальная машина будет рассматриваться как виртуальная машина SMT основным планировщиком. Однако виртуальная машина не будет наблюдать другие признаки того, что это виртуальная машина SMT. Например, использование инструкции CPUID или API Windows для запроса топологии ЦП операционной системой или приложениями не будет указывать, что SMT включен.

• Если существующая виртуальная машина явно обновляется с версий виртуальной машины ухайлер до версии 9.0 с помощью операции Update-VM, виртуальная машина сохранит текущее значение HwThreadCountPerCore. У виртуальной машины нет принудительной поддержки SMT.

• В Windows Server 2016 корпорация Майкрософт рекомендует включить SMT для гостевых виртуальных машин. По умолчанию виртуальные машины, созданные в Windows Server 2016, отключены SMT, то есть HwThreadCountPerCore имеет значение 1, если явно не изменено.

Примечание.

Windows Server 2016 не поддерживает параметр HwThreadCountPerCore значение 0.

Управление конфигурацией SMT виртуальной машины

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

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

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

Конфигурация SMT для виртуальной машины отображается на панелях сводки в консоли диспетчера Hyper-V. Настройка параметров SMT виртуальной машины может выполняться с помощью Параметры виртуальной машины или PowerShell.

Настройка параметров SMT виртуальной машины с помощью PowerShell

Чтобы настроить параметры SMT для гостевой виртуальной машины, откройте окно PowerShell с достаточными разрешениями и введите:

Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <0, 1, 2>

Где:

• 0 = Наследовать топологию SMT от узла (этот параметр HwThreadCountPerCore=0 не поддерживается в Windows Server 2016)

• 1 = non-SMT

• Значения > 1 = требуемое количество потоков SMT на ядро. Может не превышать количество физических потоков SMT на ядро.

Чтобы прочитать параметры SMT для гостевой виртуальной машины, откройте окно PowerShell с достаточными разрешениями и введите:

(Get-VMProcessor -VMName <VMName>).HwThreadCountPerCore

Обратите внимание, что гостевые виртуальные машины, настроенные с помощью HwThreadCountPerCore = 0, указывают на то, что SMT будет включен для гостя и будет предоставлять одинаковое количество потоков SMT для гостя, как правило, на базовом узле виртуализации( обычно 2).

Гостевые виртуальные машины могут наблюдать изменения топологии ЦП в сценариях мобильности виртуальных машин

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

Оповещения о неоптимальным конфигурациях виртуальных машин

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

Определение неоптимальными настроенными виртуальными машинами

Вы можете определить виртуальные машины, отличные от SMT, проверив системный журнал в Просмотр событий для события рабочего процесса Hyper-V 3498, который будет запускаться для виртуальной машины всякий раз, когда число виртуальных машин в виртуальной машине больше, чем число физических ядер. События рабочего процесса можно получить из Просмотр событий или с помощью PowerShell.

Запрос события виртуальной машины рабочего процесса Hyper-V с помощью PowerShell

Чтобы запросить событие рабочего процесса Hyper-V 3498 с помощью PowerShell, введите следующие команды из командной строки PowerShell.

Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-Worker"; ID=3498}

Влияние конфигурации SMT для гостевых SMT на использование просвещений гипервизора для гостевых операционных систем

Гипервизор Майкрософт предлагает несколько подсказок или подсказок, которые ОПЕРАЦИОННая система, запущенная на гостевой виртуальной машине, может запрашивать и использовать для активации оптимизаций, таких как те, которые могут повысить производительность или улучшить обработку различных условий при выполнении виртуализированной. Недавно появилось просвещение касается обработки планирования виртуальных процессоров и использования мер по устранению рисков ОС для атак на стороне канала, которые используют SMT.

Примечание.

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

Подробные сведения об этом гостевом просвещении приведены ниже, однако основной вывод для администраторов узла виртуализации заключается в том, что виртуальные машины должны иметь HwThreadCountPerCore, настроенные для сопоставления физической конфигурации SMT узла. Это позволяет гипервизору сообщать о отсутствии общего доступа к не архитектуре. Таким образом, любая гостевая ОС, поддерживающая оптимизацию, требующую просвещения, может быть включена. В Windows Server 2019 создайте новые виртуальные машины и оставьте значение по умолчанию HwThreadCountPerCore (0). Старые виртуальные машины, перенесенные с узлов Windows Server 2016, можно обновить до версии конфигурации Windows Server 2019. После этого корпорация Майкрософт рекомендует задать HwThreadCountPerCore = 0. В Windows Server 2016 корпорация Майкрософт рекомендует задать HwThreadCountPerCore для сопоставления конфигурации узла (обычно 2).

Сведения о просвещении NoNonArchitecturalCoreSharing

Начиная с Windows Server 2016, гипервизор определяет новую просвещению, чтобы описать ее обработку планирования и размещения VP в гостевой ОС. Это просвещение определяется в функциональной спецификации верхнего уровня гипервизора версии 5.0c.

Гипервизор искусственный ЦПД конечного ЦПД.0x40000004.EAX:18[NoNonArchitecturalCoreSharing = 1] указывает, что виртуальный процессор никогда не будет совместно использовать физическое ядро с другим виртуальным процессором, за исключением виртуальных процессоров, которые передаются как одноуровневые потоки SMT. Например, гостевая виртуальная машина никогда не будет работать в потоке SMT вместе с корневым виртуальным сервером, работающим одновременно на одноуровневом потоке SMT на одном процессоре. Это условие возможно только при выполнении виртуализированной среды и поэтому представляет неисхоженное поведение SMT, которое также имеет серьезные последствия для безопасности. Гостевая ОС может использовать NoNonArchitecturalCoreSharing = 1 в качестве указания на то, что она безопасна для включения оптимизации, что может помочь избежать затрат на производительность настройки STIBP.

В определенных конфигурациях гипервизор не будет указывать, что NoNonArchitecturalCoreSharing = 1. Например, если узел включен sMT и настроен на использование классического планировщика гипервизора, NoNonArchitecturalCoreSharing будет иметь значение 0. Это может предотвратить включение определенных оптимизаций для просвещенных гостей. Поэтому корпорация Майкрософт рекомендует администраторам узлов, использующим SMT, полагаться на планировщик ядра гипервизора и убедиться, что виртуальные машины настроены для наследования конфигурации SMT от узла, чтобы обеспечить оптимальную производительность рабочей нагрузки.

Итоги

Ландшафт угроз безопасности продолжает развиваться. Чтобы обеспечить безопасность наших клиентов по умолчанию, корпорация Майкрософт изменяет конфигурацию по умолчанию для гипервизора и виртуальных машин, начиная с Windows Server 2019 Hyper-V, и предоставляет обновленные рекомендации и рекомендации для клиентов под управлением Windows Server 2016 Hyper-V. Администраторы узла виртуализации должны:

• Чтение и понимание рекомендаций, приведенных в этом документе

• Тщательно оцените и настройте развертывания виртуализации, чтобы обеспечить соответствие требованиям безопасности, производительности, плотности виртуализации и реагирования на рабочую нагрузку.

• Рассмотрите возможность повторной настройки существующих узлов Hyper-V Windows Server 2016 для использования надежных преимуществ безопасности, предлагаемых планировщиком ядра гипервизора

• Обновите существующие виртуальные машины, отличные от SMT, чтобы снизить влияние на производительность из ограничений планирования, введенных изоляцией VP, которая устраняет уязвимости безопасности оборудования