Russian Windows Virtualization Discussion

Microsoft Deployment Toolkit 2010 — инвентаризация на службе виртуализации

Все большее количество компаний используют виртуальные машины в промышленной среде. Следовательно, нужно задуматься об автоматизации установки ОС в виртуальной среде. Иметь раздельные инструменты для установки ОС на физические и виртуальные серверы выглядит накладным. Значит, универсальные средства установки должны понимать азы технологий виртуализации, различать основные сценарии и уметь оценивать аппаратные требования и возможности. Хороший тому пример — представленный недавно обновленный набор инструментов для развёртывания «Microsoft Deployment Toolkit 2010».

Утилита Microsoft для проверки поддержки Hyper-V на вашей системе

Еще перед выходом первой версии Hyper-V мы обсуждали способы проверки совместимости вашей системы с виртуализацией Microsoft. С тех пор прошло более года, у Microsoft на подходе новое поколение операционных систем, новая версия Hyper-V, а также своя утилита для проверки совместимости. В комплект Windows Logo Kit теперь входит утилита Virtualization Detect Tool (VpDetect.exe), которая по идентификатору процессора (CPUID) и значениям MSR определяет совместимость вашего процессора с технологиями виртуализации Microsoft.

Сравнение подходов к построению кластеров внутри виртуальных машин и выход Windows Storage Server 2008

Известная особенность Hyper-V (включая грядущую вторую версию) — отсутствие возможности создать общее хранилище между несколькими виртуальными машинами. Иными словами, вы не можете подключить один и тот же файл виртуального диска (VHD) к двум одновременно запущенным виртуальным машинам. Зачем это нужно? Пожалуй, есть только один сценарий, который мог бы выиграть от такой возможности. Но этот сценарий очень и очень востребован. Речь пойдёт о кластеризации с переходом по отказу — Failover Clustering. Итак, как же собрать кластер из нескольких виртуальных машин? Однако прежде, чем мы перейдём непосредственно к теме кластеров с переходом по отказу, нам стоит вообще задуматься не только о необходимости такого подхода и различных сценариях его реализации, но и об имеющихся альтернативах. Кластеризация — это традиционный способ повышения доступности какой-либо сетевой службы. Строго говоря, к решению этой задчи существует целых шесть вполне различных подходов, каждый из которых имеет свои особенности, слабые и сильные стороны. И кластеризация из них — способ далеко не единственный и не всегда оптимальный.

Будущее виртуализации в Windows Server 2008 R2. Часть 3

Продолжаем разговор о Microsoft Windows Server 2008 R2, представленной совсем недавно на PDC и WinHEC. Я уже рассказал о том, как изменится функционал одной из серверных ролей, теснее всего связанных с виртуализацией, — кластеров с переходом по отказу (Failover Clustering). Сегодня мы рассмотрим нововведения в самой технологии гипервизора. Поговорим о второй версии Hyper-V, которая будет встроена в новую серверную ОС.

Будущее виртуализации в Windows Server 2008 R2. Часть 1

В продолжение темы о второй версии Hyper-V я решил упорядочить свои полевые заметки о том, чего же стоит ждать от виртуализации в Windows Server 2008 R2. Материала получается довольно много — как с прошедшей Professional Developer Conference (PDC) 2008

Первые заметки о второй версии Hyper-V

Сегодня первый день Professional Developer Conference 2008 — главного мероприятия Microsoft, посвящённого объявлению новых технологий. И наконец в открытых источниках начали появляться первые сведенья о возможностях второй версии Hyper-V. Понятное дело, что список этот ни в коем случае не претендует на завершённость. Ведь во-первых, он всё ещё не был объявлен официально. А во-вторых, что важнее, на текущем этапе разработки проект может претерпеть ещё весьма значительные изменения. Поэтому воспринимайте всё, сказанное ниже, именно как список возможностей, а не чёткие обещания.

