Гипервизор hyper v не настроен на включение элементов управления ресурсами процессоров
В этой статье описываются ресурсы и элементы управления изоляцией Hyper-V для виртуальных машин. Эти возможности, которые мы будем называть группами ЦП виртуальных машин или просто "группами ЦП", были введены в Windows Server 2016. Группы ЦП позволяют администраторам Hyper-V лучше управлять ресурсами ЦП узла и распределять их между гостевыми виртуальными машинами. С помощью групп ЦП администраторы Hyper-V могут:
Создавайте группы виртуальных машин, каждая из которых имеет различные выделения ресурсов ЦП узла виртуализации, общие для всей группы. Это позволяет администратору узла реализовать классы служб для различных типов виртуальных машин.
Установите ограничения ресурсов ЦП для конкретных групп. Это «групповая политика» задает верхнюю границу для ресурсов ЦП узла, которую может использовать вся группа, фактически обеспечивая требуемый класс службы для этой группы.
Ограничьте запуск группы ЦП только в определенном наборе процессоров основной системы. Это можно использовать для изоляции виртуальных машин, принадлежащих разным группам ЦП, друг от друга.
Примеры классов служб
Рассмотрим несколько простых примеров. Чтобы начать с, предположим, что администратор узла Hyper-V хочет поддерживать два уровня обслуживания для гостевых виртуальных машин:
Низкий уровень "C". Мы предоставляем этот уровень 10% от ресурсов для всего узла.
Уровень "B" среднего диапазона. Этот уровень выделяется 50% от ресурсов для всего узла.
На этом этапе мы будем утверждать, что никакие другие элементы управления ресурсами ЦП не используются, например отдельные ограничения виртуальной машины, веса и резервы. Однако отдельные ограничения виртуальной машины важны, так как мы увидим чуть позже.
Для простоты предположим, что каждая виртуальная машина имеет один вице — 1, а наш узел имеет 8 LPs. Начнем с пустого узла.
Чтобы создать уровень "B", узел админстартор устанавливает ограничение для группы на 50%:
- G = n * C
- G = 8 * 50%
- G = 4 время ЦП для всей группы
Администратор узла добавляет одну виртуальную машину "B" уровня. На этом этапе Наша виртуальная машина уровня "B" может использовать не более 50% ресурсов центрального процессора узла или эквивалент 4 LPs в нашем примере системы.
Теперь администратор добавляет вторую виртуальную машину "уровень B". Распределение группы ЦП — равномерно распределяется между всеми виртуальными машинами. В группе б имеется 2 виртуальных ВМ, поэтому каждая виртуальная машина теперь получает половину группы б всего 50%, 25% каждого или эквивалента 2 LPs времени вычислений.
Как работают группы ЦП
Распределение вычислительных ресурсов узлов между группами ЦП обеспечивается гипервизором Hyper-V с помощью вычисленного ограничения группы ЦП. Ограничение группы ЦП — это часть общей мощности ЦП для группы ЦП. Значение ограничения группы зависит от класса группы или назначенного уровня приоритета. Вычисленное ограничение группы можно рассматривать как "количество времени ЦП в LP". Этот бюджет группы является общим, поэтому если активна только одна виртуальная машина, она может использовать выделение ресурсов всей группы.
Ограничение группы ЦП вычисляется как G = n x C, где:
- G — это количество узлов LP, которое необходимо назначить группе
- n — общее число логических процессоров (LPS) в группе.
- В — это максимальное выделение ресурсов ЦП, то есть класс службы, который требуется для группы, выраженный в процентах от общей вычислительной мощности системы.
Например, рассмотрим группу ЦП, настроенную с 4 логическими процессорами (LPs), и ограничение 50%.
- G = n * C
- G = 4 * 50%
- G = 2 время ЦП для всей группы в LP
В этом примере для группы ЦП «G» выделяется 2-е время ЦП.
Обратите внимание, что ограничение группы применяется независимо от числа виртуальных машин или виртуальных процессоров, привязанных к группе, и вне зависимости от состояния (например, завершения работы или запуска) виртуальных машин, назначенных группе ЦП. Таким образом, каждая виртуальная машина, привязанная к одной и той же группе ЦП, будет принимать долю общего количества ресурсов ЦП группы, и это изменится на число виртуальных машин, привязанных к группе ЦП. Таким образом, так как виртуальные машины привязаны к виртуальным машинам или не привязаны к ним из группы ЦП, необходимо перенастроить общее ограничение группы ЦП и настроить его для поддержки требуемого ограничения на виртуальную машину. Администратор узла виртуальной машины или программный уровень управления виртуализацией отвечает за управление групповыми политиками по мере необходимости для достижения требуемого распределения ресурсов ЦП для каждой виртуальной машины.
История
Перед обсуждением логики и элементов управления, лежащих в основе планирования виртуальных процессоров Hyper-V, рекомендуется ознакомиться с основными понятиями, описанными в этой статье.
Пример 9. Печать всех виртуальных машин, сгруппированных по идентификатору группы ЦП
Минимальная корневая конфигурация или "Minroot"
В ранних версиях Hyper-V было максимальное ограничение архитектуры в 64 виртуальных машинах на секцию. Это применяется как к корневым, так и гостевым секциям. Так как системы с более чем 64 логическими процессорами появились на высокоуровневых серверах, Hyper-V также изменил свои ограничения масштабирования узлов для поддержки этих крупных систем, в одной точке поддерживая узел с до 320 LPs. Тем не менее, нарушение ограничения 64 VP на секцию в то время представляло несколько проблем и ввело сложности, которые позволили поддерживать более 64 виртуальных машин на секцию запрещено. Чтобы устранить эту проблему, Hyper-V ограничивает количество виртуальных машин, предоставленных корневому разделу, до 64, даже если базовый компьютер имеет гораздо больше доступных логических процессоров. Гипервизор будет продолжать использовать все доступные LPs для запуска гостевых виртуальных машин, но искусственно ограничивает корневую секцию на 64. Эта конфигурация стала известной как "минимальная корневая" или "minroot". Тестирование производительности подтвердило, что даже в крупномасштабных системах с более чем 64 LPs корень не нуждался в более чем 64 корневых виртуальных машинах, чтобы обеспечить достаточную поддержку большого количества гостевых виртуальных машин и гостевых виртуальных машин. На самом деле гораздо меньше 64 корневых виртуальных машин часто было достаточно, в зависимости от количества и размера гостевых виртуальных машин. выполнение определенных рабочих нагрузок и т. д.
Эта "минроот" концепция продолжает использоваться сегодня. На самом деле, даже если Windows Server 2016 Hyper-V увеличил максимальный предел поддержки архитектуры для LPs узла до 512 LPs, корневая секция по-прежнему будет ограничена максимум 320 LPs.
Выбор типа планировщика гипервизора на сервере Windows
Конфигурация планировщика гипервизора управляется с помощью записи BCD hypervisorschedulertype.
Чтобы выбрать тип планировщика, откройте командную строку с правами администратора:
Где type находится одно из следующих типов:
- Классический
- Основные сведения
- Root
Чтобы изменения в типе планировщика гипервизора вступили в силу, система должна быть перезагружена.
В настоящее время корневой планировщик низкоуровневой оболочки не поддерживается на сервере Hyper-V Windows. Администраторы Hyper-V не должны пытаться настроить корневой планировщик для использования с сценариями виртуализации серверов.
Классический планировщик
Классический планировщик был по умолчанию для всех версий гипервизора Windows Hyper-V с момента его создания, включая Windows Server 2016 Hyper-V. Классический планировщик обеспечивает справедливую долю, упреждающую модель планирования циклического перебора для гостевых виртуальных процессоров.
Классический тип планировщика наиболее подходит для большинства традиционных вариантов использования Hyper-V — для частных облаков, поставщиков услуг размещения и т. д. Характеристики производительности хорошо понятны и лучше всего оптимизированы для поддержки широкого спектра сценариев виртуализации, таких как превышение подписки виртуальных машин на LPs, одновременное выполнение нескольких разнородных виртуальных машин и рабочих нагрузок, выполнение крупномасштабных высокопроизводительных виртуальных машин, поддержка полнофункционированного набора функций Hyper-V без ограничений и многое другое.
Пример 10. Печать всех виртуальных машин для одной группы ЦП
Корневой планировщик
Корневой планировщик появился в Windows 10 версии 1803. Если включен тип корневого планировщика, низкоуровневая оболочка управляет планированием работы в корневой секции. Планировщик NT в экземпляре ОС корневого раздела управляет всеми аспектами планирования работы в системных LPS.
Корневой планировщик отвечает уникальным требованиям, присущим поддержке раздела служебной программы для обеспечения надежной изоляции рабочей нагрузки, как и в случае с Application Guard в Защитнике Windows (WDAG). В этом сценарии, оставляя обязанности по планированию корневой ОС, предоставляет несколько преимуществ. Например, элементы управления ресурсами ЦП, применимые к сценариям контейнеров, могут использоваться с разделом служебной программы, что упрощает управление и развертывание. Кроме того, корневой планировщик ОС может легко собирать метрики об использовании ЦП рабочей нагрузки в контейнере и использовать эти данные в качестве входных данных в ту же политику планирования, применимую ко всем остальным рабочим нагрузкам в системе. Эти же метрики также помогают четко выполнять работу атрибутов в контейнере приложения в хост-системе. Отслеживание этих метрик сложнее с помощью традиционных рабочих нагрузок виртуальных машин, где некоторые работают от имени всех работающих виртуальных машин в корневой секции.
Использование корневого планировщика в клиентских системах
Начиная с Windows 10 версии 1803 корневой планировщик используется по умолчанию только в клиентских системах, где гипервизор может быть включен в поддержку изоляции рабочих нагрузок на основе виртуализации и WDAG, а также для правильной работы будущих систем с разнородными ядрами архитектур. Это единственная поддерживаемая конфигурация планировщика гипервизора для клиентских систем. Администраторы не должны пытаться переопределить тип планировщика гипервизора по умолчанию в клиентских системах Windows 10.
Элементы управления ресурсами ЦП виртуальной машины и корневой планировщик
Элементы управления ресурсами процессора виртуальных машин, предоставляемые Hyper-V, не поддерживаются, если корневой планировщик гипервизора включен, так как логика планировщика корневой операционной системы управляет ресурсами узла на глобальном уровне и не имеет сведений о конкретных параметрах конфигурации виртуальной машины. Элементы управления ресурсами процессора Hyper-V для каждой виртуальной машины, такие как ограничения, весовые коэффициенты и резервы, применяются только в тех случаях, когда гипервизор напрямую управляет планированием VP, например с классическими и основными типами планировщиков.
Использование корневого планировщика в серверных системах
В настоящее время корневой планировщик не рекомендуется использовать с Hyper-V на серверах, так как его характеристики производительности еще не полностью охарактеризованы и настроены для размещения широкого спектра рабочих нагрузок, типичных для многих развертываний виртуализации серверов.
Определение текущего типа планировщика
Текущий тип планировщика гипервизора можно определить, проверив системный журнал в Просмотр событий для последнего события запуска гипервизора с идентификатором 2, которое сообщает тип планировщика гипервизора, настроенный при запуске гипервизора. События запуска гипервизора можно получить из Windows Просмотр событий или с помощью PowerShell.
Событие запуска гипервизора с идентификатором 2 обозначает тип планировщика гипервизора, где:
1 = классический планировщик, SMT отключен
2 = классический планировщик
3 = основной планировщик
4 = корневой планировщик
Пример 2. Печать всех групп ЦП на узле
Здесь мы выведем список всех групп ЦП на текущем узле, их идентификатор группы, ограничение на использование ЦП группой и индиЦиес LPs, назначенных этой группе.
Обратите внимание, что допустимые значения закрепления ЦП находятся в диапазоне [0, 65536], и эти значения выражают ограничение группы в процентах (например, 32768 = 50%).
Включение SMT на гостевых виртуальных машинах
После настройки гипервизора узла виртуализации для использования основного типа планировщика гостевые виртуальные машины могут быть настроены для использования SMT при необходимости. Предоставление виртуальной машине гиперпотока виртуальных машин позволяет планировщику в гостевой операционной системе и рабочих нагрузках, работающих на виртуальной машине, обнаруживать и использовать топологию SMT в собственном расписании работы. В Windows Server 2016 гостевой SMT не настроен по умолчанию и должен быть явно включен администратором узла Hyper-V. Начиная с Windows Server 2019 новые виртуальные машины, созданные на узле, наследуют топологию SMT узла по умолчанию. То есть виртуальная машина версии 9.0, созданная на узле с 2 потоками SMT на ядро, также будет видеть 2 потока SMT на ядро.
PowerShell необходимо использовать для включения SMT на гостевой виртуальной машине; В диспетчере Hyper-V отсутствует пользовательский интерфейс. Чтобы включить SMT на гостевой виртуальной машине, откройте окно PowerShell с достаточными разрешениями и введите:
Где — это число потоков SMT на ядро, просматриваемых гостевой виртуальной машиной. Обратите внимание, что = 0 задает значение HwThreadCountPerCore в соответствии с числом потоков SMT узла на каждое значение ядра.
Параметр HwThreadCountPerCore = 0 поддерживается начиная с Windows Server 2019.
Ниже приведен пример Сведения о системе, взятых из гостевой операционной системы, работающей на виртуальной машине с 2 виртуальными процессорами и включенными SMT. Гостевая операционная система обнаруживает 2 логических процессора, принадлежащих одному ядру.
Пример 12. Отмена привязки единственной виртуальной машины к группе ЦП и удаление группы
В этом примере мы будем использовать несколько команд для проверки группы ЦП, удаления отдельной виртуальной машины, принадлежащей этой группе, и удаления группы.
Сначала выполним перечисление виртуальных машин в нашей группе.
Мы видим, что этой группе принадлежит только одна виртуальная машина с именем G1. Давайте удалим виртуальную машину G1 из нашей группы, установив для идентификатора группы виртуальной машины значение NULL.
After update to Windows 10 Build 1803, a warning symbol appears in the processor section:
Before the update, it was possible to configure this a reserve a percentage of the processor for the host. Now it seems impossible. Anyone knows how to configure Hyper-V to enable processor resource controls?
Отделение корневого ВПС от гостя ВПС
По умолчанию Hyper-V создаст привилегированный вице-президент на каждом базовом физическом процессоре LP. Эти корневые ВПС строго 1:1 сопоставляются с системой LPs системы и не переносятся, т. е. Каждый привилегированный вице-президент всегда будет выполняться на одном физическом LP. Гостевая ВПС может выполняться в любом доступном LP, а также предоставлять выполнение с правами root ВПС.
Тем не менее, может быть желательно полностью отделить действия привилегированных гостей от гостевых ВПС. Рассмотрим наш пример выше, где мы реализуем виртуальную машину уровня "A" Premium. Чтобы обеспечить ВПС виртуальной машины "A" с наименьшей возможной задержкой и "нарушением" или вариантом планирования, мы хотим запустить их на выделенном наборе LPs и убедиться, что корень не работает на этих LPs.
Это можно сделать с помощью комбинации конфигурации "минрут", которая ограничивает выполнение раздела ОС узла на подмножестве всех системных логических процессоров, а также с одной или несколькими группами ЦП привязаны.
Узел виртуализации можно настроить так, чтобы раздел узла был ограничен определенным LPs, при этом одна или несколько групп ЦП привязаны в остальные LPs. Таким образом, корневые и гостевые разделы могут работать на выделенных ресурсах ЦП и полностью изолированы без использования ЦП.
Дополнительные сведения о конфигурации "минрут" см. в разделе Управление ресурсами ЦП узла Hyper-V.
Основные сведения о SMT
Одновременная многопоточность или SMT — это метод, используемый в современных процессорах, который позволяет совместно использовать ресурсы процессора отдельными независимыми потоками выполнения. SMT обычно обеспечивает скромный рост производительности для большинства рабочих нагрузок за счет параллелизации вычислений, когда это возможно, увеличение пропускной способности инструкций, хотя при возникновении состязаний между потоками для общих ресурсов процессора производительность не может произойти и даже небольшое снижение производительности. Процессоры, поддерживающие SMT, доступны как от Intel, так и от AMD. Intel называет свои предложения SMT технологией Intel Hyper Threading Или Intel HT.
Для целей этой статьи описания SMT и его использования Hyper-V применяются одинаково как к системам Intel, так и к AMD.
Дополнительные сведения о технологии Intel HT см. в статье " Технология Intel Hyper-Threading"
Дополнительные сведения об архитектуре AMD SMT см. в разделе "Базовая архитектура Zen"
Настройка ограничений ЦП на отдельных виртуальных машинах
В дополнение к концу группы, каждая виртуальная машина может также иметь отдельную "заглушку" виртуальной машины. Элементы управления ресурсами ЦП для каждой виртуальной машины, включая ограничение использования ЦП, вес и резервирование, были частью Hyper-V с момента его введения. В сочетании с ограничением группы, ограничение виртуальной машины определяет максимальный объем ЦП, который может получить каждый вице-президент, даже если в группе есть доступные ресурсы ЦП.
Например, администратору узла может потребоваться разместить 10% Cap на виртуальных машинах C. Таким образом, даже если большинство "C" ВПС бездействующие, каждый вице — не более 10%. Без ограничения виртуальной машины "C" виртуальные машины могут рационально производительность по сравнению с уровнями, разрешенными их уровнями.
Пример 6. Печать идентификаторов групп ЦП для всех виртуальных машин на узле
Ответы
Как я понял, все описываемые настройки влияют на распределение ресурсов между разными ВМ. Но если работает только одна, то вне зависимости от настроек ВМ должна получить все железо? Этого пока не происходит.
А вот должно бы.
Да, если работает одна машина, она и получит все ресурсы хоста, которые ей требуются. Если Вам требуются все доступные ресурсы, то лучше уйти на физику, и отказаться от виртуализации вообще, поскольку она-то часть ресурсов у Вас заберет. (Рассмотрите этот вариант, и по крайней мере протестируйте.)
Попробуйте для начала отключить HT, возможно в вашей ситуации это даст прирост нагрузки.
Пример 8. Привязка виртуальной машины к существующей группе ЦП
Здесь мы добавим виртуальную машину в существующую группу ЦП. Обратите внимание, что виртуальная машина не должна быть привязана к существующей группе ЦП, или задание идентификатора группы ЦП завершится ошибкой.
Теперь убедитесь, что виртуальная машина G1 находится в нужной группе ЦП.
Управление группами ЦП
Управление группами ЦП осуществляется с помощью службы вычислений узлов Hyper-V или HCS. Подробное описание HCS, его женесис, ссылки на API HCS и многое другое можно найти в блоге группы виртуализации Майкрософт, посвященном публикации службы вычислений узла (HCS).
Для создания групп ЦП и управления ими можно использовать только HCS. интерфейсы управления WMI и PowerShell для диспетчера Hyper-V не поддерживают группы ЦП.
Корпорация Майкрософт предоставляет программу командной строки, cpugroups.exe, в центре загрузки Майкрософт , которая использует интерфейс HCS для управления группами ЦП. Эта служебная программа также может отображать топологию ЦП узла.
Необходимые обновления
Для использования функций планировщика гипервизора, описанных в этом документе, требуются следующие обновления. Эти обновления включают изменения для поддержки нового hypervisorschedulertype параметра BCD, который необходим для настройки узла.
Версия | Выпуск | Требуется обновление | Статья базы знаний |
---|---|---|---|
Windows Server 2016 | 1607 | 2018.07 C | KB4338822 |
Windows Server 2016 | 1703 | 2018.07 C | KB4338827 |
Windows Server 2016 | 1709 | 2018.07 C | KB4338817 |
Windows Server 2019 | 1804 | Нет | Нет |
Использование средства Кпуграупс
Рассмотрим несколько примеров использования средства Кпуграупс.
Параметры командной строки для средства Кпуграупс передаются с использованием только пробелов в качестве разделителей. Символы "/" и "-" не должны воздействовать на нужный параметр командной строки.
Включение и настройка Minroot
Конфигурация minroot управляется с помощью записей BCD гипервизора. Чтобы включить minroot, в командной строке с правами администратора выполните следующие действия:
Где n — число корневых виртуальных ip-адресов.
Система должна быть перезагружена, и новое число корневых процессоров будет сохраняться в течение всего времени существования загрузки ОС. Конфигурацию minroot нельзя изменить динамически во время выполнения.
При наличии нескольких узлов NUMA каждый узел получит n/NumaNodeCount процессоры.
Обратите внимание, что при использовании нескольких узлов NUMA необходимо убедиться, что топология виртуальной машины имеет достаточно свободных LPs (т. е. LPs без корневых виртуальных ip-адресов) на каждом узле NUMA, чтобы запустить виртуальные ip-адреса узла NUMA соответствующей виртуальной машины.
Обнаружение топологии ЦП
При запуске Кпуграупс с помощью Жеткпутопологи возвращаются сведения о текущей системе, как показано ниже, включая индекс LP, узел NUMA, к которому принадлежит LP, идентификатор пакета и ядра, а также индекс КОРНЕВого президента.
В следующем примере показана система с двумя сокетами ЦП и узлами NUMA, всего 32 LPs и включенной многопоточностью и настроенной для включения Минрут с 8 корневым ВПС, 4 из каждого узла NUMA. LPs с корневым ВПС имеет Рутвпиндекс > = 0; LPs с Рутвпиндекс из-1 недоступен для корневого раздела, но по-прежнему управляется гипервизором и запускает гостевой ВПС в соответствии с другими параметрами конфигурации.
Запрос события запуска типа планировщика гипервизора Hyper-V с помощью PowerShell
Чтобы запросить событие гипервизора с идентификатором 2 с помощью PowerShell, введите следующие команды из командной строки PowerShell.
Настройка типа планировщика гипервизора в Windows Server 2016 Hyper-V
Windows Server 2016 Hyper-V использует классическую модель планировщика гипервизора по умолчанию. Гипервизор можно дополнительно настроить для использования основного планировщика, повышения безопасности путем ограничения гостевых виртуальных ip-адресов для запуска на соответствующих физических парах SMT и поддержки использования виртуальных машин с планированием SMT для гостевых виртуальных машин.
Корпорация Майкрософт рекомендует всем клиентам, работающим Windows Server 2016 Hyper-V, выбрать основной планировщик, чтобы обеспечить оптимальную защиту узлов виртуализации от потенциально вредоносных гостевых виртуальных машин.
Основной планировщик
Планировщик ядер гипервизора — это новая альтернатива классической логике планировщика, представленная в Windows Server 2016 и Windows 10 версии 1607. Основной планировщик обеспечивает надежную границу безопасности для изоляции гостевой рабочей нагрузки и снижает дисперсию производительности для рабочих нагрузок внутри виртуальных машин, работающих на узле виртуализации с поддержкой SMT. Основной планировщик позволяет одновременно запускать виртуальные машины SMT и не SMT на одном узле виртуализации с поддержкой SMT.
Основной планировщик использует топологию SMT узла виртуализации и при необходимости предоставляет пары SMT гостевым виртуальным машинам и планирует группы гостевых виртуальных процессоров с одной виртуальной машины на группы логических процессоров SMT. Это делается симметрично, чтобы если LPs находятся в группах из двух, виртуальные ip-адреса запланированы в группах из двух, а ядро никогда не совместно используется между виртуальными машинами. Если VP планируется для виртуальной машины без включения SMT, она использует все ядро при его запуске.
Общий результат основного планировщика состоит в том, что:
Гостевые виртуальные машины ограничены запуском на базовых физических парах ядер, изолируя виртуальную машину до границ ядра процессора, что снижает уязвимость к атакам на стороне канала со стороны вредоносных виртуальных машин.
Вариативность пропускной способности значительно снижается.
Производительность может снизиться, так как если только одна из групп виртуальных машин может выполняться, выполняется только один из потоков инструкций в ядре, а другой остается бездействием.
ОС и приложения, работающие на гостевой виртуальной машине, могут использовать интерфейсы SMT и программные интерфейсы (API) для управления работой и распределения работы между потоками SMT так же, как и при запуске, не виртуализированном.
Надежная граница безопасности для изоляции гостевой рабочей нагрузки. Гостевые виртуальные машины ограничены выполнением на базовых физических парах ядер, что снижает уязвимость к атакам на стороне канала.
Основной планировщик используется по умолчанию, начиная с Windows Server 2019. В Windows Server 2016 основной планировщик является необязательным и должен быть явно включен администратором узла Hyper-V, а классический планировщик — по умолчанию.
Основное поведение планировщика с отключенным SMT узла
Если гипервизор настроен для использования основного типа планировщика, но возможность SMT отключена или отсутствует на узле виртуализации, гипервизор использует классическое поведение планировщика независимо от параметра типа планировщика гипервизора.
Windows Server 2019 Hyper-V по умолчанию использует основной планировщик
Чтобы обеспечить развертывание узлов Hyper-V в оптимальной конфигурации безопасности, Windows Server 2019 Hyper-V теперь использует базовую модель планировщика гипервизора по умолчанию. Администратор узла может дополнительно настроить узел для использования устаревшего классического планировщика. Перед переопределением параметров типа планировщика по умолчанию администраторы должны внимательно изучить и учитывать влияние на каждый тип планировщика на безопасность и производительность узлов виртуализации. Дополнительные сведения см. в разделе "О типе планировщика гипервизора Hyper-V ".
Answers
The Microsoft article, "Understanding and using Hyper-V hypervisor scheduler types", explains the loss of CPU resource control, in Windows 10, though it states this change wasn't implemented until version 1804.
Microsoft has removed CPU resource control in Windows 10, by changing to a new default scheduler type, and states the default scheduler type should not be changed.
From the section, "The Root Scheduler":
" The root scheduler was introduced with Windows 10 version 1804. When the root scheduler type is enabled, the hypervisor cedes control of work scheduling to the root partition. The NT scheduler in the root partition’s OS instance manages all aspects of scheduling work to system LPs.
The root scheduler addresses the unique requirements inherent with supporting a utility partition to provide strong workload isolation, as used with Windows Defender Application Guard (WDAG).
Starting with Windows 10 version 1804, the root scheduler is used by default on client systems only. This is the only supported hypervisor scheduler configuration for client systems.
The virtual machine processor resource controls provided by Hyper-V are not supported when the hypervisor root scheduler is enabled. "
The article states, which Hyper-V Host server scheduler is in use can be seen in the System Event Log, as Event ID 2, or by using this PowerShell command:
The number in the message will be:
0x1 = Classic scheduler SMT disabled
0x2 = Classic scheduler
0x3 = Core scheduler
0x4 = Root scheduler
On my Windows 10 computer, I found the Event message was, "Hypervisor scheduler type is 0x4". (The new 'Root scheduler'.)
To change the scheduler type used by Hyper-V Host, bcdedit must be used to change the "hypervisorschedulertype" variable used at boot, to either "core" or "classic"
bcdedit /set hypervisorschedulertype core or classic>
then reboot.
(WARNING: I haven't tested this, on Windows 10 version 1804 or newer, so, if you change this, it's at your own risk. )
Есть сервер (2 CPU по 8 ядер) , на нем установлен hyper-v2016 (10.0.14393.351)
На нем крутится ВМ с Server 2012, которой нужно дать на время максимум ресурсов. Но загрузка ЦП по Диспетчеру Hyper-V не превышает 74%, хотя сама виртуальная машина все время использует под 99%. У ВМ 32 виртуальных процессора, если дать ей больше, то она не запускается, если меньше - возьмет меньше 74%.
В чем тут дело и как быть? В настройках нашел только раздел "Управление ресурсами", но результата он не дал.
Использование Minroot для ограничения и изоляции вычислительных ресурсов узла
С высоким пороговым значением по умолчанию 320 LPs в Windows Server 2016 Hyper-V конфигурация minroot будет использоваться только в самых больших серверных системах. Однако эту возможность можно настроить на гораздо более низкое пороговое значение администратором узла Hyper-V и, следовательно, использовать для значительного ограничения объема ресурсов ЦП узла, доступных для корневой секции. Определенное количество корневых LPs, которые следует использовать, необходимо тщательно выбрать для поддержки максимальных требований виртуальных машин и рабочих нагрузок, выделенных узлу. Однако разумные значения для количества LPS узла можно определить с помощью тщательной оценки и мониторинга рабочих нагрузок и проверки в непроизводственных средах до широкого развертывания.
Пример 5. Установка ограничения для группы ЦП на 50%
Здесь мы установим ограничение для группы ЦП на 50%.
Теперь давайте подтверждаем настройку, отображая только что обновленную группу.
Пример 7. Отмена привязки виртуальной машины к группе ЦП
Чтобы удалить виртуальную машину из группы ЦП, присвойте параметру Кпуграупид виртуальной машины значение GUID. Это отменяет привязку виртуальной машины к группе ЦП.
Проверка конфигурации Minroot
Конфигурацию minroot узла можно проверить с помощью диспетчера задач, как показано ниже.
Если minroot активен, диспетчер задач отобразит количество логических процессоров, выделенных узлу, в дополнение к общему количеству логических процессоров в системе.
В этой статье описываются новые режимы логики планирования виртуальных процессоров, впервые появившиеся в Windows Server 2016. Эти режимы или типы планировщика определяют, как гипервизор Hyper-V выделяет и управляет работой между гостевыми виртуальными процессорами. Администратор узла Hyper-V может выбрать типы планировщиков гипервизора, которые лучше всего подходят для гостевых виртуальных машин и настроить виртуальные машины для использования логики планирования.
Обновления необходимы для использования функций планировщика гипервизора, описанных в этом документе. Дополнительные сведения см. в разделе "Обязательные обновления".
Изоляция групп виртуальных машин для конкретных процессоров узла
Администраторам узлов Hyper-V также может потребоваться возможность выделения ресурсов вычислений виртуальной машине. Например, предположим, что администратор хочет предложить привилегированную виртуальную машину "A" с ограничением класса 100%. Эти виртуальные машины уровня "Премиум" также нуждаются в минимальных задержках и невозможности планирования. Это значит, что они не могут быть отпланированы другой виртуальной машиной. Чтобы добиться этого разделения, можно настроить для группы ЦП определенное сопоставление сопоставления LP.
Например, чтобы разместить виртуальную машину "A" на узле в нашем примере, администратор создаст новую группу ЦП и настроит соответствие процессора группы подмножеству LPs узла. Группы B и C будут привязаныы к оставшимся LPs. Администратор может создать одну виртуальную машину в группе A, которая будет иметь эксклюзивный доступ ко всем LPs в группе A, а предположительно более низкие группы B и C будут совместно использовать оставшиеся LPs.
Пример 4. Создание новой группы ЦП
Здесь мы создадим новую группу ЦП, указав идентификатор группы и набор LPs для назначения группе.
Теперь отобразите добавленную группу.
Все ответы
От того, что Вы нарисуете машине 10,20,30, vCPU, быстрее ее процессор работать не будет. Дайте машине 8 роцессоров расслабьтесь, внимательно прочитав необходимый теоретический минимум.
Дмитрий, теоретический минимум - это, конечно, интересно (а в виде ссылки на статью за авторством LCD - это мне даже забавно), но объясните, пожалуйста, своими словами - какого чёрта?
То есть, какого чёрта VM у автора вопроса ведёт себя так, будто в ней прописан предел использования виртуального процессора в 75%, хотя автор вопроса явно такую настройку не делал (если делал - знал бы и не задавал бы глупых вопросов)? Что это? Новое умолчание (раньше всегда ограничений по умолчанию не было)? Или это - влияние NUMA (тогда почему 75, а не 50: у автора вопроса - два камня в сервере)? И если это NUMA - где это у MS документировано?
Я не могу никак комментировать что у автора топика за нагрузка внутри ВМ, но с удовольствием его послушаю и помогу, статью я привел поскольку как мне кажется есть недопонимание работы гипервизора. Именно поэтому это не whitepaper, а статья за авторством зеленого LCD,Покольку ТС мечется между диспетчером задач и менеджером ресурсов, не зная, что предпринять, чтобы машина полетела быстрее.
PS. Пока про NUMA коммениировать тоже не смогу, поскольку не знаю, умеет ли приложение внутри ВМ в NUMA, или нет. Давайте зададим этот вопрос опять же, пока не мне, а ТС. Является ли Ваше приложение NUMA-Aware?
Cпасибо большое за ответы!
Статью Александра Косивченко прочитал, форум тоже. Hyper threading на сервере включен, NUMA в своей программе (которой нужно дать поработать на всех доступных ресурсах) мы не используем.
Как я понял, все описываемые настройки влияют на распределение ресурсов между разными ВМ. Но если работает только одна, то вне зависимости от настроек ВМ должна получить все железо? Этого пока не происходит.
Если я дам ВМ меньше 32 виртуальных процессоров (пробовал 14), то уменьшится параметр "Процент от общего числа системных ресурсов", и в соответствии с ним - физическая загрузка ЦП. При 32 виртуальных процессорах "Процент от общего числа системных ресурсов" равен 100, но "Загрузка ЦП" в Диспетчере Hyper-V никогда не превышает 74% (ранее - 43).
Элементы управления ресурсами ЦП узла Hyper-V, представленные в Windows Server 2016 или более поздней версии, позволяют администраторам Hyper-V лучше управлять ресурсами ЦП сервера узла между "корневым" или разделом управления и гостевыми виртуальными машинами. С помощью этих элементов управления администраторы могут выделить подмножество процессоров хост-системы корневой секции. Это может разделить работу, выполняемую на узле Hyper-V, от рабочих нагрузок, работающих на гостевых виртуальных машинах, запустив их на отдельных подмножествах системных процессоров.
Дополнительные сведения об оборудовании для узлов Hyper-V см. в Windows 10 требованиях к системе Hyper-V.
История
Перед настройкой элементов управления для ресурсов ЦП узла Hyper-V рекомендуется ознакомиться с основами архитектуры Hyper-V. Общие сведения см. в разделе "Архитектура Hyper-V ". Это важные понятия для этой статьи:
Hyper-V создает секции виртуальных машин и управляет ими, в которых вычислительные ресурсы выделяются и совместно используются под контролем гипервизора. Секции обеспечивают строгие границы изоляции между всеми гостевыми виртуальными машинами и между гостевыми виртуальными машинами и корневым разделом.
Корневая секция сама является секцией виртуальной машины, хотя она имеет уникальные свойства и гораздо больше привилегий, чем гостевые виртуальные машины. Корневая секция предоставляет службы управления, управляющие всеми гостевыми виртуальными машинами, обеспечивают поддержку виртуальных устройств для гостей и управляют всеми устройствами ввода-вывода для гостевых виртуальных машин. Корпорация Майкрософт настоятельно рекомендует не запускать рабочие нагрузки приложений в разделе узла.
Каждый виртуальный процессор (VP) корневой секции сопоставляется с базовым логическим процессором (LP). VP узла всегда будет выполняться в одном базовом LP — нет миграции виртуальных ip-адресов корневой секции.
По умолчанию LPs, на которых выполняются виртуальные машины узла, также могут запускать гостевые виртуальные ip-адреса.
Гостевая виртуальная машина может быть запланирована гипервизором для запуска на любом доступном логическом процессоре. Хотя планировщик гипервизора учитывает локальность темпорального кэша, топологию NUMA и многие другие факторы при планировании гостевого виртуального сервера, в конечном счете VP может быть запланирован на любом узле LP.
Пример 11. попытка удаления непустой группы ЦП
Можно удалить только пустые группы ЦП, т. е. группы ЦП без привязанных виртуальных машин. Попытка удалить непустую группу ЦП завершится ошибкой.
Типы планировщика гипервизора
Начиная с Windows Server 2016 гипервизор Hyper-V поддерживает несколько режимов логики планировщика, которые определяют, как гипервизор планирует виртуальные процессоры на базовых логических процессорах. Эти типы планировщика:
Общие сведения о виртуализации процессоров Hyper-V
Прежде чем рассматривать типы планировщиков гипервизора, рекомендуется также понять архитектуру Hyper-V. Общие сведения см. в обзоре технологии Hyper-V. Это важные понятия для этой статьи:
Hyper-V создает секции виртуальных машин и управляет ими, в которых вычислительные ресурсы выделяются и совместно используются под контролем гипервизора. Секции обеспечивают строгие границы изоляции между всеми гостевыми виртуальными машинами и между гостевыми виртуальными машинами и корневым разделом.
Корневая секция сама по себе является секцией виртуальной машины, хотя она имеет уникальные свойства и гораздо больше привилегий, чем гостевые виртуальные машины. Корневая секция предоставляет службы управления, управляющие всеми гостевыми виртуальными машинами, обеспечивают поддержку виртуальных устройств для гостей и управляют всеми устройствами ввода-вывода для гостевых виртуальных машин. Корпорация Майкрософт настоятельно рекомендует не запускать рабочие нагрузки приложений в корневой секции.
Каждый виртуальный процессор (VP) корневой секции сопоставляется с базовым логическим процессором (LP). VP узла всегда выполняется на том же базовом LP. Миграция виртуальных машин корневого раздела отсутствует.
По умолчанию LPs, на которых выполняются виртуальные машины узла, также могут запускать гостевые виртуальные машины.
Гостевая виртуальная машина может быть запланирована низкоуровневой оболочкой для запуска на любом доступном логическом процессоре. Хотя планировщик гипервизора заботится о том, чтобы учитывать локальность темпорального кэша, топологию NUMA и многие другие факторы при планировании гостевого VP, в конечном итоге VP может быть запланирован на любом узле LP.
Пример 3. Печать одной группы ЦП
В этом примере мы будем запрашивать одну группу ЦП, используя GroupId в качестве фильтра.
Читайте также: