Мы только что рассмотрели способ, позволяющий сделать образ системы с Hyper-V RTM, а также способ установки Windows Server 2008 и Hyper-V RTM без использования образов.
Давайте вкратце поговорим об использовании образов для установки ОС. Это замечательный способ для массового развертывания уже готовой системы на большое количество серверов или рабочих станций, не требующий настройки каждой из них по отдельности.
Даже если вы впервые устанавливаете Windows Server 2008 или Windows Vista с официального дистрибутива, вы все равно пользуетесь заранее подготовленными образами. Если вы посмотрите на DVD с Windows Server 2008 или Windows Vista, то в папке \Sources найдете файл install.wim. WIM — это аббревиатура от WIndows Image, то есть образ системы с Windows, который программа установки распакует на ваш диск.
Вы сами можете создавать файлы WIM при помощи утилиты ImageX, которая распространяется в составе Windows AIK, упоминавшегося в предыдущей статье.
Одним из преимуществ технологии WIM (а их много, но сейчас не время их перечислять) — в том, что при помощи ImageX вы можете монтировать образ в к используемой файловой системе. То есть видеть и использовать образ как локальный каталог на диске в вашей рабочей системе, копировать фалы туда и обратно, а затем сохранить образ. При проектировании Windows Vista и Server 2008 была проделана большая работа, позволившая упростить задачи поддержки и управления ОС. Не хочу петь маркетинговые гимны нашим новым ОС — скажу лишь, что одним из нововведений стал Offline Servicing. То есть возможность изменять и исправлятьОС, даже не загружаясь в нее.
Итак, что это все дает нам для установки Hyper-V?
Hyper-V RTM распространяется в формате файла обновления ОС. Это означает, что вы можете использовать все преимущества Offline Servicing для того, чтобы интегрировать его в любой имеющийся у вас образ Windows Server 2008. Это касается как образов с официальных дистрибутивов, так и любых образов, подготовленных самостоятельно. Единственное, что я вам крайне порекомендую сделать при использовании своих собственных образов, — воспользоваться утилитой sysprep с ключем /generalize, как мы обсуждали в первой статье цикла.
Исходя из того, что файл WIM у вас есть (install.wim с DVD или ваш образ после sysprep), надо выполнить несколько операций:
Все! Ваш образ готов. Теперь в него встроена версия Hyper-V RTM. Когда вы в следующий раз примените этот образ, ваш свежеустановленный Windows Server будет сразу иметь версию Hyper-V RTM в списке доступных ролей. Однако по умолчанию эта роль не будет включена. Чтобы автоматически задействовать эту роль, вам придется воспользоваться файлом unattend.xml — так, как мы обсуждали во второй статье цикла. Но как только вы ее задействуйте, — будьте уверены, она уже имеет версию RTM.
Хороший показатель подогретого интереса к технологии виртуализации Microsoft — сегодня с утра я получил вопрос о том, как же установить Hyper-V. Это означает, что человек не интересовался предварительными версиями, но собрался попробовать Hyper-V в тот же день, как было объявлено об окончательном выпуске.
Итак, вы развернули свежую установку Windows Server 2008 и ищете в списке ролей возможность установить Hyper-V. Можете не искать — на только что установленном сервере этой роли нет. Несмотря на то, что в дистрибутив Windows Server 2008 RTM встроена бета-версия Hyper-V, по умолчанию она недоступна. Поэтому в любом случае, для того, чтобы получить возможность установить роль Hyper-V, вам необходимо предварительно установить обновление из файла в формате «Microsoft Update Standalone Installer» (MSU). Поскольку вчера вышла окончательная версия Hyper-V, вам не нужны никакие предварительные версии этого обновления — ни те, что входят в дистрибутив Windows Server 2008, ни какие-либо другие, которые вы могли загрузить с сайта Microsoft до вчерашнего дня. Итак, последовательность действий такова:
Другая распространённая ошибка — попытка установить это обновление на Windows Server 2008 x86. Обновление, предназначенное для платформы x64, просто не установится. А аналогичное обновление для платформы х86 содержит только инструменты удалённого управления и не даёт возможности устанавливать роль Hyper-V. Для Hyper-V необходима только 64-битная ОС.
Третий «подводный камень», который может вас ожидать — после успешной установки роли Hyper-V гипервизор может не запускаться. Об этом можно узнать либо из соответствующих предупреждений в журнале событий системы, либо при попытке подключиться к серверу с помошью оснастки «Hyper-V Manager» (в том числе, и локально). Наиболее распространённая причина этого — отсутствие аппаратной поддержки виртуализации. Полная информация о системных требованиях приведена во вчерашней заметке «Окончательный выпуск Hyper-V и ограничения конфигураций».
Здесь есть ещё один интересный момент. Если вы обнаружите, что необходимо включить некоторые функции в BIOS сервера, иногда даже полной перезагрузки оказывается недостаточно. Даже если вы включите необходимые настройки, гипервизор может по-прежнему не запускаться. В этом случае полностью выключите сервер на несколько секунд, и только потом загружайтесь.
На тот случай, если после всех сегодняшних новостей ваша жажда знаний осталась ещё не удовлетворена, в завершение этого интересного дня хотелось бы поделиться общим набором ссылок. Большинство из этих ресурсов у всех на слуху, мы неоднократно ссылались на них в других записях этого блога. Но есть и несколько страничек, которые появились или были существенно обновлены только сегодня.
Официальные ресурсы
Сегодняшние статьи, посвящённые выходу Hyper-V и неминуемому обострению конкуренции на рынке виртуализации
К сожалению, пока что появились статьи только на англоязычных сайтах. Если вам встретится заметка, которую я пропустил — напишите об этом в комментариях, будем пополнять список вместе. (Конечно, это актуально ближайшие несколько дней, пока новость остаётся новостью).
Сегодня компания QLogic, производитель решений для хранения данных, опубликовала результаты крайне любопытного исследования. При использовании SAN и 8-гигабитного адаптера FibreChannel QLogic 2500 Series, Windows Server 2008 достиг показателя 121 000 операций ввода-вывода в секунду. С Hyper-V, виртуальные машины смогли приблизиться к этому покзателю практически вплотную — 113 000 операций ввода-вывода, что составляет 93% от «чистого» показателя. Если же уменьшить размер блока с 8 KB до 512 байт, то цифры становятся ещё более впечатляющими. Производительность собственно Windows Server 2008 достигает 200 000 операций в секунду, а виртуальных машин Hyper-V — 180 000, то есть 90%.
Из этого можно сделать два вывода. Во-первых, производительность Windows Server 2008 даже без доплнительных настроек и доработок под конкретную конфигурацию уже достаточно высока. Во-вторых, накладные расходы на виртуализацию Hyper-V минимальны — по крайней мере, в отношении подсистемы ввода-вывода.
Update. Добавил в качестве вложения сам текст пресс-релиза, так как на официальном сайте QLogic он пока недоступен.
Я повторял это сегодня много раз, и вот наконец заработали все ссылки, приведённые в первой заметке. Поскольку за всем обилием сегодняшних новостей их легко можно было потерять, повторю коротко ещё раз.
Все комментарии, описания и интересные факты — в первой за сегодня заметке «Окончательный выпуск Hyper-V».
Конечно, если кого-то интересует производительность, то какие-либо выводы на этот счёт можно делать только после выхода окончательной версии продукта. Иными словами, сейчас наступает самое время проводить нагрузочное тестирование по всем сценариям, какие подскажет вам фантазия.
Многих в этой связи интересует вопрос о максимальных поддерживаемых конфирурациях оборудования для Hyper-V. Эта тема подробно раскрывается в официальной документации — а конкретно, Hyper-V Deployment Guide (Руководстве по развёртыванию Hyper-V). Однако, поскольку этот документ ещё не опубликован, приведу в вольном переводе выдержки из него, касающиеся максимальных конфигураций.
Требования к операционной системе сервера (установленной на физическом оборудовании)
Ещё раз обращаю ваше внимание на то, что технология Hyper-V доступна только для архитектуры x64. Это не тот случай, когда существует ознакомительная версия для платформы x86 (как с Exchange Server), а также не тот случай, где архитектура Intel Itanum обеспечивает максимально возможную производителность и масштабируемость (как с SQL Server). Hyper-V попросту не существует и никогда не разрабатывался для всех остальных платформ, кроме x64.
Требования к оборудованию (Мы подробно писали о них в заметке «Утилиты для проверки поддержки Hyper-V на вашей системе»)
Архитектура виртуальных машин
Оперативная память
Процессоры
Сеть
Физическая система хранения. Широкая поддержка накопителей, включая
Виртуальные диски (подробнее смотрите в нашем блоге по метке «Storage»)
Виртуальные контроллеры дисков
Виртуальная система хранения
Виртуальные накопители CD/DVD
Виртуальные последовательные порты (COM)
Виртуальный привод гибких дисков
Количество виртуальных машин
Приходится признать, что многие из приведённых показателей сегодня выглядят более теоретическими, чем достижимыми в реалистичных сценариях. С чем же можно сравнить производительность Hyper-V на практике? Уверен, что в самом ближайшем будущем нас ждёт много интересных публикаций о результатах нагрузочных тестов с использованием самых разных задач и моделей оборудования.
А прямо сегодня есть такой интересный пример. На одном физическом сервере в восемнадцати виртуальных машинах параллельно запущена установка восемнадцати экземпляров ОС Windows Server 2008 на восемнадцати языках, на которых сегодня доступен Hyper-V. При этом осталось ещё немного ресурсов, и их использовали чтобы дополнительно запустить установку Windows Web Server 2008.
Но самое интересное здесь — конечно, характеристики физического сервера. Возьму на себя смелость охарактеризовать их как весьма средние на сегодня.
P.S. Алекс работает над серией статей, посвящённых вопросам тестирования производительности Hyper-V. Первая заметка этого цикла уже опубликована под названием «Hyper-V и производительность. Часть 1 — как тестировать?». Следите за нашим блогом, окончательный выпуск Hyper-V ещё не означает, что у нас закончатся темы для обсуждения!
Недавно мы писали о выходе обновления для текущей общедоступной бета-версии System Center Virtual Machine Manager 2008. В полном соответствии с обещаниями, это обновление приносит в SCVMM поддержку и вышедшей сегодня окончательной версии Hyper-V. По заявлениям разработчиков, им не удалось пока что обнаружить сколь-нибудь серьёзные проблемы при работе текущей бета-версии SCVMM с окончательной версией Hyper-V.
Много интересных цифр из пресс-релиза я уже приводил в первой сегодняшней заметке, которая посвящена выпуску окончательной версии Hyper-V. Сейчас я ещё дополню эту коллекцию. Во-первых, уже более 250 моделей серверов сертифицированы для работы с Hyper-V (список постоянно пополняется на сайте Windows Server Catalog). А кроме того, есть целый ряд статистических показателей по итогам тестирования предварительных версий Hyper-V.
Данные по внешним заказчикам
Данные внутреннего развёртывания в Microsoft
Результаты и планы виртуализации общедоступных веб-серверов
Вся эта статистика призвана показать, что Hyper-V действительно полностью готов к промышленной экплуатации с любыми типами задач.
При работе с Hyper-V, как и с большинством других серверных технологий, рекомендованной является схема удалённого управления. То есть сама роль виртуализации выполняется на сервере, а управление ей осуществляется с рабочей станции администратора. В случае Hyper-V инструменты удалённого управления были выпущены для Windows Vista Service Pack 1 и Windows Server 2008 x86.
У тех, кто уже успел установить окончательную версию Hyper-V, иногда возникет следующая проблема. Попытка подключения к серверу с помощю консоли Hyper-V Manager завершается ошибкой, которая гласит: «Access denied. Unable to establish communication between» (Доступ запрещён. Невозможно установить соединение между… — дальше указываются имена удалённого сервера и рабочей станции администратора).
Решение этой проблемы несложно и целиком зависит от клиентской машины. Необходимо выполнить следующую последовательность операций.
Ссылки, опубликованные в предыдущей заметке должны заработать в самое ближайшее время. Но тем временем, информация продолжает поступать. Окончательная версия Hyper-V 1.0 имеет номер сборки 6.0.6001.18016, как показано на скриншоте.
Дистрибутивы будут доступны на восемнадцати языках, в числе которых и русский. Вот полный на сегодня список.
Update. Текущий список поддерживаемых гостевых ОС, который я приводил в предыдущей заметке, официально опубликован в статье Базы знаний Microsoft KB954958 — Guest operating systems that are supported on a Hyper-V virtual machine host. В будущем этот список обязательно будет дополняться. Мы постараемся не пропускать такие события и каждый раз отдельно сообщать о них.
Update 2. Если кому интересно — полная метка сборки выглядит следующим образом: 6.0.6001.18016 (vistasp1_gdr_vm_rtm.080611-0040).
Сегодня стало объявлено о выходе окончательной версии Hyper-V. На сайте официальном сайте она должна появиться в 9 утра по тихоокеанскому времени, то есть в 8 вечера по Москве. Также соответствующие обновления станут распространяться через службу Windows Update начиная с 8 июля. Это значит, что виртуализация серверов Microsoft стала доступна всем заказчикам без ограничений и начинает пользоваться полной поддержкой в производственной среде.
По этому поводу привожу окончательный список гостевых ОС, которые поддерживаются в Hyper-V. О большинстве из них было известно давно, но часть появилась в Hyper-V RC1, а некоторые стали сюрпризом окончательной версии. Важно, что для всех ОС из этого списка созданы Службы интеграции (Integration Services, ранее называемые Integration Components). Да, даже для Windows 2000, вопреки первоначальным заявлениям.
Серверные ОС
Microsoft Windows Server 2008
Microsoft Windows Server 2003
Microsoft Windows 2000
Suse Linux Enterprise Server 10
Клиентские ОС
Microsoft Windows Vista
Microsoft Windows XP
Стоит упомянуть, что этот список включает только те ОС, которые официально поддерживаются Microsoft — как стандартной PSS, так и Premier Suppor. Отсутствие ОС в этом списке не означает, что она обязательно не будет работать вообще. Просто это не гарантируется и не поддерживается. Вот несколько примеров таких неподдерживаемых ОС, про которые известно, что они запускаются и работают.
Пафосные цифры про Hyper-V из официального пресс-релиза
Ссылки, посвящённые Hyper-V RTM
Общая информация
Статьи Базы знаний
Загрузка дистрибутивов. Внимание, после установки удаление данных обновлений станет невозможным.
Советы по проведению обновления
Update. Все сегодняшние заметки, связанные с выходом Hyper-V
Обычно перед принятием решения о консолидации серверов в виртуальной среде или миграции с альтернативных платформ на виртуализацию Microsoft требуется провести тестирование производительности работы гостевой ОС и приложений. Сегодня мы немного поговорим о том, что необходимо иметь в виду при подготовке к такому тестированию, как правильно настраивать гостевую ОС и саму виртуальную машину, чтобы получить хорошую производительность. Рассмотрим три главных шага, ведущих к получению достойного результата. Эти шаги следует выполнять не только при тестировании, но и для достижения нужных результатов в эксплуатируемых системах.
Шаг 1. Установите компоненты интеграции. Integration Components — это такой же важный элемент работы виртуальной машины Hyper-V, как Virtual Machine Additions в Virtual Server 2005. Установка компонентов интеграции увеличивает производительность на десятки, а иногда и на сотни процентов. Поэтому прежде всего убедитесь, что у вас установлены компоненты интеграции. Есть несколько способов сделать это. Один из способов — подключить виртуальный диск к контроллеру SCSI вашей ВМ. Виртуальный контроллер SCSI использует шину VMBus, и если компоненты интеграции не установлены или работают некорректно, то вы не увидите подключенного диска.
В Hyper-V операционная система может загружаться только с контроллера IDE, для работы которого не требуется запущенных компонентов интеграции. Сами же данные и приложения я рекомендую размещать на дисках, подключенных к виртуальному контроллеру SCSI. В отличии от Virtual Server 2005, в Hyper-V после установки компонентов интеграции как правило нет существенной разницы в производительности дисков, подключенных к контроллерам IDE или SCSI. Однако на некоторых задачах такая разница все-таки существует, поэтому если вы собираетесь производить тестирование — я рекомендую использовать для данных и приложений диски, подключенные к виртуальному контроллеру SCSI.
Втором способом проверки наличия установленных компонентов интеграции будет просто открыть Диспетчер устройств и проверить наличие шины VMBus и устройств, ассоциированных с Hyper-V. Их список может отличаться в зависимости от версии и языка ОС, а также версии самих компонентов интеграции. Также в Диспетчере устройств вы сможете изучить свойства драйвера шины VMBus, чтобы узнать версию установленных компонентов интеграции. Убедитесь в том, что версия компонентов интеграции и самого Hyper-V на сервере совпадают. Подробнее о версиях смотрите «Версии Hyper-V».
Шаг 2. Во время замера производительности закройте все подключения к данному серверу через Hyper-V Manager. В открытом окне Hyper-V Manager нет ничего плохого, однако он постоянно запрашивает статус виртуальных машин и отображает консоль в небольшом окне, что влияет на производительность. Если для вас важно иметь запущенный Hyper-V Manager — сверните его, при этом он перестанет опрашивать виртуальные машины. Я все-таки рекомендовал бы именно закрыть его на время тестирования.
Шаг 3. Не используйте VMConnect для соединения с тестируемой машиной. Если вы установили соединение с виртуальной машиной из Hyper-V Manager — у вас открылось окно утилиты VMConnect, через которое вы получаете доступ к ее консоли. Даже если затем вы перехватите сессию используя «Удаленный рабочий стол» — окно VMConnect все равно будет отображать заблокированную консольную сессию гостевой ОС, потребляя ресурсы. Для задач тестирования пользуйтесь только «Удаленным рабочи столом», а не VMConnect. Вы же не будете постоянно держать консоль открытой после внедрения. Если тестирование происходит автоматически и не требует вашего вмешательства, то и «Удаленный рабочий стол» следует свернуть или закрыть. Для получения максимальных результатов запускайте задачи на тестируемой ВМ удаленно при помощи утилиты PsExec.
Выполнив эти три простых рекомендации вы добьетесь от вашей виртуальной машины мксимума производительности. В дальнейшем я расскажу о резервировании и ограничении ресурсов, а также дам советы по оптимизации и способах измерения производительности.
На прошедшей в Орландо конференции TechEd комания Double-Take объявила о разработке линейки продуктов, поддерживающих Windows Server 2008 Hyper-V. Решения Double-Take ориентированы на крупных заказчиков и предлагают удобные средства для миграции в виртуальную среду — как с физических серверов (P2V), так и виртуальных машин других платформ виртуализации (V2V), а также построения надежных отказоустойчивых систем, проведения быстрой и безболезненной миграции и консолидации серверов в режиме реального времени. Объявлено, что в ближайшее время выйдет новая версия Double-Take Virtual Recovery Assistant с поддержкой Hyper-V. Не менее значимым является разработка GeoCluster с поддержкой Windows Server 2008 failover clustering и Hyper-V. Double-Take GeoCluster позволяет настроить репликацию на уровне блоков данных для двух систем хранения,или даже двух локальных дисков, позволяя легко строить кластеры, не имеющие единой системы хранения данных — что значительно снижает стоимость построения отказоустойчивого решения и позволяет избежать наличия единой точки отказа.
Согласно проведенному компанией «ESG Research» исследованию The Impact of Server Virtualization on Storage, 69% участников опроса заинтересованы в рассмотрении, тестировании и внедрении решения виртуализации на платформе Microsoft. Очевидно, что дополнительные возможности, предлагаемые партнерами, только улучшат пакет предлагаемых решений на основе Hyper-V.
Компания Double-Take давно известна на своем рынке, имеет хорошую историю партнерства с Microsoft, так что к ее решениям мы обязательно вернемся. Я планирую создать стенд, написать цикл статей и провести демонстрацию для партнеров в Москве, возможно с веб-трансляцией на TechNet, где рассказать о том, как следует строить территориально распределенные кластеры. В ближайшее время я опубликую информацию по построению кластеров на основе аппаратных решений крупнейших производителей SAN, с которыми мне удалось поработать — компаний HP и Hitachi Data Systems. Мы рассмотрим, как строятся территориально распределенные кластеры с реплицируемым хранилищем данных на Windows Server 2008. Впоследствии я рассчитываю рассмотреть аналогичный сценарий при использовании программных средств репликации, поставляемых компаниями Double-Take и Symantec.
Мы рассмотрели всевозможные тонкости лицензирования ОС для виртуальных сред. Теперь пора обсудить лицензирование серверных приложений — таких как Exchange, SQL, MOSS, BizTalk и прочих. Серверные приложения Microsoft с точки зрения лицензирования подразделяются на две группы: лицензируемые на «сервер/CAL» (Server/CAL) и лицензируемые «на процессор» (Per Processor). Для каждой версии ПО могут существовать некие тонкости, так что следует обязательно изучить документ «Лицензионные права на использование продукта Microsoft» (Microsoft Licensing Product Use Rights) перед планированием закупки лицензий.
Модель лицензирования ПО на «сервер/CAL»
Как и в случае с ОС, мы лицензируем лишь запущенные экземпляры ПО. Каждая лицензия на серверное ПО, купленная вами и привязанная к физическому серверу, позволяет вам в любой момент времени иметь один экземпляр серверного ПО, запущенного в ОС физического сервера или одной из виртуальных машин на этом сервере. При этом надо понимать, что незапущенным является экземпляр, который установлен внутри выключенной на данный момент ВМ. Но даже пассивный узел кластера считается запущенным экземпляром — как ОС, так и серверного ПО — и подлежит лицензированию (за одним исключением, о котором пойдет речь ниже).
Знаете ли вы о том, что лицензия на SQL Server 2005 Enterprise Edition позволяет одновременный запуск нескольких экземпляров на одном физическом сервере при лицензировании «Server/CAL»? Для каждого сервера, к которому вы привязали лицензию, вы имеете право на использование неограниченного числа экземпляров SQL Server 2005 Enterprise в ОС физического сервера и/или любом количестве виртуальных машин на этом сервере. Для SQL Server 2005 Standard / Workgroup вы имеете право на использование неограниченного числа экземпляров SQL Server 2005 Standard / Workgroup в ОС физического сервера или одной виртуальной машине на этом сервере. Довольно простая модель, не правда ли?
Модель лицензирования ПО «Per Processor»
Данная модель несколько более сложна при лицензировании в виртуальной среде. Следует корректно выполнить три шага:
Когда вы приобрете данное количество лицензий вы получите право на использование любого количества экземпляров лицензируемого серверного ПО в ОС физического сервера и/или в виртуальных машинах на этом сервере.
Из всех правил существуют исключения, так что и здесь есть радостная новость для заказчиков. Для SQL Server 2005 Enterprise Edition и BizTalk Server 2006 Enterprise Edition (а также, видимо, для будущих версий этих продуктов) при лицензировании «Per Processor» учитываются только физические процессоры. То есть если у вас есть восьмипроцессорный сервер и, например, четыре четырехпроцессорных виртуальных машины с запущенным серверным ПО, вам потребуется приобрести лишь восемь процессорных лицензий. При использовании SQL Standard сохраняется обычная модель, которая представлена на рисунке выше.
Кстати, для SQL Server 2005 (Workgroup / Standard / Enterprise) есть еще одно упрощение. Лицензирование для кластеров с переходом по отказу (failover clusters) не требует от вас оплачивать лицензии для серверного ПО, установленного на пассивном узле кластера. То есть, лицензировав SQL Server не сервере А и имея там набор запущенных экземпляров SQL Server, вы имеете право держать на сервере Б (или в виртуальной машине на сервере А или Б) те же экземпляры SQL Server в пассивном состоянии без необходимости их дополнительного лицензирования. Это правило касается SQL Server лицензированного как на «сервер/CAL», так и «Per Processor».
Мы рассмотрели общие вопросы лицензирования серверных продуктов Microsoft в виртуальных машинах. В завершающей статье цикла я планирую обсудить вопросы лицензирования продуктов линейки System Center.
На праздниках стала доступна предварительная версия Microsoft Assessment and Planning Toolkit 3.1. Зарегистрироваться и скачать ее может каждый желающий с сайта Connect (требуется Live ID).
Если вас интересует возможность обновления ОС на серверах до Windows Server 2008 или целесообразности установки Windows Vista на рабочих станциях, если вам важно, какие серверные роли, антивирусные средства или настройки Windows Firewall присутствуют на ваших серверах и рабочих станциях, если вы заинтересованы в консолидации серверов или приложений при помощи Hyper-V, VS2005 или SoftGrid, то Microsoft Assessment and Planning — это то, что вам нужно. MAP представляет собой очередной Solution Accelerator, призванный облегчить ряд задач администратора. Установки агентов на рабочие станции и серверы не требуется, все делается удаленно. Основной список задач (взят из пресс релиза):
Microsoft Assessment and Planning Toolkit умеет генерировать отчеты на разных языках. В настоящее время поддерживаются английский, немецкий, испанский, португальский, французский, японский и корейский. Работы над поддержкой русского языка ведутся!
Процедура использования довольна проста. Администратор устанавливает MAP на свой компьютер, запускает его с правами, достаточными для удаленного управления необходимыми рабочими станциями и серверами, MAP собирает информацию без установки дополнительного ПО на инвентаризуемые компьютеры и готовит отчет.
В отчет попадает та информация, которую вы запрашивали, — о готовности серверов, клиентов, устройств и приложений к миграции и консолидации. Формат выдаваемого отчета — Word или Excel удобен для представления руководству для принятия решения.
Детальные отчеты в форматах Excel и HTML помогают администраторам грамотно планировать предстоящую миграцию и анализировать текущую конфигурацию.
Более подробно про MAP можно почитать на официальной странице или в документации продукта. Если будет интерес к данной теме, я расскажу про специфику использования MAP для консолидации серверов с Hyper-V.
Сегодня утилита VRMCPlus обновилась до версии 1.8.0. Основное нововведение — поддержка обновления KB948515 для Virtual Server 2005 R2 SP1. Изначально предполагалось, что файлы этого обновления будет иметь номер сборки 1.1.627.0. Однако в последний момент перед официальной публикацией команда Virtual Server изменила номер сборки на 1.1.629.0. Поэтому предыдущая версия VRMCPlus 1.7.0, рассчитывающая именно на сборку 1.1.627.0, при подключении к обновленному Virtual Server выдает предупреждение о неподдерживаемой конфигурации. В версии 1.8.0 это исправлено.
Кроме того, новая версия содержит небольшие исправления. Например, стала работать функция запуска виртуальной машины в контексте учетной записи в System (сброс флажка «Run VM under user account»). Несколько изменился интерфейс управления дисками с отменой (Undo). На мой взгляд, стало более удобно и логично.
Загрузить VRMCPlus 1.8.0 из Microsoft Download Center: x86, x64.
На прошлой неделе мы обсуждали различные сценарии поддержки ОС и продуктов Microsoft, запущенных на виртуальных платформах Microsoft и других компаний. Тема вызвала очень бурную дискуссию в комментариях и по почте, что доказывает — заказчикам действительно важна поддержка Microsoft. На сегодняшний день на рынке представлено довольно большое количество различных платформ виртуализации, имеющих свои сильные и слабые стороны, различный функционал и стоимость. Операционные системы Microsoft, запущенные в виртуальных машинах, сегодня поддерживаются лишь на платформах виртуализации Microsoft и тех поставщиков, которые заключили с Microsoft соглашение о взаимной поддержке. По состоянию на начало июня 2008 года в списке таких поставщиков значилась одна лишь Novell, что не очень отражало ситуацию на рынке.
Еще в ноябре 2007 на TechEd в Барселоне было заявлено о скором запуске Server Virtualization Validation Program. Приняв участие в этой программе, пройдя необходимые тесты совместимости и предоставив необходимую документацию, производитель платформ виртуализации может заключить с Microsoft соглашение о взаимной поддержке заказчиков. Согласно такому соглашению, пользователь Windows Server (или другой поддерживаемой в рамках соглашения ОС), запущенной в виртуальной машине на сторонней платформе, может обратиться за поддержкой как к поставщику платформы, так и в Microsoft — и, начиная с первой линии поддержки, он будет получать ответы на свои запросы вне зависимости от точки входа запроса. Соглашение дает право воспользоваться как обычной Cлужбой поддержки (Product Support Services — PSS), так и Premier-поддержкой при наличии соответствующего договора. При этом уже отсутствуют ограничения и требования воспроизведения проблемы на физическом оборудовании
За восемь месяцев, прошедших с момента объявления программы, ряд поставщиков сделал вывод о том, что его заказчикам может потребоваться поддержка Microsoft, и решил участвовать в Server Virtualization Validation Program. И вот 10 июня 2008 года на TechEd в Орландо было объявлено об официальном запуске программы. В ней могут принимать участие поставщики, чья платформа виртуализации успешно проходит ряд тестов на совместимость с ОС Windows Server 2008, Windows Server 2003 c Service Pack 2 и Windows 2000 Server с Service Pack 4. Для тех платформ, которые успешно пройдут такую проверку, поддержка Microsoft будет оказываться так же, как и в случае использования ОС на физическом оборудовании. В программе могут принимать участие как платформы на базе гипервизора, так и платформы, эмулирующие оборудование и запускающиеся поверх основной ОС. Изменения в поддержке коснутся лишь указанных выше операционных систем, но не клиентских ОС и не приложений.
На данный момент в программе принимают участие следующие производители платформ виртуализации:
Если вашего поставщика нет в этом списке — обратитесь к нему с вопросом или подумайте о смене платформы виртуализации, если поддержка Microsoft для вас важна. Подробности и обновленный список всегда доступны на странице программы.
Пару дней назад на сайт Microsoft Connect было выложено долгожданное обновление для System Center Virtual Machine Manager 2008. Как мы уже сообщали, сейчас этот продукт находится в стадии разработки. Но до недавнего времени перспективу экспериментов омрачал тот факт, что текущая (и единственная) общедоступная бета-версия SCVMM несовместима с текущими сборками Hyper-V — RC1 и далее. И вот теперь наконец вы можете попробовать в деле полную связку технологий виртуализации Microsoft — SCVMM 2008 с Hyper-V — а также, при необходимости, и Virtual Server 2005. На тот случай, если вы этого ещё не успели заняться этим вплотную — позволю себе дать здесь несколько советов.
Данное обновление обеспечивает работу текущей бета-версии SCVMM как с Hyper-V RC1, так и с более поздними сборками — в том числе, и окончательной версией, выход которой уже совсем не за горами. Что же касается выпусков самого VMM, то до появления окончательной версии (которая сейчас планируется ориентировочно на август этого года) ожидается появление ещё одной общедоступной предварительной версии.
Существует набор правил по привязке и переносу лицензий между серверами. Давайте рассмотрим эти правила.
Привязка лицензии. «Привязать лицензию к серверу» просто означает выделить лицензию конкретному устройству. Цель такой привязки — избежать разделения лицензии между разными устройствами в момент времени. После привязки лицензии сервер становится лицензированным.
Перепривязка лицензии. Вы можете перепривязать лицензию на ПО к другому серверу, но нельзя делать это на короткий период времени. Повторно перепривязать эту лицензию к другому устройству станет возможно лишь через 90 дней после последней привязки. Вы имеете право перепривязать лицензию ранее, если отказываетесь от данного лицензированного сервера из-за аппаратной поломки. Когда вы перепривязываете лицензию, сервер, получающий эту лицензию, становится новым лицензированным сервером для данной лицензии.
Хранение экземпляров. Если сервер является лицензированным, то хранение незапущенных экземпляров ОС Windows Server и другого серверного ПО Microsoft на нем не требует отдельных лицензий. Права на использование разрешают хранить неограниченное число экземпляров по каждой лицензии. Вы также можете хранить экземпляры на сетевом хранилище (SAN) без необходимости докупать дополнительные лицензии. При этом хранимые экземпляры могут использоваться различными лицензированными устройствами.
Технологии виртуализации позволяют динамично перемещать экземпляры между устройствами. И платформы виртуализации зачастую не принимают в расчет требования лицензирования. То есть с точки зрения лицензионной чистоты вам необходимо отслеживать количество запущенных экземпляров в каждый момент времени на каждом сервере. Ваша задача также — не допустить использование экземпляров на нелицензированном устройстве, так как показано на рисунке:
Издание Windows Server Datacenter дает вам неограниченные права на виртуализацию (если вы лицензировали все физические процессоры сервера). И если вы лицензируете все свои серверы по лицензии Datacenter, у вас не будет необходимости считать количество запущенных экземпляров ОС на каждом сервере в момент времени — так как у вас будет право запускать любое количество экземпляров на любом сервере. Как получить лицензию Datacenter? Если вы используете Windows Standard Server или Windows Enterprise Server, и у вас есть Software Assurance, то вы имеете право перейти к использованию издания Datacenter, доплатив разницу в стоимости лицензий.
Частые ошибки и предположения о виртуализации — все нижеперечисленные рассуждения неверны.
В следующей части поговорим о лицензировании серверных приложений в виртуальной среде.
В своей вводной статье о модели делегирования прав в Hyper-V я рассказал об основных элементах модели Authorization Management Framework, их взаимосвязях — и о том, как делегировать права пользователю на определенные действия. По умолчанию Authorization Manager хранит настройки в локальном файле %programdata%\Microsoft\Windows\Hyper-V\InitialStore.xml. Однако есть возможность хранить эти настройки не на каждом узле, а централизованно: в Active Directory или базе данных Microsoft SQL Server. Сегодня мы поговорим о том, как создать хранилище Authorization Management в Active Directory, как управлять им и как настроить серверы Hyper-V на его использование.
Сразу замечу — для того, чтобы создать в Active Directory хранилище AzMan, ваш домен должен работать на функциональном уровне не ниже Windows Server 2003. Authorization Management Store находится в конфигурации домена, поместить его в отдельный application partition невозможно. Итак, рассмотрим основные шаги, необходимые для централизации настроек делегирования Hyper-V.
Создание хранилища AzMan
Хранилище AzMan создается в контейнере Program Data вашего домена. Например, для домена test.com полный путь (DN) хранилища AzMan Store может быть таким: CN=VmAzStore,CN=Virtualization,CN=Microsoft,CN=Program Data,DC=test,DC=com (имя самого контейнера вы можете задать любое. Подробнее про хранилища AzMan следует почитать на TechNet).
Я не буду описывать процедуры создания хранилища AzMan Store вручную, так как его нужно не только создать, но и заполнить объектами, описывающими элементы модели. Проще сделать это сценарием, импортировав настройки из локального файла в формате XML. Сам сценарий я прилагаю к статье, а ниже опишу, как им пользоваться.
Делегирование прав на хранилище AzMan
Серверы Hyper-V должны обращаться к хранилищу AzMan для проверки прав доступа пользователей. Служба VMMS работает в контексте Local System. Следовательно, к контейнеру AzMan Store в домене серверы будут обращаться в контексте доменных учетных записей компьютеров. Для этого с помощью консоли AzMan.msc необходимо учетным записям узлов, которые будут использовать данное хранилище, делегировать роль Reader на контейнер.
Настройка самих серверов на использование внешнего хранилища AzMan
После того, как мы создали и наполнили объектами AzMan Store в Active Directory и делегировали серверам права чтения этой информации, следует настроить серверы на использование этого хранилища. Настройки того, к какому хранилищу AzMan будет обращаться сервер, хранятся в параметре реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\Virtualization\StoreLocation (тип REG_SZ). В значении этого параметра следует указать полный путь к хранилищу AzMan. Путь к хранилищу в домене выглядит примерно так: msldap://CN=VmAzStore,CN=Virtualization,CN=Microsoft,CN=Program Data,DC=test,DC=com.
Для того, чтобы настройка вступила в силу, потребуется перезапустить службы VMMS и NVSPWMI или перезагрузить сервер.
Пример выполнения описанных настроек
Шаги ниже приводятся лишь для демонстрации работы описанного выше метода.
cscript CreateVmAzStore.js "msxml://C:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xml" "msldap://CN=VmAzStore,CN=Microsoft,CN=Program Data,DC=test,DC=com"
Для автоматизации настройки нескольких серверов Hyper-V я написал административный шаблон, который можно использовать в групповой политике для настройки путей к хранилищам AzMan. Этот шаблон прилагаю к статье. Так как ветвь реестра HKLM\Software\Microsoft\Windows NT является «неуправляемой» (Unmanaged), то в случае редактирования политик на Windows XP/2003 в редакторе политик следует в меню View/Filtering отключить фильтрацию только управляемых (Managed) политик. Ниже следует код шаблона — сохраните его в текстовом файле с расширением «.adm».
;;;;;;;AzMan.adm;;;;;;;;;;;Alex A. Kibkalo;;;;;CLASS MACHINE ;;;;CATEGORY !!VmAzStore POLICY !!SetVmAzStore KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Virtualization" EXPLAIN !!VmAzStoreExpl PART !!VmAzStorePath EDITTEXT DEFAULT !!DefaultVmAzStoreXML VALUENAME "StoreLocation" END PART END POLICYEND CATEGORY [strings] VmAzStore="Autorization Manager"SetVmAzStore="Set AzMan Store"VmAzStorePath="Path to AzMan Store"DefaultVmAzStoreXML=msxml://C:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xmlVmAzStoreExpl="Here you set the location of AzMan store for Hyper-V host. Default value is: msxml://C:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xml If you install SCVMM agent, the path to XML file changes to msxml://C:\ProgramData\Microsoft\Virtual Machine Manager\HyperVAuthStore.xml If you set up AzMan Store in Active Directory and delegated hosts the Reader role, you may specify the Active Directory path like this: msldap://CN=VmAzStore,CN=Microsoft,CN=Program Data,DC=test,DC=com." ;;;;End of template;;;;;
;;;;;;;AzMan.adm;;;;;;;;;;;Alex A. Kibkalo;;;;;CLASS MACHINE ;;;;CATEGORY !!VmAzStore POLICY !!SetVmAzStore KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Virtualization" EXPLAIN !!VmAzStoreExpl PART !!VmAzStorePath EDITTEXT DEFAULT !!DefaultVmAzStoreXML VALUENAME "StoreLocation" END PART END POLICYEND CATEGORY
[strings]
VmAzStore="Autorization Manager"SetVmAzStore="Set AzMan Store"VmAzStorePath="Path to AzMan Store"DefaultVmAzStoreXML=msxml://C:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xmlVmAzStoreExpl="Here you set the location of AzMan store for Hyper-V host. Default value is: msxml://C:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xml If you install SCVMM agent, the path to XML file changes to msxml://C:\ProgramData\Microsoft\Virtual Machine Manager\HyperVAuthStore.xml If you set up AzMan Store in Active Directory and delegated hosts the Reader role, you may specify the Active Directory path like this: msldap://CN=VmAzStore,CN=Microsoft,CN=Program Data,DC=test,DC=com."
;;;;End of template;;;;;
К выходу окончательной версии Hyper-V на TechNet должна появиться подробная статья на эту же тему. Я дам на нее ссылку и обновлю свою версию.
Виртуальные машины Hyper-V используют архитектуру синтетических устройств (в отличии от эмулированных устройств в VS2005). Это позволяет добиться серьезного увеличения производительности виртуальных машин, однако у администратора появляется новая головная боль — необходимость установки компонентов интеграции (Integration Components) в гостевой ОС. Без компонентов интеграции гостевая ОС не сможет работать с виртуальными контроллерами SCSI, синтетическим сетевыми адаптерами, а указатель мыши будет «застревать» в окне «Virtual Machine Connection» до нажатия специальной комбинации клавиш.
Если вам необходимо в виртуальной машине загрузиться в WinPE для проведения установки или восстановления системы, вам наверняка потребуется использовать компоненты интеграции и в этой среде. Очевидно, что для нормального использования WinPE в Hyper-V потребуется создать загрузочный образ WinPE со встроенными компонентами интеграции.
Для начала — краткое введение для тех, кто незнаком с WinPE. Windows Preinstallation Environment (Windows PE) — это минимальная операционная система, созданная для подготовки вашего компьютера к установке Windows. WinPE может быть использована на компьютере без операционной системы для загрузки с компакт диска — например, в целях разметки жесткого диска и создания разделов или для копирования необходимых файлов и запуска установки Windows с сетевого ресурса.
Windows PE в качестве отдельного продукта доступна в рамках некоторых схем корпоративного лицензирования. На основе WinPE построено множество различных средств установки и восстановления Windows, включая сам установщик Windows Vista, Server 2008 и Windows Deployment Services (WDS). Последняя доступная в данный момент версия — Windows PE 2.1 — основана на ядре Windows Vista с Service Pack 1 / Windows Server 2008.
Итак, для создания дистрибутива WinPE со встроенными компонентами интеграции Hyper-V нам потребуется выполнить несколько несложных шагов. Перед тем, как приступить к описанию процесса, замечу, что данный способ не поддерживается Microsoft и предлагается вам для самостоятельного использования.
В результате вы получите образ компакт-диска с WinPE. Для загрузки с него подключите образ к CD-ROM в свойствах виртуальной машины, убедитесь, что в BIOS разрешена загрузка с CD и включите машину. После этого вам должны быть доступны все синтетические устройства из WinPE.
P.S. Для старых версий WinPE последовательность немного отличается. Но я не вижу смысла их использования, поэтому не стану углубляться в это.
P.P.S. Пример сценария прилагаю для 64-битной версии WinPE. 32-битную версию при необходимости сделайте сами.
P.P.P.S. Мой пример с Hyper-V RC1 не отличается от предварительных или будущей окончательной версии ничем — кроме имени файла с обновлением. Однако я надеюсь, что вместе с оконательной версией Hyper-V выйдут интегрированные версии Windows Server 2008 и AIK. Соответственно, обновится версия WinPE.
Разных заказчиков интересуют разные вопросы, но один из них всегда остается в первой тройке. Это вопрос о поддержке ОС и ПО Microsoft в средах виртуализации — Virtual PC, Virtual Server 2005, Hyper-V и платформах третьих фирм. Вопрос достаточно тонкий и сложный, но очень важный для клиентов. Давайте в нем попробуем разобраться.
О поддержке ОС
Говоря поддерживаем, я имею в виду именно английское значение слова support так, как его трактует Microsoft. Поддержка реализуется как обычными Службами поддержки (PSS), так и службой Премьер поддержки (Premier support) — для тех заказчиков, которые ее купили. Поддержка ОС и продуктов осуществляется в течении жизненного цикла продуктов. То есть Windows 2000 Server через пару лет выйдет из поддержки, и это коснется эксплуатации и в Hyper-V, и в Virtual Server 2005.
Начнем с Hyper-V. Здесь читателям моего блога все уже известно. На платформе Hyper-V мы поддерживаем следующие ОС в виртуальных машинах:
Virtual Server 2005 поддерживает 32-битные версии следующих ОС:
Virtual PC:
Теперь поговорим о сторонних средствах виртуализации (Xen, VMware, Parallels, и.т.д.). Во-первых, заявление. Microsoft поддерживает свои ОС и приложения только на тех сторонних платформах виртуализации, с производителями которых заключено соответствующее соглашение о поддержке. Посмотреть список можно тут. Из короткого списка видно, что данное соглашение заключено лишь с Novell (Некоторые версии Linux, имеющие виртуализацию Xen).
Соответственно, следует отличать заявления производителя платформы о поддержке ОС этой платформой от заявлений Microsoft о поддержке ОС на этой платформе. Я не люблю кидать камни в чужой огород — но здесь идет речь в основном о VMware, которая поддерживает большой список ОС, 70% которых уже не поддерживаются производителем ОС. То есть данные ОС запускаются на сторонней платформе виртуализации, а остальное производителя данной платформы не интересует.
Со стороны Microsoft могу предупредить заказчика, что если у вас не приобретена Premier-поддержка, то в случае возникновения любых вопросов по ОС или продуктам Microsoft, которые установлены на платформе виртуализации, не имеющей с Microsoft соглашения о поддержке, PSS первым делом потребует от вас воспроизвести проблему на физическом оборудовании. Если вы имеете Premier-поддержку, то инженер готов попробовать решить проблему на вашем стенде или повторить ситуацию на физическом оборудовании. Если воспроизвести ситуацию на оборудовании инженеру не удастся — это станет вашей задачей. Именно это я называю глобальным отличием между поддержкой производителя продуктов и списком продуктов, поддерживаемых платформой.
О поддержке многопроцессорности в виртуальных машинах
Я уже неоднократно обращал внимание на то, что Hyper-V поддерживает до четырех виртуальных процессоров в Windows Server 2008 (x86 и x64), один или два виртуальных процессора в Windows Server 2003 (x86 и x64). Windows Vista SP1 (x86 и х64), Windows XP SP2/SP3 (x86 и x64) и лишь один виртуальный процессор в Windows 2000 Server/Advanced Server и SLES 10.0 SP1/SP2 (x86 и x64). Я не зря опять выделил слово поддерживает, поскольку виртуальные машины с таким числом процессоров на платформе Hyper-V могут получать полную поддержку в PSS и Premier Support.
При этом вы можете установить в свойствах любой виртуальной машины 1, 2 или 4 виртуальных процессора, и ВМ будут работать даже с четырьмя процессорами. Такая конфигурация не является официально поддерживаемой, поскольку к выходу Hyper-V ее не успевают оттестировать. К выходу Windows Server 2008 SP2 обязательно будет обновление, расширяющее списки поддерживаемых конфигураций.
Что это означает для заказчика? Вы можете установить и использовать свои ВМ на четырехпроцессорной платформе. Если у вас возникнут проблемы, требующие обращения в техническую поддержку Microsoft, вы элементарно изменяете количество процессоров в свойствах виртуальной машины и общаетесь с поддержкой. Согласитесь, это на порядок проще варианта с переустановкой конфигурации на физический сервер в случае возникновения таких проблем на сторонней платформе виртуализации.
Здесь я хотел подчеркнуть большую разницу между поддерживаемыми многопроцессорными конфигурациями в Hyper-V (который входит в стоимость ОС), неподдерживаемыми, но рабочими конфигурациями в Hyper-V (также бесплатно в составе ОС и легко приводится к поддерживаемой конфигурации) и многопроцессорными конфигурациями, которые поддерживаются той же VMware и требуют переразвертывания системы на физические серверы при желании обратиться в поддержку Microsoft.
О поддержке программного обеспечения Microsoft в виртуальных машинах
Мы рассмотрели варианты поддержки гостевых ОС в виртуальных машинах разных платформ. Теперь пора поговорить о приложениях. Здесь разговор будет более коротким. Два года назад в Microsoft принят стандарт Common Engineering Criteria, требующий от каждого серверного продукта Microsoft возможности (и поддержки) работы на платформах Virtual Server 2005 и Hyper-V. Очевидно, что часть продуктов требует 64-битную ОС (Exchange 2007) и на Virtual Server даже не тестировалась. Часть продуктов не проходит первичного тестирования на виртуальных машинах (ISA Server, компоненты Exchange Server и Office Communication Server, отвечающие за Unified Communications), и группа разработки конкретного продукта может заявить об отсутствии его поддержки на виртуальных машинах Microsoft.
Как и в случае с ОС, на сторонних платформах виртуализации поддержка осуществляется также лишь при наличии договора о поддержке (то есть в версиях Linux от Novell с виртуализацией Xen). Никакие продукты Microsoft не поддерживаются на других платформах. При наличии Premier-поддержки, Microsoft примет некие усилия для попытки повторить вашу ситуацию на своих стендах (виртуализация Microsoft или аппаратная платформа). Если попытка не удастся, вам потребуется самостоятельно воспроизвести проблему вне неподдерживаемой платформы виртуализации.
На этом сегодня мы заканчиваем сложную тему разницы в поддержке и… поддержке. Принимайте правильное решение, если вам важна поддержка Microsoft.
Я всегда слыл маньяком в области сертификации MIcrosoft — хобби такое у меня, экзамены сдавать. Только Transcript насчитывает почти семь десятков сданных, а там еще и не все учитывается (у меня два MCP ID). Причем последние лет пять все экзамены я сдаю в бета-версиях — как правило, бесплатно. Обычно по понедельникам я нахожу время пробежаться по списку бета-версий экзаменов на сайте Prometric — так как даже внутри Microsoft информация о появлении беты экзамена может запросто появиться за пару дней до окончания трехнедельного срока, за который его можно было попробовать сдать.
Итак, сегодня в списке экзаменов был обнаружен 71-652 — TS: Windows Server Virtualization, Configuring. Традиционно, номер 70-xxx обозначает общедоступные экзамены, 71-xxx — их бета-версии, а 74-xxx — те же экзамены по льготным ценам для студентов IT Academy. Сдавая беты экзаменов, вы обычно получаете больше вопросов, чем будет в окончательной версии. Каждый вопрос вы при желании можете прокомментировать. 10% наиболее сложных и наиболее простых вопросов по результатам тестирования убираются из списка наряду с выявленными некорректными вопросами. По окончанию обработки результатов тестирования проводится callibration meeting, на котором устанавливается проходной балл экзамена. (Для сдачи абсолютного большинства экзаменов требуется набрать 700 баллов). Если ваш результат при сдаче бета-версии превышает этот порог, то вам засчитывается этот экзамен. И в день выхода окончательной версии под номером 70-xxx этот результат появляется в транскрипте и, если сданный экзамен дает вам некий новый статус, вы получаете свой сертификат как Charter Member (один из первых пяти тысяч обладателей сертификата). С момента окончания бета-тестирования экзамена до выхода окончательной версии обычно проходит 10-12 недель, хотя известны случаи увеличения этого промежутка до 16-20 недель.
Бета-версию можно заказать в любом учебном центре точно так же, как обычный экзамен, а если у вас есть промо-код — вы можете воспользоваться им для того, чтобы не платить за сдачу. Коды иногда публикуются в MCP/MCT Newsletter, а также вы можете узнать их у более опытных товарищей. Код единый для всех, но работает только для 1500 первых зарегистрировавшихся. При этом правила разрешают передачу промо-кодов заинтересованным лицам.
К чему я написал такое большое отступление? Увы, о бета-экзаменах Microsoft нечего более рассказать. Страница с описанием экзамена и требованиями к сдаче на данный момент отсутствует, ее заполнят ближе к выходу окончательной версии. Конкретно рассказать о вопросах я тоже не могу — экзамен буду сдавать в пятницу вслепую, да и правила это запрещают. Известно лишь, что срок действия бета-версии истечет 23 июня. Призываю заинтересованных проявить сознательность и сдать этот экзамен в бета-версии :)
P.S. Если кому то интересен мой MCP Transcript, его можно посмотреть тут: http://www.microsoft.com/learning/mcp/transcripts, ID: 655758, Password: Microsoft.
Update: Добавил во вложение программу экзамена.