Network Teaming для серверов виртуализации Hyper-V. Часть третья — практическая, частный случай. Серверы HP

Сегодня я расскажу о том, создать Network Teaming на примере лезвий HP ProLiant BL460c. Сама настройка в данном случае выполняется очень просто — с помощью мастера и принятия настроек по умолчанию. Поэтому я немного усложнил задачу и собираюсь показать, как настроить конфигурацию с использованием VLAN Tagging в соответствии со стандартом IEEE 802.1q. Согласитесь, это будет весьма полезно для тех случаев, когда предстоит использовать всего два сетевых адаптера, которые встроены в сервер. И при этом хотелось бы получить возможность подключать виртуальные машины в разные сегменты сети. Скажу по секрету — именно такая схема практикуется Microsoft IT для организации внутренней инфраструктуры компании, а также хостинга веб-сайтов TechNet и MSDN (то есть, в промышленной эксплуатации).

Network Teaming для серверов виртуализации Hyper-V. Часть вторая — практическая, общий случай. Адаптеры Broadcom

Вчера мы начали разговор про Network Teaming и пообещали поделиться работающими методами создания отказоустойчивых сетевых подключений. Для начала рассмотрим самый общий случай. В абсолютное большинство современных серверов встроены сетевые адаптеры, основанные на наборе микросхем производства компании Broadcom Corporation. Именно под этим именем определит новое устройство свежеустановленная ОС Windows. Но фирма-производитель сервера иногда дает такому адаптеру свое собственное название, чтобы интегрировать его в свою линейку продуктов. В этом случае драйверы, которые поставляются производителем сервера, будут менять название устройства. И если вы получили сервер с предустановленной операционной системой и драйверами — то можете даже не знать о том, что ваши сетевые адаптеры на самом деле произведены компанией Broadcom. Как бы то ни было, но сегодня речь пойдет именно про такие устройства — вне зависимости от того пути, который они проделали прежде чем попали к вам. Этот способ сработает наверняка на всех серверах, которые используют сетевые адаптеры Broadcom серии 57xx семейства NetXtreme II. Возможно, что это касается и некоторых похожих моделей, которые мы не тестировали.

Network Teaming для серверов виртуализации Hyper-V. Часть первая — теоретическая

Вопрос отказоустойчивости сетевых подключений по праву волнует очень большое число заказчиков. И особенно остро он встает при консолидации большого количества задач на одном физическом сервере — чему и служит виртуализация. И вот на прошедшей неделе эта проблема была поднята в очередной раз. В результате проведения ряда тестов, а тажке обмена опытом с Microsoft IT мы выяснили, что на сегодня ситуация здорово изменилась по сравнению с тем, что мы имели буквально месяц назад. В паре следующих заметок мы подробно рассмотрим несколько конфигураций с использованием тех моделей сетевых адаптеров, которые сейчас встраиваются в абсолютное большинство современных серверов. Эти конфигурации, хотя по-прежнему не поддерживаются, но позволяют получить работающую систему с балансировкой нагрузки и переходом по отказу сетевых подключений на серверах виртуализации Hyper-V.

Ошибка запуска виртуальных машин после установки драйвера Intel IPMI

Те читатели блога, которые подписались на получение комментариев к статьям, на прошлой неделе получили порцию сообщений сильно больше обычной. Причиной послужила длительная переписка с одним из читателей, который столкнулся со следующей проблемой. После установки пакета под названием «Intel Active System Console» версии 3.0 любые попытки запуска виртуальных машин заканчивались ошибкой. Проведенное исследование показало, что проблема заключается в совместимости с Windows Server 2008 драйвера Intel IPMI версии 13.0. Этот драйвер входит как в Intel Active System Console, так и в Intel Active System Monitor. Несовместимость как раз и проявляется в том, что после установки драйвера все виртуальные машины Hyper-V перестают запускаться. При этом выводится ошибка доступа к файлу виртуального диска, которая выглядит следующим образом. В английской версии: The application encountered an error while attempting to change the state of 'VM name' - IDE/ATAPI: Couldn't attach 'path to disk.VHD' to location 0/0 of IDE Controller. Error: 'General access denied error' (0x80070005). Или в русской версии: Приложением обнаружена ошибка при попытке внести изменения состояния «Имя ВМ».

