Russian Windows Virtualization Discussion

Увеличение размера виртуального диска не приводит к автоматическому изменению размера тома

Наверняка многие из вас сталкивались с тем, что выделенный ранее размер виртуального диска (VHD) стал недостаточен для нужд вашей виртуальной машины. Это может касаться как о расширяемых (Dynamically Expanding), так и о дисках фиксированного объема (Fixed Size). Выходов из подобной ситуации немного — увеличить размер имеющегося диска или добавить новый. Первый вариант обычно оказывается предпочтительнее. В отличие от физических жестких дисков, для виртуальных это не составляет никакой проблемы. Достаточно в консоли Hyper-V Manager выбрать операцию Edit Disk, указать нужный файл и увеличить его размер при помощи команды Expand. Понятно, что диск в этот момент не должен использоваться виртуальными машинами. Однако, запустив виртуальную машину после описанной процедуры, вы обнаружите, что объем доступного системе места не изменился.

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.

Hyper-V и расширенное управление питанием. Функции Sleep и Hibernate

Очевидно, что Hyper-V разрабатывался для использования преимущественно на серверах и своей архитектурой предполагает именно серверные сценарии работы. Также очевидно, что на физических серверах в промышленной среде вы навряд ли используете энергосберегающие состояния — сна (sleep) или гибернации (hibernate). Однако я сам, как и многие из моих коллег, предпочитаю использовать серверную операционную систему на домашнем компьютере и даже на ноутбуках. Ведь возможность интерактивной демонстрации работы продукта на переносимом стенде — большое преимущество при продаже решения. Да и работа с лучшей технологией виртуализации для Windows на собственном ноутбуке также является хорошим подспорьем для технического специалиста. Если перечисленные сценарии затрагивают и вас — то вы, наверное, уже знаете, что при установке роли Hyper-V на Windows Server 2008 отключаются функции расширенного управления питанием. В частности, пропадает возможность просто закрыть ноутбук с расчетом на то, что он «заснёт» или сохранит своё состояние в режиме гибернации. Цель сегодняшней заметки — рассказать о том, как можно использовать Hyper-V на ноутбуке, не лишаясь при этом возможностей закрыть ноутбук, не задумываясь о том, что он «не заснёт» и посадит вам всю батарею за пару часов.

Почему при копировании виртуальной машины не сохраняются сетевые настройки?

За последние пару месяцев мне несколько раз задавали вопрос, почему при копировании виртуальной машины сбрасываются настройки сетевых интерфейсов. Если честно, изначально я не придавал ему большого значения, но когда он прозвучал из нескольких независимых источников — я решил разобраться. В Virtual Server 2005 мы просто копировали файлы виртуальных дисков (VHD) и настроек виртуальных машин (VMC) на любой другой сервер, или даже просто создавали новую ВМ на основе старого VHD диска — и все старые сохранялись. В Hyper-V для этого потребуется экспортировать виртуальную машину отдельной командой, а затем импортировать ее соответствующим образом. Но иногда этой процедурой приходится пренебречь и просто скопировать файл виртуального диска. Например, когда этот файл вам передали на внешнем носителе, не экспортировав предварительно ВМ. Что же произойдет в этом случае? Вы создадите новую ВМ, включите ее, она загрузится — но все сетевые настройки: адрес IP, серверы WINS и DNS, суффикс подключения будут потеряны. Почему это происходит? Сразу скажу, новая модель безопасности и изоляции ВМ в Hyper-V тут ни при чем. Подумайте — что будет, если вы в физическом сервере замените сетевую карту? Или даже перенесете жесткий диск в другой сервер — что, собственно, и происходит при создании новой ВМ на основе имеющегося файла виртуального диска. Вот тут-то и зарыта собака! Случится то же самое: потеряются настройки подключения. Ведь изменится GUID сетевой карты, и для нового устройства ОС создаст новое подключение. Давайте разберемся, что с этим можно сделать, куда исчезает старое подключение, исчезает ли вообще и можно ли вернуть настройки обратно.

Hyper-V и производительность. Часть 6 — расчет загрузки процессора виртуальными машинами при помощи WMI

