Работа процессора в Hyper-V
Я уже описывал ранее режим совместимости процессора, появившийся в Hyper-V R2. Режим умеет маскировать наборы инструкций, которые существуют не во всех процессорах, поддерживающих Hyper-V. Из моей прошлой заметки можно почерпнуть, что при включении режима совместимости процессора для конкретной виртуальной машины от неё скрываются следующие наборы инструкций и технологии:
- Для процессоров Intel: SSSE3, SSE4.1, SSE4.2, POPCNT, Misaligned SSE, XSAVE, AVX.
- Для процессоров AMD: SSSE3, SSE4.1, SSE4.A, SSE5, POPCNT, LZCNT, Misaligned SSE, AMD 3DNow!, Extended AMD 3DNow!.
Почему же я вернулся назад к этой теме? Есть несколько причин.
- Недавний анонс компании AMD об исключении набора инструкций 3DNow! из будущих процессоров компании. Как это повлияет на виртуализацию Hyper-V
- Желание показать, что же реально происходит с инструкциями процессора при установке роли Hyper-V на хост, что доступно в виртуальной машине с отключенным режимом совместимости процессора
- Недавняя статья моего коллеги «Какие процессоры получает виртуальная машина внутри Hyper-V?», содержащая ряд неточностей и вызвавшая поток писем в мой адрес
Давайте попробуем разобраться по порядку.
Отказ AMD от инструкций 3DNow!
Пару месяцев назад прозвучал официальный анонс от компании AMD: в будущие процессоры компании набор инструкций 3DNow! включен не будет. История набора 3DNow! непроста. Набор появился в процессорах AMD K6-2, расширяя повсеместно используемый на тот момент набор MMX от компании Intel. Инструкции MMX позволяли процессору оперировать целочисленными 64битными значениямии векторами из нескольких элементов, упакованных в 64 бита, для чего в процессор были добавлены восемь специальных регистров. Набор 3DNow! расширил данный функционал, позволив выполнять операции над вещественными числами. Примерно через год Intel представил революционный набор SSE, добавивший множество инструкций и регистров, позволивший процессору оперировать со 128битными значениями – целочисленными, вещественными и упакованными в 128 бит векторами. Оба набора претерпели эволюцию. У AMD появился Extended 3DNow! У Intel с годами вышло пять поколений SSE с различными ветвями. AMD сейчас лицензирует у Intel права на использование наборов SSE. По сути, начиная с процессоров Athlon, существует два способа обработки мультимедиа данных. При этом один из способов – наборы SSE – общий для процессоров Intel, AMD и других x86-совместимых, а 3DNow! уникален лишь для процессоров AMD. Разработчики предпочли использовать единый способ, так что для 3DNow! просто не осталось сферы применения. На самом деле, две инструкции из 3DNow! в процессорах AMD таки сохраняться, но сейчас разговор не об этом.
Как поведёт себя Hyper-V на новых процессорах? Очевидно, что виртуальным машинам на узлах с будущими процессорами AMD не будут доступны возможности 3DNow! В случае построения кластеров, включающих старые и новые серверы, вам рекомендуется для виртуальных машин включать режим совместимости процессора. Обратите внимание, что наборы 3DNow! и Extended 3DNow! изначально маскировались от виртуальных машин в режиме совместимости. Никаких изменений делать не требуется.
Какие инструкции доступны виртуальным машинам Hyper-V?
Начиная с этого момента, моя статья будет во многом противоречить статье Андрея. Верить надо мне. J
Разработчики гипервизора Hyper-V ответственно подошли к тому факту, что процессоров на рынке существует много, и в будущем будет только больше. Наборы инструкций, регистров и микрокодов, доступных виртуальным машинам жестко специфицированы. Для всех желающих доступен документ, называющийся «Hypervisor Top Level Functional Specification 2.0», описывающий спецификацию Hyper-V R2. Аналогичный документ доступен и для первой версии Hyper-V. Приложение (Appendix D) данного документа называется «Architectural CPUID» и описывает регистры и инструкции, доступные для самой хост системы с ролью Hyper-V и для виртуальных машин. Из данного документа явно следует – процессор доступный виртуальной машине получается совсем не такой, каким он является аппаратно. Более того, возможности процессора доступного хост системе с ролью Hyper-V также существенно отличается от оригинальных спецификаций. Идентификатор процессора, формально его имя и номер, пробрасываются в виртуальную машину без изменений. Но часть инструкций ей недоступна. Если завтра появится набор SSE6, то на обычных Windows системах он сразу будет доступен. На системе с установленной ролью Hyper-V и в виртуальных машинах данный набор инструкций не будет доступен – его нет в функциональной спецификации гипервизора. Навряд ли его станут добавлять каким-либо небольшим обновлением из опасения получить различные системы в одном кластере. Скорее всего новые поколения наборов инструкций будут появляться лишь в новых версиях ОС. Для критически востребованных рынком наборов я допускаю возможность появления их в пакете обновления к ОС, который всё равно требует обновленного документа спецификации гипервизора.
В случае использования в одном сервере различных процессоров (по микрокоду или даже поколению) гипервизор нормализует инструкции, доступные хост серверу и виртуальным машинам по наименьшему принципу.
В случае построения кластеров из различных серверов никакой автоматической нормализации не происходит! Если вы опасаетесь, что процессоры в серверах различны, если вы хотите чтобы ваша виртуальная машина этого не ощутила, включайте для неё режим совместимости процессора. При этом ей будут доступны все те инструкции процессора, которые есть на любой системе, поддерживающей Hyper-V, - за некими исключениями, прописанными в функциональной спецификации гипервизора.
Как изменяется CPUid в Hyper-V
Для начала немного теории о том, что же такое CPUid. С появлением процессоров Intel Pentium и AMD K5, приносящих новые возможности в мир 32-битных процессоров, возникла необходимость позволить разработчикам операционных систем и программного обеспечения судить о возможностях процессора. В процессоры была добавлена стандартизованный микрокод CPUid, возвращающий специфическую информацию о процессоре, хранимую в регистрах EAX. Не буду копать глубоко в структуру CPUid, вы можете почитать теорию и уточнить, как Microsoft это реализует на практике.
Поговорим о том, как изменяется CPUid в Hyper-V. Дело в том, что когда вы устанавливаете роль Hyper-V на Windows Server 2008/R2, между процессором и операционной системой появляется прослойка – гипервизор. Гипервизор маскирует некие свойства процессора для самой хост системы. Также он маскирует свойства процессора для виртуальных машин. Посмотрим, как меняются первые регистры CPUid при установке роли Hyper-V:
Интересно, CPUid в ОС без Hyper-V говорит о десяти доступных регистрах с информацией о процессоре, тогда как после установки роли нам доступно лишь шесть регистров.
Из первого регистра CPUid наиболее существенным для нас является факт, что уже на самом хосте после установки роли Hyper-V нам недоступен набор VT. Гипервизор маскирует его от нас, наряду с некоторыми менее интересными инструкциями. Виртуальным машинам также недоступны наборы VT, VT-d, VTx и другие. И комментариев по их появлению в виртуальных машинах на данном этапе Microsoft не дает.
Для примера я установил ОС Windows Server 2008 R2 на инженерный образец сервера HP ProLiant DL580G7 с 32 ядрами и 64 логическими потоками. Посмотрим, как известная утилита CPU-Z определяет процессоры сервера до и после установки роли Hyper-V:
Видим, что после установки роли Hyper-V для ОС уже недоступен набор VT-x, - равно как и многие другие инструкции, согласно спецификации гипервизора. Информация о системной плате, рапортуемая утилитой, не меняется. После установки роли Hyper-V система выглядела примерно так:
Что же мы увидим в виртуальной машине?
Уже заметно, что CPUid изменен. Имя модели процессора и значения идентификаторов семейства пробрасываются напрямую, однако система уже не определяет процессор как Xeon E7520, а видит лишь архитектуру Nehalem – Intel Core i7. На загадочной цифре «31», появившейся на скриншотах я остановлюсь чуть позднее.
В ОС Linux я могу увидеть более подробно список доступных виртуальной машине инструкций, взяв его из файла /proc/cpuinfo:
Приведенный скриншот дает информацию о первом ядре, остальные аналогичны, я сократил картинку.
В режиме совмести процессора, как мы знаем, инструкции нормализуются до заданной маски.
Режим совместимости со старыми ОС
Кроме режима совместимости процессора в свойствах ВМ есть еще опция включить режим совместимости со старыми операционными системами, например, Windows NT 4.0. Что на деле даёт такая опция? Мы уже знаем, что для ОС с установленной ролью Hyper-V, равно как и для виртуальных машин, гипервизор выдает измененные результаты в ответ на инструкцию CPUid. Для режима совместимости со старыми ОС, применяется еще большая маскировка. CPUid рапортует о доступности лишь двух регистров с информацией о процессоре:
Что же находилось в тех регистрах, которые недоступны виртуальной машине в режиме совместимости со старыми ОС?
Из скрытых четырёх регистров мы могли бы почерпнуть информацию о названии/модели процессора, его серийном номере, о параметрах кэша L1/L2 процессора, о количестве ядер на физическом процессоре, некоторую информацию с датчиков температуры процессора.
Дело в том, что Windows NT 4.0 при установке проверяет CPUid, считывая информацию о модели процессора, делая вывод о возможности работы ОС на данном процессоре. С годами формат хранения модели процессора в ответе CPUid несколько изменился, так что на новые процессоры Windows NT 4.0 просто не устанавливается. Режим совместимости со старыми ОС маскирует параметр модели процессора так, чтобы он подавался в старом формате. Процессор выглядит «другим» для виртуальной машины. Windows NT 4.0 устанавливается корректно.
Что же касается наборов инструкций, доступных виртуальной машине в режиме совместимости со старыми ОС, то они не отличаются от обычных виртуальных машин. Виртуальный процессор может иметь старое имя и номер модели, но при этом обладать функционалом SSE 4.2, если режим совместимости процессора не включен для данной виртуальной машины.
Многоядерность и многопроцессорность в Hyper-V
Для виртуальных машин Hyper-V мы можем предоставить несколько виртуальных процессоров. Как будут представлены эти процессоры внутри виртуальной машины – будет ли это один многоядерный процессор или несколько независимых процессоров? Что будет в случае наличия многопоточности (Hyper-Threading) на физическом процессоре?
Для виртуальных машин Hyper-V представляет процессоры многоядерными. Для поддерживаемого количества виртуальных процессоров количество ядер на процессор равно количеству физических ядер на реальных процессорах. Включение режима совместимости со старыми ОС для многопроцессорной виртуальной машины презентует виртуальные процессоры не как ядра одного физического процессора, а как логические потоки (Hyper-Threading) одноядерного процессора. Как мы понимаем, это получается из-за того, что CPUid маскирует регистр, хранящий параметр количества ядер.
Что касается максимального количества процессоров доступных виртуальным машинам. Microsoft поддерживает четыре виртуальных процессора для Windows Server 2008/R2/SUSE/RedHat. Для Windows Server 2003/XP/Vista/7 поддерживается два процессора. Один процессор поддерживается для Windows 2000 Server.
Данные значения являются показателями поддержки. Никто не мешает вам использовать больше. В случае обращения в службу технической поддержки Microsoft с проблемой, вас попросят воспроизвести проблему в виртуальной машине с поддерживаемым количеством процессоров – вам придется выключить виртуальную машину, изменить количество процессоров, включить машину и показать проблему.
Значение «4» для максимального количества доступных процессоров является мягким – тот кому очень нужно получить больше изменит одну настройку в ОС и будет доволен. Технически гипервизор Hyper-V в данный момент ограничен 64 логическими процессорами. Если ваш сервер имеет больше логических процессоров, то гипервизор не увидит ничего сверх 64. Если на таком сервере имеется многопоточность Hyper-Threading, отключите её в BIOS, чтобы гипервизор использовал 64 реальных ядра. К сожалению, на инженерном образце сервера, где я проводил тестирование, одно из ядер процессора было «битым», так что гипервизор не мог адресовать ядра, находящиеся за ним. Но первые 31 ядро были вполне адекватными, так что сейчас я продемонстрирую несколько скриншотов, - вы сами решайте что и как нужно сделать. Скриншоты с 64 ядрами я покажу, когда получу новый DL980G7:
Пример хорошо показывает масштабируемость настоящего гипервизора и возможность компании в любой момент увеличить значения поддержки. Комментарии на тему последнего абзаца принимаются только в почту, в посте включена пре-модерация комментариев.
Comments
Anonymous
January 01, 2003
Garry, не было вопроса про HT - напишите еще раз, отвечу. Я не готов обсуждать лишь многопроцессорность в ВМ.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Это стандартный диспетчер задач из GNOME интерфейса в SUSE. Аналог кнопки ПУСК слева внизу, далее выбираете его. Ничего не устанавливалось отдельно.Anonymous
January 01, 2003
Сергей, SLAT уже сейчас поддерживается начиная с выхода R2. Поддержки разных расширений в VT нет и не анонсировалось. Про новые наборы инструкций - если рынок будет требовать, то возможно обновление гипервизора и спецификации на него по списку инструкций. Сейчас такого требования нет - не видел ни одного крупного заказчика, для которого фактором выбора или отказа от гипервизора стояли дополнительные инструкции к VT. Подскажите мне такого (и обоснование зачем ему это так требуется), это может стать обоснованием для работы.Anonymous
January 01, 2003
Диспетчер задач хоста ничего не знает про загрузку ОС в ВМ. Если вас интересует суммарная загрузка, запускайте PerfMon и смотрите счетчики, начинающиеся со слов Hyper-V Я писал цикл статей про это. blogs.technet.com/.../hyper_2d00_v-performance-2d00-how-to-test.aspx blogs.technet.com/.../hyper_2D00_v-performance.-physical-vs.-virtual-counters.aspx blogs.technet.com/.../hyper_2D00_v-performance-counters.aspx blogs.technet.com/.../hyper-v-4-hyper-v-hypervisor.aspx blogs.technet.com/.../hyper-v-5-171-hyper-v-hypervisor-logical-processors-187.aspx blogs.technet.com/.../hyper-v-6-wmi.aspxAnonymous
October 16, 2010
Спасибо за столь содержательную и интересную статью. Интересует пара вопросов: В процессоры и чипсеты так же закладываются дополнительные возможности (в формулировке Intel это EPT (SLAT), VT-d). Когда появляется поддержка этих возможностей в Hyper-V? Ведь изменения в технологиях происходит куда быстрее чем выход новой ОС, можно ли расчитывать на поддержку новых технологий в процессорах с выходом скажем SP, какова позиция Микрософт в данном вопросе?Anonymous
October 17, 2010
доброе время суток,а как сделать доступным больше 4 виртуальный процессоров?Anonymous
October 17, 2010
спасибо за интересную статья. Вот только не понял как сделать чтобы виртуальная машины видела больше 4 процессоров.Anonymous
October 17, 2010
А комментарий про Hyper-Threading от меня и ответ на него будет?Anonymous
October 18, 2010
Спасибо за статью! Возможно глупый вопрос - а этот скриншот: virtualization.su/.../082510_1234_ProcessorHyperV11.png это какая программа?Anonymous
January 26, 2011
Такой вопрос, на 8ми процессорном сервере работает 5-6 виртуальных машин, терминальные сервера, файловые и пр. Скажите пожалуйста, диспетчер задач самого Hyper-V сервера отражает загрузку которую на него возлагают виртуальные? Потому как локально показывает что процессоры вообще почти не загружены... Вопрос может быть и глупый, но тем не менее, хотелось бы услышать от продвинутых людей.Anonymous
July 03, 2017
Уж простите, но я не понял как с Вами связаться в почте, а комментарий у меня по последнму абзацу.Вопрос интересный, а из блока пропали картинки... так что сделать по ним своих выводов мы не можем. Запись, вообще, довольно старая, но она в топе Яндекса по запросу "Hyper-Threading Hyper-V", поэтому стоит, может быть, освежить её.
