Мы уже обсуждали, как настраивается Network Teaming в операционных системах Windows, в частности на серверах HP ProLiant при помощи HP Network Configuration Utility. Мы рассмотрели, что для повышения доступности сетевых соединений мы объединяем несколько физических интерфейсов в Team. Далее мы можем создать несколько виртуальных интерфейсов на базе данного Team, получив несколько сетевых интерфейсов в хост системе. Поверх каждого из этих интерфейсов мы создавали внешние коммутаторы Hyper-V поверх этих виртуальных интерфейсов. Для виртуальных машин мы выбирали внешний коммутатор Hyper-V и указывали номер VLAN, к которому тот подключен, в итоге виртуальная машина получала доступ к сети.
Недавно вышла HP Network Configuration Utility версии 10.1.0, которая добавила возможность использования Network Teaming в Promiscuous mode. Рассмотрим, что это за режим и почему это интересно для виртуализации.
Создание Network Team начинается с объединения нескольких интерфейсов:
Обратим внимание, что для данного Network Team пока доступна возможность создания VLAN, так как режим Promiscuous mode по умолчанию не включен. Для того чтобы задействовать его, зайдем в свойства Team и в закладке Settings задействуем новую возможность:
Сразу после применения настройки исчезнет закладка VLAN, и в свойствах Network Team возможность конфигурации VLAN станет недоступной.
Теперь нужно создать внешний коммутатор Hyper-V на базе данного Network Team. Рекомендую делать это их SCVMM, если вы его используете, так как его настройки более гибкие.
Создадим коммутатор и настроим его как Trunk, указав все возможные виртуальные сети:
Перечислим все возможные VLAN, которые мы будем использовать для виртуальных машин:
Теперь для виртуальных машин мы будем указывать коммутатор Hyper-V (один на наш Network Team) и VLAN, к которому данная виртуальная машина должна быть подключена:
Если вы уже настроили сетевое оборудование на работу в режиме Trunk, то виртуальные машины должны начать работать с сетью. Для серверов семейства BladeSystem, следует настроить порты HP Virtual Connect, к которым подключены лезвия.
Необходимо включить режим VLAN Tunneling:
Теперь, если вы хотите перенести виртуальную машину в другой VLAN, достаточно просто изменить идентификатор VLAN в настройках виртуальной машины. Соответственно, теперь нет необходимости создавать по виртуальному интерфейсу и коммутатору Hyper-V на каждый VLAN и менять коммутатор Hyper-V, к которому подключена виртуальная машина. Надеюсь, это существенно упростит конфигурацию ваших серверов виртуализации.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=C3202CE6-4056-4059-8A1B-3A9B77CDFDDA
Сказать в общем-то нечего — за исключением следующего.
Иногда вам может потребоваться воспользоваться отладчиком на стадии загрузки ОС. Чаще всего это требуется для диагностики ошибок загрузки, написания драйверов и служб, запускающихся в высоких приоритетах. Для физического сервера или персонального компьютера, обычно, при помощи параллельного или последовательного кабеля соединяют два компьютера и отладчиком считывают информацию по ходу загрузки. Как сделать это для виртуальной машины, которая не имеет физического COM или LPT порта? Конечно же, нам помогут именованные каналы Named Pipes!
В первую очередь, вам потребуется установить Debugging Tools for Windows. Проще всего сделать это на хосте виртуализации, что не потребует настройки брэндмауэра и прав удалённого доступа к именованным каналам сервера.
Установив Debugging Tools на хост, вам следует в свойствах выключенной виртуальной машины настроить виртуальный COM порт на использование некого именованного канала. Например, я укажу имя так: \\.\pipe\VM1_pipe
Чтобы соединиться с эти именованным каналом для отладки, включите виртуальную машину, затем в режиме администратора (Elevated) запустите на хосте виртуализации Command Prompt или утилиту kd.exe с указанными ключами:
kd -k com:port=\\.\pipe\VM1_pipe,pipe,resets=0,reconnect
Если вы соединяетесь с другого удалённого компьютера, используйте следующие ключи:
kd -k com:port=\\<HyperV_host_machine>\pipe\VM1_pipe,pipe,resets=0,reconnect , где <HyperV_host_machine> - имя хоста виртуализации.
Для отладки виртуальных машин Hyper-V, Virtual PC или Virtual Server 2005 требуется использование параметра resets=0.
Подсказка: для отладки виртуальных машин на платформах виртуализации других вендоров обычно требуется значение параметра resets=2.
Я уже описывал ранее режим совместимости процессора, появившийся в Hyper-V R2. Режим умеет маскировать наборы инструкций, которые существуют не во всех процессорах, поддерживающих 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:
Пример хорошо показывает масштабируемость настоящего гипервизора и возможность компании в любой момент увеличить значения поддержки. Комментарии на тему последнего абзаца принимаются только в почту, в посте включена пре-модерация комментариев.
В прошлом я не часто писал об Offline Virtual Machine Servicing Tool. Не более чем анонс выхода новой версии с кратким списком и диаграммой возможностей и ссылкой на скачивание. Ни у кого из крупных заказчиков OVMST 1.x/2.x не прижился. Действительно, что предлагал нам Offline Virtual Machne Servicing Tool до версии 2.1 включительно? Вы могли лишь устанавливать обновления на выключенные виртуальные машины, хранящиеся в Библиотеке SCVMM. Кто из вас хранит там выключенные виртуальные машины? Никто? Мне тоже так кажется. OVMST не умел обновлять шаблонов виртуальных машин, - которыми большинство таки пользуется. Ведь для того чтобы обновить шаблон вам требуется создать новую виртуальную машину на базе этого шаблона, включить её, установить обновления с WSUS/SCCM, сделать sysprep, выключить и перезаписать старый шаблон в Библиотеке. Нетривиально, но технически реализуемо. Все бы хорошо, если бы не активация ОС. Неактивированные ОС с XP/2003 не позволят агенту зайти для установки обновлений. А Vista/Windows7/2008/R2 разрешают не более пяти операций rearm, после чего сразу попадают в Notification License State состояние и следующая операция sysprep уже не сработает. То есть метод не подходит. При использовнии Volume дистрибутивов ОС XP/2003 и KMS сервера для новых ОС частично проблема уходит.
Чем же примечателен Virtual Machine Servicing Tool версии 3.0, ставший на днях доступным для загрузки на сайте Microsoft?
Во-первых, появилась давно ожидаемаю возможность установки обновления на узлы кластеров хостов виртуализации. Процесс переводит первый узел кластера в режим обслуживания, все виртуальные машины переносятся с него на другие узлы - без потери связи и прерывания работы. Далее идет установка обновлений на узел, перезагрузка узла в случае необходимости, возврат "своих" виртуальных машин на данный узел. И итеративный переход к следующему узлу кластера. Таким образом теперь нет замкнутого круга - не использовать автоматического обновления вовсе и быть уязвимым, или включить автоматическое обновление и ждать 3 часов ночи второго вторника месяца, когда все узлы разом перезагрузятся, установив ежемесячный набор обновлений. Сейчас можно настроить еженедельное сервисное обновление узлов в различные ночные часы так, что владельцы виртуальных машин не догадаются, что хосты виртуализации были обновлены и перезагружены.
Во-вторых, реализован функционал, использующий Offline Servicing Stack - возможности установки обновлений в выключенную ОС. Теперь для шаблонов дисков, хранящихся в Библиотеке, нет нужды создавать виртуальную машину для установки обновлений. VHD диск копируется на хост, где происходит его подключение как виртуального диска, процесс загружает обновления с WSUS и устанавливает их прямо в подмонтированный VHD диск, не загружая ОС. Увы, в данной версии это работает только с шаблонами Windows 7 и 2008 R2. Я сам этого не совсем понимаю, offline servicing stack у Vista и 2008 не отличается чем-то серьезным. Думаю, что это поправят к версии 3.1.
Приведу пример скриншота работы VMST 3.0, который я развернул в Microsoft Technology Center в Москве для обновления VHD дисков, хранящихся в Библиотеке: