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

Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 1: Общий обзор
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 2: ESXi by Broadcom

Часть 3. Что из этого следует, и как устроен планировщик нормального человека в Hyper-V. Тут не будет ничего нового для тех, кто открывал документацию про корневой раздел (root partition)

Если в ESXi by Broadcom существует отдельно операционная система, в которой есть свой vsish, esxtop, и которая запускает и процессы (из которых важнейшими являются vpxa и hostd ) и worlds, то MS Hyper-V с первого взгляда выглядит как «обычная операционная система». Но MS не были бы сами собой, если бы и тут не выступили, устроив гипервизор не первого и не второго типа. Хотя AWS и пишет, что это «гипервизор первого типа»
Как и сами MS пишут в разделе Архитектура - Hyper-V architecture - Hyper-V features a Type 1 hypervisor-based architecture.

Архитектура MS Hyper-V.

Для начала, где-то в самом начале загружается сам гипервизор - Hyper-V . Гипервизор создает корневой (или родительский) раздел (root partition), где загружается ОС, и уже ОС управляет остальными виртуальными машинами, с использованием:
Virtualization Service Provider (VSP) – работает в корневом разделе
Virtualization Service Consumer (VSC) – работает в прочих разделах
VMBus – шина взаимодействия
Hypercall – интерфейс взаимодействия гостевой ОС и хоста.

Планировщик (CPU) в MS Hyper-V

Может быть одним из 3, на выбор:
The classic scheduler. Использовался по умолчанию до Windows Server 2016, включительно.
The core scheduler. Используется по умолчанию, начиная с Windows Server 2019. Обеспечивает бОльшую изоляцию и не только.
The root scheduler. Используется начиная с Windows 10.1803

Взаимоотношения планировщика и основной операционной системы

Поскольку основная операционная система (хоста) живет в отдельном разделе, то можно покрутить ручки под названием Minroot, отделив «что там делает на ядрах сама ОС» от «что там делают виртуальные машины. Настройка описана в разделе Hyper-V Host CPU Resource Management.

Взаимоотношения с таймером

В системе используется сразу 4 разных таймера, из них основной и прикрученный намертво – на 100nS, описан в разделе Hypervisor Specification  \ Timers
Из этого вытекает некоторая боль с RTC приложениями, голосовыми в основном. То есть, откручивая Minroot и поиграв (и проиграв) неравный бой с таймером в 10nS вместо 100nS, что описано нигде. И в глубине притаился HPET - High Precision Event Timer, он делает очень, очень больно, например в cloud pbx. Будете кушать - узнаете.

Выделение ресурсов

Сделано через выделение группы процессоров - Virtual Machine Resource Controls. При этом управление такой функцией доступно только через Hyper-V Host Compute Service. Ссылка на Microsoft Virtualization team's blog  из статьи Managing CPU Groups  ведет в никуда, вместо блога.
У ESXi есть относительно схожая, но иначе сделанная функция - Resource Pools.

Кроме этого, можно отдельно покрутить и настройки VM - VM cap. Про это есть отдельный раздел в Virtual Machine Resource Controls \ Setting CPU Caps on Individual VMs
В остальных моментах надо сказать, что настройки для классов сервиса (Classes of Service) и VM, описанные в статье Managing CPU resources for Hyper-V virtual machines - писали норкомане, явно не из нашей галактики, и в их мозг надо лучами проникать. Возможно, так удобнее для Azure и его локальных вариантов, но очень скудно описано.

Все вышесказанное приводит к необходимости читать всякое про таймеры, типа
Windows system timer granularity
Clocks, Timers and Virtualization 
Timekeeping Virtualization for X86-Based Architectures
Остальные настройки раскиданы по разным местам документации, и вообще описаны почти нигде.

Сети

Нырять в рамках изначально короткой статьи в глубины Virtual Machine Multiple Queues (VMMQ) , Dynamic VMMQ  и проблему Linux Network Performance мне уже не хочется.

Итого

Hyper-V тормозит точно так же, как ESXi , но делает больно иначе, управляется по другому, и масса статей и заметок утрачена вместе с проведенной чисткой старого technet. Для более подробного сравнения и описания документации недостаточно, необходимо обязательно разворачивать тестовый стенд. Аналог Hands-on lab существует только для Azure - Azure CLX.
Для того, чтобы понять, насколько в ваших условиях Hyper-V лучше или хуже ESXi – необходимо полноценное пилотное тестирование, с вашими нагрузками.

Бонусы

Случайно нашел. Архивы Virtualization Team Blog
Interview with ‘Mr Hyper V’ Ben Armstrong 
Ignite: In Chicago and online: November 18–22, 2024