Обновление для поддержки 24 логических процессоров опубликовано для общего доступа

На днях в Центре загрузки появилось обещанное обновление, которое добавляет в Hyper-V поддержку 24 логических процессоров и 192 одновременно запущенных виртуальных машин. Оно не является ни критическим, ни рекомендуемым — поэтому устанавливать его стоит только в том случае, если вам действительно необходимо расширить ограничения возможностей Hyper-V до указанных пределов. Подробная информация об обновлении изложена в статье Базы знаний Microsoft под номером 956710 — «A Hyper-V update is available to increase the number of logical processors and virtual machines on a Windows Server 2008 x64-based computer». Обратите внимание на то, что это обновление вносит изменения не только в родительский раздел. После его установки службы интеграции (Integration Services) в гостевых ОС будут также обновлены. Впрочем, это должно происходить автоматически и прозрачно для пользователя. Другое интересное замечание — если вам необходимо запускать одновременно более 150 виртуальных машин, простой установки обновления всё-таки недостаточно. Помимо этого, потребуется ещё и отредактировать параметр в реестре для того, чтобы удвоить объём оперативной памяти («кучи»), динамически выделяемой каждому рабочему столу неинтерактивного оконного терминала. Детали этой операции описываются в статье Базы знаний.

Hyper-V станет поддерживать 24 виртуальных процессора (и 192 виртуальных машины)

Казалось бы — только неделю назад в Америке прошло торжественное мероприятие, посвящённое запуску разных технологий виртуализации, и все громкие объявления были сделаны именно тогда. Но сегодня Intel представила новую линейку шестиядерных процессоров Xeon на ядре Dunnington. И Microsoft тут же обявила, что Hyper-V сможет использовать все новые ядра в полный рост.

Окончательный выпуск Hyper-V и ограничения конфигураций

Конечно, если кого-то интересует производительность, то какие-либо выводы на этот счёт можно делать только после выхода окончательной версии продукта. Иными словами, сейчас наступает самое время проводить нагрузочное тестирование по всем сценариям, какие подскажет вам фантазия. Многих в этой связи интересует вопрос о максимальных поддерживаемых конфирурациях оборудования для Hyper-V. Эта тема подробно раскрывается в официальной документации — а конкретно, Hyper-V Deployment Guide (Руководстве по развёртыванию Hyper-V). Однако, поскольку этот документ ещё не опубликован, приведу в вольном переводе выдержки из него, касающиеся максимальных конфигураций.

Hyper-V и устройства, использующие порты USB/COM

Вопрос, наболевший для многих, поднимается вновь и вновь: можно ли использовать устройства USB с виртуальными машинами Hyper-V? А устройства, использующие порты COM? Ответ обычно очень неутешителен. По соображениям безопасности серверные решения виртуализации не предполагают работы с такими устройствами. Не существует связки VSP/VSC для шины USB, а также портов COM и LPT. Если для портов COM еще есть обходной путь через именованные каналы (Named Pipes) и Hyper-V это поддерживает, то с USB все мрачно. А даже для серверов часто требуются ключи HASP (привет 1С), криптографические токены для шифрования, считыватели смарткарт, модемы и так далее. И как правило такие устройства работают только через шину USB.

Hyper-V и multimedia: звуковые карты и запись на CD/DVD

Сегодня я хочу предупредить возможные вопросы относительно использования звуковых карт и записи CD/DVD дисков из виртуальных машин. Сразу отмечу, что Hyper-V не виртуализует звуковые карты. Для этого класса устройств не существует связки Virtual Service Provider / Virtual Service Client — и вот почему