Russian Windows Virtualization Discussion

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

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

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».

Сценарии PowerShell для Hyper-V и WMI. Использование компонента интеграции обмена парами ключ-значение (KVP Exchange integration component). Часть 2 — Добавление новых элементов из родительского раздела

В прошлый раз мы рассмотрели «Компонент интеграции обмена парами ключ-значение» (Key Value Pair, KVP Exchange Integration Component). Теперь мы знаем, какие уже есть внутренние (intrinsic) KVP, как получить текущие значения KVP и как их расшифровать. С помощью KVP мы можем из родительского раздела записать ключи в реестр гостевой ОС, а также прочитать в родительском разделе ключи, переданные из гостевого раздела. Это реализуется с помощью метода AddKvpItems класса Msvm_VirtualSystemManagementService. Сейчас мы рассмотрим пример передачи ключей от родительского раздела в гостевые.

Сценарии PowerShell для Hyper-V и WMI. Использование компонента интеграции обмена парами ключ-значение (KVP Exchange integration component). Часть 1 — версия гостевой ОС

Когда Алексей опубликовал вводную заметку о компоненте обмена данными (Data Exchange) из комплекта служб интеграции (Integration Services) Hyper-V, это неожиданно вызвало целый ряд вопросов о том, что же именно можно передавать из родительской системы в ВМ и обратно. Поэтому теперь я собираюсь рассказать об этой возможности подробнее. Официально она называется «Компонент интеграции обмена парами ключ-значение» (Key Value Pair, KVP Exchange Integration Component). Этот компонент реализован в виде службы в гостевой ОС и позволяет передавать некоторую ограниченную информацию из ВМ в родительскую ОС и обратно.

Делегирование прав на Hyper-V. Часть 2 — присвоение области виртуальным машинам

Мы уже обсуждали общие вопросы модели делегирования Authorization Management Framework и Authorization Manager, используемый в Hyper-V. Сейчас пришло время более детально рассмотреть некоторые наиболее насущные вопросы. Большинство заказчиков, которым я рассказываю про модель делегирования в Hyper-V первым делом спрашивают меня, возможно ли делегировать пользователю или группе некоторые права на конкретную виртуальную машину. В Virtual Server 2005 единственным способом предоставления доступа к ограниченному набору ВМ являлось использование NTFS ограничений на конфигурационные файлы, так чтобы пользователи могли работать лишь с теми виртуальными машинами, на которые у них достаточно NTFS прав. Модель, используемая в Hyper-V позволяет настраивать это более гибко.

Делегирование прав на Hyper-V. Часть 1 — Хранение Authorization Management в Active Directory

В своей вводной статье о модели делегирования прав в 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 на его использование.

Определение платформы виртуализации из сценария

Недавно мне понадобился способ, позволяющий отличать виртуальные машины Virtual Server 2005 от виртуальных машин Hyper-V при применении групповых политик. Также возможна ситуация, когда понадобится определить платформу виртуализации для установки программного обеспечения — например, для обновления компонент виртуализации. Возможность узнать из виртуальной машины, какая используется платформа виртуализации, также может потребоваться для задач инвентаризации. Например, в тех сценариях, когда «родительская» система» по соображениям безопасности не включена в домен или даже не имеет доступа в корпоративную сеть. (При этом сеть может быть доступна лишь из самих виртуальных машин). Многие ли из вас помнят наизусть, какие платформы виртуализации используются на тех или иных серверах вашей сети (считая, что их много)? Какая версия Hyper-V, актуальна ли версия Virtual Server 2005 (R2, R2 SP1…), установлены ли в виртуальной машине текущие компоненты интеграции Hyper-V или Virtual Machine Additions (для VS2005)? В принципе, ничто не мешает нам определять и сторонние платформы виртуализации — как и версии используемых ими компонентов.

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

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

Подключение файлов VHD в Hyper-V

Многие знают, что в Virtual Server 2005 существовала утилита vhdmount.exe. Она позволяла подключать образы жестких дисков формата VHD в виде каталога на разделе NTFS или отдельного диска. В Hyper-V такой возможности нет. В связи с чем возникают больные вопросы — «доколе?» и «что делать?». Выход из этой ситуации, конечно, есть. Точнее несколько выходов. Все они основаны на богатых возможностях управления Hyper-V через репозиторий WMI. Я приведу примеры подключения образов VHD для C#, VBScript и PowerShell. Если тема программного управления VM интересна, могу привести другие примеры.