Часто задаваемый в последнее время вопрос — как получить формулу загрузки ресурсов процессора виртуальными машинами Hyper-V при помощи WMI или PowerShell. Я приведу некоторые выкладки с примерами расчета и опишу способ вычисления через WinRM (WMI). Мой пример для вычисляет загрузку процессора гостевыми ОС, то есть использует экземпляр счетчика PercentGuestRunTime. Вы можете с легкостью вычислить другие показатели нагрузки — «% Total Run Time», «% Hypervisor Time» и «% Idle time». Данные экземпляры счетчика в WMI объекте Win32_PerfRawData_HvStats_HyperVHypervisorLogicalProcessor называются не «PercentGuestRunTime», а соответственно «PercentTotalRunTime», «PercentHypervisorRunTime» и «PercentIdleTime».

Hyper-V и производительность. Часть 1 — как тестировать?

Обычно перед принятием решения о консолидации серверов в виртуальной среде или миграции с альтернативных платформ на виртуализацию Microsoft требуется провести тестирование производительности работы гостевой ОС и приложений. Сегодня мы немного поговорим о том, что необходимо иметь в виду при подготовке к такому тестированию, как правильно настраивать гостевую ОС и саму виртуальную машину, чтобы получить хорошую производительность. Рассмотрим три главных шага, ведущих к получению достойного результата. Эти шаги следует выполнять не только при тестировании, но и для достижения нужных результатов в эксплуатируемых системах.

Поиск серверов с Virtual Server 2005 и Hyper-V

В крупной сети администратору может быть сложно уследить за всеми серверами и рабочими станциями. Как точно определить, на каких именно машинах установлено ПО виртуализации? Ведь любой пользователь, имеющий достаточно прав на свой компьютер, может установить на него Virtual Server. Сейчас, в свете выхода System Center Virtual Machine Manager 2008, вопрос учета становится еще более актуальным.

Какие порты использует Hyper-V?

Ответим сегодня на часто задаваемый вопрос: «Какие порты необходимы для управления сервером при помощи Hyper-V Manager?». Радовать особенно нечем: 135, 2179, 49512-65535. Да, в MMC используется протокол RPC — а следовательно, требуется динамический набор верхних портов. Windows Server 2008 по умолчанию выделяет 16384 динамических порта. Это, однако, можно изменить.

Создаем ярлыки на конкретную ВМ

Зачастую мы работаем с ограниченным набором виртуальных машин, так что возникает желание обойтись без использования медленной оснастки Hyper-V Manager и подключаться к любимым ВМ напрямую. Так как же создать ярлык на конкретную виртуальную машину, чтобы открывать ее одним щелчком мыши? На данный момент я знаю два способа, основанных на штатной утилите «Virtual Machine Connection» (vmconnect.exe), которая устанавливается вместе с оснасткой Hyper-V Manager. Очевидно, что объект ВМ также можно вызвать через WMI и VBScript, но об этом в другой раз.

Информация о родительской системе в ВМ

Интересно, что гостевые ОС в Hyper-V знают о том, что они виртуальны. Они знают даже адреса NETBIOS и FQDN основного (родительского) сервера, на котором запущены.

Скрытые настройки Hyper-V Manager

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

Настройки параметров загрузки гипервизора при помощи программы BCDEdit

База данных конфигураций загрузки (BCD) содержит настройки, которые определяют — как запускаются ОС Windows Vista и Windows Server 2008. В предыдущих версиях ОС эти настройки указывались в файле текстовом Boot.ini на системном разделе (при использовании BIOS) или в энергонезависимой памяти (NVRAM, при использовании EFI). Сейчас параметры BCD хранятся в файле \Boot\bcd активного раздела (или на системном разделе EFI для систем с поддержкой EFI). Этот файл уже не отредактируешь в Блокноте — и даже те, кто подключат его (или его копию) как куст в реестр, навряд ли смогут уверенно вносить изменения напрямую. Настройка загрузчика Windows, который выполняется до операционной системы, производится утилитой командной строки BCDEdit.exe. Она служит для создания, удаления, редактирования и дополнения записей в хранилище BCD. Программа BCDEdit находится в папке %SysterRoot%\System32. Почему было принято решение о переходе от Boot.ini к BCD?