0203..Платформа виртуализации Hyper-V

Роберт Ларсон, Жаник Карбон
совместно с Windows Virtualization Team
«Русская Редакция» «БХВ-Петербург»
2010
681.3.06
32.973.26-018.2
25
.
25

Hyper-V™. Windows Server® 2008 / . , . -
: . . — .:

«! " !"»; #.: «$%-
»,
2010. — 800 .: . + CD-ROM
ISBN 978-5-7502-0397-0 («! " !"»)
ISBN 978-5-9775-0189-7 («$%-
»)
&

'!*

, ! ! * "
* !
*
"
(
4
", !, <&
), * !

!
Hyper-V
!*
, * "
*

, !

Hyper-V, *

< ! => ! , *

!

" * " * ",
* -

* Microsoft Virtual Server Hyper-V, * "
=? * !
!
*
,
*
*
", <

"
4!4 *

Hyper-V. *"
!* !
-
! ? !=
* "

=> *!

* " *
4 Hyper-V ! *

*
-
.

681.3.06
32.973.26-018.2
© 2009-2012, Translation Russian Edition Publishers.

Authorized Russian translation of the English edition of Windows Server 2008 Hyper-V Resource Kit, ISBN
9780735625174 © Janique Carbone and Robert Larson.
This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to
publish and sell the same.
© 2009-2012, * FFF «

«! " !"»,

«$%-
».
G
4 * 4! !4 "! * " Windows Server 2008 Hyper-V Re-
source Kit, ISBN 9780735625174 © Janique Carbone and Robert Larson.
Q

* " *!
" *
" ?" O’Reilly Media, Inc., !
"

* "&
" * *! < * &.
© 2010-2012, *
! ! <, FFF «

«! " !"»,

«$%-
».
Microsoft,
!&
!, * = *!, *& * :
http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/EN-US.aspx ""<
"

! > "
! ! * Microsoft #XG / >
>. % -

! ""<
"

<

<Y> .
% " !* 4, 4 * !
,
!& , * * >, ?-
<
! !
?" ! !* ", ", * !
.
#
4 * !

«! " !"»

«$%-
»
Оглавление
Об авторах ........................................................................................................................ 3
Благодарности.................................................................................................................. 5
Введение ............................................................................................................................ 7
Поддержка Microsoft Partner ........................................................................................................... 8
Обзор книги ...................................................................................................................................... 8
Используемые условные обозначения ........................................................................................... 9
Помощники читателя............................................................................................................... 9
Врезки ..................................................................................................................................... 10
Примеры командной строки ................................................................................................. 10
На прилагающемся компакт-диске....................................................................................... 10
Системные требования .................................................................................................................. 11
Использование скриптов ............................................................................................................... 11
Политика поддержки сборника ресурсов ............................................................................ 12
ЧАСТЬ I. ПРИСТУПАЕМ К ИЗУЧЕНИЮ WINDOWS SERVER 2008

HYPER-V ......................................................................................................................... 13
Глава 1. Представляем виртуализацию ................................................................... 15
Разбираемся с виртуализацией ..................................................................................................... 15
Основы виртуализации ..........................................................................................................16
Виртуализация на основе процессоров семейства х86 ....................................................... 16
Что такое программная виртуализация? ...................................................................................... 21
Виртуализация на уровне машины ....................................................................................... 21
Виртуализация на уровне операционной системы .............................................................. 24
Виртуализация на уровне приложений ................................................................................ 25
Виртуализация рабочего стола ............................................................................................. 27
Подготовка экономического обоснования виртуализации серверов ........................................ 29
Снижение капитальных и эксплуатационных затрат .......................................................... 29
Реализация простой, гибкой и динамичной серверной инфраструктуры ......................... 30
Повышение готовности вычислительных ресурсов............................................................ 31
Уменьшение времени на подготовку или предоставление услуг ...................................... 32
Снижение сложности управления ........................................................................................ 33
VI Оглавление
Сценарии виртуализации серверов ..............................................................................................33

Консолидация центра обработки данных ............................................................................ 34
Консолидация филиалов организации ................................................................................. 34
Виртуализация инфраструктуры тестирования и разработки ............................................ 35
Обеспечение непрерывности бизнеса и его восстановления ............................................. 35
Резюме ............................................................................................................................................ 36
Дополнительные источники ......................................................................................................... 36
Глава 2. Обзор Hyper-V ................................................................................................ 39

Основы Hyper-V ............................................................................................................................. 39
Основные функциональные возможности Hyper-V .................................................................... 42
Поддержка архитектур AMD-V и Intel VT .......................................................................... 43
Поддержка полной инсталляции и инсталляции типа Server Core .................................... 43
Сервер Microsoft Hyper-V Server 2008 ................................................................................. 44
Управление доступом при помощи Authorization Manager ................................................ 45
Live Backup при помощи Volume Shadow Copy Service ..................................................... 45
Высокая готовность при помощи отказоустойчивой кластеризации ................................ 46
Быстрая миграция .................................................................................................................. 46
Службы интеграции ............................................................................................................... 47
Импорт и экспорт виртуальных машин ............................................................................... 47
Управление виртуальными дисками .................................................................................... 47
Моментальные снимки виртуальных машин....................................................................... 48
Инструмент Virtual Machine Connection .............................................................................. 48
Поддержка операционных систем хоста.............................................................................. 51
Поддержка гостевых операционных систем ....................................................................... 51
Обзор Hyper-V ............................................................................................................................... 53
Аппаратная среда виртуальной машины ..................................................................................... 53
Виртуальные жесткие диски ................................................................................................. 55
Транзитные диски .................................................................................................................. 56
Виртуальный интерфейс IDE ................................................................................................ 56
Виртуальный интерфейс SCSI .............................................................................................. 56
Диски iSCSI ............................................................................................................................ 56
Виртуальные сети .................................................................................................................. 56
Виртуальные сетевые адаптеры............................................................................................ 57
Использование консоли Hyper-V Manager .................................................................................. 58
Управление большим количеством серверов Hyper-V ....................................................... 60
Управление виртуальными машинами ................................................................................ 60
Управление виртуальными жесткими дисками ................................................................... 73
Управление виртуальными сетями ....................................................................................... 75
Приложение для подключения виртуальных машин .......................................................... 77
Управление настройками Hyper-V ....................................................................................... 79
Принципы интерфейса прикладного программирования WMI ................................................. 80
Резюме ............................................................................................................................................ 80
Дополнительные источники информации ................................................................................... 81
Глава 3. Архитектура Hyper-V ................................................................................... 83

Гипервизор Windows ..................................................................................................................... 84
Разделы ........................................................................................................................................... 85
Родительский раздел.............................................................................................................. 86
Дочерний раздел .................................................................................................................... 86
Оглавление VII
Стек виртуализации ....................................................................................................................... 86

Служба управления виртуальными машинами ................................................................... 88
Компонент конфигурирования ............................................................................................. 93
Поставщики службы виртуализации .................................................................................... 93
Клиенты службы виртуализации .......................................................................................... 94
Шина VMBus.......................................................................................................................... 94
Драйвер инфраструктуры виртуализации ............................................................................ 95
Интерфейсы WMI .................................................................................................................. 98
Рабочий процесс .................................................................................................................... 99
Стек виртуализации в действии .......................................................................................... 102
Виртуальные устройства ............................................................................................................. 102
Виртуальная память ............................................................................................................. 103
Виртуальные процессоры ................................................................................................... 106
Виртуальная сеть ................................................................................................................. 107
Службы интеграции дочернего раздела ............................................................................. 109
Виртуальные жесткие диски ............................................................................................... 110
Виртуальный гибкий диск ................................................................................................... 115
Резюме .......................................................................................................................................... 115
Дополнительные источники информации ................................................................................. 116
ЧАСТЬ II. РАЗБИРАЕМСЯ С СЕРВЕРОМ WINDOWS SERVER 2008

HYPER-V ....................................................................................................................... 117
Глава 4. Инсталляция и конфигурирование Hyper-V ......................................... 119
Обзор процедуры инсталляции...................................................................................................119
Предварительные требования для инсталляции........................................................................ 120
Интеграция Hyper-V в Windows Server 2008 ..................................................................... 120
Необходимое программное обеспечение и инструменты ................................................ 121
Инсталляция WAIK .............................................................................................................121
Подготовка к встраиванию обновления ............................................................................. 122
Извлечение обновления Hyper-V ........................................................................................ 123
Встраивание обновления Hyper-V ...................................................................................... 123
Создание нового ISO-образа ............................................................................................... 124
Опции инсталляции: роль Hyper-V ............................................................................................ 125
Инсталляция при помощи консоли Server Manager MMC ............................................... 125
Инсталляция при помощи ServerManagerCmd.exe ............................................................ 128
Использование OCSetup.exe ............................................................................................... 129
Опции инсталляции: Microsoft Hyper-V Server 2008 ................................................................ 130
Дополнительные методы инсталляции ...................................................................................... 135
Использование Unattend.xml для инсталляции Hyper-V ................................................... 135
Инструментальный набор Microsoft Deployment Toolkit 2008 ........................................... 137
Инсталляция роли Hyper-V при помощи System Center Virtual Machine Manager
2008 ....................................................................................................................................... 146
Соображения по конфигурированию после инсталляции ........................................................ 151
Команды для модификации инсталляции Server Core ...................................................... 152
Инструмент конфигурирования сервера Microsoft Hyper-V Server 2008 ........................ 154
Резюме .......................................................................................................................................... 164
VIII Оглавление
Глава 5. Расширенные функции Hyper-V .............................................................. 167

Использование расширенных функциональных возможностей виртуальных
жестких дисков ............................................................................................................................ 167
Разностные диски................................................................................................................. 168
Автоматические разностные диски .................................................................................... 176
Копирование физического диска на VHD ......................................................................... 176
Конвертирование VHD ........................................................................................................ 178
Сжатие VHD ......................................................................................................................... 179
Расширение VHD ................................................................................................................. 183
Использование моментальных снимков виртуальной машины ............................................... 184
Создание моментального снимка виртуальной машины .................................................. 185
Возвращение к состоянию предыдущего моментального снимка .................................. 190
Использование опции Apply Snapshot ................................................................................ 190
Использование опции Delete Snapshot ............................................................................... 193
Использование опции Delete Snapshot Subtree .................................................................. 193
Использование функций Integration Services ............................................................................. 193
Служба синхронизации времени ........................................................................................ 194
Служба тактовых импульсов............................................................................................... 195
Служба завершения работы ................................................................................................ 195
Служба обмена парами "ключ/значение" .......................................................................... 195
Служба теневого копирования Volume Shadow Copy Service (VSS) ............................... 197
Поддерживающие службы интеграции гостевые операционные системы ..................... 197
Использование расширенных функций виртуальной сети ....................................................... 198
Движение виртуального сетевого трафика ........................................................................ 198
Виртуальные локальные сети ............................................................................................. 209
Пулы MAC-адресов .............................................................................................................213
Использование транзитного диска ............................................................................................. 214
Конфигурирование транзитного диска .............................................................................. 215
Использование функций отказоустойчивой кластеризации .................................................... 216
Высокая готовность ............................................................................................................. 217
Отказоустойчивая кластеризация Windows Server 2008................................................... 217
Реализация кластера серверов Hyper-V ............................................................................. 218
Реализация отказоустойчивого кластера виртуальных машин ........................................ 233
Резюме .......................................................................................................................................... 238
Глава 6. Безопасность Hyper-V................................................................................. 241

Обзор файлов Hyper-V ................................................................................................................ 241
Обзор служб Hyper-V .................................................................................................................. 249
Обзор правил межсетевого экрана Hyper-V .............................................................................. 250
Обеспечение безопасности ресурсов Hyper-V .......................................................................... 252
Использование менеджера Authorization Manager с Hyper-V .......................................... 252
Создание хранилища авторизации в Active Directory ....................................................... 254
Разбираемся с безопасностью Hyper-V .............................................................................. 256
Конфигурирование роли наблюдения для Hyper-V .......................................................... 261
Конфигурирование роли менеджера виртуальных сетей ................................................. 267
Конфигурирование роли менеджера виртуальных машин ............................................... 267
Оглавление IX
Обзор лучших практик по безопасности Hyper-V .................................................................... 271

Минимизация пространства для атак в родительском разделе Hyper-V ......................... 271
Запуск приложений только в дочерних разделах .............................................................. 272
Определение уровней безопасности виртуальных машин ............................................... 272
Определение политики авторизации с наименьшими привилегиями ............................. 272
Реализация строгой стратегии обновлений ....................................................................... 273
Выделение физического сетевого адаптера для родительского раздела ........................ 273
Использование в родительском разделе шифрования дисков BitLocker ........................ 273
Реализация или расширение стратегии аудита.................................................................. 274
Обеспечение безопасности доступа к виртуальной машине.................................................... 274
Конфигурирование каталогов виртуальных машин с центральным управлением......... 276
Конфигурирование организационно управляемой безопасности
виртуальных машин .............................................................................................................277
Конфигурирование управляемой на уровне проектов безопасности виртуальных
машин.................................................................................................................................... 277
Резюме .......................................................................................................................................... 279
Глава 7. Лучшие практики и оптимизация сервера Hyper-V ............................ 281

Модификация инсталляции по умолчанию сервера Hyper-V .................................................. 281
Переименуйте первую внешнюю виртуальную сеть ........................................................ 283
Используйте для виртуальных сетей обычные имена ...................................................... 283
Резервное копирование хранилища авторизации.............................................................. 284
Включаем удаленный рабочий стол ................................................................................... 284
Оптимизация производительности сервера ............................................................................... 285
Максимизация производительности процессора .............................................................. 285
Максимизация производительности памяти ..................................................................... 286
Максимизация производительности системы хранения хоста ........................................ 289
Максимизируем производительность сети ........................................................................ 294
Совместная (командная) работа сетевых адаптеров ......................................................... 297
Инсталляция сетевых адаптеров команды совместной работы ....................................... 300
Оптимизация производительности виртуальной машины ....................................................... 301
Максимизация производительности процессора .............................................................. 301
Максимизация производительности памяти ..................................................................... 308
Максимизация сетевой производительности .................................................................... 311
Максимизация производительности системы хранения................................................... 315
Эксплуатационные соображения................................................................................................ 318
Выработка стандартов .........................................................................................................318
Пример стандарта именования VHD.................................................................................. 319
Резюме .......................................................................................................................................... 320
Глава 8. Переход с Virtual Server 2005 R2 на Hyper-V ......................................... 323

Анализ перед миграцией хоста Virtual Server 2005 R2 на Hyper-V ......................................... 323
Обслуживание хостов Virtual Server 2005 R2 .................................................................... 323
Поддержка беспроводных сетей ......................................................................................... 324
Поддержка серверного оборудования ................................................................................ 324
Минимизация времени простоя .......................................................................................... 324
X Оглавление
Миграция хоста Virtual Server 2005 R2 на Hyper-V .................................................................. 325

Разработка спецификации на оборудование сервера Hyper-V ......................................... 325
Инсталляция Hyper-V ..........................................................................................................327
Миграция виртуальных сетей ............................................................................................. 327
Соображения по миграции виртуальных машин ...................................................................... 328
Конфигурация загрузочного диска ..................................................................................... 328
Дополнения Virtual Machine Additions ............................................................................... 328
Диски Undo ........................................................................................................................... 329
Сохраненные состояния ...................................................................................................... 329
Разница в уровне абстракции Hardware Abstraction Layer................................................ 329
Разностные диски................................................................................................................. 329
Кластеры виртуальных машин с совместно используемой шиной SCSI ........................ 330
Миграция виртуальных машин...................................................................................................330
Определение совместимости .............................................................................................. 330
Преобразование загрузки со SCSI в загрузку с IDE.......................................................... 331
Удаление дополнений Virtual Machine Additions .............................................................. 333
Удаление карты эмулированных сетевых интерфейсов ................................................... 333
Фиксирование или удаление дисков Undo......................................................................... 334
Восстановление или удаление сохраненных состояний ................................................... 335
Слияние разностных дисков ............................................................................................... 335
Проверка уровня Hardware Abstraction Layer .................................................................... 337
Завершение миграции..........................................................................................................337
Резюме .......................................................................................................................................... 342
Глава 9. Знакомимся с сервером Windows Server 2008 R2 Hyper-V.................. 343

Инсталляция роли Hyper-V на Windows Server 2008 R2 .......................................................... 343
Обзор новых функций Hyper-V ..................................................................................................349
Функция Live Migration .......................................................................................................350
Трансляция адресов второго уровня .................................................................................. 353
Функция остановки ядра ..................................................................................................... 354
Динамическое добавление и удаление объемов хранения ............................................... 355
Поддержка разгрузки ТСР .................................................................................................. 355
Поддержка очередей виртуальных машин ........................................................................ 355
Пакеты увеличенного размера ............................................................................................ 356
Настройка диапазона МАС-адресов ................................................................................... 356
Работа моментальных снимков виртуальных машин ....................................................... 357
Новые каталоги по умолчанию сервера Hyper-V .............................................................. 358
Использование Live Migration .................................................................................................... 358
Создание кластера из двух хостов Hyper-V ....................................................................... 358
Конфигурирование совместно используемых дисков iSCSI ............................................ 359
Создание новой виртуальной машины............................................................................... 363
Превращаем виртуальную машину в машину высокой готовности ................................ 364
Конфигурирование кластерных сетей для миграции Live Migration ............................... 365
Инициирование миграции Live Migration .......................................................................... 365
Управление Hyper-V R2 .............................................................................................................. 365
Резюме .......................................................................................................................................... 366
Оглавление XI
ЧАСТЬ III. УПРАВЛЕНИЕ ИНФРАСТРУКТУРОЙ WINDOWS

SERVER 2008 HYPER-V............................................................................................. 369
Глава 10. Обзор управления сервером Hyper-V.................................................... 371
Решения по управлению.............................................................................................................. 372
Менеджер Hyper-V Manager для ММС .............................................................................. 372
Менеджер Failover Cluster Manager .................................................................................... 374
Менеджер System Center Virtual Machine Manager 2008 .................................................. 376
Решения по преодолению последствий катастроф ................................................................... 380
Windows Server Backup........................................................................................................ 380
Менеджер System Center Data Protection Manager 2007 SP1 ............................................ 382
Решения по наблюдению ............................................................................................................ 384
Монитор Reliability and Performance Monitor .................................................................... 384
Менеджер System Center Operations Manager 2007 ........................................................... 388
Резюме .......................................................................................................................................... 390
Глава 11. Управление одним сервером Hyper-V................................................... 393

Управление сервером Hyper-V ...................................................................................................393
Инсталляция инструментов управления сервером Hyper-V............................................. 394
Активирование удаленного управления ............................................................................ 399
Настройка представления Hyper-V Manager ............................................................................. 409
Настройки сервера Hyper-V ........................................................................................................ 411
Изменение состояния службы Virtual Machine Management Service ....................................... 412
Управление виртуальными машинами при помощи Hyper-V Manager .................................. 414
Создание новой виртуальной машины............................................................................... 414
Настройка ключевых параметров конфигурации виртуальной машины ........................ 417
Добавление устройств виртуального оборудования ......................................................... 417
Конфигурирование настроек BIOS виртуальных машин ................................................. 418
Изменение настроек памяти................................................................................................ 419
Изменения процессорных настроек ................................................................................... 420
Изменение настроек виртуальных жестких дисков .......................................................... 421
Изменение настроек виртуального дисковода DVD ......................................................... 423
Изменение настроек виртуального сетевого адаптера ..................................................... 424
Изменение настроек виртуальных СОМ-портов ............................................................... 427
Изменение настроек виртуального дисковода гибких дисков ......................................... 429
Изменение имени виртуальной машины ........................................................................... 429
Модификация настроек служб интеграции Integration Services ....................................... 430
Модификация местоположения файлов моментальных снимков ................................... 431
Модификация действий при автоматическом запуске виртуальной машины ................ 432
Модификация действий при автоматическом останове виртуальной машины .............. 433
Удаление виртуальной машины ......................................................................................... 434
Инсталляция гостевой операционной системы ......................................................................... 435
Инсталляция служб интеграции Integration Services................................................................. 438
Управление состоянием виртуальной машины ......................................................................... 440
Обновление виртуальных машин ............................................................................................... 440
Выполнение резервного копирования и восстановления сервера Hyper-V ............................ 441
Инсталляция Windows Server Backup................................................................................. 441
Конфигурирование Windows Server Backup для поддержки Hyper-V............................. 443
XII Оглавление
Соображения относительно приложения Windows Server Backup .................................. 445

Резервное копирование виртуальной машины при помощи Windows Server Backup ... 446
Восстановление виртуальной машины при помощи Windows Server Backup ................ 450
Наблюдение за состоянием и производительностью сервера Hyper-V................................... 455
Резюме .......................................................................................................................................... 456
Дополнительные ресурсы ........................................................................................................... 457
Глава 12. Управление фермой серверов ................................................................. 459

Инсталляция менеджера System Center Virtual Machine Manager 2008................................... 459
Опции инсталляции .............................................................................................................460
Требования к программному и аппаратному обеспечению ............................................. 460
Требования к программному обеспечению ....................................................................... 460
Требования к оборудованию............................................................................................... 462
Пошаговая инсталляция ...................................................................................................... 466
Управление фермой серверов ..................................................................................................... 472
Типы управляемых хостов .................................................................................................. 473
Управление хостами ............................................................................................................474
Управление порталом Self-Service Portal ........................................................................... 480
Управление серверами библиотек ...................................................................................... 481
Управление виртуальными машинами .............................................................................. 490
Управление кластером серверов Hyper-V ......................................................................... 497
Резюме .......................................................................................................................................... 499
Глава 13. Резервное копирование и восстановление сервера Hyper-V ............ 501

Резервное копирование среды виртуализации .......................................................................... 501
Модуль записи VSS для Hyper-V ............................................................................................... 502
Компоненты VSS ................................................................................................................. 503
Процесс резервного копирования Hyper-V при помощи VSS ......................................... 505
Документ метаданных модуля записи VSS для Hyper-V.................................................. 506
Использование традиционных методов для резервного копирования сервера Hyper-V
и виртуальных машин ................................................................................................................. 507
Резервное копирование виртуальной машины контроллера домена Active Directory ........... 507
Использование VSS для резервного копирования Hyper-V и виртуальных машин .............. 508
Использование менеджера System Center Data Protection Manager 2007 SP1......................... 510
Обновление служб интеграции виртуальных машин........................................................ 511
Инсталляция System Center Data protection Manager 2007 SP1 ........................................ 513
Активация локальной защиты данных в DPM 2007 SP1 .................................................. 514
Развертывание агента менеджера DPM 2007 SP1 ............................................................. 516
Конфигурирование пула хранения менеджера DPM 2007 SP1 ........................................ 521
Конфигурирование группы защиты DPM 2007 SP1 ......................................................... 523
Восстановление виртуальной машины при помощи DPM 2007 SP1 .............................. 530
Резюме .......................................................................................................................................... 535
Глава 14. Миграция серверов при помощи менеджера System Center

Virtual Machine Manager ............................................................................................. 537
Опции миграции .......................................................................................................................... 537
Требования для миграции ........................................................................................................... 538
Оперативная миграция с физической машины на виртуальную ............................................. 539
Оглавление XIII
Автономная миграция физической машины в виртуальную ................................................... 547

Предварительные требования для автономной миграции P2V........................................ 548
Сбор системной информации ............................................................................................. 548
Модификация конфигурации томов ................................................................................... 549
Модификация автономного IP-адреса................................................................................ 551
Модификация конфигурации виртуальной машины ........................................................ 552
Выбор хоста для размещения ............................................................................................. 553
Выбор пути хранения ..........................................................................................................553
Выбор сетей.......................................................................................................................... 554
Дополнительные свойства................................................................................................... 554
Информация по преобразованию ....................................................................................... 556
Выполнение миграции......................................................................................................... 557
Резюме .......................................................................................................................................... 557
Глава 15. Наблюдение за сервером при помощи пакета управления

Windows Server 2008 Hyper-V Management Pack для менеджера System
Center Operations Manager 2007 ............................................................................... 561
Обзор консоли System Center Operations Manager 2007 Operations Console ........................... 561
Характеристики пакета управления Windows Server 2008 Hyper-V Management Pack ......... 568
Инсталляция пакета управления Windows Server 2008 Hyper-V Management Pack ............... 571
Запуск инсталлятора пакета управления Windows Server 2008 Hyper-V Management
Pack ....................................................................................................................................... 572
Импорт пакета Windows Server 2008 Hyper-V Management Pack .................................... 572
Проверка версии пакета управления Windows Server 2008 Hyper-V Management Pack 573
Инсталляция агента System Center Operations Manager 2007 Agent ................................ 574
Наблюдение за серверами Hyper-V ............................................................................................ 578
Представления наблюдения за серверами Hyper-V .......................................................... 578
Стандартные представления наблюдения за серверами Hyper-V .................................... 581
Инструмент System Center Operations Manager 2007 Health Explorer Tool ..................... 583
Отчетность System Center Operations Manager 2007 Reporting ........................................ 583
Резюме .......................................................................................................................................... 585
Глава 16. Управление сервером Hyper-V при помощи Windows PowerShell .. 587
Классы WMI для Hyper-V ........................................................................................................... 588
Подключение к WMI для Hyper-V ..................................................................................... 589
Запросы к локальному серверу Hyper-V ............................................................................ 591
Запросы к удаленным серверам Hyper-V ........................................................................... 592
Запрос по конкретной виртуальной машине ..................................................................... 592
Запрос нескольких классов ................................................................................................. 593
Модификация настроек виртуальной машины.................................................................. 595
Использование библиотеки Windows PowerShell Hyper-V Library.......................................... 597
Изменение политики Windows PowerShell Execution Policy ............................................ 598
Загрузка библиотеки в память ............................................................................................ 599
Функции библиотеки Hyper-V PowerShell Management Library....................................... 599
Управление виртуальными машинами .............................................................................. 602
Управление виртуальными жесткими дисками ................................................................. 607
XIV Оглавление
Управление виртуальными сетями ..................................................................................... 609

Управление моментальными снимками............................................................................. 611
Резюме .......................................................................................................................................... 614
ЧАСТЬ IV. МЕТОДОЛОГИЯ ПРОЕКТА ВИРТУАЛИЗАЦИИ

СЕРВЕРОВ ................................................................................................................... 617
Глава 17. Сценарии виртуализации серверов ....................................................... 619
Сценарий центра обработки данных .......................................................................................... 619
Соображения по проектированию хостов ......................................................................... 619
Соображения по схеме управления .................................................................................... 625
Эксплуатационные соображения ........................................................................................ 627
Сценарий филиала ....................................................................................................................... 628
Соображения по проектированию хостов ......................................................................... 629
Соображения по управлению.............................................................................................. 629
Соображения по резервному копированию ....................................................................... 630
Сценарий тестовой лаборатории ................................................................................................631
Соображения по проектированию сервера ........................................................................ 631
Соображения по управлению.............................................................................................. 633
Соображения по альтернативному использованию .......................................................... 636
Сценарий разработки программного обеспечения ................................................................... 637
Соображения по разработке хостов ................................................................................... 637
Соображения управления .................................................................................................... 638
Резюме .......................................................................................................................................... 638
Глава 18. Инфраструктура виртуальных рабочих столов .................................. 641

Важнейшие атрибуты VDI .......................................................................................................... 642
Независимые от оборудования виртуальные рабочие столы ........................................... 642
Выделенные, изолированные и безопасные виртуальные рабочие столы ...................... 643
Динамическая доставка и конфигурирование приложений ............................................. 643
Гибкое выделение ресурсов ................................................................................................ 643
Быстрая поставка и вывод из эксплуатации рабочих столов ........................................... 644
Быстрая миграция рабочих столов ..................................................................................... 645
Централизованное и безопасное хранение данных ........................................................... 645
Централизованное резервное копирование ....................................................................... 646
Расширенная поддержка клиентских устройств ............................................................... 646
Определение главных компонентов VDI ................................................................................... 647
Определение статических и динамических виртуальных рабочих столов ..................... 647
Основные компоненты виртуализации .............................................................................. 648
Клиентские компоненты ..................................................................................................... 649
Компоненты виртуализации приложений.......................................................................... 650
Компоненты управления ..................................................................................................... 651
Описание стандартных сценариев VDI...................................................................................... 653
Оффшорная разработка ....................................................................................................... 653
Центры обработки звонков, службы технической поддержки, розничные филиалы .... 654
Оглавление XV
Обзор решения VDI компании Microsoft ................................................................................... 655

Сервер Windows Server 2008 Hyper-V................................................................................ 655
Централизованный рабочий стол Windows Vista Enterprise Centralized Desktop ........... 655
Рабочий стол Citrix XenDesktop ......................................................................................... 656
Виртуализация приложений Microsoft Application Virtualization .................................... 657
Windows Server 2008 Terminal Services RemoteApp .......................................................... 657
Менеджер System Center Virtual Machine Manager ........................................................... 657
Менеджер System Center Data Protection Manager............................................................. 658
Резюме .......................................................................................................................................... 658
Источники дополнительной информации ................................................................................. 659
Глава 19. Проект виртуализации серверов: фаза представления ..................... 661

Определение фаз проекта виртуализации серверов.................................................................. 661
Что такое "фаза представления"? ...............................................................................................662
Состав команды фазы представления ........................................................................................ 662
Выработка представления ........................................................................................................... 663
Определение формулировок проблем........................................................................................ 664
Процесс определения формулировок проблем ................................................................. 665
Назначение приоритетов ..................................................................................................... 666
Определение команды проекта...................................................................................................666
Определение необходимых для проекта команд и ролей ................................................. 666
Определение командных ролей .......................................................................................... 667
Определение области действия проекта .................................................................................... 672
Что входит в область действия? ......................................................................................... 672
Что не вошло в область действия проекта? ....................................................................... 673
Определение фаз проекта .................................................................................................... 674
Выполнение анализа возврата инвестиций................................................................................ 674
Выявление рисков........................................................................................................................ 676
Создание бюджета проекта ......................................................................................................... 678
Резюме .......................................................................................................................................... 679
Глава 20. Проект виртуализации серверов: фаза обнаружения ........................ 681

Сбор информации, которая послужит точкой отсчета ............................................................. 682
Информация по лесу Active Directory ................................................................................ 682
Сбор информации о местоположении................................................................................ 682
Сбор информации инвентаризации ............................................................................................ 683
Инвентаризация аппаратного обеспечения ....................................................................... 684
Инвентаризация программного обеспечения .................................................................... 687
Службы ................................................................................................................................. 688
Наблюдение за производительностью ....................................................................................... 689
Информация по среде .................................................................................................................. 691
Автоматизация процесса обнаружения...................................................................................... 692
Скрипты ................................................................................................................................ 692
Инструменты общего назначения ...................................................................................... 693
Systemtools Exporter Pro ......................................................................................................694
Инструменты обнаружения и оценки......................................................................................... 697
Инструментальный набор Microsoft Assessment and Planning.......................................... 697
PlateSpin PowerRecon ........................................................................................................... 701
XVI Оглавление
Резюме .......................................................................................................................................... 703

Глава 21. Проект виртуализации серверов: фаза оценки ................................... 705

Выявление кандидатов на виртуализацию серверов ................................................................ 705
Ограничения по оборудованию виртуальных машин............................................................... 706
Оценка ограничений по оборудованию ..................................................................................... 706
Ограничения оборудования по процессорам .................................................................... 707
Ограничения оборудования по памяти .............................................................................. 707
Ограничения по сетевому адаптеру ................................................................................... 708
Ограничения оборудования по дискам .............................................................................. 708
Ограничения по периферийным портам ............................................................................ 708
Установка пределов по производительности ............................................................................ 709
Оценка производительности ....................................................................................................... 710
Оценка производительности процессора ........................................................................... 710
Оценка производительности памяти .................................................................................. 711
Оценка производительности дисков .................................................................................. 712
Оценка сетевой производительности ................................................................................. 712
Оценка поддержки приложений ................................................................................................. 714
Использование МАР для оценки и планирования высокого уровня ....................................... 715
Выявление кандидатов на виртуализацию и сценарии консолидации серверов ............ 715
Как работает мастер Server Virtualization and Consolidation Wizard................................ 716
Выявление экономии расходов ..................................................................................................722
Экономия капитальных затрат ............................................................................................ 722
Экономия на среде ............................................................................................................... 723
Экономия стоечного пространства..................................................................................... 723
Потребление электроэнергии.............................................................................................. 724
Расходы на охлаждение ....................................................................................................... 725
Резюме .......................................................................................................................................... 725
Глава 22. Проект виртуализации серверов: фаза планирования

и проектирования........................................................................................................ 727
Определение конфигурации серверов Hyper-V......................................................................... 728
Физические требования ....................................................................................................... 729
Требования по высокой готовности ................................................................................... 730
Планирование консолидации ...................................................................................................... 731
Группировка кандидатов ..................................................................................................... 731
Анализ рабочих нагрузок .................................................................................................... 732
Повторное использование оборудования .......................................................................... 739
Дополнительные задачи проектирования и планирования ...................................................... 739
Управление инфраструктурой виртуализации .................................................................. 739
Наблюдение за инфраструктурой виртуализации ............................................................. 740
Управление обновлениями инфраструктуры виртуализации .......................................... 740
Резервное копирование и восстановление инфраструктуры виртуализации .................. 741
Резюме .......................................................................................................................................... 742
Оглавление XVII
Глава 23. Проект виртуализации серверов: пилотная фаза ............................... 745

Цели пилотного проекта ............................................................................................................. 745
Область действия пилотного проекта ........................................................................................ 746
Выбор пилотных площадок ................................................................................................ 746
Выбор кандидатов на виртуализацию ................................................................................ 747
Архитектура пилотного проекта ................................................................................................747
Планирование пилотного проекта .............................................................................................. 748
Создание плана развертывания........................................................................................... 748
Создание плана поддержки ................................................................................................. 749
Создание плана отслеживания проблем............................................................................. 749
Разработка плана миграции ................................................................................................ 751
Разработка плана действий ................................................................................................. 752
Разработка плана обучения ................................................................................................. 752
Создание плана обмена информацией ............................................................................... 753
Документирование рисков .......................................................................................................... 755
Определение вех пилотного проекта ......................................................................................... 756
Определение критерия успеха .................................................................................................... 756
Реализация пилотного проекта ................................................................................................... 757
Измерение успеха проекта .......................................................................................................... 757
Усваиваем полученные уроки ....................................................................................................758
Резюме .......................................................................................................................................... 758
Глоссарий ...................................................................................................................... 761

Приложение. Описание компакт-диска .................................................................. 773
Как использовать компакт-диск? ...............................................................................................773
Меню автозапуска диска ..................................................................................................... 773
Средства просмотра файлов ............................................................................................... 773
Что находится на компакт-диске? ..............................................................................................773
Книга "Windows Server 2008 Hyper-V. Resource Kit" в электронном виде ..................... 774
Вспомогательные материалы.............................................................................................. 774
Скрипты ................................................................................................................................ 774
Ссылки на инструменты и ресурсы .................................................................................... 774
Бонусное содержимое.......................................................................................................... 774
Информация о поддержке ........................................................................................................... 774
Информация по технической поддержке Microsoft Learning Technical Support ............. 774
Отказ от ответственности ........................................................................................................... 775
Предметный указатель .............................................................................................. 777

Эта книга посвящается моим родственникам, как ближним, так
и дальним, которые продолжают поддерживать мои начинания.
–JSC
Я посвящаю эту книгу двум моим детям — Алексу и Ксавье. Они

продолжают вдохновлять меня каждый день.
–REL
Об авторах
Джени Карбон (Janique Carbone) работает в области информационных технологий

более 15 лет и специализируется по проектам проектирования и развертывания инфра-
структуры предприятий. Она является соавтором книги Microsoft Virtual Server 2005 R2
Resource Kit (издательство Microsoft Press, 2008) и пишет статьи по технологии виртуа-
лизации. После семи лет работы в Microsoft Services Джени основала группу Infrastruc-
tor Group, которая занимается обучением технологиям виртуализации и консультиро-
ванием. Джени имеет звание MCSE, степени бакалавра и магистра в авиационно-
космической области, а также степень магистра в области компьютерных наук. Она
живет в Техасе и имеет семью, которая состоит из мужа, двух замечательных детей и
нескольких веселых собак.
Роберт Ларсон (Robert Larson) — ведущий разработчик консультационной службы

Microsoft (MCS), является экспертом по технологиям виртуализации. Роберт регулярно
делает доклады по виртуализационным темам на конференциях TechEd и ITForum и
подготовил в TechNet много Web-кастов по технологиям виртуализации компании
Microsoft. Помимо того, что он является соавтором книги Microsoft Virtual Server 2005
R2 Resource Kit, он написал (и помогал в написании) для компании Microsoft докумен-
ты по серверам Hyper-V и Virtual Server 2005. Роберт также пишет статьи по виртуали-
зации для журнала "Windows IT Pro" и сайта VirtualizationAdmin.com. Роберт проработал
в области информационных технологий более 20 лет в качестве инженера, поставщика
и консультанта. В качестве архитектора MCS он помогает клиентам и партнерам пла-
нировать и создавать проекты консолидации центров обработки данных и серверов
(с применением виртуализации). Роберт имеет степень магистра по компьютерным
наукам. Живет за городом (Хьюстон, Техас) вместе со своей прекрасной женой и двумя
энергичными детьми. Он увлекается баскетболом и дайвингом, а также любит гото-
вить. Вы можете почитать его размышления по поводу виртуализации (и прочим те-
мам) в его блоге по адресу: http://blogs.technet.com/roblarson/default.aspx.
Благодарности
Как и в случае с книгой "Virtual Server 2005 R2 Resource Kit", данная книга представля-
ет собой результат коллективных усилий многих людей, которые писали и рецензиро-
вали ее содержимое, а также придавали ему форму — чтобы она была полезной, точ-
ной и стоила того времени и тех денег, которые вы на нее потратите. Поэтому повто-
римся еще раз — мы должны поблагодарить многих, поскольку без их помощи эта
книга была бы менее значительной работой.
Мартин ДелРе (Martin DelRe) из Microsoft Press стал работать над проектом Windows
Server 2008 Hyper-V Resource Kit вскоре после завершения книги "Microsoft Virtual
Server 2005 R2 Resource Kit". Мартин, мы еще раз благодарим тебя за предоставленные
нам возможности и за твою помощь в этом проекте.
Еще одна благодарность Хизер Стэффорд (Heather Stafford), которая помогала нам со
всеми контрактами и счетами.
У нас были замечательные редакторы издательства Microsoft Press, которые направля-
ли наши усилия и обеспечили высокое качество содержимого этой книги. Большое
спасибо Карэн Сзалл (Karen Szall) за то, что она направила нас по верному пути. Жюли
Хотчкисс (Julie Hotchkiss) и Мэган Смит-Крид (Megan Smith-Creed) были замечатель-
ными литературными редакторами. Они проделали отличную работу для того, чтобы
этот текст стал более понятным и лаконичным. И наконец, мы хотим поблагодарить
технического редактора Рэндэлла Галловэя (Randall Galloway) за его работу над этой
книгой.
Мелисса вон Тшуди-Саттон (Melissa von Tschudi-Sutton) была главным редактором
проекта, с ней было очень приятно работать. Мелисса постоянно контролировала про-
ект, и ее предложения были просто бесценными. Мелисса, мы ценим твою помощь и
верность проекту этой книги и были очень счастливы опять работать с тобой.
Мы хотели бы поблагодарить команду Windows Virtualization Product Team за помощь
в создании достойного сборника ресурсов Windows Server 2008 Hyper-V Resource Kit.
Многие члены команды рецензировали эту книгу, а также участвовали в создании ее
формы и содержимого. Они отвечали на сообщения по электронной почте и на вопро-
сы во время своей работы над версией Windows Server 2008 R2 Hyper-V. Мы благода-
рим всех и каждого из вас за сотрудничество и поддержку.
В частности, мы должны особо поблагодарить Арно Михма (Arno Mihm) и Джеффа
Вулсэя (Jeff Woolsey), наших основных контактеров из команды консультантов по про-
6 Благодарности
граммным продуктам. На вопросы по кодам нам отвечало несколько других разработ-

чиков. Эти люди очень помогли нам документировать информацию по Hyper-V, кото-
рая будет весьма интересна читателям этой книги. Спасибо вам всем за ваши усилия!
Мы хотели также, чтобы, помимо команды консультантов по программным продуктам,
каждую главу этой книги отрецензировали члены "полевой" команды Microsoft. Доб-
ровольно вызвались принять участие многие рецензенты из команд Microsoft
Consulting Services и Customer Support Services, а также из Microsoft Sales. Каждый, кто
участвовал в рецензировании этих глав, работал сверхурочно — и все они давали
предложения, которые существенно улучшили содержимое этой книги. Спасибо вам
еще раз за то, что вы уделили свое время для того, чтобы помочь нам и улучшить ко-
нечный продукт.
Мы также получили большую поддержку от Донны Бэкэр (Donna Becker) и Тима
Мьюэтлинга (Tim Mueting (компания AMD)), Джона Портерфилда (John Porterfield),
Шэйна Бартона (Shane Burton) и Джастина Брауна (Justin Brown (компания Compellent
Technologies)), а также от Трэвора МакГилла (Trevor McGill (компания Sun
Microsystems)). Они предоставили нам оборудование и свой опыт, что позволило нам
проверить технические сценарии на оборудовании промышленного уровня. Огромное
вам спасибо за совместную работу в течение длительного времени. Мы очень ценим
вашу поддержку и сотрудничество!
А вам, читатели, спасибо за то, что вы купили эту книгу! Мы усердно работали над ее
составлением и организацией содержимого таким образом, чтобы она стала ценным
источником информации, который поможет вам развернуть успешные решения на
основе технологии Hyper-V. Нас очень интересуют ваши комментарии, предложения и
вопросы. Пожалуйста, пишите нам об этой книге на адрес: askme@doingITvirtual.com.
Обычно мы отвечаем в течение 24 часов. Дополнительную информацию по технологи-
ям виртуализации вы можете получить в сообществе Doing IT Virtual по адресу:
http://doingitvirtual.com. Следите также за нашими блогами: http://doingitvirtual.com
/blogs/virtualzone/default.aspx и http://blogs.technet.com/roblarson.
С наилучшими пожеланиями,
Джени С. Карбон (Janique S. Carbone)
Managing Member, Infrastructor Group
http://www.doingitvirtual.com
Роберт Е. Ларсон (Robert E. Larson)
Architect, Microsoft Consulting Services
http://blogs.technet.com/roblarson
Введение
Добро пожаловать в сборник ресурсов "Windows Server 2008 Hyper-V Resource Kit"!
Это всесторонний источник технической информации по планированию, развертыва-
нию и управлению инфраструктурами виртуализации, выполненными на базе серверов
Windows Server 2008 Hyper-V и Microsoft Hyper-V Server 2008.
Технология виртуализации продолжает развиваться и изменяет те варианты и ту ско-
рость, с которыми отдел информационных технологий может реагировать на изме-
няющиеся потребности бизнеса (создавая мощные, гибкие и адаптируемые вычисли-
тельные среды). Многие организации могут использовать преимущества реализации
технологии Hyper-V (и в том числе получить экономию затрат, которой можно достичь
при помощи виртуализации рабочих нагрузок). Консолидация серверов, инфраструкту-
ра для тестирования и разработки, непрерывность бизнеса, филиалы предприятий —
вот некоторые принципиально возможные цели для решений на основе технологии
Hyper-V. Однако малый и средний бизнес также может получить выгоду от виртуали-
зации рабочих нагрузок. Поэтому наша цель — дать информацию и инструменты, ко-
торые могут быть полезными широкому спектру профессионалов в области информа-
ционных технологий.
В этом сборнике ресурсов вы найдете подробную информацию и процедуры, которые
помогут вам управлять всеми аспектами серверов Windows Server 2008 Hyper-V и Hy-
per-V Server 2008, в том числе по: ручной и автоматизированной инсталляции, конфи-
гурировании безопасности, отказоустойчивой кластеризации на уровне виртуальных
машин и на уровне хостов, процессам создания и миграции виртуальных машин, на-
блюдению, а также по способам резервного копирования и восстановления. Кроме то-
го, мы включили указания для помощи вам по всем аспектам проекта виртуализации
(начиная с ранней фазы представления и заканчивая фазой пилотного проекта).
В этой книге вы найдете многочисленные врезки, написанные членами команды
Windows Virtualization, команд Microsoft Consulting Services, Microsoft Support Services,
Microsoft Sales и Microsoft Partners, в которых даются подробности дизайна Hyper-V,
его функциональные возможности, а также лучшие практики и советы по оптимизации
(которые помогут вам получить от развертывания Hyper-V максимум возможного).
И наконец, на прилагаемом к книге компакт-диске имеются примеры скриптов, кото-
рые вы можете использовать для облегчения автоматизации различных аспектов
управления средой Hyper-V.
8 Введение
Поддержка Microsoft Partner

Многие из представленных в этой книге технических сценариев были сконфигуриро-
ваны и протестированы на оборудовании, которое было предоставлено компаниями
AMD, Compellent Technologies, Sun Microsystems, а также центром Microsoft Partner
Solutions Center. Все эти партнеры компании Microsoft не один раз продлевали нам
аренду своего оборудования (из-за изменений нашего графика), и все они очень преду-
предительно отвечали на наши вопросы и предоставляли техническую поддержку.
Для поддержки инсталляций, отказоустойчивой кластеризации и тестирования конфи-
гураций компания AMD предоставила нам оборудование промышленного уровня. Со-
трудники AMD (Донна Бэкэр (Donna Becker), Тим Мьюэтлинг (Tim Mueting) и Джон
МакКрай (John McCrae)) предоставили нам два сервера Dell PowerEdge 2970, снабжен-
ные двумя четырехъядерными процессорами Opteron 2356, с 16 Гбайт памяти, интег-
рированным контроллером RAID (модель Dell PERC 5/I), а также 300 Гбайт внутрен-
ней дисковой памяти. Конфигурация была усилена дополнительными 300 Гбайт внеш-
ней системы хранения на базе iSCSI.
Компании Compellent Technologies, Sun Microsystems, а также центр Microsoft Partner
Solutions Center предоставили оборудование и удаленный доступ к серверам промыш-
ленного класса, подключенным к сети хранения данных (SAN) компании Compellent
Storage Center. Джон Портерфилд (John Porterfield), Шэйн Бартон (Shane Burton) и
Джастин Браун (Justin Braun) — сотрудники компании Compellent Technologies — пре-
доставили свое время, опыт и помощь для сбора такой конфигурации оборудования,
которую можно было бы использовать для удаленного тестирования сценариев отказо-
устойчивой кластеризации. На системе SAN компании Compellent Storage Center было
сконфигурировано 10 Тбайт объема хранения уровня Tier-1 и 41 Тбайт объема хране-
ния уровня Tier-3.
Джон Портерфилд (компания Compellent Technologies) совместно с Трэвором МакГил-
лом (компания Sun Microsystems) на все время наших тестов зарезервировал за нами
несколько серверов. В частности, компания Sun Microsystems предоставила сервер Sun
X4450 с четырьмя четырехъядерными процессорами Intel X7350, 64 Гбайт памяти, че-
тырьмя дисками SAS по 146 Гбайт, четырьмя гигабитными сетевыми адаптерами
Ethernet, а также два сервера Sun X4150 с двумя четырехъядерными процессорами Intel
E5345, 16 Гбайт памяти, четырьмя дисками SAS по 146 Гбайт и четырьмя гигабитными
сетевыми адаптерами Ethernet.
Обзор книги
Четыре части этой книги охватывают следующие темы.
Часть I дает глубокое представление о функциональных возможностях серверов
Windows Server 2008 Hyper-V и Microsoft Hyper-V Server 2008, а также о подробно-
стях архитектуры этих продуктов.
Часть II дает глубокую информацию и указания по инсталляции серверов Windows
Server 2008 Hyper-V и Microsoft Hyper-V Server 2008 (с использованием расширен-
Введение 9
ных функциональных возможностей), по конфигурированию безопасности, по на-

стройке производительности, а также по переходу с сервера Virtual Server 2005 R2
на сервер Hyper-V. Там имеется также подробный обзор новых функциональных
возможностей, которые включены в версию Windows Server 2008 R2 Hyper-V.
Часть III описывает способы наблюдения за состоянием инфраструктуры Hyper-V
при помощи таких инструментов, как менеджер System Center Virtual Machine Man-
ager 2008, программа Windows Backup Server, менеджер System Center Data Protec-
tion Manager SP1, а также пакет управления Windows Server 2008 Hyper-V Manage-
ment Pack для менеджера System Center Operations Manager 2007. Эта часть книги
содержит также информацию, которая поможет вам разрабатывать скрипты при
помощи интерфейса прикладного программирования Windows Management Instru-
mentation (WMI) и инструмента написания скриптов Windows PowerShell.
Часть IV определяет наиболее часто встречающиеся сценарии виртуализации сер-
веров, основные (составляющие решение VDI) концепции и компоненты, а также
дает исчерпывающее руководство по управлению проектом виртуализации (начиная
с фазы представления и заканчивая фазой развертывания пилотного проекта).
Используемые условные обозначения

В книге для выделения особых характеристик используются некоторые условные обо-
значения.
Помощники читателя
Для выделения полезной информации используются следующие помощники читателя.
ПРИМЕЧАНИЕ
Подчеркивает важность данной концепции или выделяет специальный случай, который
возможно применим не в любой ситуации.
ВАЖНО
Привлекает внимание к существенной информации, которой не следует пренебрегать.
ВНИМАНИЕ!
Предупреждает вас о том, что невозможность выполнить указанное действие может при-
вести к серьезным проблемам для пользователей, систем, целостности данных и т. д.
На компакт-диске
Привлекает внимание к имеющемуся на прилагаемом к книге компакт-диске материалу, ко-
торый поможет вам выполнить описываемую в тексте задачу.
Лучшие практики
Дает советы по опыту, полученному при использовании и развертывании данных продуктов
командой Windows Virtual Team.
10 Введение
Дополнительная информация
Содержит ссылки на другие важные справочные материалы, такие как документация по
продуктам, соответствующие Web-сайты, другие книги (либо на другие разделы этой же
книги).
Врезки
В данной книге для предоставления дополнительных соображений, подсказок и сове-
тов (по различным функциональным возможностям Hyper-V) используются следующие
врезки.
И НФОРМАЦИЯ ИЗ ПЕРВОИСТОЧНИКА
Предоставлены специалистами продуктовой команды Windows Virtualization для того, чтобы
вы получили (непосредственно из первоисточника) информацию о том, как работает Hyper-V,
о лучших практиках, а также подсказки по поиску проблем.
И НФОРМАЦИЯ С МЕСТА СОБЫТИЙ

Предоставлены специалистами Microsoft Consulting Services, Microsoft Customer Support
Services, Microsoft Sales, а также Microsoft Partners, чтобы вы получили "непосредственно
с места событий" информацию о том, как работает Hyper-V, о лучших практиках, а также
подсказки по поиску проблем.
К АК ЭТО РАБОТАЕТ
Обеспечивает быстрое знакомство с функциональными возможностями технологий и с тем,
как они работают.
Врезки написаны специалистами исключительно в информационных целях и могут

отличаться от мнения их работодателей. Относительно информаций во врезках не да-
ется никаких гарантий (ни прямых, ни подразумеваемых).
Примеры командной строки

При документировании примеров командной строки используются следующие услов-
ные обозначения:
Стиль Значение
Жирный шрифт Используется для указания элементов интерфейса

Курсив Используется для указания важных терминов
Моноширинный Используется для образцов кода и вывода в командной строке, переменных
шрифт
%SystemRoot% Используется для переменных среды
На прилагающемся компакт-диске
Прилагающийся компакт-диск является ценным дополнением к этой книге и содержит
следующее.
Скрипты и вспомогательные материалы. Образцы скриптов на языках Visual Basic
Scripting Edition (VBScript) или Windows PowerShell (для администрирования раз-
Введение 11
личных аспектов инфраструктур Hyper-V). Эти скрипты можно использовать либо в

том виде, как они есть, либо их можно адаптировать под ваши административные
потребности. Включены также упомянутые в тексте книги вспомогательные мате-
риалы.
Бонусы и ссылки на ресурсы. В каталоге Bonus Content вы найдете электронную
версию книги "Understanding Microsoft Virtualization" издательства Microsoft Press.
На странице Resources and Tools вы найдете многочисленные ссылки на полезные
ресурсы и инструменты, найденные авторами этого сборника ресурсов.
eBook. На прилагающемся компакт-диске имеется также электронная версия этого
сборника ресурсов "Windows Server 2008 Hyper-V Resource Kit".
Полное описание содержимого и структуры прилагающегося диска вы можете найти
в файле Readme.txt на диске.
Для читателей электронной версии книги. Если вы купили только электронный ва-
риант этой книги, то можете получить некоторые части содержимого диска печатной
версии. Зайдите по ссылке: http://go.microsoft.com/fwlink/?LinkId=149827 и скачайте
это содержимое. Оно всегда актуально и доступно всем читателям.
Системные требования
Далее приводятся минимальные системные требования для работы с прилагаемым
к этой книге диском:
Windows Server 2008 или Windows Vista Service Pack 1;
Windows PowerShell 1.0 или более поздняя версия (для скриптов);
Microsoft Office 2003 или более поздняя версия (для вспомогательных электронных
таблиц);
дисковод DVD;
подключение к Интернету;
монитор с разрешением 1024×768;
мышь Microsoft Mouse или совместимое с ней устройство;
программа Adobe Reader или другое средство просмотра файлов формата PDF (для
чтения электронной версии книги).
Использование скриптов
Скрипты с прилагающегося компакт-диска необходимо выполнять при помощи
Cscript.exe или Windows PowerShell. Это можно делать несколькими способами.
Ввести в командной строке
cscript script_name.vbs <parameters>
Чтобы получить список имеющихся параметров, введите в командной строке
cscript script_name.vbs /?
либо откройте скрипт в редакторе Notepad и прочитайте комментарии скрипта.

12 Введение
Настройте сервер скриптов локального компьютера по умолчанию на Cscript.exe

(чтобы вы могли запускать скрипты при помощи ввода в командной строке команд
типа: script_name.vbs <parameters>). Чтобы настроить сервер скриптов на
Cscript.exe, введите в командной строке cscript //h:cscript //nologo //s.
Для Windows PowerShell 1.0 откройте окно команд PowerShel. Для этого нажмите
кнопку Start, затем выберите Run, введите powershell и нажмите кнопку OK. Вы
можете также запустить Windows PowerShell 1.0 из меню Start. Для этого нажмите
кнопку Start, потом выберите All Programs | Windows PowerShell | Windows
PowerShell.
Для Windows PowerShell 2.0 нажмите кнопку Start, потом выберите All Programs |
Windows PowerShell | Windows PowerShell V2. Либо вы можете выбрать Windows
PowerShell V2 ISE, чтобы открыть интегрированную среду Windows PowerShell V2
Integrated Scripting Environment.
Чтобы все работало как следует, большинство скриптов надо выполнять с повышен-
ными привилегиями. Для того чтобы открыть администраторскую командную строку
в Windows Vista, нажмите кнопку Start и выберите пункт All Programs | Accessories,
щелкните правой кнопкой мыши по пункту Command Prompt, а потом выберите Run
As Administrator. (Либо можно создать ярлык для командной строки с повышенными
привилегиями и сохранить его на панели быстрого запуска.)
Политика поддержки сборника ресурсов

Для обеспечения точности этой книги (с прилагающегося компакт-диска) были пред-
приняты все необходимые усилия. Исправления к тексту этой книги компания Micro-
soft предоставляет через Интернет по следующей ссылке:
http://www.microsoft.com/learning/en/us/book.aspx?ID=11842&locale=en-us#tab1
Если у вас есть комментарии, вопросы или идеи относительно данной книги или со-
держимого прилагающегося к ней диска; либо если у вас есть вопросы, ответы на ко-
торые вы не получили в Knowledge Base, то, пожалуйста, направляйте их в издательст-
во Microsoft Press одним из следующих способов:
по электронной почте: rkinput@microsoft.com;
обычной почтой:
Microsoft Press
Attn: Windows Server 2008 Hyper-V Resource Kit editor
One Microsoft Way
Redmond, WA 98052-6399
Пожалуйста, учтите, что по вышеуказанному адресу электронной почты техническая
поддержка продукта не предоставляется. Для получения информации технической
поддержки продукта обращайтесь на сайт Microsoft Product Support по адресу:
http://support.microsoft.com.
часть I
Приступаем к изучению
Windows Server 2008 Hyper-V
Глава 1. Представляем виртуализацию
Глава 2. Обзор Hyper-V
Глава 3. Архитектура Hyper-V

ГЛАВА 1
Представляем виртуализацию
Цель этой книги — дать глубокое объяснение новой технологии виртуализации компа-
нии Microsoft, которая называется Windows Server 2008 Hyper-V. Hyper-V является раз-
витием технологии виртуализации от архитектуры на основе хостов Microsoft Virtual
Server 2005 R2 (которая работает поверх операционной системы Windows) до архитек-
туры на базе гипервизора. Гипервизор Windows внутри Hyper-V — это слой программ-
ного обеспечения, который выполняется непосредственно на физическом оборудова-
нии и делает возможной работу множества изолированных сред (или разделов) с обо-
собленными наборами виртуализированных ресурсов, а также ведет арбитраж доступа
к физическому оборудованию. Короче говоря, гипервизор Windows — это базовый
элемент, делающий Hyper-V безопасным и масштабируемым решением виртуализации,
которое вы можете использовать для поддержки широкого разнообразия сценариев
развертывания.
Перед тем, как перейти непосредственно к техническим подробностям, которые вам
понадобятся для планирования, развертывания и управления основанной на Hyper-V
виртуализированной инфраструктуры, эта глава даст вам обзор основных методик вир-
туализации, чтобы помочь понять, каково место Hyper-V в спектре современных тех-
нологий. Кроме того, вы получите более подробное объяснение различных техниче-
ских и бизнес-сценариев, для которых подходит решение на базе Hyper-V (чтобы по-
мочь вам создать и представить четкий вариант своего проекта виртуализации
серверов вашим коллегам и руководству).
Разбираемся с виртуализацией
В течение последних нескольких лет многие организации обратились к технологии
виртуализации с целью консолидации физических серверов (чтобы противостоять
"расползанию" серверов), а также для снижения затрат центров обработки данных на
электроэнергию, охлаждение и аренду площадей. Несколько позже появились и техно-
логии виртуализации для настольных компьютеров и приложений. Они прижились как
способ упрощения развертывания инфраструктуры конечных пользователей и управ-
ления ею. Отделы информационных технологий поняли, что виртуализированная ин-
16 Часть I. Приступаем к изучению Windows Server 2008 Hyper-V
фраструктура представляет собой более гибкую в управлении среду и помогает быст-

рее адаптироваться к изменению потребностей бизнеса.
Основы виртуализации
Виртуализацию (в контексте такого программного обеспечения, как Microsoft Hyper-V
Server и Virtual Server 2005 R2) можно описать как абстрагирование физических ресур-
сов системы, позволяющее создавать множество логических разделов, в которых будут
работать различные операционные системы (одновременно на одном физическом сер-
вере). Каждый раздел (называемый также виртуальной машиной) — это программная
среда, которая предоставляет ресурсы (при помощи эмуляции оборудования или уст-
ройств). Поверх нее можно инсталлировать операционную систему, а также одно или
несколько приложений. Несмотря на то, что виртуализация в совместимых с процессо-
ром х86 информационных средах получила бурное развитие только в текущем десяти-
летии, сама эта технология появилась более 40 лет назад.
Начало коммерческой технологии виртуализации было положено компанией IBM
в середине шестидесятых годов прошлого века, когда компьютер System/360 Model 67
позволял поддерживать несколько одновременно работающих гостевых виртуальных
машин (в каждой из которых могла работать однопользовательская операционная сис-
тема). Компания IBM достигла этого путем разработки двух отдельных операционных
систем — Virtual Machine (VM) и Conversational Monitor System (CMS), которые обыч-
но обозначаются как VM/CMS. VM создавала виртуальные машины и управляла ими, а
CMS (однопользовательская операционная система) работала внутри виртуальной ма-
шины, предоставляя доступ к ресурсам системы каждому пользователю. В настоящее
время компания IBM продолжает разрабатывать и продвигать VM (после изменения
бренда она называется z/VM), которая может теперь даже выполнять внутри виртуаль-
ной машины саму себя (причем с несколькими уровнями вложенности).
Виртуализация на основе процессоров семейства х86

В последнее десятилетие исследования технологии виртуализации (и разработка соот-
ветствующих продуктов) пошли на подъем с акцентом на использование платформ х86
(как 32-, так и 64-битных). В 2006 г. компании AMD и Intel выпустили версии процес-
соров семейства х86 с новыми инструкциями и расширениями, которые были предна-
значены специально для аппаратной поддержки виртуализации. Несмотря на то, что
детали этих реализаций отличаются, технологии AMD Virtualization (AMD-V) и Intel
Virtualization Technology (VT) предоставили такие аппаратные возможности виртуали-
зации, которые могут быть использованы поставщиками программного обеспечения
для упрощения кодов их программных продуктов виртуализации и для развития самой
архитектуры решений виртуализации.
В 2007—2008 гг. расширения технологий AMD-V и Intel VT (появившиеся с выпуском
64-битных двух- и четырехъядерных процессоров AMD и Intel) оказали существенное
влияние на разработку кода для Hyper-V. Компания Microsoft и другие поставщики
программного обеспечения для виртуализации продолжают работать с AMD и Intel,
чтобы совместно находить те способы оптимизации и улучшения, которые появятся
в будущих процессорах.
Глава 1. Представляем виртуализацию 17
Основы архитектуры AMD-V
Виртуализация AMD (обозначается AMD-V) — это процессорная архитектура Secure Virtual
Machine (SVM), которая позволяет разработчикам программного обеспечения реализовы-
вать безопасные виртуальные решения и снижать сложность программного кода. В сле-
дующем списке приведены основы архитектуры AMD-V SVM, которые чаще всего упомина-
ются в контексте такого программного обеспечения, как Hyper-V.
• Режим хоста Host Mode позволяет гипервизору (а в более общем случае — монитору
виртуальных машин Virtual Machine Monitor, VMM) выполняться с самым высоким уров-
нем привилегий. Этот режим выполнения иногда называется режимом Ring –1 (Коль-
цо –1).
• Гостевой режим Guest Mode позволяет гостевой операционной системе выполняться
в привилегированном режиме (Ring 0), а стек приложения работает в пользовательском
режиме (Ring 3).
• Виртуализация поддерживается восемью инструкциями SVM (в том числе VMRUN, ко-
торая позволяет производить переключение контекста из режима хоста в гостевой ре-
жим — для загрузки и выполнения новой гостевой операционной системы).
• Структура данных Virtual Memory Control Block (VMCB) содержит информацию о состоя-
нии гостя (в том числе настройки, которые определяют перехваты; а также инструкции,
которые вызывают переходы из гостевого режима в режим хоста).
• Address Space Identifier (ASID) — это уникальный идентификатор в буфере быстрой
трансляции адреса (Translation-Lookaside Buffer, TLB), который позволяет различать
элементы хоста и гостевых систем и помогает повысить производительность переклю-
чения контекста. TLB — это кэш процессора, который содержит соответствия виртуаль-
ных адресов памяти физическим. Каждое ядро процессора имеет свой TLB.
• Одновременная поддержка 16-, 32- и 64-битных гостевых операционных систем.
• Индексация Rapid Virtualization Indexing (именуемая также Nested Paging) обеспечивает
трансляцию процессором пространства адресов памяти гостевой системы сначала
в виртуальное адресное пространство хоста, а затем и в физическое пространство
адресов хоста.
• I/O Memory Management Unit (IOMMU) — это технология виртуализации, которая позво-
ляет гостевым операционным системам (выполняющимся в виртуальных машинах) на-
прямую использовать периферийные устройства, подключенные к хост-серверу.
Функции Rapid Virtualization Indexing и IOMMU архитектуры AMD-V SVM в начальной версии
Hyper-V не используются, но они могут быть в последующих версиях этого продукта.
Более подробную информацию по AMD-V см. в документации AMD64 Architecture Tech
Docs по ссылке:
http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_739_7044,00.html.

Основы виртуализации систем
Для того чтобы должным образом виртуализировать и изолировать виртуальную машину,
гипервизор должен управлять всеми привилегированными операциями, выполняемыми
виртуальной машиной (или быть посредником при их выполнении). Для этого гипервизор
может использовать виртуализацию с поддержкой аппаратного обеспечения. При такой ап-
паратной виртуализации гипервизор использует процессорные расширения (такие, как
AMD-V) для перехвата и эмуляции привилегированных операций в гостевой системе.
В определенных случаях технология AMD-V позволяет гипервизору указать, как процессор
может обрабатывать привилегированные операции внутри самой гостевой системы (без
передачи управления гипервизору).
Виртуализация страничной организации процессора х86

Для обеспечения защиты и изоляции гостевых систем гипервизор должен контролировать
трансляцию адресов на процессоре, для чего (при активных гостевых системах) фактически
необходимо реализовать еще один уровень трансляции адресов. Этот дополнительный
уровень трансляции устанавливает соответствие между представлением гостевой системы
о физической памяти и представлением хост-системы о физической памяти.
Для немодифицированных гостевых систем гипервизор должен полностью виртуализиро-
вать трансляцию адресов х86, что может привести к значительным накладным расходам.
Программные методики виртуализации трансляции адресов

Программные методики поддерживают теневую версию таблицы страниц, полученную из
гостевой таблицы страниц (guest page table, GPT). Когда гостевая система активна, то ги-
первизор заставляет процессор использовать для трансляции адресов теневую таблицу
(shadow page table, SPT). Гостевой системе SPT не видна.
При гостевых SMP-системах теневая организация страниц может привести к существенным
дополнительным расходам памяти и производительности. В гостевой SMP-системе один и
тот же экземпляр GPT может использоваться при трансляции адресов для более чем одно-
го процессора. В таком случае гипервизор должен либо поддерживать экземпляры SPT для
каждого процессора, либо совместно использовать SPT для нескольких виртуальных про-
цессоров. Первый вариант приводит к большому расходу памяти, второй — к большим рас-
ходам на синхронизацию.
Есть оценки, что для некоторых рабочих нагрузок издержки на теневую организацию стра-
ниц могут составлять 75% всех дополнительных издержек, связанных с гипервизором.
Индексирование AMD-V (Rapid Virtualization Indexing)

Во избежание программных издержек на теневую организацию страниц, четырехъядерные
процессоры AMD64 имеют функцию AMD-V под названием AMD-V Rapid Virtualization
Indexing (RVI). RVI использует дополнительную вложенную таблицу страниц (nested page
table, NPT)) для трансляции физических адресов гостевой системы в физические адреса
хост-системы и оставляет гостевой системе полное управление ее таблицами страниц.
В данном случае (в отличие от использования теневой организации страниц) после запол-
нения вложенных страниц гипервизору не нужно перехватывать и эмулировать модифика-
цию гостевой системой таблицы GPT.
RVI предназначена для снижения накладных расходов на теневую организацию страниц.
Однако поскольку RVI вводит дополнительный уровень трансляции, то стоимость промаха
TLB может стать больше. RVI дает повышение производительности для интенсивно рабо-
тающих с памятью рабочих нагрузок (с высокой частотой переключения контекста и высо-
ким процентом успешных обращений к TLB).
Подробности
При использовании вложенных таблиц страниц и гостевая система, и гипервизор имеют
свои копии состояния процессора (которое влияет на организацию страниц).
GPT устанавливает соответствия между линейными и физическими адресами гостевой
системы. Вложенные таблицы страниц NPT отображают физические адреса гостевых сис-
тем на физические адреса хост-системы.
Таблицы гостевых систем и вложенные таблицы страниц настраиваются соответственно
гостевыми системами и гипервизором. Когда гостевая система пытается сделать ссылку на
память при помощи линейного адреса и включена вложенная организация страниц, то де-
лаются два прохода при помощи GPT и NPT (для трансляции линейного адреса гостевой
системы в физический адрес хост-системы).
Когда проход будет завершен, элемент TLB (содержащий трансляцию из линейного адреса
гостевой системы в физический адрес хост-системы) кэшируется в TLB и используется при
последующем доступе к этому же линейному адресу.
Процессоры AMD (которые поддерживают RVI и вложенные таблицы) имеют вложенный

TLB, кэширующий трансляции физических адресов гостевой системы в физические адреса
хост-системы (для ускорения проходов по вложенным таблицам страниц). Вложенный TLB
использует высокую локальность структур гостевых таблиц страниц и существенно повы-
шает процент успешных обращений к TLB.
Экономия памяти при помощи NPT

В отличие от теневой организации страниц (которая требует от гипервизора поддержки эк-
земпляра SPT для каждой GPT), при использовании вложенной организации страниц ги-
первизор может настроить единственный экземпляр NPT для того, чтобы отобразить все
физическое адресное пространство гостевой системы. Поскольку память гостевой системы
компактна, то NPT обычно расходует гораздо меньше памяти, чем эквивалентная реализа-
ция на базе теневой организации страниц.
Заключение
Индексирование Rapid Virtualization Indexing уменьшает накладные расходы на виртуализа-
цию, связанные с традиционными программными алгоритмами теневой организации стра-
ниц. В сочетании с другими архитектурными и микроархитектурными улучшениями, имею-
щимися в четырехъядерных процессорах AMD64, RVI может дать виртуальным средам вы-
игрыш в производительности (особенно для интенсивно работающих с памятью рабочих
нагрузок, имеющих высокую частоту переключения контекста).
Тим Мьюэтлинг (Tim Muetling, Virtualization Solutions Manager
(Advanced Micro Devices, Inc.))

Технология виртуализации ввода/вывода AMD
Технология виртуализации ввода/вывода компании AMD помогает увеличить производи-
тельность, безопасность и надежность виртуализации устройств. Впервые опубликованная
в феврале 2006 г., спецификация IOMMU (I/O Memory Management Unit) определяет мето-
дику для абстрагирования устройств в виртуальных средах и дает возможность программ-
ному обеспечению отображать устройства напрямую на виртуальные машины (VM). Вир-
туализация ввода/вывода реализована в основном в мостах ввода/вывода микропроцес-
сорных наборов и в других базовых компонентах системной логики.
IOMMU обеспечивает изоляцию устройств (путем ограничения доступа адаптера к опреде-
ленной области памяти, который разрешается модулем IOMMU). Без изоляции адаптер мог
бы разрушить содержимое памяти, создав угрозу для безопасности или готовности сис-
темы.
IOMMU поддерживает виртуализацию при помощи предоставления трансляции адресов
для периферийных устройств (аналогичной трансляции адресов процессора). Это помогает
улучшить производительность посредством переноса дополнительной трансляции адресов
(необходимой программному обеспечению виртуализации) в аппаратное обеспечение.
IOMMU может создать уникальное пространство транслированных адресов (независимое
от любого адресного пространства, созданного модулем управления памятью Memory
Management Unit (MMU) процессора), которое может установить соответствие между адре-
суемым диапазоном устройства и любым местом памяти хост-системы.
Технология виртуализации ввода/вывода AMD определяет IOMMU, который предназначен
для трансляции и защиты памяти при любой передаче периферийным устройством в ре-
жиме DMA. Устройства назначаются в защищенную область с набором таблиц страниц
ввода/вывода (определяющими разрешенные адреса памяти). При каждой передаче в ре-
жиме DMA модуль IOMMU перехватывает доступ для данного устройства (используя его
кэш или IOTLB для эффективной трансляции). Аналогичным же образом можно перехва-
тить каждое прерывание устройства и переназначить его тому процессору, который лучше
других подготовлен к обработке данного прерывания.
Функции трансляции и изоляции в IOMMU могут использоваться независимо от аппаратной

или программной виртуализации; однако эти средства являются естественным расширени-
ем виртуализации.
Тим Мьюэтлинг (Tim Muetling, Virtualization Solutions Manager
(Advanced Micro Devices, Inc.))
Основы архитектуры Intel VT
Технология виртуализации Intel Virtualization Technology (Intel VT) представляет собой архи-
тектуру процессора, которая поддерживает приложения программной виртуализации при
помощи набора расширений, называемых расширениями виртуальной машины (Virtual
Machine Extensions, VMX). В следующий список включены те основные характеристики Intel
VT VMX, которые обычно упоминаются в контексте виртуализационного программного
обеспечения (такого, как Hyper-V).
• Режим работы VMX Root позволяет гипервизору или VMM выполняться в режиме с пол-
ными привилегиями.
• Режим работы VMX Non-Root позволяет гостевой операционной системе выполняться
в кольце Ring 0, а стеку приложений — в кольце Ring 3.
• Виртуализация поддерживается десятью инструкциями VMX, в том числе VMLAUNCH
(которая позволяет переключению контекста загрузить и выполнить новую гостевую
операционную систему).
• Структура данных Virtual Memory Control Data Structure (VMCS) содержит информацию
состояния гостевой и хост-систем, а также поля VMX, используемые для управления
переходами между режимами работы VMX Root и VMX Non-Root.
• Virtual Processor Identifier (VPID) — это уникальный идентификатор, хранящийся в VMCS
(для различения элементов хоста и гостевой системы). Элементы TLB помечены соот-
ветствующим значением VPID, что позволяет при переключениях контекста не делать
лишних сбросов и перезагрузок TLB.
• Одновременная поддержка 16-, 32- и 64-битных гостевых операционных систем.
• Таблицы Extended Page Tables (EPT) обеспечивают выполнение процессором трансля-
ции физического адресного пространства гостевой системы в физическое адресное
пространство хост-системы.
• Технология виртуализации направленного ввода/вывода Virtualization Technology for
Directed I/O (VT-d) обеспечивает прямое назначение и использование устройств (под-
ключенных к хост-системе) из гостевых операционных систем, работающих в виртуаль-
ных машинах.
Hyper-V в своей начальной версии не использует функции Extended Page Tables и VT-d ар-
хитектуры Intel VT (как и функции Rapid Virtualization Indexing и IOMMU архитектуры AMD-V).
Вы видите, что архитектуры Intel VT и AMD-V предлагают разработчикам программных при-
ложений для виртуализации очень сходную функциональность (хотя реализация этих воз-
можностей и их набор отличаются).
Более подробную информацию по Intel VT вы можете найти в руководствах для разработ-
чиков программного обеспечения для архитектур Intel 64 и IA-32 по ссылке:
http://www.intel.com/products/processor/manuals/.
Слабые (в смысле виртуализации) места традиционной процессорной платформы х86

не помешали разработчикам программного обеспечения создать свои решения еще до
появления архитектур Intel VT и AMD-V. Для работы на исходной архитектуре процес-
сора х86 было фактически создано несколько технологий виртуализации (с использо-

ванием разнообразных методик, которые отличались по своему уровню абстракции и
были предназначены для конкретных областей этой проблемы).
Что такое программная виртуализация?

Программная виртуализация включает в себя различные методики для обеспечения
работы на одной физической хост-системе нескольких безопасных и изолированных
разделов (совместно и одновременно использующих ресурсы). Эти подходы отличают-
ся по плотности разделов (количеству одновременных разделов), масштабируемости,
производительности и разнообразию поддерживаемых операционных систем.
Виртуализация на уровне машины

В основе решения виртуализации на уровне машины лежит монитор виртуальных ма-
шин (Virtual Machine Monitor, VMM). VMM отвечает за создание и изоляцию вирту-
альной машины и сохранение ее состояния, а также за организацию доступа к систем-
ным ресурсам. Схема VMM зависит от архитектуры конкретного процессора; несмотря
на то, что VMM позволяет работать внутри виртуальной машины немодифицирован-
ным операционным системам, вы обычно ограничены теми операционными система-
ми, которые могут работать на данном физическом системном процессоре.
На рис. 1.1 показаны три разные реализации VMM: тип 2, гибридная модель и тип 1.
VMM типа 2 работает над операционной системой хоста (как Java VM). В гибридной
модели VMM работает как равноправный с операционной системой модуль. Так реа-
лизован сервер Virtual Server 2005 R2. В отличие от него VMM типа 1 (гипервизор) ра-
ботает непосредственно на аппаратном обеспечении (ниже разделов виртуальных ма-
шин). Продукт Microsoft Hyper-V выполнен как гипервизор.
Рис. 1.1. Типы мониторов виртуальных машин
В смысле производительности гипервизор (VMM типа 1) обычно способен дать более

высокий уровень эффективности и, следовательно, большую плотность виртуальных
машин. Другие типы VMM при доступе к ресурсам зависят от операционной системы
хоста, что приводит к более дорогим переключениям контекста и более значительным
потерям производительности.
При реализации VMM для создания интерфейса между виртуальными машинами и

виртуализированными системными ресурсами используются три возможных метода:
полная виртуализация, собственная виртуализация и паравиртуализация.
Полная виртуализация
При использовании этого метода монитором VMM (для абстрагирования виртуальной
машины от реального оборудования) создается и поддерживается полная виртуальная
система. Этот подход позволяет выполнять в виртуальной машине операционную сис-
тему без всяких ее модификаций. Сервер Virtual Server 2005 R2 использует этот способ
вместе с двоичной трансляцией (процесс, который позволяет VMM обрабатывать не-
виртуализируемые инструкции х86 для обеспечения виртуализации систем на предше-
ствовавших Intel VT и AMD-V архитектурах процессоров).
Преимуществом полной виртуализации и подхода с полным развязыванием физиче-
ского оборудования и виртуальной машины является способность легко переносить
виртуальные машины между серверами с различными физическими конфигурациями.
Такая гибкость достигается ценой потери производительности из-за накладных расхо-
дов на обслуживание состояний виртуальных машин и задержек при двоичной транс-
ляции.
Собственная виртуализация
Такая виртуализация зависит от архитектуры виртуализируемого процессора (напри-
мер, такой, как в сериях процессоров AMD-V и Intel VT). Эти процессоры имеют в
своей аппаратной части новые режимы выполнения, инструкции и структуры данных,
которые предназначены для уменьшения сложности VMM.
При собственной виртуализации монитору VMM больше не требуется поддерживать в
программном обеспечении характеристики ресурсов виртуальной машины и ее состоя-
ние. Точно так же, как и в случае полной виртуализации, внутри виртуальных машин
операционные системы могут выполняться без их модификации. Hyper-V использует
этот метод для работы устаревших операционных систем.
Такой тип реализации имеет много потенциальных преимуществ — от упрощения ар-
хитектуры VMM и до существенного повышения производительности (в результате
снижения накладных расходов программного обеспечения). При помощи снижения
накладных расходов на виртуализацию можно достичь более высокой плотности раз-
делов в системе.
Virtual Server 2005 R2 — решение виртуализации на основе хоста
В компании Microsoft решения виртуализации подразделяются на две категории: на основе
хоста и на базе гипервизора. Virtual Server 2005 R2 — это решение виртуализации на осно-
ве хоста, поскольку сервер работает поверх операционной системы Windows. При стан-
дартном (невиртуализированном) программном стеке Windows операционная система
работает на самом высоком уровне привилегий х86 (Ring 0, "привилегированный" режим), а
приложения — на самом низком уровне привилегий (Ring 3, "пользовательский" режим).
В Virtual Server 2005 R2 монитор VMM инсталлируется как драйвер уровня ядра, который
работает на том же уровне, что и ядро операционной системы Windows (уровень Ring 0).
Когда нужно выполнять виртуальную машину, управление передается ядру операционной

системы, и VMM переключается на процессор для выполнения гостевой операционной сис-
темы виртуальной машины. Несмотря на то, что гостевая система думает, будто она вы-
полняется в Ring 0, она на самом деле выполняется в промежуточном режиме Ring 1. При-
ложения в гостевой операционной системе продолжают выполняться в Ring 3. Этот метод
называется сжатием колец.
Использование метода сжатия колец требуется из-за семнадцати имеющихся в процессоре
х86 инструкций, которые не могут быть полностью виртуализированы (но могут привести к
сбою и останову системы). Поэтому (для сохранения целостности состояния системы) VMM
перехватывает и транслирует инструкции гостевой операционной системы в инструкции
операционной системы хоста (процесс двоичной трансляции), передавая управление об-
ратно ядру операционной системы Windows тогда, когда требуется доступ к аппаратному
ресурсу или происходит такая ситуация, которую VMM обработать не может. В версии
Virtual Server 2005 R2 SP1 добавлено использование аппаратной поддержки виртуализа-
ции, имеющейся в процессорах семейств AMD-V и Intel VT, но она по-прежнему остается
решением на основе хоста, поскольку работает поверх его операционной системы
Windows.
Паравиртуализация
Паравиртуализация была разработана как альтернатива использованию двоичной
трансляции при обработке невиртуализируемых инструкций процессора х86. При этом
подходе требуется модификация гостевых операционных систем (для того, чтобы сде-
лать возможными "гипервызовы" от виртуальной машины к гипервизору). Вместо вы-
полнения (для обеспечения сохранности системного состояния) гипервизором (или
монитором VMM) трансляции потенциально небезопасной инструкции гостевой опе-
рационной системы, для управления изменением состояния системы делается структу-
рированный гипервызов от гостя к гипервизору.
Строгая реализация паравиртуализации дает повышение производительности на стан-
дартном оборудовании х86 (за счет ликвидации дорогих операций при полной виртуа-
лизации и двоичной трансляции). Однако это делается за счет отсутствия поддержки
немодифицированных гостевых операционных систем и миграции виртуальных машин
обратно на физический сервер. Учитывая эти ограничения, программные продукты на
основе паравиртуальных реализаций используют также и аппаратную виртуализацию
(для работы немодифицированных операционных систем). Такой подход позволяет
предоставить более широкую поддержку, охватывающую и устаревшие операционные
системы (которые вряд ли будут модифицироваться), а также позволяет обновлять бо-
лее новые операционные системы (используя те улучшения и повышение производи-
тельности, которые можно получить от паравиртуализации).
Пионером в реализации паравиртуализации была компания XenSource (недавно куп-
ленная компанией Citrix), которая создала решение виртуализации с открытым кодом
под названием Xen. Первоначальные версии Xen поддерживало только несколько мо-
дифицированных операционных систем. С выпуском версии Xen 3.0 (которая исполь-
зует аппаратную поддержку виртуализации архитектур AMD-V и Intel VT) в гостевой
виртуальной машине стало можно выполнять немодифицированную операционную
систему Windows XP.
В июле 2006 г. компании Microsoft и XenSource заключили соглашение о поддержке
такого взаимодействия, которое позволило бы модифицированным для Xen виртуаль-
ным машинам Linux мигрировать на Hyper-V, а виртуальным машинам Windows — на

решение Xen. Компании Microsoft и Citrix продолжают это сотрудничество (которое
было начато с компанией XenSource). Фактически Citrix разработала слой адаптации,
который устанавливает соответствие между интерфейсом прикладного программиро-
вания гипервызовов Citrix и таким же интерфейсом Hyper-V (а также сетевые драйверы
и драйверы систем хранения для поддерживаемых дистрибутивов Linux). Эти драйве-
ры обеспечивают повышение производительности при их инсталляции в гостевую опе-
рационную систему Linux, работающую на Hyper-V.
XenServer компании Citrix — это современный продукт виртуализации серверов, разрабо-
танный на базе кодов компании XenSource. Citrix также предлагает продукт для виртуали-
зации приложений под названием XenApp и продукт для виртуализации рабочих столов
с названием XenDesktop. Более подробную информацию по продуктам виртуализации ком-
пании Citrix см. по ссылке: http://www.citrix.com/English/ps2/category.asp.
Hyper-V — решение виртуализации на основе гипервизора
Компания Microsoft делит решения виртуализации на две категории: на основе хоста и на
базе гипервизора. В отличие от Virtual Server 2005 R2, Hyper-V является гипервизором, по-
скольку он загружается и выполняется непосредственно поверх аппаратного уровня. Такая
реализация часто называется "чисто аппаратной виртуализацией". Для Hyper-V требуется
64-битный процессор (платформы AMD-V или Intel VT). Как уже пояснялось, в AMD-V и Intel
VT добавлены два новых режима: один для выполнения гипервизора с полными привиле-
гиями (иногда называемый Ring –1), а другой — для выполнения гостевых операционных
систем и стека приложений (Ring 0 и Ring 3 соответственно). Такая реализация избавляет
от необходимости использовать механизм сжатия колец (который применялся в Virtual
Server 2005 R2). Hyper-V не работает на 32-битных процессорах х86 или на 64-битных про-
цессорах Itanium. По существу гипервизор Windows управляет доступом к физическим ап-
паратным ресурсам из изолированных сред выполнения (называемых разделами). Каждый
раздел представляет собой виртуальную машину, которая предоставляет виртуализиро-
ванный набор аппаратных ресурсов гостевой операционной системе и приложениям.
Hyper-V поддерживает собственную виртуализацию для устаревших операционных систем
(до Windows Server 2003 включительно), которые работают без служб Integration Services, а
также реализует паравиртуализацию. Интерфейс гипервызовов позволяет гостевым вирту-
альным машинам делать запросы к гипервизору Windows. Windows Vista и Windows Server
2008 — первые операционные системы семейства Windows, содержащие модификации для
паравиртуализации (которые компания Microsoft называет "просвещенностью"). Эта про-
свещенность позволяет Windows Vista и Windows Server 2008 определить, что они выпол-
няются в виртуальной машине, а также обеспечивает оптимизации управления памятью
для повышения производительности.
Подробное описание архитектуры Hyper-V (в том числе "просвещенности" и компонентов
Integration Components) см. в главе 3.
Виртуализация на уровне операционной системы

Виртуализация на уровне операционной системы основана на идее поддержания опе-
рационной системой хоста нескольких изолированных разделов (или виртуальных
сред, virtual environment (VE)). Виртуализация достигается при помощи мультиплекси-
рования доступа к ядру (с обеспечением безопасности системы от виртуальных сред).

На рис. 1.2 показана архитектура такого подхода.
Рис. 1.2. Основы архитектуры виртуализации на уровне операционной системы
Эта методика обеспечивает очень низкие накладные расходы на виртуализацию и мо-

жет дать высокую плотность разделов. Однако такое решение имеет два основных не-
достатка. Первый — неспособность выполнять на данном сервере несколько разнород-
ных операционных систем (поскольку все разделы совместно используют одно ядро
операционной системы). Второй недостаток (также вызванный совместным использо-
ванием ядра) — неспособность поддерживать одновременно 32- и 64-битные рабочие
нагрузки. Кроме того, любое обновление ядра операционной системы влияет на все
виртуальные среды. По этим причинам виртуализация на уровне операционной систе-
мы лучше всего работает в однородных рабочих средах. Примером программного про-
дукта для виртуализации на уровне операционной системы является Virtuozzo
Containers (компания Parallels, ранее SWsoft). Virtuozzo Containers был широко принят
и развернут в компаниях, предоставляющих Web-хостинг (для создания инфраструктур
высокой плотности, предлагающих изолированные Web-службы).
Виртуализация на уровне приложений

Все обсуждавшиеся до настоящего момента способы виртуализации имели одну и ту
же цель — увеличить количество защищенных изолированных разделов, которые од-
новременно работают на физическом оборудовании (для максимального использова-
ния процессоров, объема дисков, сети, памяти и прочих ресурсов). Несмотря на то, что
они могут применяться и для настольного компьютера, они все же в основном нацеле-
ны на решение проблем управления ресурсами для серверных сред. Они не решают
проблем управления клиентскими приложениями для настольных компьютеров.
Виртуализация на уровне приложения — это технология, которая направлена на разде-
ление и изоляцию приложений на стороне клиента (работающих под местной операци-
онной системой). Приложения изолируются в виртуальной среде, находящейся между
операционной системой и стеком приложений (рис. 1.3). Виртуальная среда загружает-

ся до приложения, изолирует его от других приложений и операционной системы, а
также предотвращает модификацию приложением локальных ресурсов (таких, как
файлы и настройки реестра). Приложения могут читать информацию из локального
системного реестра и файлов, но пригодные для записи версии этих ресурсов поддер-
живаются внутри виртуальной среды. Фактически приложение не обязательно даже
инсталлировать на настольный компьютер; код можно получать динамически (по мере
необходимости) и кэшировать в виртуальной среде.
Рис. 1.3. Архитектура виртуализации на уровне приложения

(RW — чтение и запись, RO — только чтение)
Виртуализация на уровне приложения дает несколько преимуществ. Главные из них:

повышенная стабильность локального настольного компьютера; простое удаление
приложений без таких изменений локальной среды, которые могли бы негативно ска-
заться на других приложениях; бесконфликтное одновременное выполнение несколь-
ких экземпляров одного и того же приложения. Для обслуживания дистрибутивов при-
ложений может потребоваться один или несколько дополнительных серверов, поточ-
ная передача приложений на настольные компьютеры, а также реализация прочих
функций в масштабе предприятия.
В 2006 г. компания Microsoft пришла на рынок виртуализации приложений (после покупки
линейки программных продуктов Softricity и SoftGrid). Приложение SoftGrid Application
Virtualization for Desktops компании Microsoft работает на локальном настольном компьюте-
ре и поддерживает виртуальные реестр, файловую систему и прочие компоненты данных
(необходимые при выполнении приложения). Сервер SoftGrid Virtual Application Server ком-
пании Microsoft поддерживает область хранения для приложений и делает потоковую вы-
дачу кода приложения на настольный компьютер (по требованию). Прочие основные ком-
поненты решения SoftGrid Application Virtualization — это Microsoft SoftGrid Sequencer (для
упаковки и виртуализации приложений); Web-служба Microsoft SoftGrid Management (для

централизации служб политик приложения); а также Microsoft SoftGrid Management Console
(для обеспечения подготовки, доступа и отчетности). И наконец, продукт SoftGrid Application
Virtualization for Terminal Services позволяет службам Terminal Services предоставлять вир-
туализированные приложения клиентам. В 2008 г. компания Microsoft выпустила обновле-
ние линейки приложений SoftGrid — это продукт Microsoft Application Virtualization 4.5.
Более подробную информацию об Microsoft Application Virtualization 4.5 см. по адресу:
http://www.microsoft.com/systemcenter/softgrid/default.mspx.
Виртуализация рабочего стола

Такая виртуализация предназначена для изменения управления компьютерными ресур-
сами конечных пользователей (путем виртуализации рабочих столов настольных ком-
пьютеров и консолидации их на централизованных серверах). Виртуализация рабочих
столов обычно реализуется при помощи инфраструктуры Virtual Desktop Infrastructure
(VDI). Этот термин обозначает комбинацию аппаратного обеспечения, программного
обеспечения для виртуализации, а также инструментов управления (все это составляет
решение по виртуализации рабочих столов). В следующем списке приведены некото-
рые наиболее общие цели виртуализации рабочих столов:
снижение капитальных и эксплуатационных затрат на вычислительные ресурсы ко-
нечных пользователей;
уменьшение времени ввода в действие (или вывода из эксплуатации) виртуального
рабочего стола для нового конечного пользователя;
повышение коэффициента использования системных ресурсов;
повышение готовности вычислительных ресурсов для конечных пользователей;
централизация конфиденциальной информации на более надежных устройствах
хранения;
централизация обновлений, установки исправлений, резервного копирования и вос-
становления операционных систем виртуальных рабочих столов, а также прочих
функций управления рабочими столами.
Виртуализация рабочих столов может быть реализована либо как статические вирту-
альные рабочие столы, либо как динамические виртуальные рабочие столы. При пер-
вом варианте физический настольный компьютер заменяется виртуальным (обычно
выделенным конкретному конечному пользователю). Во втором варианте конечные
пользователи динамически подключаются к одному из виртуальных рабочих столов из
пула (по требованию). На рис. 1.4 дана иллюстрация простого решения VDI.
В то время как вариант статического виртуального рабочего стола может быть более
применим в такой среде, которая требует его индивидуальных настроек для выполне-
ния конкретных задач, вариант динамического виртуального рабочего стола может
вполне подойти для той среды, в которой большое количество пользователей выполня-
ет одинаковую работу с помощью одинакового набора инструментов (например, в цен-
тре обслуживания клиентов). При использовании (для динамических виртуальных ра-

бочих столов) решений виртуализации приложений с предоставлением (по требова-
нию) потоковых приложений можно получить более гибкие среды виртуализации ра-
бочих столов, хотя для них потребуются более сложные архитектуры и сложная ин-
фраструктура управления.
Системы конечных пользователей

Системы конечных пользователей
(включающие "тонких" и "толстых"
клиентов в корпоративной интрасети,
а также удаленных клиентов), кото-
рые инициируют запросы на подклю-
чение к виртуальным рабочим сто-
лам
Брокер подключения
Сервер, на котором имеется про-
граммное обеспечение для управле-
ния и маршрутизации запросов
(конечных пользователей на подклю-
чение к виртуальным рабочим
столам) к соответствующим серве-
рам виртуализации
Ферма серверов виртуального Подготовка виртуальных
приложения рабочих столов
Ферма серверов (где работает про- Сервер, который получает
граммное обеспечение виртуализа- запросы от брокера под-
ции приложения), которая выдает ключений и развертывает
поток приложения на виртуальные виртуальный рабочий стол
рабочие столы (по требованию) на доступном сервере
виртуализации
Ферма серверов виртуализации
Серверная ферма, на которой рабо-
тает программное обеспечение вир-
туализации (типа Hyper-V) для рабо-
ты виртуальных рабочих столов
Сеть хранения данных (SAN)
Хранилище данных для файлов вир-
туальных рабочих столов (виртуаль-
ные жесткие диски, файлы конфигу-
рации и т. д.) и пакетов виртуальных
приложений
Рис. 1.4. Решение на основе виртуальных рабочих столов

Virtual Desktop Infrastructure (VDI)
Дополнительную информацию о виртуализации рабочих столов см. в главе 18.
Подготовка экономического обоснования

виртуализации серверов
При составлении отделом информационных технологий экономического обоснования
(для внедрения новой технологии) базовой идеей всегда является минимизация затрат
при одновременном увеличении емкости, безопасности, надежности, готовности и гиб-
кости инфраструктуры (что позволит быстро адаптироваться к изменению потребно-
стей бизнеса). Технология виртуализации серверов является той основой, которая мо-
жет помочь предприятию ускорить достижение следующих целей:
снижение капитальных и эксплуатационных затрат на информационные техно-
логии;
реализация упрощенной, динамичной инфраструктуры предприятия;
повышение готовности вычислительных ресурсов;
уменьшение времени, необходимого для подготовки или предоставления новых
услуг;
уменьшение сложности управления.
Понимание того, как виртуализированная инфраструктура может способствовать дос-
тижению этих целей, поможет выполнить экономическое обоснование для быстрого
внедрения этой технологии.
Снижение капитальных и эксплуатационных затрат

Последние 15 лет количество физических серверов росло экстенсивно (по мере роста
организаций и соответствующего развертывания новых приложений и вычислитель-
ных мощностей). Для того чтобы обеспечить изоляцию приложений и управления сер-
верами, большинство развертываний делалось по схеме "один сервер — одно прило-
жение". Основным следствием такого подхода было то, что все увеличивающаяся
часть бюджета информационных технологий выделялась на эксплуатационные расхо-
ды (на оплату площадей, электроэнергии, охлаждения, административного персонала и
соответствующих инструментов управления). Вдобавок к этому многие компании пе-
режили один или несколько переездов своих центров обработки данных, которые про-
сто перерастали местные возможности в плане наличия пригодных для расширения
площадей, дополнительных мощностей электропитания и охлаждения. И что еще хуже,
оценки среднего коэффициента использования сервера дают цифры от 5 до 15%. По-
этому отделы информационных технологий имеют дело не только с разрастанием сер-
верного парка и увеличением накладных расходов, но и не могут (при традиционной
серверной архитектуре) максимизировать отдачу от капитальных вложений в сервер-
ное оборудование (из-за преобладания на предприятии конфигураций "один сервер —
одно приложение").
Виртуализация производственных серверов (начиная с уровня отдела и далее вверх до
уровня центра обработки данных) может помочь уменьшить новые капитальные вло-
жения (поскольку при появлении необходимости развернуть новые рабочие нагрузки
нужно будет покупать меньше физических серверов). Если один или несколько развер-
нутых серверов имеют запас вычислительной мощности, то новые рабочие нагрузки

можно будет развернуть просто в виде новых виртуальных машин. Поскольку вирту-
альные машины предоставляют (операционной системе и приложениям) стандартную
(эмулированную) конфигурацию аппаратного обеспечения, то их можно без труда пе-
реносить между серверами с разными конфигурациями аппаратного обеспечения. Та-
кая гибкость позволяет балансировать существующие на серверах рабочие нагрузки,
перенося их на неидентичное (но имеющееся в наличии) серверное оборудование и
создавая при этом необходимые мощности для новых развертываний (без новых капи-
тальных затрат). Кроме того, при работе с несколькими рабочими нагрузками физиче-
ские серверы работают с гораздо более высокими коэффициентами использования, и,
следовательно, увеличивается отдача от капитальных вложений (return on investment,
ROI).
При растущих (в традиционных инфраструктурах) тепловыделениях процессоров и
плотности серверов главными проблемами отделов информационных технологий ста-
новятся площади, электропитание и охлаждение. Даже при современных технологиях
управления электропитанием (которые понижают потребление энергии при снижении
использования процессора) и с учетом появления на рынке более эффективных источ-
ников питания для решения всех этих проблем нужны дополнительные меры. Виртуа-
лизация вычислительной среды может помочь снизить эксплуатационные затраты и
здесь. Консолидация рабочих нагрузок на меньшем количестве серверов может суще-
ственно снизить потребности в площадях, электроэнергии и охлаждении. По мере рос-
та вычислительных возможностей серверов (с внедрением многопроцессорности и
многоядерности) показатели консолидации рабочих нагрузок будут продолжать расти,
что приведет к снижению этих эксплуатационных расходов.
Реализация простой, гибкой и динамичной

серверной инфраструктуры
Современный бизнес является гибким ровно настолько, насколько это позволяют его
вычислительная инфраструктура и бизнес-процессы. Традиционная инфраструктура —
сложная, не очень гибкая и весьма редко — динамичная. Персонал отделов информа-
ционных технологий (ИТ) сталкивается с непростой задачей создания и соблюдения
стандартов на аппаратное обеспечение (в условиях, когда само аппаратное и про-
граммное обеспечение постоянно меняется). Экономические факторы заставляют ме-
неджеров по ИТ максимально увеличивать время жизни серверного оборудования (за-
тягивая обновление серверов для снижения капитальных затрат). К сожалению, такая
стратегия усложняет управление имеющимся оборудованием и его поддержку.
Снижение сложности инфраструктуры помогает снизить затраты. Виртуализированная
среда снижает сложность потому, что виртуальная машина обеспечивает стандартное
аппаратное решение, которое совместимо со многими операционными системами. По-
скольку виртуализированное аппаратное обеспечение развязано с устройствами реаль-
ного физического сервера, то вы получаете также и совместимость с различными фи-
зическими серверами. Такая гибкость позволяет вам создать виртуальную машину на
одном сервере (с определенной аппаратной конфигурацией) и перенести ее на другой
сервер (с другой аппаратной конфигурацией) без всякой ее модификации. Это избавля-
ет отдел ИТ от излишних временны́х затрат на длительную сертификацию серверов

(которая делается сейчас для проверки возможности выполнения рабочих нагрузок на
новом аппаратном обеспечении).
Более того, традиционную схему развертывания приложений — одна рабочая нагрузка
на сервер (для выполнения условий соглашений об уровне услуги (service level
agreements, SLA) и во избежание проблем совместимости рабочих нагрузок) — можно
при помощи виртуализации изменить. Основная проблема в том, что традиционный
метод развертывания не полностью использует ресурсы сервера, и это делает инфра-
структуру слишком негибкой. Виртуализация создает более гибкую серверную инфра-
структуру, которую можно оптимизировать для достижения более высоких показате-
лей использования серверов и даже использовать для работы с разными рабочими на-
грузками на одном физическом сервере.
Виртуализация полезна также для тестирования и разработки. В такой среде виртуали-
зация может обеспечить быструю подготовку виртуальных машин для создания слож-
ных сред приложений (на одном или нескольких серверах). Виртуализированная среда
может также использоваться для воспроизведения ошибок, обнаруженных при тести-
ровании (без необходимости переинсталлировать систему, как это часто бывает в
обычной тестовой инфраструктуре). Воспроизведение ошибок делается при помощи
создания моментальных снимков виртуальных машин (которые регистрируют конфи-
гурацию виртуальной машины на данный момент времени и информацию о ее состоя-
нии). Моментальные снимки виртуальных машин дают тестировщикам возможность
буквально за несколько секунд вернуться к одному из ранее сохраненных состояний
(при помощи простой загрузки сохраненного моментального снимка).
Виртуализированные инфраструктуры в смысле переноса рабочих нагрузок гораздо
более динамичны (чем традиционные). В традиционной среде нет простого процесса
переноса рабочей нагрузки "на ходу" (с одного сервера на другой). В виртуализирован-
ной среде балансировка нагрузок может быть без труда автоматизирована и выполня-
ется с существенно меньшим риском (поскольку виртуальные машины абстрагируют
зависимость от аппаратного обеспечения).
Повышение готовности вычислительных ресурсов

Одна из самых сложных задач для отделов ИТ (будь это малый бизнес или большая
транснациональная корпорация) является планирование восстановлений (таких, как
при отказе аппаратного обеспечения сервера), которые обычно сопровождаются значи-
тельным снижением имеющихся вычислительных ресурсов. Обеспечение непрерывно-
сти бизнеса после серьезной аварии (которая вызывает значительную или полную по-
терю оборудования) с восстановлением поврежденных служб в другом месте — это
(при наличии таких рабочих нагрузок, которые тесно связаны с аппаратным обеспече-
нием) непростой процесс. Кроме зависимости стека программного обеспечения от
конфигурации оборудования, существуют также сложности и расходы по синхрониза-
ции данных между разнесенными на большие расстояния местами. Достаточно сложно
также и оттестировать процедуры такого восстановления (чтобы обеспечить их пра-
вильность и эффективность).
Технология виртуализации может помочь повысить готовность вычислительных ре-

сурсов при помощи интеграции со службами высокой готовности, такими как класте-
ризация (которая обеспечивает отказоустойчивость). Имеющееся в решениях виртуа-
лизации достаточно тонкое управление дает вам возможность кластеризировать вирту-
альные машины на сервере, кластеризировать сами серверы или динамически
переназначать рабочие нагрузки на другие серверы. Такая высокая степень управления
позволяет ликвидировать традиционные уязвимые места (тем самым упрощая и облег-
чая процесс восстановления).
Виртуализированная инфраструктура упрощает также и преодоление последствий та-
ких событий, которые приводят к выходу из строя большого количества серверов и
рабочих нагрузок. Инкапсуляция виртуальных машин в несколько переносимых и лег-
ко реплицируемых файлов может значительно облегчить планирование, тестирование
и время восстановления после широкомасштабных отказов. Поскольку настройки кон-
фигурации виртуальной машины находятся в маленьких файлах, то после их реплика-
ции на место восстановления (вместе с файлами данных), все восстановление сводится
к простой регистрации виртуальной машины на новом хосте и загрузке операционной
системы. Абстрагирование от аппаратного обеспечения (свойственное решениям вир-
туализации) является ключевым элементом для упрощения процессов восстановления
и обеспечения непрерывности бизнеса.
Уменьшение времени на подготовку

или предоставление услуг
Для того чтобы получить преимущество в бизнесе, вы должны сделать бизнес-
процессы и основную инфраструктуру способными быстро реагировать на изменения.
Это преимущество может обернуться увеличением рыночной доли, повышением при-
были, проникновением на новые рынки или другими разновидностями роста бизнеса.
Если ваш бизнес может уменьшить время вывода на рынок новой идеи или линейки
бизнес-приложений, то он сможет также получить и более быструю отдачу от капита-
ловложений.
Реализация нового приложения в корпоративной среде зависит от его не очень просто-
го жизненного цикла, в который обычно входят следующие фазы: концепция, планиро-
вание, разработка, тестирование, проверка качества, развертывание и работа. При тра-
диционной инфраструктуре многие из этих фаз требуют предоставления или разверты-
вания новых вычислительных ресурсов (либо даже покупки нового оборудования для
запуска проекта). Каждая покупка занимает определенное время, поскольку проходит
через следующие стадии: согласование проекта, составление бюджета, тендер постав-
щиков, размещение заказа, поставка, тестирование и физическое развертывание. Эти
процессы могут занимать от нескольких недель до нескольких месяцев (в зависимости
от компании). Если же требуется оборудование от нескольких поставщиков, то могут
появиться дополнительные задержки (которые повлияют на время разработки нового
решения). Минимизация всех этих временны́х затрат (от концепции проекта до его
развертывания) является критичной для достижения бизнес-преимущества.
Виртуализированная вычислительная инфраструктура может сократить время реализа-
ции проекта, т. к. уменьшает необходимость в покупке и развертывании новых серве-
ров для каждого нового проекта. При помощи пулов виртуализированных серверов и
заранее созданных библиотек виртуальных машин процесс предоставления вычисли-
тельных ресурсов для проекта может быть сокращен до нескольких минут, а изменение
конфигурации виртуальных ресурсов (таких, как объем дисковой памяти, сетевые ин-
терфейсы и память) занимает буквально секунды. Однако для того чтобы получить от
виртуализации все эти преимущества, необходимо тщательно планировать мощности.
Виртуализация не избавляет также от необходимости покупать оборудование — до-
бавляются новые серверы, которые увеличивают имеющиеся мощности (они будут не-
сти множество новых рабочих нагрузок). Существенное преимущество виртуализации
состоит в том, что вы можете обеспечить ресурсами новую рабочую нагрузку в течение
нескольких минут (или часов), а не нескольких недель (или месяцев).
Снижение сложности управления

Обычно инфраструктура состоит из оборудования разных поставщиков, которое требу-
ет регулярного обслуживания и управления (чтобы обеспечить установку новых про-
шивок и исправлений программного обеспечения, а также гарантировать отсутствие
аппаратных проблем). При виртуализации физической инфраструктуры снижение ко-
личества физических серверов является ключевым преимуществом, которое ведет к
упрощению среды и уменьшению времени, затрачиваемого на управление. Уменьшая
количество имеющихся у вас брендов, вы можете снизить количество требующихся
для них инструментов (что также уменьшает сложность управления).
Еще одна важная задача управления — процесс резервного копирования. Управление
резервным копированием обычно состоит из администрирования следующих вещей:
программного обеспечения резервного копирования; агентов резервного копирования;
процессов резервного копирования серверов; носителей с резервными копиями для
каждого сервера. Управление резервным копированием в виртуализированной инфра-
структуре гораздо проще. Технологии моментальных снимков, которые позволяют де-
лать резервное копирование целых виртуальных машин, уменьшают сложность управ-
ления резервным копированием. Нет необходимости инсталлировать, обновлять и под-
держивать агентов резервного копирования в каждой гостевой операционной системе,
что приводит к более быстрому созданию резервных копий (упрощается также и
управление этим процессом).
Сценарии виртуализации серверов

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

обеспечение непрерывности бизнеса и реализация планов восстановления.
Консолидация центра обработки данных

Этот сценарий представляет собой ситуацию дефицита электропитания, охлаждения и
площадей, которая имеет место в большинстве центров обработки данных. Многие
рабочие нагрузки (которые обслуживаются в центрах обработки данных) являются хо-
рошими кандидатами для консолидации, которая позволит менеджерам и администра-
торам отделов ИТ более полно использовать мощность компьютеров (при снижении
количества физических единиц обслуживания). Консолидация центра обработки дан-
ных может производиться одним из следующих способов:
гомогенная консолидация — группирование (на одной платформе) серверов с анало-
гичными приложениями или рабочими нагрузками;
смешивание рабочих нагрузок — группирование (на одной платформе) серверов с
разными рабочими нагрузками.
Оба способа консолидации могут использовать виртуализацию. В этих случаях виртуа-
лизация дает следующие преимущества:
обеспечивает простой процесс миграции с физического компьютера на виртуаль-
ную машину, который минимизирует проектирование и тестирование, необходимые
для обеспечения совместимости рабочих нагрузок на одной платформе;
снижение количества физических серверов, что ведет к снижению расходов на ИТ;
ликвидация дублирования услуг (снижение потребности в управлении);
возможность динамической настройки для максимального использования мощно-
стей серверов.
Консолидация филиалов организации

Большинству организаций необходимо минимизировать развертывание оборудования
в большом количестве маленьких филиалов. Реализация виртуализированной среды в
филиале позволяет избежать проблем с поддержкой и безопасностью, которые возни-
кают при комбинировании в одной операционной системе: доменного контроллера,
файлового сервера и сервера печати, сервера Exchange Server, а также других рабочих
нагрузок. Использование виртуализации для консолидации филиалов дает следующие
преимущества:
реализация отдельного SLA для каждой виртуализированной рабочей нагрузки;
организация простого процесса миграции с физического сервера на виртуальную
машину, который минимизирует проектирование и тестирование, необходимые для
обеспечения совместимости рабочих нагрузок на одной платформе;
снижение количества физических серверов, что ведет к снижению расходов на ИТ;
разделение управления виртуализированными нагрузками при одновременном
обеспечении безопасности физического доступа к серверам.
Виртуализация инфраструктуры
тестирования и разработки
Это сценарий реализации виртуализированной инфраструктуры для тестирования и
разработки. Обслуживание и обеспечение (для тестирования и разработки) тради-
ционной среды могут существенно истощить бюджет и стать серьезной проблемой
управления. Использование виртуализации в этом сценарии дает следующие преиму-
щества.
Уменьшение количества оборудования, необходимого для работы приложений со
сложными архитектурами (с множеством рабочих нагрузок). Одного сервера соот-
ветствующей мощности может быть вполне достаточно (поскольку каждая рабочая
нагрузка может выполняться в отдельной виртуальной машине).
Уменьшение времени, требующегося для подготовки новых сценариев тестирова-
ния и разработки, а также автоматизация развертывания виртуальных машин на
серверы (где имеются свободные мощности).
Улучшение управления жизненным циклом тестирования и разработки. Например,
время миграции новых приложений из среды тестирования и разработки в произ-
водственную среду значительно сокращается (благодаря переносимости и простоте
репликации файлов виртуальных машин).
Простота создания библиотеки виртуальных машин (для хранения сценариев тести-
рования).
Простая миграция производственной среды с физических серверов в библиотеку
виртуальных машин для тестирования и разработки.
Упрощение процесса воспроизведения ошибок (при помощи использования момен-
тальных снимков и сохранения состояния виртуальной машины).
Обеспечение непрерывности бизнеса

и его восстановления
Это сценарий реализации процесса восстановления бизнеса в случае отказа или серьез-
ной катастрофы. При планировании непрерывности бизнеса необходимо выработать
простой и быстрый способ восстановления, который можно проверить на соответствие
требованиям непрерывности бизнеса. Использование для этого виртуализации дает
следующие преимущества:
поддержка кластеризации отдельных виртуальных машин на разных серверах, а
также кластеризации серверов виртуализации и рабочих нагрузок (для достижения
высокой готовности);
снижение зависимости от сложного и дорогого оборудования (для поддержания
синхронности данных между разными физическими площадками);
возможность создать решение для непрерывности бизнеса по схеме "физический
компьютер — виртуальная машина";
возможность создать решение для непрерывности бизнеса по схеме "виртуальная

машина — виртуальная машина";
возможность использовать дешевые технологии репликации файлов для реплика-
ции файлов виртуальных машин между серверами (для снижения времени восста-
новления).
Дополнительную информацию по виртуализации серверов см. в главе 12.
Резюме
В этой главе вы узнали о различных типах технологий программной виртуализации и о
том, какое отношение они имеют к архитектуре Hyper-V. Вам были представлены ос-
новные аргументы для разработки экономического обоснования внедрения технологии
виртуализации. Глава закончилась обзором основных технических сценариев виртуа-
лизации, решение для которых может дать Hyper-V, а также соответствующих пре-
имуществ таких решений.
Дополнительные источники
Следующие источники содержат дополнительную информацию по темам этой главы:
сайт Microsoft Virtualization Web по адресу:
http://www.microsoft.com/virtualization/default.mspx;
документ "Virtualization from the Datacenter to the Desktop", доступный по адресу:
http://www.microsoft.com/virtualization/datacenter.mspx;
техническая документация по архитектуре AMD64, доступная по адресу:
http://www.amd.com/us-en/Processors/DevelopWithAMD
/0,,30_2252_739_7044,00.html;
технический документ "AMD64 Architecture Programmer’s Manual Volume 2: System
Programming", доступный по адресу:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs
/24593.pdf;
технический документ "AMD64 Architecture Programmer’s Manual, Volume 3:
General-Purpose and System Instructions", доступный по адресу:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs
/24594.pdf;
руководства для разработчиков программного обеспечения под архитектуры Intel 64
и IA-32, доступные по адресу: http://www.intel.com/products/processor/manuals/;
технический документ "Intel 64 and IA-32 Architectures Software Developer’s Manual
Volume 1: Basic Architecture", доступный по адресу:
http://download.intel.com/design/processor/manuals/253665.pdf;
технический документ "Intel 64 and IA-32 Architectures Software Developer’s Manual

Volume 2B: Instruction Set Reference, N-Z", доступный по адресу:
технический документ "Intel 64 and IA-32 Architectures Software Developer’s Manual,
Volume 3B: System Programming Guide, Part 2", доступный по адресу:
технический документ "Intel Virtualization Technology for Directed I/O — Architecture
Specification", доступный по адресу:
http://download.intel.com/technology/computing/vptech
/Intel(r)_VT_for_Direct_IO.pdf.
ГЛАВА 2
Обзор Hyper-V
Эта глава содержит обзор функциональных возможностей Hyper-V, имеющихся в сер-

верной роли полной инсталляции Windows Server 2008, в роли Server Core, а также в
сервере Microsoft Hyper-V Server 2008. Для того чтобы обеспечить надежную платфор-
му виртуализации, которая абстрагирует от физического аппаратного обеспечения и
масштабируется для одновременного выполнения множества рабочих нагрузок, Hyper-V
выполнен на основе архитектуры гипервизора, который предоставляет стандартные
службы и ресурсы для создания, управления и выполнения виртуальных машин. Hyper-V
предлагает стандартную среду виртуального аппаратного обеспечения, виртуальные
жесткие диски (virtual hard disks, VHD), а также виртуальные сети, что соответственно
позволяет выполнять и сохранять виртуальные машины, а также вести обмен между
ними. Службы и компоненты интеграции (Integration Services (IS) и Integration
Components (IC) соответственно) поддерживают важнейшие процессы и повышают
производительность виртуальных машин. При помощи менеджера Hyper-V Manager и
оснастки Microsoft Management Console (MMC) производится управление сервером
Hyper-V и конфигурацией виртуальных машин. Менеджер Hyper-V Manager предос-
тавляет интерфейс для создания, обследования и конфигурирования виртуальных
машин, виртуальных жестких дисков и виртуальных сетей, а также для выделения вир-
туальным машинам памяти и процессоров. Свойства Hyper-V можно также модифици-
ровать при помощи Hyper-V Manager. В менеджер Hyper-V Manager интегрировано
средство Virtual Machine Connection (VMC) для удаленного доступа к виртуальным
машинам из консоли (это средство имеется также в виде отдельного приложения).
Кроме того, Hyper-V предлагает обширный интерфейс Windows Management Instru-
mentation (WMI), который вы можете использовать при помощи различных языков
скриптов и языков разработки (в том числе и PowerShell) для программного и удален-
ного управления развертыванием, администрированием и конфигурированием вирту-
альных машин.
Основы Hyper-V
В феврале 2003 г. с покупкой технологии программной виртуализации фирмы
Connectix компания Microsoft пришла на рынок средств виртуализации. В октябре
2004 г. компания Microsoft выпустила Virtual Server 2005 — решение для виртуализа-
ции инфраструктуры предприятия (для платформы х86) с поддержкой 32-битных вир-
туальных машин. Virtual Server 2005 представляет собой пример архитектуры виртуа-
лизации на основе хоста, поскольку он работает совместно с операционной системой
Windows и зависит от нее при арбитраже доступа к аппаратным ресурсам. В ноябре
2005 г. была выпущена версия Virtual Server 2005 Release 2 (R2), в которой появилось
несколько повышающих производительность функциональных возможностей, а также
поддержка: операционных систем х64 для хоста, подключения iSCSI, архитектуры
Non-Uniform Memory Access (NUMA), загрузки Pre-Execution Environment (PXE) и кла-
стеризации хостов сервера Virtual Server. Последняя версия Virtual Server 2005 R2
Service Pack 1 (SP1) появилась в июне 2007 г. В этой версии компания Microsoft доба-
вила поддержку процессоров Intel VT и AMD-V и обеспечила возможность управления
виртуализацией аппаратного обеспечения для каждой виртуальной машины (VM).
И наконец, в мае 2008 г. было выпущено обновление KB948515, которое расширило
имеющуюся в Virtual Server 2005 R2 SP1 поддержку операционных систем. Теперь
поддерживаются также Windows XP SP3, Windows Vista SP1 и Windows Server 2008
(как в качестве операционной системы хоста, так и гостя).
Параллельно с Virtual Server 2005 R2 SP1 компания Microsoft разрабатывала свой про-
дукт следующего поколения для виртуализации предприятия Windows Server 2008
Hyper-V, который был выпущен в июне 2008 г. На рис. 2.1 показана архитектура Hyper-V,
которая основана на 64-битном микроядре гипервизора (Windows Hypervisor). Гипер-
визор работает непосредственно над аппаратным обеспечением, позволяет одновре-
менно выполняться внутри разделов нескольким операционным системам и обеспечи-
Рис. 2.1. Архитектура Hyper-V

Глава 2. Обзор Hyper-V 41
вает строгую изоляцию разделов друг от друга (посредством реализации политик дос-
тупа для критических системных ресурсов, таких как память и процессоры). В отличие
от таких операционных систем, как Windows Server 2003 и более ранние, гипервизор
Windows Hypervisor не содержит никаких драйверов или кода сторонних производите-
лей, что минимизирует его уязвимость для атак и обеспечивает более безопасную
архитектуру.
Вследствие такой микроядерной архитектуры и отсутствия в нем драйверов Windows, раз-
мер гипервизора составляет менее 1 Мбайт.
В дополнение к гипервизору в Hyper-V имеются еще два основных элемента: роди-

тельский раздел и дочерние разделы. Родительский раздел — это специальная вирту-
альная машина, которая выполняет Windows Server 2008, занимается созданием и
управлением дочерних разделов, а также обслуживает прямой доступ к аппаратным
ресурсам. Для этого в родительском разделе должны быть инсталлированы драйверы
для физических устройств. И наконец, роль дочерних разделов состоит в том, чтобы
предоставить виртуальную машину для инсталляции и выполнения гостевых операци-
онных систем и приложений.
Через шину VMBus сервер Hyper-V ведет высокоскоростной обмен между родитель-
скими и дочерними разделами. VMBus поддерживает выделенные каналы "точка —
точка" для безопасного обмена между разделами (между поставщиками Virtualization
Service Providers (VSP) в родительском разделе и клиентами Virtualization Service
Clients (VSC) в дочерних разделах). VSP — это программные компоненты, которые
управляют запросами ввода/вывода от VSC в виртуальных машинах и направляют эти
запросы к физическому оборудованию (через драйверы устройств). VSC — это синте-
тические драйверы (программные компоненты), которые предоставляют высокопроиз-
водительный доступ к устройствам хранения, сети, видео и пользовательского интер-
фейса виртуальных машин. В нынешней версии Hyper-V клиенты VSC имеются для
некоторых операционных систем Windows, а также для сервера SUSE Linux Enterprise
Server 10 (который имеет осведомленное о гипервизоре Xen ядро). При работе на сер-
вере Hyper-V сервер SUSE Linux Enterprise Server 10 использует адаптер гипервызовов
Hypercall Adapter (для трансляции вызовов гипервизора Xen (гипервызовов) в вызовы
гипервизора Hyper-V), что дает высокую производительность выполнения.
Полный список поддерживающих VSC операционных систем Windows см. в главе 5.
Виртуальные машины, в которых работают гостевые операционные системы, не

имеющие поддержки VSC, используют (для предоставления доступа к виртуализиро-
ванным аппаратным устройствам) эмулирующие (или обычные) драйверы. Родитель-
ский раздел отслеживает и перехватывает запросы ввода/вывода к виртуализирован-
ным аппаратным устройствам и направляет их к физическим устройствам.
Подробное описание архитектуры Hyper-V см. в главе 3.
Основные функциональные возможности

Hyper-V
В табл. 2.1 приведена сводка основных функциональных возможностей серверов
Windows Server 2008 Hyper-V и Hyper-V Server 2008. Виртуальные машины Hyper-V
поддерживают 32- и 64-битные гостевые операционные системы, а также выделение до
четырех виртуальных процессоров и 64 Гбайт памяти (для серверов Hyper-V, которые
работают на версиях Windows Server 2008 Enterprise или Datacenter). В первоначальной
версии Hyper-V поддерживал 16 процессорных ядер и 128 виртуальных машин. Однако
последовавшее затем обновление KB956710 увеличило эти цифры до 24 логических
процессоров и 192 виртуальных машин.
Таблица 2.1. Сравнение основных функций Hyper-V
Windows Windows Windows

Hyper-V
Функции Server 2008 Server 2008 Server 2008
Server 2008
Standard Enterprise Datacenter
Поддержка х86 Только гостевая Только гостевая Только гостевая Только гостевая
ОС ОС ОС ОС
Поддержка х64 Хост и гость Хост и гость Хост и гость Хост и гость
Количество VM Максимум 192 Максимум 192 Максимум 192 Максимум 192
Поддерживаемое 32 Гбайт 32 Гбайт 1 Тбайт 1 Тбайт
количество памяти
хоста
Поддерживаемое Максимально Максимально Максимально Максимально
количество про- 24 ядра 24 ядра (см. при- 24 ядра (см. при- 24 ядра (см. при-
цессоров хоста (см. примечание) мечание) мечание) мечание)
Виртуальные сети Не ограничено Не ограничено Не ограничено Не ограничено
Память Максимум Максимум Максимум Максимум
гостевой VM 32 Гбайт 32 Гбайт 64 Гбайт 64 Гбайт
Виртуальных 4 на одну VM 4 на одну VM 4 на одну VM 4 на одну VM
гостевых
процессоров
Виртуальных гос- 4 обычных, 4 обычных, 4 обычных, 4 обычных,
тевых сетевых 8 синтетических 8 синтетических 8 синтетических 8 синтетических
адаптеров
Гостевых адапте- 2 IDE, 4 SCSI 2 IDE, 4 SCSI 2 IDE, 4 SCSI 2 IDE, 4 SCSI
ров для устройств
хранения
Гостевых устройств 4 IDE, 256 SCSI 4 IDE, 256 SCSI 4 IDE, 256 SCSI 4 IDE, 256 SCSI
хранения
Поддержка класте- Нет Нет Есть Есть
ризации
Быстрая миграция Нет Нет Есть Есть
Количество лицен- Нет 1 физическая, 1 физическая, 1 физическая,
зий на использова- 1 VM 4 VM VM без ограни-
ние чений
Если вы собираетесь инсталлировать и использовать Hyper-V на физическом сервере
с 24 процессорными ядрами, то вы должны скачать и инсталлировать KB956710 для
Windows Server 2008 Hyper-V с адреса: http://support.microsoft.com/kb/956710.
ВАЖНО
Лицензия Windows позволяет вам выполнять одну виртуальную машину на Windows Server
2008 Standard, четыре VM на Windows Server 2008 Enterprise и неограниченное количество
VM на Windows Server 2008 Datacenter. Поскольку Microsoft Hyper-V Server 2008 не являет-
ся версией Windows, то вместе с ним вы не получаете лицензий Windows, и поэтому у вас
должна быть лицензия Windows на каждую выполняющуюся в нем виртуальную машину на
базе Windows.
Поддержка архитектур AMD-V и Intel VT

Для работы Hyper-V требуется 64-битный процессор из семейства AMD-V или Intel
VT, который имеет аппаратную поддержку виртуализации и функции Data Execution
Prevention (DEP). Вы должны убедиться, что обе эти функции включены в BIOS, по-
скольку по умолчанию они могут быть выключены. При включении DEP в процессо-
рах AMD активируется бит No-Execute (NX), а в процессорах Intel — бит Execute-
Disable (XD), которые помогают предотвратить использование ошибки переполнения
буфера. Прочие преимущества работы на процессорах AMD-V и Intel VT — это доступ
к более обширному адресному пространству и более высокая плотность разделов.
Hyper-V не поддерживает системы на базе процессоров Itanium и х86.
После включения битов AMD NX и Intel XD вам может понадобиться перезапустить ваш
физический компьютер.
Поддержка полной инсталляции

и инсталляции типа Server Core
Hyper-V можно инсталлировать либо как инсталляцию Server Core, либо как роль
в полной инсталляции 64-битных версий Windows Server 2008 Standard, Enterprise и
Datacenter. В полной инсталляции Windows Server 2008 для добавления роли Hyper-V
вы можете использовать Initial Configuration Tasks или Server Manager. Гипервизор
Windows появляется только после инсталляции роли Hyper-V в сервере Windows Server
2008. Более того, когда вы выбираете и добавляете роль Hyper-V, на вашу систему ин-
сталлируются все компоненты Hyper-V. В их число входят такие инструменты управ-
ления Hyper-V, как оснастка MMC с названием Hyper-V Manager, а также приложение
Virtual Machine Connection, которое позволяет вам получить удаленный доступ к вир-
туальным машинам. Установка роли Hyper-V в полную инсталляцию Windows Server
2008 требует перезапуска компьютера для загрузки гипервизора Windows.
Server Core сервера Windows Server 2008 — это новая функциональная возможность,
которая позволяет вам инсталлировать минимальную серверную конфигурацию, вклю-
чающую только определенное подмножество двоичных файлов, требующихся для вы-
полнения поддерживаемых ролей. Ключевым преимуществом Server Core является
снижение необходимого обслуживания операционной системы (например, нужно

меньшее количество обновлений) и требований к управлению (в инсталляцию входит
меньше файлов и служб).
В инсталляции Server Core существует девять ролей: Hyper-V, File Services, Active
Directory Domain Services, Active Directory Lightweight Directory Services, DHCP Server,
DNS Server, Print Services, Streaming Media Services, а также Web Server. По умолчанию
интерфейс управления для инсталляции Server Core — это командная строка, посколь-
ку графический пользовательский интерфейс оболочки Explorer не инсталлируется.
Поэтому для активации роли Hyper-V в инсталляции Server Core вам придется исполь-
зовать командную строку. Однако инсталляцией Server Core можно удаленно управ-
лять при помощи стандартных инструментов MMC (с сервера, который имеет полную
инсталляцию Windows Server 2008). Вы можете также использовать инструменты
Remote Server Administration Tools (RSAT) для управления инсталляциями Server Core
из 32- и 64-битных версий следующих операционных систем: Windows Vista Business
с сервисным пакетом Service Pack 1 (SP1), Windows Vista Enterprise с сервисным паке-
том SP1, а также Windows Vista Ultimate с сервисным пакетом SP1.
Если вы собираетесь инсталлировать и использовать RSAT для управления инсталляцией
Server Core, то вы должны скачать и инсталлировать KB941314 с адреса:
http://support.microsoft.com/kb/941314.
Подробные инструкции по инсталляции роли Hyper-V как для полной инсталляции Windows
Server 2008, так и для инсталляции Server Core см. в главе 4.
Сервер Microsoft Hyper-V Server 2008

Сервер Microsoft Hyper-V Server 2008 является отдельным продуктом, основанным на
той же самой архитектуре виртуализации, что и Windows Server 2008 Hyper-V. Однако
он был упрощен и оптимизирован для работы одного только Hyper-V. Аналогично ин-
сталляции Server Core, он предоставляет только интерфейс командной строки и может
администрироваться удаленно при помощи инструментов управления Hyper-V и RSAT.
Сервер Microsoft Hyper-V Server 2008 можно скачать бесплатно с Web-сайта компании
Microsoft. Это хороший вариант для виртуализации одного хоста, когда не нужны та-
кие промышленные функциональные возможности, как высокая готовность, и когда
виртуальным машинам не нужно более 32 Гбайт оперативной памяти. Возможность
использования Hyper-V Server 2008 можно рассмотреть для непромышленных приме-
нений, а также для сред тестирования и разработки. Обновить Microsoft Hyper-V Server
2008 до Windows Server 2008 Hyper-V нельзя. Однако виртуальные машины этих двух
продуктов совместимы и могут мигрировать при помощи функций экспорта и импорта
виртуальных машин в Hyper-V (см. далее в этой главе).
Если вас заинтересовал сервер Windows Hyper-V Server 2008, то его можно скачать по ад-
ресу: http://www.microsoft.com/servers/Hyper-V-server/how-to-get.mspx.
Сервер Microsoft Hyper-V Server 2008 имеет инструмент HVConfig.cmd (запускается из

командной строки, имеет систему меню) для конфигурирования подключений и функ-
ций (для использования сервера в управляемой среде). HVConfig.cmd поддерживает
следующее конфигурирование и действия:
членство в домене или рабочей группе;
имя компьютера;
сетевые настройки;
локальные администраторы;
настройки обновлений Windows Update;
загрузку и инсталляцию обновлений Windows Updates;
удаленный рабочий стол;
региональные и языковые настройки;
дату и время;
выход пользователя из системы;
перезагрузку сервера;
завершение работы сервера;
выход в командную строку.
HVConfig.cmd фактически выполняет скрипт Visual Basic с именем HVConfig.vbs, ко-
торый содержит всю вышеупомянутую функциональность. HVConfig.cmd запускается
каждый раз, когда вы регистрируетесь в системе.
Управление доступом при помощи Authorization Manager

Hyper-V использует менеджер Authorization Manager (AzMan) для управления доступом
(на основе ролей) к Hyper-V и виртуальным машинам. Это позволяет вам создавать
определения заданий и преобразовывать их в роль с ограниченным набором операций
и задач. Вы можете назначать роли отдельным пользователям или группам, что позво-
лит им выполнять свою работу и ограничит их доступ только теми ресурсами, опера-
циями и задачами Hyper-V, которые им для этого требуются.
Подробности относительно использования AzMan для Hyper-V (и о типах ролей, которые,
может быть, полезно определить для управления сервером Hyper-V и виртуальными маши-
нами) см. в главе 6.
Live Backup при помощи Volume Shadow Copy Service

Служба Volume Shadow Copy Service (VSS) в Hyper-V обеспечивает резервное копиро-
вание на стороне хоста, что избавляет от необходимости загружать агента в каждую
виртуальную машину. Любое осведомленное о VSS приложение (такое, как System
Center Data Protection Manager (DPM) 2007 SP1) может использовать эту службу для
выполнения резервного копирования в виде моментальных снимков (если оно исполь-
зует интерфейс записи VSS, реализованный в Hyper-V). Для любой виртуальной маши-
ны с осведомленной о VSS гостевой операционной системой Windows (Windows Server
2003 и более поздние) резервное копирование может выполняться в активном ее со-
стоянии. Любая другая гостевая система (Windows 2000, Linux и т. д.) должна перед
выполнением моментального снимка VSS находиться в сохраненном состоянии. По-
скольку моментальные снимки VSS выполняются исключительно быстро (этот процесс
занимает буквально секунды), то время простоя виртуальных машин минимально.
Кроме того, при использовании поддержки VSS уменьшается количество операций
резервного копирования (или восстановления), а также обеспечивается целостность
данных.
Дополнительную информацию о выполнении резервного копирования на активной системе
при помощи VSS см. в главе 13.
Высокая готовность
при помощи отказоустойчивой кластеризации
Hyper-V поддерживает отказоустойчивую кластеризацию Windows Failover Clustering
для реализации такой стратегии высокой готовности, которая позволяет управлять как
плановым, так и неплановым выключением серверов. Есть два уровня реализации от-
казоустойчивого кластера Hyper-V: на уровне гостевой операционной системы и на
уровне хоста виртуализации. Отказоустойчивый кластер на уровне гостевой операци-
онной системы требует наличия осведомленных о кластеризации приложений (которые
выполняются на виртуальных машинах). Кроме того, в виртуальной машине должна
работать такая операционная система, которая поддерживает отказоустойчивую кла-
стеризацию (Windows Server 2003 (кластер до 8 узлов) или версия Windows Server 2008
Enterprise либо Datacenter (кластер до 16 узлов)). Второй вариант отказоустойчивой
кластеризации представляет собой два (или более) сервера Windows Server 2008
Hyper-V, каждый из которых сконфигурирован как узел кластера. Такой тип конфигу-
рации позволяет вам создать решение с высокой готовностью для неосведомленных
о кластеризации гостевых операционных систем и приложений (работающих в вирту-
альных машинах).
Подробности по конфигурированию отказоустойчивых кластеров обоих типов см. в главе 5.
Быстрая миграция
Hyper-V поддерживает также и быструю миграцию (Quick Migration) — это способ-
ность переносить (без потери данных) виртуальные машины между узлами кластера
с минимальным прерыванием обслуживания. Для этого виртуальная машина перево-
дится в сохраненное состояние, состояние памяти и процессора записываются на диск,
а владение ресурсами системы хранения передается другому узлу кластера. На новом
узле память виртуальной машины и состояние процессора загружаются, и обработка
возобновляется. В зависимости от объема хранения и размера данных состояния весь

этот процесс может занять секунды (или минуты).
Подробнее о быстрой миграции Quick Migration см. в главе 14.
Службы интеграции
В сервере Hyper-V службы интеграции Integration Services (IS) обеспечивают поддерж-
ку пяти уникальных компонентов, для которых требуется безопасный интерфейс меж-
ду родительским и дочерним разделом. Вот эти функции:
синхронизация времени;
служба тактовых импульсов;
завершение работы;
обмен парами "ключ/значение";
служба теневого копирования Volume Shadow Copy Service (VSS).
Службы интеграции Integration Services занимаются очень специфичными задачами,
которые улучшают функциональность гостевых операционных систем или управление
ими. В дополнение к этим функциям службы интеграции предоставляют синтетические
(высокопроизводительные) драйверы для сети, видео, хранения и человеко-машинного
интерфейса. Если вы инсталлируете в виртуальной машине Windows Server 2008, то
службы интеграции будут уже инсталлированы. Однако вам следует обновить их до
самой последней версии. Для других операционных систем вам придется установить
службы интеграции после завершения инсталляции операционной системы. Важно от-
метить, что для некоторых устаревших или не относящихся к семейству Windows опе-
рационных систем может поддерживаться неполный набор служб интеграции.
Подробности относительно служб интеграции см. в главах 3 и 5.
Импорт и экспорт виртуальных машин

Функции импорта и экспорта в Hyper-V предназначены для переноса (и копирования)
виртуальных машин между серверами Hyper-V. Эти функции не дают возможности
экспортировать или импортировать виртуальные машины для других решений виртуа-
лизации (таких, как Virtual Server 2005 R2). Кроме того, вы можете экспортировать
только такую виртуальную машину, которая находится в сохраненном состоянии или
выключена.
Управление виртуальными дисками

Hyper-V имеет несколько опций управления виртуальными жесткими дисками (virtual
hard disks, VHD), доступ к которым можно получить через консоль Hyper-V Manager.
Вот эти опции:

Compact — предоставляет возможность уменьшить размер VHD путем ликвидации
пустого пространства, которое остается после удаления данных из файла VHD;
Convert — предоставляет возможность превратить динамически расширяющийся
VHD в VHD фиксированного размера (или наоборот);
Expand — предоставляет возможность увеличить емкость динамически расши-
ряющегося диска или фиксированного диска;
Merge — предоставляет возможность объединить содержимое дочернего разност-
ного диска и родительского разностного диска;
Reconnect — предоставляет возможность повторно подключить дочерний разност-
ный диск к родительскому;
Доступные варианты зависят от типа выбранного вами VHD, а также от состояния это-
го VHD.
Подробнее об опциях управления VHD см. в главе 15.
Моментальные снимки виртуальных машин

Функция моментальных снимков сервера Hyper-V позволяет вам сохранить конфигу-
рацию и состояние виртуальной машины в любой момент времени и дает возможность
загрузить любой имеющийся снимок буквально за несколько секунд. Моментальные
снимки Hyper-V могут быть очень полезны тогда, когда вам нужно делать в виртуаль-
ной машине постепенные изменения с возможностью откатиться к предыдущему со-
стоянию. Функция моментальных снимков Hyper-V в принципе предназначена для ис-
пользования в средах тестирования и разработки, а не в производственной инфра-
структуре.
Дополнительные подробности по моментальным снимкам виртуальных машин см. в главе 5.
Инструмент Virtual Machine Connection

Virtual Machine Connection (VMC) — это инструмент удаленного администрирования,
поставляемый вместе с Hyper-V. Для предоставления доступа к выполняющейся в вир-
туальной машине гостевой операционной системе VMC использует протокол Remote
Desktop Protocol операционной системы Windows. Он встроен в оснастку Hyper-V
Manager консоли MMC, а также имеется в виде отдельного приложения. VMC предос-
тавляет доступ к видеобуферу с момента включения виртуальной машины, так что
у вас есть доступ к ней во время ее загрузки.
Дополнительные подробности по использованию VMC см. в главе 11.
Функциональные возможности сервера Windows Server 2008 R2 Hyper-V
Компания Microsoft сделала большие вложения в разработку сервера Windows Server 2008
Hyper-V, являющегося платформой виртуализации, которая обеспечивает гибкость и про-
изводительность для консолидации рабочих нагрузок. Эта книга дает превосходное и под-
робное изложение различных аспектов платформы Hyper-V, однако компания Microsoft
продолжает разработку и улучшение функций и возможностей Hyper-V. Вот некоторые воз-
можности Windows Server 2008 R2 Hyper-V, следующей версии платформы виртуализации
серверов.
Горячая миграция Live Migration виртуальных машин

Для переноса VM (с минимальным прерыванием обслуживания) между хостами кластера
сервер Windows Server 2008 обеспечивает быструю миграцию (Quick Migration). Однако эта
возможность требует остановки виртуальной машины на то время, пока ее сохраненное со-
стояние переносится с исходного узла на узел назначения. В это время виртуальная маши-
на не работает (этот период называется "временем недоступности" (blackout)), что по су-
ществу вызывает простой виртуальной машины. Для сегодняшних вычислительных сред
простой даже в течение короткого периода времени является проблемой. Для того чтобы
справиться с этой проблемой, компания Microsoft улучшила продукт Hyper-V при помощи
введения в него функции Live Migration. При использовании Live Migration отсутствует ви-
димый простой работающих на виртуальных машинах рабочих нагрузок, а сетевые подклю-
чения к мигрирующим VM остаются активными. Так же, как и быстрая миграция Quick
Migration, "горячая" миграция Live Migration возможна между узлами отказоустойчивого кла-
стера. Фактически сделанные в инфраструктуру (для использования Quick Migration) вло-
жения оправдаются и при использовании Live Migration. Кроме того, компания Microsoft до-
бавляет в отказоустойчивые кластеры функцию Clustered Shared Volumes, которая позво-
ляет дискам VHD для различных виртуальных машин храниться на одном устройстве
Logical Unit Number (LUN). Это не только упрощает управление совместно используемыми
устройствами хранения кластера, но и обеспечивает значительное уменьшение времени
недоступности переносимых при помощи Live Migration виртуальных машин.
Поддержка функций Enhanced Hardware Virtualization

С течением времени изготовители оборудования (такие, как AMD и Intel) разработали для
своих процессоров и наборов микросхем существенные улучшения (такие, как технологии
AMD-V и Intel VT), имеющие специально предназначенные для виртуализации функции.
Продолжая разработку таких улучшений, компании AMD и Intel предоставляют поддержку
Nested Page Tables (NPT) и Extended Page Tables (EPT) соответственно. Эти функции по-
вышают производительность трансляций адресов памяти. Без этих аппаратных улучшений
при каждом неудачном чтении страницы памяти гостевой операционной системы требуется
переключение контекста на гипервизор (для обработки этой ситуации). При помощи же NPT
и EPT гостевая система может сама обрабатывать неудачные чтения страниц, избавляясь
от необходимости в дорогих переключениях контекста на гипервизор и снижая издержки
виртуализации на трансляцию памяти.
Добавление и удаление виртуальных устройств хранения

Виртуализация устраняет зависимость работающего на системе программного обеспече-
ния от аппаратного обеспечения, а также повышает (для отделов ИТ) удобство разверты-
вания и управления средой. При наличии такой гибкости необходимо также иметь возмож-
ность увеличивать и уменьшать объемы хранения, связанные с виртуальными машинами.
В версии Windows Server 2008 R2 Hyper-V компания Microsoft вводит возможность добав-
лять виртуальные жесткие диски в виртуальную машину (и удалять их) при ее работе. Это
открывает широкий диапазон возможностей для решений по резервному копированию
и т. д.
Сетевые улучшения
Поставщики сетевого оборудования также произвели некоторые улучшения своего обору-
дования, которые полезны для виртуализированных платформ. Две основные техноло-
гии — это TCP Offload Engine (TOE) и Virtual Machine Queues (VMQ).
TOE переносит обработку TCP/IP на карту сетевого интерфейса (NIC). Эта технология не
является специфичной для виртуализированных платформ, поскольку невиртуализирован-
ные операционные системы и приложения также могут ею пользоваться. Эмпирическое
правило таково: для отправки 1 бита данных TCP/IP нужен 1 Гц тактовой частоты процес-
сора. Для высокоскоростных NIC накладные расходы на обработку трафика TCP/IP могут
быть весьма существенными. Windows Server 2008 R2 Hyper-V поддерживает перенос об-
работки TCP/IP с виртуальных машин на сетевые адаптеры (что снижает издержки на об-
работку сетевого трафика). При этом ресурсы процессора освобождаются для выполнения
дополнительной работы.
VMQ обеспечивает на сетевом адаптере несколько очередей и алгоритмы сортировки. Ги-
первизор может присваивать очереди виртуальным машинам. Сетевой адаптер сортирует
входящий сетевой трафик и помещает его в соответствующие очереди для виртуальных
машин. Поскольку эта обработка происходит в аппаратной части сетевого адаптера, то при
этом снижаются издержки гипервизора и процессорные ресурсы опять-таки освобождаются
для выполнения другой работы.
Кроме того, компания Microsoft также добавила поддержку пакетов увеличенного размера
(jumbo frames), которые позволяют повысить полезную нагрузку. Пакет увеличенного раз-
мера — это кадр Ethernet с объемом полезных данных до 9000 байтов (в отличие от тради-
ционных 1500 байтов). Это снижает накладные расходы на один переданный байт. В соче-
тании с функцией large send offload, LSO (это способность операционной системы переда-
вать сетевому адаптеру большие блоки данных для создания кадров Ethernet) и с функцией
large receive offload, LRO (которая позволяет создавать один большой буфер данных для
приема нескольких поступающих кадров Ethernet) все это дает дополнительное снижение
накладных расходов на обработку сетевого трафика.
Улучшения в части управления электропитанием

Поскольку электропитание и охлаждение центров данных теперь является серьезной про-
блемой, следующее поколение гипервизора Windows имеет такие улучшения, которые по-
зволяют снизить потребление электроэнергии виртуализированными рабочими нагрузками.
В число этих улучшений входит "парковка ядер", которая позволяет гипервизору с упрежде-
нием консолидировать простаивающие рабочие нагрузки на меньшем количестве ядер.
Неиспользуемые процессоры могут быть после этого переведены в режим "глубокого сна",
что приведет к снижению потребляемой сервером энергии. Кроме того, инфраструктура
виртуального управления (Virtual Machine Manager (SCVMM) в System Center) может также
помочь оптимально разместить рабочие нагрузки, что снизит общее потребление энергии
этими рабочими нагрузками.
Брокер подключений удаленного рабочего стола

Брокер подключений удаленного рабочего стола Remote Desktop Connection Broker создает
унифицированный способ управления для традиционных сеансовых (на основе Terminal
Services) удаленных рабочих столов и для удаленных рабочих столов виртуальных машин в
инфраструктуре Virtual Desktop Infrastructure (VDI). Два основных сценария развертывания,
которые поддерживает брокер Remote Desktop Connection Broker, — это постоянные вирту-
альные машины и виртуальные машины из пула. В случае постоянной виртуальной маши-
ны пользователю присваивается выделенная VM, которую можно персонализировать и на-
страивать, причем она сохраняет все сделанные пользователем изменения. В случае VM
из пула для пользователей по мере необходимости реплицируется один и тот же образ VM.
Пользовательское состояние может сохраняться при помощи профиля и перенаправления
каталогов, но после выхода пользователя из системы все это утрачивается.
Виджей Тевари (Vijay Tewari, Principal Program Manager
(Windows Virtualization))
Поддержка операционных систем хоста

Все 64-битные операционные системы хоста (поддерживаемые на данный момент сер-
вером Hyper-V) приведены в следующем списке:
Windows Server 2008 Standard Edition;
Windows Server 2008 Enterprise Edition;
Windows Server 2008 Datacenter Edition;
Microsoft Hyper-V Server 2008.
Поддержка гостевых операционных систем

Следующий список содержит все поддерживаемые гостевые операционные системы
х86, которые можно использовать с версиями Windows Server 2008 Standard, Enterprise
и Datacenter, а также с Microsoft Hyper-V Server 2008:
Windows 2000 (поддержка одного виртуального процессора):
• Windows 2000 Server SP4;
• Windows 2000 Advanced Server SP4;
Windows Server 2003 x86 (поддержка одного или двух виртуальных процессоров):
• Windows Server Web Edition SP2;
• Windows Server Standard Edition SP2;
• Windows Server Enterprise Edition SP2;
• Windows Server Datacenter Edition SP2;
Windows Server 2003 R2 x86 (поддержка одного или двух виртуальных процессо-
ров):
• Windows Server Web Edition SP2;
Windows Server 2003 x64 (поддержка одного или двух виртуальных процессоров):
Windows Server 2003 R2 x64 (поддержка одного или двух виртуальных процес-
соров):
Windows Server 2008 x86 (поддержка одного, двух или четырех виртуальных про-
цессоров):
• Windows Server 2008 Standard Edition;
• Windows Server 2008 Enterprise Edition;
• Windows Server 2008 Datacenter Edition;
• Windows Web Server 2008 Edition;
• Windows Server 2008 Standard Edition без Hyper-V;
• Windows Server 2008 Enterprise Edition без Hyper-V;
• Windows Server 2008 Datacenter Edition без Hyper-V;
Windows Server 2008 x64 (поддержка одного, двух или четырех виртуальных про-
цессоров):
• Windows Server 2008 Standard Edition;
• Windows Server 2008 Enterprise Edition;
• Windows Server 2008 Datacenter Edition;
• Windows Web Server 2008 Edition;
• Windows Server 2008 Standard Edition без Hyper-V;
• Windows Server 2008 Enterprise Edition без Hyper-V;
• Windows Server 2008 Datacenter Edition без Hyper-V;
Windows HPC Server 2008 (поддержка одного, двух или четырех виртуальных про-
цессоров);
SUSE Linux Enterprise Server 10 x86 (поддержка одного виртуального процессора):
• SUSE Linux Enterprise Server 10 SP1;
SUSE Linux Enterprise Server 10 x64 (поддержка одного виртуального процессора):
Windows XP Professional x86:
• Windows XP Professional SP2 (поддержка одного виртуального процессора);
• Windows XP Professional SP3 (поддержка одного или двух виртуальных процес-
соров);
Windows XP Professional x64: Windows XP Professional SP2 (поддержка одного или
двух виртуальных процессоров);
Windows Vista x86 (поддержка одного или двух виртуальных процессоров):
• Windows Vista Business Edition SP1;
• Windows Vista Enterprise Edition SP1;
• Windows Vista Ultimate Edition SP1;
Windows Vista x64 (поддержка одного или двух виртуальных процессоров):

• Windows Vista Business Edition SP1;
• Windows Vista Enterprise Edition SP1;
• Windows Vista Ultimate Edition SP1.
Обзор Hyper-V
Серверы Windows Server 2008 Hyper-V и Microsoft Hyper-V Server 2008 — это плат-
формы виртуализации на основе гипервизора. Hyper-V имеет много потоков и одно-
временно выполняет одну или более виртуальных машин (рабочих нагрузок), причем
каждую машину в ее собственном потоке выполнения. Каждая виртуальная машина
предоставляет (гостевой операционной системе и приложениям) набор виртуализиро-
ванных (синтетических) устройств, которые абстрагируют имеющееся аппаратное
обеспечение, что обеспечивает переносимость рабочих нагрузок между несхожими
физическими серверами (работающими под управлением Hyper-V).
Аппаратная среда виртуальной машины

В табл. 2.2 приведен стандартный набор тех виртуализированных компонентов, кото-
рые виртуальная машина предоставляет операционной системе и стеку приложений.
Эти устройства детектируются и выглядят как физические аппаратные ресурсы, дос-
тупные для выполняемой рабочей нагрузки. Когда рабочая нагрузка виртуальной ма-
шины запрашивает доступ к виртуализированным ресурсам, то Hyper-V работает вме-
сте с родительским разделом и транслирует запрошенную операцию из среды вирту-
ального оборудования в среду физического оборудования, причем доступ организуется
через стандартные драйверы устройств уровня ядра (инсталлированные в родитель-
ском разделе). Такой подход дает рабочей нагрузке способность выполняться на самом
широком спектре серверного оборудования (без всяких модификаций конфигурации
этой рабочей нагрузки).
Таблица 2.2. Виртуализированные компоненты оборудования
Компонент Виртуализированное оборудование

Basic Input/Output System BIOS American Megatrends с чипсетом Intel 440BX и ACPI PIIX4, в том
(BIOS) числе:
• Complementary metal oxide semiconductor (CMOS);
• часы реального времени;
• RAM и видеопамять (VRAM);
• контроллер памяти;
• контроллер прямого доступа к памяти (DMA);
• шина PCI;
• шина ISA;
• шина SM;
• управление питанием;
• программируемый контроллер прерываний 8259 (PIC);
• программируемый таймер прерываний (PIT)
Таблица 2.2 (окончание)
Компонент Виртуализированное оборудование

Дисковод гибких дисков Один дисковод 1,44 Мбайт, который отображается на образ дисковода
гибких дисков
Последовательный порт Два последовательных порта, которые могут быть подключены
(COM) к локальным именованным каналам
Порт принтера (LPT) Отсутствует
Мышь Стандартное устройство мыши Microsoft IntelliMouse с интерфейсом
PS/2, которое отображается на устройство PS/2 на физическом компь-
ютере.
Синтетическое устройство мыши (требует инсталляции служб
Integration Services)
Клавиатура Стандартное устройство клавиатуры Microsoft со 101 клавишей
с интерфейсом PS/2, которое отображается на клавиатуру PS/2 на
физическом компьютере.
Синтетическое устройство клавиатуры (требует инсталляции служб
Integration Services)
Сетевой адаптер До четырех сетевых адаптеров Multiport DEC/Intel 21140.
(многофункциональный) До восьми синтетических сетевых адаптеров (требует инсталляции
служб Integration Services)
Процессор До четырех процессоров (соответствуют физическим процессорам
компьютера)
Память До 32 Гбайт оперативной памяти на виртуальную машину для серве-
ров Windows Server 2008 Hyper-V Standard Edition и Microsoft Hyper-V
Server 2008.
До 64 Гбайт оперативной памяти на виртуальную машину для серве-
ров Windows Server 2008 Hyper-V версий Enterprise и Datacenter
Видеокарта Совместимый с VESA эмулируемый графический адаптер с 4 Мбайт
видеопамяти, поддержка VGA и SVGA (совместимая с VESA 1.2),
двумерный графический акселератор и аппаратный курсор, поддержка
DirectX.
Синтетический видеоадаптер (требует инсталляции служб Integration
Services)
Интерфейс хранения Два канала IDE, которые поддерживают жесткие диски, дисководы
IDE/ATAPI CD-ROM и DVD-ROM, а также образы ISO. Каждый канал IDE поддер-
живает два диска
Интерфейс хранения SCSI До четырех синтетических адаптеров SCSI, каждый поддерживает
64 диска (требует инсталляции служб Integration Services)
Звуковая карта Отсутствует
Рабочие нагрузки виртуальных машин имеют некоторые соответствующие такой аппа-

ратной среде ограничения. В виртуальной машине не могут выполняться такие опера-
ционные системы или приложения, которым требуется прямой доступ к не упомянуто-
му в табл. 2.2 аппаратному устройству. Поскольку виртуальные машины предоставля-
ют нагрузке только четыре процессора, то тем приложениям, которым требуется
симметричная многопроцессорность (Symmetric Multiprocessing, SMP), в виртуальной
машине может быть выделен один, два или четыре процессора.
Виртуальные жесткие диски

Виртуальный жесткий диск (virtual hard drive, VHD) — это представление физического
жесткого диска в виде одного файла, который инкапсулирует данные виртуальной
машины. Виртуальные жесткие диски отражают внутреннюю структуру физического
жесткого диска (в том числе имеют таблицы распределения блоков, блоки данных и
секторы). В табл. 2.3 приведен список имеющихся в Hyper-V типов виртуальных жест-
ких дисков.
Таблица 2.3. Типы виртуальных жестких дисков
Тип диска Описание
Fixed Файл виртуального жесткого диска, все блоки данных которого выделяются на
(фиксированный) дисковой подсистеме хоста в момент его создания. Диск размером 10 Гбайт
занимает 10 Гбайт пространства того физического диска хоста, на котором он
создан
Dynamically Файл виртуального жесткого диска, который размещается без выделения про-
Expanding (дина- странства под блоки данных и растет по мере записи в него данных (до дости-
мически расши- жения полного размера). Такой диск объемом 10 Гбайт первоначально занима-
ряющийся) ет меньше 2 Мбайт и растет до размера 10 Гбайт блоками по 2 Мбайт.
В Hyper-V максимальный размер диска такого типа составляет 127 Гбайт
Differencing Файл виртуального жесткого диска, который привязан к существующему "роди-
(разностный) тельскому" виртуальному жесткому диску в качестве оверлея. Все операции
записи делаются в "дочерний" разностный диск, а чтения осуществляется из
родительского и дочернего дисков. Разностные диски создаются как динамиче-
ски расширяющиеся диски
Linked (связанный) Том физического диска, который вы хотите превратить в виртуальный жесткий
диск. Связанные диски существуют только для выполнения миграции с физи-
ческого диска на виртуальный жесткий диск
Внутри виртуальной машины виртуальный жесткий диск представляется как физиче-

ский диск. На физическом диске сервера Hyper-V виртуальный жесткий диск хранится
как файл с расширением vhd. Виртуальные машины подключаются к виртуальному
жесткому диску через виртуализированный адаптер Integrated Drive Electronics (IDE)
или Small Computer System Interface (SCSI). Сервер Hyper-V виртуальному жесткому
диску ставит в соответствие vhd-файл на физическом диске. VHD может храниться на
любой системе хранения (IDE, SCSI, iSCSI, SAN или NAS), поддерживаемой операци-
онной системой Windows Server 2008.
Виртуальные жесткие диски создаются либо при помощи программы Hyper-V Manager,
либо через интерфейс прикладного программирования WMI. Виртуальная машина мо-
жет поддерживать до 260 виртуальных жестких дисков (подключенных через IDE и
SCSI).
Спецификации виртуальных жестких дисков не зависят от используемого для подключения
к виртуальной машине типа шины. Однако тип шины налагает на виртуальные диски огра-
ничения по размеру. Подключенные через IDE виртуальные жесткие диски не могут пре-
вышать по размеру 127 Гбайт. Подключенные через SCSI виртуальные жесткие диски не
могут превышать по размеру 2040 Гбайт.
Транзитные диски
При помощи Hyper-V вы можете предоставить виртуальной машине подключенный к
физическому серверу диск без создания на нем тома. Это называется транзитным дис-
ком. Транзитные диски могут быть либо физически подключены к серверу Hyper-V,
либо как LUN в сети хранения SAN. Одним из преимуществ транзитных дисков явля-
ется то, что они не имеют ограничения в 2040 Гбайт, наложенного на виртуальные же-
сткие диски VHD. Однако они не поддерживают динамически расширяющихся VHD,
разностных VHD и моментальных снимков Hyper-V.
Виртуальный интерфейс IDE

Виртуальная машина предоставляет встроенные первичный и вторичный виртуальные
интерфейсы IDE. На сервере Hyper-V вы можете загрузить виртуальную машину толь-
ко с такого виртуального жесткого диска, который подключен через виртуальный ин-
терфейс IDE. Каждый виртуальный интерфейс IDE может поддерживать два подклю-
ченных к нему устройства (т. е. всего четыре устройства IDE на каждую виртуальную
машину). К интерфейсу IDE могут подключаться как виртуальные жесткие диски, так и
виртуальные CD-ROM. По умолчанию первый виртуальный CD-ROM подключается
к вторичному интерфейсу как ведущее устройство.
Виртуальный интерфейс SCSI

В отличие от встроенных виртуальных интерфейсов IDE, виртуальные интерфейсы
SCSI — это необязательные компоненты, которые для их использования должны ин-
сталлироваться в виртуальную машину. Виртуальная машина поддерживает до четы-
рех виртуальных адаптеров SCSI. Каждый виртуальный адаптер SCSI может иметь до
64 подключенных устройств (т. е. всего до 256 устройств SCSI на каждую виртуальную
машину).
Поскольку виртуальные адаптеры SCSI реализованы как синтетические устройства,
которые загружаются после загрузки гостевой операционной системы, то подключен-
ные к ним VHD нельзя использовать для загрузки виртуальной машины.
Диски iSCSI
Еще один вариант предоставления устройств хранения виртуальной машине — это ин-
сталляция инициатора iSCSI в гостевую операционную систему и подключение непо-
средственно к целевому устройству iSCSI. Однако сервер Hyper-V не поддерживает
загрузку с подключенного при помощи iSCSI-диска; поэтому вам придется подключать
ваш загрузочный диск через виртуальный интерфейс IDE. Использование подключен-
ных через iSCSI дисков требует выделения на сервере Hyper-V сетевого адаптера для
iSCSI-обмена.
Виртуальные сети
Виртуальная сеть — это программная эмуляция сетевого коммутатора уровня Layer 2
с неограниченным количеством портов и коммутируемым каналом связи, который мо-
жет подключаться к внешней физической сети через физический сетевой адаптер или
вовсе не иметь подключения (чтобы создать изолированную внутреннюю сеть). Для
каждой создаваемой в Hyper-V виртуальной сети создается новый программный ком-
мутатор. Кроме того, каждый виртуальный сетевой порт имитирует 10-гигабитный
порт Ethernet. Сервер Hyper-V поддерживает неограниченное количество виртуальных
сетей с неограниченным количеством портов для подключений виртуальных машин.
Сервер Hyper-V обеспечивает три типа виртуальных сетей: external (внешняя), private
(частная) и internal (внутренняя). Для подключения к физической сети используется
внешняя виртуальная сеть. Когда вы создаете новую виртуальную внешнюю сеть, то в
родительском разделе Hyper-V создается новый виртуальный сетевой адаптер со всеми
основными сетевыми привязками. Виртуальный сетевой адаптер подключается к но-
вому виртуальному сетевому коммутатору, а виртуальный сетевой коммутатор под-
ключается к выбранному вами физическому сетевому адаптеру. Если на сервере
Hyper-V инсталлировано несколько физических сетевых адаптеров, то вы можете вы-
брать тот, который будет привязан к новой внешней виртуальной сети. Все сетевые
привязки физического сетевого адаптера удаляются (за исключением протокола
Microsoft Virtual Network Switch Protocol). Когда новая виртуальная машина подключа-
ется к внешней виртуальной сети, то на виртуальный сетевой коммутатор добавляется
новый сетевой порт.
Внутренняя виртуальная сеть дает возможность виртуальным машинам вести обмен
с сервером Hyper-V, но не дает доступа к физическим сетям. В этом случае в родитель-
ском разделе Hyper-V так же создается виртуальный сетевой адаптер, который под-
ключается к порту на новом виртуальном сетевом коммутаторе. Однако этот новый
виртуальный коммутатор не подключен ни к одному из инсталлированных на сервере
Hyper-V физических сетевых адаптеров. Когда новая виртуальная машина подключа-
ется к внутренней виртуальной сети, то на виртуальный сетевой коммутатор добавля-
ется новый сетевой порт.
Частная виртуальная сеть позволяет виртуальным машинам обмениваться друг с дру-
гом (но не с сервером Hyper-V и не с подключенными к внешней физической сети хос-
тами). Фактически при создании новой частной виртуальной сети создается новый
виртуальный сетевой коммутатор, но в родительском разделе Hyper-V никакого вирту-
ального сетевого адаптера не создается. По мере добавления к новому виртуальному
сетевому коммутатору новых подключений виртуальных машин на коммутаторе соз-
даются новые сетевые порты.
Все три типа виртуальных сетей могут создаваться либо при помощи оснастки Hyper-V
Manager, либо при помощи интерфейса WMI.
Виртуальные сетевые адаптеры

В Hyper-V поддерживаются два типа виртуальных сетевых адаптеров: обычные (эму-
лируемые) и синтетические. Обычный сетевой адаптер имитирует виртуальный сете-
вой адаптер Multiport DEC 21140. Использование обычного сетевого адаптера повыша-
ет нагрузку на процессор, поскольку доступ к устройству требует переключения кон-
текста (которого не требуется при использовании синтетического сетевого адаптера).
Синтетический сетевой адаптер обеспечивает высокую производительность, поскольку

запросы доступа к устройствам виртуальной машины делаются через высокоскорост-
ную шину VMBus к родительскому разделу. Для использования синтетического сете-
вого адаптера гостевая операционная система виртуальной машины должна поддержи-
вать инсталляцию служб Integration Services.
Виртуальные машины поддерживают максимум четыре виртуальных обычных адапте-
ра и восемь синтетических сетевых адаптеров. Только обычный сетевой адаптер под-
держивает протокол Pre-boot Execution Environment (PXE), который позволяет постав-
лять виртуальные машины при помощи стандартных инструментов развертывания
(таких, как Windows Deployment Services (WDS) или приложения сторонних организа-
ций). Это существенно, т. к. синтетический сетевой адаптер загружается только после
загрузки виртуальной машины.
Когда в виртуальную машину добавляется обычный сетевой адаптер, вы можете опре-
делить для подключения к нему виртуальную сеть (либо оставить виртуальную маши-
ну отключенной от всех виртуальных сетей). Hyper-V выделяет для нового виртуально-
го сетевого адаптера новый динамический адрес Media Access Control (MAC) из своего
пула имеющихся адресов. Можно также предоставить виртуальному сетевому адаптеру
статический MAC-адрес, указываемый вручную. В Hyper-V и обычные, и синтетиче-
ские сетевые адаптеры предоставляют поддержку идентификации виртуальных ло-
кальных сетей (VLAN).
ВАЖНО
Несмотря на то, что виртуальный сетевой адаптер Multiport DEC 21140 описывает
10/100-мегабитный интерфейс Ethernet, рабочие нагрузки виртуальных машин не имеют ог-
раничений по полосе пропускания сети. Если соответствующий физический сетевой адап-
тер способен показать более высокую производительность (например, развивает гигабит-
ные скорости), то рабочая нагрузка виртуальной машины может превысить скорость обме-
на в 100 Мбит/с.
Использование консоли Hyper-V Manager

Оснастка Hyper-V Manager для ММС инсталлируется тогда, когда роль Hyper-V кон-
фигурируется в полной инсталляции сервера Microsoft Windows Server 2008. Этот ме-
неджер является по умолчанию графическим интерфейсом пользователя, который по-
зволяет вам управлять серверами Hyper-V и виртуальными машинами, а также конфи-
гурировать их. Он доступен также и для Microsoft Vista SP1 (версий x86 и x64) — его
можно скачать с Web-сайта компании Microsoft.
Если вас интересует работа с менеджером Hyper-V Manager в среде операционной систе-
мы Microsoft Vista SP1, то его можно скачать по адресу: http://support.microsoft.com
/kb/952627.
Менеджер Hyper-V позволяет администратору управлять серверами Hyper-V; однако

он может быть инструментом управления только для небольших развертываний вир-
туализации. Если вы развертываете Hyper-V в большой или сложной среде, то вам сле-
дует использовать приложение для управления в масштабе предприятия (такое, как

System Center Virtual Machine Manager).
Вы можете запустить менеджер Hyper-V Manager из меню Start (подменю
Administrative Tools), как показано на рис. 2.2. В полной инсталляции (по умолчанию)
сервера Windows Server 2008 вы можете запустить его также и через пункт Run меню
Start, либо через командную строку — путем ввода C:\Program Files\Hyper-V
\virtmgmt.msc.
Рис. 2.2. Запуск менеджера Hyper-V Manager через меню Start
Консоль менеджера Hyper-V Manager разбита на три раздела (рис. 2.3). В левой панели
отображается древовидное представление управляемых серверов Hyper-V. В централь-
ной панели отображаются существующие виртуальные машины и их состояние, а так-
же древовидное представление имеющихся моментальных снимков и минимизирован-
ное представление консоли виртуальной машины (когда выбрана виртуальная маши-
на). Правая панель содержит список действий для управления серверами Hyper-V и
виртуальными машинами. Список действий для виртуальных машин отображается
только после создания виртуальной машины на сервере Hyper-V (или добавления ее
туда).
Рис. 2.3. Представление по умолчанию менеджера Hyper-V Manager
Управление большим количеством

серверов Hyper-V
Несмотря на то, что менеджер Hyper-V Manager позволяет одновременно управлять
только одним сервером Hyper-V, с его помощью можно без труда переключиться на
другой сервер Hyper-V. На рис. 2.4 показано диалоговое окно Select Computer, которое
отображается при щелчке правой кнопкой мыши в левой панели Hyper-V Manager и
выборе пункта Connect To Server. В этом диалоговом окне вы можете указать имя или
IP-адрес того сервера Hyper-V, которым вы хотите управлять.
В этом диалоговом окне вы можете также установить переключатель Another
Computer и просмотреть те серверы Hyper-V, которыми вы хотите управлять с вашей
консоли.
Управление виртуальными машинами

Менеджер Hyper-V Manager позволяет вам создавать, удалять, экспортировать, импор-
тировать и конфигурировать виртуальные машины на управляемом вами сервере
Hyper-V. Вы управляете виртуальными машинами посредством выбора нужного дейст-
вия, а затем указываете нужную информацию при помощи простых мастеров.
Рис. 2.4. Выбор сервера в Hyper-V Manager
Создание виртуальных машин

Для того чтобы создать новую виртуальную машину, вы можете выбрать пункт New
непосредственно под названием сервера Hyper-V в панели Actions, а затем — пункт
Virtual Machine (рис. 2.5).
Hyper-V имеет мастер New Virtual Machine Wizard (рис. 2.6) для оказания вам помощи
в процессе конфигурирования и создания новой виртуальной машины.
Мастер собирает информацию о конфигурации новой виртуальной машины, в том чис-
ле: название виртуальной машины и местоположение ее области хранения; выделяемая
виртуальной машине память; виртуальная сеть для подключения к виртуальной маши-
не; а также хотите ли вы создать новый виртуальный жесткий диск, использовать су-
ществующий виртуальный жесткий диск, либо подключить виртуальный жесткий диск
позднее. И наконец, вы можете указать опции инсталляции гостевой операционной
системы, в том числе: позднее; с загрузочного CD или DVD-ROM; с загрузочного гиб-
кого диска; с сетевого сервера инсталляций. После того как вы сделаете свой выбор,
у вас будет возможность просмотреть заданные вами настройки и указать, следует ли
запускать виртуальную машину после ее создания.
После того как информация из мастера попадает в Hyper-V, создается новый конфигу-
рационный xml-файл виртуальной машины, который содержит информацию о на-
стройках. Новая виртуальная машина регистрируется и становится видна в менеджере
Рис. 2.5. Создание новой виртуальной машины в менеджере Hyper-V Manager
Рис. 2.6. Мастер New Virtual Machine Wizard в менеджере Hyper-V Manager
Hyper-V Manager; создается новый виртуальный жесткий диск (если такое указано);
виртуальный сетевой адаптер подключается к виртуальной машине. Новая виртуальная
машина готова к загрузке и инсталляции новой операционной системы либо к загрузке
существующей операционной системы.
Экспорт и импорт виртуальных машин

Если вы хотите экспортировать виртуальную машину, то щелкните по ней правой
кнопкой мыши в менеджере Hyper-V Manager или выберите опцию Export в панели
Actions. Затем вы увидите диалоговое окно Export Virtual Machine (рис. 2.7). Важно
отметить, что вы можете экспортировать только такую виртуальную машину, которая
находится в сохраненном состоянии или выключена.
Рис. 2.7. Диалоговое окно Export Virtual Machine в менеджере Hyper-V Manager
В диалоговом окне Export Virtual Machine вы можете указать местоположение для

сохранения файлов экспорта виртуальных машин. Там есть также опция экспорта
только exp-файла конфигурации виртуальной машины (без файлов сохраненного со-
стояния или файлов VHD).
После переноса или копирования файлов экспорта виртуальной машины, для импорта
виртуальной машины в Hyper-V выберите опцию Import Virtual Machine в панели
Actions под названием соответствующего сервера. Далее вы должны ввести путь
к файлам экспорта в диалоговом окне Import Virtual Machine или перейти к нему
(рис. 2.8).
Рис. 2.8. Диалоговое окно Import Virtual Machine в менеджере Hyper-V Manager
Вам нужно также решить, будете ли вы повторно использовать идентификатор ID вир-

туальной машины (это Global Unique Identifier (GUID), присваиваемый при создании
новой виртуальной машины). Если вы делаете копию существующей виртуальной ма-
шины, то должны сгенерировать новый идентификатор виртуальной машины и оста-
вить эту опцию неотмеченной. Если вы переносите виртуальную машину или восста-
навливаете из резервной копии виртуальной машины, то вам следует повторно исполь-
зовать старый идентификатор виртуальной машины.
Если вы собираетесь повторно использовать старый идентификатор виртуальной машины,
а исходная виртуальная машина по-прежнему присутствует на сервере Hyper-V, то опера-
ция импорта закончится ошибкой (поскольку идентификатор виртуальной машины должен
быть уникальным).
Когда вы импортируете виртуальную машину, она остается там, откуда вы ее импорти-

руете, и после импорта ее нельзя будет переместить. Поэтому перед импортом вирту-
альной машины обеспечьте перемещение файлов экспортированной виртуальной
машины в предназначенное для них место.
Моментальные снимки виртуальных машин

Функция моментальных снимков Hyper-V позволяет вам сохранить конфигурацию и
состояние виртуальной машины в любой момент времени и вернуть ее в это состояние
(без заметного прерывания). Hyper-V позволяет создавать моментальный снимок вир-
туальной машины как во время ее работы, так и в сохраненном или выключенном со-
стоянии.
Для того чтобы создать моментальный снимок виртуальной машины в менеджере
Hyper-V Manager, щелкните правой кнопкой мыши по виртуальной машине и выберите
пункт Snapshot контекстного меню (рис. 2.9).
Рис. 2.9. Создание моментального снимка виртуальной машины

при помощи консоли менеджера Hyper-V Manager
На рис. 2.10 показаны те изменения в консоли менеджера Hyper-V Manager, которые

происходят после завершения выполнения моментального снимка. Раздел Snapshots
в центральной панели теперь показывает древовидную структуру, которая отражает
иерархию моментальных снимков виртуальной машины. Корневой узел дерева — это
только что созданный моментальный снимок (он имеет метку времени создания). Под
корневым узлом есть дочерний с названием Now, который представляет собой рабо-
тающую версию виртуальной машины.
По мере того как вы производите изменения в конфигурации виртуальной машины, вы
можете создавать и сохранять дополнительные моментальные снимки. На рис. 2.11
Рис. 2.10. Моментальные снимки в консоли менеджера Hyper-V Manager
Рис. 2.11. Отображение иерархии моментальных снимков в консоли менеджера Hyper-V Manager
показано, что после первоначального был сгенерирован еще один моментальный сни-
мок, и выводятся они в виде иерархии "родитель→потомок", отражающей связь разно-
стных дисков, которые создаются для каждого моментального снимка (для регистра-
ции изменений в операционной системе виртуальной машины, ее приложениях и
данных).
Если после серии изменений в виртуальной машине вы решите, что хотите загрузить
предыдущий моментальный снимок, то используйте опцию Revert (рис. 2.12). После
применения к виртуальной машине этой опции конфигурация и состояние виртуальной
машины возвращаются к сохраненным в файлах моментальных снимков настройкам.
Рис. 2.12. Опция Revert в консоли Hyper-V Manager
Если вы хотите загрузить моментальный снимок, который находится на два или более
уровней выше, чем работающая виртуальная машина (представленная меткой Now в
панели Snapshots), то можете щелкнуть по моментальному снимку правой кнопкой
мыши и выбрать пункт Apply из контекстного меню (рис. 2.13).
Если вы решите, что вам больше не нужен моментальный снимок (или все поддерево
моментальных снимков), то в Hyper-V есть два варианта Delete (рис. 2.14) для удаления
одного (или более) моментальных снимков из иерархии моментальных снимков.
Вы можете выбрать удаление одного моментального снимка или поддерева момен-
тальных снимков. Удаление одного снимка не влияет на другие моментальные снимки
Рис. 2.13. Опция Apply в консоли Hyper-V Manager
Рис. 2.14. Опции Delete Snapshot и Delete Snapshot Subtree в консоли Hyper-V Manager
в иерархии; однако при этом немедленно удаляются файл конфигурации и файлы со-
храненных состояний, связанные с этим моментальным снимком. Удаление поддерева
моментальных снимков немедленно удаляет файлы конфигураций и файлы сохранен-
ных состояний, связанные со всеми моментальными снимками поддерева.
Состояние виртуальной машины

Состояние виртуальной машины можно изменить при помощи менеджера Hyper-V
Manager. На рис. 2.15 показаны пункты контекстного меню, которые появляются при
щелчке правой кнопкой мыши по работающей виртуальной машине. Имеющиеся
пункты меню отличаются в зависимости от состояния виртуальной машины. Напри-
мер, если виртуальная машина находится в состоянии Off или Saved, то в меню по-
явится пункт Start.
Рис. 2.15. Опции изменения состояния работающей виртуальной машины
Вот состояния виртуальной машины, которые вы можете изменять при помощи ме-
неджера Hyper-V Manager:
Start — включить и загрузить виртуальную машину;
Turn Off — неконтролируемое выключение питания виртуальной машины (равно-
сильно выдергиванию кабеля питания из физического компьютера);
Shut Down — контролируемое отключение питания виртуальной машины (требует
поддержки служб интеграции Integration Services);
Save — остановка работы виртуальной машины и сохранение в файл состояния па-

мяти и процессора;
Pause — приостановка работы виртуальной машины;
Resume — возобновление работы виртуальной машины после ее приостановки;
Reset — неконтролируемый перезапуск виртуальной машины (равносильно нажа-
тию кнопки Reset физического компьютера).
Управление конфигурацией виртуальной машины

Вы можете щелкнуть правой кнопкой мыши по виртуальной машине и выбрать пункт
Settings в контекстном меню для доступа к настройкам виртуальной машины
(рис. 2.16).
Рис. 2.16. Пункт Settings для настройки виртуальной машины
На рис. 2.17 показан пример диалогового окна с настройками виртуальной машины.

Настройки оборудования виртуальной машины и ее управления показаны в панели
слева (с разбивкой по основным компонентам). Панель справа показывает те опции,
которые есть для каждого компонента оборудования и управления.
В табл. 2.4 приведен список опций конфигурирования оборудования виртуальной ма-
шины и описание изменений, связанных с каждой опцией.
Рис. 2.17. Пример диалогового окна с настройками виртуальной машины
Таблица 2.4. Элементы конфигурации оборудования виртуальной машины
Элемент
Описание
конфигурации
Add Hardware Позволяет добавлять на виртуальную машину синтетические контроллеры SCSI,
(Добавить обору- синтетические сетевые адаптеры, а также обычные (эмулированные) сетевые
дование) адаптеры
BIOS Позволяет выполнять настройку состояния Num Lock (включен или выключен),
а также порядка загрузки с устройств (CD, IDE, обычный сетевой адаптер, гибкий
диск)
Memory Позволяет указать выделение памяти виртуальной машине
Processor Позволяет указать выделение логических процессоров виртуальной машины,
управление ресурсами и функциональность процессоров
IDE Controller 0 Позволяет добавлять виртуальные жесткие диски или устройства DVD, подклю-
ченные к виртуальной машине через контроллер IDE Controller 0
Hard Drive Позволяет настраивать, к какому виртуальному контроллеру (IDE или SCSI)
подключен жесткий диск и где он подключен. Также предоставляет доступ
к инструментам управления виртуальными жесткими дисками (сжатие, преобра-
зование, расширение и т. д.) и позволяет настраивать транзитные диски. И нако-
нец, позволяет удалять жесткие диски из виртуальной машины
Элемент
Описание
IDE Controller 1 Позволяет добавлять виртуальные жесткие диски или дисководы DVD, подклю-
ченные к виртуальной машине через контроллер IDE Controller 1
CD Drive, Позволяет подключать к виртуальной машине дисководы CD/DVD с интерфей-
DVD Drive сом IDE. CD или DVD может иметь вид образа ISO или физического дисковода
CD/DVD, инсталлированного на хосте. Кроме того, позволяет удалять дисководы
CD/DVD с виртуальной машины
SCSI Controller Позволяет добавлять на виртуальную машину виртуальные жесткие диски, под-
ключенные при помощи контроллера SCSI Controller
Legacy Network Позволяет добавлять, настраивать и удалять виртуальные сетевые адаптеры,
Adapter инсталлированные в виртуальную машину. Для каждого сетевого адаптера у вас
есть возможность указать подключение к виртуальной сети, а также выделение
адреса МАС (динамическое или статическое). Кроме того, вы можете настроить
и включить идентификацию виртуальных локальных сетей VLAN
Network Adapter Позволяет добавить, настроить и удалить синтетические сетевые адаптеры,
инсталлированные в виртуальной машине. Для каждого сетевого адаптера вы
можете указать подключение к виртуальной сети, а также выделение адреса
МАС (динамическое или статическое). Кроме того, вы можете настроить и вклю-
чить идентификацию виртуальных локальных сетей VLAN
COM 1, COM 2 Позволяет подключить порты СОМ к виртуальной машине или отключить от нее.
Порты СОМ могут подключаться к именованному каналу на локальном или уда-
ленном компьютере
Diskette Drive Позволяет подключить виртуальный дисковод гибкого диска к существующему
образу гибкого диска
В табл. 2.5 приведен список опций конфигурирования управления виртуальными ма-

шинами и описание изменений, которые связаны с каждой опцией.
Таблица 2.5. Опции конфигурирования управления виртуальными машинами
Элемент
Описание
Name Позволяет указать название виртуальной машины, а также примечания о ней

Integration Позволяет выбрать компоненты Integration Services, которые Hyper-V будет под-
Services держивать для виртуальной машины
Snapshot File Позволяет указать каталог, который используется для хранения файлов момен-
Location тальных снимков
Automatic Start Позволяет настроить запуск виртуальной машины при запуске сервера Hyper-V.
Action Можно настроить следующие действия: старт при условии, что виртуальная маши-
на работала при остановке сервера; старт виртуальной машины всегда; отсутст-
вие всякого действия. Кроме того, есть вариант указания задержки автоматическо-
го старта (для уменьшения конкуренции за ресурсы между виртуальными маши-
нами)
Automatic Stop Позволяет настроить останов виртуальной машины при выключении сервера
Action Hyper-V. Можно настроить следующие действия: сохранить состояние виртуальной
машины (сохраненное состояние); выключение виртуальной машины; прекраще-
ние работы гостевой операционной системы. Гостевая операционная система
должна поддерживать службы Integrations Services
Управление виртуальными жесткими дисками

Менеджер Hyper-V Manager позволяет вам создавать, изучать и редактировать вирту-
альные жесткие диски и виртуальные гибкие диски на управляемом вами сервере
Hyper-V. Точно так же, как виртуальный жесткий диск является представлением физи-
ческого жесткого диска (в виде одного файла), так и виртуальный гибкий диск являет-
ся представлением физического гибкого диска (в виде одного файла).
Создание виртуальных жестких дисков

Файлы виртуальных жестких дисков — это основной компонент виртуальной машины,
инкапсулирующей гостевую операционную систему и данные приложений. Внутри
Hyper-V Manager виртуальный диск можно создать отдельно от виртуальной машины
(при помощи выбора опции New в панели Actions, а затем выбора пункта Hard Disk).
На рис. 2.18 показан запускающийся после этого мастер New Virtual Hard Disk Wizard.
Для создания виртуального жесткого диска вы должны определить его тип (динамиче-
ски расширяющийся, фиксированного размера, разностный), указать название и место
хранения для нового VHD, а также определить размер нового VHD. Вы можете также
задать (по желанию) копирование содержимого физического диска на новый VHD.
Рис. 2.18. Создание нового виртуального жесткого диска в Hyper-V Manager
Подробности относительно всех типов жестких дисков см. в главах 3 и 5.
Виртуальная машина предоставляет гостевой операционной системе один виртуальный

дисковод гибких дисков. Виртуальная машина не поддерживает удаление виртуально-
го дисковода гибких дисков, не поддерживает она также и подключения дополнитель-
ных дисководов гибких дисков. Менеджер Hyper-V Manager позволяет создать вирту-
альный гибкий диск только размером 1,44 Мбайт. Виртуальный гибкий диск создается
при помощи выбора опции New в панели Actions, затем надо выбрать пункт Floppy
Disk и указать имя файла и местоположение нового виртуального гибкого диска.
Изучение и редактирование виртуальных жестких дисков

Если вы выберете опцию Inspect Disk в панели Actions, то менеджер Hyper-V Manager
выдаст вам запрос на идентификацию целевого виртуального жесткого диска. Hyper-V
открывает виртуальный жесткий диск, получает его текущий и максимальный размеры
(а также тип виртуального жесткого диска), после чего отображает полученную ин-
формацию (рис. 2.19).
Рис. 2.19. Изучение виртуального жесткого диска в менеджере Hyper-V Manager
Если вы выберете опцию Edit Disk в панели Actions, то менеджер Hyper-V Manager
запустит мастер Edit Virtual Hard Disk Wizard (рис. 2.20).
После выбора целевого виртуального жесткого диска (и в зависимости от его типа)
будет показан список потенциально возможных действий. В табл. 2.6 содержится спи-
сок потенциально возможных действий, которые имеются для каждого типа виртуаль-
ных жестких дисков.
Таблица 2.6. Возможные действия по редактированию виртуальных жестких дисков
Действие Тип VHD Описание
Compact • Динамически расширяющийся Сжать динамически расширяющийся диск

для возврата неиспользуемого пространства
• Разностный
Convert • Динамически расширяющийся Конвертирование динамически расширяющегося
диска в диск фиксированного размера
• Фиксированного размера (или наоборот)
Действие Тип VHD Описание
Expand • Динамически расширяющийся Увеличение размера виртуальных жестких

дисков
• Фиксированного размера
Merge Разностный Сливание изменений дочернего диска в роди-
тельский диск, либо объединение родительского
и дочернего дисков в новый виртуальный жест-
кий диск
Reconnect Разностный Подключение дочернего разностного диска
к родительскому виртуальному жесткому диску
Рис. 2.20. Мастер Edit Virtual Hard Disk Wizard менеджера Hyper-V Manager
Управление виртуальными сетями

Менеджер Hyper-V Manager позволяет создавать, добавлять и конфигурировать вирту-
альные сети на управляемом вами сервере Hyper-V. Виртуальные сети позволяют вир-
туальным машинам подключаться друг к другу, к хосту, а также к другим физическим
или виртуальным машинам на физической сети.
Создание виртуальных сетей

Для создания новой виртуальной сети выберите пункт Virtual Network Manager в па-
нели Actions менеджера Hyper-V Manager. Менеджер запустит показанный на рис. 2.21
менеджер Virtual Network Manager.
Для создания новой виртуальной сети вы должны выбрать один из трех имеющихся
типов: External (Внешняя), Internal (Внутренняя) или Private (Частная). Внешняя вир-
туальная сеть обеспечивает виртуальной машине подключение к внешним физическим
сетям. Этот тип виртуальной сети должен быть привязан к физическому сетевому
адаптеру, инсталлированному на сервере Hyper-V. Внутренняя виртуальная сеть обес-
печивает подключения между виртуальными машинами и сервером Hyper-V, но не да-
ет доступа к физическим сетям. Иначе говоря, по физической сети не будут переда-
ваться никакие пакеты от виртуальных машин или сервера Hyper-V. Частная виртуаль-
ная сеть еще более ограничена, чем внутренняя, т. к. она обеспечивает подключения
только между виртуальными машинами. Доступа к физическим сетям или серверу
Hyper-V нет.
Рис. 2.21. Менеджер Virtual Network Manager, запущенный из менеджера Hyper-V Manager
Если вы решите добавить новую внешнюю виртуальную сеть, то вам придется указать
название для этой новой виртуальной сети и выбрать физический сетевой адаптер,
к которому она будет привязана. Как показано на рис. 2.22, в панели New Virtual
Network есть раскрывающийся список, который позволяет вам выбрать нужный физи-
ческий сетевой адаптер из списка имеющихся адаптеров.
Рис. 2.22. Параметры конфигурирования виртуальной сети в менеджере Virtual Network Manager
Если вы выберете новую виртуальную сеть типа "внутренняя" или "частная", то вам
нужно будет указать соответственно опции Internal only или Private virtual machine
network (в группе Connection type).
Если вы выберете новую виртуальную сеть типа "внешняя" или "внутренняя", то смо-
жете также включить и настроить идентификатор ID виртуальной локальной сети
(VLAN). Этот идентификатор может использоваться для изоляции сетевого трафика от
других виртуальных машин, подключенных к этой же виртуальной сети. Виртуальные
машины с одним и тем же идентификатором VLAN могут обмениваться друг с другом,
но не с системами, имеющими другое значение идентификатора VLAN. Для частных
виртуальных сетей VLAN не поддерживается.
Приложение для подключения виртуальных машин

Вы можете получить удаленный доступ к виртуальной машине при помощи приложе-
ния Virtual Machine Connection (VMC), которое встроено в менеджер Hyper-V Manager.
Для запуска VMC и подключения к виртуальной машине нужно дважды щелкнуть по
значку в нижней части центральной панели менеджера Hyper-V Manager (или щелкнуть
Рис. 2.23. Подключение к виртуальной машине при помощи VMC в менеджере Hyper-V Manager
Рис. 2.24. Вид VMC

правой кнопкой мыши на названии виртуальной машины и выбрать пункт Connect

контекстного меню (рис. 2.23)).
VMC по существу создает сеанс удаленного рабочего стола в графическом интерфейсе
Hyper-V и организует подключение к виртуальной машине (для ее администрирова-
ния). Пример VMC показан на рис. 2.24. Графический интерфейс VMC обеспечивает
большую часть имеющейся в менеджере Hyper-V Manager функциональности по
управлению виртуальными машинами. Сюда входят: действия по изменению состоя-
ния виртуальной машины (Start, Turn Off, Save и т. д.); доступ к настройкам вирту-
альной машины; управление моментальными снимками; работа с привязками вирту-
альных DVD- и дисководов гибких дисков к различным носителям; возможность
инсталляции служб Integration Services.
VMC позволяет осуществлять удаленный доступ к виртуальной машине и взаимодей-
ствие с ней с момента ее включения.
Управление настройками Hyper-V

Менеджер Hyper-V Manager позволяет также конфигурировать настройки Hyper-V. На
рис. 2.25 показано диалоговое окно Hyper-V Settings, которое отображается после вы-
бора опции Hyper-V Settings в панели Actions.
Рис. 2.25. Настройки Hyper-V

Есть два набора настроек Hyper-V, которые вы можете модифицировать: Server (Сер-
верные) и User (Пользовательские). Настройки Server позволяют вам указать каталог
по умолчанию для хранения файлов виртуальных жестких дисков и файлов конфигу-
рации виртуальных машин. Настройки User имеют несколько пунктов. Пункт
Keyboard позволяет вам настроить фокус (для обработки клавиатурных комбинаций
Windows) либо на физический сервер, либо на виртуальную машину. Mouse Release
Key дает вам возможность настроить клавиатурные комбинации для того случая, когда
службы Integration Services не инсталлированы (или не поддерживаются) в гостевой
операционной системе. User Credentials позволяет указать, должен ли Virtual Machine
Connection автоматически использовать ваши учетные данные для подключения к вир-
туальной машине. Компонент Delete Saved Credentials позволяет вам удалять учетные
данные, которые вы использовали для подключения к виртуальной машине. И наконец,
функция Reset Check Boxes позволяет восстановить настройки по умолчанию для под-
тверждающих сообщений Hyper-V и страниц мастеров (скрытые при помощи установ-
ки определенных флажков).
Принципы интерфейса
прикладного программирования WMI
Hyper-V предоставляет обширный и мощный интерфейс прикладного программирова-
ния WMI API, который можно использовать: для программного управления сервером
Hyper-V, наблюдения за ним, а также для автоматизации развертывания и управления
виртуальными машинами. Все предлагаемые менеджером Hyper-V Manager возможно-
сти можно воспроизвести при помощи скриптов, использующих этот интерфейс.
Скрипты и собственные приложения можно создавать на разных языках, в том числе
C#, Perl, C++ или Visual Basic (и это только наиболее популярные). Скрипты можно
выполнять при помощи Microsoft Windows PowerShell, который позволяет выполнять
команды внутри командной строки Windows и сразу же видеть их результаты.
Интерфейс WMI API подробно обсуждается в главе 16. Глава 16 содержит много скриптов,
которые вы можете применять или модифицировать для использования в своих усло-
виях.
Резюме
Hyper-V предоставляет много функциональных возможностей, в том числе виртуаль-
ные машины, которые обеспечивают стандартную виртуальную аппаратную среду для
своих гостевых операционных систем и приложений. Познакомиться с виртуальной
аппаратной средой и моделью новых синтетических устройств в Hyper-V совершенно
необходимо для того, чтобы принимать компетентные решения относительно физиче-
ских рабочих нагрузок, которые могут быть развернуты в виде виртуальных машин.
Создание, изучение и конфигурирование главных компонентов виртуальных машин
(в том числе виртуальных жестких дисков и виртуальных сетей) можно осуществлять
при помощи менеджера Hyper-V Manager. Вы можете также использовать менеджер

Hyper-V Manager для конфигурирования настроек Hyper-V.
Используйте приложение Virtual Machine Connection внутри Hyper-V (или в виде от-
дельного приложения) для удаленного доступа и работы с виртуальными машинами
с момента их активации. Если вы предвидите развертывание большого количества сер-
веров Hyper-V и виртуальных машин (или у вас их уже много), то вам для программно-
го управления развертыванием, администрированием и конфигурированием серверов
Hyper-V и виртуальных машин следует использовать интерфейс WMI API (либо ме-
неджер System Center Virtual Machine Manager).
Дополнительные источники информации

блог Microsoft Technet "Can I run Hyper-V on my machine?" по адресу:
http://blogs.technet.com/apawar/archive/2008/11/11/can-i-run-Hyper-V-on-my-
machine.aspx;
блог Windows Virtualization Team по адресу:
http://blogs.technet.com/virtualization/default.aspx.
Web-cайт Microsoft, "Virtualization with Hyper-V: Technical Resources" по адресу:
http://www.microsoft.com/windowsserver2008/en/us
/hyperv-technical-resources.aspx;
Web-сайт Microsoft, руководство "Microsoft Hyper-V Server 2008 Configuration
Guide", доступное по адресу:
http://www.microsoft.com/downloads/details.aspx?FamilyId=E1E111C9-FA69-
4B4D-8963-1DD87804C04F&displaylang=en.
ГЛАВА 3
Архитектура Hyper-V
Компания Microsoft поставляет Hyper-V в двух видах: как роль сервера Windows
Server 2008 и как отдельный продукт под названием Microsoft Hyper-V Server 2008.
Сервер Windows Server 2008 может инсталлироваться как с ролью Hyper-V, так и без
нее. Без Hyper-V компоненты операционной системы и приложения работают непо-
средственно на аппаратном обеспечении. При появлении Hyper-V это поведение ко-
ренным образом изменяется. Сервер Microsoft Hyper-V Server является отдельным про-
дуктом, который реализует виртуализацию на базе технологий, используемых в
Windows Server 2008 и Hyper-V. Сервер Hyper-V Server имеет очень похожую на Hyper-V
в Windows Server 2008 архитектуру, например, он использует те же драйверы, что и
Windows, что позволяет серверу Windows Hyper-V Server работать на самом разнооб-
разном серверном оборудовании. В этой главе описывается архитектура роли Hyper-V
в Windows Server 2008, но все сказанное применимо также и к Microsoft Hyper-V
Server 2008.
Роль Hyper-V в Windows Server 2008 состоит из набора компонентов, который включа-
ет: гипервизор (называемый гипервизором Windows), компоненты режима ядра и ком-
поненты пользовательского режима. Гипервизор Windows спроектирован как гиперви-
зор первого типа на базе микроядра. Это означает, что гипервизор Windows работает
непосредственно на аппаратном обеспечении.
Кольца процессора определяют уровень привилегий для инструкций, причем кольцо
Ring 0 имеет наивысшие привилегии, а кольцо Ring 3 — низшие. Ядро операционной
системы работает в кольце Ring 0, а приложения пользователя обычно работают в
кольце Ring 3. Кольцо Ring –1 (с номером "минус один") было введено в аппаратных
расширениях виртуализации, которые компании Intel и AMD реализовали в своих но-
вых линейках процессоров. Это новое кольцо позволяет гипервизору Windows рабо-
тать в своем собственном контексте и с таким уровнем привилегий, который выше
уровня ядра Windows, позволяя в то же время ядру любой гостевой операционной сис-
темы выполняться в кольце Ring 0. Пользовательские приложения продолжают рабо-
тать в кольце Ring 3.
На рис. 3.1 показано графическое представление связей между режимами ядра и поль-
зовательским режимом, уровнями колец процессора, а также компонентами Hyper-V.
После инсталляции роли Hyper-V и загрузки гипервизора можно создавать разделы.

Корневой раздел (называемый родительским) — это единственный создаваемый по
умолчанию раздел, который содержит операционную систему Windows Server 2008 и
драйверы. Вместе с Hyper-V инсталлируется также целый набор компонентов, которые
обеспечивают управление разделами, доступ к оборудованию и интерфейсы програм-
мирования.
Рис. 3.1. Стек Windows Server 2008 с активированной ролью Hyper-V
Гипервизор Windows
Гипервизор Windows — это программный интерфейс, который находится между физи-
ческим оборудованием и операционными системами. Гипервизор Windows управляет
доступом к оборудованию и определяет изолированные среды выполнения (называе-
мые разделами).
Главные задачи гипервизора Windows — гарантировать изоляцию разделов, обеспе-
чить реализацию политик по ограничению доступа к оборудованию, а также наблюдать
за разделами. Гипервизор управляет определенным набором оборудования, что позво-
ляет ему гарантировать изоляцию всех разделов, делегируя в то же время управление
доступом (к остальному оборудованию) процессам или драйверам родительского раз-
дела. Гипервизор Windows управляет: маршрутизацией прерываний (так, как это дела-
ют контроллеры прерываний (APIC)); физическими процессорами для спланированно-
го доступа виртуальной машины к логическим процессорам; системными счетчиками;
физическим адресным пространством (для управления доступом к оперативной памяти
и памяти устройств); а также прочим оборудованием. Родительский раздел управляет
выделением памяти, питанием процессора и системы, доступом к шине PCI, доступом
к устройствам (через драйверы устройств) и т. д.
Глава 3. Архитектура Hyper-V 85
Гипервизор должен быть простым и выполнять свои операции быстро и без перерывов.
Это достигается (среди прочего) еще и тем, что гипервизор не вытесняемый. Для этого
при выполнении кода внутри гипервизора деактивируются внешние и межпроцессор-
ные прерывания. При выполнении кода внутри гипервизора могут происходить только
прерывания управления системой (system management interrupt, SMI) и немаскируемые
прерывания (nonmaskable interrupts, NMI).
Гипервизор Windows логически разделен на два уровня. Нижний уровень содержит
микроядро, которое поддерживает выделение адресного пространства памяти, потоки,
сигнализацию и механизмы абстрагирования от оборудования. Верхний уровень пре-
доставляет интерфейсы служб виртуализации (при помощи интерфейса прикладного
программирования гипервызовов). Службы виртуализации включают создание разде-
лов, виртуальные процессоры, а также трансляцию адресов.
Процесс загрузки гипервизора
Возможно, вас интересует, что же загружается сначала — гипервизор или Windows Server
2008. Загрузчик Windows Server 2008 грузит компьютер и загружает специальный драйвер
Hvboot.sys. Этот драйвер выполняет следующие шаги по инициализации гипервизора:
• определяет, не был ли уже загружен гипервизор и, если это так, прекращает загрузку
гипервизора;
• вызывает процедуру детектирования платформы (для определения процессора (Intel
или AMD) и наличия на нем расширений для виртуализации). Если процессор поддер-
живает такие расширения, то Hvboot.sys загружает образ гипервизора, который знает
архитектуру и расширения данного процессора. Вот образы гипервизора для конкрет-
ных процессоров:
AMD-V: %Systemroot%\System32\Hvax64.exe;
Intel VT: %Systemroot%\System32\Hvix64.exe;
• вызывает код запуска гипервизора на всех процессорах (известных родительской опе-
рационной системе) для запуска гипервизора;
• инициализирует специфичные для данной платформы структуры процессоров и прочие
подсистемы гипервизора (при помощи процессорных расширений для виртуализации).
Когда эти операции завершаются, гипервизор полностью инициализирован. Для каждо-
го физического процессора создается виртуальный процессор, и родительская опера-
ционная система изолируется в родительском разделе.
Управление возвращается родительской операционной системе (в родительский раздел),
и гипервизор в этот момент работает в непривилегированном режиме (Ring –1).
Джим Коллинз (Jim Collins, Senior Support Escalation Engineer
(Команда Windows Virtualization Support Team))
Разделы
Разделы — это изолированные (друг от друга) гипервизором контейнеры. Раздел со-
стоит из виртуального пространства адресов памяти, одного или нескольких виртуаль-
ных процессоров, рабочих процессов и коммуникационных интерфейсов. Виртуальное
пространство адресов памяти раздела сопоставляется с физическим пространством ад-
ресов памяти физического сервера. Количество виртуальных процессоров в разделе не
может превышать количества аппаратных потоков физического сервера.
Разделу может быть выделен доступ к конкретным аппаратным ресурсам (памяти,

устройствам, циклам процессора и т. д.), либо он может сам получить к ним доступ.
Каждый раздел имеет определенные разрешения и политику прав доступа (которые
обеспечиваются гипервизором Windows).
В Hyper-V есть два типа разделов: родительский и дочерний. Hyper-V имеет один ро-
дительский раздел и один (или более) дочерний раздел.
Родительский раздел
Родительский раздел — это первый создаваемый раздел. Несмотря на то, что фор-
мально это виртуальная машина, он имеет уникальные свойства. Он владеет всеми те-
ми ресурсами, которые не принадлежат гипервизору. Он управляет созданием и рабо-
той дочерних разделов. Он управляет доступом к ресурсам и определяет, могут ли они
совместно использоваться дочерними разделами, либо ограничены одним дочерним
разделом. Он отвечает за управление электропитанием, технологию Plug & Play, а так-
же за аппаратные события. В родительский раздел загружаются все драйверы для фи-
зических устройств. В то время как дочерний раздел видит эмулированные или синте-
тические устройства, родительский раздел видит реальное физическое оборудование.
Дочерний раздел
Дочерние разделы — это программные представления физического оборудования (они
называются также виртуальными машинами). Дочерние разделы не имеют прямого
доступа к реальному физическому оборудованию сервера. Все, что они видят, — это
представленные им виртуальное оборудование и виртуальные устройства. Каждый до-
черний раздел видит одно и то же основное виртуальное оборудование: материнскую
плату, последовательные порты, видеокарту, шину PCI и т. д. В виртуальную материн-
скую плату можно вставить дополнительное виртуальное оборудование. В число тако-
го оборудования входят: виртуальные сетевые адаптеры, виртуальные адаптеры SCSI,
виртуальные жесткие диски, виртуальные дисководы CD/DVD, а также память. Неко-
торые из виртуальных устройств представляют собой свои физические аналоги, такие
виртуальные устройства называются эмулированными устройствами. Те виртуальные
устройства, у которых нет физических аналогов, называются синтетическими устрой-
ствами.
На рис. 3.2 показана связь между гипервизором Windows, родительским и дочерними
разделами (в которых работают разные операционные системы). В легенде указано,
какой элемент какие компоненты предоставляет.
Стек виртуализации
Стек виртуализации в Hyper-V — это коллекция программных компонентов и вирту-
альных устройств, которые работают вместе для создания виртуальных машин и
управления ими. Для этого стек работает вместе с консолью Hyper-V Management и
гипервизором. Есть компоненты стека, которые работают в родительском разделе, а
также компоненты дочерних разделов.
Рис. 3.2. Архитектура Windows Server 2008 Hyper-V
Стек виртуализации включает в себя следующие главные компоненты. Некоторые из

этих компонентов состоят из одного или более подкомпонентов:
рабочие процессы;
компонент конфигурирования;
интерфейсы Windows Management Instrumentation (WMI);
служба Virtual Machine Management Service (VMMS);
поставщик Virtualization Service Provider (VSP);
клиент Virtualization Service Client (VSC);
драйвер Virtualization Infrastructure Driver (VID);
менеджер Virtualization Stack Memory Manager (VSMM);
шина Virtual Machine Bus (VMBus);
эмулируемые устройства;
виртуальная материнская плата;

службы Integration Services.
На рис. 3.3 представлен вид стека виртуализации, в том числе: реализация компонен-
тов по режимам (в пользовательском режиме или режиме ядра); а также реализация
компонентов по разделам (в родительском/дочернем разделе).
Рис. 3.3. Стек виртуализации
В следующих разделах приводятся подробности по компонентам стека виртуализации

(что они делают и как взаимодействуют).
Служба управления виртуальными машинами

Служба Virtual Machine Management Service (VMMS) является коллекцией компонен-
тов, которые совместно работают при управлении виртуальными машинами. VMMS
реализована как исполняемый модуль VMMS.exe с названием Hyper-V Virtual Machine
Management.
VMMS отвечает за: предоставление поставщика WMI виртуальных машин; управление
виртуальными машинами, рабочими процессами, моментальными снимками; предос-
тавление модуля прослушивания RDP для перенаправления рабочего стола; регистра-
цию и управление точками подключения служб (service connection points, SCP) в Active
Directory; а также предоставление интерфейса записи службы Volume Shadow Copy

Service (VSS) для создания моментальных VSS-снимков родительского раздела и вир-
туальных машин.
Внутри VMMS имеются следующие компоненты:
поставщик WMI;
менеджер виртуальных машин Virtual Machine Manager;
менеджер рабочих процессов Worker Process Manager;
менеджер Snapshot Manager;
модуль прослушивания Single Port Listener для RDP;
маркер Active Directory Service Marker;
модуль записи VSS Writer;
управление ресурсами кластера Cluster Resource Control.
На рис. 3.4 дана схема, которая показывает все подкомпоненты службы Virtual Machine
Management Service.
Рис. 3.4. Схема компонентов службы Virtual Machine Management Service
Поставщик WMI
Компонент WMI Provider позволяет производить удаленное управление виртуальными
машинами (в зависимости от описанной объектной модели). Когда поставщик WMI
получает запрос на управление виртуальной машиной, он сначала определяет, работает
ли виртуальная машина. Если она работает, то поставщик WMI направляет запрос ра-
бочему процессу виртуальной машины. Затем рабочий процесс направляет запрос к
соответствующему устройству или компоненту и возвращает результат поставщику
WMI (чтобы вернуть его вызвавшему приложению). Если виртуальная машина нахо-
дится в автономном режиме, то нет рабочего процесса (которому можно направить за-
прос), поэтому VMMS сама обрабатывает запрос. VMMS определяет, какому устройст-
ву или компоненту предназначен запрос, загружает устройство (или выполняет обмен
с компонентом) и отправляет запрос. Когда ответ возвращается в VMMS, служба на-
правляет его вызывающему приложению.
В разд. "Дополнительные источники информации" далее в этой главе дана ссылка на
спецификацию Virtualization WMI.
Менеджер виртуальных машин

Менеджер Virtual Machine Manager (VMM) поддерживает список определенных в
Hyper-V виртуальных машин, создает рабочие процессы, управляет конфигурировани-
ем виртуальных машин, а также добавлением или удалением устройств. Когда VMM
запускается, он создает список виртуальных машин (зарегистрированных на сервере
Hyper-V) и поддерживает информацию по их состоянию (запуск, остановка, приоста-
новка, сохранение состояния). Если у виртуальной машины есть активный рабочий
процесс, то все запросы (на изменение состояния, конфигурирование и устройства) на-
правляются рабочему процессу. Если рабочего процесса нет, то запросы на изменение
конфигурации или изменение состояния обрабатывает VMM. Менеджер VMM работа-
ет с менеджером рабочих процессов (WPM) для запуска тех рабочих процессов, кото-
рые создает VMM.
Например, когда делается запрос на создание виртуальной машины, то VMM создает
для виртуальной машины конфигурацию по умолчанию, управляет изменениями этой
конфигурации до запуска виртуальной машины, а также регистрирует вновь созданную
виртуальную машину в поддерживаемом менеджером VMM списке.
Когда делается запрос на запуск виртуальной машины, то VMM делает поиск в списке
виртуальных машин, запрашивает создание нового рабочего процесса, а затем передает
рабочий процесс менеджеру WPM (чтобы он запустил рабочий процесс и отслеживал
его).
При запросе на останов работающей виртуальной машины VMM осуществляет поиск в
списке виртуальных машин, находит дескриптор рабочего процесса, а затем просит
рабочий процесс остановить виртуальную машину.
Менеджер рабочих процессов

Менеджер рабочих процессов Worker Process Manager (WPM) поддерживает список
всех выполняющихся рабочих процессов и запускает их, а также обеспечивает (для
подписчиков) уведомления об изменениях состояния рабочих процессов. Когда WPM
запускает новый рабочий процесс, то он добавляет его в список выполняющихся про-
цессов. После запуска рабочего процесса и регистрации его в списке WPM подписыва-
ется на события изменений для этого рабочего процесса и позволяет внутренним ком-
понентам подписаться на уведомления об изменениях рабочего процесса. Когда проис-
ходят изменения состояния (запуск, остановка, приостановка, возобновление и т. д.)
или другие события, то WPM посылает уведомления о событии всем подписчикам.
Когда менеджер WPM запускается, он связывается с менеджером VMM и перечисляет
все зарегистрированные виртуальные машины. С этого момента времени он поддержи-
вает список всех рабочих процессов, которые он запускает (и их текущее состояние).
Если по какой-то причине происходит перезапуск VMMS, то WPM проверяет, есть ли
у какой-нибудь виртуальной машины рабочий процесс, добавляет эту виртуальную
машину в список известных рабочих процессов и подписывается на события измене-

ний. Когда происходит изменение состояния, то список рабочих процессов обновляет-
ся (они добавляются или удаляются по мере необходимости), и все подписчики уве-
домляются об изменении состояния.
Менеджер моментальных снимков

Моментальные снимки можно делать тогда, когда виртуальная машина находится как в
автономном, так и в активном состоянии. Если виртуальная машина активна, то вы-
полнением моментальных снимков управляет конечный автомат рабочего процесса.
Рабочего процесса для управления моментальными снимками при автономном состоя-
нии нет, поэтому этим занимается менеджер моментальных снимков Snapshot Manager.
Когда запрашивается моментальный снимок для автономной виртуальной машины,
менеджер Snapshot Manager выполняет следующие шаги (в общих чертах):
1. Создает новый разностный диск (используя текущий виртуальный жесткий диск как
родительский).
2. Создает файл конфигурации нового моментального снимка и каталог для него.
3. Копирует текущий файл конфигурации VM в файл конфигурации моментального
снимка.
4. Копирует файлы сохраненного состояния (vsv и bin) в каталог конфигурации мо-
ментального снимка.
Удаление моментального снимка несколько сложнее, поскольку для него необходимо
исследовать цепочку разностных дисков и их зависимости, но в общих чертах менед-
жер моментальных снимков при получении запроса на удаление моментального сним-
ка делает следующее (если виртуальная машина находится в автономном режиме):
1. Удаляет конфигурационный файл подлежащего удалению моментального снимка.
2. Удаляет файлы сохраненных состояний в каталоге моментального снимка.
3. Удаляет каталог моментального снимка.
4. Делает слияние текущего разностного диска моментального снимка (при необходи-
мости).
Дополнительную информацию о моментальных снимках см. в главе 5.
Модуль прослушивания для RDP

Протокол Remote Desktop Protocol (RDP) используется для передачи видеоизображе-
ния, клавиатурного ввода и перемещений мыши между сервером и клиентским прило-
жением. В Hyper-V в сеансе управления удаленной виртуальной машиной по протоко-
лу RDP работает несколько компонентов (на порту 2179). Модуль прослушивания
Single Port Listener (SPL) для RDP внутри VMMS управляет запросами на входящие
подключения от клиента управления виртуальными машинами (Vmconnect.exe) и пере-
направляет их к соответствующему рабочему процессу для обработки. Рабочий про-
цесс имеет подкомпонент RDP Encoder, который принимает подключение и работает с

менеджером ввода и монитором видео для того, чтобы обеспечить работу пользователя
по RDP в сеансе консоли виртуальной машины.
Маркер службы Active Directory Service

Маркер Active Directory Service Marker (ADSM) является подкомпонентом VMMS, ко-
торый обеспечивает регистрацию и управление точками подключения служб (service
connection points, SCP) в Active Directory. SCP — это опубликованный в Active
Directory объект, позволяющий клиентам запрашивать те данные, которые служба
опубликовала в SCP. Точки SCP хранятся в глобальном каталоге, что делает их дос-
тупными всему дереву Active Directory.
Точка SCP регистрируется при инсталляции Hyper-V в объекте компьютера. При каж-
дом запуске службы Virtual Machine Management Service маркер ADSM пытается по-
вторно зарегистрировать точку подключения службы. Если в течение времени тайм-
аута не будет найден контроллер домена Active Directory, то в журнал событий
\Application and Services Log\Microsoft\Windows\Hyper-V VMMS\Admin будет записано
событие с идентификатором 14050.
Для загрузки и предоставления служб виртуализации серверу Hyper-V не требуется
успешная регистрация SCP. Если не удается зарегистрировать запись об SCP, то запрос
в Active Directory не будет выдавать результатов по данному серверу Hyper-V.
Объекты SCP содержат имеющий множество значений элемент ServiceBinding-
Information. По умолчанию ADSM регистрирует следующую информацию привязки:
ServiceBindingInformation[0] = UNC для подключения к серверу по WMI;
ServiceBindingInformation[1] = URL для подключения к серверу по WS-Management;
ServiceBindingInformation[2] = URL для подключения к серверу по RDP;
ServiceBindingInformation[3] = местоположение хранилища AzMan.
Модуль записи VSS

Служба Volume Shadow Copy Service (VSS) использует три слоя компонентов для
идентификации объектов резервного копирования, выполнения операций резервного
копирования и восстановления предварительно скопированных объектов:
VSS Requestor собирает информацию по объектам и управляет процессом;
VSS Framework является интерфейсом между VSS Requestor и VSS Writer, а также
управляет процессом выполнения моментальных снимков;
VSS Writer выполняет специализированные действия для того компонента, ради
работы с которым он спроектирован.
VSS Requestor — это приложение резервного копирования, которое делает запрос на
выполнение резервного копирования. Для того чтобы обеспечить наилучшую резерв-
ную копию, он запрашивает у родительского раздела перечисление всех модулей запи-
си VSS, которые зарегистрированы в системе. VSS Requestor выбирает соответствую-
щие модули записи VSS и запрашивает у них все поддерживаемые ими компоненты.
Модуль записи VSS Writer возвращает описание метаданных компонента.
Модуль записи VSS Writer работает с каждой виртуальной машиной как с отдельным
компонентом. Запрос от VSS Requestor к модулю записи VSS Writer вернет описание
метаданных каждой виртуальной машины (по отдельности). Описание метаданных го-
ворит Requestor о том, какую информацию ему нужно копировать для получения со-
гласованной резервной копии. Описание метаданных виртуальной машины содержит
следующую информацию:
конфигурационные файлы виртуальной машины;
файлы моментальных снимков;
всю информацию с виртуальных дисков (кроме транзитных дисков).
Модуль записи VSS в Hyper-V поддерживает резервное копирование как активных, так
и автономных виртуальных машин. Для выполнения резервного копирования активной
машины виртуальная машина должна иметь загруженными службы Integration Services
(чтобы была инсталлирована служба VSS Writer Integration Services и ее можно было
запрашивать).
Управление ресурсами кластера

Управление ресурсами кластера — это интерфейс службы VMMS для компонента
пользовательского режима Vmclusres.dll, который используется в Windows 2008
Failover Clustering для создания и управления виртуальными машинами высокой го-
товности. Управление ресурсами кластера принимает команды по управлению состоя-
нием и конфигурированием виртуальной машины и передает их соответствующим
подкомпонентам или рабочему процессу.
Компонент конфигурирования
Компонент конфигурирования обеспечивает создание, управление, модификацию и
уничтожение конфигурационных настроек дочернего раздела. Когда компоненту стека
виртуализации необходимо получить пару "ключ/значение" из файла настроек вирту-
альной машины, этот запрос должен быть направлен для обработки в компонент кон-
фигурирования. Настройки конфигурации сохраняются в XML-файле. По умолчанию
файл конфигурации создается в корне того каталога, где создана виртуальная машина,
ему присваивается имя GUID.xml, где GUID — это глобально-уникальный идентифи-
катор дочернего раздела.
Поставщики службы виртуализации

Поставщики Virtualization Service Providers (VSP) — это программные компоненты,
которые работают в родительском разделе и обрабатывают запросы ввода/вывода от
имени виртуальных машин. Поставщики VSP предоставляют интерфейс к клиентам
служб виртуализации Virtualization Service Clients (VSC) через шину VMBus. Постав-
щики VSP также ведут обмен с физическим оборудованием (через стек драйверов
Windows или драйвер устройства) для обработки запросов ввода/вывода. Они могут
существовать как в пользовательском режиме, так и в режиме ядра, и могут быть реа-
лизованы как объекты СОМ, службы или драйверы. Каждый VSP обменивается с од-
ним или несколькими VSC (при помощи выделенных каналов "точка — точка"). Роди-
тельский раздел содержит VSP для видео, сети и устройств человеко-машинного ин-
терфейса. Один VSP может обслуживать несколько VSC дочерних разделов (при по-
мощи выделенных каналов обмена по шине VMBus).
Ввод/вывод по сети в родительском разделе
Несмотря на то, что поставщики Virtualization Service Providers обычно обслуживают запро-
сы ввода/вывода только от клиентов Virtualization Service Client, существует также специ-
альный случай для сетевого VSP и родительского раздела. Если виртуальная сеть была
создана и привязана к физическому сетевому адаптеру, то по умолчанию те запросы на се-
тевой ввод/вывод родительского раздела, которые маршрутизируются через этот физиче-
ский сетевой адаптер, будут проходить через сетевой VSP. Для того чтобы предотвратить
использование этого адаптера сетевым трафиком родительского раздела (т. е. предотвра-
тить обмен между родительским разделом и сетевым VSP), вы можете деактивировать
подключение Local Area Network родительского раздела к физическому сетевому адаптеру
(в окне Control Panel | Network Connections).
Арно Михм (Arno Mihm, Program Manager (Команда Windows Virtualization Team))
Клиенты службы виртуализации

Клиенты Virtualization Service Clients (VSC) — это синтетические драйверы, которые
работают в дочернем разделе и обмениваются по шине VMBus с соответствующими
поставщиками Virtualization Service Providers родительского раздела. VSC имеются для
сети, видео, хранения и интерфейсных устройств.
Клиенты Virtualization Service Clients инсталлируются при инсталляции в дочернем
разделе компонентов Integration Services. До инсталляции VSC дочерний раздел видит
эмулированное оборудование и загружает драйверы для этих устройств (если они су-
ществуют).
Шина VMBus
VMBus — это механизм для высокоскоростного обмена между разделами, который
состоит из множества компонентов (технологий):
протокол для передачи данных между дочерним и родительским разделами;
протокол для обнаружения или предложения служб дочерним разделам;
протокол для управления физическими адресами гостей;
драйвер шины, который реализует все протоколы;
библиотека передачи данных, которая предоставляет службы пользовательского
режима (или режима ядра).
Шина VMBus создана для обеспечения обмена "точка — точка" между дочерним и ро-
дительским разделами (по выделенному каналу). Каждый VSP предоставляет отдель-
ный канал для VSC из дочернего раздела. Один VSP может вести обмен со многи-
ми VSC.
Драйвер VMBus реализует конечные точки, которые позволяют читать и писать дан-
ные через VMBus. Каналы состоят либо из двух конечных точек (одна в VSC, а другая
в VSP), либо из двух кольцевых буферов (один в VSC, а другой в VSP). Каждый канал
имеет также страницу передачи (transfer page). Это предварительно выделенная стра-
ница памяти, которая сопоставлена обоим разделам (в конечных точках) и не является
частью кольцевого буфера. Страницы передачи используются как цель при передаче
данных в режиме direct memory address (DMA) или при других передачах данных, ко-
торые могут потребовать длительного времени для своего завершения. Для содействия
режиму DMA (для обеспечения устройства из родительского раздела прямым адресом
в памяти дочернего раздела) используется список дескрипторов Guest Physical Address
Descriptor List (GPADL). Для этого дочерний раздел размещает в списке дескрипторов
и в родительском разделе (указывающие на данные) адреса Guest Physical Addresses.
Данные перемещаются между разделами при помощи разных механизмов:
команды помещаются в кольцевые буфера;
данные небольшого объема могут передаваться при помощи кольцевых буферов;
более значительные объемы данных используют страницы передачи, управляемые
командами из кольцевых буферов;
те данные, которые имеют слишком большой объем для буферов передачи, исполь-
зуют адреса GPADL и DMA (без копирования данных);
пакеты посылаются асинхронно по шине VMBus.
Гипервизор Windows участвует в настройке каналов VMBus (между дочерним и роди-
тельским разделами) и при необходимости в сигнальных разделах. Для передачи дан-
ных участие гипервизора не нужно.
Драйвер инфраструктуры виртуализации

Драйвер Virtualization Infrastructure Driver (VID) — это интерфейс уровня ядра (в роди-
тельском разделе) для гипервизора Windows (используются описанные интерфейсы
прикладного программирования, которые называются гипервызовами). VID предостав-
ляет службы для рабочего интерфейса и интерфейса административного управления
(работающих в пользовательском режиме) и ведет обмен с гипервизором Windows (для
координации работы виртуальных машин).
VID реализован в виде двух частей: драйвер (режима ядра) для устройства (VID.sys),
а также клиентский интерфейс пользовательского режима (VID.dll). Драйвер режима
ядра содержит логический подкомпонент Virtualization Stack Memory Manager
(VSMM). VID предоставляет службы завершения инструкций тогда, когда получено
прерывание памяти, а VSMM предоставляет интерфейсы VID для доступа к таблицам
страниц дочерних разделов и памяти (при завершении выполнения инструкций). На
рис. 3.5 показана связь между VID.dll и VID.sys.
VID обеспечивает управление разделами, виртуальными процессорами, памятью, а
также поддержку служб виртуализации на стадии выполнения.
Управление разделами
VID предоставляет службу Virtual Machine Management Service (VMMS), а рабочие
процессы предоставляют возможность создавать, удалять, запускать, останавливать,
Рис. 3.5. Интерфейс VID для гипервизора Windows и процессы пользовательского режима
сохранять, восстанавливать разделы и управлять ими. Драйвер VID фактически не вы-

полняет этих задач, он координирует доступ к гипервизору и другим службам (для вы-
полнения ими этих задач). Например, когда рабочий процесс запрашивает у VID соз-
дание раздела, то VID делает запрос к гипервизору на создание дочернего раздела, ги-
первизор создает этот раздел и возвращает дескриптор для него, а затем VID владеет
этим дескриптором и использует его для управления данным разделом.
При запросе на сохранение раздела VID сохраняет состояние работающего раздела и
всех его виртуальных процессоров в виде блока данных и возвращает его в рабочий
процесс. После этого рабочий процесс отвечает за хранение этого блока данных на
диске, а также за извлечение его и предоставление драйверу VID для восстановления.
Драйвер VID также предоставляет возможность управлять настройками выделения
процессоров (для тех разделов, которыми он владеет). Это такие настройки, как отно-
сительный вес раздела, резервирование и максимальное использование процессоров.
VSMM отвечает за установку пределов использования памяти.
Управление виртуальными процессорами

Драйвер VID предоставляет возможность управлять количеством виртуальных процес-
соров, выделенных разделу. Во время создания раздела количество виртуальных про-
цессоров по умолчанию устанавливается в 1. Для изменения количества виртуальных
процессоров после создания дочерний раздел должен быть в выключенном состо-
янии.
Драйвер VID также обеспечивает возможность: инициализировать, запускать и оста-
навливать раздел; предоставлять информацию о его состоянии, а также обрабатывать
прерывания раздела. Во время инициализации драйвер VID настраивает информацию

CPUID для каждого виртуального процессора. Это позволяет обрабатывать прерыва-
ния CPUID без участия дочерних разделов. Драйвер VID предоставляет возможность
запустить и остановить отдельный виртуальный процессор, а также уведомить дочер-
ний раздел о завершении этой операции. VID обеспечивает возможность для конечного
автомата (в рабочем процессе) читать и записывать состояние виртуальных процессо-
ров, которыми он владеет (когда виртуальный процессор находится в приостановлен-
ном состоянии). В состав этой информации входят: все регистры общего назначения,
управляющие регистры, регистры с плавающей точкой, регистры сегментов, регистры
отладки, а также таблицы дескрипторов. Это только часть возможностей по сохране-
нию состояния дочернего раздела.
Управление памятью
Менеджер Virtualization Stack Memory Manager (VSMM) обеспечивает интерфейсы (как
для пользовательского режима, так и режима ядра) для управления памятью дочерних
разделов. Интерфейс пользовательского режима — это интерфейс прикладного про-
граммирования управления вводом/выводом (IOCTL), а интерфейс режима ядра — это
Plug and Play (PnP) Device Interface. VSMM обеспечивает интерфейс с гипервизором
Windows через интерфейс прикладного программирования гипервызовов, предостав-
ляемый драйвером режима ядра WINHV.sys. VSMM имеет интерфейс с рабочими про-
цессами (при помощи интерфейса IOCTL), а также с поставщиками VSP (при помощи
интерфейса уровня ядра для устройств PnP).
VSMM получает уведомления от гипервизора Windows о случаях перехвата памяти.
При этом VSMM обрабатывает перехваты памяти и уведомляет гипервизор Windows о
том, что перехват был должным образом обработан.
Поддержка на этапе выполнения

Для поддержки работы разделов драйвер VID предоставляет службы обработки преры-
ваний (для инструкций IN/OUT) и службы завершения инструкций. VID предоставляет
службы обработки прерываний при помощи реализации внутренних обработчиков,
получающих перехваты от гипервизора Windows. VID обрабатывает процессорные ис-
ключения гостевых операционных систем, запросы доступа к специфическим для дан-
ной модели регистрам, а также запросы доступа к портам ввода/вывода. VSMM обра-
батывает все перехваты прерываний памяти от гипервизора. VID обеспечивает завер-
шение инструкций, работая как внешний монитор и перехватывая запросы доступа к
памяти, которые были помечены гипервизором для перехвата.
VID способен разбирать инструкции х86 и х64 и завершать те инструкции, которые не
завершил гипервизор Windows. Для разбора инструкции драйвером VID он должен:
уметь использовать свои знания таблиц страниц гостевых операционных систем,
а также соответствий текущих физических адресов гостевых операционных систем
физическим адресам хост-системы; уметь напрямую обращаться к данным в памяти
дочерних разделов. Или, проще говоря, VID должен уметь осуществлять прямой дос-
туп к памяти.
Интерфейсы WMI
Интерфейсы Windows Management Instrumentation (WMI) существуют для удаленного
управления и работы с Hyper-V. Интерфейсы WMI состоят из службы WMI, клиентов
WMI, а также поставщиков WMI. Служба WMI Service (SVCHost.exe) обеспечивает
интерфейс между клиентами WMI и поставщиками WMI. Клиенты WMI — это прило-
жения и компоненты, которым нужно получать данные от поставщиков WMI или вы-
давать определенные команды поставщикам для выполнения задач. На рис. 3.6 показа-
на схема, которая иллюстрирует интерфейсы WMI.
Рис. 3.6. Интерфейсы WMI
Служба Virtual Machine Management Service (VMMS) реализует основные поставщики

WMI, которые позволяют выполнять управление дочерними разделами. VMMS обес-
печивает интерфейс с объектами СОМ в виртуальных устройствах, рабочих процессах,
компоненте конфигурирования, а также в провайдерах VSP (для управления конфигу-
рацией и состоянием).
Для обеспечения интерфейсов WMI с целью управления хранением и сетью были реа-
лизованы две специальные службы. Служба Image Management Service (IMS) предос-
тавляет интерфейсы WMI для управления виртуальными жесткими дисками (VHD).
В то время как VMMS управляет интерфейсами WMI для подключения VHD к вирту-
альным машинам, служба IMS обеспечивает интерфейсы WMI для управления самими
VHD (обследование диска, слияние и сжатие). Служба Networking Management Service
(NMS) предоставляет интерфейсы WMI для управления виртуальными сетями и вирту-
альными коммутаторами. В то время как VMMS управляет интерфейсами WMI для
подключения виртуальных сетевых адаптеров дочерних разделов к виртуальным сетям,
служба NMS обеспечивает интерфейсы WMI для управления самими виртуальными
сетями (конфигурирование, привязка к физическим сетевым адаптерам, настройки
VLAN). Службы IMS и NMS реализованы как подключаемые интерфейсы для службы
WMI Service (SVCHost.exe).
Основной клиент WMI (который поставляется вместе с Hyper-V) — это оснастка
Hyper-V Manager для ММС. Он использует все интерфейсы WMI для управления вир-
туальными машинами, виртуальным хранением и виртуальными сетями.
Рабочий процесс
Рабочий процесс создается для каждой виртуальной машины, которая работает или
конфигурируется. Задача рабочего процесса — управлять рабочим состоянием вирту-
альной машины, управлять конфигурацией и состоянием виртуальной машины и ее
устройств, управлять удаленными сеансами RDP, вести обмен со службами интеграции
(которые работают в дочернем разделе). Для этого виртуальный процесс состоит из
некоторых подкомпонентов, которые обрабатывают различные аспекты вышеупомяну-
тых задач:
виртуальная материнская плата;
менеджер памяти;
виртуальные устройства;
конечный автомат;
интерфейс подключения виртуальных устройств;
службы интеграции (основное виртуальное устройство);
кодировщик RDP Encoder (основное виртуальное устройство).
Для выполнения задач управления рабочий процесс работает с другими внешними
компонентами стека виртуализации (рис. 3.7).
Виртуальная материнская плата

Виртуальная материнская плата предоставляет: определение виртуальных устройств и
интерфейсов материнской платы; возможность вставлять дополнительные эмулиро-
ванные или синтетические виртуальные устройства; а также управление BIOS. Вирту-
альная материнская плата разделена на два компонента. Первый поддерживает мани-
фест всех сконфигурированных устройств материнской платы. Манифест хранится в
поддерживаемом рабочим процессом репозитарии. Второй компонент — набор интер-
фейсов, которые предоставляют доступ к памяти, подключение и удаление виртуаль-
ных устройств, портов ввода/вывода, прерываний и таймеров. Интерфейсный компонент
Рис. 3.7. Компоненты и интерфейсы рабочего процесса
также ведет обмен с драйвером инфраструктуры виртуализации (при помощи уведом-

лений).
По умолчанию манифест виртуальной материнской платы содержит все основные (не-
удаляемые) виртуальные устройства и BIOS, кроме синтетических контроллеров видео
и мыши (являющихся подключаемыми виртуальными устройствами, которые нельзя
удалить). К материнской виртуальной плате могут быть подключены (или отключены
от нее) дополнительные виртуальные устройства вроде виртуальных сетевых карт или
виртуальных адаптеров SCSI. Добавление или удаление виртуального устройства тре-
бует выключения виртуальной машины. Подключаемые виртуальные устройства реа-
лизованы как синтетические устройства, которые работают как прокси для поставщи-
ков VSP (видео, сети и хранения).
Менеджер памяти
Менеджер памяти отвечает за управление ресурсами памяти для виртуальной машины.
Менеджер памяти реализует управление памятью, а виртуальная материнская плата
отвечает за предоставление интерфейсов менеджера памяти виртуальным устройствам.
Запросы на управление памятью приходят к виртуальной материнской плате от вирту-
альных устройств, а виртуальная материнская плата направляет их в менеджер па-
мяти. Менеджер памяти управляет запросами на память и реализует интерфейс с
Virtualization Stack Memory Manager (VSMM) для фактической реализации доступа
к памяти и управления ею.
Менеджер памяти отвечает за выделение и освобождение блоков памяти и установле-
ние соответствия между подразделами блоков памяти и физическими адресами (guest
physical addresses, GPA) гостевых операционных систем виртуальных машин. Когда

создается новый рабочий процесс, то менеджер памяти запрашивает компонент конфи-
гурирования о количестве выделенной памяти и вызывает VID для создания блока па-
мяти указанного размера. После выделения блока памяти менеджер памяти может соз-
дать соответствие GPA для всего блока памяти.
Подробное обсуждение физических адресов гостевых операционных систем см. в
разд. "Виртуальная память" далее в этой главе.
Основные виртуальные устройства

Рабочий процесс содержит основные виртуальные устройства, которые предоставляют
интерфейсы конечных точек для функций виртуальной материнской платы. Сюда вхо-
дят: BIOS, последовательные порты, IDE, службы интеграции, RDP, таймеры и пр. Ос-
новные виртуальные устройства создаются автоматически при создании рабочего про-
цесса и виртуальной материнской платы. Дополнительные виртуальные устройства
создаются как подключаемые DLL (чтобы их можно было добавить по желанию в лю-
бой момент). Эти устройства включают: сетевой адаптер, обычный сетевой адаптер,
адаптер SCSI. Подключаемые виртуальные устройства работают как прокси для обме-
на с поставщиками Virtualization Service Providers (VSP).
Конечный автомат
Конечный автомат создает экземпляр виртуальной машины и управляет ею (а также
переходами состояний), ее сохранением и восстановлением, а также моментальными
снимками. Конечный автомат никогда не обменивается напрямую с виртуальными уст-
ройствами; он всегда ведет обмен через виртуальную материнскую плату. Все интер-
фейсы с конечным автоматом реализованы через интерфейс прикладного программи-
рования управления состояний (с использованием WMI).
В табл. 3.1 приведены допустимые состояния виртуальной машины и описания каждо-
го состояния.
Таблица 3.1. Состояния виртуальной машины
Состояние Описание
Not Active Начальное состояние (когда создается рабочий процесс)
Starting Состояние включения виртуальной машины
Stopping Состояние выключения виртуальной машины
Paused Состояние, когда виртуальные процессоры не работают
Running Состояние, когда виртуальная машина закончила инициализацию состояния Starting
Saving Состояние, когда виртуальная машина сохраняет свое состояние на диск
Snapshotting Состояние, когда виртуальная машина делает моментальный снимок виртуальной

машины
Виртуальное устройство компонентов интеграции

Основные виртуальные устройства служб Integration Services обеспечивает интерфейс
обмена между работающими в дочерних разделах службами интеграции и рабочими
процессами (через работающих в родительском разделе поставщиков VSP). Основные
виртуальные устройства служб интеграции реализованы как DLL и включают: такто-
вые импульсы (Vmicheartbeat.dll), синхронизацию времени (Vmictimesync.dll), обмен
парами "ключ/значение" (Vmickvpexchange.dll), выключение (Vmicshutdown.dll), а так-
же интеграцию с VSS (Vmicvss.dll). Весь обмен между дочерним разделом и VSP про-
изводится по шине VMBus.
Виртуальное устройство RDP Encoder

Кодировщик RDP Encoder — это основное виртуальное устройство, отвечающее за
создание и перечисление удаленных подключений RDP, управление потоком данных
между компонентами RDP и виртуальной машиной, а также кодирование видео, мыши
и клавиатуры в единый поток данных RDP. Кодировщик RDP делает это при помощи
предоставления интерфейса установления подключений для клиентов RDP (через мо-
дуль прослушивания Single Port Listener для RDP), обмена с видеопоставщиком VSP
для получения видеоданных, а также обмена с поставщиком VSP входных данных
(данные от клавиатуры и мыши).
Стек виртуализации в действии

Мы обсудили главные компоненты и подкомпоненты архитектуры Hyper-V и объясни-
ли, что делает каждый из них. Теперь мы можем продемонстрировать — как это рабо-
тает все вместе при выполнении задачи вроде включения виртуальной машины (опре-
деленной в интерфейсе оснастки Hyper-V для ММС). На рис. 3.8 показана блок-схема
процесса загрузки виртуальной машины.
Виртуальные устройства
Виртуальные устройства могут быть двух типов: эмулированные и синтетические.
Эмуляция устройств позволяет виртуальной машине видеть виртуализированное физи-
ческое оборудование. Это означает, что обеспечивающий эмуляцию драйвер устройст-
ва во многих случаях работает точно так же, как он делал бы это с физическим устрой-
ством. Поэтому эмулированное устройство обеспечивает практически идеальную со-
вместимость с имеющимся программным обеспечением. Выбор устройства для
эмуляции обычно определяется теми операционными системами, которые вы хотите
поддерживать. Эмулированным устройствам (для перехвата запросов прямого доступа
к оборудованию и перенаправления их в нужное место) родительский раздел должен
предоставить некий "монитор". Синтетические виртуальные устройства не пытаются
эмулировать физическое оборудование, но обеспечивают такие свойства устройств,
которые можно оптимизировать для виртуальной среды.
Рис. 3.8. Блок-схема включения виртуальной машины
Виртуальная память
Наше обсуждение виртуальной памяти начнем с основ. Физический компьютер имеет
физическую и виртуальную память. Физическая память — это определенное количест-
во блоков адресов (в зависимости от количества физической памяти компьютера).
Компьютер поддерживает набор адресов всех блоков (который позволяет программам
найти все блоки). Виртуальная память позволяет компьютеру иметь больше адресов
(большее адресное пространство), чем у него есть физической памяти. Ядро операци-
онной системы поддерживает соответствие между адресным пространством виртуаль-
ной памяти и адресным пространством физической памяти. Обычно это делается бло-
ками, которые называются страницами памяти. Поскольку адресное пространство
физической памяти меньше, чем пространство виртуальной памяти, то страницы вир-
туальной памяти должны ставиться в соответствие физическим страницам памяти и

загружаться (выгружаться) по мере необходимости. Все виртуальные страницы, кото-
рые в данный момент не сопоставлены физическим страницам, должны храниться где-
то в другом месте (обычно на жестком диске). Это называется подкачкой, и большин-
ство операционных систем использует для этого файл подкачки. На рис. 3.9 показано
представление этой концепции.
Рис. 3.9. Соответствие физической и виртуальной памяти
Виртуализация усложняет установление соответствия между адресными пространства-

ми физической и виртуальной памяти, поскольку каждый гость предполагает, что он
работает на физическом компьютере с физическим адресным пространством, а опера-
ционная система гостя предполагает, что имеется виртуальное адресное пространство.
Для решения этой проблемы архитектура гипервизора Windows определяет три незави-
симых адресных пространства памяти:
системные физические адреса (System physical addresses, SPA);
гостевые физические адреса (Guest physical addresses, GPA);
гостевые виртуальные адреса (Guest virtual addresses, GVA).
Системные физические адреса — это адресное пространство физической памяти физи-

ческого компьютера. На компьютере сервера Hyper-V есть только одно пространство
SPA. Гостевые физические адреса — это адресное пространство физической памяти
дочернего раздела. Каждый дочерний раздел имеет один GPA (точно так же, как каж-
дый физический компьютер имеет один SPA). Для дочернего раздела GPA является
эквивалентом SPA. Внутри каждого дочернего раздела есть виртуальное адресное про-
странство, которое называется виртуальным адресным пространством гостя. Оно ис-
Рис. 3.10. Соответствие физической и виртуальной памяти при виртуализации

пользуется как физическая машина для обеспечения такого виртуального адресного

пространства, которое гораздо больше, чем количество физической памяти (а страницы
памяти, которые не имеют соответствия в GPA, сбрасываются на диск).
Родительский раздел рассматривается как особый дочерний раздел (поскольку он вла-
деет физической памятью системы). Несмотря на то, что родительский раздел может
сбрасывать страницы своей виртуальной памяти на диск, дочерние разделы делать это-
го не могут. На рис. 3.10 показаны связи между SPA, GPA и GVA.
Windows Server 2008 Hyper-V использует для загрузки и работы виртуальных машин
только доступную физическую память. Используемое виртуальной машиной количест-
во памяти определяется при ее создании и сохраняется в настройках виртуальной ма-
шины. Гипервизор Windows выполняет выделение памяти из физической памяти при
включении виртуальной машины, причем количество системной памяти виртуальной
машины не может быть изменено во время работы виртуальной машины. Hyper-V не
позволяет виртуальным машинам совместно использовать страницы памяти.
Виртуальные процессоры
До введения аппаратной поддержки виртуализации в линейках процессоров Intel и
AMD архитектура процессора х86 тяжело поддавалась виртуализации, поскольку он
имел плохое разделение привилегированных и пользовательских состояний, а некото-
рые инструкции, которые имели доступ к привилегированному состоянию, были про-
сто неперехватываемыми. Несмотря на то, что эмуляция была возможна, общие на-
кладные расходы на полную эмуляцию были неприемлемыми. В сервере Virtual Server
2005 R2 SP1 для получения наилучшей производительности использовалось сочетание
прямого выполнения и эмуляции, причем прямое выполнение было предпочтительным
методом выполнения.
Сегодня физический компьютер имеет такие физические процессоры, которые могут
содержать один или более логических процессоров (называемых ядрами или гиперпо-
токами). Гипервизор Windows создает один виртуальный процессор в родительском
разделе для каждого логического процессора, который существует в физическом обо-
рудовании в момент загрузки. В отличие от виртуальных процессоров в дочерних раз-
делах, виртуальные процессоры в родительском разделе имеют жесткие привязки
к конкретным ядрам физического процессора. Родительский и дочерние разделы всегда
имеют один или более виртуальных процессоров.
Виртуальный процессор может находиться в одном из четырех состояний:
RUNNING — использует процессорные циклы логического процессора;
READY — готов использовать процессорные циклы, но работают другие виртуаль-
ные процессоры;
WAITING — переведен в состояние ожидания планировщиком гипервизора (по
разным причинам);
SUSPENDED — остановлен на границе гостевой инструкции.
Виртуальные процессоры дочерних разделов, которые в данный момент выполняют
потоки, находятся в состоянии RUNNING. Виртуальные процессоры дочерних разде-
лов, имеющие в данный момент работающие процессы, которым нужны процессорные

циклы (и в которых дочерний раздел не превысил свой предел количества циклов вир-
туального процессора), находятся в состоянии READY. Виртуальные процессоры до-
черних разделов, которые не имеют работающих процессов или имеют работающие
процессы, но превысили предел количества циклов виртуального процессора, либо пе-
реведены в состояние ожидания планировщиком гипервизора Windows, находятся в
состоянии WAITING. Виртуальные процессоры дочернего раздела, которые работали,
но были остановлены гипервизором для обработки такой инструкции, которой требу-
ется поддержка других компонентов стека виртуализации, находятся в состоянии
SUSPENDED. Виртуальные процессоры дочернего раздела могут быть как явно, так и
неявно приостановлены.
Виртуальная сеть
Виртуальные сети в Hyper-V предоставляют возможность (для родительского и дочер-
них разделов) создавать виртуальные сети, которые могут быть как изолированными от
физической системы, так и использовать инсталлированные физические сетевые адап-
теры для подключения к внешней/физической сети. Для этого требуются компоненты
как в родительском, так и в дочерних разделах. На рис. 3.11 показаны эти компоненты
и их взаимодействие.
Рис. 3.11. Стек виртуальных сетей

Сетевой компонент VSP состоит из двух частей: виртуальный коммутатор и менеджер

политик. Виртуальный коммутатор — это многопортовый сетевой коммутатор уровня
Layer 2 (реализованный программно). Менеджер политик управляет тем, кто может
создавать и удалять виртуальные коммутаторы и порты, а также тем, кто и к какому
порту виртуального коммутатора может получить доступ.
Каждый дочерний раздел реализует два возможных интерфейса для виртуального ком-
мутатора. Первый — это сетевой VSC, который реализует синтетические драйверы се-
тевых адаптеров и ведет обмен с родительским разделом через VMBus. Второй — это
эмулированная карта сетевого адаптера, которая не ведет обмена через VMBus.
В Hyper-V существуют три типа виртуальных сетей:
External — виртуальный коммутатор привязан к физическому сетевому адаптеру,
подключен к родительскому сетевому стеку, а также может быть подключен к до-
чернему разделу;
Internal — виртуальный коммутатор подключен к сетевому стеку родительского
раздела в режиме замыкания на себя, а также может быть подключен к дочернему
разделу;
Private — виртуальный коммутатор не имеет подключения к сетевому стеку роди-
тельского раздела, но может быть подключен к дочернему разделу.
Виртуальный коммутатор
Виртуальный коммутатор реализован как коммутатор уровня Layer 2 на основе стан-
дарта 802.1D (с использованием промежуточного драйвера MUX). Виртуальный ком-
мутатор обеспечивает маршрутизацию по МАС-адресам или по идентификаторам те-
гов VLAN (как это определено стандартом 802.1Q). Каждый коммутатор может иметь
неограниченное количество портов, причем порты могут добавляться в коммутатор
(и удаляться из него) динамически. Виртуальный коммутатор также обеспечивает под-
держку обработки контрольных сумм TCP/IP и разгрузки больших сегментов.
Виртуальному коммутатору требуется способность модифицировать МАС-адреса, что-
бы он мог транспортировать пакеты с такими адресами, которые отличаются от его
МАС-адреса. Это позволяет виртуальному коммутатору привязываться к любому фи-
зическому сетевому адаптеру стандарта Ethernet 802.3. Виртуальный коммутатор не
может привязываться к беспроводным адаптерам 802.11, т. к. стандарт 802.11 не под-
держивает отправку пакетов с исходными МАС-адресами, отличающимися от его соб-
ственного МАС-адреса.
Виртуальный сетевой адаптер

Дочернему разделу для обмена с внешним миром требуется сетевой адаптер. Для до-
чернего раздела существуют два типа адаптеров: синтетический и эмулированный (на-
зываемый также обычным). Синтетический сетевой адаптер — это то, что реализовано
как VSC и инсталлируется при инсталляции служб интеграции в гостевой операцион-
ной системе. Эмулированный адаптер может инсталлироваться как со службами инте-
грации в гостевой операционной системе, так и без них.
Разница между эмулированными и синтетическими адаптерами состоит в том, что син-

тетический адаптер не существует до загрузки гостевой операционной системы и соот-
ветствующих служб типа VMBus. Это означает, что синтетический сетевой адаптер не
поддерживает загрузку PXE. Эмулированный же сетевой адаптер не зависит от VMBus.
Службы интеграции дочернего раздела

Службы интеграции — это программные компоненты, которые могут инсталлировать-
ся в гостевых операционных системах, работающих в дочерних разделах. Службы ин-
теграции предоставляют компоненты, которые позволяют дочерним разделам обмени-
ваться с другими разделами (при помощи поставщиков Virtualization Services Providers
через шину VMBus).
Службы интеграции упакованы в монтируемый ISO-файл в родительском разделе сер-
вера Windows Server 2008 с серверной ролью Hyper-V:
%SystemRoot%\System32\VMGuest.iso
Когда службы интеграции инсталлируются в поддерживаемых гостевых операционных

системах, то инсталлируются и конфигурируются указанные в табл. 3.2 системные
компоненты. Эти компоненты можно просмотреть в Device Manager (надо смотреть в
соответствующем узле устройства и искать название устройства). В табл. 3.2 перечис-
лены те драйверы, которые должны быть установлены под каждым устройством.
Таблица 3.2. Компоненты служб интеграции
Устройство Название устройства Службы интеграции
Видеоадаптер Microsoft VMBus Video C:\Windows\system32\drivers\VMBusVideoM.sys

Device C:\Windows\system32\VMBusVideoD.dll
Устройства чело- Microsoft VMBus HID C:\Windows\system32\drivers\hidclass.sys
веко-машинного Miniport C:\Windows\system32\drivers\hidparse.sys
интерфейса C:\Windows\system32\drivers\hidusb.sys
C:\Windows\system32\drivers\VMBusHID.sys
Сетевые Microsoft VMBus Network Для Windows Server 2008 и Windows Vista SP1:
адаптеры Adapter C:\Windows\system32\drivers\netvsc60.sys
Для Windows Server 2003 SP2 и Windows XP SP2 или
SP3: C:\Windows\system32\drivers\netvsc50.sys
Контроллеры Storage miniport driver C:\Windows\system32\drivers\storvsc.sys
хранения
Системные Disk VMBUS Acceleration C:\Windows\system32\drivers\storflt.sys
устройства Filter Driver C:\Windows\system32\VmdCoinstall.dll
Microsoft Emulated S3 C:\Windows\system32\s3cap.sys
Device Cap
VMBus C:\Windows\system32\drivers\vmbus.sys
C:\Windows\system32\drivers\winhv.sys
C:\Windows\system32\vmbuspipe.dll
Компоненты табл. 3.3 также инсталлируются вместе со службами интеграции (как сис-
темные службы, они реализованы в Vmicsvc.exe). После инсталляции служб интегра-
ции Integration Services эти службы регистрируются и конфигурируются для автомати-

ческого запуска. В табл. 3.3 перечислены требующиеся для каждой службы файлы.
Таблица 3.3. Системные службы служб интеграции
Название службы Службы интеграции
Hyper-V Data Exchange Service C:\Windows\system32\lcCoinstall.dll

C:\Windows\system32\vmicsvc.exe
Hyper-V Guest Shutdown Service C:\Windows\system32\lcCoinstall.dll
C:\Windows\system32wmicsvc.exe
Hyper-V Heartbeat Service C:\Windows\system32\lcCoinstall.dll
Hyper-V Time Synchronization Service C:\Windows\system32\lcCoinstall.dll
C:\Windows\system32\vmictimeprovider.dll
Hyper-V Volume Shadow Copy Service C:\Windows\system32\lcCoinstall.dll
Конфигурация этих служб определяется перечисленными в табл. 3.4 ключами реестра.
Таблица 3.4. Местоположение в реестре конфигурации системных служб
Название службы Ключ реестра

Hyper-V Data Exchange Service HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\Vmickvpexchange
Hyper-V Guest Shutdown Service HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\Vmicshutdown
Hyper-V Heartbeat Service HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\Vmicheartbeat
Hyper-V Time Synchronization Service HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\Vmictimesync
Hyper-V Volume Shadow Copy Service HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\Vmicvss
Виртуальные жесткие диски

Для загрузки и работы виртуальным машинам требуется то же основное оборудование,
что и физическим машинам: материнская плата, BIOS, память, сетевой адаптер, кла-
виатура, мышь, дисплей и жесткий диск. Архитектура Hyper-V обеспечивает макси-
мально возможную переносимость виртуальных машин. Одной из проблем переноси-
мости было обеспечение доступности и переносимости жесткого диска виртуальной
машины (при одновременном сохранении достаточной его производительности). Ком-
пания Microsoft справилась с этой проблемой при помощи концепции виртуального
жесткого диска (VHD). VHD — это представление физического жесткого диска в виде
одного файла, который хранится на жестком диске физической машины. Поскольку это
самодостаточный файл, то его несложно перенести с одной системы на другую.
Существует пять типов виртуальных жестких дисков:

фиксированный жесткий диск;
динамически расширяющийся жесткий диск;
разностный жесткий диск;
жесткий диск для откатов (в Hyper-V не используется);
автоматический виртуальный жесткий диск.
Фиксированный виртуальный жесткий диск — это такой диск, размер которого на фи-
зическом диске сервера равен указанному при создании данного диска размеру. На-
пример, при создании 100-гигабайтного фиксированного виртуального жесткого диска
Hyper-V сразу же выделяет все 100 Гбайт пространства, а также дополнительные об-
ласти для заголовков диска.
Динамически расширяющийся виртуальный жесткий диск — это такой диск, началь-
ный размер которого не содержит блоков данных. Размер будет расти по мере выделе-
ния блоков данных (до максимального размера, указанного для данного виртуального
жесткого диска).
Разностный виртуальный жесткий диск — это особая версия динамически расширяю-
щегося виртуального жесткого диска. Они отличаются в основном содержимым заго-
ловка диска.
Автоматические виртуальные жесткие диски (avhd) — это разностные диски, которые
автоматически создаются при выполнении моментального снимка виртуальной ма-
шины.
VHD могут храниться либо на локально подключенных физических жестких дисках,
либо на любом томе родительского раздела. Любой диск, который хранит VHD, дол-
жен быть отформатирован в NTFS (для управления безопасностью доступа).
Транзитные диски
Транзитные диски — это новая возможность сервера Windows Server 2008 Hyper-V.
Транзитные диски — это такие виртуальные диски, которые не хранятся в виде одного
файла. Вместо создания файла VHD транзитные диски используют автономные тома,
подключенные к родительскому разделу. Транзитные диски могут использоваться в
дочерних разделах как системные тома или тома данных. При использовании в качест-
ве системного тома транзитные диски позволяют дочернему разделу грузиться непо-
средственно с транзитного диска. Концепция транзитного диска для самой виртуаль-
ной машины полностью прозрачна.
Используемый для транзитного диска том может быть локально подключенным дис-
ком, подключенным к родительскому разделу Logical Unit Number (LUN) интерфейса
iSCSI, либо подключенным к родительскому разделу LUN в сети Storage Area Network
(SAN). В родительском разделе используемый том должен быть в автономном режиме
и не использоваться родительским разделом.
Дополнительную информацию о транзитных дисках см. в главе 5.
Какую структуру имеет виртуальный жесткий диск?

Все виртуальные диски имеют одинаковую основную структуру (рис. 3.12). Каждый
файл виртуального диска содержит нижнюю шапку жесткого диска, таблицу выделе-
ния блоков (Blocks Allocation Table, BAT), сами блоки данных, а также необязательную
верхнюю шапку диска (которая отличается для каждого типа виртуального жесткого
диска). Блок данных имеет размер в 2 Мбайт и содержит 4096 секторов размером по
512 байтов. Копия нижней шапки жесткого диска содержится в начале файла (в целях
дублирования).
Рис. 3.12. Структура виртуального жесткого диска
Полную спецификацию формата жестких дисков Virtual Hard Disk Image format Specification
можно скачать с Web-сайта компании Microsoft по ссылке:
http://www.microsoft.com/downloads/details.aspx?FamilyID=c2d03242-2ffb-48ef-a211-
f0c44741109e&DisplayLang=en.
Описание нижней шапки жесткого диска

Нижняя шапка жесткого диска содержит информацию, которая определяет размер, тип,
геометрию и функциональные возможности виртуального жесткого диска. В табл. 3.5
приведена спецификация для информации полей и их размер для нижней шапки (раз-
мером 512 байтов) жесткого диска. Формат нижней шапки диска одинаков для всех
типов виртуальных жестких дисков.
Таблица 3.5. Спецификация нижней шапки жесткого диска
Название Размер
Описание
поля (байт)
Cookie 8 Используется для идентификации первоначального создателя вирту-
ального жесткого диска; по умолчанию устанавливается в значение
"connectix"
Features 4 Используется для индикации поддержки (виртуальным жестким дис-
ком) специфических функций
Название Размер
Описание
поля (байт)
File Format 4 Версия спецификации файла (для файла виртуального жесткого диска)
Version
Data Offset 8 Содержит абсолютное смещение в байтах (от начала файла до сле-
дующей структуры дискового заголовка). Это поле используется для
динамических и разностных дисков, но не для фиксированных дисков.
Для фиксированных дисков это поле устанавливается в значение
0xFFFFFFFF
Time Stamp 4 Хранит первоначальное время создания файла виртуального жесткого
диска. Время хранится как количество секунд после 12 часов
(по времени UTC/GMT) 1 января 2000 года
Creator 4 Используется для документирования, какое именно приложение созда-
Application ло файл виртуального жесткого диска. Настраивается в "vs", если
файл был создан виртуальным сервером, либо в "vpc", если файл был
создан при помощи Virtual PC
Creator Version 4 Основная/второстепенная версия приложения, которое создало файл
виртуального жесткого диска
Creator Host OS 4 Содержит значение, которое обозначает операционную систему хоста,
создавшего файл виртуального жесткого диска. Для Windows оно уста-
навливается в "Wi2k" (шестнадцатеричное 0x5769326B)
Original Sixe 8 Указанный при создании виртуального жесткого диска размер в байтах
Current Size 8 Текущий размер виртуального жесткого диска в байтах
Disk Geometry 4 Значение, которое содержит цилиндры, головки и количество секторов
на дорожку для данного жесткого диска. Хранится так: 2 байта для ко-
личества цилиндров, 1 байт для количества головок, и 1 байт для ко-
личества секторов на дорожку
Disk Type 4 Определяет тип диска, который содержится в данном файле виртуаль-
ного жесткого диска (фиксированный, динамический или разностный)
Checksum 4 Контрольная сумма нижней шапки жесткого диска (с использованием
алгоритма дополнения до единицы)
Unique Id 16 128-битный универсальный уникальный идентификатор (UUID),
используемый верхней шапкой разностного виртуального жесткого диска
Saved State 1 Флаг, который указывает — находится ли виртуальная машина
в сохраненном состоянии
Reserved 427 Зарезервированные поля — в настоящее время не используются
и содержат нули
Вы можете использовать шестнадцатеричный редактор файлов, открыть файл VHD и про-
смотреть эти поля нижней шапки диска (для проверки данного описания).
Определение верхней шапки динамического диска

Поле Data Offset нижней шапки жесткого диска указывает на дополнительную верх-
нюю шапку диска, в которой указана информация для определения динамического или
разностного диска. Верхняя шапка предоставляет подробности по компоновке динами-
ческого диска и по данным, на которые он ссылается. Для разностного диска заголовок

дает местоположение родительского виртуального диска (в форме элемента-локатора).
В табл. 3.6 дано описание верхней шапки динамического диска.
Таблица 3.6. Описание верхней шапки динамического диска
Поля верхней шапки Размер

Описание
динамического диска (байт)
Cookie 8 Идентифицирует верхнюю шапку, по умолчанию содержит зна-

чение "cxspare"
Data Offset 8 Содержит абсолютное смещение в байтах до следующей струк-
туры в образе жесткого диска. В настоящее время не использу-
ется существующими форматами и должно быть установлено
в значение 0xFFFFFFFF
Table Offset 8 Хранит абсолютное смещение в байтах таблицы ВАТ в файле
Header Version 4 Хранит версию верхней шапки динамического диска. В настоя-
щее время это поле должно быть инициализировано значением
0x00010000
Max Table Entries 4 Максимальное количество элементов, имеющихся в ВАТ. Долж-
но равняться количеству блоков диска (размеру диска, поделен-
ному на размер блока)
Block Size 4 Блок — это единица расширения для динамических и разност-
ных дисков (в байтах), представляет собой размер блока облас-
ти данных. Количество секторов на блок всегда должно быть
степенью двойки. Значение по умолчанию — 0x00200000
(2 Мбайт)
Checksum 4 Хранит простую контрольную сумму верхней шапки динамиче-
ского диска. Значение контрольной суммы — дополнение
до единицы суммы всех байтов верхней шапки (за исключением
поля контрольной суммы)
Parent Unique ID 16 Используется для разностных жестких дисков. Разностный жест-
кий диск хранит 128-битный UUID родительского жесткого диска
Parent Time Stamp 4 Это поле хранит отметку времени модификации родительского
жесткого диска. Это количество секунд с момента 12:00:00 АМ
1 января 2000 года (по времени UTC/GMT)
Reserved 4 Не используется, должно быть заполнено нулями
Parent Unicode Name 512 Содержит строку в кодировке Unicode (UTF-16) — имя файла
родительского жесткого диска
Parent Locator Entry 1 24 Каждый элемент Parent Locator Entry хранит абсолютное сме-
Parent Locator Entry 2 24 щение в байтах для того места, где содержится локатор родите-
ля для разностного жесткого диска. Это поле используется толь-
Parent Locator Entry 3 24 ко для разностных дисков и должно быть заполнено нулями для
Parent Locator Entry 4 24 динамических дисков
Parent Locator Entry 5 24

Reserved 256 В настоящее время не используется и должно быть заполнено
нулями
Таблица выделения блоков

Таблица выделения блоков (Blocks Allocation Table, ВАТ) — это таблица абсолютных
смещений секторов для блоков данных виртуального жесткого диска. Размер ВАТ
определяется при создании виртуального жесткого диска. Каждый блок имеет размер
2 Мбайт, а каждый элемент ВАТ — 4 байта. Каждый блок данных состоит из битовой
карты секторов и данных. Использование битовой карты секторов зависит от типа
VHD (это динамический или разностный диск).
Для динамического диска битовая карта показывает наличие данных. Если сектор со-
держит данные, то соответствующее место на битовой карте содержит значение 1.
Если сектор данных не содержит, то на битовой карте будет стоять 0. Для разностного
диска битовая карта указывает, какие секторы содержат данные разностного диска (1),
а какие — данные родительского диска (0).
Виртуальный гибкий диск

Виртуальный гибкий диск — это представление физического гибкого диска в виде од-
ного файла. Hyper-V пишет (и читает) на (с) диски (дисков) размером 1,44 Мбайт и
720 Кбайт, но создает образы виртуальных гибких дисков только размером 1,44 Мбайт.
Физический гибкий диск имеет две стороны по 80 дорожек с 18 секторами на дорожку
и 512 байтами на сектор (всего 1 474 560 байтов на диск). Формат виртуального гибко-
го диска точно такой же, но он представляет две стороны физического гибкого диска
в виде одного плоского файла.
Каждая виртуальная машина имеет один виртуальный дисковод гибких дисков. В лю-
бой момент к этому виртуальному дисководу можно подключить виртуальный образ
гибкого диска. В отличие от сервера Virtual Server 2005 R2, сервер Hyper-V не позволя-
ет вам смонтировать физический гибкий диск в виртуальный дисковод гибких дисков;
поддерживаются только виртуальные образы гибких дисков.
Hyper-V не предоставляет возможности получить доступ к содержимому файла виртуально-
го образа гибкого диска (vfd), если он не подключен к работающей виртуальной машине.
Есть приложения сторонних организаций, которые могут смонтировать vfd-файл и позво-
ляют получить к нему доступ на чтение и запись (без подключения файла виртуального об-
раза гибкого диска к виртуальной машине).
Резюме
Сервер Windows Server 2008 Hyper-V предоставляет гипервизор (в виде микроядра),
который работает непосредственно на оборудовании. Сервер Hyper-V состоит из мно-
жества компонентов, которые включают: гипервизор Windows, компоненты пользова-
тельского режима, а также компоненты режима ядра. Эти компоненты работают со-
вместно для того, чтобы сделать возможным создание дочерних разделов (виртуаль-
ных машин) и управление ими. Компоненты пользовательского режима (такие, как
рабочие процессы, службы управления виртуальными машинами, интерфейсы WMI)
позволяют оснастке Hyper-V для ММС (и другим приложениям, использующим ин-
терфейсы прикладного программирования WMI) удаленно управлять настройками сер-

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

спецификация Virtual Hard Disk Image Format Specification, доступная по адресу:
http://www.microsoft.com/windowsserversystem/virtualserver/techinfo/vhdspec.mspx;
спецификация Hypervisor Functional Specification, доступная по адресу:
http://www.microsoft.com/downloads/details.aspx?FamilyID=
91E2E518-C62C-4FF2-8E50-3A37EA4100F5&displaylang=en;
документ Virtualization WMI Provider and class definition из MSDN, доступный по
адресу: http://msdn2.microsoft.com/en-us/library/cc136992(VS.85).aspx;
документ Publishing Service Connection Points (SCP), доступный по адресу:
http://msdn2.microsoft.com/en-us/library/ms677638(VS.85).aspx.
часть II
Разбираемся с сервером
Глава 4. Инсталляция и конфигурирование Hyper-V
Глава 5. Расширенные функции Hyper-V
Глава 6. Безопасность Hyper-V
Глава 7. Лучшие практики и оптимизация сервера Hyper-V
Глава 8. Переход с Virtual Server 2005 R2 на Hyper-V
Глава 9. Знакомимся с сервером Windows Server 2008 R2 Hyper-V

ГЛАВА 4
Инсталляция и конфигурирование
Hyper-V
В предыдущих главах мы рассмотрели гипервизор, архитектуру Hyper-V, а также дали
обзор продукта Hyper-V. Теперь пришло время инсталлировать его и посмотреть — что
он может делать. Эта глава объяснит предварительные требования и опции инсталля-
ции для роли Hyper-V в сервере Windows Server 2008, а также для инсталляции
Microsoft Hyper-V Server 2008. Эта глава дает пошаговое описание обеих процедур
инсталляции; мы также обсудим дополнительные шаги конфигурирования после ин-
сталляции (которые необходимо выполнить для подготовки сервера Hyper-V к вашей
среде).
Обзор процедуры инсталляции

Windows Server 2008 можно инсталлировать либо с полным графическим интерфейсом
(инсталляция по умолчанию), либо с интерфейсом командной строки (вариант инстал-
ляции Server Core). Роль Hyper-V можно инсталлировать при обоих упомянутых вари-
антах инсталляции Windows Server 2008.
Hyper-V имеется только в 64-битных версиях Windows Server 2008 Standard, Windows
Server 2008 Enterprise и Windows Server 2008 Datacenter. Сервер Microsoft Hyper-V
Server 2008 есть только в 64-битном варианте. Роль Hyper-V не инсталлируется на
32-битных версиях Windows Server 2008 или на сервере Windows Server 2008 для сис-
тем на базе процессоров Itanium. Оснастку Hyper-V Manager для ММС можно инстал-
лировать на всех 32- и 64-битных версиях Windows Server 2008 (за исключением сис-
тем Itanium). Кроме того, оснастку Hyper-V Manager можно инсталлировать и на
Windows Vista SP1 (и более поздних версиях).
Перед инсталляцией роли Hyper-V вы должны решить, какой вариант инсталляции ис-
пользовать для Windows Server 2008 — полный или Server Core. Полный вариант по-
зволяет управлять сервером Hyper-V непосредственно на самом сервере при помощи
графического интерфейса пользователя (GUI). Вариант Server Core обеспечивает
меньшие накладные расходы и более высокую производительность, но все управление
сервером Hyper-V придется выполнять по сети.
120 Часть II. Разбираемся с сервером Windows Server 2008 Hyper-V
Предварительные требования для инсталляции

Перед инсталляцией Hyper-V вы должны выполнить некоторые предварительные усло-
вия, которые упростят сам процесс. Для того чтобы гипервизор смог запуститься, сер-
веру Windows Server 2008 с ролью Hyper-V и серверу Microsoft Hyper-V Server 2008
требуется наличие соответствующего оборудования и правильных настроек BIOS.
Hyper-V требует наличия серверного оборудования, которое поддерживает 64-битные
инструкции процессора и имеет аппаратную поддержку технологий виртуализации в
процессоре сервера. Все это есть в процессорах с технологией Intel Virtualization
Technology (Intel VT) и AMD Virtualization (AMD-V). Кроме того, Hyper-V требует на-
личия аппаратной функции Data Execution Prevention (DEP) — она должна быть вклю-
чена в BIOS. Точнее говоря, вы должны включить бит Intel XD или бит AMD NX.
После настройки в BIOS сервера этих опций его необходимо выключить (для того, чтобы
эти изменения вступили в силу).
Интеграция Hyper-V в Windows Server 2008

Сервер Windows Server 2008 был выпущен до выхода в свет Hyper-V. Несмотря на то,
что Hyper-V включен в состав Windows Server 2008, это бета-версия роли Hyper-V. Для
того чтобы получить финальную версию Hyper-V, вы должны скачать и инсталлиро-
вать обновление. Статья Microsoft Knowledge Base (KB) с номером 950050 предостав-
ляет информацию и пакет скачивания для обновления инсталляции Windows Server
2008 до финальной версии Hyper-V.
Несмотря на то, что вы можете либо использовать службу Windows Update, либо ска-
чать и вручную инсталлировать обновление KB950050, выполнение этой процедуры
для каждого хоста Hyper-V приведет к дополнительным перезагрузкам и потерям вре-
мени. Лучше встроить обновление KB950050 в образ ISO дистрибутива Windows Server
2008 (чтобы оно инсталлировалось по умолчанию). После встраивания обновления
Hyper-V код финальной версии будет инсталлироваться автоматически (каждый раз
при создании нового хоста Hyper-V). Есть и еще одно преимущество — при каждом
создании (с помощью образа ISO) виртуальной машины Windows Server 2008 будут
инсталлироваться также и обновленные службы Integration Services.
Для быстрой инсталляции операционной системы Windows Server 2008 использует
формат Windows Imaging (WIM). Диск DVD операционной системы Windows Server
2008 имеет два образа WIM: Boot.wim и Install.wim. Загрузочные драйверы и инстру-
менты хранятся в образе Boot.wim и используются во время загрузки для запуска про-
цесса инсталляции. Install.wim содержит шесть инсталляционных образов для версий
Standard, Enterprise и Datacenter (для каждой версии по два образа — полная инсталля-
ция и инсталляция Server Core). Windows Server 2008 предоставляет новую модель об-
служивания, которая позволяет вам интегрировать обновления и драйверы непосредст-
венно в Install.wim (чтобы они могли инсталлироваться как часть основной процедуры
инсталляции).
Компания Microsoft предлагает инструментальный набор Windows Automated
Installation Kit (WAIK), который позволяет вам монтировать образы WIM и управлять
Глава 4. Инсталляция и конфигурирование Hyper-V 121
ими. Этот набор предоставляет некоторые ключевые инструменты для обслуживания

образов WIM. ImageX.exe позволяет вам монтировать файл образа WIM для доступа и
модификации (и в том числе копирования и удаления файлов). Pkgmgr.exe позволяет
вам интегрировать обновления в образ WIM и делает все необходимые изменения для
того, чтобы образ знал о том, что эти новые файлы имеются. Oscdimg.exe позволяет
вам создать обновленный загрузочный ISO, который можно записать на DVD-диск.
Вот шаги, необходимые для создания нового образа ISO диска Windows Server 2008,
который можно будет затем использовать для инсталляции хоста Hyper-V или вирту-
альной машины сервера Windows Server 2008:
1. Инсталлировать на вашем компьютере WAIK.
2. Скопировать диск DVD с Windows Server 2008 х64 в подкаталог.
3. Сделать копию файла Install.wim для модификации.
4. Смонтировать копию Install.wim при помощи ImageX.
5. Интегрировать обновление для Hyper-V при помощи Pkgmgr.
6. Заменить исходный файл Install.wim.
7. Создать новый образ ISO при помощи Oscdimage.
Выпуск Windows Server 2008 SP2 содержит финальную версию Hyper-V
Сервер Windows Server 2008 SP2 содержит последнюю версию Hyper-V (интегрированную в
сервисный пакет обновлений). Если вы используете версию со встроенным Service Pack 2,
то вам не придется создавать носитель с обновлением или импортировать обновление
KB950050 внутрь Microsoft Deployment Toolkit 2008 Deployment Workbench.
Поль Деспе (Paul Despe, Program Manager (Windows Virtualization))
Необходимое программное обеспечение и инструменты

Для того чтобы выполнить встраивание обновления, вам необходимо иметь следующее
программное обеспечение и оборудование:
инструментальный набор Windows Automated Installation Kit (WAIK);
физический диск DVD с Windows Server 2008 х64 (или его ISO-образ);
файл обновления KB950050 для Hyper-V;
пишущий DVD-привод (если вы хотите создать новый физический диск DVD).
Инсталляция WAIK
Набор WAIK для Windows Server 2008 можно скачать с сайта компании Microsoft. Ска-
чанный файл — это ISO-образ, который нужно записать на диск (либо вам понадобится
использовать какой-то инструмент, который позволит вам смонтировать этот ISO для
инсталляции). Инсталлируйте WAIK — вставьте этот диск в ваш компьютер и выбери-
те вариант Windows AIK Setup на странице приветствия. Инсталляция — это короткий
процесс из трех шагов: нужно принять соглашение EULA, принять каталог инсталля-
ции по умолчанию, а затем нажать кнопку Install. После инсталляции вы можете выйти
из диалогового окна (выбрав опцию Exit на странице приветствия WAIK).
Подготовка к встраиванию обновления

Встраивание обновления Hyper-V требует создания копии оригинальных инсталляци-
онных файлов Windows Server 2008 (с диска DVD на жесткий диск) и создания рабочей
копии Install.wim (которая будет использована для встраивания обновления Hyper-V).
Для подготовки к встраиванию обновления сделайте следующее:
1. Вставьте диск DVD с Windows Server 2008 х64 в дисковод DVD.
2. Создайте на вашем компьютере каталог C:\NewWin2008ISO.
3. Скопируйте все содержимое диска DVD в каталог C:\NewWin2008ISO.
4. Создайте на вашем компьютере каталог C:\WIM.
5. Скопируйте C:\NewWin2008ISO\Sources\INSTALL.WIM в C:\WIM.
Формат WIM позволяет существовать в одном файле нескольким инсталляционным
образам. Каждый образ имеет индексный номер. В табл. 4.1 перечислены образы и ин-
дексные номера, которые содержатся в файле Install.wim сервера Windows Server 2008.
Таблица 4.1. Инсталляционные образы и индексы
Индексный номер Название
1 Windows Longhorn SERVERSTANDARD

2 Windows Longhorn SERVERENTERPRISE
3 Windows Longhorn SERVERDATACENTER
4 Windows Longhorn SERVERSTANDARDCORE
5 Windows Longhorn SERVERENTERPRISECORE
6 Windows Longhorn SERVERDATACENTERCORE
Поскольку в Install.wim каждый образ независим, то обновление необходимо будет

встроить в каждый образ. Для этого нужно смонтировать Install.wim при помощи
ImageX.exe (с указанием индекса образа), инсталлировать обновление в этот образ, а
потом зафиксировать эти изменения в Install.wim во время процедуры размонтирова-
ния. Затем необходимо повторить этот процесс для всех индексов.
После инсталляции WAIK он предоставляет ссылку на свою командную строку, в ко-
торой можно пользоваться инструментами WAIK. Для того чтобы ImageX работал пра-
вильно, права этой командной строки необходимо повысить при помощи опции Run
As Administrator.
Для монтирования wim-файла необходимо использовать следующий синтаксис
ImageX:
Imagex /mountrw <path to WIM> <WIM image Index> <mount folder>
Для подготовки к встраиванию обновления Hyper-V в первый образ внутри Install.wim

выполните следующие шаги:
1. Откройте командную строку Windows PE Tools Command Prompt (с повышенны-
ми правами) из меню программы Microsoft Windows AIK. Вы должны щелкнуть
правой кнопкой мыши по пункту Windows PE Tools Command Prompt и выбрать

команду Run As Administrator.
2. Создать каталог C:\MNT (набрать md c:\mnt, а затем нажать клавишу <Enter>).
3. Выполнить следующую команду для монтирования первого образа из Install.wim
(это будет образ Windows Server 2008 Server x64 Standard Edition):
imagex /mountrw C:\WIM\INSTALL.WIM 1 C:\MNT
Теперь первый образ внутри Install.wim готов для встраивания обновления Hyper-V.
Извлечение обновления Hyper-V

Для того чтобы интегрировать обновление в Install.wim, вам нужен cab-файл из ин-
сталляционного пакета KB950050 службы Windows Update. Для этого необходимо ска-
чать пакет обновления и при помощи инструмента командной строки Expand.exe из-
влечь все файлы.
Для извлечения файлов сделайте следующее:
1. Скачайте обновление Hyper-V для х64 (KB950050).
2. Создайте каталог C:\Extract.
3. Разверните обновление Hyper-V при помощи ввода следующей командной строки:
expand <download folder>\Windows6.0-KB950050-x64.msu -F:* C:\EXTRACT
Нужный для встраивания файл — Windows6.0-KB950050-x64.cab, он находится в ката-

логе С:\Extract.
Встраивание обновления Hyper-V

Теперь вы готовы использовать Pkgmgr.exe для встраивания обновления Hyper-V
в первый образ Install.wim. Pkgmgr.exe — это инструмент командной строки, который
имеет целый набор параметров командной строки (для управления опциями инсталля-
ции пакета). Pkgmgr.exe имеет следующий синтаксис:
Pkgmgr <options> /m:<path to package> /o:<path to mounted wim>;<path to Windows
directory in wim> /s:<temp directory>
Для встраивания пакета нужна только одна опция: /ip — инсталлировать один пакет.
Для нашей процедуры пути будут такими:
/m:C:\EXTRACT\Windows6.0-KB950050-x64.cab
/o:C:\MNT;C:\MNT\WINDOWS
/s:%temp%
Для интеграции извлеченного cab-файла обновления Hyper-V выполните следующие

шаги:
1. При помощи Pkgmgr.exe интегрируйте обновление KB950050 в смонтированный
образ посредством ввода следующей командной строки:
start /w pkgmgr /ip /m:C:\EXTRACT\Windows6.0-KB950050-x64.cab
/o:C:\MNT;C:\MNT\WINDOWS /s:%temp%
2. Для того чтобы убедиться в успешности этой операции, введите в командной строке:
Echo %errorlevel%
Если вам будет возвращен уровень ошибки 0, то это означает, что при интеграции
обновления ошибок не было.
3. Для сохранения модифицированного образа в Install.wim размонтируйте Install.wim
и зафиксируйте изменения при помощи ввода следующей командной строки:
imagex /unmount /commit C:\MNT
К сожалению, этот процесс обновил только один из шести образов файла Install.wim.
Для обновления всех образов необходимо выполнить (для всех индексов) следующий
процесс:
1. Смонтировать Install.wim с указанием нового значения индекса образа.
2. Встроить обновление Hyper-V при помощи инструмента Pkgmgr.
3. Размонтировать образ и зафиксировать изменения.
Создание нового ISO-образа

После обновления всех образов внутри файла Install.wim пришло время создать новый
файл ISO, который можно будет записать на DVD (для инсталляции физического сер-
вера) или смонтировать в виртуальной машине для инсталляции. WAIK предоставляет
инструмент командной строки Oscdimg.exe для создания загрузочных ISO-образов.
Oscdimg.exe имеет следующий синтаксис командной строки:
oscdimg [options] source location targetfile
Список этих опций длинный, но основными (для создания загрузочного ISO-образа)

являются следующие:
-b location — указывает местоположение файла загрузочного сектора. Не исполь-
зуйте никаких пробелов, как это показано здесь:
-bC:\TEMP\Etfsboot.com
-m — игнорировать предел максимального размера образа;

-n — разрешить использование длинных имен файлов.
После всего, что мы сделали ранее, все (необходимые для создания нового ISO) файлы
находятся в каталоге C:\NewWin2K8ISO.
Для создания обновленного ISO выполните такую процедуру:
1. Скопируйте обновленный файл C:\WIM\Install.wim в каталог C:\NewWin2008ISO
\Sources\, перезаписав существующую там копию.
2. Откройте командную строку Windows PE Tools Command Prompt из меню про-
граммы Microsoft Windows AIK. Для этого вы должны щелкнуть правой кнопкой
мыши по пункту Windows PE Tools Command Prompt и выбрать команду Run As
Administrator.
3. Используйте Oscdimg.exe из WAIK для создания нового ISO. Введите следующую
командную строку и нажмите клавишу <Enter>:
Oscdimg –n –m –bC:\NewWin2K8ISO\BOOT\ETFSboot.com C:\NewWin2K-8ISO

C:\Win2008Hyper-V-RTM.ISO
4. Запишите ISO на DVD или поместите его туда, откуда вы сможете его монтировать
при создании виртуальных машин.
Опции инсталляции: роль Hyper-V

Инсталляцию роли Hyper-V на сервере Windows Server 2008 можно выполнить многи-
ми способами. Эти способы зависят от инсталлированной вами версии Windows Server
2008. В табл. 4.2 приведены различные способы инсталляции, имеющиеся в полной
инсталляции и в инсталляции Server Core.
Таблица 4.2. Способы инсталляции роли Hyper-V
Способ инсталляции Полная инсталляция Инсталляция Server Core
Server Manager MMC ×

ServerManagerCMD.exe ×
OCSetup.exe ×
Unattend.xml × ×
Task sequence × ×
Инсталляция при помощи консоли Server Manager MMC

Server Manager предоставляет графический интерфейс для управления конфигурацией
Windows Server 2008, включая инсталляцию и деинсталляцию ролей и функций. При
помощи Server Manager можно легко инсталлировать роль Hyper-V. Запустите Server
Manager либо при помощи щелчка по значку Server Manager в системном лотке (затем
надо щелкнуть правой кнопкой мыши по пункту Computer и выбрать пункт Manage),
либо при помощи выбора пункта Server Manager в меню Administrative Tools. Ис-
пользуйте для инсталляции роли Hyper-V следующую процедуру:
1. После запуска Server Manager выберите в левой панели пункт Roles. После этого в
правой панели будет показан экран Roles Summary (рис. 4.1), в котором приводится
описание инсталлированных на сервере ролей и даются варианты добавления и уда-
ления ролей.
2. Нажмите кнопку Add Roles (чтобы получить список ролей для выбора).
3. Нажмите кнопку Next для пропуска страницы Before You Begin.
4. На странице Select Server Roles установите флажок Hyper-V (рис. 4.2) и нажмите
кнопку Next.
5. Если на том сервере, где вы пытаетесь инсталлировать роль Hyper-V, нет необходи-
мых расширенных функций процессора, то мастер Add Roles Wizard выдаст вам
информационное диалоговое окно (рис. 4.3), в котором говорится о том, что роль
Hyper-V инсталлировать невозможно. Прочитайте показанную информацию, устра-
ните проблемы в BIOS, а затем повторите инсталляцию роли с пункта 1 этой про-
цедуры.
Рис. 4.1. Экран Roles Summary
Рис. 4.2. Выбор роли Hyper-V
6. Если проблем с процессором нет, то мастер перечисляет сетевые интерфейсы сер-

вера и выдает диалоговое окно (рис. 4.4) с запросом, хотите ли вы определить вир-
туальную сеть с использованием какого-либо из этих интерфейсов. Интерфейс
в этот момент указывать не обязательно. Выбор интерфейса (при инсталляции роли

Hyper-V) приведет к автоматическому созданию внешней виртуальной сети. Сде-
лайте свой выбор и нажмите кнопку Next.
Рис. 4.3. Диалоговое окно Hyper-V cannot be installed
Рис. 4.4. Выбор интерфейса для виртуальной сети
Если вы инсталлируете Hyper-V удаленно через подключение удаленного рабочего стола,
то будьте осторожны — не выберите тот сетевой интерфейс, через который работает сеанс
удаленного рабочего стола. При создании виртуальной сети стек TCP/IP сбрасывается и
сеанс удаленного рабочего стола будет прерван. После сброса сетевого стека сеанс уда-
ленного рабочего стола нужно будет подключить вновь.
7. Вы сделали все необходимые (для процесса инсталляции) настройки. Нажмите

кнопку Install для инсталляции роли Hyper-V и административных инструментов.
После инсталляции файлов вы получите запрос на перезагрузку компьютера (для
завершения инсталляции роли на сервере). После перезагрузки сервера должен на-
чать работать гипервизор, а в меню Administrative Tools появится пункт Hyper-V
Manager MMC.
Инсталляция при помощи ServerManagerCmd.exe

ServerManagerCmd.exe предоставляет интерфейс командной строки для управления
конфигурацией сервера Windows Server 2008. Почти все, что вы можете сделать при
помощи оснастки Server Manager MMC, вы можете сделать и посредством
ServerManagerCmd.exe (с использованием его опций командной строки). Можно при
помощи ServerManagerCmd.exe инсталлировать и роль Hyper-V, хотя нельзя при этом
выбрать сетевой адаптер для виртуальной сети. После инсталляции роли Hyper-V мож-
но создать виртуальную сеть при помощи Hyper-V MMC.
1. Для добавления роли Hyper-V при помощи командной строки введите следующую
команду (в командной строке с повышенными правами) и нажмите клавишу
<Enter>:
ServerManagerCmd.exe –install Hyper-V
После нажатия клавиши <Enter> сразу же начнется инсталляция, и способа остановить ее
не будет.
2. Если сервер, на котором вы пытаетесь инсталлировать Hyper-V, не соответствует

требованиям к его оборудованию, то вы получите сообщение об ошибке (рис. 4.5).
Рис. 4.5. Сообщение об ошибке
3. Если проблем с оборудованием нет, то инсталляция начинается сразу же, причем во

время инсталляции процент ее выполнения будет отображаться в виде <xxx/100>,
где xxx — это процент выполнения. Когда инсталляция завершится, вам будет вы-
дано напоминание о необходимости произвести перезагрузку для завершения ин-
сталляции (рис. 4.6). Перезагрузите сервер (без использования времени ожидания)
командой Shutdown –r –t 0.
Рис. 4.6. Напоминание о перезагрузке
Использование OCSetup.exe
При инсталляции роли Hyper-V на инсталляции Server Core невозможно использовать
ServerManagerCmd.exe (поскольку Server Manager в инсталляции Server Core отсутству-
ет). Компания Microsoft предоставляет другой инструмент — OCSetup.exe, который
можно использовать для инсталляции ролей или функций на Server Core.
При инсталляции при помощи OCSetup.exe на Server Core вы можете использовать два
подхода. Первый: просто запустить OCSetup.exe для инсталляции Hyper-V. Второй ис-
пользует дополнительный шаг для автоматического запуска гипервизора и последую-
щей инсталляции при помощи OCSetup. Разница в подходах состоит в количестве пе-
резагрузок. Если вы просто используете OCSetup, то инсталляция потребует дополни-
тельной перезагрузки (чтобы обеспечить активацию всех опций). Если вы вручную
включаете автоматический запуск гипервизора перед инсталляцией роли Hyper-V при
помощи OCSetup, то от одной перезагрузки вы избавляетесь.
Для подготовки текущей инсталляции Windows Server 2008 для автоматического за-
пуска гипервизора при загрузке (перед инсталляцией роли Hyper-V) введите следую-
щую команду:
Bcdedit /set HypervisorLaunchType Auto
После того как вы установили автоматический тип запуска гипервизора, роль Hyper-V
можно инсталлировать при помощи OCSetup.exe.
1. В командном окне введите следующую строку и нажмите клавишу <Enter>:
Start /w OCSetup Microsoft-Hyper-V
Название роли "Microsoft-Hyper-V" чувствительно к регистру. Вы должны ввести его именно
так, как показано.
2. Для проверки инсталляции Hyper-V вы можете использовать инструмент OCList.

Введите OCList, а затем нажмите клавишу <Enter>.
Вы увидите список всех инсталлированных пакетов сервера в алфавитном порядке.
Прокрутите список и найдите Microsoft-Hyper-V. Если он инсталлировался пра-
вильно, то он должен быть приведен в списке как Installed:Microsoft-Hyper-V.
Опции инсталляции:
Microsoft Hyper-V Server 2008
Microsoft Hyper-V Server 2008 — это отдельный гипервизор на базе технологий
Windows Server 2008 и Hyper-V. В отличие от Windows Server 2008 (где вы должны
инсталлировать роль Hyper-V), при инсталляции сервера Microsoft Hyper-V Server 2008
дополнительной настройки (чтобы получить поддержку гипервизора) после инсталля-
ции не требуется.
Инсталляция сервера Microsoft Hyper-V Server 2008 очень похожа на инсталляцию лю-
бого другого продукта семейства Windows Server и использует стандартный мастер
инсталляции. Далее приведены шаги по инсталляции сервера Microsoft Hyper-V Ser-
ver 2008:
1. Вставьте инсталляционный диск Microsoft Hyper-V Server 2008.
2. Включите питание сервера и выберите загрузку с CD.
3. Главная страница инсталляции запрашивает язык для страниц инсталляции
(рис. 4.7). Выберите предпочтительный для вас язык.
Рис. 4.7. Запрашиваемый язык

4. Следующая страница позволяет вам выбрать инсталлируемый язык, формат време-

ни и валюты, а также язык клавиатуры (рис. 4.8). По завершении этих настроек на-
жмите кнопку Next.
Рис. 4.8. Выбор языка инсталляции, формата времени и валюты, языка клавиатуры
5. Теперь вы готовы начать инсталляцию (рис. 4.9). Нажмите кнопку Install now.
6. Просмотрите условия лицензии и установите флажок I accept the license terms, а
затем нажмите кнопку Next (рис. 4.10).
7. Сервер Microsoft Hyper-V Server 2008 не поддерживает обновления с другой вер-
сии Windows, так что единственный вариант — Custom (advanced). Щелкните по
нему (рис. 4.11).
8. Выберите диск и раздел для инсталляции (можете при необходимости использо-
вать опции создания, удаления или модификации существующих разделов). Когда
будете готовы продолжать, нажмите кнопку Next (рис. 4.12).
9. Начнется инсталляция, которая пройдет в полностью автоматическом режиме
(рис. 4.13).
10. Когда инсталляция завершится, то вы увидите экран регистрации. Сервер Microsoft
Hyper-V Server 2008 полностью инсталлирован и ждет дальнейшей настройки
(рис. 4.14).
Рис. 4.9. Приглашение к инсталляции
Рис. 4.10. Лицензионное соглашение

Рис. 4.11. Выбор варианта инсталляции
Рис. 4.12. Выбор диска и раздела для инсталляции

Рис. 4.13. Инсталляция запущена
Рис. 4.14. Экран регистрации

Дополнительные методы инсталляции

Кроме инсталляции Hyper-V вручную, есть также варианты инсталлирования его при
помощи автоматизированных методов. Первый метод — автоматическая инсталляция
при помощи Unattend.xml — инсталлирует операционную систему и роль Hyper-V в
одном процессе. Файл Unattend.xml отвечает на все вопросы во время развертывания.
Второй метод — инструментальный набор Microsoft Deployment Toolkit 2008 (MDT) —
предоставляет способ инсталляции операционной системы и роли Hyper-V единым ав-
томатизированным шагом, но без использования файла Unattend.xml. MDT автомати-
чески создаст файл Unattend.xml и использует постинсталляционные скрипты для кон-
фигурирования прочих указанных опций и настроек. Третий метод — менеджер System
Center Virtual Machine Manager (SCVMM) 2008 — предоставляет способ инсталляции
роли Hyper-V как части процесса добавления хоста в консоль управления.
Использование Unattend.xml для инсталляции Hyper-V

Использование автоматической инсталляции с применением файла Unattend.xml и об-
новленной версии ISO (со встроенным обновлением финальной версии Hyper-V) по-
зволит вам полностью автоматизировать инсталляцию операционной системы
Windows Server 2008 и роли Hyper-V. Метод автоматической инсталляции будет рабо-
тать также и с сервером Microsoft Hyper-V Server 2008, хотя Hyper-V уже инсталлиро-
ван по умолчанию, так что автоматическая инсталляция используется только для ин-
сталляции операционной системы сервера.
Для автоматической инсталляции нужно создать файл Unattend.xml со всеми нужными
вам опциями и настройками, записать его на гибкий диск и загрузить сервер с загру-
зочного диска WinPE. Затем в командной строке WinPE вы переходите на диск
CD-ROM и выполняете следующую команду (для запуска инсталляции с использова-
нием файла Unattend.xml на гибком диске):
Setup /unattend:A:\unattend.xml
Автоматическая инсталляция роли Hyper-V

Модифицировать файл Unattend.xml для активации роли Hyper-V несложно. Для этого
нужно добавить основной пакет, обновление KB950050, а также указать, что инсталля-
ции подлежит как роль Hyper-V, так и клиенты управления для Hyper-V.
Для модификации файла Unattend.xml версии Windows Server 2008 Enterprise Edition
1. Запустите менеджер Windows System Image Manager (WSIM) — рис. 4.15.
2. В меню File выберите пункт Select Windows Image и выберите файл Install.wim.
3. Откройте имеющийся файл Unattend.xml для редактирования (при помощи пункта
File | Open Answer File).
4. Под узлом Packages разверните узел Foundation.
5. Щелкните правой кнопкой мыши по элементу amd64_Microsoft-Windows-
Foundation_Package_6.0.6001.18000 и выберите пункт контекстного меню Add To
Answer File.
Рис. 4.15. Менеджер Windows System Image Manager
6. В панели Answer File выберите элемент amd64_Microsoft-Windows-Foundation_

Package_6.0.6001.18000, и вы увидите свойства этого пакета в панели справа.
7. В панели Windows Features Selection используйте раскрывающийся список для из-
менения состояния Microsoft-Hyper-V и Microsoft-Hyper-V-Management-Clients
(с Disabled на Enabled).
8. Теперь сохраните файл ответов и используйте его для инсталляции сервера.
Необслуживаемая инсталляция сервера Microsoft Hyper-V Server 2008

Выполнение необслуживаемой инсталляции сервера Microsoft Hyper-V Server 2008
требует создания файла ответов Unattend.xml (использующего файл Install.wim дистри-
бутива Microsoft Hyper-V Server 2008) и применения этого файла ответов для инстал-
ляции сервера. Сервер Microsoft Hyper-V Server 2008 основан на тех же самых техноло-
гиях, что и Windows Server 2008, но он оптимизирован исключительно как сервер вир-
туализации на базе гипервизора. Поддержка виртуализации Hyper-V инсталлируется по
умолчанию (поэтому не нужно указывать инсталляцию этой роли). Не нужно также
встраивать обновление KB950050, поскольку сервер Microsoft Hyper-V Server по-
ставляется с новейшей версией Hyper-V. В данном случае вы используете файл
Unattend.xml только для указания таких настроек, как имя компьютера, ввод в домен и
IP-адрес.
Инструментальный набор Microsoft Deployment Toolkit 2008

Microsoft Deployment Toolkit 2008 — это продукт для выполнения инсталляций опера-
ционных систем при минимальном взаимодействии с пользователем. Это называется
Lite Touch. Текущая версия Microsoft Deployment Toolkit 2008 (MDT) — уже четвертое
поколение этой технологии. MDT дает вам высокую степень настройки развертывания
операционных систем (при помощи концепции последовательности задач). Последова-
тельность задач — это набор инструкций (в виде скрипта), который позволяет MDT:
инсталлировать операционную систему; встраивать драйверы и обновления; конфигу-
рировать сеть; подключаться к домену; скачивать и устанавливать обновления; инстал-
лировать роли, функции и приложения; и многое другое. Все эти задачи контролиру-
ются и конфигурируются в консоли MDT (с названием Deployment Workbench).
Использование набора Microsoft Deployment Toolkit

для инсталляции роли Hyper-V
Использование MDT избавляет от необходимости создавать обновленную версию
Windows Server 2008 (с включением обновления Hyper-V). Вместо того чтобы интегри-
ровать обновление вручную, MDT позволяет вам импортировать обновление в узел OS
Packages консоли Deployment Workbench. MDT автоматически разворачивает пакет и
извлекает cab-файл. Во время инсталляции MDT автоматически устанавливает обнов-
ление (это делается как часть процесса развертывания), устраняя необходимость
встраивания его в образ операционной системы.
В следующей процедуре разъясняется процесс интеграции обновления KB950050 в
консоль Deployment Workbench и развертывание сервера Windows Server 2008 с авто-
матической инсталляцией роли Hyper-V.
Для добавления обновления KB950050 в консоль Deployment Workbench выполните
следующие шаги:
1. Скачайте обновление KB950050 х64 с сайта Microsoft Downloads и поместите его в
каталог C:\Updates сервера MDT.
2. Запустите консоль Deployment Workbench.
3. В левой панели щелкните правой кнопкой мыши по узлу Distribution Share\OS
Packages и выберите пункт New.
4. Запустится мастер New Package Wizard. На странице Specify Directory мастера вве-
дите C:\Updates в качестве каталога, который мастер должен проверить при поиске
пакетов. Затем нажмите кнопку Finish.
5. Пакет обновления KB950050 будет развернут и добавлен в узел OS Packages.
6. После завершения добавления пакета вы увидите его как Package_for_KB950050
в списке OS Packages.
Для создания последовательности задач для инсталляции Windows Server 2008 выпол-
ните следующие шаги:
1. После инсталляции пакета создайте новую последовательность задач Task Sequence
(при помощи выделения узла Task Sequences в левой панели консоли Deployment
Workbench). Щелкните правой кнопкой мыши по этому узлу и выберите пункт

New.
2. На странице General Settings мастера New Task Sequence Wizard (рис. 4.16) задайте
уникальный идентификатор Task sequence ID и название Task sequence name (ко-
торые вы будете использовать для ссылок на последовательность задач), а затем
нажмите кнопку Next.
Рис. 4.16. Страница General Settings мастера New Task Sequence Wizard
3. На странице Select Template (рис. 4.17) выберите в раскрывающемся списке опцию

Standard Server Task Sequence, а затем нажмите кнопку Next.
4. На странице Select OS мастера (рис. 4.18) выберите инсталлируемую версию опера-
ционной системы Windows Server 2008. Например, выберите Windows Longhorn
SERVERENTERPRISE для полной инсталляции Windows Server 2008 Enterprise
Edition, а затем нажмите кнопку Next.
Если у вас в консоли Deployment Workbench в настоящее время нет версии операционной
системы Windows Server 2008, то вы должны будете использовать мастер New OS Wizard
для загрузки Windows Server 2008. Пошаговые инструкции см. в руководстве Microsoft
Deployment Toolkit Quick Start Guide.
Рис. 4.17. Страница Select Template мастера
Рис. 4.18. Страница Select OS мастера

5. На странице Specify Product Key (рис. 4.19) выберите вариант — указать ключ про-
дукта или нет. Затем нажмите кнопку Next.
Рис. 4.19. Страница Specify Product Key
6. На странице OS Settings (рис. 4.20) укажите правильную информацию в текстовых

полях Full Name, Organization и Internet Explorer Home Page, а затем нажмите
кнопку Next.
7. На странице Admin Password (рис. 4.21) выберите, нужно ли задавать пароль адми-
нистратора. Введите пароль (при желании), а затем нажмите кнопку Finish.
Для редактирования последовательности задач по инсталляции роли Hyper-V выполни-
те следующие шаги:
1. Выберите узел Task Sequences (чтобы в центральной панели консоли Deployment
Workbench отобразились все существующие последовательности задач). Дважды
щелкните только что созданную последовательность задач (чтобы увидеть ее свой-
ства).
2. Выберите вкладку Task Sequence (рис. 4.22) для отображения последовательности
задач.
3. В узле State Restore выделите шаг Install Applications и нажмите кнопку Add, вы-
берите опцию Roles, а затем — Install Roles and Features (рис. 4.23).
Рис. 4.20. Страница OS Settings
Рис. 4.21. Страница Admin Password

Рис. 4.22. Вкладка Task Sequence
Рис. 4.23. На вкладке Task Sequence выберите Install Roles and Features
4. Выделите Install Roles and Features в последовательности задач, а затем в правой

панели найдите роль Hyper-V и установите флажок рядом с ней (чтобы инсталлиро-
вать эту роль) — рис. 4.24. Затем нажмите кнопку OK. Теперь последовательность
задач настроена (для инсталляции роли Hyper-V).
Рис. 4.24. Выберите роль Hyper-V
5. Далее следуйте стандартному процессу развертывания MDT (инсталлируйте после-

довательность задач при помощи загрузки PXE с использованием служб Windows
Deployment Services или с помощью ISO-образа Lite Touch WinPE).
Использование Microsoft Deployment Toolkit

для инсталляции сервера Microsoft Hyper-V
При инсталляции сервера Microsoft Hyper-V Server 2008 технология виртуализации
Hyper-V инсталлируется по умолчанию. Чтобы использовать MDT для инсталляции
Microsoft Hyper-V Server 2008, файлы операционной системы с инсталляционного дис-
ка необходимо загрузить в консоль Deployment Workbench как образ операционной
системы. Этот процесс управляется мастером, и для него требуется наличие на сервере
MDT инсталляционного диска.
Для загрузки нового образа операционной системы в консоль Deployment Workbench

1. Запустите консоль Deployment Workbench.
2. В левой панели под узлом Distribution Share щелкните правой кнопкой мыши по
узлу Operating Systems и выберите пункт New.
3. На странице OS Type (рис. 4.25) выберите одну из опций: Full set of source files,
Custom image file или Windows Deployment Services images. В нашем случае со-
гласитесь с вариантом по умолчанию Full set of source files, а затем нажмите кнопку
Next.
Рис. 4.25. Страница OS Type в консоли Deployment Workbench
4. На странице Source (рис. 4.26) вставьте инсталляционный диск в дисковод DVD,

укажите дисковод (D:\) в поле Source directory, а затем нажмите кнопку Next.
5. На странице Destination (рис. 4.27) в текстовом поле Destination directory name
укажите имя каталога для хранения файлов дистрибутива операционной системы,
а затем нажмите кнопку Finish.
6. Консоль Deployment Workbench скопирует файлы в указанный каталог (рис. 4.28)
и после завершения поместит в список Operating System каждый найденный внут-
ри Install.wim образ.
Рис. 4.26. Страница Source
Рис. 4.27. Введите имя каталога назначения на странице Destination

Рис. 4.28. Копирование файлов в каталог дистрибутивов
Более подробную информацию по инструментальному набору Microsoft Deployment Toolkit
2008 и будущей его версии Microsoft Deployment Toolkit 2010 вы можете получить по ссыл-
ке: http://www.microsoft.com/deployment.
Инсталляция роли Hyper-V

при помощи System Center Virtual Machine Manager 2008
Менеджер System Center Virtual Machine Manager 2008 (SCVMM) — это решение
Microsoft для управления серверами Hyper-V из центральной консоли. SCVMM может
управлять: хостом Windows Server 2008, который еще не имеет инсталлированной роли
Hyper-V; хостом с инсталлированной ролью Hyper-V; а также хостом с инсталлирован-
ным сервером Microsoft Hyper-V Server. Если роль Hyper-V не активирована, то
SCVMM может удаленно активировать эту роль (во время процесса добавления хоста
в консоль управления).
Для добавления хоста в консоль управления SCVMM и автоматической активации ро-
ли Hyper-V используйте следующие шаги:
1. Запустите консоль SCVMM Administration Console (рис. 4.29).
2. В меню Actions выберите пункт Add Host (для запуска мастера Add Hosts Wizard).
3. На странице Select Host Location (рис. 4.30) есть три возможных варианта иденти-
фикации хоста. Для сервера Hyper-V подходят только два:
• если сервер является членом того же самого домена или доверенного домена, то
выберите вариант Windows Server-based host on an Active Directory domain.
Укажите также пароль и учетную информацию для подключения к домену, а за-

тем нажмите кнопку Next;
• если сервер входит в демилитаризованную зону или не подключен ни к одному
домену, то выберите вариант Windows Server-based host on a perimeter
network, а затем нажмите кнопку Next.
Рис. 4.29. Запуск консоли SCVMM Administration Console
4. На странице Select Host Servers (рис. 4.31) выберите серверы для добавления в кон-
соль SCVMM. В текстовом поле Computer name укажите имя сервера для добавле-
ния, а затем нажмите кнопку Add. После добавления всех серверов в консоль
SCVMM нажмите кнопку Next.
5. Если какой-то из выбранных хостов является сервером Hyper-V, то SCVMM пока-
жет предупреждающее сообщение (рис. 4.32) с объяснением, что роль Hyper-V мо-
жет быть развернута только в том случае, если она еще не инсталлирована. Нажми-
те кнопку Yes.
6. На странице Configuration Settings (рис. 4.33) выберите группу Host group, в кото-
рую будет помещен сервер Hyper-V. По умолчанию это группа All Hosts. Нажмите
кнопку Next.
7. На странице Host Properties (рис. 4.34) укажите дополнительные пути для хранения
файлов виртуальных машин и измените порт по умолчанию для удаленного рабоче-
го стола (в случае необходимости). Затем нажмите кнопку Next.
Рис. 4.30. Опции идентификации хоста Hyper-V
Рис. 4.31. Страница Select Host Servers

Рис. 4.32. Предупреждающее сообщение VMM
Рис. 4.33. Выберите группу хостов на странице Configuration Settings
8. На странице Summary (рис. 4.35) просмотрите все те действия, которые будут про-
деланы. Затем нажмите кнопку Add Hosts.
9. Появится диалоговое окно Jobs (рис. 4.36). Выберите выполняющуюся задачу (что-
бы увидеть состояние ее выполнения).
Если сетевой экран блокирует доступ к совместно используемому ресурсу ADMIN$ на хос-
те, то задача Add Hosts закончится неудачей. Настройте сетевой экран таким образом,
чтобы он разрешал File And Print Sharing, и попробуйте еще раз.
Рис. 4.34. Страница Host Properties
Рис. 4.35. Страница Summary

Рис. 4.36. Просмотр состояния выполнения на странице Jobs
Соображения по конфигурированию
после инсталляции
После того как вы активируете роль Hyper-V в Windows Server 2008 или инсталлируете
сервер Microsoft Hyper-V Server 2008, вам нужно будет выполнить некоторые шаги по
конфигурированию. Эти шаги включают: конфигурирование идентификации сервера;
активирование Remote Desktop; установка обновлений; настройка правил сетевого эк-
рана; многие другие задачи. Выполнение этих действий на полной инсталляции
Windows Server 2008 с графическим интерфейсом вам конечно уже знакомо. Однако
многие не знают, как выполнять эти действия при помощи интерфейса командной
строки на инсталляции Server Core или сервера Microsoft Hyper-V Server 2008.
Компания Microsoft предоставила пошаговое руководство для инсталляции Server Core
(чтобы описать обычные действия по конфигурированию и используемые для этого
инструменты). Для сервера Microsoft Hyper-V Server 2008 компания Microsoft предос-
тавляет инструмент командной строки, который содержит все те действия по конфигу-
рированию, которые необходимо выполнить для активации удаленного управления
сервером Hyper-V. Этот инструмент выполняет не все требующиеся действия по кон-
фигурированию, но он конфигурирует сервер Hyper-V таким образом, что к нему мож-
но получить доступ через стандартные инструменты удаленного управления с графиче-
ским интерфейсом.
Команды для модификации инсталляции Server Core

Следующие разделы описывают некоторые стандартные задачи и соответствующие им
команды для конфигурирования инсталляции Server Core. Этот список задач не являет-
ся исчерпывающим.
Конфигурирование домена
В табл. 4.3 дан список задач и соответствующих команд для модификации членства
сервера Hyper-V в домене или рабочей группе.
Таблица 4.3. Команды конфигурирования домена или рабочей группы
Задача Команда
Ввести компьютер в домен netdom join %computername% /domain:<domain>
/userd:<domain>\<username> /password:*
Вывести компьютер из домена netdom remove
Изменить имя находящегося в netdom renamecomputer %computername% /NewName:

домене компьютера <new computer name> /userd:<domain>\<username> /password:*
Изменить имя находящегося в netdom renamecomputer <currentcomputername>

рабочей группе компьютера /NewName:<newcomputername>
Конфигурирование группы локальных администраторов

В табл. 4.4 дан список задач и соответствующие команды для модификации пароля
локального администратора и членства в группе локальных администраторов сервера
Hyper-V.
Таблица 4.4. Команды конфигурирования локальных администраторов
Настроить пароль локального администратора net user administrator *
Добавить пользователя в группу локальных net localgroup Administrators /add

администраторов <domain>\<username>
Удалить пользователя из группы локальных net localgroup Administrators /delete

администраторов <domain\username>
Конфигурирование сети
В табл. 4.5 приведен список задач и соответствующих команд по модификации сетевой
конфигурации сервера Hyper-V.
Таблица 4.5. Команды конфигурирования сети
Переход к статическому netsh interface ipv4 set address name <ID from interface
адресу IP list> source=static address=<preferred IP address>
gateway=<gateway address>
Настройка статического netsh interface ipv4 add dnsserver name=<name of primary

адреса DNS для первичного DNS server> address=<IP address of the primary DNS server>
сервера DNS index=1
Настройка статического netsh interface ipv4 add dnsserver name=<name of secondary

адреса DNS для вторичного DNS server> address=<IP address of the secondary DNS
сервера DNS server> index=2
Переход к получаемому netsh interface ipv4 set address name=<IP address of local
по протоколу DHCP system> source=DHCP
адресу IP
Активация
В табл. 4.6 представлен список задач и соответствующие команды для активации сер-
вера Hyper-V.
Таблица 4.6. Команды конфигурирования активации
Активировать сервер локально slmgr.vbs -ato
Активировать сервер удаленно cscript slmgr.vbs -ato <servername> <username> <password>
Сетевой экран
В табл. 4.7 приведен список задач и соответствующие команды для модификации кон-
фигурации сетевого экрана сервера Hyper-V.
Таблица 4.7. Команды конфигурирования сетевого экрана
Активировать удаленное netsh advfirewall firewall set rule group="Windows

администрирование сетевого экрана Firewall Remote Management" new enable=yes
Отключить сетевой экран netsh firewall set opmode=disable
Включить сетевой экран netsh firewall set opmode=enable
Включить исключения File and Print netsh firewall set service fileandprint mode=enable
Включить удаленное управление netsh firewall set service remoteadmin enable
Журналы событий
В табл. 4.8 приведен список задач и соответствующих команд для вывода, запроса и
управления журналом событий сервера Hyper-V.
Таблица 4.8. Команды журнала событий
Дать список журналов событий wevtutil el
Запросить события из указанного журнала wevtutil qe /f:text <log name>

Экспортировать журнал событий wevtutil epl <log name>
Очистить журнал событий wevtutil cl <log name>
Инструмент конфигурирования сервера

Microsoft Hyper-V Server 2008
Сервер Microsoft Hyper-V Server 2008 поставляется с инструментом конфигурирования
(имеющим систему меню и работающим из командной строки) с названием
HVConfig.cmd, который позволяет вам настроить подключения и функции, необходи-
мые для использования сервера Hyper-V в управляемой среде. HVConfig.cmd фактиче-
ски вызывает скрипт-файл с названием HVConfig.vbs, который и обеспечивает всю
функциональность. HVConfig.cmd запускается при каждой регистрации и позволяет
вам делать следующее:
конфигурировать членство в домене или рабочей группе;
настраивать имя компьютера;
конфигурировать настройки сетевого адаптера;
добавлять доменные учетные записи в группу локальных администраторов;
конфигурировать Windows Update для автоматических или ручных обновлений;
скачивать и инсталлировать обновления Windows;
конфигурировать удаленный рабочий стол Remote Desktop;
настраивать региональные и языковые опции;
настраивать дату и время.
Кроме того, меню конфигурирования Hyper-V Configuration позволяет вам выполнять
следующие действия:
выход из системы;
рестарт;
завершение работы.
На рис. 4.37 показано меню Hyper-V Configuration, которое появляется после инстал-
ляции сервера Hyper-V.
Конфигурирование домена или рабочей группы

Выбор в меню варианта 1 позволит вам ввести сервер Hyper-V в домен или рабочую
группу (рис. 4.38). По умолчанию после инсталляции сервер находится в рабочей
группе.
Рис. 4.37. Меню Hyper-V Configuration
Рис. 4.38. Конфигурирование сервера Hyper-V для ввода в домен или рабочую группу
Для ввода сервера в домен в окне конфигурирования сервера Hyper-V выполните сле-
дующие действия:
1. Введите 1 (чтобы выбрать вариант конфигурирования домена или рабочей группы).
2. Введите D (для конфигурирования членства в домене).
3. Введите название домена (например, contoso.com), а затем нажмите клавишу
<Enter>.
4. Введите идентификатор пользователя домена, который имеет право добавлять ком-
пьютеры в домен (например, contoso\administrator), а затем нажмите клавишу
<Enter>.
5. Предпринимается попытка ввода в домен. Если она пройдет успешно, то вы полу-
чите сообщение "You must restart your computer to apply these changes. Restart now?".
Нажмите кнопку Yes для перезагрузки.
Имя компьютера
Чтобы изменить имя сервера Hyper-V, выберите вариант 2. На экране будет показано
текущее имя сервера.
Для изменения имени сервера выполните следующие шаги:
1. Введите 2 (чтобы выбрать вариант изменения имени сервера).
2. Введите новое имя компьютера, а затем нажмите клавишу <Enter>.
3. Варианты зависят от того, находится ли сервер в домене или в рабочей группе.
• Для компьютера в рабочей группе будет выполнено изменение имени, и при его
успехе вы получите диалоговое окно с сообщением "The computer needs to be
restarted in order to complete the operation". Команда закончилась успешно, так что
нажмите кнопку OK.
• Для входящего в домен компьютера вы получите запрос названия домена и
идентификатора пользователя, который имеет право на изменение имени ком-
пьютера. Введите домен\идентификатор, а затем нажмите клавишу <Enter>. После
этого вы получите запрос пароля указанного пользователя. Введите пароль, а за-
тем нажмите клавишу <Enter>.
4. Теперь вы получите сообщение "you must restart your computer to apply these changes.
Restart now?". Нажмите кнопку Yes для перезагрузки.
Сетевые настройки
Для изменения конфигурации сетевых адаптеров сервера Hyper-V выберите вариант 3
(рис. 4.39). Вы можете настроить адрес IP статическим или через DHCP, указать серве-
ры DNS для разрешения имен, либо очистить текущие настройки сервера DNS.
Рис. 4.39. Настроить сетевые адаптеры сервера Hyper-V
Для конфигурирования сетевых адаптеров сервера выполните в окне Hyper-V Con-

figuration представленные далее шаги.
1. Для изменения конфигурации сетевого адаптера сервера введите 3.

2. Вы получите список сетевых адаптеров. Выберите адаптер при помощи ввода его
индекса, а затем нажмите клавишу <Enter>.
3. Будет показана текущая конфигурация выбранного сетевого адаптера (рис. 4.40),
в том числе адрес IP, маска подсети (если для адаптера включен DHCP), сетевой
шлюз по умолчанию, первичный и вторичный серверы DNS. Вы получите четыре
новых варианта меню: Set Network Adapter IP Address, Set DNS Servers, Clear
DNS Server Settings и Return to Main Menu.
Рис. 4.40. Текущая конфигурация сетевого адаптера и варианты меню
4. Выберите вариант 1 (чтобы настроить адрес IP), а затем нажмите клавишу <Enter>.
5. Вы получите возможность выбрать либо статический адрес IP, либо присваивание
адреса через DHCP. Введите D (для выбора DHCP) или S (для указания статического
адреса).
Если вы ввели D, то сервер будет настроен на получение адреса IP, маски подсети и
сетевого шлюза от сервера DHCP.
Если вы ввели S, то получите запрос на ввод статического адреса для данного сете-
вого адаптера. Введите статический адрес IP в формате с точкой (например,
10.10.1.22), а затем нажмите клавишу <Enter>.
6. Введите маску подсети в формате с точкой (например, 255.255.0.0), а затем нажмите
клавишу <Enter>.
7. Введите шлюз по умолчанию в формате с точкой (например, 10.10.1.1), а затем на-
жмите клавишу <Enter>. Теперь вы вернетесь обратно в меню Network Adapter
Settings.
Для конфигурирования адресов первичного и вторичного серверов DNS выполните
1. Введите 2 и нажмите клавишу <Enter>.
2. Введите адрес IP сервера DNS, а затем нажмите клавишу <Enter>.
3. Сервер DNS будет настроен и появится диалоговое окно с сообщением "Preferred

DNS Server set". Нажмите кнопку OK.
4. Введите адрес IP для вторичного сервера DNS, а затем нажмите клавишу <Enter>.
5. Вторичный сервер DNS будет настроен, и появится диалоговое окно с сообщением
"Alternate DNS Server set". Нажмите кнопку OK.
Если необходимо перейти от статического адреса к конфигурированию через DHCP, то
нужно сбросить статические адреса серверов DNS.
Для сброса статических адресов DNS выполните следующие шаги:
1. Введите 3, а затем нажмите клавишу <Enter>.
2. Вы увидите диалоговое окно с сообщением "DNS Servers Removed". Теперь серверы
DNS будут автоматически поступать из сети. Нажмите кнопку OK.
После внесения всех изменений в сетевые настройки введите 4 (чтобы вернуться в
главное меню), а затем нажмите клавишу <Enter>.
Добавление локального администратора

Выбор варианта 4 позволит вам добавить локального или доменного пользователя в
группу локальных администраторов сервера Hyper-V. Для добавления доменных поль-
зователей сервер должен быть членом домена или иметь установленные доверитель-
ные отношения с тем доменом, пользователя которого вы хотите добавить. Для упро-
щения этого процесса вы должны быть зарегистрированы с локальными администра-
тивными правами.
Для добавления пользователя в группу локальных администраторов сервера выполните
в окне Hyper-V Configuration следующие шаги:
1. Введите 4 (чтобы добавить пользователя в локальную группу Administrators).
2. Если вы хотите добавить в локальную группу Administrators пользователя домена,
то введите домен\пользователь и нажмите клавишу <Enter>.
3. Если вы хотите добавить в локальную группу Administrators локального пользова-
теля, то введите идентификатор пользователя и нажмите клавишу <Enter>.
4. Независимо от того, какого пользователя вы добавляете, вы получите сообщение
"User added to Local Administrators group", при этом будет выведен идентификатор
добавленного пользователя. Нажмите кнопку OK.
Настройки Windows Update

Выбор варианта 5 позволит вам сконфигурировать сервер Hyper-V для автоматическо-
го получения обновлений Windows Updates в 3 часа ночи (по умолчанию) ежедневно,
либо для получения обновлений вручную (рис. 4.41).
Для конфигурирования обновлений Windows Update выполните в окне Hyper-V
Configuration представленные далее шаги.
Рис. 4.41. Сконфигурировать хост Hyper-V для получения обновлений
1. Введите 5 (чтобы выбрать вариант изменения настроек Windows Update).

2. Если сервер Hyper-V настроен на автоматические обновления, то введите M
для конфигурирования сервера под ручные обновления, а затем нажмите клавишу
<Enter>.
Вы получите сообщение "Windows Update set to Manual. System will never check for
updates". Нажмите кнопку OK.
3. Если сервер Hyper-V сконфигурирован для ручных обновлений, то введите A для
конфигурирования сервера под автоматические обновления, а затем нажмите кла-
вишу <Enter>.
Вы получите сообщение "Windows Update set to Automatic. System will check for and
install updates every day at 3:00 AM". Нажмите кнопку OK.
4. Меню Hyper-V Configuration покажет текущую конфигурацию Windows Update.
Скачивание и инсталляция обновления

Выбор варианта 6 позволит вам интерактивно скачать обновления с Windows Update.
Для использования этого варианта сервер Hyper-V должен иметь подключение к Ин-
тернету. Выбор этого варианта произведет запуск скрипта, который использует ло-
кальный клиент Windows Update для связи с серверами Windows Update и определения
отсутствующих на данном сервере обновлений. Будет выведен список обновлений
и предоставлен выбор — инсталлировать все обновления или отменить обновление.
Если будут выбраны все обновления, то обновления будут скачаны с Windows Update и
инсталлированы. Если после обновлений потребуется перезагрузка, то диалоговое окно
уведомит вас об этой необходимости.
Для скачивания и инсталляции обновлений Windows Updates на сервер Hyper-V в ин-
терактивном режиме выполните в окне Hyper-V Configuration следующие шаги:
1. Введите 6 (чтобы выбрать вариант скачивания и инсталляции обновлений Windows
Updates). Появится новое командное окно скрипта Windows Update (рис. 4.42).
2. Скрипт определит недостающие обновления Windows Updates и выдаст список всех

критичных и рекомендуемых обновлений (рис. 4.43). Вы получите запрос "Would
you like download and install updates now?". Если вы введете Y, то все обновления из
списка будут скачаны и инсталлированы на локальном компьютере.
Рис. 4.42. Скачать и инсталлировать обновления на хост Hyper-V
Рис. 4.43. Список критичных и рекомендуемых обновлений
3. Вы можете также получить запрос "A restart is required to complete windows updates.
Restart now?". Нажмите кнопку Yes, чтобы произвести перезагрузку.
Удаленный рабочий стол

Выбор варианта 7 позволит вам активировать или дезактивировать удаленный рабочий
стол на сервере Hyper-V (рис. 4.44). Windows Server 2008 поддерживает различные
клиенты для удаленного рабочего стола. По умолчанию Windows Server 2008 поддер-
живает клиентов, которые имеют версию Remote Desktop Connection client 6.0 и более
поздние. Эти клиенты поддерживают аутентификацию на уровне сети и прочие расши-
ренные функции. По умолчанию в Windows Vista и Windows Server 2008 используются
клиенты Remote Desktop Connection версии 6.0. В Windows XP SP2 и Windows Server
2003 SP1 (или SP2) используется более ранняя версия клиента Remote Desktop
Connection, однако можно скачать и инсталлировать обновление клиента Remote
Desktop Connection до версии 6.0.
Для настройки удаленного рабочего стола на сервере Hyper-V в окне Hyper-V

Configuration выполните следующие шаги:
1. Введите 7 (чтобы выбрать конфигурирование удаленного рабочего стола на сервере
Microsoft Hyper-V Server 2008).
2. По умолчанию удаленный рабочий стол дезактивирован. Для его включения введи-
те Y.
3. Вы получите на выбор два варианта:
• введите 1 для включения удаленного рабочего стола для клиентов, использую-
щих версию Remote Desktop Connection 6.0 или более новые (с использованием
безопасной аутентификации на уровне сети);
• введите 2 для включения удаленного рабочего стола для клиентов, использую-
щих версию Remote Desktop Connection ниже 6.0 (с использованием менее безо-
пасной аутентификации).
Рис. 4.44. Включение и выключение удаленного рабочего стола
4. Вы получите диалоговое окно с подтверждением сделанного вами выбора. Нажмите

кнопку OK.
Если вам нужно дезактивировать удаленный рабочий стол на хосте Microsoft Hyper-V
Server 2008, выполните в окне Hyper-V Configuration следующие шаги:
1. Введите 7 (чтобы выбрать вариант конфигурирования удаленного рабочего стола на
сервере Microsoft Hyper-V Server 2008).
2. Для отключения удаленного рабочего стола введите D.
3. Вы получите сообщение "Remote Desktop disabled". Нажмите кнопку OK.
Региональные и языковые опции

Выбор варианта 8 позволит вам сконфигурировать региональные и языковые опции
сервера Hyper-V (рис. 4.45). Региональные и языковые опции включают: язык, на кото-
ром отображаются числовые данные; местоположение сервера; язык клавиатуры и

дисплея; административные опции по хранению и извлечению языковых настроек.
Для конфигурирования региональных и языковых настроек сервера Hyper-V в окне
Hyper-V Configuration необходимо выполнить следующие шаги:
1. Введите 8 и нажмите клавишу <Enter> (чтобы сконфигурировать или модифициро-
вать региональные и языковые настройки сервера Hyper-V).
2. Вы получите диалоговое окно Regional and Language Options сервера Hyper-V.
Рис. 4.45. Сконфигурировать региональные и языковые настройки сервера Hyper-V
3. Когда вы закончите конфигурировать региональные и языковые настройки, нажми-

те кнопку OK или Apply для фиксации изменений (либо Cancel для их отмены).
Дата и время
Выбор варианта 9 позволит вам сконфигурировать дату и время на сервере Hyper-V
(рис. 4.46). В число этих настроек входят: дата, время, часовой пояс, а также дополни-
тельные часы. Несмотря на то, что вкладка для дополнительных часов имеется, сами
дополнительные часы на экране не отображаются.
Для конфигурирования даты и времени на сервере Hyper-V выполните в окне Hyper-V
Configuration следующие шаги:
1. Введите 9 и нажмите клавишу <Enter> для конфигурирования или модификации да-
ты и времени сервера Hyper-V.
Рис. 4.46. Сконфигурировать дату и время на сервере Hyper-V
2. Вы получите диалоговое окно Date and Time сервера Hyper-V.

3. Когда вы закончите конфигурировать дату и время, нажмите кнопку OK для фикса-
ции изменений (или Cancel для их отмены).
Выход из системы
Выбор варианта 10 позволит вам закончить текущий сеанс конфигурирования и выйти
из системы. После этого хост Microsoft Hyper-V Server вернется к стандартному экрану
регистрации Windows. Этот вариант даст тот же самый результат, что и нажатие ком-
бинации клавиш <Ctrl>+<Alt>+<Delete> с выбором варианта выхода из системы.
Для выхода текущего пользователя из системы Microsoft Hyper-V Server в окне Hyper-V
1. Введите 10 и нажмите клавишу <Enter> (для выхода текущего пользователя из сис-
темы).
2. Вы получите запрос "Are you sure you want to Log Off?". Нажмите кнопку Yes.
Перезапуск сервера
Выбор варианта 11 позволит вам перезапустить хост Microsoft Hyper-V Server. Этот
вариант приведет к тому же действию, что и нажатие комбинации клавиш
<Ctrl>+<Alt>+<Delete> с последующим выбором перезапуска. Если на сервере Hyper-V
работают виртуальные машины, то перед перезапуском хоста Hyper-V они будут авто-
матически сохранены.
Для перезапуска хоста Microsoft Hyper-V Server выполните в окне Hyper-V

Configuration следующие шаги:
1. Введите 11 и нажмите клавишу <Enter> (для перезапуска сервера Hyper-V).
2. Вы получите запрос "Are you sure you want to Restart?". Нажмите кнопку Yes.
Выключение сервера
Выбор пункта 12 позволит вам завершить работу хоста Microsoft Hyper-V Server. Этот
вариант приведет к такому же действию, что и нажатие пользователем комбинации
клавиш <Ctrl>+<Alt>+<Delete> и выбор пункта завершения работы в меню. Если на
сервере Hyper-V работают виртуальные машины, то перед выключением Hyper-V они
будут автоматически сохранены.
Для выключения хоста Microsoft Hyper-V Server выполните в окне Hyper-V Con-
figuration следующие шаги:
1. Введите 12 и нажмите клавишу <Enter> (для завершения работы сервера Hyper-V).
2. Вы получите запрос "Are you sure you want to Shut Down?". Нажмите кнопку Yes.
Выход в командную строку

Выбор варианта 13 приведет к выходу из инструмента конфигурирования Hyper-V
Configuration в командную строку. Вы можете вручную перезапустить инструмент
Hyper-V Configuration, он будет также автоматически запущен после выхода и после-
дующего входа в систему.
Для выхода и перезапуска инструмента конфигурирования в окне Hyper-V
1. Введите 13 и нажмите клавишу <Enter> (для выхода в командную строку).
2. Если вам нужно перезапустить инструмент Hyper-V Configuration, введите hvconfig
и нажмите клавишу <Enter>.
Резюме
В этой главе описаны варианты установки роли Hyper-V на полной инсталляции и ин-
сталляции Server Core для версий Windows Server 2008 64-бит Standard, Enterprise и
Datacenter, а также сервера Microsoft Hyper-V Server 2008. Для Hyper-V требуется
64-битный процессор с аппаратной поддержкой виртуализации и включенной функци-
ей Data Execute Protection. Здесь мы создали обновленную версию Windows Server 2008
и роли Hyper-V (чтобы сделать доступным финальный код Hyper-V и службы интегра-
ции Integration Services). В данной главе обсуждалось также использование инструмен-
тального набора Microsoft Deployment Toolkit 2008 для того, чтобы избежать необхо-
димости предварительного создания обновленного дистрибутива; сам же набор являет-
ся простым в использовании инструментом развертывания. Вы узнали, что менеджер
System Center Virtual Machine Manager инсталлирует роль Hyper-V автоматически во
время процесса добавления хостов Add Host (если на сервере еще нет Hyper-V). В этой
главе также были описаны выполняемые после инсталляции шаги и те инструменты,

которые могут упростить эти шаги.

Microsoft Deployment Toolkit 2008, описание по развертыванию и применению
Microsoft Deployment Toolkit 2008, доступное по ссылке:
http://www.microsoft.com/deployment;
Netsh Commands for Windows Firewall, описание опций команды netsh сетевого эк-
рана, доступное по ссылке:
http://technet.microsoft.com/en-us/library/cc771046.aspx;
Microsoft Hyper-V Server 2008, информация о продукте Microsoft Hyper-V Server
2008 и документация по его инсталляции и конфигурированию, доступные по ссыл-
ке: http://www.microsoft.com/HVS;
Windows Imaging File Format, описание формата файлов Windows Imaging, доступ-
ное по ссылке: http://go.microsoft.com/fwlink/?LinkId=92227.
ГЛАВА 5
Расширенные функции Hyper-V
В этой главе описываются расширенные функциональные возможности Hyper-V и объ-

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

возможностей виртуальных жестких дисков
Сервер Hyper-V использует формат виртуальных жестких дисков (VHD) для инкапсу-
лирования данных виртуальной машины в один или более файлов, которые эквива-
лентны физическим дискам обычного сервера. Используя формат VHD как основной
строительный блок, Hyper-V предоставляет расширенные функциональные возможно-
сти виртуальных жестких дисков, позволяющие создавать виртуализированные среды,
которые более функциональны и более гибки, чем их физические аналоги (в особенно-
сти для таких целей, как разработка программного обеспечения, тестирование, обуче-
ние и поддержка). В табл. 5.1 перечислены описанные в данном разделе расширенные
функции виртуальных жестких дисков.
Таблица 5.1. Расширенные функциональные возможности виртуальных жестких дисков
Функция Описание
Differencing disks Специальный тип динамически расширяющихся виртуальных жестких дис-
(разностный диск) ков, который хранит изменения данных виртуальной машины, изолируя их
от основного виртуального жесткого диска
Automatic differencing Специальный тип динамически расширяющихся виртуальных жестких дис-
disks (автоматический ков, который хранит изменения данных виртуальной машины, изолируя их
разностный диск) от основного виртуального жесткого диска. Похож на разностный диск, но
есть отличия в опциях и сценариях использования. Автоматические разно-
стные диски создаются при выполнении моментального снимка виртуаль-
ной машины
Physical disk to VHD Процесс копирования содержимого физического жесткого диска в файл
copy (копия физиче- виртуального жесткого диска. Этот процесс может быть достаточно дли-
ского диска на VHD) тельным и зависит от размера физического диска
Convert VHD (конвер- Процесс конвертирования динамически расширяющегося диска в диск фик-
тирование VHD) сированного размера и наоборот. Этот процесс может быть достаточно
длительным и зависит от размера виртуального жесткого диска. Во время
конвертирования VHD должен быть в автономном режиме
Compact VHD Процесс возвращения неиспользованного пространства, выделенного вир-
(сжатие VHD) туальному жесткому диску. Процесс сжатия работает только с динамически
расширяющимися или разностными виртуальными жесткими дисками. Дру-
гие типы VHD сжимать нельзя. Во время сжатия VHD должен быть в авто-
номном режиме
Expand VHD Процесс увеличения максимального объема хранения для динамически
(расширение VHD) расширяющихся или фиксированных виртуальных дисков. Во время расши-
рения VHD должен быть в автономном режиме
Разностные диски
Данные работающей внутри Hyper-V виртуальной машины содержатся на одном или
нескольких основных виртуальных дисках. Когда происходит изменение данных гос-
тевой операционной системы или работающих в ней приложений, то эти изменения
фиксируются на виртуальных жестких дисках. Изменения на виртуальных жестких
дисках постоянные (как и в стандартных физических системах). Однако сохранение
основного виртуального диска в неизмененном состоянии предоставляет массу различ-
ных возможностей (при этом все изменения в виртуальной машине продолжают сохра-
няться).
Разностный диск — это специальный тип динамически расширяющегося диска, кото-
рый хранит изменения данных виртуальной машины в отдельном от основного вирту-
ального жесткого диска файле. Связь основного и разностного виртуальных дисков
определяется как связь "родитель→потомок". В такой взаимосвязи каждый дочерний
разностный диск может наследовать только от одного родительского диска, но роди-
тельские диски могут использоваться для создания нескольких различных дочерних
разностных дисков.
На рис. 5.1 показано, что разностные диски могут создаваться как в простых, так и в
очень сложных иерархиях "родитель→потомок". Многоуровневая иерархия разност-
ных дисков обычно называется цепью разностных дисков, а это отражает тот факт, что
дочерний разностный диск может иметь такого родителя, который также является раз-
ностным диском. Цепь может состоять из нескольких уровней, но она всегда начинает-
ся от стандартного виртуального жесткого диска (либо динамически расширяющегося,
либо фиксированного размера). Это важная концепция, поскольку изменения данных
на разностном диске представлены как модифицированные (по сравнению с родитель-
ским диском) блоки. Поэтому разностный диск никогда не используется самостоятель-
но, а только совместно со всеми родительскими дисками в своей иерархии.
Глава 5. Расширенные функции Hyper-V 169
Рис. 5.1. Многоуровневая иерархия разностных дисков
Если вы изучите файловую систему сервера Hyper-V, то увидите, что каждый разност-
ный диск хранится как отдельный файл. В файловой же системе виртуальной машины
вы видите только один диск — независимо от того, сколько уровней разностных дис-
ков реально связано с данным виртуальным жестким диском.
Для облегчения выявления связей разностных дисков в сложной цепочке примите некое
стандартизованное соглашение по наименованию виртуальных жестких дисков. Менеджер
Hyper-V Manager позволяет вам обследовать разностный диск и выявить его родительский
диск, но он не сообщает о связанных с ним дочерних разностных дисках.
Создание разностного диска

Когда вы создаете новый разностный диск, то должны указать местоположение основ-
ного виртуального жесткого диска, который будет родителем нового разностного дис-
ка. Родительский диск может быть либо диском фиксированного размера, либо дина-
мически расширяющимся виртуальным жестким диском. Разностный диск растет по
мере необходимости до размера, указанного для родительского виртуального жесткого
диска.
Для создания разностного диска выполните следующие шаги:
1. Откройте консоль менеджера Hyper-V Manager.
2. В панели Actions под именем сервера щелкните по пункту New и выберите пункт
Hard Disk в меню (чтобы запустить мастер New Virtual Hard Disk Wizard).
3. На странице Before You Begin нажмите кнопку Next.

4. На странице Choose Disk Type выберите опцию Differencing, а затем нажмите
кнопку Next.
5. На странице Specify Name and Location введите в текстовом поле Name имя нового
разностного диска, а затем в текстовом поле Location введите полный путь к ката-
логу хранения (либо нажмите кнопку Browse, чтобы использовать Windows Explorer
для выбора каталога хранения). После выполнения всех этих действий нажмите
кнопку Next.
6. На странице Configure Disk введите в текстовом поле Location полный путь к ро-
дительскому виртуальному жесткому диску (либо нажмите кнопку Browse, чтобы
использовать Windows Explorer для выбора родительского виртуального жесткого
диска). После этого нажмите кнопку Next.
7. На странице Completing The New Virtual Hard Disk Wizard просмотрите сделан-
ные вами настройки.
8. Нажмите кнопку Finish.
По умолчанию разностные диски используют расширение vhd, что затрудняет их отличие
от стандартных виртуальных жестких дисков.
Изучение связей "родитель→потомок" разностных дисков

Каждый динамический диск имеет стандартную верхнюю шапку виртуального жестко-
го диска, в которой содержится верхняя шапка конкретного типа динамического диска.
Формат верхней шапки динамического диска одинаковый для динамически расши-
ряющегося и разностного дисков. Однако несколько полей этой шапки имеют смысл
только для разностных дисков, поскольку они указывают атрибуты родительского дис-
ка. Список полей верхней шапки динамического диска приведен в табл. 5.2, причем
относящиеся только к разностным дискам выделены жирным шрифтом.
Таблица 5.2. Верхняя шапка динамического диска
Поле верхней шапки

Описание
динамического диска
Cookie Поле, которое идентифицирует верхнюю шапку
Data Offset Абсолютное смещение в байтах до следующей структуры образа диска
(в настоящее время не используется)
Table Offset Абсолютное смещение в байтах таблицы выделения блоков (BAT)
в файле
Header Version Версия верхней шапки динамического диска
Max Table Entries Максимальное количество элементов в ВАТ
Block Size Размер блока, который используется для расширения динамического
диска
Checksum Контрольная сумма верхней шапки динамического диска
Поле верхней шапки

Описание
динамического диска
Parent UUID 128-битный универсальный уникальный идентификатор (UUID) родитель-

ского диска (используется только для разностных дисков)
Parent Time Stamp Временная метка модификации родительского диска (используется толь-
ко для разностных дисков)
Reserved Данное поле установлено в ноль
Parent Unicode Name Строка в кодировке Unicode — имя файла родительского диска (исполь-
зуется только для разностных дисков)
Parent Locator Entry 1 Специфичный для конкретной платформы формат, содержащий абсо-
лютное смещение в байтах того места в файле, где хранится родитель-
ский локатор (используется только для разностных дисков)
лютное смещение в байтах в файле, где хранится родительский локатор
(используется только для разностных дисков)
Reserved Значение поля установлено в нуль
Разностный диск использует информацию об UUID и имени файла родительского дис-

ка (из верхней шапки динамического диска) для того, чтобы найти и открыть роди-
тельский диск. Поскольку родительский диск также может быть разностным диском,
то вполне возможно, что будет открыта вся иерархия родительских дисков (вплоть до
основного виртуального жесткого диска).
Переносимость родительского и дочерних разностных дисков для различных сервер-
ных платформ обеспечивается элементами Parent Locator (приведенными в табл. 5.2).
Эти элементы хранят специфичную для конкретной платформы информацию для оты-
скивания родительских разностных дисков на физическом диске.
ВАЖНО
Для платформы Microsoft Windows в элементе Parent Locator разностного диска хранятся
и абсолютный (например, C:\parent\parent.vhd), и относительный (например, .\parent
\parent.vhd) пути к родительскому диску. Если вы используете экспорт виртуальной машины
для переноса ее на новый сервер, то сможете импортировать виртуальную машину на тот
сервер Hyper-V и включить ее (без всяких дополнительных изменений).
Для того чтобы узнать больше об экспорте и импорте виртуальных машин Hyper-V, см. главу 2.
Когда использующая разностные диски виртуальная машина выдает операцию записи,

то данные пишутся только в дочерний разностный диск. Частью этого процесса являет-
ся обновление структуры внутренних данных виртуального жесткого диска (для отра-
жения тех изменений, которые замещают собой данные родительского диска). Во вре-
мя операций чтения эта же внутренняя структура данных виртуального жесткого диска
проверяется, чтобы определить, какие данные нужно читать из дочернего разностного
диска. Неизмененные данные читаются из родительского диска.
Конфигурирование родительских дисков "только для чтения"
Дочерний разностный диск записывает временну́ю метку модификации родительского дис-
ка в момент своего создания. Любые модификации родительского диска после создания
дочернего разностного диска будут обнаружены и сделают дочерний диск недействитель-
ным. Для обеспечения невозможности записи в родительский диск (которая нарушит связь
"родитель→потомок" между дисками) сконфигурируйте родительский диск как "только для
чтения".
Брион Сурэйс (Bryon Surace, Program Manager (Windows Virtualization))
Повторное подключение разностных дисков

Если один (или более) виртуальный жесткий диск в цепи разностных дисков не может
быть найден, то связанные с таким отключенным дочерним разностным диском вирту-
альные машины работать не смогут. Если вы попытаетесь запустить виртуальную
машину с отключенным разностным диском, то Hyper-V сгенерирует похожую на
показанную на рис. 5.2 ошибку. Кроме того, вы не можете добавить отключенный до-
черний разностный диск в виртуальную машину.
Для решения этой проблемы вы должны повторно подключить дочерний разностный
диск к его родительскому диску. Если родительский диск был случайно удален или
перемещен, то вы можете просто вернуть его назад на старое место. Если же родитель-
ский диск был специально перемещен в другой каталог, то вы должны будете обновить
новым значением пути элемент Parent Locator (родительский локатор) дочернего раз-
ностного диска. К счастью, Hyper-V предоставляет возможность обследовать дочерний
разностный диск и повторно подключить его к своему родительскому диску. При по-
мощи этой возможности вы указываете новое местоположение родительского диска, а
Hyper-V обновляет абсолютный и относительный пути (хранящиеся в элементе Parent
Locator дочернего разностного диска).
Рис. 5.2. Ошибка Hyper-V, сгенерированная при запуске виртуальной машины

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

при помощи опции Inspect Disk выполните следующие шаги:
2. В панели Actions под именем сервера щелкните по пункту Inspect Disk.
3. В окне Windows Explorer перейдите к тому каталогу, в котором содержится дочер-
ний разностный диск, щелкните по соответствующему файлу VHD, а затем нажмите
кнопку Open.
4. В диалоговом окне Virtual Hard Disk Properties нажмите кнопку Reconnect (чтобы
запустить мастер Edit Virtual Hard Disk Wizard).
5. На странице Reconnect Virtual Hard Disk нажмите кнопку Next.
6. На странице Reconnect To Parent Virtual Hard Disk введите полный путь и назва-
ние родительского виртуального жесткого диска, либо нажмите кнопку Browse для
использования окна Windows Explorer для перехода к каталогу и выбора файла
VHD. После выполнения всех этих действий нажмите кнопку Next.
7. На странице Completing The Edit Virtual Hard Disk Wizard просмотрите сделан-
9. Убедитесь, что в диалоговом окне Virtual Hard Disk Properties указан правильный
полный путь к родительскому виртуальному жесткому диску.
10. Нажмите кнопку Close.
Можно также пропустить вариант Inspect Disk и выбрать Edit Disk в панели Actions ме-
неджера Hyper-V Manager. После выбора отключенного разностного диска мастер Edit
Virtual Hard Disk Wizard автоматически распознает, что диск нужно повторно подключить, и
выдаст страницу Reconnect Virtual Hard Disk мастера Edit Virtual Hard Disk Wizard (как по-
казано в шаге 5 предыдущей процедуры).
Объединение разностных дисков

Несмотря на то, что разностный диск можно использовать для постоянного хранения
изменений в данных виртуальной машины, вам может понадобиться объединить до-
черний разностный диск с родительским диском. Hyper-V предоставляет для этого два
способа. Вы можете либо влить разностный диск в родительский диск, либо объеди-
нить разностный и родительский диски в новый виртуальный жесткий диск. Если вы
вливаете разностный диск в родительский диск, то разностный диск по завершении
этого процесса удаляется, а любые другие (указывающие на данный родительский
диск) дочерние диски становятся недействительными. Если же вам нужно сохранить
разностный диск, то следует выполнить слияние разностного и родительского дисков в
новый виртуальный жесткий диск. Для снижения риска потери данных рекомендуется
именно этот подход. Перед удалением исходных файлов вы можете проверить успеш-
ность операции слияния.
ВАЖНО
Перед слиянием разностного и родительского дисков в новый виртуальный жесткий диск
убедитесь в том, что на физическом диске имеется достаточно места для выполнения этой
операции.
Для объединения в новый виртуальный жесткий диск выполните следующие шаги:

2. В панели Actions под именем сервера щелкните по пункту Edit Disk (для запуска
мастера Edit Virtual Hard Disk Wizard).
4. На странице Locate Virtual Hard Disk введите полный путь к разностному диску,
который вы хотите слить (либо нажмите кнопку Browse для использования окна
Windows Explorer для его указания). Затем нажмите кнопку Next.
5. На странице Choose Action выберите опцию Merge, а затем нажмите кнопку Next.
6. На странице Merge Changes From Differencing Disk выберите вариант To A New
Virtual Hard Disk. Вы должны ввести полный путь и название нового виртуального
жесткого диска (либо нажать кнопку Browse для использования окна Windows
Explorer для выбора каталога, а потом ввести название). Затем вы должны выбрать
тип нового жесткого диска (динамический или фиксированный). После завершения
этих действий нажмите кнопку Next.
7. На странице Completing The Edit Virtual Hard Disk Wizard проверьте сделанные
вами настройки.
Использование разностных дисков

Преимущества использования разностных дисков становятся очевидными при рас-
смотрении типичного сценария поддержки. Инженеру службы поддержки часто нужно
искать неисправности в разных обновлениях операционных систем и разных приложе-
ниях. При использовании одного или нескольких тестовых серверов (даже с предвари-
тельно подготовленными образами) настройка и тестирование множества серверных
конфигураций является длительным и сложным процессом, который существенно уве-
личивает время реакции на поставленную проблему. При помощи разностных дисков
Hyper-V инженер поддержки может быстро создать виртуальную машину для каждой
конфигурации сервера. Началом служит родительский виртуальный жесткий диск, ко-
торый содержит основную операционную систему, затем создаются все нужные сер-
верные конфигурации (в виде новых виртуальных машин с одним или несколькими
разностными дисками — для сохранения обновлений операционных систем и прило-
жений).
ВАЖНО
Разностные диски не следует использовать в кластерных конфигурациях.
Как показано на рис. 5.3, реализация виртуализированной среды поддержки с исполь-

зованием разностных дисков может помочь существенно сократить циклы настройки и
Рис. 5.3. Использование разностных дисков для создания гостевых виртуальных машин
для одновременного тестирования
тестирования (которые влияют на время решения проблемы). Даже при наличии всего
одного физического сервера сервер Hyper-V может выполнять несколько виртуальных
машин одновременно, что позволяет параллельно производить тестирование различ-
ных конфигураций сервера. Кроме создания среды, которая может привести к сокра-
щению времени отклика службы поддержки, такое решение имеет также преимущест-
во в плане экономии значительных объемов дискового пространства (для любого сце-
нария, в котором требуется множество сложных конфигураций с общей базой
программного обеспечения (имеющей большой объем)).
Автоматические разностные диски

Автоматические разностные диски похожи на обычные разностные диски. Подобно
разностному диску, автоматический разностный диск используется для изоляции изме-
нений в данных виртуальной машины от основного виртуального жесткого диска.
Автоматические разностные диски тоже имеют те же специальные характеристики ди-
намических дисков, которые были описаны ранее для разностных дисков. Однако ав-
томатические разностные диски используются для поддержки моментальных снимков
виртуальных машин Hyper-V, когда необходимо быстро отказаться от изменений
в данных или быстро откатиться к базовому состоянию виртуальной машины.
В отличие от разностного диска (который имеет расширение vhd) автоматический разност-
ный диск использует расширение avhd. По умолчанию автоматические разностные диски
хранятся в том же самом каталоге, что и виртуальная машина (в подкаталоге Snapshots).
Чтобы больше узнать о функции моментальных снимков виртуальных машин Hyper-V,
см. разд. "Использование моментальных снимков виртуальной машины" далее в этой главе.
Важным отличием между разностными и автоматическими разностными дисками яв-

ляется процесс их конфигурирования. Разностный диск создается на уровне виртуаль-
ных жестких дисков и обычно связан с созданием новой виртуальной машины. Авто-
матический же разностный диск создается сервером Hyper-V при генерировании
моментального снимка виртуальной машины. Автоматический разностный диск созда-
ется для каждого виртуального жесткого диска данной виртуальной машины. Иначе
говоря, вы не можете выбрать те виртуальные жесткие диски, для которых будут гене-
рироваться автоматические разностные диски.
ВАЖНО
Если вам нужно перенести виртуальную машину с одного сервера Hyper-V на другой, ис-
пользуйте функцию экспорта виртуальных машин (чтобы в одном каталоге экспорта были
сохранены файлы конфигурации виртуальной машины, родительские виртуальные жесткие
диски, дочерние разностные диски, а также автоматические разностные диски с момен-
тальными снимками).
Копирование физического диска на VHD

Сервер Hyper-V позволяет вам дублировать содержимое физического диска на новый
виртуальный жесткий диск. При использовании этого метода для миграции содержи-
мого физического диска на виртуальный жесткий диск необходимо учитывать не-

сколько требований. Вот эти ограничения:
при копировании VHD конвертируется физический диск, а не том или раздел;
копирование VHD может использоваться только для миграции диска с данными;
миграция дисков операционных систем не поддерживается;
копирование VHD следует использовать для конвертирования физического диска,
к которому во время этого процесса не производится доступ из операционной сис-
темы хоста или из приложений;
копирование VHD для физического диска размером более 127 Гбайт требует под-
ключения виртуального диска через виртуальный SCSI-адаптер.
Этот процесс может занять значительное время (зависит от размера копируемого фи-
зического диска).
До начала копирования на VHD вам следует использовать консоль Disk Management
Microsoft Management Console (MMC) (или другой аналогичный инструмент) для удаления
буквы целевого диска. Это сделает диск недоступным для операционной системы хоста и
предотвратит его повреждение во время процесса конвертирования.
Конвертирование физического диска в виртуальный жесткий диск

Процесс создания нового виртуального жесткого диска из физического несложен. Для
того чтобы начать этот процесс и скопировать содержимое физического диска на но-
вый виртуальный жесткий диск, выполните следующие шаги:
1. Откройте консоль Hyper-V Manager.
2. В панели Actions под именем сервера щелкните по пункту New, а затем выберите
пункт Hard Disk в меню (для запуска мастера New Virtual Hard Disk Wizard).
4. На странице Choose Disk Type выберите тип создаваемого диска (Dynamically
Expanding или Fixed Size), а затем нажмите кнопку Next.
5. На странице Specify Name and Location введите в текстовом поле Name название
для нового виртуального жесткого диска, а затем введите в текстовом поле Location
полный путь к каталогу хранения (либо нажмите кнопку Browse, чтобы в окне
Windows Explorer выбрать каталог хранения). После завершения всех этих действий
6. На странице Configure Disk выберите Copy The Contents Of The Specified Physical
Disk, а затем щелкните в списке по тому физическому жесткому диску, который вы
хотите конвертировать. После завершения всех этих действий нажмите кнопку
Next.
7. На странице Completing The New Virtual Hard Disk Wizard просмотрите сделан-
В качестве целевого диска для преобразования следует использовать диск фиксированно-
го размера (если у вас не будет потребности в динамическом расширении виртуального
жесткого диска).
Конвертирование VHD
В Hyper-V вы можете конвертировать динамически расширяющийся VHD в VHD фик-
сированного размера или конвертировать VHD фиксированного размера в динамиче-
ски расширяющийся VHD. Динамически расширяющийся VHD использует простран-
ство физического диска наиболее эффективным образом, но имеет пониженную произ-
водительность, вызванную фрагментацией файлов. Если вы создадите динамически
расширяющийся VHD размером в 1 Гбайт, то его начальный размер на физическом
диске составит примерно 10 Кбайт (а динамически расширяющийся диск максималь-
ного размера в 2040 Гбайт первоначально использует примерно 16 Мбайт дискового
пространства). Поскольку новый динамически расширяющийся VHD еще не содержит
данных, то его начальный размер отражает размер содержащейся в нем информации
верхней и нижней шапки файла VHD и таблицы выделения блоков. По мере записи
в виртуальной машине новых данных, Hyper-V расширяет размер VHD до его заданно-
го значения.
VHD фиксированного размера дает более высокую производительность (поскольку все
выделение пространства физического диска производится в момент создания VHD, что
обычно приводит к выделению непрерывного пространства). Аналогично динамически
расширяющимся VHD, диск VHD фиксированного размера вначале содержит верх-
нюю и нижнюю шапки файла, таблицу выделения блоков, а также сегмент данных
с пустыми блоками. По мере записи на VHD новых данных пустые блоки заменяются
данными.
Во время процесса конвертирования динамически расширяющегося VHD в VHD фик-
сированного размера (и наоборот) Hyper-V создает новый VHD указанного типа и ко-
пирует в него содержимое оригинального VHD. Для использования функции конвер-
тирования VHD выполните следующие шаги:
2. В панели Actions под именем сервера щелкните по пункту Edit Disk (для запуска
мастера Edit Virtual Hard Disk Wizard).
4. На странице Locate Virtual Hard Disk введите полный путь к виртуальному жест-
кому диску, который вы хотите сжать (либо нажмите кнопку Browse, чтобы в окне
Windows Explorer выбрать местоположение, а затем введите название VHD), а по-
том нажмите кнопку Next.
ВНИМАНИЕ!
Конвертирование VHD требует наличия достаточного количества дискового пространства
для одновременного хранения файлов исходного виртуального жесткого диска и нового
виртуального жесткого диска. Перед началом конвертирования Hyper-V проверяет имею-
щееся на целевом диске пространство и в случае его нехватки выдает ошибку. После ус-
пешного конвертирования исходный виртуальный жесткий диск остается на диске-
источнике.
Сжатие VHD
Сжатие VHD — это процесс, который уменьшает размер файла виртуального жесткого
диска (на физическом диске). Hyper-V имеет и такую опцию сжатия, которая удаляет
заполненные нулями или помеченные пустыми блоки (в имеющих файловую систему
NTFS динамически расширяющихся или разностных виртуальных жестких дисках).
Виртуальный жесткий диск фиксированного размера перед сжатием необходимо кон-
вертировать в динамически расширяющийся. Несмотря на то, что можно использовать
непосредственно опцию сжатия Hyper-V, предпочтительнее применять двухшаговый
процесс (перед сжатием производить дефрагментацию). Для использования опции
сжатия Hyper-V виртуальный жесткий диск не должен активно использоваться вирту-
альной машиной.
Перед дефрагментацией жесткого диска удалите из него временные файлы и каталоги, а
также все прочие ненужные данные. Очистите корзину удаленных файлов.
Если динамически расширяющийся виртуальный жесткий диск не отформатирован в

NTFS, то вы должны будете использовать трехступенчатый процесс, в который входят:
дефрагментация, предварительное сжатие и сжатие. Дефрагментация и предваритель-
ное сжатие готовят файл виртуального жесткого диска к сжатию. Предварительное
сжатие заполняет пустые области файла виртуального диска нулями. Это позволяет
Hyper-V удалить при сжатии секторы, которые содержат только нули (что приводит к
более существенному уменьшению размера файла). Сжатие VHD требует, чтобы вир-
туальный жесткий диск был в автономном режиме; поэтому все виртуальные машины,
которые могут предпринять попытку доступа к виртуальному жесткому диску, должны
быть перед сжатием выключены.
Сжатие VHD после удаления раздела в гостевой операционной системе
Если вы удалите раздел в гостевой операционной системе, то заметите, что сжатие
Hyper-V может не полностью сжать соответствующий VHD. Например, рассмотрим VHD
размером 100 Гбайт, который первоначально имел два раздела (определенных в гостевой
операционной системе): один раздел размером 10 Гбайт, а другой — 90 Гбайт. Если вы
удалите раздел размером в 90 Гбайт, то VHD может быть все равно больше десяти гига-
байтов (даже несмотря на то, что теперь он содержит только один раздел размером в
10 Гбайт). Сжатие Hyper-V не сожмет VHD полностью (поскольку оно работает только с ак-
тивными разделами). В такой ситуации для выполнения полного сжатия вы сначала долж-
ны произвести дефрагментацию диска (в гостевой операционной системе), затем создать в
свободном пространстве раздел NTFS, и наконец, выключить виртуальную машину и вы-
полнить сжатие Hyper-V (при помощи мастера Edit Disk Wizard в менеджере Hyper-V
Manager). Если вы выполните все эти стадии, то VHD будет полностью сжат.
Роб Хефнер (Rob Hefner, Support Escalation Engineer (Microsoft Enterprise Platforms Support))
Из-за потребности в процессорных и дисковых ресурсах сжатие виртуальных жестких дис-
ков лучше по возможности выполнять на непроизводственном сервере. В Hyper-V вы може-
те выполнить дефрагментацию и предварительное сжатие в виртуальной машине (либо
смонтировав виртуальный жесткий диск на сервере Hyper-V, пока виртуальный жесткий
диск находится в автономном режиме). Дефрагментацию, предварительное сжатие и сжа-
тие рекомендуется выполнять при нахождении виртуального жесткого диска в автономном
режиме.
Дефрагментация файла виртуального жесткого диска

Первый шаг процесса по уменьшению размера виртуального жесткого диска — деф-
рагментация. По мере записи на диск новой информации она пишется на диск отдель-
ными блоками (не непрерывно). Со временем (по мере удаления данных на диске) пус-
тые блоки будут случайным образом перемешаны с фрагментами файлов. Избыточная
фрагментация диска снижает его производительность, поскольку на извлечение раз-
бросанных по всему диску данных уходит больше времени, чем если бы они были за-
писаны непрерывным блоком. Дефрагментация уменьшает или ликвидирует фрагмен-
тирование файлов на диске, что приводит к появлению больших пространств пустых
непрерывных блоков.
Для дефрагментации виртуального жесткого диска в автономном режиме вы сначала
должны смонтировать файл виртуального жесткого диска на сервере Hyper-V и пере-
вести его в оперативное состояние. Дальше показан простой пример — использование
скрипта PowerShell для монтирования файла VHD, присваивания ему буквы диска и
перевода его в оперативный режим.
# Указать полный путь для монтируемого файла VHD
$VHDFilename = "D:\HVResKit\Win2003\BaseX86VM.vhd"
# Получить указатель на объект MSVM_ImageManagementService

$IMGMgtSvc = get-wmiobject -class "Msvm_ImageManagementService"
-namespace "root\virtualization" -computername "."
# Смонтировать файл VHD

$Result = $IMGMgtSvc.Mount($VHDFilename)
# Проверить результат монтирования VHD и получить индекс диска

if ($Result.returnValue -eq 4096)
{$Job = [WMI]$result.job
while ($job.jobstate -eq 4) {Start-Sleep -seconds 1 ;
$Job.PSBase.Get() }
Start-sleep 2
$MountedDiskImage= Get-WmiObject -NameSpace "root\virtualization"
-query ("Select *
from Msvm_MountedStorageImage where name ='"+
$VHDFilename.replace("\","\\") +"'")
$diskIndex=(Get-WmiObject -Query "Select * From win32_diskdrive
Where Model='Msft Virtual Disk SCSI Disk Device' and
ScsiTargetID=$($MountedDiskImage.TargetId) and
ScsiLogicalUnit=$($MountedDiskImage.Lun) and
ScsiPort=$($MountedDiskImage.PortNumber)").index
# Перевести VHD в оперативный режим при помощи Dispart

if ($diskIndex -ne $null) {@("select disk $diskIndex", "online disk" ,
"attributes disk clear readonly", "exit") | Diskpart | Out-Null}
}
После монтирования виртуального жесткого диска используйте на сервере утилиту

Windows Defrag для дефрагментирования виртуального жесткого диска. Необходимое
для дефрагментации время зависит от нескольких факторов, в том числе от степени
фрагментации, размера файла, характеристик диска.
В командной строке Windows Server 2008 можно использовать Defrag DriveLetter –w,
где DriveLetter — это буква смонтированного виртуального жесткого диска, а опция –w
указывает, что необходимо консолидировать все фрагменты файлов (независимо от их
размера).
Предварительное сжатие файла виртуального жесткого диска

Для файлов виртуальных жестких дисков, которые не отформатированы в NTFS, вто-
рым шагом процесса является предварительное сжатие. Сервер Hyper-V не предостав-
ляет инструментов для предварительного сжатия. Однако сервер Virtual Server 2005 R2
имеет Virtual Disk Precompactor, который предназначен для заполнения нулями всех
нераспределенных дисковых блоков в файле виртуального жесткого диска. Вы можете
использовать его для подготовки виртуального жесткого диска, чтобы инструмент сжа-
тия Hyper-V мог сделать файл виртуального диска (не отформатированного в NTFS)
как можно меньшим.
Инструмент Virtual Disk Precompactor содержится в дисковом образе Precompact.iso,
который имеется в комплекте поставки сервера Virtual Server 2005 R2. Если на вашем
компьютере установлен сервер Virtual Server 2005 R2, то скопируйте файл
Precompact.iso на сервер Hyper-V и используйте предпочитаемый вами инструмент ра-
боты с виртуальными компакт-дисками для монтирования этого образа и копирования
с него Precompact.exe. В табл. 5.3 приведены те варианты, которые доступны при за-
пуске инструмента Virtual Disk Precompactor из командной строки.
Таблица 5.3. Опции командной строки инструмента Virtual Disk Precompactor
Опция командной строки Описание

-Help Показывает диалоговое окно помощи, в котором перечислены
опции командной строки, версия продукта, а также примеры
синтаксиса
-Version Показывает диалоговое окно помощи, в котором перечислены
опции командной строки, версия продукта, а также примеры
синтаксиса
-Silent Выполняет предварительное сжатие в автоматическом режи-
ме и подавляет все диалоговые окна
-SetDisks:<list> (<list> — Определяет список виртуальных жестких дисков для предва-

необязательный параметр, который рительного сжатия. Если эта опция не указана, то сжимаются
представляет собой одну или все виртуальные жесткие диски, подключенные к виртуальной
несколько букв дисков) машине
Например, следующая команда предварительно сжимает виртуальные жесткие диски,

смонтированные как буквы F и G (в автоматическом режиме):
Precompact –Silent –SetDisks:FG
Hyper-V позволяет также выполнять предварительное сжатие файлов виртуального жестко-
го диска внутри виртуальной машины. После монтирования образа Precompact.iso в диско-
воде виртуальной машины вы можете дважды щелкнуть по этому дисководу для запуска
Virtual Disk Precompactor. При использовании этого процесса вы не можете указать вирту-
альные жесткие диски для предварительного сжатия. В этом случае Virtual Disk
Precompactor предварительно сжимает все виртуальные жесткие диски, подключенные
к виртуальной машине.
Сжатие файла виртуального жесткого диска

Последний шаг процесса по уменьшению размера виртуального жесткого диска —
сжатие. Инструмент сжатия Hyper-V находит пустые блоки и удаляет их (уменьшая,
таким образом, размер файла виртуального жесткого диска).
Перед использованием инструмента сжатия Hyper-V вы должны демонтировать вирту-
альный жесткий диск с сервера Hyper-V. Вот простой пример скрипта PowerShell для
демонтирования файла VHD.
# Указать полный путь к демонтируемому файлу VHD
$VHDFilename = "D:\HVResKit\Win2003\BaseX86VM.vhd"
# Получить указатель на объект MSVM_ImageManagementService

$ImgMgtSvc = Get-WmiObject -NameSpace "root\virtualization" -Class
"MsVM_ImageManagementService"
# Демонтировать файл VHD

$Result=$ImgMgtSvc.Unmount($VHDFilename)
Для сжатия виртуального жесткого диска выполните следующие шаги:

2. В панели Actions под именем сервера щелкните по пункту Edit Disk (чтобы запус-
тить мастер Edit Virtual Hard Disk Wizard).
кому диску, который вы хотите сжать (либо нажмите кнопку Browse, чтобы исполь-
зовать окно Windows Explorer для его выбора). После выполнения этих действий
5. На странице Choose Action выберите опцию Compact, а затем нажмите кнопку
Next.
Процесс сжатия VHD можно вывести в скрипт при помощи интерфейса прикладного
программирования WMI для Hyper-V. Этот API позволяет вам создавать скрипты и
сжимать файлы виртуального жесткого диска вне консоли менеджера Hyper-V
Manager.
На приложенном к книге компакт-диске вы найдете каталог \Scripts\Chapter 5\Compact.
Внутри этого каталога есть три файла: скрипт для PowerShell с названием
CompactVHD.ps1, библиотека PowerShell Management Library для Hyper-V с названием
Hyperv.ps1, а также XML-файл Hyperv.format.ps1xml. Все три файла должны храниться в
одном каталоге вашего сервера Hyper-V. Скрипт CompactVHD.ps1 использует функции из
Hyperv.ps1 для монтирования файла виртуального жесткого диска и запуска дефрагмента-
тора (перед запуском инструмента сжатия Hyper-V для сжатия виртуального жесткого диска
в автономном режиме). Дополнительную информацию о библиотеке управления Hyperv.ps1
см. по адресу: http://pshyperv.codeplex.com.
Расширение VHD
Сервер Hyper-V может увеличить максимальный размер динамически расширяющего-
ся VHD (или VHD фиксированного размера). Когда Hyper-V расширяет VHD, он до-
бавляет дополнительное пространство в конец vhd-файла. После расширения файла
VHD для использования дополнительного пространства вы должны создать новый раз-
дел или расширить том. Важно отметить, что VHD можно расширять только тогда, ко-
гда виртуальная машина (к которой он подключен) выключена. Для расширения раз-
мера динамически расширяющегося VHD (или VHD фиксированного размера) выпол-
2. В панели Actions под именем сервера щелкните по пункту Edit Disk (чтобы запус-
тить мастер Edit Virtual Hard Disk Wizard).
кому диску, который вы хотите сжать (либо нажмите кнопку Browse, чтобы исполь-
зовать Windows Explorer для его выбора). После выполнения этих действий нажми-
те кнопку Next.
5. На странице Choose Action выберите опцию Expand, а затем нажмите кнопку Next.
6. На странице Expand Virtual Hard Disk введите новый размер VHD и нажмите
кнопку Next.
7. На странице Completing the Edit Virtual Hard Disk Wizard просмотрите сделанные
вами настройки.
ВНИМАНИЕ!
Важно отметить, что вы не должны расширять VHD, если он подключен к виртуальной ма-
шине, для которой имеются моментальные снимки (либо если он является родителем до-
чернего разностного диска). Любые модификации VHD в цепочке разностных дисков могут
привести к недействительности всех дочерних разностных дисков в этой цепочке.
Использование
моментальных снимков виртуальной машины
Моментальные снимки виртуальной машины позволяют вам сохранить конфигурацию
и состояние виртуальной машины на любой момент времени и вернуть виртуальную
машину в это состояние практически без прерывания ее работы. Когда вы делаете мо-
ментальный снимок работающей виртуальной машины, то Hyper-V на короткое время
приостанавливает виртуальную машину для создания нового автоматического вирту-
ального жесткого диска (avhd), подключает его к виртуальной машине для регистрации
(с этого момента времени) изменений в данных виртуальной машины, сохраняет со-
стояние процессора в файл (vsv), а затем запускает виртуальную машину. Hyper-V так-
же делает копию конфигурационного файла виртуальной машины (xml) и сохраняет
содержимое памяти виртуальной машины в файл (bin). Моментальные снимки можно
также создавать при выключенной виртуальной машине, в этом случае серверу Hyper-V
не нужно сохранять память виртуальной машины или данные по состоянию процес-
сора.
На сервере Hyper-V родительский раздел создает дочерние разделы и управляет ими
при помощи набора компонентов, называемого стеком виртуализации. Одним из ком-
понентов стека виртуализации является служба Virtual Machine Management Service
(VMMS). VMMS содержит множество важных компонентов, в том числе: менеджер
рабочих процессов Worker Process Manager (WPM) и менеджер моментальных снимков
Snapshot Manager (SM). WPM создает для каждой виртуальной машины рабочий про-
цесс виртуальной машины Virtual Machine Worker Process (VMWP) при ее запуске.
VMWP управляет созданием рабочих снимков для находящейся в оперативном состоя-
нии (работающей) виртуальной машины. Если виртуальная машина находится в авто-
номном режиме (и поэтому у нее нет активного процесса VMWP), то процессом созда-
ния моментальных снимков занимается менеджер Snapshot Manager.
Подробнее о роли всех компонентов в создании моментального снимка виртуальной маши-
ны см. в главе 3.
Моментальные снимки виртуальных машин в принципе предназначены для использо-

вания в средах тестирования и разработки, а не в производственной инфраструктуре.
Моментальные снимки не следует использовать как механизм восстановления для та-
ких транзакционных приложений, как Microsoft Exchange Server или Active Directory
Domain Services. Однако моментальные снимки могут быть исключительно полезны в
таких ситуациях, когда вам нужно делать модификации виртуальной машины с воз-
можностью отката обратно к предыдущему состоянию. Моментальные снимки могут
интенсивно использоваться при создании образов, в службе технической поддержки, а
также при тестировании приложений.
Перед тем как глубоко погрузиться в создание и использование моментальных сним-
ков виртуальной машины, важно понять структуру файлов виртуальной машины (на
сервере Hyper-V).
Как показано на рис. 5.4, каталог виртуальной машины и структура файлов в инсталля-
ции Hyper-V по умолчанию состоят из:
каталога Virtual Hard Disks, который хранит один или более виртуальных дисков
(содержащих файлы гостевой операционной системы, файлы приложений и дан-
ных);
каталога Snapshots, который первоначально не содержит файлов;
каталога Virtual Machines, который содержит XML-файл конфигурации виртуальной
машины (с именем на основе GUID), а также каталог с тем же самым GUID в назва-
нии (который содержит два файла). Первый файл — это файл сохраненного состоя-
ния (названный по тому же GUID, что и XML-файл, но с расширением vsv), кото-
рый используется для хранения информации о состоянии виртуальной машины (та-
кой, как данные регистров процессора). Второй файл — двоичный (также назван по
тому же GUID, что и XML-файл, и имеет расширение bin), он используется для хра-
нения содержимого памяти виртуальной машины.
Рис. 5.4. Каталог виртуальной машины и структура файлов

в инсталляции Hyper-V по умолчанию
На рис. 5.4 вы можете видеть, что местоположением по умолчанию для каталога Virtual
Hard Disks является C:\Users\Public\Documents\Microsoft Hyper-V\Virtual Hard Disks, и что ка-
талоги Snapshots и Virtual Machines находятся в C:\ProgramData\Microsoft\Windows\Hyper-V.
Эти каталоги легко изменить в настройках Hyper-V (при помощи консоли Hyper-V Manager).
Однако местоположение каталога Snapshots необходимо изменить до выполнения первого
моментального снимка, поскольку после первого снимка вы уже не сможете этого сделать.
Для виртуальной машины без моментальных снимков все изменения файлов гостевой
операционной системы виртуальной машины, файлы приложений и данные содержатся
на виртуальном жестком диске машины. Информация состояния сохраняется в файлах
с расширениями vsv и bin. Когда вы делаете изменения настроек виртуальной машины,
то эти модификации сохраняются в xml-файле конфигурации.
Создание моментального снимка виртуальной машины

Консоль Hyper-V Manager позволяет вам создавать и просматривать моментальные
снимки виртуальной машины, а также манипулировать ими. Как показано на рис. 5.5,
менеджер Hyper-V Manager имеет панель Snapshots (которая пуста, если виртуальная
машина не имеет моментальных снимков). Для создания моментального снимка в ме-
неджере Hyper-V Manager щелкните правой кнопкой мыши по виртуальной машине и
выберите пункт Snapshot контекстного меню.
Рис. 5.5. Панель Snapshots менеджера Hyper-V Manager
Фактически процесс создания моментального снимка генерирует несколько новых ка-

талогов и файлов, которые содержат информацию виртуальной машины. Как показано
на рис. 5.6, в каталоге Snapshots для виртуальной машины создаются следующие ката-
логи и файлы:
новый каталог с названием по идентификатору GUID виртуальной машины. В этом
каталоге для каждого виртуального жесткого диска виртуальной машины создается
новый автоматический разностный диск. Новый автоматический разностный диск
получает имя по названию исходного виртуального жесткого диска с добавлением
нового GUID и расширения avhd;
копия исходного файла конфигурации виртуальной машины (с названием по ново-
му GUID) с расширением xml;
новый каталог с названием по тому же GUID, что и новый xml-файл. Этот каталог
содержит файлы сохраненного состояния (vsv) и двоичный файл (bin), которые соз-
даются во время выполнения моментального снимка виртуальной машины. Оба
файла получают имя по тому же GUID, что и их каталог.
Кроме того, исходный файл конфигурации виртуальной машины обновляется — на-

звание исходного виртуального жесткого диска заменяется в нем на название нового
автоматического разностного диска.
Рис. 5.6. Файловая структура каталога Snapshots виртуальной машины

после создания первого моментального снимка
Если при создании моментального снимка виртуальная машина находится в автоном-

ном режиме или выключена, то состояние виртуальной машины и содержимое ее па-
мяти сохранять не нужно и эти файлы (vsv и bin) не генерируются. После создания мо-
ментального снимка все изменения данных гостевой операционной системы, приложе-
ний и прочих данных сохраняются в соответствующем автоматическом разностном
диске. Исходный виртуальный диск сохраняется, поскольку он является родителем
автоматического разностного диска (и нужен для возвращения виртуальной машины
в состояние первого моментального снимка).
Как показано на рис. 5.7, для каждого последующего моментального снимка генериру-
ется новый набор каталогов и файлов (для сохранения состояния виртуальной машины
и ее конфигурации). Необходимо отметить, что создаваемые для каждого последующе-
го моментального снимка разностные диски связаны в одну иерархию с исходным вир-
туальным жестким диском, служащим узлом верхнего уровня.
На рис. 5.8 показаны изменения в консоли Hyper-V Manager после двух моментальных
снимков виртуальной машины. В панели Snapshots показана древовидная структура,
которая отражает иерархию моментальных снимков виртуальной машины. Корневой
узел этого дерева — это первый моментальный снимок, который содержит временну́ю
метку момента своего создания. Под корневым узлом есть второй моментальный сни-
мок, а за ним следует объект Now, который представляет собой работающую (актив-
ную) версию виртуальной машины. Иерархия моментальных снимков отражает также
связи между автоматическими разностными дисками (которые создаются для каждого
моментального снимка). В иерархии моментальных снимков при создании нового
снимка активный автоматический разностный диск отключается от виртуальной ма-
шины и становится родителем нового дочернего автоматического разностного диска
Рис. 5.7. Файловая структура каталога Snapshots виртуальной машины после второго снимка
Рис. 5.8. Панель Snapshots в менеджере Hyper-V Manager

после создания моментальных снимков
(который подключается к виртуальной машине). Новый дочерний автоматический раз-

ностный диск записывает изменения файлов операционной системы виртуальной ма-
шины, файлов приложений и данных (до момента выполнения следующего момен-
тального снимка).
По мере того как вы производите изменения в конфигурации виртуальной машины, вы
можете создать и сохранить множество моментальных снимков. Например, если вы
хотите загрузить и протестировать на данной виртуальной машине несколько прило-
жений, то можете загрузить одно приложение, протестировать его и сделать момен-
тальный снимок виртуальной машины перед тем, как начать тестировать следующее
приложение.
ВАЖНО
Существует предельное количество моментальных снимков на одну виртуальную маши-
ну — 50 штук. Если вы попытаетесь создать моментальный снимок сверх этого количества,
то получите сообщение о том, что создать его не удалось.
Если вы щелкнете правой кнопкой мыши по той виртуальной машине, у которой есть
один или несколько моментальных снимков, то в контекстном меню появится пункт
Revert, который позволит вам быстро вернуться к предыдущему состоянию виртуаль-
ной машины.
Если вы щелкнете правой кнопкой мыши моментальный снимок в менеджере Hyper-V
Manager, то получите несколько вариантов, в том числе:
Settings — открывает диалоговое окно настроек виртуальной машины и позволяет
просмотреть конфигурацию виртуальной машины на момент создания моменталь-
ного снимка. Настройки оборудования и управления изменить нельзя (за исключе-
нием названия моментального снимка и соответствующего ему примечания);
Apply — изменяет состояние активной виртуальной машины в состояние выбран-
ного моментального снимка;
Rename — редактирование названия моментального снимка (отображаемого в па-
нели Snapshots менеджера Hyper-V Manager);
Delete Snapshot — удаляет файлы выбранного моментального снимка (за исключе-
нием автоматического разностного диска, если он является родителем другого ав-
томатического разностного диска в иерархии моментальных снимков). Автоматиче-
ский разностный диск, может, понадобится слить с дочерним разностным диском
(чтобы активная виртуальная машина или следующий моментальный снимок могли
поддерживать состояние данных). Автоматические разностные диски объединяются
при следующем выключении виртуальной машины;
Delete Snapshot Subtree — удаляет выбранный моментальный снимок и все сним-
ки, которые находятся в иерархии ниже него.
Все эти функции более подробно обсуждаются в последующих разделах.
Если для создания моментальных снимков виртуальных машин вы используете консоль
Hyper-V Manager, то сервер Hyper-V будет автоматически генерировать название момен-
тального снимка (по имени виртуальной машины с добавлением временной метки создания
моментального снимка). Приложение Virtual Machine Connection также имеет пункт меню
для выполнения моментального снимка виртуальной машины. Если вы используете этот
вариант для создания моментального снимка, то появится диалоговое окно с запросом на-
звания для нового снимка.
Возвращение к состоянию
предыдущего моментального снимка
Если после выполнения изменений в виртуальной машине вы решите, что вам необхо-
димо вернуться к состоянию предыдущего моментального снимка, то в Hyper-V для
выполнения такого действия имеется опция Revert. После использования действия
Revert конфигурация и состояние виртуальной машины возвращаются к настройкам,
сохраненным в моментальном снимке, предыдущем в иерархии моментальных сним-
ков. Это значит, что любые изменения конфигурации, сделанные после выполнения
моментального снимка (в том числе такие, как модификация виртуального оборудова-
ния — памяти, количества процессоров, адаптеров виртуальных жестких дисков и т. д.)
будут утеряны.
Когда выполняется опция Revert, то работающая виртуальная машина останавливается
и активный разностный диск (avhd) удаляется. Создается новый разностный диск, ко-
торый получает название с новым GUID. Восстанавливается сохраненная при выпол-
нении моментального снимка конфигурация виртуальной машины и обновляется на-
звание активного разностного диска. Затем виртуальная машина запускается и загру-
жаются файлы сохраненного состояния (vsv и bin). Если моментальный снимок был
создан при выключенной виртуальной машине, тогда этих файлов нет, и виртуальная
машина остается выключенной.
ВАЖНО
При выполнении опции Revert иерархия моментальных снимков не изменяется. Этого и
следует ожидать, поскольку во время этой операции никакие моментальные снимки не из-
меняются. Однако повторное использование опции Revert будет опять сбрасывать вирту-
альную машину в состояние того моментального снимка, который непосредственно пред-
шествует активной виртуальной машине. То есть опция Revert является средством изме-
нения состояния на один уровень. Ее нельзя использовать для того, чтобы перемешаться
вверх по иерархии моментальных снимков (с целью восстановления предыдущих состоя-
ний виртуальной машины).
Использование опции Apply Snapshot

Для изменения состояния активной виртуальной машины в состояние того моменталь-
ного снимка, который находится более чем на один уровень выше в иерархии момен-
тальных снимков, вы должны щелкнуть по этому моментальному снимку правой кноп-
кой мыши в менеджере Hyper-V Manager и выбрать пункт Apply контекстного меню
(рис. 5.9).
На рис. 5.10 показано диалоговое окно, которое перед выполнением операции Apply
предлагает вам создать моментальный снимок активной виртуальной машины (либо вы
можете продолжить без сохранения текущей конфигурации и состояния). Как и в слу-
чае опции Revert, если вы не сделаете моментального снимка до операции Apply, то

конфигурация и состояние работающей виртуальной машины будут потеряны.
Рис. 5.9. Выбор пункта Apply в консоли Hyper-V Manager
Рис. 5.10. Запрос в консоли Hyper-V Manager после выбора опции Apply
Действие Apply аналогично действию Revert. Активная виртуальная машина останав-

ливается, автоматический разностный диск удаляется и создается новый автоматиче-
ский разностный диск. Восстанавливается конфигурация виртуальной машины из мо-
ментального снимка, в конфигурационном файле виртуальной машины обновляется
название автоматического разностного диска. Затем виртуальная машина запускается и
загружаются файлы сохраненного состояния (vsv и bin).
Как показано на рис. 5.11, маркер Now переместился вверх под использованный мо-
ментальный снимок, чтобы показать, что активная виртуальная машина основана
именно на нем.
Рис. 5.11. Консоль Hyper-V Manager показывает положение маркера после действия Apply
Рис. 5.12. Консоль Hyper-V Manager показывает новое поддерево моментальных снимков
Если в этот момент будет создан новый моментальный снимок, то он создаст новое
поддерево в иерархии моментальных снимков (рис. 5.12).
Использование опции Delete Snapshot

Если вы решите, что моментальный снимок вам больше не нужен, то Hyper-V имеет
опцию Delete Snapshot для удаления единичного моментального снимка из иерархии.
Для удаления одного моментального снимка щелкните по нему правой кнопкой мыши
в консоли Hyper-V Manager и выберите пункт Delete Snapshot контекстного меню.
Удаление одного моментального снимка не повлияет на другие моментальные снимки,
но удалит также и связанные с данным снимком файлы конфигурации и сохраненного
состояния. Если вы помните, то в иерархии моментальных снимков автоматические
разностные диски связаны друг с другом отношениями "родитель→потомок". Поэтому
автоматический разностный диск моментального снимка немедленно удаляется только
в том случае, если он не является родителем для дочернего автоматического разност-
ного диска. Если имеется только один дочерний автоматический разностный диск, то
он вливается в родительский автоматический разностный диск при следующем выклю-
чении виртуальной машины. Если родительский автоматический разностный диск
имеет много дочерних, тогда он сохраняется до тех пор, пока у него не останется толь-
ко один дочерний автоматический разностный диск. Этот дочерний автоматический
разностный диск вливается в родительский автоматический разностный диск при сле-
дующем выключении виртуальной машины.
Использование опции Delete Snapshot Subtree

Удаление поддерева моментальных снимков немедленно удаляет файлы и конфигура-
ции, и сохраненного состояния, связанные со всеми моментальными снимками подде-
рева. Если автоматический разностный диск активной виртуальной машины не являет-
ся дочерним диском ни для одного моментального снимка поддерева, тогда все авто-
матические разностные диски поддерева также удаляются. Если автоматический
разностный диск активной виртуальной машины зависит от цепочки автоматических
разностных дисков из удаляемого поддерева, то эта цепочка дисков будет объединена в
автоматический разностный диск, находящийся на один уровень выше удаляемого
поддерева (при следующем выключении виртуальной машины).
Использование функций Integration Services

В виртуализированной среде процессы, которым требуется интерфейс между роди-
тельским и дочерним разделами, должны реализовывать его таким образом, чтобы не
нарушать изоляцию ресурсов и безопасную работу обоих разделов. В Hyper-V службы
интеграции Integration Services (IS) предоставляют поддержку для пяти уникальных
компонентов, которым требуется безопасный интерфейс между родительским и дочер-
ним разделами. Вот эти компоненты:
служба синхронизации времени;
служба тактовых импульсов;
служба завершения работы;

служба обмена парами "ключ/значение";
служба теневого копирования Volume Shadow Copy Service (VSS).
Службы IS в Hyper-V доступны в дочернем разделе после инсталляции их в поддержи-
ваемой гостевой операционной системе. Службы IS ведут обмен с компонентами стека
виртуализации родительского раздела (которые реализованы как виртуальные устрой-
ства (VDEV)). Обмен между компонентами родительского и дочернего разделов про-
исходит по шине VMBus сервера Hyper-V. Шина VMBus поддерживает высокоскоро-
стные каналы "точка — точка" для безопасного обмена между разделами, что улучшает
производительность виртуальных машин. Каждой функцией служб интеграции роди-
тельского раздела управляет отдельный выделенный VDEV. Соответственно, каждой
функцией служб интеграции дочернего раздела управляет отдельная выделенная
служба.
Дополнительную информацию об архитектуре служб интеграции Hyper-V см. в главе 3.
Службы интеграции предназначены для очень специфических областей применения

(для улучшения функциональности или управления поддерживаемыми гостевыми опе-
рационными системами). Важно отметить, что для некоторых устаревших гостевых
операционных систем (или систем не из семейства Windows) может поддерживаться
только некоторое подмножество компонентов интеграции. Например, поскольку VSS
поддерживается только в операционных системах Windows семейства Windows Server
2003, то компонент интеграции VSS будет недоступен для Windows 2000 Server,
Windows XP или для поддерживаемых версий Linux.
Служба синхронизации времени

Работающая непосредственно на физическом сервере операционная система для под-
держания точного времени обычно использует целую комбинацию оборудования и се-
тевых протоколов. В Hyper-V службы интеграции предоставляют альтернативное та-
кому подходу решение и позволяют использовать родительский раздел в качестве на-
дежного источника синхронизации времени (для работающих в дочерних разделах
виртуальных машин). В частности, синхронизация времени (из служб интеграции) вы-
полняет две конкретные задачи:
поддерживает синхронизацию времени гостевой операционной системы (для учета
ухода времени в виртуальной машине);
восстановление виртуальной машины из моментального снимка или сохраненного
состояния (когда с момента последней синхронизации времени гостевой операци-
онной системы прошло много времени).
Синхронизация времени по родительскому разделу дает возможность решить следую-
щие проблемы:
отсутствие подключения к сети (что делает неприменимыми традиционные сетевые
протоколы);
необходимость в более быстрой синхронизации времени, чем могут обеспечить се-

тевые протоколы (для того, чтобы виртуальная машина могла быстро стартовать
после восстановления сохраненного состояния или моментального снимка);
необходимость произвести успешную синхронизацию времени в случае прохожде-
ния значительного количества времени после того, как виртуальная машина была в
последний раз в активном состоянии (после восстановления сохраненного состоя-
ния или моментального снимка).
В последнем случае стандартный сетевой протокол мог бы и не синхронизировать
время, поскольку максимально допустимая разница по времени в этих случаях часто
бывает превышена (не только для моментальных снимков, но и для сохраненных со-
стояний).
Служба тактовых импульсов

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

Для того чтобы чисто завершить работу виртуальной машины без непосредственного
взаимодействия с гостевой операционной системой (через подключение к виртуальной
машине или сеанс протокола RDP), службы интеграции предоставляют функцию за-
вершения работы виртуальной машины. Запрос на завершение работы инициируется из
родительского раздела к дочернему разделу при помощи вызова Windows Management
Instrumentation (WMI).
Служба обмена парами "ключ/значение"

Целью функции обмена парами "ключ/значение" (имеющейся в службах интеграции)
является предоставление средства для настройки, удаления и перечисления специфиче-
ской информации о виртуальной машине и конфигурации гостевой операционной сис-
темы. Таким образом, родительский раздел может установить определенные значения
данных в гостевой операционной системе или извлечь данные для предоставления их
инструментам управления сторонних разработчиков.
Данные пар "ключ/значение" хранятся в следующих разделах реестров гостевых опе-
рационных систем:
HKLM\Software\Microsoft\Virtual Machine\Auto;
HKLM\Software\Microsoft\Virtual Machine\External;
HKLM\Software\Microsoft\Virtual Machine\Guest\Parameters.
По умолчанию дочерний раздел предоставляет в родительский раздел (по запросу) со-

храненные в HKLM\Software\Microsoft\Virtual Machine\Auto данные. В табл. 5.4 пере-
числена содержащаяся в этом разделе реестра информация.
Таблица 5.4. Параметры реестра в \Software\Microsoft\Virtual Machine\Auto
Параметр Описание
OSMajorVersion Основная часть номера версии гостевой операционной системы

OSMinorVersion Вспомогательная часть номера версии гостевой операционной системы
OSBuildNumber Номер сборки гостевой операционной системы
OSVersion Версия гостевой операционной системы (например, 5.0.2195)
OSPlatformId Платформа гостевой операционной системы (Win9x, NT4 или более
новая)
CSDVersion Самый новый пакет обновлений, установленный в гостевой операцион-
ной системе
ServicePackMajor Основная часть номера версии самого нового пакета обновлений,
установленного в гостевой операционной системе
ServicePackMinor Вспомогательная часть номера версии самого нового пакета обновле-
ний, установленного в гостевой операционной системе
SuiteMask Имеющиеся в системе наборы пакетов
ProductType Тип инсталлированного в системе продукта (рабочая станция, сервер,
контроллер домена)
OSName Название из ключа HKLM\Software\Microsoft\Windows
NT\CurrentVersion\ProductName
ProcessorArchitecture Идентификатор архитектуры процессора (Intel, Itanium, AMD, неизвест-
ный)
FullyQualifiedDomainName Полное имя DNS, которое уникально идентифицирует гостевую опера-
ционную систему. Это имя является комбинацией DNS-имени хоста и
DNS-имени домена. Если это узел кластера, тогда это полное DNS-имя
виртуального сервера кластера
Если гостевая операционная система в дочернем разделе имеет информацию

"ключ/значение", которую необходимо использовать совместно с родительским разде-
лом, то она будет расположена в разделе реестра HKLM\Software\Microsoft\Virtual
Machine\External.
Родительский раздел предоставляет дочернему разделу значения в HKLM\Software
\Microsoft\Virtual Machine\Guest\Parameters. В табл. 5.5 перечислена информация, со-
держащаяся в этом разделе реестра.
Таблица 5.5. Параметры реестра

в HKLM\Software\Microsoft\Virtual Machine\Guest\Parameters
HostName DNS-имя, установленное в операционной системе родительского

раздела. Если система является узлом кластера, тогда это DNS-
имя виртуального сервера кластера
PhysicalHostName Имя, установленное в операционной системе родительского раз-

дела
PhysicalHostNameFullyQualified Полное имя, установленное в операционной системе родитель-

ского раздела
VirtualMachineName Имя виртуальной машины, используемое в стеке виртуализации
Служба теневого копирования

Volume Shadow Copy Service (VSS)
Для поддерживающих VSS операционных систем службы интеграции позволяют роди-
тельскому разделу запрашивать синхронизацию и "успокоение" (quiescence) работаю-
щей в дочернем разделе виртуальной машины. Если VSS поддерживают все гостевые
операционные системы, то можно сделать резервную копию всего сервера Hyper-V (и в
том числе всех виртуальных машин (и автономных, и работающих)) при помощи мо-
ментального снимка VSS.
Дополнительную информацию относительно VSS и имеющихся вариантов выполнения ре-
зервных копий на уровне хоста Hyper-V и виртуальных машин см. в главе 13.
Поддерживающие службы интеграции

гостевые операционные системы
Как упоминалось ранее, на устаревших операционных системах Windows и дистрибу-
тивах Linux может быть инсталлировано только некоторое подмножество компонентов
служб интеграции Integration Services. В табл. 5.6 приведена матрица служб интеграции
для поддерживаемых в Hyper-V гостевых операционных систем.
Таблица 5.6. Матрица поддержки службами интеграции

гостевых операционных систем
Key/value
Time
Операционная система Heartbeat Shutdown pair VSS
Synchronization
exchange
Windows Server 2008 x64 Да Да Да Да Да
Windows Server 2008 x86 Да Да Да Да Да
Windows Server 2003 x64 SP2 Да Да Да Да Да
Windows Server 2003 x86 SP2 Да Да Да Да Да
Windows 2000 Server SP4 Да Да Да Да Нет
Windows 2000 Advanced Да Да Да Да Нет

Server SP4
Key/value
Time
Операционная система Heartbeat Shutdown pair VSS
Synchronization
exchange
Windows Vista x64 SP1 Да Да Да Да Да
Windows Vista x86 SP1 Да Да Да Да Да
Windows XP x86 SP2 Да Да Да Да Нет

или SP3
Windows XP x64 SP2 Да Да Да Да Нет
SUSE Linux Enterprise Нет Нет Нет Нет Нет

Server 10 x64
SUSE Linux Enterprise Нет Нет Нет Нет Нет

Server 10 x86
Использование расширенных функций

виртуальной сети
Сетевая архитектура Hyper-V позволяет изолировать сетевой трафик виртуальной ма-
шины от других виртуальных машин, сервера Hyper-V и внешних сетей. Она также
позволяет виртуальным машинам подключаться друг к другу, серверу Hyper-V, корпо-
ративным сетям и Интернету. Имеется много опций конфигурирования, причем неко-
торые из них зависят от реализации расширенных сетевых настроек.
Движение виртуального сетевого трафика

В Hyper-V существуют три основных типа виртуальных сетей: внешние, внутренние и
частные. Когда вы создаете внешнюю виртуальную сеть, то вы можете подключить к
ней ту виртуальную машину, которой требуется доступ к вашей корпоративной сети
или к Интернету. Внутренняя сеть позволяет виртуальным машинам вести обмен с сер-
вером Hyper-V и другими виртуальными машинами, которые подключены к ней, но не
дает доступа к внешним физическим сетям. Частная сеть позволяет подключенным
к ней виртуальным машинам вести обмен только друг с другом.
Как показано на рис. 5.13, окно Network Connections сервера Hyper-V (т. е. родитель-
ского раздела) до создания первой виртуальной сети содержит только инсталлирован-
ные в физический компьютер сетевые адаптеры. Более того, свойства физического се-
тевого адаптера показывают, что к нему привязаны элементы по умолчанию и что име-
ется дополнительный протокол Microsoft Virtual Network Switch Protocol (который не
привязан к сетевому адаптеру).
В окне Device Manager (рис. 5.14) есть только физические сетевые адаптеры (чего и
следовало ожидать).
Рис. 5.13. Окно Network Connections родительского раздела Hyper-V (без виртуальных сетей)
Рис. 5.14. Окно Device Manager родительского раздела Hyper-V (без виртуальных сетевых адаптеров)
Внешняя виртуальная сеть

Когда вы создаете внешнюю виртуальную сеть, то Hyper-V создает в родительском
разделе два новых компонента (рис. 5.15). Первый компонент — это программный
(виртуальный) сетевой коммутатор с возможностью динамического добавления и уда-
ления сетевых портов. Сетевые порты добавляются в виртуальный сетевой коммутатор
по мере подключения виртуальных машин к соответствующей виртуальной сети
(и удаляются при отключении виртуальных машин от этой виртуальной сети). Второй
компонент — это виртуальный сетевой адаптер, который подключается к виртуально-
му сетевому коммутатору и позволяет родительскому разделу напрямую обмениваться
с этой виртуальной сетью.
Рис. 5.15. Сетевая конфигурация Hyper-V для внешней виртуальной сети
Виртуальный сетевой адаптер появляется в окне Network Connections как новый ком-
понент (в данном случае это Local Area Connection 2), как показано на рис. 5.16. Кро-
ме того, изучение его свойств показывает, что к сетевому адаптеру привязаны некото-
рые элементы по умолчанию.
Как показано на рис. 5.17, физический сетевой адаптер был перенастроен (убраны все
привязки по умолчанию и теперь к нему привязан только протокол Microsoft Virtual
Network Switch Protocol).
Рис. 5.16. Свойства виртуального сетевого адаптера родительского раздела

(для внешней виртуальной сети)
Рис. 5.17. Свойства физического сетевого адаптера родительского раздела

Теперь в окне Device Manager виден виртуальный сетевой адаптер, а описание устрой-
ства в его свойствах показывает, что это адаптер Microsoft Virtual Network Switch
(рис. 5.18).
Рис. 5.18. Свойства виртуального сетевого адаптера в окне Device Manager

Когда виртуальная машина в дочернем разделе должна выполнить обмен по внешней

виртуальной сети, то трафик идет следующим образом:
1. Данные посылаются через сетевой стек гостевой операционной системы, привязан-
ный к виртуальному сетевому адаптеру виртуальной машины (если имеется только
один виртуальный сетевой адаптер, как на рис. 5.15).
2. В случае синтетического сетевого адаптера данные посылаются на виртуальный се-
тевой коммутатор родительского раздела через VMBus. В случае обычного сетевого
адаптера гипервизор Windows перехватывает запрос и дает указание стеку виртуа-
лизации родительского раздела извлечь данные из предварительно настроенного
буфера памяти (которые затем посылаются стеком в виртуальный сетевой комму-
татор).
3. Виртуальный сетевой коммутатор определяет, как направить данные к их назна-
чению.
4. Если назначением данных является внешнее устройство на физической сети, то
виртуальный сетевой коммутатор посылает данные физическому сетевому адаптеру
(привязанному к внешней виртуальной сети), который передает данные по физи-

ческой сети.
5. Если назначением данных является родительский раздел, то виртуальный сетевой
коммутатор посылает данные в тот сетевой порт, к которому подключен виртуаль-
ный сетевой адаптер родительского раздела.
6. Предназначенные виртуальной машине возвращаемые данные следуют по тому же
самому пути в обратном порядке.
Если сервер Hyper-V имеет только один физический сетевой адаптер, то все данные
к месту назначения на физической сети принудительно проходят через виртуальный
сетевой коммутатор. Как показано на рис. 5.15, рекомендуется установить на сервере
Hyper-V по крайней мере два физических сетевых адаптера и зарезервировать один из
них для использования исключительно сервером Hyper-V.
Может случиться так, что сетевой трафик от родительского раздела к месту назначения на
внешней физической сети пойдет через виртуальный сетевой коммутатор (вместо того,
чтобы идти напрямую через выделенный физический сетевой адаптер). Однако так будет
только до того момента, пока сетевые алгоритмы родительского раздела не вычислят мар-
шрут наименьшей стоимости до физической сети.
Внутренняя виртуальная сеть

При создании внутренней виртуальной сети Hyper-V так же создают виртуальный се-
тевой коммутатор и виртуальный сетевой адаптер в родительском разделе (рис. 5.19).
Однако в этом сценарии виртуальный сетевой коммутатор не подключен ни к одному
установленному в сервере Hyper-V физическому сетевому адаптеру. Это ограничивает
обмен по сети только сервером Hyper-V и подключенными к внутренней сети вирту-
альными машинами. Внутренний сетевой трафик никогда не передается по физической
сети.
Виртуальный сетевой адаптер появляется в окне Network Connections как новый ком-
понент (в данном случае это Local Area Connection 3), как показано на рис. 5.20. Ана-
логично случаю внешней виртуальной сети, изучение его свойств показывает, что
к виртуальному сетевому адаптеру привязаны все элементы по умолчанию.
В варианте внутренней виртуальной сети конфигурация физического сетевого адаптера
остается неизменной (рис. 5.21) и сохраняются все привязки по умолчанию.
В окне Device Manager (рис. 5.22) виртуальный сетевой адаптер также виден, и описа-
ние устройства в его свойствах говорит, что это адаптер Microsoft Virtual Network
Switch.
Когда виртуальной машине из дочернего раздела необходимо выполнить обмен через
внутреннюю виртуальную сеть, то сетевой трафик проходит следующим образом:
1. Данные посылаются через сетевой стек гостевой операционной системы (привязан-
ный к виртуальному сетевому адаптеру виртуальной машины).

буфера памяти (которые затем посылаются стеком в виртуальный сетевой комму-
татор).
3. Виртуальный сетевой коммутатор определяет, как направить данные по их назна-
чению.
4. Если назначением данных является другая виртуальная машина, то виртуальный се-
тевой коммутатор посылает данные в тот сетевой порт, к которому подключена
нужная виртуальная машина, и передает данные по отдельному подключению ши-
ны VMBus (либо с помощью гипервизора Windows) к эмулированному сетевому
адаптеру в виртуальной машине назначения.
5. Если назначением данных является родительский раздел, то виртуальный сетевой
коммутатор посылает данные в тот сетевой порт, к которому подключен виртуаль-
ный сетевой адаптер родительского раздела.
Рис. 5.19. Сетевая конфигурация Hyper-V для внутренней виртуальной сети

Рис. 5.20. Свойства виртуального сетевого адаптера родительского раздела

(для внутренней виртуальной сети)
Рис. 5.21. Свойства физического сетевого адаптера родительского раздела

Рис. 5.22. Свойства виртуального сетевого адаптера в окне Device Manager

Между родительским разделом и каждой виртуальной машиной, подключенной через син-
тетический сетевой адаптер, существует отдельное, безопасное и изолированное подклю-
чение через VMBus. За подробной информацией по архитектуре VMBus обращайтесь
к главе 3.
Частная виртуальная сеть

При создании частной виртуальной сети Hyper-V создает в родительском разделе толь-
ко виртуальный сетевой коммутатор (рис. 5.23). Поэтому сетевой обмен ограничивает-
ся только подключенными к виртуальной частной сети виртуальными машинами. Сер-
вер Hyper-V не может передавать по частной виртуальной сети никаких данных.
В случае частной виртуальной сети на рис. 5.24 видно, что конфигурация физического
сетевого адаптера остается неизменной и сохраняются все привязки по умолчанию.
В окне Device Manager (рис. 5.25) перечислены только физические сетевые адаптеры.
Когда виртуальной машине из дочернего раздела необходимо произвести обмен по
частной виртуальной сети, то сетевой трафик идет следующим образом:
1. Данные посылаются через сетевой стек гостевой операционной системы (привязан-
ный к виртуальному сетевому адаптеру виртуальной машины).
Рис. 5.23. Сетевая конфигурация Hyper-V для частной виртуальной сети

буфера памяти (которые затем посылаются стеком в виртуальный сетевой коммута-
тор).
3. Виртуальный сетевой коммутатор определяет, как направить данные к виртуальной
машине назначения. Они либо посылаются в тот сетевой порт виртуального сетево-
го коммутатора, к которому подключена нужная виртуальная машина (и передаются
по отдельному подключению шины VMBus), либо передаются с помощью гиперви-
зора Windows эмулированному сетевому адаптеру в виртуальной машине назначе-
ния.
ВАЖНО
Поскольку виртуальный сетевой коммутатор Hyper-V работает на уровне Layer 2 модели
Open Systems Interconnection (OSI), то маршрутизировать сетевой трафик он не может.
Если требуется IP-маршрутизация между виртуальными сетями (уровень Layer 3 модели
OSI), то вы должны реализовать в виртуальной машине программный маршрутизатор (на-
пример, сервер Internet Security & Acceleration Server 2006).
Рис. 5.24. Свойства физического сетевого адаптера родительского раздела (для частной виртуальной сети)
Рис. 5.25. Диалоговое окно Device Manager (для частной виртуальной сети)
Виртуальные локальные сети

Сервер Windows Server 2008 Hyper-V предоставляет поддержку Virtual LAN (VLAN)
как в родительском (сервер Hyper-V), так и в дочерних разделах (виртуальные маши-
ны). Институт Institute of Electrical and Electronics Engineers (IEEE) в стандарте 802.1Q
определил тегирование VLAN для передачи трафика нескольких сетей по одному фи-
зическому сетевому подключению. Каждый сетевой поток виртуально изолирован от
других, так что компьютеры на разных сетях VLAN не могут видеть пакеты чужой сети
(если только между VLAN не реализована маршрутизация). На рис. 5.26 показано, что
единственная физическая сетевая магистраль может передавать сетевые данные не-
скольких VLAN (а также и другие данные). Это называется транкингом. На схеме по-
казано, что пакеты разных VLAN являются частью единого сетевого потока трафика, и
только сервер, который является членом VLAN, может видеть те пакеты, которые по-
мечены как предназначенные для этой VLAN. Не являющийся членом VLAN сервер не
может видеть те пакеты, которые предназначены для данной VLAN.
Рис. 5.26. Транкинг VLAN
Для реализации VLAN существуют два различных метода. Первый метод — статиче-
ское конфигурирование VLAN на уровне портов сетевого коммутатора. При такой
конфигурации вы присваиваете порт коммутатора данной VLAN, после чего весь про-
ходящий через него трафик помечается идентификационным номером (VLAN ID) дан-
ной VLAN. Этот метод не позволяет подключенному к порту устройству изменять зна-
чение VLAN ID. Однако если устройство перемещается с одного порта сетевого ком-
мутатора на другой порт, то новый порт также необходимо настроить для конкретной
VLAN. Этот метод также не позволяет нескольким подключенным к одному порту се-
тевого коммутатора устройствам быть членами разных VLAN.
Второй метод требует, чтобы подключенное к сетевому порту устройство динамически
присваивало VLAN ID (перед передачей пакета). При таком методе устройство может
легко перемещаться из одной VLAN в другую (без необходимости менять конфигура-
цию портов сетевого коммутатора). Однако этот метод требует, чтобы устройство пол-
ностью поддерживало тегирование VLAN по стандарту IEEE 802.1Q. Устройство
должно уметь тегировать пакет, передать тегированный пакет и открыть тегированный
пакет.
Первый метод (статическая конфигурация VLAN) более безопасен, чем динамическое
тегирование VLAN, поскольку сетевое устройство не может легко поменять сеть
VLAN без смены порта сетевого коммутатора (а сетевые коммутаторы обычно распо-
ложены в охраняемых помещениях).
Вот список требований для поддержки тегирования VLAN (статического или динами-
ческого) в сложных сетевых средах:
сервер Hyper-V должен иметь физические сетевые адаптеры с поддержкой IEEE
802.1Q. Для динамического тегирования физические сетевые адаптеры должны
поддерживать тегированные пакеты даже в том случае, если драйвер не настроен на
поддержку VLAN;
сетевые коммутаторы должны иметь поддержку IEEE 802.1Q;
сетевые маршрутизаторы должны иметь поддержку IEEE 802.1Q для маршрутиза-
ции тегированных пакетов.
Настройка родительского раздела для использования VLAN

Родительский раздел Hyper-V можно сделать членом VLAN. Обычно это делается для
изоляции сетевого трафика управления сервером Hyper-V от сетевого трафика дочер-
них разделов. В случае непривязанного к внешней виртуальной сети физического сете-
вого адаптера конфигурирование VLAN ID производится в настройках Advanced сете-
вого драйвера (рис. 5.27). По умолчанию VLAN ID установлен в ноль. Изменение этой
настройки приведет к тегированию всех пакетов из родительского раздела (которые
идут через данный физический сетевой адаптер) новым значением VLAN ID.
Если физический сетевой адаптер подключен к внешней виртуальной сети, то конфи-
гурирование VLAN ID можно выполнить при помощи Virtual Network Manager (в кон-
соли Hyper-V Manager). Для конфигурирования VLAN ID при помощи менеджера
Virtual Network Manager выполните следующие шаги:
2. В панели Actions под названием сервера щелкните по пункту Virtual Network
Manager.
3. В менеджере Virtual Network Manager выберите целевую сеть External Network из
списка Virtual Networks в левой панели.
4. В правой панели под Virtual Network Properties выберите Enable Virtual LAN
Identification For Parent Partition.
Рис. 5.27. Конфигурирование идентификатора VLAN ID в драйвере физического сетевого адаптера
5. В текстовом поле VLAN ID введите значение VLAN ID.

6. Нажмите кнопку OK для применения сделанных изменений.
После изменения VLAN ID весь трафик родительского раздела (который идет через
выбранный сетевой адаптер) будет помечаться идентификатором VLAN ID.
Вы можете также изменить настройки внутренней виртуальной сети, чтобы разрешить
тегирование VLAN в родительском разделе. Этот процесс идентичен использованным
для конфигурации VLAN ID шагам, за исключением того, что вы должны выбрать це-
левую внутреннюю виртуальную сеть в окне Virtual Network Manager.
Частные виртуальные сети не поддерживают тегирование VLAN.
Конфигурирование дочернего раздела для использования VLAN

Дочерние разделы (виртуальные машины) также поддерживают тегирование VLAN.
Конфигурирование идентификатора VLAN ID должно выполняться индивидуально для
каждого целевого виртуального сетевого адаптера, инсталлированного в виртуальной
машине. Это позволяет вам подключить одну виртуальную машину к нескольким
VLAN. Поскольку виртуальная машина может иметь максимум 12 виртуальных сете-
вых адаптеров (8 синтетических и 4 обычных), то она может быть подключена одно-
временно максимум к 12 сетям VLAN.
Для конфигурирования VLAN ID на виртуальном сетевом адаптере виртуальной ма-

шины выполните следующие шаги:
2. Щелкните правой кнопкой мыши по виртуальной машине и выберите пункт Settings
контекстного меню.
3. В диалоговом окне Settings выберите целевой сетевой адаптер.
4. В правой панели под Network Adapter выберите Enable Virtual LAN Identification.
5. В текстовом поле VLAN ID введите значение идентификатора VLAN ID.
6. Нажмите кнопку OK для применения сделанных вами изменений.
После того как вы измените VLAN ID, весь трафик дочернего раздела (который прохо-
дит через выбранный виртуальный сетевой адаптер) будет помечаться идентификато-
ром VLAN ID.
Если у вас есть необходимость для виртуальной машины обмениваться с двумя или
более VLAN, то нужно просто сконфигурировать в дочернем разделе дополнительные
виртуальные сетевые адаптеры, присвоить им идентификаторы VLAN ID, настроить
соответствующие адреса IP, а затем убедиться, что трафик данной VLAN использует
правильный адрес IP или имя цели (чтобы трафик шел через правильный виртуальный
сетевой адаптер).
Использование VLAN для настройки изолированного тестирования

VLAN может дать определенные преимущества для настройки сценариев изолирован-
ного тестирования. Например, предположим, что у вас есть два сервера Hyper-V, под-
ключенные к одному сетевому коммутатору, и вам нужно настроить такой сценарий,
в котором для выявления проблемы требуется наличие службы типа DHCP. Более того,
для правильного исследования проблемы требуется, чтобы виртуальные машины раз-
ных серверов Hyper-V обменивались друг с другом по сети. Конфигурирование VLAN
для изоляции сетевого трафика может помочь избежать следующих проблем:
наличия на сети конкурирующих служб DHCP;
настройки тестовой конфигурации на одном сервере Hyper-V (во избежание про-
блем со службой DHCP);
сложных тестовых конфигураций для выполнения тестов (добавления дополнитель-
ного сетевого адаптера в каждый сервер Hyper-V, подключения серверов Hyper-V
к изолированному сетевому коммутатору, настройки новой виртуальной сети, кон-
фигурирования виртуальных машин для использования новой виртуальной сети).
Тегирование VLAN при таком сценарии — это отличное решение для изоляции сетево-
го трафика виртуальных машин. Все, что требуется, — сконфигурировать все вирту-
альные машины (необходимые для тестирования) на подключение к внешней вирту-
альной сети и настроить на каждом виртуальном сетевом адаптере один и тот же иден-
тификатор VLAN. Это позволит вам изолировать подсеть двух серверов (только
машины с одинаковым идентификатором VLAN будут видеть сетевой трафик и смогут
обмениваться друг с другом).
Пулы MAC-адресов
Сервер Hyper-V позволяет присвоить виртуальному сетевому адаптеру либо статиче-
ский, либо динамический адрес Media Access Control (MAC). Статический МАС-
адрес — это тот, который администратор Hyper-V присваивает виртуальной машине.
Динамический МАС-адрес — это тот, который Hyper-V автоматически присваивает из
своего пула МАС-адресов. После присваивания динамического МАС-адреса он не ме-
няется.
При инсталляции Hyper-V пул МАС-адресов создается и сохраняется в реестре в
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Virtualization. Он хранится как
диапазон из 256 значений, определенный двумя значениями ключей реестра:
MinimumMacAddress и MaximumMacAddress.
МАС-адрес состоит из двух частей: идентификатора изготовителя оборудования
(OEM) и уникального значения. Для того чтобы выдавать правильные МАС-адреса,
компания Microsoft зарегистрировалась и получила собственный идентификатор ОЕМ
(00-15-5d); поэтому все диапазоны МАС-адресов в Hyper-V начинаются этими тремя
октетами. Следующие два октета генерируются путем преобразования последних двух
октетов IP-адреса первого физического (установленного в сервер Hyper-V) сетевого
адаптера в шестнадцатеричные значения. Например, если IP-адрес первого физическо-
го сетевого адаптера был 192.168.0.97, то последние два октета 0.97 превращаются в
00-61 и используются как следующие два октета МАС-адреса. Таким образом, мы по-
лучаем первые пять октетов: 00-15-5d-00-61. Для того чтобы получить диапазон в
256 адресов, последний октет принимает диапазон от MinimumMacAddress со значени-
ем 00 до MaximumMacAddress со значением FF. Как показано на рис. 5.28, пул МАС-
адресов для этого примера имеет диапазон от 00-15-5d-00-61-00 до 00-15-5d-0061-ff.
Рис. 5.28. Диапазон МАС-адресов в реестре сервера Hyper-V
При первом включении виртуальной машины (если она сконфигурирована для исполь-
зования динамического МАС-адреса) ей присваивается следующее доступное значение
из диапазона пула МАС-адресов. Если виртуальная машина имеет несколько виртуаль-
ных сетевых адаптеров, то каждый адаптер получает МАС-адрес из пула. Кроме того,
когда генерируется внешняя или внутренняя виртуальная сеть, то создаваемый в роди-
тельском разделе виртуальный сетевой адаптер также получает МАС-адрес из пула

адресов сервера Hyper-V.
По умолчанию на сервере Hyper-V может быть всего 256 устройств с присвоенными
им динамическими МАС-адресами. Это может быть либо 256 виртуальных машин
с одним виртуальным сетевым адаптером, либо 128 виртуальных машин с двумя вир-
туальными сетевыми адаптерами, либо 126 виртуальных машин с двумя виртуальными
сетевыми адаптерами и четыре внутренние виртуальные сети, либо любая другая ком-
бинация с максимальным количеством 256 устройств.
По мере присваивания МАС-адресов пул адресов может быть, в конце концов, израс-
ходован. Если виртуальная машина удаляется, то присвоенные ее виртуальным сете-
вым адаптерам МАС-адреса можно использовать повторно. Если Hyper-V присвоит все
256 МАС-адресов, то поиск свободного МАС-адреса начинается с первого МАС-адреса
пула. Если МАС-адрес активно используется, то он пропускается и используется сле-
дующий имеющийся в наличии МАС-адрес. Если поиск МАС-адреса не находит дос-
тупного адреса, то выдается ошибка с сообщением, что доступных МАС-адресов нет.
Модификация пула МАС-адресов на сервере Hyper-V

Наличия на сервере Hyper-V диапазона в 256 МАС-адресов вполне достаточно для
большинства ситуаций. Однако вы можете модифицировать значения в реестре для
расширения пула МАС-адресов. В частности, вы можете использовать один октет или
часть октета для увеличения количества доступных МАС-адресов. Для использования
части октета модифицируйте значения MinimumMacAddress и MaximumMacAddress
таким образом, чтобы использовать для диапазона адресов три последние шестнадца-
теричные цифры:
MinimumMacAddress = 00-15-5d-00-61-00
MaximumMacAddress = 00-15-5d-00-6F-FF
В этом примере такая модификация дает пул в 3839 МАС-адресов. Пул МАС-адресов
необходимо настроить до того, как вы начнете создавать виртуальные машины или
внутренние виртуальные сети.
ВНИМАНИЕ!
Перед выполнением изменений сделайте резервную копию реестра. Прямое редактирова-
ние реестра может иметь серьезные и неожиданные последствия, которые могут воспре-
пятствовать запуску системы.
Использование транзитного диска

Сервер Hyper-V позволяет виртуальным машинам получать доступ к физическому дис-
ку сервера, для которого не сконфигурирован том. Это называется транзитным дис-
ком. Транзитные диски могут быть подключены к серверу Hyper-V либо физически,
либо через логический номер устройства LUN сети хранения данных SAN. Преимуще-
ство транзитных дисков в том, что они не подвержены ограничению размера виртуаль-
ных жестких дисков в 2040 Гбайт. Однако транзитные диски не поддерживают дина-
мически расширяющиеся виртуальные жесткие диски, разностные диски, а также мо-

ментальные снимки виртуальных машин. Для того чтобы обеспечить виртуальной ма-
шине монопольный доступ к физическому диску, он должен быть сконфигурирован на
сервере Hyper-V как автономный.
Конфигурирование транзитного диска

На рис. 5.29 показан физический диск (Disk 2) в автономном состоянии, который под-
ключен к серверу Hyper-V. Диск должен быть инициализирован перед подключением
его к виртуальной машине. Для инициализации диска выполните следующие шаги:
1. Откройте консоль Disk Management.
2. Щелкните правой кнопкой мыши по диску и выберите пункт Initialize Disk контек-
стного меню.
Рис. 5.29. Физический диск в автономном состоянии в консоли Disk Management
3. В диалоговом окне Initialize Disk выберите опцию Master Boot Record (MBR) или
GUID Partition Table (GPT), а затем нажмите кнопку OK.
4. После инициализации диска щелкните по нему правой кнопкой мыши и выберите
пункт Offline.
5. Закройте консоль Disk Management.
Если физический диск не находится на сервере Hyper-V в автономном состоянии, то его
нельзя будет выбрать в настройках виртуальной машины.
Для того чтобы подключить транзитный диск к виртуальной машине, выполните сле-
дующие шаги:
2. Щелкните правой кнопкой мыши по виртуальной машине и выберите пункт Settings
контекстного меню.
3. В диалоговом окне Settings выберите целевой контроллер для транзитного диска
(в панели Hardware слева).
4. В правой панели выберите Hard Drive, а затем нажмите кнопку Add.
5. В диалоговом окне Hard Drive Properties просмотрите и измените настройки
Controller и Location так, как это нужно для вашей конфигурации.
6. В разделе Media выберите Physical Hard Disk, а затем выберите целевой физиче-
ский диск (в выпадающем меню).
7. Нажмите кнопку OK.
Вам может понадобиться присвоить букву транзитному диску виртуальной машины
(для того чтобы он появился в окне Windows Explorer). Теперь транзитный диск скон-
фигурирован, и виртуальная машина может начать использовать его для хранения дан-
ных.
Если вы планируете использовать транзитный диск для загрузки гостевой операцион-
ной системы виртуальной машины, то конфигурационный файл виртуальной машины
должен храниться в другом месте. В отличие от виртуальных жестких дисков (которые
являются хранящимися на физических дисках файлами), транзитный диск целиком вы-
деляется гостевой операционной системе виртуальной машины.
ВАЖНО
Если транзитный диск будет использоваться для загрузки гостевой операционной системы
виртуальной машины, то он должен быть подключен к виртуальному IDE-контроллеру. Диск
данных может быть подключен как к виртуальному IDE-контроллеру, так и к виртуальному
SCSI-контроллеру.
Использование функций
отказоустойчивой кластеризации
Несмотря на то, что виртуализация серверов предоставляет организациям такое реше-
ние для реализации динамичной и гибкой базовой инфраструктуры, которое миними-
зирует количество развернутых физических серверов, увеличивает использование фи-
зических ресурсов и снижает долгосрочные эксплуатационные расходы, миграция
множества физических серверов на общий сервер виртуализации требует более серьез-
ной стратегии обеспечения высокой готовности, чем при традиционной инфраструкту-
ре. Если один или несколько серверов виртуализации прекратят работу, то это затронет
многих пользователей, которые потеряют доступ к сервисам и приложениям, что пре-

вратится в потерю производительности и нанесет организации финансовый ущерб.
Развертывание серверов виртуализации на таких аппаратных платформах, которые
имеют избыточные или пригодные для горячей замены компоненты (источники пита-
ния, процессоры и память), снижает риск незапланированных простоев. Сервер
Windows Server 2008 с Hyper-V дает возможность использовать интегрированную в
него отказоустойчивую кластеризацию для управления как плановыми, так и неплано-
выми простоями серверов виртуализации и виртуальных машин.
Высокая готовность
Решения высокой готовности предоставляют способы управления как планируемыми,
так и внеплановыми простоями. Например, планируемый простой — это инсталляция
операционной системы или обновление приложения, для которых сервер необходимо
вывести в автономный режим. Внеплановый простой может быть результатом отказа
компонента оборудования или утраты физических серверов в результате природной
катастрофы. Создание стратегии высокой готовности включает в себя тщательное изу-
чение всех взаимосвязанных компонентов, которые обеспечивают пользователям дос-
туп к сервисам и может потребовать реализации более чем одного решения (чтобы
достичь заявленных целей по готовности).
Отказоустойчивая кластеризация Windows Server 2008

Отказоустойчивая кластеризация Failover Clustering является компонентом серверных
продуктов Microsoft Windows, начиная с версии 4.0 операционной системы NT. В по-
следующие годы компонент отказоустойчивой кластеризации развивался (особенно в
плане легкости настройки и поддерживаемых приложений). Отказоустойчивый кластер
Windows Server 2008 состоит как минимум из двух серверов (узлов), которые соедине-
ны через несколько сетевых подключений (одно из которых предназначено для обмена
между узлами). Каждый узел отказоустойчивого кластера подключен к общему масси-
ву хранения (такому, как SAN или дисковая система на базе iSCSI), и только один узел
кластера в данный момент времени может владеть сетевыми и дисковыми ресурсами
приложения или сервиса. В плане масштабирования, отказоустойчивый кластер
Windows Server 2008 может содержать до 16 узлов. Узлы отслеживают друг друга при
помощи сетевых тактовых импульсов (чтобы определить, отзывается ли узел). Если
узел прекращает отзываться, то работавшее на нем приложение (или сервис) будет пе-
резапущено на другом узле кластера (после того как он примет на себя владение ресур-
сами). Начиная с Windows Server 2008, можно реализовать также и географически раз-
бросанные кластеры (без применения специализированного оборудования). Это дает
вам возможность реализовать такой отказоустойчивый кластер, который сможет
управлять неплановыми простоями — передавая управление в случае отказа одного
сервера другому локальному узлу, а в случае более серьезной аварии — узлу другого
географического региона.
Использование отказоустойчивой кластеризации с Windows Server 2008 и Hyper-V дает
возможность реализовать стратегию высокой готовности, которая позволит управлять
в виртуализированной инфраструктуре как планируемыми, так и неплановыми просто-
ями. Есть два разных уровня, на которых можно реализовать отказоустойчивый кла-
стер в среде Hyper-V: на уровне сервера виртуализации и на уровне гостевой операци-
онной системы. В последующих разделах вы узнаете, как сконфигурировать виртуаль-
ные машины и серверы Hyper-V для реализации перечисленных в табл. 5.7 сценариев
отказоустойчивой кластеризации.
Таблица 5.7. Конфигурации отказоустойчивой кластеризации Hyper-V
Функциональная
Описание
возможность
Hyper-V Server Кластер на базе отказоустойчивой кластеризации Failover Clustering сервера

Failover Cluster Windows Server 2008, который состоит из двух (или более) кластерных узлов
Hyper-V
Virtual Machine Кластер на основе отказоустойчивой кластеризации Failover Clustering сервера
Failover Cluster Windows Server 2008, который состоит из двух (или более) кластерных узлов
виртуальных машин (поддерживающих осведомленное о кластере приложе-
ние). Кластерные узлы виртуальных машин могут находиться на разных серве-
рах Hyper-V, но для них нужны диски iSCSI
Реализация кластера серверов Hyper-V

Модель отказоустойчивого кластера серверов Hyper-V показана на рис. 5.30. Эта кон-
фигурация позволяет вам достичь высокой готовности для неосведомленных о класте-
ре приложений (работающих в виртуальных машинах). Она позволяет также управлять
плановыми и неплановыми простоями серверов Hyper-V. Кластеры серверов Hyper-V
обычно развертываются при помощи совместно используемых систем хранения на базе
Fibre-Channel или iSCSI. Кластеры серверов Hyper-V могут иметь размер от двух
до 16 активных узлов. Важно понимать, что в такой конфигурации вы кластеризируете
серверы Hyper-V, а не работающие в виртуальных машинах (VM) приложения. Если
один из узлов кластера Hyper-V выйдет из строя, то виртуальные машины кластера бу-
дут запущены на другом узле кластера Hyper-V. Однако сбой (или отказ) гостевой опе-
рационной системы или приложения не приведет к передаче управления.
ВАЖНО
Весь набор оборудования для реализации кластера серверов Hyper-V должен значиться в
каталоге Windows Server Catalog как пригодное решение для кластеризации Windows Server
2008. Вы можете найти этот каталог по адресу: http://www.windowsservercatalog.com
/results.aspx?&bCatID=1291&cpID=0&avc=10&ava=0&avq=0&OR=1&PGS=25.
Отказоустойчивый кластер серверов Hyper-V не ограничен применением для совместно ис-
пользуемой системы хранения только iSCSI. В такой конфигурации вы можете использо-
вать системы как на базе iSCSI, так и Fibre-Channel. Существуют различные конфигурации
систем хранения, которые вы можете реализовывать в зависимости от требований вашей
среды.
Есть много сценариев, в которых вы можете применить кластер серверов Hyper-V.

В табл. 5.8 перечислены наиболее часто встречающиеся сценарии, для которых приго-
дится реализация кластера серверов Hyper-V.
Рис. 5.30. Отказоустойчивый кластер Hyper-V с совместно используемой системой хранения
Таблица 5.8. Сценарии для кластера серверов Hyper-V
Сценарий Преимущества кластера серверов Hyper-V
Планируемый Перед выполнением обслуживания серверного оборудования узла кластера

останов оборудова- серверов Hyper-V виртуальные машины можно перенести на другие узлы
ния серверов кластера (с минимальным влиянием на готовность приложений)
Обновление Перед применением (потенциально прерывающих обслуживание) обновлений
программного программного обеспечения сервера Hyper-V виртуальные машины можно
обеспечения передать на другие узлы кластера (с минимальным влиянием на готовность
серверов приложений)
Неосведомленные Работающие в виртуальной машине (узла кластера серверов Hyper-V) неос-
о кластеризации ведомленные о кластеризации приложения защищены от простоев из-за сбо-
приложения ев серверного оборудования. Если узел кластера серверов Hyper-V выходит
из строя, то виртуальная машина может передать управление на другие узлы
кластера (с минимальным влиянием на готовность приложений)
Балансировка Производительность виртуальных машин может потребовать балансировки
рабочей нагрузки нагрузки в узле кластера Hyper-V. Если есть другой узел кластера со свобод-
ными ресурсами, то виртуальную машину можно быстро передать туда
(с минимальным влиянием на готовность приложений)
Во время планового простоя виртуальная машина переводится в сохраненное состоя-

ние, мигрирует на другой узел кластера и перезапускается буквально за несколько се-
кунд или минут (в зависимости от размера выделенной виртуальной машине памяти).
Работающие в виртуальной машине приложения не теряют данных, поскольку состоя-
ние виртуальной машины загружается при ее перезапуске на новом узле кластера. Не-
плановый простой обычно бывает вызван неожиданным отказом питания, отказом

компонента оборудования или программным отказом — что приводит к потере данных
приложения и прерыванию обслуживания (поскольку нельзя сохранить состояние вир-
туальной машины до этого события). Отказоустойчивая кластеризация Windows Server
2008 Failover Clustering обеспечивает минимальное прерывание обслуживания как при
плановых, так и при неплановых простоях.
В табл. 5.9 перечислены требования реализации кластера серверов Hyper-V для произ-
водственного развертывания.
Таблица 5.9. Требования к кластеру серверов Hyper-V
Требование Описание
Физическое обору- Для создания производственного кластера серверов Hyper-V требуются два
дование или более идентичных физических серверов, которые значатся в каталоге
Windows Server Catalog
Операционная Windows Server 2008 Enterprise Edition, Windows Server 2008 Datacenter Edition
система
Система хранения Система хранения Microsoft iSCSI Software Initiator 2.8 (или более поздняя
на базе iSCSI или версия) или Fibre-Channel
Fibre-Channel
Диск-свидетель Диск-свидетель и общий диск должны быть созданы до конфигурирования

и общий диск узлов кластера. Диск-свидетель должен быть больше 500 Мбайт. Общий диск
должен быть такого размера, чтобы на нем разместились файлы виртуальных
жестких дисков виртуальной машины
Сетевые адаптеры Сетевые адаптеры должны быть добавлены и сконфигурированы для публич-
ного трафика и трафика тактовых импульсов на каждом узле кластера серве-
ров Hyper-V. При использовании системы хранения на базе iSCSI должен
быть добавлен дополнительный сетевой адаптер
Виртуальные сети Виртуальные сети следует создавать для публичного трафика и трафика
тактовых импульсов
Службы интеграции Integration Services должны быть инсталлированы на каждой виртуальной

машине
Развертывание отказоустойчивого кластера серверов Hyper-V из двух узлов с системой

хранения Fibre-Channel SAN потребует выполнения следующих основных шагов:
1. Создать том-свидетель и тома хранения данных в Fibre-Channel SAN.
2. Сконфигурировать тома на каждом сервере Hyper-V.
3. Инсталлировать функцию Failover Clustering на каждом сервере Hyper-V.
4. Сконфигурировать Failover Clustering на каждом сервере Hyper-V и подключить его
к кластеру.
5. Сконфигурировать виртуальную машину для высокой готовности.
Описанный в предыдущем разделе кластер серверов Hyper-V был инсталлирован на сер-
верах Sun Microsystems, подключенных к системе хранения Compellent Technologies Storage
Center (находившейся в центре Microsoft Partner Solution Center, MPSC). Конфигурация кла-
стера серверов Hyper-V состояла из следующих компонентов:
• конфигурация контроллера домена Active Directory:
сервер Sun X4450;
четыре процессора Intel X7350 (2,93 ГГц, четыре ядра) — всего 16 ядер;
тридцать два двухгигабайтных модуля памяти FB DIMM — всего 64 Гбайт;
четыре диска SAS по 146 Гбайт;
четыре гигабитных сетевых адаптера Gigabit Ethernet;
• конфигурация кластера серверов Hyper-V:
два сервера Sun X4150;
два процессора Intel E5345 (2,33 ГГц, четыре ядра) — всего 8 ядер;
восемь двухгигабайтных модулей памяти FB DIMM — всего 16 Гбайт;
четыре диска SAS по 146 Гбайт;
четыре гигабитных сетевых адаптера Gigabit Ethernet;
• конфигурация Storage Area Network (SAN):
одна система Compellent Storage Center System;
10 Тбайт объема хранения уровня tier-1;
41 Тбайт объема хранения уровня tier-3.
Если вас интересуют подробности конфигурации тестовой среды кластера Hyper-V, обра-
титесь к описанию во введении.
Показанные в следующем разделе шаги по созданию и назначению (для узлов класте-

ра) диска-свидетеля и дисков хранения данных являются специфичными для системы
хранения Compellent Storage Center, поэтому для вашей конкретной системы SAN эта
процедура будет иной. Однако эти шаги показаны здесь для того, чтобы дать вам поня-
тие о той процедуре, которую вам нужно будет выполнить для подготовки совместно
используемой системы хранения для работы с отказоустойчивым кластером серверов
Hyper-V.
Создание тома-свидетеля и томов хранения данных

на системе хранения Compellent Storage Center SAN
Перед конфигурированием кластера серверов Hyper-V вы должны создать в системе
SAN том-свидетель и тома хранения данных для виртуальных машин. На рис. 5.31 по-
казан Web-интерфейс управления системой Compellent Storage Center (и опция Create
Volume).
Необходимо задать несколько параметров, начиная с размера тома (рис. 5.32). Вы
должны обеспечить размер тома-свидетеля не менее 500 Мбайт. В системе Compellent
Storage Center пространство тома выделяется динамически по мере записи в него но-
вых данных. Таким образом, реальный размер тома в системе Compellent Storage Center
при его инициализации может быть меньше 1 Гбайт, но серверу Hyper-V он будет
представлен как том размером 1 Гбайт.
Следующий шаг — задать профиль Replay для тома (рис. 5.33). Система Compellent
Storage Center предоставляет функцию Data Instant Replay, которая поддерживает вы-
полнение моментальных снимков томов.
Рис. 5.31. Создание тома в системе Compellent Storage Center
Рис. 5.32. Задание размера тома в системе Compellent Storage Center

Рис. 5.33. Настройка Instant Replay в системе Compellent Storage Center
После определения профиля Data Instant Replay для тома вы должны указать название
тома. Как показано на рис. 5.34, мы указываем Witness в качестве названия нового
тома.
Функция Data Instant Replay системы Compellent Storage Center
Функция Data Instant Replay дает возможность сделать неограниченное количество "вос-
произведений" любого тома системы Compellent Storage Center. В отличие от традицион-
ных моментальных снимков, функция воспроизведения Data Instant Replay просто "замора-
живает" блоки данных как доступные "только для чтения". Эти блоки не копируются и не
перемещаются, поэтому данный процесс не влечет дополнительных накладных расходов.
Если серверу нужно обновить блок, он просто записывает новый блок.
Преимущество Data Instant Replay в том, что она не требует предварительного выделения
пространства хранения. "Воспроизведение" — это не клон тома, оно содержит только те
блоки, которые изменились с момента последнего воспроизведения.
Шэйн Бартон (Shane Burton, Microsoft Product Specialist (Compellent Technologies))
Система Compellent Storage Center имеет всю необходимую информацию для создания
нового тома Witness и позволяет вам просмотреть его характеристики перед тем, как
начать создание тома (рис. 5.35).
Во время создания тома вы можете следить за продвижением этой операции (рис. 5.36).
После создания нового тома он должен быть назначен серверу Hyper-V. При помощи
Web-интерфейса управления системой Compellent Storage Center вы должны указать
Рис. 5.34. Указание названия тома в системе Compellent Storage Center
Рис. 5.35. Спецификация тома системы Compellent Storage Center

Рис. 5.36. Процесс создания тома в системе Compellent Storage Center
отдельно каждое соответствие (рис. 5.37 и 5.38). После завершения процесса появится
подтверждение (рис. 5.39). Этот процесс повторяется, чтобы установить соответствие
между диском Witness и всеми серверами Hyper-V, которые будут узлами отказоустой-
чивого кластера.
После назначения диска Witness каждому серверу Hyper-V создается диск хранения
данных для виртуальной машины (в данном случае он называется VmStorage), который
также назначается всем серверам Hyper-V.
На рис. 5.40 и 5.41 показаны тома Witness и VmStorage, назначенные соответственно
двум серверам (MSPRESS1 и MSPRESS2).
Конфигурирование тома-свидетеля и тома хранения данных

на серверах Hyper-V
1. Откройте оснастку Disk Management MMC на первом сервере Hyper-V.
2. Щелкните правой кнопкой мыши по диску Witness (в левой панели) и выберите
пункт Online контекстного меню.
3. Опять щелкните правой кнопкой мыши по диску Witness (в левой панели) и выбе-
рите пункт Initialize Disk контекстного меню.
4. В диалоговом окне Initialize Disk выберите тип раздела (MBR или GPT), а затем
Рис. 5.37. Назначение дисков в системе Compellent Storage Center
Рис. 5.38. Выбор сервера при назначении дисков в системе Compellent Storage Center
Рис. 5.39. Подтверждение назначения дисков в системе Compellent Storage Center
Рис. 5.40. Назначения томов в системе Compellent Storage Center для сервера MSPRESS1
Рис. 5.41. Назначения томов в системе Compellent Storage Center для сервера MSPRESS2
5. Щелкните правой кнопкой мыши по диску Witness еще раз (в правой панели) и вы-
берите пункт New Simple Volume контекстного меню.
6. На первой странице мастера New Simple Volume Wizard нажмите кнопку Next.
7. На странице Specify Volume Size page нажмите кнопку Next.
8. На странице Assign Drive Letter or Path выберите букву диска W в раскрываю-
щемся списке Assign the following drive letter, а затем нажмите кнопку Next.
9. На странице Format Partition выберите Format this volume with the following
settings, введите название нового диска в текстовом поле Volume label, а затем на-
10. На странице Completing The New Simple Volume Wizard просмотрите сделанные
вами настройки, а затем нажмите кнопку Finish.
11. Повторите шаги 2—10 для диска хранения данных и выберите для него букву дис-
ка S.
12. Откройте оснастку Disk Management MMC на втором сервере Hyper-V.
13. В оснастке Disk Management MMC щелкните правой кнопкой мыши по диску
Witness (в левой панели) и выберите пункт Online контекстного меню.
14. Щелкните по диску Witness правой кнопкой мыши еще раз (в правой панели) и вы-
берите пункт Change Drive Letter and Paths контекстного меню.
15. В диалоговом окне Change Drive Letter and Paths For нажмите кнопку Change.
16. В диалоговом окне Change Drive Letter or Path выберите букву диска W в рас-
крывающемся списке Assign the following drive letter, а затем нажмите кноп-
ку OK.
17. Повторите шаги 13—16 и выберите букву диска S для тома хранения данных.
Добавление функции отказоустойчивой кластеризации

в сервера Hyper-V
Перед тем как вы сможете создать кластер, вы должны добавить функцию отказо-
устойчивой кластеризации Failover Clustering на каждый сервер Hyper-V. Для добавле-
ния функции отказоустойчивой кластеризации на сервера Hyper-V выполните следую-
щие шаги:
1. Зарегистрируйтесь на первом сервере Hyper-V под учетной записью с правами ад-
министратора домена.
2. Откройте Server Manager и щелкните по пункту Features в левой панели.
3. В правой панели щелкните по пункту Add Features (чтобы открыть мастер Add
Features Wizard).
4. На странице Select Features выберите Failover Clustering, а затем нажмите кнопку
Next.
5. На странице Confirm Installation Selections нажмите кнопку Install.
6. На странице Installation Results нажмите кнопку Close.
7. Повторите шаги 1—6 для второго сервера Hyper-V.
Конфигурирование отказоустойчивой кластеризации

на серверах Hyper-V
Когда вы создаете первый узел кластера, вы указываете все параметры, которые опре-
деляют конфигурацию кластера. Мастер Cluster Configuration Wizard ведет вас по ин-
сталляции и производит настройку кластера после ввода вами всей необходимой ин-
формации.
Для конфигурирования отказоустойчивой кластеризации на первом узле кластера сер-
веров Hyper-V выполните следующие шаги:
1. Нажмите Start | All Programs | Administrative Tools | Failover Cluster Mana-
gement.
2. Выберите Validate A Configuration в панели Management (для запуска мастера
Validate A Configuration Wizard).
4. На странице Select Servers or a Cluster введите название всех серверов Hyper-V
в текстовом поле Enter name и нажмите кнопку Add. После завершения этих дей-
ствий нажмите кнопку Next.
5. На странице Testing Options выберите Run All Tests (Recommended), а затем на-
6. На странице Confirmation просмотрите список тестов, убедитесь в том, что там
нет ошибок, а затем нажмите кнопку Next.
7. Исправьте все ошибки, найденные при проверке, а затем повторите проверку кон-
фигурации.
8. На странице Summary нажмите кнопку Finish.
9. В панели Management выберите Create A Cluster (для запуска мастера Create
Cluster Wizard).
11. На странице Select Servers введите названия всех серверов Hyper-V в текстовом
поле Enter server name и нажмите кнопку Add. После выполнения этих действий
12. На странице Validation Warning выберите соответствующую опцию, а затем на-
13. На странице Access Point For Administering The Cluster введите название класте-
ра (в текстовом поле Cluster name). Вам может также понадобиться ввести IP-
адрес для каждой сконфигурированной сети. После выполнения этих действий на-
14. На странице Confirmation просмотрите информацию о кластере, а затем нажмите
кнопку Next.
После выполнения этих шагов все серверы Hyper-V станут узлами отказоустойчивого
кластера. Для быстрой проверки функционирования отказоустойчивого кластера вы
можете остановить первый узел кластера Hyper-V. Когда вы откроете Failover Cluster
Management на втором узле кластера Hyper-V, то увидите, что он владеет всеми ресур-
сами кластера. После такой проверки успешности перехвата управления в кластере при
сбое вы можете начать конфигурирование виртуальной машины.
ВАЖНО
После настройки кластера серверов Hyper-V и перед созданием новой виртуальной маши-
ны высокой готовности вы должны сконфигурировать и подключить внешнюю виртуальную
сеть с одинаковым названием на каждом сервере Hyper-V, включенном в отказоустойчивый
кластер.
Создание виртуальной машины на отказоустойчивом кластере

После конфигурирования кластера серверов Hyper-V следующий шаг — создание вир-
туальной машины на одном из узлов кластера Hyper-V:
1. Откройте консоль Hyper-V Manager на первом узле кластера Hyper-V.
2. В панели Actions под именем сервера щелкните по пункту New и выберите в меню
пункт Virtual Machine для запуска мастера New Virtual Machine Wizard.

4. На странице Specify Name and Location введите название новой виртуальной ма-
шины. Затем выберите Store the virtual machine in a different location и нажмите
кнопку Browse для того, чтобы использовать Windows Explorer для выбора тома
хранения данных (буква диска S). После выполнения всех этих действий нажмите
кнопку Next.
5. На странице Assign Memory укажите выделение памяти для виртуальной машины,
а затем нажмите кнопку Next.
6. На странице Configure Networking выберите созданную для некластерного трафи-
ка внешнюю виртуальную сеть.
7. На странице Connect Virtual Hard Disk выберите Create a virtual hard disk и вве-
дите информацию по умолчанию для Name, Location и Size новой виртуальной
машины. После выполнения всех этих действий нажмите кнопку Next.
8. На странице Options выберите соответствующий метод для инсталляции гостевой
операционной системы в виртуальной машине, а затем нажмите кнопку Next.
9. На странице Completing The New Virtual Machine Wizard сбросьте флажок Start
the virtual machine after it is created.
Преобразование виртуальной машины

в машину высокой готовности
Когда виртуальная машина находится в выключенном состоянии, вы можете сделать ее
машиной высокой готовности. Для того чтобы сконфигурировать новую виртуальную
машину и сделать ее машиной высокой готовности, выполните следующие шаги:
1. Откройте консоль Failover Cluster Management на первом узле кластера серверов
Hyper-V.
2. В левой панели щелкните правой кнопкой мыши по пункту Services And
Applications под названием кластера и выберите пункт Configure a service or
application контекстного меню (для запуска мастера High-Availability Wizard).
4. На странице Select Service Or Application выберите Virtual Machine в списке
опций.
5. На странице Select Virtual Machine выберите соответствующую виртуальную ма-
шину, а затем нажмите кнопку Next.
6. На странице Confirmation проверьте всю информацию и нажмите кнопку Next.
7. После выполнения всех этих действий откройте Hyper-V Manager и выберите Start
под названием виртуальной машины (для перевода ее в оперативный режим).
Проверка высокой готовности виртуальной машины

Для проверки того, что виртуальная машина производит передачу управления при сбое
второму узлу кластера Hyper-V, выполните следующие шаги:
1. Откройте консоль Failover Cluster Management на первом сервере Hyper-V.
2. В левой панели щелкните правой кнопкой мыши по виртуальной машине, выберите
Move Virtual Machine(s) To Another Node | Move Virtual Machine(s) To Node 2.
Весь процесс займет совсем немного времени, причем продолжительность этого
промежутка времени зависит от выделенного виртуальной машине количества па-
мяти, времени сохранения информации о состоянии и времени восстановления ин-
формации о состоянии на новом узле.
ВАЖНО
Если вы хотите создать такие виртуальные машины, которые в случае сбоя будут переда-
вать управление независимо друг от друга, то вам придется хранить каждую машину на от-
дельном томе.
Преодоление ограничения по количеству букв дисков
при помощи точек подключения
Отказоустойчивая кластеризация серверов Hyper-V является отличным решением для пла-
новых простоев, например, когда вам нужно быстро мигрировать виртуальную машину с
одного узла на другой для выполнения работ по обслуживанию (скажем, для обновления
BIOS, либо для добавления памяти или дисков в систему хранения сервера Hyper-V). Отка-
зоустойчивая кластеризация серверов Hyper-V является также отличным решением для
неплановых простоев (когда происходит отказ оборудования и вам нужна автоматическая
передача виртуальных машин на другой узел).
Когда происходит миграция или сбой, то на новый узел переносится весь диск или LUN.
Для миграции на другой узел кластера одной виртуальной машины этот диск (или LUN)
должен содержать только те файлы, которые относятся к этой виртуальной машине. Ти-
пичные инсталляции отказоустойчивой кластеризации Windows Server 2008 присваивают
отдельную букву диска каждому LUN, но с учетом наличия всего 26 букв этого может быть
недостаточно. Решение здесь — поместить на диск больше, чем одну виртуальную маши-
ну, либо найти способ увеличить количество доступных (узлам кластера Hyper-V) номеров
LUN. Точки подключения позволяют вам создавать неограниченное количество номеров
LUN и предоставляют способ доступа к ним для кластеров Windows Server 2008. Более
подробную информацию по созданию точек подключения к физическим дискам и конфигу-
рированию их как дисковых ресурсов отказоустойчивого кластера см. по ссылке:
Джефф Вулсэй (Jeff Woolsey, Senior Program Manager (Windows Virtualization))
При проектировании вашего решения кластеризации серверов на конфигурацию необ-

ходимого для его реализации оборудования влияет количество узлов кластера и сцена-
рий сбоя. При кластере из двух узлов вы должны спроектировать каждый узел на рабо-
чую нагрузку обоих серверов (на случай отказа). Для этого вы должны определить тре-
бования по оборудованию для рабочей нагрузки одного узла и удвоить их. Например,
если рабочая нагрузка одного узла (работа 20 виртуальных машин) требует двух чете-
рехъядерных процессоров и 24 Гбайт памяти, то эти требования следует удвоить до
четырех четырехъядерных процессоров и 48 Гбайт памяти (чтобы справиться со сбоем
второго узла).
При добавлении в кластер дополнительных узлов рабочая нагрузка отказавшего узла

может быть распределена по другим узлам и требования по оборудованию к отдельно-
му узлу уменьшаются (по сравнению с конфигурацией кластера из двух узлов). Либо
вы можете запланировать в кластере узел горячего резерва (не несущий рабочей на-
грузки). Когда узел кластера отказывает, то вся рабочая нагрузка с этого узла возоб-
новляет свою работу на узле горячего резерва. Использование такого узла упрощает
процесс проектирования, снижает аппаратные требования к узлам кластера (уменьшая,
таким образом, стоимость каждого узла) и гарантирует, что процесс переноса при сбое
не затронет рабочие нагрузки на остальных узлах кластера.
Реализация отказоустойчивого кластера

виртуальных машин
Отказоустойчивый кластер виртуальных машин реализуется при помощи двух (или
более) виртуальных машин, работающих на разных серверах Hyper-V, которые под-
ключены к общей системе хранения (рис. 5.42). Для реализации такого варианта вы
должны выполнять виртуальную машину в такой операционной системе, которая под-
держивает отказоустойчивую кластеризацию (например, Windows Server 2003 (до
восьми узлов), либо Windows Server 2008 Enterprise или Datacenter (до 16 узлов)). Кро-
ме того, то приложение, которому вы хотите обеспечить высокую готовность, должно
быть "осведомленным" о кластеризации. Это означает, что данное приложение было
разработано со специальными функциональными возможностями, которые позволяют
ему взаимодействовать со службой кластеризации и выполнять передачу управления и
повторный запуск при сбое (со всеми необходимыми для этого ресурсами) на другом
узле кластера.
Если вы планируете отказоустойчивый кластер виртуальных машин, то iSCSI — един-
ственный поддерживаемый для такой конфигурации протокол доступа к системе хра-
нения. Использование iSCSI для развертывания отказоустойчивого кластера избавляет
от необходимости покупать специализированное оборудование (которое ранее требо-
валось для конфигурирования кластеризации). Для решения на базе iSCSI требуются
сетевые адаптеры (для подключения системы хранения к узлам кластера) и модуль
хранения с поддержкой протокола iSCSI. Протокол iSCSI определяет правила и про-
цессы для передачи и получения блочных данных по сетям TCP/IP. Реализации на ос-
нове iSCSI состоят из инициатора iSCSI и iSCSI-цели (с соединяющей их сетью).
Для использования iSCSI и максимизации производительности вы должны выделить в
каждой виртуальной машине отдельный виртуальный сетевой адаптер для обмена по
iSCSI. Вам следует также выделить один (или более) физических сетевых адаптеров и
сконфигурировать индивидуальные виртуальные сети на каждом сервере Hyper-V (для
доступа к системе хранения iSCSI). Для доступа к iSCSI-целям системы хранения на
каждой виртуальной машине требуется iSCSI-инициатор. Этот инициатор — про-
граммный компонент, который обеспечивает подключение сервера Windows к внешней
системе хранения через сеть TCP/IP. Важно отметить, что такая конфигурация не под-
держивает непосредственного подключения iSCSI-цели к виртуальной машине в каче-
стве устройства для загрузки.
Рис. 5.42. Отказоустойчивый кластер виртуальных машин

с использованием системы хранения iSCSI
iSCSI-инициатор компании Microsoft включен в состав Windows Server 2008, но для версии
Windows Server 2003 и более ранних его необходимо скачать. Вы можете скачать iSCSI-
инициатор по ссылке: http://go.microsoft.com/fwlink/?linkid=44352.
Отказоустойчивый кластер виртуальных машин способен поддерживать как плановые,

так и неплановые простои (для осведомленных о кластеризации приложений). Факти-
чески такая конфигурация способна справляться с неплановыми простоями, вызван-
ными сбоем или отказом виртуальной машины, а также сбоями или отказами самого
сервера Hyper-V.
В табл. 5.10 перечислены требования для реализации двухузлового кластера из вирту-
альных машин (на базе устройства хранения iSCSI).
Таблица 5.10. Требования к отказоустойчивому кластеру виртуальных машин

(на базе iSCSI)
Операционная На каждой виртуальной машине кластера должен быть инсталлирован
система Windows Server 2003 Enterprise или Datacenter Edition, либо Windows Server
2008 Enterprise или Datacenter Edition
Службы интеграции Службы интеграции должны быть инсталлированы на каждой виртуальной
машине
Диск-свидетель Диск-свидетель и общий диск должны быть созданы до конфигурирования
и общий диск узлов кластера. Диск-свидетель должен быть размером не менее 500 Мбайт,
чтобы соответствовать требованиям отказоустойчивого кластера
Виртуальные сети Для некластерного трафика, трафика тактовых импульсов и трафика iSCSI
необходимо создать виртуальные сети
Сетевые адаптеры На каждой виртуальной машине следует создать три виртуальных сетевых
адаптера и подключить их на каждом узле к описанным в предыдущем пункте
виртуальным сетям
Служба Active Узлы кластера виртуальных машин должны быть членами домена Active
Directory Directory
Для развертывания кластера виртуальных машин из двух узлов (с использованием

iSCSI) вы должны выполнить следующие основные шаги:
1. Создать общий диск для свидетеля и тома хранения данных (при помощи iSCSI-
инициатора).
2. Сконфигурировать общие диски на каждом узле виртуальной машины.
3. Инсталлировать функцию отказоустойчивой кластеризации Failover Clustering на
каждой виртуальной машине.
4. Сконфигурировать отказоустойчивую кластеризацию на всех узлах виртуальных
машин и включить их в кластер.
Конфигурирование общих дисков iSCSI

После того как вы создадите ваши виртуальные машины Windows Server 2008, вы мо-
жете сконфигурировать общие диски кластера. Для конфигурирования доступа узлов
кластера виртуальных машин к общим дискам iSCSI выполните следующие шаги:
1. В первой виртуальной машине откройте Control Panel в виде Classic View, дважды
щелкните по значку iSCSI Initiator, а потом нажмите кнопку Yes в диалоговом окне
Microsoft iSCSI (для запуска службы Microsoft iSCSI). При запросе нажмите кнопку
Yes для разблокирования службы Microsoft iSCSI (чтобы она могла вести обмен
через сетевой экран Windows Firewall).
2. В диалоговом окне iSCSI Initiator Properties перейдите на вкладку Discovery и в
разделе Target Portals нажмите кнопку Add Portal.
3. Введите название или IP-адрес того сервера, где определено целевое устройство
iSCSI, а затем нажмите кнопку OK.
4. Перейдите на вкладку Targets для показа списка целевых дисков.
5. Выберите название цели и щелкните по Log On.
6. Выберите Automatically Restore This Connection When The Computer Starts, а за-
тем Enable Multipath (если у вас инсталлировано программное обеспечение, кото-
рое умеет работать с несколькими путями).
7. Нажмите кнопку OK для подключения к iSCSI-цели.
8. Нажмите кнопку OK, чтобы закрыть диалоговое окно iSCSI Initiator Properties.
9. Откройте оснастку Disk Management MMC.
10. Щелкните правой кнопкой мыши по диску Witness в левой панели и выберите
пункт Online в контекстном меню.
11. Еще раз щелкните правой кнопкой мыши по диску Witness в левой панели и выбе-
рите пункт Initialize Disk в контекстном меню.
12. В диалоговом окне Initialize Disk выберите соответствующий тип раздела (MBR
или GPT), а затем нажмите кнопку OK.
13. Еще раз щелкните правой кнопкой мыши по диску Witness в правой панели и вы-
берите пункт New Simple Volume в контекстном меню.
14. На начальной странице мастера New Simple Volume Wizard нажмите кнопку Next.
15. На странице Specify Volume Size нажмите кнопку Next.
16. На странице Assign Drive Letter Or Path выберите букву диска W в раскрываю-
щемся списке Assign the following drive letter, а затем нажмите кнопку Next.
settings введите название нового диска в текстовом поле Volume label, а затем на-
19. Повторите шаги 11—18 для общего диска и выберите для него букву диска S.
20. Повторите шаги 1—9 для второй виртуальной машины.
21. В оснастке Disk Management MMC щелкните правой кнопкой мыши по диску
Witness и выберите пункт Online в контекстном меню.
22. Еще раз щелкните правой кнопкой мыши по диску Witness в правой панели и вы-
берите пункт Change Drive Letter and Paths в контекстном меню.
23. В диалоговом окне Change Drive Letter and Paths For нажмите кнопку Change.
24. В диалоговом окне Change Drive Letter and Paths выберите букву диска W из
раскрывающегося списка Assign the following drive letter, а затем нажмите кноп-
ку OK.
25. Повторите шаги 21—24 и выберите букву S для диска Shared.
Добавление функции отказоустойчивой кластеризации

на виртуальные машины
Перед тем как вы сможете создать кластер, вы должны добавить функцию отказо-
устойчивой кластеризации на все виртуальные машины.
Для добавления функции отказоустойчивой кластеризации на все виртуальные маши-
ны выполните следующие шаги:
1. Зарегистрируйтесь на первой виртуальной машине под учетной записью с правами
администратора домена.
2. Откройте Server Manager и щелкните по пункту Features в левой панели.

3. В правой панели щелкните по пункту Add Features.
4. На странице Select Features мастера Add Features Wizard выберите Failover
Clustering, а затем нажмите кнопку Next.
7. Повторите шаги 1—6 для второй виртуальной машины.
Конфигурирование отказоустойчивой кластеризации

на виртуальных машинах
Когда вы создаете первый узел кластера, то указываете все параметры, которые опре-
деляют конфигурацию кластера. Мастер Cluster Configuration Wizard проводит вас по
инсталляции и завершает настройку кластера после ввода вами всей необходимой ин-
формации.
Для конфигурирования отказоустойчивой кластеризации на первом узле кластера вир-
туальных машин выполните следующие шаги:
1. Выполните последовательно Start | All Programs | Administrative Tools | Failover
Cluster Management.
2. Выберите Validate A Configuration в панели Management, чтобы запустить мастер
Validate A Configuration Wizard.
4. На странице Select Servers or a Cluster введите названия всех виртуальных машин
в тестовом поле Enter name и нажмите кнопку Add. После выполнения этих дей-
6. На странице Confirmation просмотрите список тестов, а затем нажмите кнопку
Next.
7. Исправьте все ошибки, обнаруженные в процессе проверки, а затем произведите
повторную проверку конфигурации.
9. Выберите Create A Cluster в панели Management для запуска мастера Create
Cluster Wizard.
11. На странице Select Servers введите название всех виртуальных машин в текстовом
поле Enter server name и нажмите кнопку Add. После выполнения всех этих дей-
12. На странице Validation Warning выберите соответствующую опцию, а затем на-
ра в текстовом поле Cluster name. Вам может также понадобиться ввести IP-адрес
для каждой сконфигурированной сети. После выполнения всех этих действий на-
14. На странице Confirmation просмотрите информацию о кластере, а затем нажмите
кнопку Next.
ВНИМАНИЕ!
При выполнении проверки кластера вы можете получить ошибку, которая связана с двой-
ными адресами протокола Teredo IPv6 Tunneling Protocol. Для устранения этой проблемы
откройте Device Manager, выберите пункт Show Hidden Devices в меню View, в разделе
Network Adapters щелкните правой кнопкой мыши по Teredo Tunneling Pseudo-Interface и
выберите пункт Disable.
После выполнения всех этих шагов все виртуальные машины станут узлами отказо-
устойчивого кластера. Для быстрой проверки работы кластера вы можете завершить
работу первого узла кластера виртуальных машин. Когда вы откроете Failover Cluster
Management на втором узле кластера виртуальных машин, то увидите, что теперь
ему принадлежат все ресурсы кластера. После такой проверки успешной передачи
управления вы можете начать инсталляцию осведомленного о кластеризации прило-
жения.
Резюме
В Hyper-V имеется много расширенных функциональных возможностей, которые вы
можете использовать для оптимизации развертывания инфраструктур виртуализации.
Если вы хотите создать сложную среду для тестирования, службы поддержки или обу-
чения пользователей, то используйте разностные диски и моментальные снимки вирту-
альных машин для того, чтобы быстро готовить новые конфигурации виртуальных
машин (с возможностью отката к базовому состоянию). Когда вам нужно уменьшить
размер динамически расширяющихся дисков (отформатированных в NTFS), исполь-
зуйте дефрагментацию до применения инструмента сжатия виртуальных жестких дис-
ков (для минимизации размера сжатых виртуальных жестких дисков). Перед сжатием
отформатированного не в NTFS виртуального жесткого диска необходимо применять
предварительное сжатие. Hyper-V обеспечивает внешние, внутренние и частные сети
для реализации широкого диапазона сетевых конфигураций и предоставляет виртуаль-
ным машинам соответствующую область видимости подключений. Кроме того, сервер
Hyper-V поддерживает конфигурирование VLAN на уровне сервера и виртуальных
машин. Для работающих на виртуальных машинах осведомленных о кластеризации
приложений используйте кластер виртуальных машин (для минимизации простоев от
сбоев виртуальных машин). В случае неосведомленных о кластеризации приложений
для управления плановыми и неплановыми простоями развертывайте кластеры серве-
ров Hyper-V.

блог Technet Blog Жозе Баррето (Jose Barreto) "Windows Server 2008 Hyper-V
Failover Clustering Options" по адресу:
http://blogs.technet.com/josebda/archive/2008/06/17/windows-server-2008-Hyper-V-
failover-clustering-options.aspx;
блог Technet Blog Жозе Баррето "Failover Clustering for Windows Server 2008 Hyper-V
with File Server Storage" по адресу:
http://blogs.technet.com/josebda/archive/2008/07/16/failover-clustering-for-Hyper-V-
with-file-server-storage.aspx;
блог Technet Blog Жозе Баррето "More on Storage Options for Windows Server 2008
Hyper-V" по адресу:
http://blogs.technet.com/josebda/archive/2008/03/06/more-on-storage-options-for-
windows-server-2008-s-Hyper-V.aspx;
статья Microsoft Knowledge Base "Parallel SCSI Support in Windows Server 2008
Failover Clusters" по ссылке: http://support.microsoft.com/kb/947710;
блог Microsoft AskCore Blog, документ "Cluster Resource Type Options for Hyper-V"
по ссылке:
http://blogs.technet.com/askcore/archive/2008/07/27/cluster-resource-type-
options-forHyper-V.aspx;
Web-сайт Microsoft Technet, документ "Hyper-V Step-by-Step Guide: Hyper-V and
Failover Clustering" по ссылке:
http://technet.microsoft.com/en-us/library/cc732181.aspx#BKMK_Install.
ГЛАВА 6
Безопасность Hyper-V
В этой главе описывается безопасность Windows Server 2008 Hyper-V. Вы узнаете

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

При инсталляции по умолчанию роли Hyper-V на сервере Windows Server 2008 в фай-
ловой системе создается несколько каталогов, каждый из которых содержит важные
файлы приложения. Таблицы 6.1—6.16 содержат списки этих каталогов, их местопо-
ложение (при инсталляции по умолчанию английской версии Hyper-V), а также файлы
каждого каталога. Вы должны быть знакомы со структурой каталогов и файлов Hyper-V,
чтобы вы могли разработать и реализовать надежную модель безопасности вашей ин-
фраструктуры Hyper-V, а также управлять ею.
Таблица 6.1. Клиентские файлы управления сервером Hyper-V
Каталог Файлы Подробности

%SystemDrive% Этот каталог содержит клиент-
\Program Files ские файлы управления серве-
\Hyper-V ром Hyper-V
InspectVhdDialog.exe Это диалоговое окно, которое
отображается при выборе вами
Inspect Disk в Hyper-V Manager.
Оно показывает такие свойства
VHD, как местоположение фай-
ла, размер файла и максималь-
ный размер VHD
Microsoft.Virtualization.Client.dll
Microsoft.Virtualization.Client.Management.dll
Microsoft.Virtualization.Client.RdpClientAxHost.dll
Microsoft.Virtualization.Client.RdpClientInterop.dll
Microsoft.Virtualization.Client.Settings.dll
Microsoft.Virtualization.Client.VMBrowser.dll
Microsoft.Virtualization.Client.Wizards.dll
SnapInAbout.dll
Virtmgmt.msc Это файл оснастки Hyper-V
Manager для MMC
Vmconnect.exe Это файл приложения Virtual
Machine Connection
Таблица 6.2. Файлы ресурсов клиента управления сервером Hyper-V
%SystemDrive% Этот каталог содержит

\Program Files файлы ресурсов клиента
\Hyper-V\en-US управления сервером
Hyper-V
InspectVhdDialog.resources.dll
Microsoft.Virtualization.Client.Management.resources.dll
Microsoft.Virtualization.client.resources.dll
Microsoft.Virtualization.Client.Settings.resources.dll
Microsoft.Virtualization.Client.VMBrowser.resources.dll
Microsoft.Virtualization.Client.Wizards.resources.dll
SnapInAbout.dll.mui
Virtmgmt.msc
Vmconnect.resources.dll
Таблица 6.3. Файлы средства просмотра событий Hyper-V
%SystemDrive%\ProgramData Этот каталог содержит файлы сред-

\Microsoft\Event Viewer\Views ства просмотра событий Hyper-V
\Server Roles
Virtualization.Events.xml Этот файл содержит системные
события для служб Hyper-V
Глава 6. Безопасность Hyper-V 243
Таблица 6.4. Хранилище менеджера авторизации по умолчанию в Hyper-V
%SystemDrive%\ProgramData\Microsoft Этот каталог содержит файлы

\Windows\Hyper-V менеджера авторизации Hyper-V
InitialStore.xml Это файл хранилища менеджера

авторизации по умолчанию
Таблица 6.5. Каталог по умолчанию для моментальных снимков

виртуальных машин Hyper-V
%SystemDrive%\ProgramData\Microsoft Это каталог по умолчанию, который Hyper-V

\Windows\Hyper-V\Snapshots использует для хранения файлов момен-
тальных снимков виртуальных машин.
Вначале он пуст
Таблица 6.6. Каталог по умолчанию для виртуальных машин Hyper-V
%SystemDrive%\ProgramData\Microsoft Это каталог по умолчанию, который Hyper-V

\Windows\Hyper-V\Virtual Machines использует для хранения файлов виртуаль-
ных машин. Вначале он пуст
Таблица 6.7. Каталог по умолчанию для виртуального флоппи-диска Hyper-V
%SystemDrive%\Users\Public Это каталог по умолчанию, который

\Public Documents\Hyper-V Hyper-V использует для хранения пустого
\Blank Floppy Disk файла виртуального флоппи-диска
Blank.vfd Это пустой файл виртуального флоппи-

диска (по умолчанию)
Таблица 6.8. Каталог по умолчанию для виртуальных жестких дисков Hyper-V

%SystemDrive%\Users\Public Это каталог по умолчанию, который Hyper-V
\Public Documents\Hyper-V\Virtual Hard Disks использует для хранения файлов вирту-
альных жестких дисков. Вначале он пуст
Таблица 6.9. Информационные файлы драйверов Hyper-V

%SystemDrive% Этот каталог содержит информационные файлы Hyper-V
\Windows\Inf
Wnetvsc.inf, Это информационный файл (inf) и предварительно скомпи-
wnetvsc.pnf лированный информационный файл (pnf) для инсталляции
сетевого драйвера мини-порта VSC для Hyper-V
Ws3Cap.inf, Это inf- и pnf-файлы для инсталляции драйвера VGA Cap
Ws3Cap.pnf в Hyper-V
Wstorflt.inf, Это inf- и pnf-файлы для инсталляции драйвера фильтра
wstorflt.pnf ускорения виртуального диска Hyper-V
Wstorvsc.inf, Это inf- и pnf-файлы для инсталляции драйвера мини-порта
wstorvsc.pnf клиента VSC для системы хранения Hyper-V
Wstorvsp.inf, Это inf- и pnf-файлы для инсталляции драйвера мини-порта
wstorvsp.pnf поставщика VSP для системы хранения Hyper-V
Wvid.inf, wvid.pnf Это inf- и pnf-файлы для инсталляции драйвера инфра-
структуры виртуализации в Hyper-V
Wvmbus.inf, Это inf- и pnf-файлы для инсталляции драйвера VMBus для
wvmbus.pnf Hyper-V
Wvmbushid.inf, Это inf- и pnf-файлы для инсталляции драйвера мини-порта
wvmbushid.pnf VMBus HID в Hyper-V
Wvmbusvideo.inf, Это inf- и pnf-файлы для инсталляции синтетического
wvmbusvideo.pnf видеодрайвера Hyper-V
Wvmic.inf, wvmic.pnf Это inf- и pnf-файлы для инсталляции служб интеграции
Hyper-V
Wvms_mp.inf, Это inf- и pnf-файлы для инсталляции граничного драйвера
wvms_mp.pnf мини-порта для коммутатора виртуальной машины
Wvms_pp.inf, Это inf- и pnf-файлы для инсталляции граничного драйвера
wvms_pp.pnf протокола коммутатора виртуальной машины
Таблица 6.10. Компилированные HTML-файлы системы помощи для Hyper-V

%SystemDrive% Этот каталог содержит файлы системы помощи
\Windows\Help\Mui\0409 Hyper-V
Virtual_help.chm Это скомпилированный HTML-файл системы помощи
Hyper-V
Таблица 6.11. Компилированные файлы системы помощи для Hyper-V

%SystemDrive%\Windows Этот каталог содержит файлы системы помощи
\Help\en-US Hyper-V
Virtsrv_start.h1s Это скомпилированный файл системы помощи
Hyper-V
Virtual_help.h1s Это скомпилированный файл системы помощи
Hyper-V
Таблица 6.12. Файлы гипервизора Windows и служб интеграции

%SystemDrive% Этот каталог содержит исполняемые файлы
\Windows Hyper-V, DLL-файлы и прочие файлы, связан-
\System32 ные со службами интеграции
Hvax64.exe Это версия гипервизора Windows для AMD
Hvix64.exe Это версия гипервизора Windows для Intel
Hypervisor.mof Это управляемый файл объектного формата
(MOF), описывающий события диагностиче-
ской трассировки, которые гипервизор
Windows записывает в журнал Event Tracing
для Windows (ETW)
IcCoinstall.dll Это DLL-файл для Integration Services
Coinstaller
Nvspwmi.dll Это DLL-файл для поставщика Virtual Network
Switch WMI
Rdp4vs.dll Это DLL-файл Virtual Machine Remoting
Services API
RemoteFileBrowse.dll Это DLL-файл данных для браузера удален-
ного просмотра файлов
Removehypervisor.mof Это управляемый файл объектного формата
(MOF), который используется для отмены
регистрации событий диагностической трас-
сировки, которые гипервизор Windows запи-
сывает в журнал ETW
Synthnic.dll Это вспомогательный DLL-файл для синтети-
ческого сетевого адаптера
Synthstor.dll Это вспомогательный DLL-файл для синтети-
ческого адаптера системы хранения
Vhdsvc.dll Это вспомогательный DLL-файл для службы
управления VHD
Vid.dll Это вспомогательный DLL-файл для драйве-
ра библиотеки инфраструктуры
Vmbuspipe.dll Это вспомогательный DLL-файл для канала
пользовательского режима VMBus
Vmbusvdev.dll Это вспомогательный DLL-файл для устрой-
ства шины виртуальной машины
Vmclusex.dll Это вспомогательный DLL-файл для админи-
стрирования отказоустойчивого кластера
Vmclusres.dll Это вспомогательный DLL-файл ресурсов для
отказоустойчивого кластера виртуальных
машин.
VmdCoinstall.dll Это вспомогательный DLL-файл для
Integration Services Coinstaller
Vmguest.iso Это файл образа, который используется для
инсталляции служб интеграции в гостевых
операционных машинах

Vmicheartbeat.dll Это вспомогательный DLL-файл для вирту-
ального устройства тактовых импульсов
Integration Services
Vmickvpexchange.dll Это вспомогательный DLL-файл ключевых
параметров тактовых импульсов Integration
Services
Vmicshutdown.dll Это вспомогательный DLL-файл виртуального
устройства завершения работы Integration
Services
Vmicsvc.exe Это файл службы Integration Services
Vmictimeprovider.dll Это вспомогательный DLL-файл библиотеки
поставщика синхронизации времени
Vmictimesync.dll Это вспомогательный DLL-файл виртуального
устройства синхронизации времени Integration
Services
Vmicvss.dll Это вспомогательный DLL-файл виртуального
устройства VSS writer для Integration Services
Vmms.exe Это файл службы управления виртуальными
машинами.
Vmprox.dll Это вспомогательный DLL-файл прокси
Hyper-V
Vmsntfy.dll Это вспомогательный DLL-файл уведомления
коммутатора виртуальной машины
Vmwp.exe Это файл рабочего процесса виртуальной
машины
Vmwpctrl.dll Это вспомогательный DLL-файл моникера
виртуальной машины
Vsconfig.dll Это вспомогательный DLL-файл конфигури-
рования виртуальной машины
WindowsVirtualization.mof Это управляемый файл объектного формата
с директивами для добавления всех классов и
экземпляров пространства имен Virtualization
WindowsVirtualizationUninstall.mof Это управляемый файл объектного формата,
который содержит директивы деинсталляции
для всех классов и экземпляров пространства
имен Virtualization
Таблица 6.13. Файлы драйверов Hyper-V

%SystemDrive% Этот каталог содержит файлы драйверов Hyper-V
\Windows\System32\Drivers
Hvboot.sys Это файл драйвера загрузки гипервизора
Windows
Isoparser.sys Это файл драйвера анализатора образа ISO

Passthruparser.sys Это файл драйвера анализатора транзитного
диска
S3Cap.sys Это файл Cap-драйвера эмулированного устрой-
ства Microsoft S3
Storflt.sys Это файл драйвера фильтра виртуального хра-
нения
Storvsc.sys Это файл драйвера мини-порта VSC хранения
Storvsp.sys Это файл драйвера мини-порта VSP хранения
Vhdparser.sys Это файл драйвера анализатора VHD
Vid.sys Это файл драйвера инфраструктуры Hyper-V
Vmbus.sys Это файл драйвера VMBus
Vmswitch.sys Это файл драйвера сетевого VSP
Winhv.sys Это файл драйвера интерфейса гипервизора
Windows
Таблица 6.14. Файлы локализации драйверов Hyper-V

%SystemDrive%\Windows Этот каталог содержит файлы локализа-
\System32\drivers\en-US ции для файлов драйверов Hyper-V
Isoparser.sys.mui
Hvboot.sys.mui
Vmbus.sys.mui
Netvsc50.sys.mui
Netvsc60.sys.mui
Passthruparser.sys.mui
Storflt.sys.mui
Storvsp.sys.mui
Vhdparser.sys.mui
Таблица 6.15. Файлы локализации информации Hyper-V

%SystemDrive%\Windows Этот каталог содержит файлы локализации,
\System32\DriverStore\en-US связанные с информационными файлами
Hyper-V
Wnetvsc.inf_loc
Ws3cap.inf_loc
Wstorflt.inf_loc
Wstorvsp.inf_loc
Wvid.inf_loc
Wvmbus.inf_loc
Wvmbushid.inf_loc
Wvmbusvideo.inf_loc
Wvmic.inf_loc
Wvms_mp.inf_loc
Wvms_pp.inf_loc
Таблица 6.16. Файлы локализации служб интеграции Hyper-V
%SystemDrive%\Windows Этот каталог содержит файлы

\System32\en-US локализации для служб интегра-
ции Hyper-V
Nvspwmi.dll.mui
RemoteFileBrowse.dll.mui
SynthNic.dll.mui
SynthStor.dll.mui
Vhdsvc.dll.mui
Vmclusex.dll.mui
Vmclusres.dll.mui
Vmicheartbeat.dll.mui
Vmickvpexchange.dll.mui
Vmicshutdown.dll.mui
Vmictimesync.dll.mui
Vmicvss.dll.mui
Vmms.exe.mui
Vmwp.exe.mui
Vsconfi g.dll.mui
WindowsVirtualization.mfl
WindowsVirtualizationUninstall.mfl
Как показано в табл. 6.5—6.8, есть несколько каталогов по умолчанию, которые

Hyper-V создает во время инсталляции для хранения относящихся к виртуальным ма-
шинам файлов. В частности, это:
%SystemDrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots;
%SystemDrive%\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines;
%SystemDrive%\Users\Public\Public Documents\Hyper-V\Virtual Hard Disks;
%SystemDrive%\Users\Public\Public Documents\Hyper-V\Blank Floppy Disk.
Вам следует изменить местоположение этих каталогов для того, чтобы избежать хра-
нения файлов виртуальных машин на системном диске. Хорошей практикой будет из-
менение положения этих каталогов (чтобы избежать проблем ввода/вывода, которые
могут возникнуть на системном диске сервера). Вы можете изменить настройки серве-
ра Hyper-V в менеджере Hyper-V Manager (указать новые пути для каталогов виртуаль-
ных машин и виртуальных жестких дисков). Местоположение каталога моментальных
снимков виртуальной машины и путь к виртуальному флоппи-диску указываются для
каждой отдельной виртуальной машины в настройках виртуальной машины (в менед-
жере Hyper-V Manager).
ВНИМАНИЕ!
Местоположение каталога моментальных снимков виртуальной машины нельзя изменить
тогда, когда виртуальная машина уже имеет хотя бы один виртуальный снимок.
Лучшие практики по безопасности требуют устанавливать роль Hyper-V в инсталляцию
Windows Server 2008 типа Server Core. На такой инсталляции Windows Server 2008 клиент-
ские файлы управления Hyper-V не инсталлируются, что уменьшает пространство для атак
сервера Hyper-V. Кроме того, такой подход имеет также и то преимущество, что при этом
уменьшается размер инсталляции сервера Hyper-V, что приводит и к уменьшению времени
простоев (поскольку для обслуживания системы требуется меньше обновлений).
Обзор служб Hyper-V

Как уже обсуждалось ранее подробно в главе 3, вместе с Hyper-V в родительском раз-
деле инсталлируются три службы.
Hyper-V Image Management Service (IMS). Служба IMS обеспечивает управление
виртуальными жесткими дисками (VHD) через интерфейсы WMI. Управление VHD
включает в себя такие действия, как обследование VHD, а также их сжатие и объ-
единение разностных дисков.
Hyper-V Networking Management Service (NMS). Служба NMS обеспечивает управ-
ление виртуальными сетями (через интерфейсы WMI). Управление виртуальными
сетями включает в себя такие действия, как привязка физических сетевых адаптеров
и конфигурирование VLAN.
Virtual Machine Management Service (VMMS). Служба VMMS обеспечивает управ-
ление дочерними разделами через интерфейсы WMI. Сюда входят: подключение
VHD к виртуальным машинам, подключение виртуальных сетевых адаптеров к вир-

туальным сетям, создание рабочих процессов виртуальных машин, управление мо-
ментальными снимками, а также много других важных функций.
Службы Hyper-V конфигурируются с автоматическим запуском, зависят от служб
Remote Procedure Call (RPC) и Windows Management Instrumentation (WMI), а выпол-
няются в контексте системных учетных записей с наименьшим возможным уровнем
привилегий. Служба IMS выполняется с правами учетной записи Network Service (это
NT AUTHORITY\Network Service). Учетная запись Network Service имеет ограничен-
ный доступ к ресурсам локального компьютера и для аутентификации доступа к сете-
вым ресурсам использует учетную запись компьютера. Службы NMS и VMMS выпол-
няются в контексте учетной записи Local System (это NT AUTHORITY\LocalSystem).
Учетная запись Local System имеет обширные права на локальном компьютере и на
сети действует как компьютер. Поскольку маркер безопасности записи Local System
содержит идентификаторы безопасности NT AUTHORITY\SYSTEM и BUILTIN
\Administrators, то эта учетная запись имеет доступ ко многим системным объектам.
ВНИМАНИЕ!
Системные учетные записи служб Hyper-V изменять не следует. Изменение этих настроек
или контекста выполнения служб Hyper-V может привести к прекращению их работы.
Обзор правил межсетевого экрана Hyper-V

Для того чтобы разрешить сетевой трафик, который необходим для доступа к Hyper-V,
а также для управления им и ресурсами виртуальных машин, при инсталляции Hyper-V
конфигурируется несколько правил межсетевого экрана. В табл. 6.17 содержится спи-
сок этих правил межсетевого экрана и соответствующие сетевые порты.
Таблица 6.17. Правила межсетевого экрана Windows Server 2008 Hyper-V
Правило экрана Описание Протокол Сетевые порты
Hyper-V — WMI Входящее правило для разрешения TCP Local — Any;

(Async-In) асинхронного трафика WMI Remote — Any
Hyper-V — WMI Входящее правило для разрешения TCP Local — 135;

(DCOM-In) управления WMI при помощи DCOM Remote — Any
Hyper-V — WMI Входящее правило для разрешения TCP Local — Any;

(TCP-In) удаленного трафика WMI Remote– Any
Hyper-V (RPC) Входящее правило для разрешения TCP Local — Dynamic

удаленного управления при помощи RPC; Remote — Any
RPC/TCP
Hyper-V Входящее правило для службы TCP Local — RPC

(RPC-EPMAP) RPCSS для разрешения трафика Endpoint Mapper;
RPC/TCP Remote — Any
Hyper-V Входящее правило для разрешения TCP Local — 2179;

(SPL-TCP-In) удаленных подключений к виртуаль- Remote — Any
ным машинам
Правило экрана Описание Протокол Сетевые порты

Hyper-V Management Входящее правило для клиентов TCP Local — Any;
Clients — WMI управления Hyper-V для разрешения Remote — Any
(Async-In) асинхронного трафика WMI
Hyper-V Management Входящее правило для клиентов TCP Local — 135;
(DCOM-In) управления WMI через DCOM
Hyper-V Management Входящее правило для клиентов TCP Local — Any;
(TCP-In) удаленного трафика WMI
Hyper-V — WMI Исходящее правило для разрешения TCP Local — Any;
(TCP-Out) удаленного трафика WMI Remote — Any
Hyper-V Management Исходящее правило для клиентов TCP Local — Any;
(TCP-Out) удаленного трафика WMI
Как показано на рис. 6.1, вы можете использовать оснастку Windows Firewall With
Advanced Security для ММС в Windows Server 2008 для просмотра и управления как
входящими, так и исходящими правилами межсетевого экрана.
Рис. 6.1. Оснастка Windows Firewall With Advanced Security для ММС
Для того чтобы открыть эту оснастку, выполните следующие шаги:

1. На панели задач Windows нажмите кнопку Start.
2. В меню выберите Administrative Tools.
3. Выберите пункт меню Windows Firewall With Advanced Security.
Для использования оснастки Windows Firewall With Advanced Security вы должны войти
в систему под учетной записью из группы Administrators или группы Network Operators
Group.
Обеспечение безопасности ресурсов Hyper-V

В сервере Virtual Server 2005 R2 возможность предоставлять права доступа к хосту
Virtual Server, виртуальным машинам, виртуальным жестким дискам и виртуальным
сетевым ресурсам была реализована как разновидность списков Discretionary Access
Control Lists (DACL) для файлов и каталогов Virtual Sever 2005 R2. При такой модели
административные задачи преобразуются в разрешения на объекты, а пользователям и
группам (для выполнения их работы) предоставляются необходимые права доступа
к каждому объекту.
В отличие от такого подхода, Hyper-V определяет набор операций, которые можно ис-
пользовать для создания элементов управления доступом на базе ролей (role-based
access controls, RBAC), которые не требуют непосредственной модификации разреше-
ний для каждого отдельного объекта, а присваивают разрешения набору ресурсов (что-
бы можно было выполнить требующиеся функции). При использовании RBAC, роль —
это базовый модуль, который позволяет управлять разрешениями и присваиваниями.
Разрешения предоставляются роли, а роль присваивается пользователям или группам
(что позволяет им выполнять свою работу).
Использование менеджера
Authorization Manager с Hyper-V
Сервер Hyper-V использует менеджер Authorization Manager (AzMan) для определения
элементов управления доступом на базе ролей. Authorization Manager позволяет вам
определять административные роли, приспособленные для выполнения определенных
работ в вашей среде; предоставлять необходимые (для выполнения функций данной
роли) разрешения; а также присваивать роли пользователям и группам. Далее приво-
дятся некоторые основные концепции AzMan, которые вам следует понять перед тем,
как пытаться модифицировать базовую модель системы безопасности Hyper-V.
Operation (операция). Это разрешение низкого уровня, которое определяет конкрет-
ное действие, разрешенное приложением. Примеры: запуск виртуальной машины,
подключение к порту виртуального сетевого коммутатора, создание виртуальной
машины.
Task (задача). Это коллекция операций, которая используется для определения про-
стого административного действия. Задачи могут содержать другие задачи. Напри-
мер, в Hyper-V вы можете создать задачу Manage VMs, которая будет состоять из
операций запуска, останова, приостановки и перезапуска виртуальной машины.
Role (роль). Это коллекция операций и задач, которые нужны пользователю для вы-
полнения определенного задания. Роль применяется к набору связанных с приложе-
нием объектов, а пользователи и группы получают эти роли. Например, в Hyper-V
вы можете определить роль VM User, VM Administrator и т. д.
Scope (область действия). Это граница объектов, к которым может быть применена
роль. Например, область действия может включать такие объекты, как файлы или
каталоги, контейнер Active Directory, либо любой предоставляемый приложением
объект. В Hyper-V область действия может применяться к виртуальным машинам,
виртуальным коммутаторам, а также портам виртуальных коммутаторов.
Authorization Policy (политика авторизации). Описывает связи между операциями,
задачами, ролями и областями действия (содержащимися в хранилище Authorization
Manager).
В отличие от списков контроля доступа к файлам или каталогам (ACL) (которые хра-
нятся с объектом), определения ролей, задач и операций (а также присваивание ролей
пользователям и группам) хранятся отдельно от объектов в хранилище авторизации
(которым можно управлять при помощи оснастки Authorization Manager для MMC). По
умолчанию Hyper-V создает файловое хранилище авторизации (%SystemDrive%
\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xml) при своей инсталляции. Хра-
нилище авторизации может также иметься и в Active Directory. В дополнение к оснаст-
ке Authorization Manager для MMC вы можете управлять хранилищем авторизации и
при помощи интерфейса прикладного программирования Authorization Manager API
(который поддерживает такие языки скриптов, как Visual Basic Scripting, VBScript).
Хранилище авторизации на основе XML не поддерживает делегирования администрирова-
ния, поскольку доступ к хранилищу авторизации на базе XML управляется списком DACL
для этого файла (который управляет доступом ко всему содержимому файла).
Если для хранилища авторизации используется база данных Active Directory, то служ-
бы домена Active Directory Domain Services (AD DS) должны быть на функциональном
уровне Windows Server 2003. Очень важно учесть хранилище авторизации в стратегии
резервного копирования Hyper-V. Модуль записи VSS в Hyper-V может сделать ре-
зервное копирование хранилища авторизации на сервере Hyper-V.
ВНИМАНИЕ!
Хранилище авторизации на основе XML-файла может одновременно редактироваться дву-
мя административными приложениями. Поэтому при помощи процедурных мер вы должны
обеспечить такое положение, чтобы в каждый момент времени только один администратор
мог делать изменения в XML-файле.
При помощи менеджера Authorization Manager сервер Hyper-V запрашивает на стадии

выполнения политику авторизации (для подтверждения того, что пользователь автори-
зован для выполнения запрошенной операции с ресурсом Hyper-V).
ВНИМАНИЕ!
Перед выполнением любых модификаций хранилища авторизации Hyper-V вы должны
сделать его резервную копию (при помощи Windows Backup Server или другого приложения
резервного копирования). Если хранилище авторизации Hyper-V повреждено или отсутст-
вует, то службы Hyper-V не смогут запуститься.
Подробности об инфраструктуре Authorization Manager см. по адресу:
http://technet.microsoft.com/en-us/library/cc732077.aspx.
Создание хранилища авторизации в Active Directory

Если вы хотите реализовать хранилище авторизации в Active Directory, то обычно соз-
даете его в контейнере Program Data. Это не является непременным требованием, по-
этому вы можете сделать иначе (в соответствии со схемой вашего Active Directory и
политиками управления). Однако хранилище авторизации должно содержаться внутри
контекста именования домена Active Directory; поэтому вы не можете хранить его
в разделе приложений.
На компакт-диске вы найдете каталог \Scripts\Chapter 6\AzMan. В этом каталоге есть скрипт
CreateAzStore.js. Вы должны запустить этот скрипт из командной строки с повышенными
правами. Скрипт создает новое хранилище авторизации в Active Directory (для него нужно
задать путь к начальному хранилищу авторизации InitialStore.xml, а также название и ме-
стоположение нового хранилища авторизации в Active Directory). Кроме того, в новом хра-
нилище авторизации по умолчанию создаются операции и роль Administrator (в соответст-
вии с содержащейся в начальном хранилище информацией). Однако роль Administrator не
присваивается никаким пользователям или группам.
cscript CreateAzStore.js msxml://C:\ProgramData\Microsoft\Windows
\Hyper-V\InitialStore.xml "msldap://CN=AzStoreRK,CN=Microsoft,
CN=Program Data,DC=contoso,DC=com"
В этом примере путь к начальному хранилищу — C:\programData\Microsoft\Windows\Hyper-V
\InitialStore.xml, название нового хранилища авторизации — AzStoreRK, а местоположение
для создания нового хранилища авторизации в Active Directory — это CN=Microsoft,
CN=Program Data,DC=contoso,DC=com.
После завершения работы скрипта CreateAzStore.js выполните следующие шаги (для

того, чтобы открыть оснастку Authorization Manager для MMC и посмотреть новое хра-
нилище авторизации в Active Directory):
1. В родительском разделе нажмите кнопку Start, введите azman.msc в текстовом поле
Start Search, а затем нажмите клавишу <Enter>.
2. В левой панели консоли Authorization Manager щелкните правой кнопкой мыши по
корню менеджера Authorization Manager и выберите пункт Open Authorization
Store контекстного меню.
3. В диалоговом окне Open Authorization Store выберите Active Directory или Active
Directory Application Mode (ADAM), а затем нажмите кнопку Browse.
4. В следующем диалоговом окне выберите созданное при помощи скрипта
CreateAzStore.js хранилище авторизации, а затем нажмите кнопку Open.
5. В диалоговом окне Open Authorization Store убедитесь, что в текстовом поле Store
Name содержится нужное вам хранилище авторизации, а затем нажмите кноп-
ку OK.
6. В левой панели консоли Authorization Manager разверните новое хранилище автори-
зации, затем узел Hyper-V Services, и наконец, узел Definitions.
7. Выберите Role Definitions. Вы должны будете увидеть в правой панели роль
Administrator.
8. Закройте консоль Authorization Manager.
Для того чтобы сервер Hyper-V использовал хранилище Authorization Manager в Active
Directory, необходимо выполнить следующие шаги (для изменения местоположения
хранилища авторизации в реестре):
1. В родительском разделе нажмите кнопку Start, введите regedit в текстовом поле
2. В редакторе реестра Registry Editor перейдите к ключу HKEY_Local_
Machine\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization.
3. В левой панели щелкните по этому ключу правой кнопкой мыши и выберите пункт
Export.
4. В диалоговом окне Export Registry File введите имя файла для сохранения ключа,
а затем нажмите кнопку Save.
5. В левой панели щелкните правой кнопкой мыши по элементу StoreLocation и вы-
берите пункт Modify.
6. В диалоговом окне Edit String введите новое местоположение хранилища автори-
зации в Active Directory (например, msldap://CN=AzStoreRK, CN=Microsoft,
CN=Program Data, DC=contoso, DC=com), а затем нажмите кнопку OK.
Кроме того, вы должны предоставить учетной записи компьютера сервера Hyper-V
доступ на чтение Read к хранилищу авторизации в Active Directory. Для предоставле-
ния соответствующих разрешений учетной записи компьютера сервера Hyper-V вы-
полните следующие шаги:
новому хранилищу авторизации и выберите пункт Properties.
3. В диалоговом окне Properties хранилища авторизации перейдите на вкладку
Security.
4. В раскрывающемся списке Authorization Manager User Role выберите Reader.
5. В диалоговом окне Properties хранилища авторизации нажмите кнопку Add.
6. В диалоговом окне Select Users, Computers, or Groups введите название учетной
записи компьютера сервера Hyper-V, отметьте Check Names, а затем нажмите
кнопку OK.
7. В диалоговом окне Properties хранилища авторизации нажмите кнопку OK.

9. Откройте консоль Services и перезапустите службы Virtual Machine Management
Service (VMMS) и Networking Management Service (NVSPWMI).
10. Закройте консоль Services.
Для того чтобы вернуться к использованию исходного файла хранилища, выполните
1. В родительском разделе откройте консоль Services и остановите службы Virtual
Machine Management Service и Networking Management Service.
2. Откройте редактор Registry Editor и перейдите к ключу HKEY_Local_
Machine\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization.
3. В левой панели щелкните правой кнопкой мыши по элементу StoreLocation и
выберите пункт Modify.
4. В диалоговом окне Edit String введите местоположение исходного хранили-
ща авторизации (такое, как msxml://C:\ProgramData\Microsoft\Windows\Hyper-V
\InitialStore.xml), а затем нажмите кнопку OK.
5. Закройте Registry Editor.
6. В консоли Services перезапустите службы Virtual Machine Management Service и
Networking Management Service.
7. Закройте консоль Services.
8. Откройте консоль Authorization Manager и проверьте конфигурацию Authorization
Policy.
Если вы используете менеджер System Center Virtual Machine Manager (SCVMM) для управ-
ления серверами Hyper-V, то SCVMM создает и использует собственное хранилище авто-
ризации. SCVMM не импортирует никаких данных из используемого сервером Hyper-V хра-
нилища авторизации, а также ничего в него не экспортирует. Когда сервер Hyper-V удаля-
ется из управления при помощи SCVMM, то вы должны сконфигурировать для него
локальное хранилище авторизации (или хранилище в Active Directory), чтобы реализовать
дополнительные роли для более тонкого управления сервером Hyper-V.
Разбираемся с безопасностью Hyper-V

По умолчанию Hyper-V определяет одну область действия, 33 операции и одну роль.
Вы можете просмотреть и модифицировать политику авторизации Hyper-V по умолча-
нию (при помощи оснастки Authorization Manager для ММС). Для использования этой
оснастки вы должны использовать такую учетную запись, которая является членом
группы администраторов родительского раздела.
Для того чтобы открыть оснастку Authorization Manager и просмотреть политику авто-
ризации Hyper-V, выполните следующие шаги:

пункту Authorization Manager и выберите пункт Open Authorization Store контек-
3. В диалоговом окне Open Authorization Store выберите XML File, введите
%ProgramData%\Microsoft\Windows\Hyper-V\InitialStore.xml в текстовом поле Store
Name, а затем нажмите кнопку OK.
4. Разверните узел Hyper-V Services под InitialStore.xml, чтобы просмотреть опреде-
ления ролей и задач, а также присваивание ролей.
Как показано на рис. 6.2, Hyper-V Services представляет собой область действия по
умолчанию, которая распространяется на все объекты Hyper-V. Можно определить до-
полнительные области действия, причем они наследуют (от области действия по умол-
чанию) определения ролей и задач, а также присваивания ролей. Однако новые области
можно создавать и применять только к виртуальным машинам, виртуальным коммута-
торам, портам виртуальных коммутаторов и объектам VMMS.
Рис. 6.2. Область действия Hyper-V по умолчанию в менеджере Authorization Manager
В табл. 6.18—6.20 приведены операции Hyper-V, сгруппированные в категории служб,

сетей и виртуальных машин соответственно. При определении новых ролей при помо-
щи менеджера Authorization Manager эти операции доступны для предоставления раз-
решений доступа к объектам Hyper-V и для определения задач, которые затем при-
сваиваются ролям.
Таблица 6.18. Операции служб Hyper-V
Операция Описание
Read Service Configuration Разрешает читать конфигурацию службы Virtual Machine Management
Service
Reconfigure Service Разрешает переконфигурировать службу Virtual Machine Management

Service
View Virtual Switch Разрешает просматривать службу Virtual Switch Management Service
Management Service
Таблица 6.19. Сетевые операции Hyper-V
Bind External Ethernet Port Разрешает привязку к внешнему порту Ethernet
Change VLAN Configuration on Port Разрешает модифицировать настройки VLAN
Connect Virtual Switch Port Разрешает подключение к порту виртуального коммутатора

Create Internal Ethernet Port Разрешает создание внутреннего порта Ethernet
Create Virtual Switch Разрешает создание нового виртуального коммутатора.

Create Virtual Switch Port Разрешает создание нового порта виртуального коммутатора
Delete Internal Ethernet Port Разрешает удаление внутреннего порта Ethernet
Delete Virtual Switch Разрешает удаление виртуального коммутатора
Delete Virtual Switch Port Разрешает удаление порта виртуального коммутатора
Disconnect Virtual Switch Port Разрешает отключение от порта виртуального коммутатора
Modify Internal Ethernet Port Разрешает модификацию внутреннего порта Ethernet
Modify Switch Port Settings Разрешает модификацию настроек порта коммутатора
Modify Switch Settings Разрешает модификацию настроек коммутатора

Unbind External Ethernet Port Разрешает убрать привязку к внешнему порту Ethernet
View External Ethernet Ports Разрешает просматривать доступные внешние порты
Ethernet
View Internal Ethernet Ports Разрешает просматривать доступные внутренние порты
Ethernet
View LAN Endpoints Разрешает просматривать конечные точки LAN
View Switch Ports Разрешает просматривать доступные порты коммутатора
View Switches Разрешает просматривать доступные коммутаторы
View VLAN Settings Разрешает просматривать настройки VLAN
Таблица 6.20. Операции виртуальных машин Hyper-V
Allow Input to Virtual Machine Разрешает пользователю делать ввод в виртуальной машине
Allow Output from Virtual Machine Разрешает просматривать вывод из виртуальной машины
Change Virtual Machine Разрешает изменять область действия виртуальной машины
Authorization Scope
Create Virtual Machine Разрешает создавать виртуальную машину
Delete Virtual Machine Разрешает удалять виртуальную машину
Pause and Restart Virtual Machine Разрешает приостанавливать и перезапускать виртуальную

машину
Reconfigure Virtual Machine Разрешает переконфигурировать виртуальную машину
Start Virtual Machine Разрешает запускать виртуальную машину
Stop Virtual Machine Разрешает останавливать виртуальную машину
View Virtual Machine Configuration Разрешает просматривать конфигурацию виртуальной

машины
ВНИМАНИЕ!
В Windows Server 2008 Hyper-V нет единой операции для предоставления разрешения на
создание моментальных снимков виртуальных машин. Однако такая операция (Allow
Virtual Machine Snapshots) имеется в Windows Server 2008 R2 Hyper-V.
В Hyper-V по умолчанию определена только одна роль — Administrator (рис. 6.3). По-
скольку все 33 операции Hyper-V присвоены роли Administrator, то она может про-
сматривать и модифицировать все объекты Hyper-V (в том числе виртуальные маши-
ны, виртуальные жесткие диски с соответствующими списками ACL, виртуальные сети
и настройки Hyper-V).
Рис. 6.3. Определение роли Administrator в оснастке Authorization Manager
В инсталляции по умолчанию Windows Server 2008 Hyper-V только членам локальной

группы администраторов (родительского раздела) предоставлен доступ к управлению
конфигурацией Hyper-V, а также объектами виртуальных машин, виртуальных жестких
дисков и виртуальных сетей. Локальная группа администраторов — это единственная

группа, которой присвоена роль Administrator (рис. 6.4). Для предоставления другим
пользователям или группам разрешений на доступ к ресурсам Hyper-V и управление
ими необходимо создать и добавить дополнительные роли и присвоить владение этими
ролями.
Рис. 6.4. Присваивание роли Administrator в менеджере Authorization Manager
Не следует использовать группу локальных администраторов для присваивания новым
пользователям разрешений на ресурсы Hyper-V. Вместо этого создавайте новые группы и
используйте хорошо описанную модель вложенных групп (до создания новых элементов
менеджера Authorization Manager). Например, создайте в домене новую глобальную группу
(такую, как Hyper-V Admins — GG, чтобы обозначить, что это глобальная группа) и добавь-
те в эту группу нужных пользователей. Затем создайте локальную группу домена (такую,
как Hyper-V Local Admins — DLG) и вложите в нее глобальную группу. И наконец, исполь-
зуйте эту локальную группу домена при новом присваивании ролей Hyper-V.
Дополнительную информацию по вложенным группам см. по адресу:
http://msdn.microsoft.com/en-us/library/cc246068(PROT.10).aspx.
В нескольких следующих разделах описываются возможные роли управления Hyper-V,

а также новые определения и присваивания ролей (для активации специфических для
роли прав доступа). Для реализации этих ролей определите группу, которая ей соответ-
ствует, добавьте в нее нужных пользователей или группы, после чего присвойте этой
группе нужную роль.
Сделанные модификации определений и присваивания ролей применяются немедленно.
Пользователь получает (или утрачивает) права доступа сразу же, как только изменения со-
храняются в оснастке Authorization Manager.
В тех организациях, где существует очень строгое разделение обязанностей, представ-

ленные группами роли заполнены как отдельными личностями, так и целыми коман-
дами. В организациях с многофункциональными командами таким командам (или от-
дельным личностям) может быть предоставлено множество ролей (присвоенных не-

скольким группам).
Создавайте и присваивайте роли группам, а не отдельным пользователям. Точнее говоря,
создавайте такие группы, которые соответствуют основным ролям, существующим в вашей
организации. Поместите тех людей, которые выполняют данную роль, в глобальную группу
и вложите эту глобальную группу в локальную группу домена. Затем вы сможете опреде-
лить новые роли в менеджере Authorization Manager и присвоить им те операции, которые
требуются для выполнения различных ролей. Когда вы будете готовы делать присваивание
ролей, добавьте созданную вами для конкретной роли локальную группу домена.
ВНИМАНИЕ!
Свою политику Authorization Manager вы должны реализовывать в сочетании с жесткой по-
литикой безопасности NTFS (для каталога виртуальной машины и файловой структуры).
Только команда администраторов и пользователи могут иметь права доступа к файлам
виртуальной машины. Подробности см. в разд. "Обеспечение безопасности доступа к вир-
туальной машине" далее в этой главе.
Конфигурирование роли наблюдения для Hyper-V

Для вашей среды вам, возможно, понадобится реализовать роль наблюдения за Hyper-V,
чтобы можно было использовать оснастку Hyper-V Manager и изучать настройки кон-
фигурации Hyper-V без прав на их модификацию (если у вас есть человек, который
будет наблюдать за работой и настройками Hyper-V и виртуальных машин).
В табл. 6.21 перечислены операции, которые необходимо присвоить этой роли. Роль
можно определить при помощи области действия по умолчанию Hyper-V Services.
Таблица 6.21. Определение роли наблюдения в Hyper-V
Права доступа Операции
Hyper-V Services Read Service Configuration, View Virtual Switch Management Service
Virtual Machines Allow Output from Virtual Machine, View Virtual Machine Configuration
Virtual Networks View External Ethernet Ports, View Internal Ethernet Ports,
View LAN Endpoints, View Switch Ports, View Switches, View VLAN Settings
Выполните перечисленные далее шаги для того, чтобы открыть оснастку Authorization
Manager, создать роль Hyper-V Monitor и присвоить ее пользователям или группам:
1. Зарегистрируйтесь на сервере Hyper-V с учетной записью, имеющей права админи-
стратора.
пункту Authorization Manager и выберите пункт Open Authorization Store контек-

5. Разверните узел Hyper-V Services (область действия по умолчанию) под
InitialStore.xml.
6. Разверните узел Definitions, чтобы просмотреть определения ролей и задач
(рис. 6.5).
Рис. 6.5. Определения ролей и задач в Authorization Manager
7. Щелкните правой кнопкой мыши по узлу Role Definitions и выберите пункт New
Role Definition контекстного меню.
8. В диалоговом окне New Role Definition (рис. 6.6) введите Hyper-V Monitor в тек-
стовом поле Name. Вы можете также ввести здесь краткое описание роли в тексто-
вом поле Description (это не обязательно).
9. После ввода названия определения роли и ее описания нажмите кнопку Add.
10. В диалоговом окне Add Definition перейдите на вкладку Operations (рис. 6.7).
11. На вкладке Operations выберите все перечисленные в табл. 6.21 операции, а затем
12. В диалоговом окне New Role Definition проверьте, что все требуемые операции
там перечислены (рис. 6.8), а затем нажмите кнопку OK.
13. В левой панели разверните узел Role Assignments.
14. Щелкните правой кнопкой мыши по узлу Role Assignments и выберите пункт New
Role Assignment в контекстном меню (рис. 6.9).
15. В диалоговом окне Add Role установите флажок Hyper-V Monitor (рис. 6.10), а за-
тем нажмите кнопку OK.
16. В правой панели щелкните правой кнопкой мыши по узлу Hyper-V Monitor и вы-
берите последовательно Assign Users and Groups | From Windows and Active
Directory (рис. 6.11).
Рис. 6.6. Диалоговое поле New Role Definition
Рис. 6.7. Вкладка Operations диалогового окна Add Definition
17. В диалоговом окне Select Users, Computers, or Groups введите название группы,
содержащей тех пользователей, которым необходимо наблюдать за Hyper-V
(рис. 6.12), а затем нажмите кнопку OK.
18. В оснастке Authorization Manager проверьте, что данная группа включена в при-
сваиваниях роли Hyper-V Monitor (рис. 6.13).
19. Закройте оснастку Authorization Manager.
Вы можете зарегистрироваться на сервере Hyper-V под учетной записью, являющейся

членом группы, которой присвоена роль Hyper-V Monitor, и использовать Hyper-V
Manager для просмотра конфигурации виртуальных машин и виртуальных сетей.
Однако если вы попытаетесь модифицировать какие-либо настройки, то получите по-
хожее на рис. 6.14 сообщение об ошибке, в котором говорится о том, что у вас нет не-
обходимых разрешений.
Рис. 6.8. Список требуемых операций
Рис. 6.9. Выбор пункта New Role Assignment в контекстном меню

Рис. 6.10. Флажок Hyper-V Monitor

для добавления определения роли
Рис. 6.11. Выбор пункта From Windows and Active Directory
Рис. 6.12. Введите название группы

Рис. 6.13. Проверьте группу
Рис. 6.14. Ошибка при использовании роли Hyper-V Monitor

для модификации состояния виртуальной машины
Вы можете ограничить роль Hyper-V Monitor только просмотром настроек Hyper-V и вирту-
альных машин (удалив операции с виртуальными машинами Allow Output from Virtual
Machine и View Virtual Machine Configuration из определения роли Hyper-V Manager).
Конфигурирование роли менеджера виртуальных сетей

Роль Virtual Network Manager дает возможность создавать, добавлять и модифициро-
вать виртуальные сети. Виртуальные сети можно также удалять с Hyper-V. В табл. 6.22
перечислены операции, которые необходимо присвоить определению роли Virtual
Network Manager. Эту роль можно определить при помощи области действия по умол-
чанию Hyper-V Services. Роль Virtual Network Manager может быть реализована в том
случае, когда для поддержания строгой виртуальной сетевой структуры выделяется
специальная команда.
Таблица 6.22. Определение роли Virtual Network Manager
Virtual Networks Bind External Ethernet Port, Connect Virtual Switch Port,
Create Internal Ethernet Port, Create Virtual Switch, Create Virtual Switch Port,
Delete Internal Ethernet Port, Delete Virtual Switch, Delete Virtual Switch Port,
Disconnect Virtual Switch Port, Modify Internal Ethernet Port,
Modify Switch Port Settings, Modify Switch Settings,
Unbind External Ethernet Port, View External Ethernet Ports,
View Internal Ethernet Ports, View LAN Endpoints, View Switch Ports,
View Switches, View VLAN Settings
При помощи описанной ранее в разд. "Конфигурирование роли наблюдения для

Hyper-V" процедуры создайте новое определение роли с названием Hyper-V Virtual
Network Manager, присвойте ей перечисленные в табл. 6.22 операции, а потом присвой-
те эту роль соответствующей группе.
Конфигурирование роли менеджера

Роль Virtual Machine Manager позволяет делегировать управление виртуальными ма-
шинами при помощи оснастки Hyper-V Manager. Роль Virtual Machine Manager может
быть реализована в тестовой лаборатории или в производственной среде, когда опре-
деленной группе нужен доступ только к конкретному подмножеству работающих на
сервере Hyper-V виртуальных машин.
Для того чтобы реализовать роль Virtual Machine Manager, вы должны предоставить
права доступа к оснастке Hyper-V Manager на уровне области действия по умолчанию.
Для этого используйте описанную в разд. "Конфигурирование роли наблюдения для
Hyper-V" ранее в этой главе процедуру, чтобы создать новое определение роли под
названием Hyper-V Manager, присвоить ей перечисленные в табл. 6.23 операции и сде-
лать присваивание новой роли соответствующей группе.
Таблица 6.23. Определение роли Hyper-V Manager
Для делегирования управления подмножеством работающих на сервере Hyper-V вир-

туальных машин вы должны создать новую область действия AzMan и применить ее
к целевому набору виртуальных машин. Затем вы можете создать определение роли
Virtual Machine Manager (при помощи перечисленных в табл. 6.24 операций) и при-
сваивание роли в новой области действия.
Таблица 6.24. Определение роли Virtual Machine Manager
Virtual Machines Allow Input To Virtual Machine, Allow Output From Virtual Machine,
Pause And Restart Virtual Machine, Start Virtual Machine,
Stop Virtual Machine, View Virtual Machine Configuration
Выполните следующие шаги для применения оснастки Authorization Manager для соз-
дания новой области действия, определения роли, а также присваивания этой роли:
1. Зарегистрируйтесь на сервере Hyper-V под учетной записью с правами админист-
ратора.
узлу Authorization Manager и выберите пункт Open Authorization Store контек-
5. Разверните узел Hyper-V Services под узлом InitialStore.xml.
6. Щелкните правой кнопкой мыши по узлу Hyper-V Services и выберите пункт New
Scope в контекстном меню (рис. 6.15).
7. В новой области действия щелкните правой кнопкой мыши по узлу Role
Definitions и выберите пункт New Role Definition в контекстном меню.
8. В диалоговом окне New Role Definition введите Hyper-V Virtual Machine Manager
в текстовом поле Name (рис. 6.16). Вы можете также ввести краткое описание роли
в текстовом поле Description.
9. После ввода названия определения роли и описания нажмите кнопку Add.
10. В диалоговом окне Add Definition перейдите на вкладку Operations.
11. На вкладке Operations выберите все перечисленные в табл. 6.24 операции, а затем
12. В диалоговом окне New Role Definition проверьте, что в нем перечислены все тре-
буемые операции, а затем нажмите кнопку OK.
13. В новой области действия щелкните правой кнопкой мыши по узлу Role
Assignments и выберите пункт New Role Assignment в контекстном меню.
Рис. 6.15. Диалоговое окно New Scope
14. В диалоговом окне Add Role выберите Hyper-V Virtual Machine Manager, а затем
15. В правой панели щелкните правой кнопкой мыши по узлу Hyper-V Virtual
Machine Manager и последовательно выберите Assign Users and Groups | From
Windows and Active Directory.
16. В диалоговом окне Select Users, Computers, or Groups введите название той груп-
пы, которой необходимо управлять виртуальными машинами, а затем нажмите
кнопку OK.
17. В оснастке Authorization Manager проверьте, что данная группа включена в при-
сваивание роли Hyper-V Virtual Machine Manager.
18. Закройте оснастку Authorization Manager.
После создания новой области действия вы должны применить ее к подмножеству вир-
туальных машин. Для применения новой области действия вы должны настроить свой-
ство ScopeOfResidence каждой виртуальной машины на название новой области дей-
ствия. Вы должны использовать скрипт для модификации свойства ScopeOfResidence
виртуальной машины, поскольку для выполнения этой операции нет графического ин-
терфейса.
Далее следует простой VBScript, который позволяет вам присвоить новую область дей-
ствия для виртуальной машины.
Рис. 6.16. Диалоговое окно New Role Definition
Option Explicit
Dim VMManagementService
Dim VMSystemGlobalSettingData
Dim VMName
Dim VMScope
Dim Result
' Ввести название VM и название области ее действия

VMName = InputBox("Specify the virtual machine to change scope on:")
VMScope = InputBox("Specify the new scope to be used:")
' Получить экземпляр службы WMI в пространстве имен виртуализации

Set WMIService=GetObject("winmgmts:\\.\root\virtualization")
' Получить объект VMManagementService

Set VMManagementService = WMIService.ExecQuery("SELECT * FROM
Msvm_VirtualSystemManagementService").ItemIndex(0)
' Получить объект VM, который мы хотим модифицировать

Set VM=(WMIService.ExecQuery
("SELECT * FROM Msvm_ComputerSystem WHERE ElementName='" &
VMName & "'")).ItemIndex(0)
' Получить VirtualSystemGlobalSettingsData для модифицируемой VM

Set VMSystemGlobalSettingData =
(VM.Associators_("MSVM_ElementSettingData",
"Msvm_VirtualSystemGlobalSettingData")).ItemIndex(0)
' Изменить свойство ScopeOfResidence

VMSystemGlobalSettingData.ScopeOfResidence = VMScope
' Обновить VM при помощи ModifyVirtualSystem

Result = VMManagementService.ModifyVirtualSystem(VM.Path_.Path,
VMSystemGlobalSettingData.GetText_(1))
После применения новой области действия к подмножеству виртуальных машин поль-

зователи из той группы, которой присвоена роль Virtual Machine Manager, получат воз-
можность использовать оснастку Hyper-V Manager и управлять назначенными им вир-
туальными машинами.
На прилагающемся к этой книге компакт-диске вы найдете каталог \Scripts\Chapter 6
\Scopes. В этом каталоге есть три скрипта: ChangeVMScope.vbs, ClearVMScope.vbs и
DisplayVMScope.vbs. Скрипт ChangeVMScope.vbs позволяет изменить свойство
ScopeOfResidence виртуальной машины. Скрипт DisplayVMScope.VBS позволяет вам
просматривать область действия каждой виртуальной машины. И наконец, скрипт
ClearVMScope.vbs позволяет сбросить свойство ScopeOfResidence виртуальной машины в
значение по умолчанию.
Обзор лучших практик по безопасности Hyper-V

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

в родительском разделе Hyper-V
Развертывание Hyper-V на инсталляции Server Core позволит вам достичь наименьше-
го возможного пространства атак на сервер Hyper-V. Поскольку инсталляция Server
Core устанавливает только необходимые для конкретной роли (такой, как Hyper-V)
компоненты и не инсталлирует никаких инструментов управления с графическим ин-
терфейсом, то не только пространство для атак минимизируется, но и трудоемкость
обслуживания уменьшается (поскольку нужно меньше обновлений), уменьшается так-
же и время простоев.
Чтобы узнать об инсталляции Server Core, см. главу 4.
Поскольку инсталляция Server Core сервера Hyper-V не устанавливает инструментов

управления Hyper-V, то вам придется управлять серверами Hyper-V удаленно с других
компьютеров (под управлением Windows Server 2008 или Windows Vista SP1).
Чтобы узнать о том, как удаленно управлять инсталляцией типа Server Core сервера
Windows Server 2008 Hyper-V, см. главу 12.
Запуск приложений
только в дочерних разделах
Родительский раздел Hyper-V должен быть выделен для управления дочерними разде-
лами, и в нем не должно работать никаких приложений (таких, как Exchange Server или
SQL Server). Инсталлированное в родительском разделе приложение может в принципе
вызвать его блокировку или зависание, что повлияет на все дочерние разделы. Поэтому
запускайте приложения только в дочерних разделах, которые изолированы от роди-
тельского раздела и от других дочерних разделов. Если работающее в дочернем разде-
ле приложение зависнет, то оно не повлияет на выполнение или производительность
приложений в других разделах.
Определение уровней безопасности

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

с наименьшими привилегиями
Поскольку платформа виртуализации может обеспечивать работу нескольких вирту-
альных машин, имеющих разные группы администраторов, то очень важно определить
такую политику авторизации, которая соблюдает принцип наименьших привилегий.
Поэтому не следует ни предоставлять права локального администратора сервера Hyper-V,
ни использовать роль по умолчанию Hyper-V Administrator в Authorization Manager для
присвоения разрешений тем группам и пользователям, которым нужен доступ только к
некоторому подмножеству виртуальных машин. Вместо этого вам нужно расширить
политику по умолчанию Hyper-V Authorization Policy (определив новые роли и области
действия, которые соответствуют административной модели вашей организации) и
предоставлять новым ролям только наименьшие привилегии, которые позволят выпол-
нять их рабочие функции.
ВАЖНО
Помните, что в родительском разделе учетные записи с административными разрешения-
ми могут делать такие изменения конфигурации Hyper-V, которые могут повлиять на все
дочерние разделы сервера Hyper-V, в то время как учетные записи с административными
разрешениями дочернего раздела имеют административные привилегии только в этом до-
чернем разделе.
Реализация строгой стратегии обновлений

Одним из преимуществ переноса рабочих нагрузок серверов на виртуальные машины
является то, что виртуальная машина состоит из набора переносимых файлов, которые
можно легко развернуть и мигрировать на другой сервер Hyper-V. Кроме того, при на-
личии возможности более быстрого развертывания новых виртуальных машин (при
помощи наборов файлов-шаблонов) весьма важной становится реализация строгой
стратегии обновлений (для обслуживания как работающих, так и находящихся в авто-
номном режиме виртуальных машин). Если вы используете System Center Configuration
Manager, Windows Update Services или другие приложения для обновлений, то не за-
будьте расширить их применение и на вашу структуру виртуализации.
Вы можете также обдумать возможность развертывания одного или нескольких серве-
ров Hyper-V в качестве хостов обслуживания. Такой хост — это сервер Hyper-V, кото-
рый выделен для создания, промежуточного хранения и обновления виртуальных ма-
шин (перед развертыванием их в производственной среде). Когда виртуальная машина
будет полностью обновлена, вы сможете использовать Quick Migration для переноса ее
на производственный сервер Hyper-V. Либо вы можете использовать менеджер System
Center Virtual Machine Manager для переноса виртуальной машины между серверами
Hyper-V (руководствуясь определенными критериями по загрузке серверов).
Выделение физического сетевого адаптера

для родительского раздела
Из соображений производительности и безопасности на каждом производственном
сервере Hyper-V родительскому разделу следует выделить отдельный сетевой адаптер.
Кроме того, используйте дополнительные физические сетевые адаптеры для изоляции
сетевого трафика работающих в дочерних разделах виртуальных машин. Такая страте-
гия даст вам также максимальную гибкость в смысле обеспечения безопасности сете-
вого трафика при помощи VLAN, IPSEC и других протоколов.
Использование в родительском разделе шифрования

дисков BitLocker
Если вам нужно защитить ваши серверы Hyper-V от воровства данных (и в том числе
физического), то вам следует рассмотреть возможность реализации в родительском
разделе технологии Windows BitLocker Drive Encryption, чтобы обеспечить безопас-
ность процесса загрузки системы и файлов виртуальной машины в системах совмест-
ного хранения. Поскольку это сложная технология, то стратегию ее развертывания
следует тщательно спланировать.
Дополнительную информацию по планированию и проектированию технологии Windows
BitLocker Drive Encryption см. в руководстве BitLocker Design Guides, которое вы можете
скачать по ссылке: http://go.microsoft.com/fwlink/?LinkId=134201.
Реализация или расширение стратегии аудита

Еще до развертывания вашей инфраструктуры Hyper-V вам следует расширить вашу
текущую стратегию аудита и включить в нее сбор, анализ и отчеты по событиям сис-
темы безопасности Hyper-V. Если вы находитесь на стадии планирования и разработки
стратегии аудита, то можете использовать инструменты аудита от сторонних компа-
ний, либо System Center Operations Manager 2007 Audit Collection Services (ACS). ACS
собирает, сводит воедино и генерирует отчеты по данным журналов безопасности
Windows в реальном времени.
Подробности о System Center Operations Manager 2007 ACS см. по адресу:
http://download.microsoft.com/download/E/E/7/EE797D69-02B2-420D-B0F2-
196906CCE063/Whitepaper-Audit_Collection_with_System_Center_Operations_
Manager_2007_final.pdf.
Обеспечение безопасности доступа

к виртуальной машине
Как описано в табл. 6.1, сервер Hyper-V создает несколько каталогов в
%ProgramData%\Microsoft\Windows\Hyper-V в качестве местоположения по умолчанию
для файлов виртуальных машин (xml, vhd, avhd, vsv и bin). По умолчанию файлы VHD
хранятся в %Users%\Public\Public Documents\Hyper-V\Virtual Hard Disks, а пустой
флоппи-диск — в %Users%\Public\Public Documents\Hyper-V\Blank Floppy Disk.
Когда создается новая виртуальная машина, то в иерархии каталогов создается соот-
ветствующий каталог, в который и помещаются файлы виртуальной машины. Однако в
производственных условиях файлы виртуальной машины обычно не хранятся в место-
положении по умолчанию. Требования по архитектуре, производительности и сами
размеры файлов приводят к тому, что каталоги виртуальных машин обычно находятся
на одной или нескольких централизованно управляемых системах хранения (или фай-
ловых серверах).
ВАЖНО
Если вы указываете другое местоположение хранения для файлов виртуальных машин,
убедитесь в том, что учетная запись System и группа Administrators имеют разрешения Full
Control на новые каталоги.
Каждая иерархия каталогов виртуальных машин должна быть защищена прямым при-
менением разрешений NTFS (в соответствии с вашими организационными потребно-
стями). Это предотвратит создание, копирование, замену или удаление файлов вирту-
альных машин неавторизованными пользователями. Однако поскольку каждая вирту-
альная машина работает в контексте рабочего процесса виртуальной машины, то поль-

зователи с соответствующими правами доступа к Hyper-V могут выполнять задачи
управления в Authorization Manager (например, останавливать и запускать виртуальные
машины), несмотря на ограничения разрешений доступа к файлам виртуальных машин
в NTFS. Поэтому обеспечение безопасности доступа к виртуальным машинам требует
определенной стратегии, которая сочетает настройку соответствующих разрешений
NTFS для файлов виртуальных машин и применение строгой политики авторизации
для ограничения возможностей по управлению виртуальными машинами.
Идентификаторы SID виртуальных машин Hyper-V
В Hyper-V при помощи Authorization Manager реализована политика авторизации на базе
ролей. Однако ему нужно получать доступ из рабочего процесса виртуальной машины к та-
ким ресурсам, как файлы виртуальных жестких дисков, которые защищены списками дос-
тупа DACL. Одним из возможных решений этой проблемы является запуск рабочих процес-
сов под учетной записью SYSTEM (подобно Virtual Machine Management Service (VMMS)).
Однако учетная запись SYSTEM имеет полный и неограниченный доступ к родительскому
разделу. Это нежелательно, поскольку если дочерний раздел сможет как-то получить дос-
туп к своему рабочему процессу, то он получит полный контроль над родительским разде-
лом.
Для защиты от такого варианта VMMS создает и управляет специальным идентификатором
безопасности (security identifier, SID), который уникален для каждой виртуальной машины.
Этот SID называется идентификатором SID виртуальной машины (или VM SID). В окне
Windows Explorer VM SID выглядит как "NT VIRTUAL MACHINE\<VMID>", где <VMID> — это
уникальный идентификатор GUID виртуальной машины. Когда защищенный списком DACL
ресурс подключается к виртуальной машине, то VMMS модифицирует список DACL этого
ресурса, чтобы предоставить доступ для идентификатора VM SID. VMMS создает при по-
мощи учетной записи NETWORK SERVICE специальный маркер доступа (в качестве основ-
ного идентификатора учетной записи) и включает VM SID в список идентификаторов SID
маркера. После этого рабочий процесс виртуальной машины работает при помощи этого
специального маркера. Это позволяет Hyper-V предоставить специфичный для рабочего
процесса данной виртуальной машины доступ к ресурсам, а также снижает риск компроме-
тации рабочего процесса. Использование VM SID улучшает также и изоляцию рабочих про-
цессов виртуальных машин (поскольку никакие два рабочих процесса не имеют одинаково-
го VM SID).
Для того чтобы все рабочие процессы виртуальных машин получили доступ к обычным за-
щищенным списками DACL ресурсам, VMMS также создает и обслуживает еще один спе-
циальный идентификатор SID под названием VM Group SID. В окне Windows Explorer иден-
тификатор VM Group SID выглядит как "NT VIRTUAL MACHINE\VirtualMachines". Когда
VMMS создает специальный маркер доступа для запуска рабочего процесса виртуальной
машины, она добавляет VM Group SID в список SID (в дополнение к VM SID). Использова-
ние VM Group SID помогает улучшить изоляцию между коллекцией рабочих процессов вир-
туальных машин и прочими службами, работающими как NETWORK SERVICE в родитель-
ском разделе.
Эд Рид (Ed Reed, Senior Software Design Engineer (Windows Virtualization))
В обычной производственной среде часто бывает необходимо иметь несколько разных

администраторов, которые управляют разными виртуальными машинами одного сер-
вера Hyper-V. Так бывает тогда, когда основные рабочие нагрузки администрируются
центральной группой администраторов, бизнес-нагрузки отделов администрируются
группой отдела, а тестовые нагрузки (и нагрузки разработки программного обеспече-
ния) администрируются командами проектов (или отдельными их членами).
Конфигурирование каталогов виртуальных машин

с центральным управлением
Самые важные для бизнеса рабочие нагрузки обычно управляются центральной коман-
дой администраторов. К таким нагрузкам обычно относятся основные инфраструктур-
ные службы — такие, как Active Directory, Domain Name Service (DNS), и Dynamic Host
Configuration Protocol (DHCP). Приложения масштаба предприятия (такие, как сервер
Microsoft Exchange Server) представляют собой другую категорию рабочих нагрузок,
которая также часто управляется централизованно. На рис. 6.17 показано, как органи-
зовать и управлять разрешениями иерархии каталогов виртуальной машины при нали-
чии центральной команды администраторов (которая может состоять из нескольких
более мелких команд), отвечающей за управление основными рабочими нагрузками.
В этой модели каталоги рабочих нагрузок содержат каталоги отдельных виртуальных
машин. Разрешения NTFS присваиваются рабочим нагрузкам, и каталоги виртуальных
машин строго настраиваются, чтобы ограничить доступ только членами группы ме-
неджеров виртуальных машин, которая управляет рабочими нагрузками. Более того,
наследование разрешений реализуется только на уровне каталогов виртуальных ма-
шин.
ВАЖНО
В условиях среды с высокой безопасностью (или регламентированной среды) файлы вир-
туальных машин для разных виртуальных нагрузок может потребоваться изолировать на
серверах и системах хранения с очень тщательно контролируемыми правами доступа.
Рис. 6.17. Безопасность виртуальных машин для централизованно управляемых рабочих нагрузок
Конфигурирование организационно управляемой

безопасности виртуальных машин
В большинстве сред бизнес-приложения управляются по децентрализованной модели
администрирования. Такие приложения обычно администрируются на уровне отдела,
бизнес-подразделения или другом организационном уровне. В такой ситуации важно
применить соответствующие разрешения к каталогам виртуальных машин на системах
совместного хранения и обеспечить права доступа только соответствующей команде
администраторов. На рис. 6.18 показано, как вы можете организовать и управлять раз-
решениями на иерархию каталогов в такой среде, где одна или несколько виртуальных
машин управляются на уровне отделов.
Рис. 6.18. Безопасность виртуальных машин для управляемых на уровне отделов рабочих нагрузок
В этой модели каталоги отделов содержат каталоги виртуальных машин. Разрешения

NTFS, примененные к каталогам отделов и каталогам виртуальных машин, сконфигу-
рированы так, чтобы ограничить доступ только группой менеджеров, управляющих
виртуальными машинами отдела. Наследование разрешений также реализовано только
на уровне каталогов виртуальных машин.
Конфигурирование управляемой на уровне проектов

безопасности виртуальных машин
В тестовых средах и средах разработки программного обеспечения обычно в работе
одновременно находится несколько проектов. Каждый проект имеет свою команду,
членам которой поручено выполнять определенные обязанности. В такой ситуации для

жизненного цикла проекта нужны как виртуальные машины проекта, так и индивиду-
альные виртуальные машины. Здесь опять-таки важно применить соответствующие
разрешения к каталогам виртуальных машин на общих системах хранения и обеспе-
чить доступ к виртуальным машинам только соответствующим командам или отдель-
ным ее членам. На рис. 6.19 показано, как вы можете организовать и управлять разре-
шениями для иерархии каталогов в среде тестирования и разработки.
Рис. 6.19. Безопасность виртуальных машин для управляемых проектами рабочих нагрузок
В этой модели каталоги групп тестирования и разработки содержат подкаталоги от-

дельных проектов. Внутри каждого подкаталога проекта создаются отдельные катало-
ги виртуальных машин, доступ к которым ограничен отдельными членами команды.

Есть также каталог виртуальных машин уровня проекта, доступ к которому имеют чле-
ны команды, но модифицировать который могут только группы менеджеров виртуаль-
ных машин. Наследованные разрешения в этой иерархии каталогов не разрешены.
Резюме
Для того чтобы должным образом обеспечить безопасность ресурсов Hyper-V, важно
понять те компоненты, которые нуждаются в защите. Вы должны предоставлять права
доступа к ресурсам Hyper-V и виртуальных машин при помощи сочетания политики
авторизации и разрешений NTFS. Во всех случаях определите необходимые для вашей
среды роли управления, создайте определения ролей и их присваивания в менеджере
Authorization Manager, создайте соответствующие группы безопасности, поместите
в них соответствующих членов и присвойте этим группам соответствующие роли.
Иерархии каталогов виртуальных машин должны быть четко определены, и безопас-
ность их должна быть обеспечена в соответствии с требованиями к управлению вирту-
альными машинами в вашей среде. Для обеспечения безопасности доступа к Hyper-V и
виртуальным машинам важно изучать и применять лучшие практики по безопасности.

Web-сайт компании Microsoft, руководство "Windows Server 2008 Security Guide",
доступное по адресу:
http://www.microsoft.com/downloads/details.aspx?FamilyID=fb8b981f-227c-4af6-
a44bb115696a80ac;
Web-сайт Microsoft Technet, документ "Authorization Manager", доступный по ад-
ресу: http://technet.microsoft.com/en-us/library/cc726036.aspx;
блог Microsoft Technet Blog, блог Windows Virtualization Team Blog по адресу:
http://blogs.technet.com/virtualization/default.aspx;
блог Microsoft Technet Blog, документ "Hyper-V How To: Plan Security", доступный
по адресу:
http://blogs.technet.com/tonyso/archive/2008/11/20/Hyper-V-how-to-plan-
security.aspx.
ГЛАВА 7
и оптимизация сервера Hyper-V
В этой главе даны рекомендации и лучшие практики по конфигурированию хоста
Hyper-V и виртуальных машин (с целью оптимизации их производительности). Данная
глава содержит модификацию настроек Hyper-V по умолчанию, разбор лучших прак-
тик по производительности виртуальных машин, а также практические соображения.
Приведены рекомендации по настройке производительности для процессора, памяти,
сети и системы хранения.
Модификация инсталляции по умолчанию

сервера Hyper-V
Инсталляция по умолчанию роли Hyper-V на сервере Windows Server 2008 или сервера
Microsoft Hyper-V Server 2008 подразумевает наличие только одного системного тома
(диск С:). Поэтому местом хранения по умолчанию для виртуальных жестких дисков и
файлов виртуальных машин является диск С:, где они хранятся в двух отдельных ката-
логах:
путь хранения виртуальных машин по умолчанию:
C:\ProgramData\Microsoft\Windows\Hyper-V;
путь хранения виртуальных жестких дисков:
C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks.
Использование установок по умолчанию позволяет быстро создавать виртуальные ма-
шины (просто указав название виртуальной машины), но при таком создании вирту-
альных машин их файлы будут храниться на системном томе. Если вы используете ди-
намически расширяющиеся виртуальные жесткие диски (по умолчанию) или делаете
моментальные снимки виртуальной машины, то вы очень быстро израсходуете имею-
щееся на системном томе свободное пространство. До создания первой виртуальной
машины места хранения следует изменить на другой (не системный) том.
Для изменения мест хранения по умолчанию выполните следующие шаги (локально на
сервере Hyper-V или удаленно при помощи оснастки Hyper-V Manager):
1. Запустите оснастку Hyper-V Manager для ММС.

2. Если вы управляете удаленным сервером Hyper-V, то щелкните правой кнопкой
мыши по пункту Hyper-V Manager в верхней части дерева в левой панели и выбери-
те пункт Connect To Server. На рис. 7.1 показано появляющееся после этого диало-
говое окно Select Computer. Отметьте переключатель Another Computer и введите
сервер Hyper-V (либо нажмите кнопку Browse для перехода к нужному серверу
Hyper-V), а затем нажмите кнопку OK.
Рис. 7.1. Выберите сервер Hyper-V для удаленного управления
Рис. 7.2. Настройки Hyper-V

Глава 7. Лучшие практики и оптимизация сервера Hyper-V 283
3. Когда вы управляете нужным вам сервером Hyper-V, выберите опцию Hyper-V

Settings в меню Actions с правой стороны.
4. На рис. 7.2 показано диалоговое окно Hyper-V Settings. Первые две опции позво-
ляют вам изменить места хранения по умолчанию. При модификации этих опций
используйте кнопку Browse для выбора другого каталога компьютера.
5. После изменения мест хранения на другой (не системный) том нажмите кнопку OK.
Изменить места хранения по умолчанию — это хорошая идея, однако при создании новой
виртуальной машины следует также помечать опцию Store the Virtual Machine In A Dif-
ferent Location и указывать путь для файлов виртуальной машины. При этом в указанном
месте будет создан подкаталог (с именем виртуальной машины) и в нем будет сохранен
виртуальный жесткий диск, файл конфигурации и файлы сохранения состояния.
Переименуйте первую внешнюю виртуальную сеть

Когда вы создаете первую внешнюю виртуальную сеть, то она получает название по
физическому сетевому адаптеру. Это происходит автоматически при инсталляции роли
Hyper-V (если вы выбрали сетевой адаптер во время работы мастера инсталляции). Это
не происходит при инсталляции роли Hyper-V из командной строки, а также в сервере
Microsoft Hyper-V Server 2008. Проблема состоит в том, что большая часть серверного
оборудования поставляется с двумя одинаковыми сетевыми интерфейсами, которые
различаются только наличием номера ("#2") в имени адаптера. Это означает, что вир-
туальные сетевые адаптеры (с названием по умолчанию) будет тяжело отличить в ин-
терфейсе пользователя.
Для решения этой проблемы вам следует переименовать виртуальную сеть по умолча-
нию (использовав нечто, имеющее смысл в вашей среде). Например, вы можете ис-
пользовать что-то совсем простое (вроде "Intranet"), либо нечто более описательное
(например, "сеть 10.10.1.0, подключенная через гигабитный интерфейс"). Цель состоит
в том, чтобы использовать некое уникальное название, которое идентифицирует под-
ключенную сеть и позволит вам уверенно выбирать правильную виртуальную сеть
в мастере New Virtual Machine Wizard.
Отличайте внешние виртуальные сети от внутренних. Вы можете установить стандарт
именования и предварять названия всех внутренних виртуальных сетей одним и тем же
префиксом. При использовании одинакового префикса все внутренние сети будут отобра-
жаться в раскрывающемся списке рядом друг с другом.
Используйте для виртуальных сетей

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

Сервер Hyper-V использует хранилище авторизации, которое управляет тем, какие ро-
ли имеют доступ для выполнения разрешенных действий. По умолчанию определена
только одна роль (с названием Administrators). Эта роль имеет полный доступ ко всем
разрешенным операциям Hyper-V. Хранилище авторизации называется InitialStore.xml
и находится по умолчанию в C:\ProgramData\Microsoft\Windows\Hyper-V\.
Если хранилище авторизации повреждено или отсутствует, то вы не сможете выпол-
нять такие обычные задачи, как запуск виртуальной машины, редактирование вирту-
альных сетей, создание новых виртуальных машин. Для создания резервной копии
файла InitialStore.xml просто скопируйте его из места хранения по умолчанию в другое
место системы (либо на удаленный сервер, либо на съемный носитель).
Повторная инициализация файла InitialStore.xml
Несмотря на то, что вы можете использовать режим разработчика в оснастке Authorization
Manager для создания нового хранилища, создания приложения Hyper-V Services, добавле-
ния роли Administrators, добавления всех определений операций и создания присваивания
роли — все это будет напрасно, поскольку Hyper-V зависит от конкретных GUID в исходном
файле InitialStore.xml.
Если по какой-то причине вы не сделали резервную копию хранилища авторизации
InitialStore.xml вашего сервера Hyper-V и она была повреждена — не пугайтесь. Существует
простой способ вернуть его обратно. Все, что вам нужно, — это другой сервер Hyper-V
с немодифицированным файлом InitialStore.xml. Скопируйте InitialStore.xml с другого серве-
ра на ваш сервер Hyper-V и замените им поврежденную версию.
Майк Вильямс (Mike Williams, Senior Consultant II (Microsoft Services))
Включаем удаленный рабочий стол

Виртуальные машины не имеют физической консоли, за которую вы можете сесть и
работать, поэтому все взаимодействие ведется с удаленной консоли. Для обеспечения
удаленного интерфейса к виртуальной машине Hyper-V использует выделенного кли-
ента под названием VMConnect.exe. VMConnect использует для этого интерфейса про-
токол Remote Desktop Protocol (RDP) с модулем прослушивания Single Port Listener на
TCP-порту с номером 2179. Этот порт (при инсталляции Hyper-V) по умолчанию до-
бавляется как правило исключения для межсетевого экрана.
VMConnect позволяет вам подключаться к серверу Hyper-V и перенаправлять удален-
ный рабочий стол любой виртуальной машины, к которой вы имеете доступ.
VMConnect использует ресурсы сервера Hyper-V для установления удаленного под-
ключения и передачи обновлений экрана. Если VMConnect используется локально на
сервере Hyper-V для подключения к виртуальным машинам, то он запускает отдельную
копию VMConnect для каждого удаленного сеанса. Каждый сеанс VMConnect исполь-
зует примерно 20 Мбайт оперативной памяти.
Установление слишком большого количества сеансов VMConnect на консоли сервера
Hyper-V может израсходовать ценную оперативную память, которую можно было бы
использовать для запуска еще одной виртуальной машины. Лучше включить в вирту-
альной машине удаленный рабочий стол Remote Desktop и использовать его для под-
ключения к виртуальной машине и управления ею.
В отличных от семейства Windows гостевых операционных системах удаленного рабочего
стола Remote Desktop нет, поэтому в таких случаях VMConnect является наилучшим вари-
антом для удаленного управления виртуальными машинами из операционной системы
Windows.
Если вы предпочитаете для управления виртуальными машинами использовать
VMConnect, то вам следует делать это с другого сервера Windows Server 2008, из Windows
Vista, либо из Windows 7 (имеющих инструменты Remote Server Administration Tools
(RSAT)). При этом расход памяти не будет оказывать влияние на сервер Hyper-V.
Оптимизация
производительности сервера
Для настройки вашего сервера Hyper-V для получения наилучшей производительности
нужно сосредоточиться на четырех основных областях конфигурирования: процессор,
память, дисковая подсистема, сетевые адаптеры. Использование самых производи-
тельных аппаратных компонентов является хорошим началом, но способ их комбини-
рования для получения оптимальной конфигурации не всегда является очевидным.
В этом разделе вы узнаете о четырех областях конфигурирования и о наилучших прак-
тиках для получения оптимальной производительности вашего сервера Hyper-V.
Максимизация производительности процессора

Для Hyper-V требуется 64-битный процессор Intel или AMD с аппаратной поддержкой
виртуализации (с технологией Intel VT или AMD-V). Использование нескольких про-
цессоров не дает линейного прироста производительности, но Hyper-V (как многопо-
точное приложение) может полностью использовать несколько процессоров.
Виртуализация серверов имеет наивысшую производительность на серверах с несколь-

кими процессорами, поскольку основная идея — это консолидация рабочих нагрузок
(с нескольких физических серверов) на сервере под управлением гипервизора. Это по-
зволяет вам взять группу серверов, которые работают с низким коэффициентом
использования процессора и перенести их на один сервер (чтобы максимально исполь-
зовать мощность). Поскольку количество одновременно выполняющихся потоков на-
прямую связано с количеством имеющихся процессорных ядер, то наилучшей конфи-
гурацией является хост с несколькими ядрами. Для максимизации количества процес-
соров и минимизации занимаемой сервером площади рекомендуется покупать самые
новые многоядерные процессоры (что даст вам наилучшее соотношение "цена/
производительность").
Сервер Hyper-V поддерживает до 24 логических процессоров (LP) на физический сер-
вер и восемь виртуальных процессоров (VP) на логический процессор. Hyper-V под-
держивает максимум 192 виртуальных машины на один сервер. Это означает, что ком-
пания Microsoft провела тестирование только до такой конфигурации, а не то, что
Hyper-V не может расширяться до большего количества. Это также диктуется и теми
типичными серверами, которые в данный момент продаются. Большинство серверов
сегодня — это двух- или четырехпроцессорные серверы с двумя, четырьмя или шестью
ядрами на процессор. Если вы купите сервер, который имеет более 24 процессоров или
ядер, то можете разбить сервер на разделы по 24 процессора (или ядра) и запустить
отдельную копию Hyper-V в каждом разделе (чтобы полностью использовать ваше
оборудование).
Для того чтобы получить поддержку 24 логических процессоров и 192 одновременно рабо-
тающих виртуальных машин, вы должны инсталлировать обновление KB956710.
Выбор процессора с большим размером кэша L2 или L3 также может повысить произ-
водительность. Это характерно для таких рабочих нагрузок, которые держат в памяти
большой рабочий набор и могут выиграть от его предварительного кэширования.
Большой размер кэша также помогает тем серверам Hyper-V, которые имеют большое
соотношение количества виртуальных процессоров к количеству логических процес-
соров.
Для достижения наилучшей процессорной производительности для Hyper-V рекомен-
дуется выполнить инсталляцию типа Server Core (как для Windows Server 2008 с ролью
Hyper-V, так и для сервера Microsoft Hyper-V Server 2008). Windows Server 2008 с един-
ственной загруженной в родительском разделе ролью Hyper-V минимизирует количе-
ство требуемой для родительского раздела вычислительной мощности, что оставляет
большее ее количество для дочерних разделов.
Максимизация производительности памяти

Количество имеющейся памяти очень важно для среды Hyper-V, поскольку Hyper-V
использует для загрузки и выполнения виртуальных машин только физическую память.
Если вы должным образом спланируете требования к памяти и конфигурацию сервера
Hyper-V, то получите хорошую производительность виртуальных машин.
Типы памяти
Материнские платы могут использовать разные типы памяти (в зависимости от исполь-
зованного процессора и набора микросхем). Выбор памяти обычно представляет собой
компромисс между скоростью и емкостью. Выбирая более быстрые микросхемы памя-
ти, вы можете снизить максимальный размер доступной для вашей системы памяти.
Это снижение может быть связано с производительностью системной шины или про-
сто следствием того факта, что быстрая память еще не выпускается в микросхемах вы-
сокой плотности. Например, одна и та же материнская плата может поддерживать па-
мять, которая работает как на частоте 667 МГц, так и на частоте 800 МГц. Материнская
плата может поддерживать до 64 Гбайт памяти в модулях по 8 Гбайт на каждый слот.
Модули такого объема могут быть доступны в варианте 667 МГц, но отсутствовать в
варианте 800 МГц. Выбрав память 800 МГц из-за ее скорости, вы можете недобрать
максимальное количество устанавливаемой в сервер памяти (по крайней мере, до тех
пор, пока не появятся модули памяти более высокой плотности).
Выбор наилучшей конфигурации памяти для сервера Hyper-V зависит от цели вашей сис-
темы. Если ее цель состоит в достижении максимальной возможной производительности
памяти для сервера Hyper-V, используйте максимально быструю память. Если же цель со-
стоит в том, чтобы получить наилучшую возможную производительность, но выполнять при
этом максимально возможное для сервера количество виртуальных машин, то используйте
такую память, которая даст вам максимальный ее объем, и компенсируйте другими компо-
нентами (более быстрыми процессорами или более скоростной дисковой подсистемой).
Покупайте серверы с модулями памяти максимально возможной плотности, чтобы в даль-
нейшем производить ее наращивание без потери количества слотов. Например, вы можете
установить 16 Гбайт памяти либо шестнадцатью модулями по 1 Гбайт, либо восемью по
2 Гбайт, либо четырьмя по 4 Гбайт, либо двумя по 8 Гбайт. Используя модули по 8 Гбайт,
вы получите максимальное количество памяти при помощи минимального количества сло-
тов. Это позволит вам расширить сервер путем добавления дополнительных модулей па-
мяти (без удаления модулей низкой плотности).
Конфигурация памяти
Производительность микросхем памяти — это не единственное соображение при
оценке производительности виртуальных машин. Те виртуальные машины, которым
выделено слишком мало памяти, производят интенсивную выгрузку содержимого па-
мяти на диск. Доступ к диску обычно измеряется миллисекундами (т. е. 10–3 секунды),
в то время как доступ к памяти измеряется наносекундами (т. е. 10–9 секунды). То есть
извлечение данных из памяти в миллион раз быстрее, чем с диска. Поскольку доступ
к дискам в виртуальной среде имеет дополнительные накладные расходы, то фактиче-
ская разница становится еще больше. Уменьшение подкачки памяти с диска повысит
производительность виртуальных машин.
Родительскому разделу требуется память для предоставления таких служб, как: вир-
туализация ввода/вывода, моментальные снимки, удаленный доступ, а также для об-
щих задач управления. Операционным системам внутри виртуальных машин требуется
не меньше памяти, чем на реальных компьютерах. Дочерним разделам нужна дополни-
тельная память для интерфейсов управления и обмена с родительским разделом (физи-

ческие среды не требуют этих дополнительных интерфейсов и не имеют таких допол-
нительных затрат памяти). Размер этих затрат варьируется, но типичными значениями
является 32 Мбайт дополнительной памяти для первого гигабайта памяти виртуальной
машины и дополнительные 8 Мбайт памяти на каждый дополнительный гигабайт па-
мяти виртуальной машины.
Физические серверы обычно покупаются в стандартной конфигурации. Многие физи-
ческие серверы приобретаются с бо́льшим количеством памяти, чем требуется для ра-
бочих нагрузок. Базовой конфигурацией физического сервера вполне может быть
4 Гбайт памяти, хотя его конкретная рабочая нагрузка может никогда не использовать
более 2 Гбайт памяти. Виртуальным машинам Hyper-V память может выделяться бло-
ками по 1 Мбайт, так что при желании память для дочерних разделов может выделять-
ся весьма точно.
Проанализируйте существующие стандарты выделения памяти на физических серверах
для того, чтобы (при конвертации физического компьютера в виртуальную машину) опре-
делить фактическое требуемое количество памяти. На существующих серверах используй-
те такие инструменты, как System Center Operations Manager, чтобы получить ретроспек-
тивный отчет по использованию памяти (для определения максимального требуемого ко-
личества памяти).
При вычислении количества памяти для физического сервера, для родительского раздела
следует предусмотреть как минимум 1 Гбайт памяти.
Доступ к неоднородной памяти (NUMA)

Еще одно соображение относительно памяти — это архитектура процессора и мате-
ринской платы. Доступ к неоднородной памяти (Non-Uniform Memory Access,
NUMA) — это архитектурная особенность современных многопроцессорных плат-
форм. Архитектура NUMA комбинирует процессор, шину ввода/вывода и память в
единый "узел", который настраивается для достижения наивысшей производительно-
сти. Эти узлы соединены высокоскоростной шиной. При работе с памятью своего узла
процессор имеет более быстрый доступ, меньшие задержки и более широкую полосу
пропускания. Когда же серверу нужно получить доступ к памяти другого узла через
системную шину, то производительность этого процесса снижается из-за увеличенных
задержек и пониженной полосы пропускания. Правильная настройка компьютера с
архитектурой NUMA позволяет максимально использовать локальный доступ к памяти
при одновременной минимизации доступа к памяти через системную шину. Непра-
вильно сконфигурированный сервер, имеющий такую архитектуру, может существенно
потерять производительность.
Конфигурирование сервера с архитектурой NUMA требует понимания требований
к памяти со стороны работающих в системе виртуальных машин. Для правильной
настройки памяти системы NUMA вам нужно равномерно распределить память, при-
своенную каждому процессору. Это даст каждому процессору локальный кэш одина-
кового размера и минимизирует межузловые запросы к памяти. Количество памяти,
которое необходимо поставить в систему, зависит от комбинации факторов, в том чис-

ле от максимального блока памяти, требующегося виртуальной машине, количества
процессоров системы, размера линеек памяти, которые может принять система.
Если у вас есть виртуальная машина, которой выделяется 4 Гбайт памяти, то вы долж-
ны обеспечить наличие в каждом процессорном узле системы NUMA по крайней мере
4 Гбайт памяти (чтобы поток выполняющейся на процессоре виртуальной машины мог
получить всю память в локальном узле). Если у вас четыре процессорных узла, то ми-
нимальное количество памяти, которое вы должны установить в сервер, составляет
16 Гбайт (по 4 Гбайт на узел).
Коэффициент NUMA
Поставщики систем NUMA определили коэффициент NUMA, описывающий количество
времени, которое требуется узлу для доступа к "удаленной" памяти (памяти другого узла)
относительно своей "локальной" памяти. При значении коэффициента NUMA от 1,0 до 1,5
производительность практически не падает. Когда же это значение равно 3,0 или больше,
производительность уменьшается.
На работающих под управлением роли Hyper-V или сервера Microsoft Hyper-V Server сис-
темах NUMA с одним или более "безголовых" узлов (это узел с одной только памятью, без
процессоров), Hyper-V не будет выделять память из такого узла. Несмотря на то, что обыч-
но это видно при использовании параметра NUMPROC в хранилище данных конфигурации
загрузки, мы рекомендуем вам уточнить конфигурацию NUMA у производителя вашего обо-
рудования (чтобы понять, как правильно сконфигурировать память).
Роб Хефнер (Rob Hefner, Microsoft Services Support Engineer (Virtualization))
Для оптимальной производительности определите максимальное количество памяти, кото-
рое будет выделяться виртуальной машине на системе NUMA, а затем купите как минимум
столько памяти на каждый процессор. Память по процессорам следует распределить рав-
номерно (чтобы максимизировать использование памяти локального узла и уменьшить ко-
личество обращений к памяти другого узла). Поскольку виртуальная машина в Hyper-V мо-
жет иметь максимум 64 Гбайт памяти, то вам, может, и не удастся одновременно выделить
максимальное количество памяти и обеспечить ее наличие на одном процессорном узле.
Используйте вариант инсталляции Server Core для Windows Server 2008 с ролью Hyper-V.
По сравнению с полной инсталляцией это даст вам примерно 80 Мбайт лишней оператив-
ной памяти сервера для использования ее в дочерних разделах.
Максимизация производительности
системы хранения хоста
Серверу Hyper-V требуется система хранения для родительского раздела, дочерних
разделов, а также для хранения всяких специфичных для виртуализации вещей. Роди-
тельскому разделу требуется пространство для файлов операционной системы, файла
подкачки, файлов журналов, а также теневых копий для резервного копирования. Каж-
дому дочернему разделу требуется место для файлов операционной системы, файла
подкачки, файлов журналов, файлов приложений, хранения данных приложений, а
также теневых копий для резервного копирования. Несмотря на то, что это не обяза-
тельно, рекомендуется также резервировать пространство для файла дампа памяти (как
в родительском, так и в дочерних разделах). Пространство хранения дочернего раздела
инкапсулируется либо в виртуальный жесткий диск (VHD), либо в транзитный диск.
Специфичные для виртуализации потребности в хранении включают: файлы состояния
виртуальных машин, файлы конфигурации виртуальных машин, а также файлы авто-
матических виртуальных жестких дисков.
Масштабируемость сервера Hyper-V очень зависит от дисковой подсистемы. По мере
добавления на хост дополнительных виртуальных машин увеличивается нагрузка дис-
кового ввода/вывода. Одна виртуальная машина, которая создает большую нагрузку
дискового ввода/вывода, может серьезно снизить производительность других рабо-
тающих виртуальных машин.
Оценка приложений хоста,

влияющих на дисковую производительность
Влияющие на дисковую производительность (сервера Hyper-V) приложения следует
удалить или переконфигурировать, чтобы минимизировать их воздействие на диско-
вую производительность. Примером такого приложения является антивирусное про-
граммное обеспечение, которое обычно инсталлируется в родительский раздел сервера
Hyper-V. Антивирусное программное обеспечение обычно реализуется в виде фильт-
рующего драйвера для диска, который перехватывает все вызовы чтения и записи на
диск и сканирует информацию на наличие вирусов (до того, как разрешить завершение
такой операции). Антивирусное программное обеспечение обычно нацелено на испол-
няемые файлы, а также на прочие типы файлов, которые могут представлять угрозу
операционной системе хоста.
Службы Hyper-V и соответствующие расширения его файлов в большинстве антиви-
русных приложений по умолчанию из сканирования не исключаются. Большинство
антивирусных приложений позволяет вам исключать расширения файлов или процес-
сы из сканирования. Если вы исключаете расширение файла, то вы исключаете также и
любое приложение, которое читает или пишет в эти файлы (а это может быть вирус
или троян). Если же вы исключаете именно процессы, то любое другое приложение
при попытке открыть эти файлы будет сканироваться, что существенно повышает ве-
роятность обнаружения вируса или трояна.
Настройте антивирусное приложение на исключение расширений файлов или процессов.
Рекомендуется исключать из сканирования процессы (поскольку это обеспечивает более
высокую безопасность). При настройке антивирусного приложения на исключение процес-
сов управления сервером Hyper-V вам следует исключить службу Virtual Machine
Management (VMMS.exe) и службу Virtual Machine Worker Process (Vmwp.exe).
Если ваше антивирусное приложение не позволяет исключать процессы, то вы должны бу-
дете добавить расширения файлов vhd, avhd, vfd, vsv и xml в список исключений вашего
антивируса, чтобы они не сканировались.
Производительность дискового оборудования

Для получения наилучшей производительности дисков для ваших виртуальных машин
необходимо использовать высокоскоростные диски и распределять нагрузку дискового
ввода/вывода на как можно большее количество дисководов. Скорость чтения и записи

диска напрямую связана со скоростью вращения диска. Жесткие диски обычно дела-
ются со скоростями вращения 4200, 5400, 7200, 10 000 и 15 000 оборотов в минуту.
Самая часто встречающаяся скорость — 7200 оборотов в минуту.
Пластины жестких дисков организованы в концентрические окружности, называемые
дорожками. Каждая дорожка разделена на секторы, которые похожи на маленькие ду-
ги. При вращении пластины головка чтения/записи позиционируется над дорожкой.
Чем быстрее крутится пластина, тем быстрее головка чтения/записи может получить
доступ к секторам (что увеличивает пропускную способность).
Для минимизации времени чтения/записи виртуальных машин используйте в сервере
Hyper-V диски со скоростью вращении 10 000 оборотов в минуту или более быстрые. Ис-
пользование диска со скоростью вращения 10 000 оборотов в минуту (вместо 7200 оборо-
тов) существенно увеличивает количество выполняемых за минуту операций чтения
и записи.
Как тип диска влияет на его производительность

Скорость диска — это только одна часть уравнения. Очень важен также и тип диска.
Сегодня используются диски типов Serial-ATA, Serial Attached SCSI (SAS) и SCSI. Все
типы дисков имеют разные характеристики производительности, причем большинство
типов содержит разные семейства дисков (с повышением производительности по мере
повышения цены). В табл. 7.1 показано сравнение характеристик производительности
стандартных дисков SATA, SAS и SCSI.
Таблица 7.1. Сравнение производительности дисков
Тип диска Пропускная способность Очередь команд

SATA 2,4 Гбайт/с на диск NCQ
SAS 6 Гбайт/с на диск TCQ
SCSI 2,5 Гбайт/с на совместно используемую шину
Диски работают по разным протоколам. Диски Serial Advanced Technology Attachment

(SATA), Small Computer System Interface (SCSI) и Serial Attached SCSI (SAS) могут соз-
давать очередь из запросов и принимать разумные решения относительно последова-
тельности выполнения операций. Новейшие диски SATA используют метод Native
Command Queuing (NCQ), в то время как диски SAS используют аналогичный метод
Tagged Command Queuing (TCQ). Оба метода предназначены для повышения произво-
дительности. Они позволяют жесткому диску создавать очередь из запросов вво-
да/вывода и динамически модифицировать порядок выполнения операций. Без очереди
команд для выполнения операций по порядку их поступления диску пришлось бы де-
лать дополнительные обороты и передвижения головок (что снижает эффективность).
При использовании очереди команд операции переупорядочиваются для минимизации
перемещений головок и оптимизации времени простоя головок чтения/записи. Такая
гибкость уменьшает задержки дисков.
Для использования преимуществ очереди команд используйте на серверах Hyper-V диски
SATA или SAS. Несмотря на то, что рекомендуется использовать диски на 10 000 оборотов
в минуту и более быстрые, тип выбранного вами диска и его скорость будут зависеть от
имеющегося в вашем распоряжении бюджета и (возможно) от имеющихся у вас контрактов
с поставщиками оборудования.
Конфигурирование дисков
Производительность системы хранения определяется используемыми компонентами и
конфигурацией этих компонентов. В число этих компонентов входят: тип жестких
дисков, их количество, скорость и количество контроллеров. Конфигурация — это
организация жестких дисков в массив. На производительность также влияет рабочая
нагрузка хоста и количество (а также местоположение) виртуальных машин в системе
хранения.
Работа одной виртуальной машины на одном выделенном для нее диске даст отличную
производительность. Но по мере увеличения количества виртуальных машин увеличи-
вается также и дисковая активность и один диск уже не сможет обеспечить приемле-
мую производительность чтения/записи. Увеличение количества жестких дисков уве-
личит пропускную способность системы хранения, а распределение виртуальных ма-
шин по разным дискам даст увеличение производительности. При подключении к
одному контроллеру множества дисков узким местом становится уже сам контроллер
(причем он становится также и единственной точкой отказа). Создание дискового мас-
сива — это лучший способ распределения дискового ввода/вывода между дисками
(и нет необходимости выделять по диску на виртуальную машину). Большинство мас-
сивов обеспечивает определенную избыточность, так что отказ диска не влияет на мас-
сив. Это достигается путем использования избыточных массивов недорогих дисков
(Redundant Array of Inexpensive Disks, RAID). Самые часто встречающиеся уровни
RAID показаны в табл. 7.2.
Таблица 7.2. Конфигурация RAID
Тип RAID Описание
RAID 0 (чередова- RAID 0 — это такая схема компоновки данных, при которой последовательные
ние) блоки определенного размера (модуль чередования) циклически размещаются
по нескольким дискам. Он представляет собой логический диск, который делит
доступ к диску между несколькими физическими дисками. Нагрузка системы
хранения распределяется между всеми физическими дисками.
Поскольку для избыточности данных никакая емкость не выделяется, то RAID 0
не имеет таких механизмов восстановления данных, которые имеются в других
уровнях RAID. Потеря любого диска приводит к утрате данных
RAID 1 (зеркали- RAID 1 — это такая схема компоновки данных, при которой каждый логический
рование) блок существует по меньшей мере на двух физических дисках. Логический диск
состоит из зеркальной пары дисков.
RAID 1 часто имеет худшие показатели пропускной способности и задержек,
чем RAID 0. Это происходит потому, что данные необходимо писать на два или
более физических дисков. Задержка запроса определяется самой медленной
из двух (или более) операцией записи, которые необходимо выполнить для
обновления всех копий соответствующих блоков данных.
Тип RAID Описание

RAID 1 может обеспечить более быстрое чтение, чем RAID 0, поскольку он
может читать с менее занятого физического диска зеркальной пары.
RAID 1 переносит потерю одного любого физического диска
RAID 0+1 (чередо- Сочетание чередования и зеркалирования дает преимущества производитель-
вание зеркал) ности массива RAID 0 и преимущества избыточности массива RAID 1.
Этот вариант известен так же, как RAID 1+0 и RAID 10.
RAID 0+1 обычно конфигурируется как зеркальный набор RAID 1 из двух мас-
сивов RAID 0.
RAID 0+1 может перенести потерю одного или более дисков в чередовании
RAID 5 (цикличе- RAID 5 представляет собой логический диск, состоящий из нескольких физиче-
ская четность) ских дисков, на которых последовательные блоки данных (модули чередова-
ния) размещены чередованием. Информация о четности на физических дисках
разбросана по всему дисковому массиву.
При запросах чтения RAID 5 показывает такие характеристики, которые напо-
минают характеристики RAID 0. Однако операции записи небольшого объема
данных на RAID 5 гораздо медленнее, чем на RAID 0, поскольку каждый блок
четности (соответствующий модифицируемому блоку данных) требует выпол-
нения еще трех запросов к дискам. Поскольку для каждой логической записи
генерируется четыре запроса к физическому диску, то пропускная способность
снижается примерно на 75%.
RAID 5 обеспечивает возможность восстановления данных (поскольку их мож-
но восстановить по данным четности). RAID 5 может перенести потерю одного
(любого) физического диска
RAID 6 (двойная RAID 6 — это практически RAID 5 с дополнительной избыточностью. Вместо
циклическая одного блока четности используется два блока избыточности. Второй блок
четность) использует другой код избыточности (вместо четности), который позволяет
произвести реконструкцию данных при выходе из строя любых двух дисков.
Либо диски можно организовать в двумерную матрицу и поддерживать как
вертикальную, так и горизонтальную четность
Сети хранения данных (Storage area networks, SAN) — это дисковые системы, которые
имеют высокоскоростные подключения к дисковым массивам. Сети SAN имеют про-
граммные интерфейсы, которые позволяют дисковое пространство комбинировать
в логические устройства (logical unit number, LUN) и быстро переконфигурировать.
Адаптеры шины (host bus adapter, HBA) обеспечивают высокоскоростное подключение
между хостом и дисковым массивом. Большинство HBA использует оптическое под-
ключение, называемое Fibre Channel.
Протокол Internet SCSI (iSCSI) — это сетевой протокол, который позволяет передавать
данные по протоколу SCSI через сети TCP/IP. Для работы iSCSI нужен только сетевой
адаптер Ethernet. Для iSCSI не нужны дорогие НВА или такие протоколы хранения, как
Fibre Channel, и для него на целевой системе не требуются диски SCSI. Это позволяет
протоколу iSCSI обеспечивать недорогой способ доступа к централизованному храни-
лищу. Некоторые новые сетевые адаптеры Gigabit Ethernet обеспечивают обработку
протокола iSCSI прямо на адаптере (для ускорения выдачи пакетов в физическую среду
и считывания их из нее).
Для обмена iSCSI использует метафору "клиент/сервер". Клиент iSCSI называется ини-
циатором, а сервер iSCSI — целью. Инициатор — это клиентское устройство, которое
подключается к цели (предоставляющей поблочный доступ к своей системе хранения).
Ограничение системы "инициатор/цель" состоит в том, что в каждый момент времени с
целью может вести обмен только один инициатор. Цель iSCSI справляется с тяжелыми
нагрузками, поскольку использует буфер для формирования очереди входящих запро-
сов.
Для загружающихся с внутренних жестких дисков серверов Hyper-V используйте массивы
RAID 1 (чтобы обеспечить отказоустойчивость для родительского раздела и для конфигу-
рационных настроек Hyper-V).
Для хранения виртуальных машин используйте SAN, которая обеспечивает: избыточность
при помощи RAID 0+1; все возможности iSCSI-цели; а также возможность применения вы-
сокоскоростных жестких дисков (с формированием очереди команд). Выбор такой системы,
которая поддерживает в одном корпусе как диски SATA, так и диски SAS, обеспечит вам
максимальную гибкость. При создании дискового массива RAID 0+1 вам следует использо-
вать как можно больше дисков (для распределения нагрузки ввода/вывода).
Максимизируем производительность сети

Родительский раздел предоставляет доступ к физическим сетевым адаптерам сервера
Hyper-V как для работающих в родительском разделе приложений, так и для работаю-
щих в дочерних разделах операционных систем и приложений. Сетевой трафик нужен
и серверу Hyper-V, и работающим на сервере виртуальным машинам. Трафик хоста
включает: удаленное управление, обмен между агентами, обмен по протоколу iSCSI,
кластерный обмен. Трафик виртуальных машин может включать: удаленное управле-
ние, обмен между агентами, обмен по протоколу iSCSI, кластерный обмен, сетевой
трафик приложений. Изоляция трафика хоста от трафика виртуальных машин умень-
шит проблемы обмена с хостом (когда невозможно подключиться к виртуальной ма-
шине, которая испытывает некие сетевые проблемы). Если и хост, и виртуальные ма-
шины совместно используют один сетевой адаптер, то виртуальная машина может
стать целью атаки типа "отказ в обслуживании" (denial of service, DOS), что приведет
к недоступности и самого хоста.
Выделите, по крайней мере, один физический сетевой адаптер для управления и резервно-
го копирования Hyper-V. Выделение сетевого адаптера для управления сервером Hyper-V
означает, что трафик управления сервером Hyper-V и сетевой трафик его резервного копи-
рования не будут влиять на трафик виртуальных машин.
Присутствие на одном адаптере нескольких типов сетевого трафика — плохая идея.

Например, если родительский раздел Hyper-V использует LUN на основе iSCSI, то
производительность дисков может снизиться из-за перегруженного сетевого адаптера.
Если сервер Hyper-V является членом кластера, то очень важно, чтобы кластерный об-
мен и сигналы тактовых импульсов не проходили через тот сетевой адаптер, который
может быть перегружен дополнительным трафиком (влияющим на кластерный обмен).
Выделите для обмена по iSCSI отдельный сетевой адаптер (используйте такой адаптер,
который обеспечивает аппаратную поддержку обработки протокола iSCSI).
Выделите отдельный сетевой адаптер для кластерного обмена.
Сетевой стек сервера Windows Server 2008 может передавать обработку некоторых за-
дач на сетевые адаптеры, которые имеют соответствующие возможности. В табл. 7.3
предоставлены подробности такой разгрузки.
Таблица 7.3. Возможности передачи обработки на сетевые адаптеры
Тип разгрузки Описание

Вычисление Сетевой стек может передать вычисление и проверку контрольных сумм
контрольных сумм (как для протокола Transmission Control Protocol (TCP), так и для протокола
User Datagram Protocol (UDP)) и при передаче, и при приеме (как для вер-
сии IPv4, так и для версии IPv6)
Аутентификация и Транспортный уровень ТСР/IP может передать вычисление и проверку
шифрование шифрованных контрольных сумм заголовков аутентификации и полезной
протокола IP нагрузки Encapsulating Security Payloads (ESP). Транспортный уровень
TCP/IP может также разгрузиться от шифрования и дешифрации ESP
Сегментация Транспортный уровень TCP/IP может разгрузиться от сегментации больших
больших пакетов TCP пакетов ТСР. Поддерживается Large Send Offload (LSO) версий 1 и 2
Стек ТСР Ядро разгрузки TCP (TCP offload engine, TOE) позволяет сетевому адапте-
ру (имеющему такую поддержку) делать разгрузку всего сетевого стека
По умолчанию для физического сетевого адаптера доступны все функции разгрузки, но

они могут быть не включены. Windows Server 2008 поддерживает также такие допол-
нительные функции, как: пакеты увеличенного размера, подстройку буферов вво-
да/вывода, масштабирование на принимающей стороне.
Серверы Hyper-V на базе Windows Server 2008, у которых внешние виртуальные сети
привязаны к физическим сетевым адаптерам, поддерживают для использующих эту
внешнюю сеть виртуальных машин только функцию разгрузки Large Send Offload
(LSOv1) и разгрузку контрольных сумм TCPv4. На обмен с родительским разделом
(через стек TCP/IP родительского раздела) эти ограничения не распространяются.
В версии Hyper-V на базе сервера Windows Server 2008 R2 для виртуальных машин добав-
лена поддержка TCP Chimney, Large Send Offload v2 и пакетов увеличенного размера.
Активация TCP Chimney Offload

Функция TCP Chimney Offload будет работать только в том случае, если она активиро-
вана в операционной системе и в расширенных свойствах сетевого адаптера. В Win-
dows Server 2008 функция TCP Chimney Offload в обоих вышеупомянутых местах по
умолчанию выключена.
Для того чтобы вручную активировать функцию TCP Chimney Offload на сервере
Windows Server 2008 с ролью Hyper-V или на хосте Microsoft Hyper-V Server 2008, вы-
1. Откройте командную строку с администраторскими учетными данными.
2. В командной строке введите следующую команду, а затем нажмите клавишу
<Enter>.
netsh int tcp set global chimney=enabled
Чтобы настроить TCP Chimney Offload на сетевом адаптере, выполните следующие

шаги:
1. Откройте Device Manager.
2. В пункте Network Adapters дважды щелкните по нужному вам сетевому адаптеру.
3. На вкладке Advanced выберите Enabled в раскрывающемся списке рядом с элемен-
том TCP Offload.
Разные производители могут использовать (на вкладке Advanced страницы Network
Adapter) для функции TCP Chimney Offload разные названия.
После активации функции разгрузки TCP Chimney Offload вы можете определить, ка-
кие подключения разгружены (при помощи команды netstat -t). Выходные данные
содержат столбец Offload State. Если подключение TCP разгружено, то его состояние
будет обозначено как Offload. Если подключение не разгружено, то его состояние бу-
дет InHost.
Не активируйте TCP Chimney Offload на кластерах хостов Hyper-V. Отказоустойчивая кла-
стеризация в Windows Server 2008 не использует функцию TCP Chimney Offload.
Активируйте функцию TCP Chimney Offload на некластеризованных серверах Hyper-V. Не-
смотря на то, что привязанные к внешним виртуальным сетям физические сетевые адапте-
ры не смогут применять функцию разгрузки TCP, ее смогут использовать другие сетевые
адаптеры.
Протестируйте производительность приложения до и после активирования функции TCP
Chimney. Не все приложения могут использовать функцию разгрузки TCP Chimney Offload.
Некоторые сетевые адаптеры недостаточно мощные для того, чтобы справиться с допол-
нительной нагрузкой, которую создает TCP Chimney Offload. В любом из этих случаев акти-
вация функции TCP Chimney Offload может отрицательно повлиять на сетевую производи-
тельность некоторых приложений.
Увеличение ресурсов сетевых адаптеров

Некоторые сетевые адаптеры позволяют вручную настраивать буферы приема и пере-
дачи. Изготовитель может по умолчанию использовать маленькие размеры буферов
приема и передачи (с целью сэкономить память сервера), но низкие значения могут
уменьшить производительность и вызвать потерю пакетов. Для повышения производи-
тельности вы можете настроить буферы приема и передачи большего размера.
Для конфигурирования буферов приема и передачи сетевого адаптера выполните сле-
2. В разделе Network Adapters дважды щелкните по нужному вам сетевому адаптеру.
3. На вкладке Advanced щелкните Receive Buffers в списке Property и увеличьте
имеющиеся буферы до максимального размера.
4. В списке Property щелкните Transmit Buffers и увеличьте имеющиеся буферы до
максимального размера.
Если адаптер не позволяет произвести ручную настройку ресурсов, тогда он либо динами-
чески конфигурирует ресурсы, либо настроен на фиксированное значение (которое изме-
нить нельзя).
Активация пакетов увеличенного размера

Пакеты увеличенного размера позволяют полезной нагрузке пакета превышать размер
по умолчанию (1500 байтов). Пакеты повышенного размера позволяют полезной на-
грузке достигать 9000 байтов. Это позволяет посылать больше данных, при этом сни-
жается количество пакетов, что может привести к уменьшению нагрузки на процессор
и увеличить пропускную способность, т. к. обрабатывается меньшее количество заго-
ловков кадров. Для использования пакетов увеличенного размера такие пакеты долж-
ны поддерживаться и операционной системой, и сетевыми адаптерами, и сетевыми
коммутаторами, и маршрутизаторами.
Пакеты повышенного размера могут дать значительное повышение производительно-
сти для тех приложений или протоколов, которые передают по сети большое количест-
во данных. Два основных примера — это передача файлов по протоколу server message
block (SMB) и протокол iSCSI.
Для того чтобы настроить пакеты повышенного размера, выполните следующие шаги:
2. В разделе Network Adapters дважды щелкните по нужному вам сетевому адаптеру.
3. На вкладке Advanced щелкните в списке Jumbo Frames и установите в раскры-
вающемся списке значение Enabled (или указанное там значение).
Совместная (командная) работа сетевых адаптеров

Совместная работа сетевых адаптеров одного компьютера повышает готовность серве-
ра (при помощи функции отказоустойчивости) и повышает пропускную способность
(при помощи функции балансировки нагрузки). Существуют два способа реализации

функций балансировки и отказоустойчивости (load balancing and failover, LBFO): неза-
висимый от коммутатора и зависящий от коммутатора. Зависящий от коммутатора
подход дает повышенную независимость от сбоя, но не во всех ситуациях доступны
все функциональные возможности.
Технология Hyper-V позволяет виртуальным машинам обмениваться по локальной се-
ти (при помощи внешних виртуальных сетей, привязанных к физическим сетевым
адаптерам). На рис. 7.3 показана типичная внешняя виртуальная сеть хоста, привязан-
ные к внешней виртуальной сети виртуальные машины, виртуальный коммутатор, а
также компьютеры на локальной сети.
Рис. 7.3. Пример сетевой конфигурации Hyper-V

(для внешней сети с использованием совместной работы сетевых адаптеров)
На рис. 7.3 каждый клиент имеет один сетевой адаптер, MAC-адреса которых — соот-
ветственно MAC1 и MAC2. Сервер Windows Server 2008 с ролью Hyper-V имеет два
физических адаптера с MAC-адресами MAC3 и MAC4. Они работают совместно
в команде LBFO. Сервер имеет два дочерних раздела с МАС-адресами МАС5 и МАС6.
Родительский раздел имеет внешнюю виртуальную сеть, которая привязана к команде
сетевых адаптеров и имеет МАС-адрес МАС3.
Дочерние разделы используют свои МАС-адреса для обмена друг с другом и с другими
клиентами. Виртуальный коммутатор внешней виртуальной сети осуществляет обмен
между подключенными к нему разделами. Драйвер LBFO инсталлирован в сетевом
стеке ниже виртуального коммутатора Hyper-V. Поэтому драйвер LBFO никоим обра-
зом не должен затрагивать внутренний обмен между разделами (по внутренним вирту-
альным сетям).
Весь обмен между сервером и клиентами проходит через драйвер LBFO. В этом случае
виртуальный коммутатор может считаться эквивалентом реального коммутатора. Раз-
ница в среде Hyper-V состоит в том, что драйвер LBFO реализует не совместную рабо-
ту сервера и коммутатора, а совместную работу двух или более коммутаторов.
Зависящий от коммутатора подход

Компьютеры и коммутаторы в подсети работают при помощи МАС-адресов. Трансля-
ция между адресами протокола IP и МАС-адресами делается при помощи протокола
Address Resolution Protocol (ARP). Зависящая от коммутатора реализация на базе стан-
дарта IEEE 802.3AD не модифицирует МАС-адреса во входящих или исходящих паке-
тах. Для этой реализации не требуется также и помощь ARP. Поэтому все такие (зави-
сящие от коммутатора) реализации с технологией Hyper-V должны работать. При та-
ком подходе драйвер LBFO не должен быть осведомлен о том, что он инсталлирован
ниже виртуального коммутатора Hyper-V.
Независящая от коммутатора
балансировка нагрузки на передающей стороне
Независящая от коммутатора балансировка нагрузки на передающей стороне обычно
реализуется посредством передачи исходящего трафика через все доступные адаптеры
группы. Драйвер LBFO модифицирует МАС-адрес источника в каждом исходящем
пакете так, чтобы он совпадал с МАС-адресом адаптера, который используется для его
передачи. Это обязательно, поскольку если все члены группы адаптеров попытаются
передавать пакеты с одним МАС-адресом, то коммутатор станет до бесконечности пе-
реприсваивать этот МАС-адрес от одного порта другому.
В ситуации рис. 7.3 исходящие из всех дочерних разделов пакеты имеют МАС-адрес
источника, равный МАС-адресу физического передающего их адаптера (МАС3 или
МАС4), и МАС-адрес назначения, равный реальному назначению. Физические комму-
таторы (работающие на МАС-уровне) не смогут различить дочерние разделы. Комму-
таторы видят два МАС-адреса (МАС3 и МАС4), но не реальные МАС-адреса дочерних
разделов (МАС5 или МАС6). Клиенты на локальной сети заполняют свой кэш ARP
значениями из ARP-ответов. Для балансировки нагрузки на передающей стороне драй-
вер LBFO не модифицирует ARP-ответы. Поэтому клиенты получают реальные адреса
(МАС5 или МАС6) из ARP-запроса по дочерним разделам и адрес МАС3 для роди-
тельского раздела.
Такой подход приводит к проблемам по производительности и безопасности. Посколь-
ку клиенты на локальной сети видят адреса дочерних разделов (МАС5 и МАС6), а
коммутаторы их не видят, то предназначенный для этих двух МАС-адресов трафик не
может быть послан в нужный порт коммутатора. Поэтому коммутатор будет посылать
все пакеты, предназначенные обоим этим МАС-адресам, на все порты всех коммутато-
ров подсети. Это повлияет на производительность сетевых коммутаторов, на время
отклика пакетов (направленных в дочерние разделы) — при этом любой подключен-
ный к сетевому коммутатору компьютер может легко прослушивать трафик дочерних

разделов.
Независящая от коммутатора балансировка нагрузки

на принимающей стороне
Независящая от коммутатора балансировка нагрузки на принимающей стороне обычно
реализуется при помощи выдачи различных МАС-адресов в ответ на приходящие от
разных клиентов ARP-запросы. Фактически это балансировка клиентов (а не баланси-
ровка трафика). Балансировка нагрузки может быть статической или динамической.
При динамической реализации незатребованные направленные ARP-пакеты отправля-
ются конкретным клиентам (для изменения сетевой карты-получателя).
Эта функция сильно изменена сетевой реализацией сервера Hyper-V. На рис. 7.3 рабо-
тающие в этом режиме драйверы LBFO модифицируют все ARP-отклики (приходящие
из дочерних разделов). Исходные адреса дочерних разделов МАС5 и МАС6 заменяют-
ся МАС-адресом сетевого адаптера из команды совместной работы (МАС3 или
МАС4). Поэтому клиенты на локальной сети получают кадры с МАС-адресом источ-
ника МАС3 или МАС4 (вместо МАС5 и МАС6). Когда клиент на локальной сети хочет
вести обмен с дочерним разделом, то пакет посылается с МАС-адресом назначения
МАС3 или МАС4. Когда виртуальный коммутатор внешней виртуальной сети получает
этот пакет, то он пересылает его в родительский раздел (поскольку именно он ассоции-
руется с этими МАС-адресами). Дочерний раздел никогда не получает никаких откли-
ков, поскольку МАС-адрес дочернего раздела в пакете отсутствует.
Отключите балансировку нагрузки на принимающей стороне для всех сетевых адаптеров
команды совместной работы. Если вы этого не сделаете, то виртуальные машины (под-
ключенные к внешним виртуальным сетям, которые привязаны к сетевым адаптерам
команды совместной работы), не смогут обмениваться с сервером Hyper-V.
Инсталляция сетевых адаптеров

команды совместной работы
Сетевые адаптеры совместной работы компанией Microsoft не поддерживаются, однако
если они инсталлированы правильно, то их можно заставить работать. Для этого драй-
вер LBFO должен быть инсталлирован в сетевом стеке ниже драйвера протокола вир-
туального коммутатора Hyper-V.
Для правильной инсталляции драйвера LBFO выполните следующие общие шаги:
1. Добавьте роль Hyper-V на сервер Windows Server 2008.
2. Используйте Windows Update для инсталляции на сервер новейших обновлений.
3. Скачайте и инсталлируйте новейшую версию драйвера LBFO (c сайта изготови-
теля).
4. Сконфигурируйте LBFO (посредством настройки нужных функций и отключения
балансировки нагрузки на стороне приема).
5. Создайте внешнюю сеть Hyper-V при помощи драйвера мини-порта виртуального

адаптера совместной работы.
Решения по балансировке нагрузки и по отказоустойчивости разными изготовителями обо-
рудования реализуются по-разному. Некоторые изготовители реализуют изменения конфи-
гурации LBFO при помощи перезапуска или перезагрузки драйвера LBFO. Это приводит
к потере всех сетевых подключений.
Позиция компании Microsoft относительно поддержки совместной работы сетевых адапте-
ров в Windows Server 2008 (развернутом в физической среде или в виртуализированной
среде Hyper-V) состоит в том, что поддержку оборудования и драйверы предоставляет из-
готовитель оборудования.
Оптимизация производительности
Оптимизация производительности виртуальной машины включает в себя настройку
процессора, памяти, сети и системы хранения. Варианты настройки зависят от типа
рабочей нагрузки, конфигурации сервера Hyper-V, взаимодействия с другими вирту-
альными машинами, гостевой операционной системы. В этом разделе обсуждаются
имеющиеся варианты и лучшие практики по настройке процессора, памяти, сети и сис-
темы хранения виртуальной машины. В каждом разделе есть указания по наблюдению
за каждым компонентом (чтобы определить — правильна ли конфигурация).
Максимизация производительности процессора

Виртуальные машины Hyper-V могут быть сконфигурированы с одним, двумя или че-
тырьмя процессорами. Для получения максимальной процессорной производительно-
сти имеется целый набор действий, которые вы должны предпринять (сконфигуриро-
вать и оценить конфигурацию каждой виртуальной машины, чтобы убедиться в том,
что она эффективно использует процессоры).
Использование
"просвещенных" гостевых операционных систем
Операционные системы Windows Vista SP1, Windows Server 2008 и более поздние вер-
сии Windows содержат определенные модификации ядра, которые оптимизируют их
работу в виртуальных машинах (когда ядро определяет, что оно работает в среде ги-
первизора Hyper-V). Эти модификации ядра уменьшают накладные расходы процессо-
ра (путем оптимизации вызовов процессора для использования имеющихся в процес-
соре функций аппаратной поддержки виртуализации).
Более ранние версии Windows не имеют таких модификаций ядра, поэтому они будут
требовать от гипервизора прерывания всех тех операций процессора и ввода/вывода,
которые недопустимы в виртуальной среде. Эти прерывания снижают производитель-
ность виртуальных машин и создают дополнительные издержки при работе процессора

и систем ввода/вывода сервера Hyper-V.
Для получения наилучшей производительности дочерних разделов Hyper-V используйте
Windows Server 2008 или более новые версии операционных систем. Для улучшения про-
изводительности виртуальных машин и уменьшения нагрузки на сервер Hyper-V мигрируй-
те виртуальные машины Windows 2000 Server и Windows Server 2003 на версию Windows
Server 2008.
Инсталлируем службы интеграции

Службы интеграции Integration Services — это набор "просвещенных" драйверов и
служб, которые обеспечивают оптимизированные интерфейсы для диска, сети, процес-
сора и памяти. Просвещенные драйверы предназначены для синтетических устройств,
которые настроены специально для виртуализированного дочернего раздела Hyper-V.
Синтетические устройства служб интеграции уменьшают издержки процессора при
выполнении задач. Они могут существенно улучшить производительность и пропуск-
ную способность (по сравнению с эмулированными устройствами).
Службы интеграции следует инсталлировать как одно из самых первых действий (для лю-
бой поддерживаемой операционной системы). Если вы встроили обновление KB950050 и
создали новый инсталляционный диск Windows Server 2008 для инсталляции виртуальных
машин, то службы интеграции с него будут инсталлироваться автоматически.
Дополнительную информацию по службам интеграции см. в главе 5.
Виртуальные процессоры
Сервер Hyper-V поддерживает максимум четыре виртуальных процессора на одну вир-
туальную машину. Те виртуальные машины, рабочие нагрузки которых не использует
процессор интенсивно, следует конфигурировать с одним виртуальным процессором.
Конфигурирование для виртуальной машины дополнительных виртуальных процессо-
ров, которые не используются, приведет к дополнительным накладным расходам (та-
ким, как дополнительная синхронизация в гостевой операционной системе). Если для
рабочей нагрузки виртуальной машины требуются дополнительные процессоры, то
количество виртуальных процессоров следует увеличить до двух или четырех (в зави-
симости от используемой операционной системы).
При переходе на виртуальные машины оцените использование процессоров на сущест-
вующих физических серверах. Физические серверы могли быть куплены в минимальной
или стандартной комплектации. Если данные по использованию процессоров показывают,
что используется только один процессор, то сконфигурируйте на виртуальной машине один
процессор и последите за его загрузкой.
Дополнительную информацию по гостевым операционным системам и поддерживае-

мому ими числу процессоров см. в главе 2.
Удалите
неиспользуемые эмулированные устройства
Виртуальные машины могут инсталлировать съемные эмулированные (обычные) уст-
ройства. Два таких устройства — это виртуальный дисковод CD/DVD и обычный сете-
вой адаптер. Даже если они не используются, эти устройства могут создавать дополни-
тельные издержки при периодическом их опросе.
Виртуальный дисковод CD/DVD инсталлируется по умолчанию на каждой виртуаль-
ной машине при ее создании. Виртуальный CD/DVD обеспечивает доступ к физиче-
скому дисководу CD/DVD и образам дисков CD или DVD. Обычные сетевые адаптеры
должны инсталлироваться при помощи пункта Add Hardware. Обычные сетевые адап-
теры обеспечивают поддержку старых операционных систем и возможности загрузки с
сети (pre-execution environment, PXE). Если вы не используете такую операционную
систему, для которой нет поддержки служб интеграции, и вам не нужно грузить вирту-
альную машину с устройства PXE, то вам следует использовать стандартные синтети-
ческие сетевые адаптеры.
Удалите виртуальный дисковод CD/DVD с виртуальной машины. Дисковод CD/DVD должен
регулярно проверяться на вставку диска, а это создает циклы процессора (даже если вы не
используете дисковод).
Используйте обычные сетевые адаптеры для загрузки РХЕ или для операционной системы,
которая не имеет поддержки службами интеграции синтетического сетевого адаптера.
Обычные сетевые адаптеры требуют более высокого уровня использования процессорного
времени (для обработки пакетов в рабочем процессе виртуальной машины). Обычные се-
тевые адаптеры имеют более низкую пропускную способность, чем синтетические адапте-
ры (из-за пути через стек виртуализации).
Те виртуальные машины, которыми постоянно нужно пользоваться обычным сетевым
адаптером, следует изолировать на отдельном сервере Hyper-V. Это исключит дополни-
тельные процессорные издержки обычных сетевых адаптеров, и они не будут влиять на
производительность или масштабируемость серверов Hyper-V, работающих с виртуальны-
ми машинами при помощи синтетических сетевых адаптеров.
Конфигурирование экранной заставки

для виртуальных машин
Экранные заставки предназначены для физических компьютеров, чтобы люминофор
мониторов не выгорал от изображения и чтобы автоматически блокировать консоль
компьютера (если пользователь по забывчивости отлучится от физического компьюте-
ра, не заблокировав его, на определенный промежуток времени). В мире виртуальных
машин об экране монитора беспокоиться не приходится, но блокировка клавиатуры по-
прежнему остается актуальной. Экранные заставки используют также некоторое коли-
чество процессорного времени (на прорисовку изображения заставки и на отслежива-
ние нажатий клавиатуры).
На тех компьютерах, доступ к которым осуществляется только проверенными людьми, от-
ключение экранной заставки может сэкономить некоторое количество процессорных цик-
лов. Для тех компьютеров, которым необходима экранная заставка для блокировки консоли
с целью предотвращения неавторизованного доступа, следует использовать экранную за-
ставку с пустым экраном (без изображений), которая минимально отслеживает нажатия
клавиш.
Оптимизация сочетаний рабочих нагрузок

Hyper-V позволяет на одном физическом сервере работать нескольким виртуальным
машинам, которые совместно используют ресурсы этого сервера. Если вы скомбини-
руете на сервере несколько таких виртуальных машин, пики производительности и
ввода/вывода которых совпадают, то службы ввода/вывода Hyper-V могут быть пере-
гружены и производительность виртуальных машин может упасть. Например, если все
виртуальные машины сервера Hyper-V сконфигурированы для выполнения резервного
копирования (по локальной сети на центральную систему резервного копирования)
в 1:00 ночи, то процессор, сеть и система хранения Hyper-V будут бороться за один и
тот же набор ресурсов. Для оптимизации производительности планируйте резервное
копирование виртуальных машин с минимальными накладками по времени (или со-
всем без них).
Чтобы понять, какой эффект на уже существующие рабочие нагрузки окажет добавление
виртуальной машины, выполните анализ использования этой виртуальной машиной про-
цессора, сети и системы дискового ввода/вывода.
Управление ресурсами процессора

Hyper-V управляет выделением процессора каждой виртуальной машине при помощи
настроек Processor Resource Control Settings, доступ к которым можно получить в диа-
логовом окне Settings виртуальной машины (рис. 7.4).
Настройки управления ресурсами процессора содержат три опции: резервирование
производительности, ограничение производительности, относительный вес. В табл. 7.4
описаны эти три настройки и допустимые диапазоны их значений.
Таблица 7.4. Настройки управления ресурсами
Настройка Диапазон Описание

Reserve Capacity 0—100 Резервирование производительности — это тот процент произво-
дительности логического процессора, доступность которого Hyper-V
гарантирует для данной виртуальной машины. Максимальный про-
цент равен 100
Limit Capacity 0—100 Это максимальная производительность логического процессора,
превысить которую Hyper-V данной виртуальной машине не позво-
лит
Relative Weight 1—10 000 Присвоенные виртуальным машинам относительные значения,
которые определяют количество получаемых виртуальной машиной
вычислительных ресурсов. Виртуальная машина с высоким относи-
тельным весом получает больше вычислительных ресурсов, чем
виртуальная машина с низким относительным весом
Рис. 7.4. Настройки Processor Resource Control Settings
По умолчанию все виртуальные машины имеют относительный вес 100 и максималь-

ную производительность логического процессора 100%, так что запросы на ресурсы от
всех виртуальных машин равны и никакая машина не имеет преимуществ перед дру-
гими.
Управление ресурсами имеет два аспекта: установленные в виртуальных машинах зна-
чения резервирования производительности, ограничения производительности и отно-
сительного веса; имеющаяся производительность хоста при включении виртуальной
машины. Можно для каждой виртуальной машины настроить значения резервирования
производительности в 100%. Несмотря на то, что при этом вы как будто бы перегру-
жаете процессорные ресурсы хоста, управление ресурсами процессора автоматически
регулирует производительность. При запуске такой виртуальной машины, которая
имеет настроенное значение резервирования производительности, доступная мощность
системы уменьшается. При запуске такой виртуальной машины, которая имеет настро-
енное значение резервирования производительности больше, чем остаток мощности
системы, Hyper-V выдаст ошибку и не запустит эту виртуальную машину.
Резервирование и ограничение производительности высчитываются по количеству ло-
гических процессоров хоста и по количеству выделенных виртуальной машине вирту-
альных процессоров. На рис. 7.4 хост имеет четыре логических процессора и один вы-
деленный виртуальной машине виртуальный процессор, поэтому ограничение произ-
водительности для одной виртуальной машины можно установить в 25%. Это значение
вычисляется так: берем 100%, делим их на количество логических процессоров хоста и
умножаем на количество выделенных виртуальной машине процессоров.
Когда вы настраиваете значение резервирования производительности для виртуальной
машины, то устанавливаете процент производительности логического процессора, ко-
торый вы хотите зарезервировать. Так что если вы хотите зарезервировать для вирту-
альной машины весь логический процессор, то здесь надо ввести 100% — и система
вычислит ту мощность системы, которая будет выделена (из имеющегося пула мощно-
сти) при включении виртуальной машины — в данном случае это будет один логиче-
ский процессор (или 25% мощности системы). Если вы установите значение резерви-
рования производительности виртуальной машины в 50%, то зарезервированная мощ-
ность системы будет показана как 12%.
Управление ресурсами должно всегда выполняться при планировании размещения
виртуальных машин на сервере Hyper-V. Периодически следует возвращаться к рас-
пределению ресурсов хоста, чтобы убедиться в том, что добавление (или удаление)
виртуальных машин не нарушило баланс системы. Когда вы модифицируете конфигу-
рацию по умолчанию (управления ресурсами виртуальной машины), то рискуете заду-
шить другие виртуальные машины дефицитом процессорных ресурсов.
Используйте управление ресурсами как последнее средство. Если вы не собираетесь
управлять настройками контроля ресурсов всех виртуальных машин — не трогайте уста-
новленную по умолчанию конфигурацию ресурсов процессора. Если у вас есть виртуаль-
ные машины, которым необходимо гарантированное наличие ресурсов процессора, то ис-
пользуйте настройку резервирования производительности. Если у вас есть сервер Hyper-V
с такими виртуальными машинами, которые испытывают всплески процессорной активно-
сти и влияют на работу других виртуальных машин хоста, используйте ограничение произ-
водительности (чтобы "обуздать" эти виртуальные машины и получить прогнозируемую
производительность).
Наблюдайте за производительностью процессора

Для наблюдения за производительностью виртуальных машин (чтобы определить, по-
лучают ли они достаточное количество вычислительной мощности) требуется сочета-
ние наблюдения за логическими процессорами хоста и наблюдения за виртуальными
процессорами виртуальных машин. Наилучшей конфигурацией является соответствие
логических и виртуальных процессоров "один к одному". Это означает, что каждая
виртуальная машина имеет в своем распоряжении логический процессор (полностью).
Для некоторых приложений это правильный подход, и вы можете либо ограничить ко-
личество работающих на хосте виртуальных машин (по количеству логических про-
цессоров хоста), либо использовать управление ресурсами для настройки конфигура-
ции каждой виртуальной машины.
Если целью системы является максимальная консолидация, тогда количество выделен-
ных виртуальных процессоров будет превышать количество логических процессоров
хоста, но они не будут работать на полной производительности.
Для отслеживания производительности процессора гостевой операционной системы

в среде Hyper-V есть несколько основных счетчиков производительности (за кото-
рыми следует наблюдать из операционной системы хоста и из гостевых операционных
систем):
\Hyper-V Hypervisor Logical Processor(_Total)\% Total Run Time — (LPTR)
\Hyper-V Hypervisor Virtual Processor(_Total)\% Total Run Time — (VPTR)
\Hyper-V Hypervisor Virtual Processor(*)\%Guest Run Time — (VPGRT)
LPTR дает вам указание на степень загрузки логических процессоров хоста. VPTR по-
казывает вам, насколько загружены виртуальные процессоры хоста. VPGRT показыва-
ет, насколько загружены виртуальные процессоры гостевой системы.
Для оценки счетчиков Performance Monitor используйте следующие предельные зна-
чения:
менее 60% — безопасно;
60—89% — наблюдать (внимание);
90—100% — критическое состояние, производительность падает.
Если значение VPTR на хосте высокое, а значение LPTR низкое, тогда на хосте есть
такие виртуальные машины, которым выделено недостаточно процессорных мощно-
стей. Используйте счетчики VPGRT виртуальных машин для того, чтобы определить,
какая виртуальная машина работает с высоким значением коэффициента использова-
ния процессора, после чего добавьте ей дополнительный виртуальный процессор. Если
гостевая операционная система не поддерживает большее количество виртуальных
процессоров, тогда необходимо масштабировать само приложение (добавив дополни-
тельную виртуальную машину и сбалансировав рабочую нагрузку между виртуальны-
ми машинами).
Если значение LPTR высокое, а значение VPTR низкое, то в наличии имеется много
виртуальных машин с низкими нагрузками. Переключение контекста между виртуаль-
ными машинами создает узкое место. Если работающая на хосте виртуальная машина
выдает всплеск использования процессора, то возможны два варианта: либо эта вирту-
альная машина получит дополнительные процессорные ресурсы за счет других рабо-
тающих виртуальных машин, либо она их не получит и ее производительность упадет.
Ни то, ни другое не желательно (если это случается постоянно). Обдумайте вариант
добавления еще одного сервера Hyper-V и переноса виртуальных машин на него.
Если значения и VPTR, и LPTR высокие, то процессоры сервера Hyper-V перегружены.
Следует добавить дополнительный сервер Hyper-V и перераспределить имеющиеся
виртуальные машины между серверами Hyper-V.
Перед тем как начать отслеживание проблем производительности, разберитесь с конфигу-
рацией рабочих нагрузок хоста. Если вы наблюдаете сервер Hyper-V и не знаете, сконфи-
гурирован ли он для максимальной консолидации серверов или для максимизации произ-
водительности рабочих нагрузок, то вы не будете знать, что вам искать в счетчиках произ-
водительности.
Максимизация производительности памяти

Гипервизор виртуализирует память дочерних разделов для изоляции их друг от друга и
для обеспечения непрерывного пространства памяти для каждой гостевой операцион-
ной системы. Страницы памяти отслеживаются в таблицах, которые устанавливают
соответствие между виртуализированным пространством памяти и физическим про-
странством памяти сервера Hyper-V. Виртуализация памяти может увеличить стои-
мость доступа к памяти, особенно если приложения часто выделяют и освобождают
память в виртуальном адресном пространстве.
Windows Server 2008 и более новые операционные системы семейства Windows имеют
такие модификации ядра и оптимизации менеджера памяти, которые позволяют
уменьшить накладные расходы процессора на виртуализацию памяти Hyper-V. Те ра-
бочие нагрузки, которые держат в памяти большой рабочий набор данных, могут вы-
играть от использования в качестве гостевой операционной системы сервера Windows
Server 2008 или более новых версий Windows. Эти модификации снижают расходы
процессора на переключения контекста между процессами и на доступ к памяти.
Windows — не единственная операционная система, которая имеет модификации ядра.
SUSE Linux Enterprise Server 10 также имеет аналогичные модификации для оптимиза-
ции выделения памяти и производительности в среде Hyper-V.
Для максимизации преимуществ от этих модификаций операционных систем Windows
Server 2008 и SUSE Linux Enterprise Server 10 вы должны инсталлировать в гостевых
операционных системах службы интеграции Integration Services.
Выделяйте правильное количество памяти

Виртуальным машинам требуется памяти не меньше, чем физическим. Однако у них
есть преимущество в том отношении, что память можно выделить с точностью до од-
ного мегабайта. Это позволяет вам оптимизировать выделение памяти и ограничиться
именно тем количеством, которое вам нужно, но будьте осторожны. Виртуальные ма-
шины выгружают содержимое памяти в файлы подкачки на дисках точно так же, как и
физические машины, поэтому подкачка с диска в виртуальной машине может сильно
влиять на ее производительность (и поэтому подкачку следует по мере возможности
минимизировать).
Выделение памяти — это последовательность компромиссов. Если бы количество па-
мяти было бесконечным, то вы могли бы дать каждой машине достаточное количество
памяти, чтобы подкачки с дисков не было вовсе. Это максимизирует производитель-
ность, но значительно снизит количество виртуальных машин, которое вы сможете
разместить на одном сервере Hyper-V. Ваша цель состоит в том, чтобы выделить дос-
таточное количество памяти для минимизации подкачки с дисков при нормальной ра-
боте (но не ликвидировать ее совсем). Наилучшим способом достижения этой цели
является выделение памяти виртуальной машине, последующее отслеживание произ-
водительности памяти и внесение необходимых изменений.
Удушение родительского раздела Hyper-V недостаточным количеством памяти может ока-
зать отрицательное воздействие на производительность виртуальных машин. Для роди-
тельского раздела надо зарезервировать как минимум 1 Гбайт памяти.
Наблюдайте за производительностью памяти

После того как виртуальные машины будут сконфигурированы и запущены, вам нужно
понять, получила ли виртуальная машина должное количество памяти. Для измерения
влияния количества доступной памяти на производительность (инсталлированной в
виртуальной машине Hyper-V) гостевой операционной системы вы можете использо-
вать целый набор счетчиков производительности. Измерение в виртуальной машине
количества доступной памяти может дать вам представление о том проценте памяти,
который доступен для работающих в виртуальной машине процессов (относительно
количества инсталлированной в виртуальной машине памяти). Для отслеживания ис-
пользования памяти используйте счетчик производительности \Memory\Available
Mbytes виртуальной машины. При оценке значения этого счетчика следует применять
следующие указания:
свободно 50% памяти — безопасно;
свободно 25% памяти — наблюдать;
свободно 10% памяти — предупреждение;
менее 5% памяти свободно — критическое состояние, производительность падает.
Измерение той скорости, с которой страницы пишутся на диск и читаются с него (при
сбоях страниц физической памяти), может дать вам подсказку относительно подкачки
содержимого памяти с диска. Высокий уровень ошибок страниц физической памяти
(при низком проценте доступной свободной памяти) указывает, что виртуальной ма-
шине выделено недостаточное количество оперативной памяти. Для отслеживания со-
стояния подкачки страниц с диска используйте внутри виртуальной машины счетчик
\Memory\Pages/sec. При измерении значения этого счетчика нужно руководствоваться
следующим:
меньше 500 — безопасно;
от 500 до 1000 — наблюдать (внимание);
больше 1000 — критическая ситуация, производительность падает.
Если счетчик \Memory\Available Mbytes постоянно показывает меньше 10% свободной па-
мяти и счетчик \Memory\Pages/sec показывает значения больше 1000, то вам следует вы-
делить виртуальной машине дополнительную память. Если счетчик \Memory\Available
Mbytes постоянно показывает больше 50% свободной памяти и счетчик \Memory\Pages/sec
постоянно показывает меньше 250, то вы можете уменьшить количество выделенной дан-
ной виртуальной машине памяти.
Получение максимальной производительности
путем выделения памяти виртуальной машине в узле NUMA
Когда виртуальные процессоры и память виртуальной машины находятся в одном узле
NUMA, то это обеспечивает наилучшую производительность, но нет никакой гарантии, что
так получится автоматически. Если процессор использует память из другого узла, то про-
цессор применяет другой маршрут к памяти (и эти маршруты могут иметь разную длину).
Например, доступ из ЦПУ 0 узла 0 к памяти узла Х может занимать 10 нс, а доступ из ЦПУ
0 узла 0 к памяти узла Y может занимать 20 нс. Эта разница во времени доступа может по-
влиять на общую производительность виртуальной машины. Худший случай — это когда

виртуальный процессор виртуальной машины работает на самом дальнем узле от того уз-
ла, в котором выделена память для виртуальной машины.
Для повышения производительности вы можете выделять виртуальной машине память на
разных узлах. В дополнение к размещению памяти планировщик гипервизора будет пы-
таться запустить виртуальные процессоры виртуальной машины рядом с выделенной для
виртуальной машины памятью. Это создает двойную родственность, которая может быть
очень полезна.
При помощи скрипта PowerShell можно выделить память виртуальной машины на конкрет-
ном узле NUMA. Вам нужно знать только название виртуальной машины и узел NUMA, ко-
торому вы хотите присвоить узел. Пример скрипта показан далее:
# Этот скрипт настроит виртуальную машину на запуск
# в конкретном узле NUMA
# Проверьте аргументы командной строки
if (($args.length -lt 1) –or
(($args[0] -ne "/list") –and
($args[0] -ne "/set") –and
($args[0] -ne "/clear")) –or
(($args[0] -eq "/set") -and ($args.length -lt 3)) -or
(($args[0] -eq "/clear") -and ($args.length -lt 2))) {
Write-Host "numa.ps1 /list [<Hyper-V host>]"
Write-Host "numa.ps1 /set <vm machine name> <required node>
[<Hyper-V host>]"
Write-Host "numa.ps1 /clear <vm machine name> [<Hyper-V host>]'n"
Write-Host "Options:"
Write-Host "'t/list — show configured VM's"
Write-Host "'t/set <vm machine name> <required node>
— set the NUMA node for the VM"
Write-Host "'t/clear <vm machine name>
— clear NUMA node setting for the VM"
exit;
}
# Просто показать виртуальные машины
if ($args[0] -eq "/list") {
if ($args.length -gt 1) {
$HyperVHost = $args[1];
}
Get-WmiObject -Namespace 'root\virtualization' -Query "Select *
From Msvm_ComputerSystem" | select ElementName
exit;
}
# Установить или сбросить
$HyperVHost = '.';
if ($args[0] -eq "/set") {
}
$VMName = $args[1];
$RequiredNode = $args[2];
} elseif ($args[0] -eq "/clear") {
}
$VMName = $args[1];
}
# Основное тело скрипта
$VMManagementService = Get-WmiObject -Namespace root\virtualization
-Class Msvm_VirtualSystemManagementService -ComputerName $HyperVHost
$Query = "Select * From Msvm_ComputerSystem Where ElementName='" +
$VMName + "'"
$SourceVm = Get-WmiObject -Namespace root\virtualization -Query $Query
-ComputerName $HyperVHost
$VMSettingData = Get-WmiObject -Namespace root\virtualization
-Query "Associators of {$SourceVm} Where
ResultClass=Msvm_VirtualSystemSettingData
AssocClass=Msvm_SettingsDefineState" -ComputerName $HyperVHost
if ($args[0] -eq "/set") {
$VMSettingData.NumaNodesAreRequired = 1
$VMSettingData.NumaNodeList = @($RequiredNode)
} else {
$VMSettingData.NumaNodesAreRequired = 0
}
$VMManagementService.ModifyVirtualSystem($SourceVm$VMSettingData.PSBase.
GetText(1))
После того как вы сохраните этот скрипт как NUMA.PS1, то сможете использовать его для
создания виртуальной машины на конкретном узле NUMA. Рассмотрим эти примеры.
• Пример 1: перечислить сконфигурированные виртуальные машины.
C:\> .\numa.ps1 /list
• Пример 2: установить родственность NUMA равную узлу 1. Нумерация узлов начинает-
ся с узла 0.
C:\> .\numa.ps1 /set testvm 1
• Пример 3: сбросить родственность NUMA.

C:\> .\numa.ps1 /clear testvm
Тони Воэллм (Tony Voellm, Principal Software Design Engineer (Windows Kernel Test))
Максимизация сетевой производительности

Hyper-V поддерживает в виртуальных машинах как синтетические сетевые адаптеры,
так и обычные сетевые адаптеры (эмулированные). Синтетические адаптеры обеспечи-
вают значительно лучшую производительность и снижение накладных расходов про-
цессора. Сетевой адаптер может быть подключен к четырем типам сетей:
Not Connected — сетевой адаптер к сети не подключен;
Private Virtual Network — сетевой коммутатор, который обеспечивает обмен между
виртуальными машинами одного сервера Hyper-V;
Internal Virtual Network — сетевой коммутатор, который обеспечивает обмен между
виртуальными машинами и сервером Hyper-V;
External Virtual Network — сетевой коммутатор, который привязан к физическому

сетевому адаптеру сервера Hyper-V и обеспечивает обмен с любым устройством,
подключенным к этой сети (или к любой другой маршрутизируемой сети).
Сервер Hyper-V может создать неограниченное количество внешних виртуальных се-
тевых коммутаторов, и каждый коммутатор может быть привязан к одному физиче-
скому сетевому адаптеру. Это является практическим ограничением количества внеш-
них сетевых коммутаторов (оно зависит от количества физических адаптеров в сервере
Hyper-V).
Синтетический сетевой адаптер

Инсталляция в виртуальной машине служб интеграции Integration Services позволяет
использовать синтетические сетевые адаптеры. Синтетические адаптеры спроектиро-
ваны специально для виртуальных машин (с целью достижения более высокой сетевой
пропускной способности при меньшем использовании процессора). Синтетический
адаптер ведет обмен между родительским и дочерними разделами через выделенный
канал виртуальной шины (VMBus) компьютера. Синтетические адаптеры имеются
только для поддерживаемых гостевых операционных систем (в которых есть службы
интеграции).
Для максимизации сетевой производительности запускайте службы интеграции и исполь-
зуйте синтетические сетевые адаптеры.
В виртуальную машину можно инсталлировать до восьми синтетических сетевых адап-

теров. Количество инсталлированных сетевых адаптеров зависит от количества разных
подсетей, к которым виртуальная машина должна иметь подключение и от рабочей
сетевой нагрузки в каждой подсети. Виртуальная машина может генерировать доста-
точное для перегрузки физического адаптера количество сетевого трафика. Поэтому
вполне возможно, что виртуальной машине для обслуживания рабочей сетевой нагруз-
ки может понадобиться более одного сетевого адаптера, подключенного к данной под-
сети.
Обычный сетевой адаптер

Обычный сетевой адаптер — это эмулированный сетевой адаптер. Эмуляция основана
на обычном промышленном сетевом адаптере и позволяет в большинстве операцион-
ных систем использовать стандартный драйвер. Поскольку обычные сетевые адаптеры
используют эмуляцию, то их производительность отстает от синтетических сетевых
адаптеров. Использование обычных сетевых адаптеров требуется в двух случаях: за-
грузка РХЕ и те операционные системы, которые не имеют своих версий служб инте-
грации.
Загрузка РХЕ требуется для инсталляции гостевой операционной системы в виртуаль-
ную машину с сети (при помощи таких технологий, как Windows Deployment Services,
Microsoft Deployment Services, Remote Installation Services и т. д.).
Не имеющие служб интеграции Integration Services операционные системы сервером
Hyper-V не поддерживаются, но если операционная система поддерживает эмулиро-
ванный сетевой адаптер, то сетевой обмен возможен.
Для загрузки РХЕ используйте обычные сетевые адаптеры, а затем переключайтесь на
синтетические сетевые адаптеры (при условии, что гостевая операционная система имеет
поддерживаемую версию служб интеграции).
Дополнительную информацию по обычным сетевым адаптерам см. в главе 5.
Разгружайте оборудование
Виртуальные машины Hyper-V поддерживают следующие (предоставляемые некото-
рыми физическими сетевыми адаптерами) функции разгрузки: Large Send Offload
(LSO) версии 1 и функцию разгрузки контрольных сумм ТСР IPv4. Эти функции сни-
жают требуемую для обработки пакетов (в родительском разделе) процессорную мощ-
ность и увеличивают производительность виртуальных машин. Сэкономленная мощ-
ность процессора может быть использована для виртуальных машин.
Для серверов Hyper-V покупайте такие физические адаптеры, которые обеспечивают функ-
цию Large Send Offload и функцию разгрузки контрольных сумм TCP IPv4. Не забудьте
активировать и сконфигурировать эти опции в настройках драйверов родительского раз-
дела.
Производительность VLAN
Как обычные, так и синтетические сетевые адаптеры поддерживают тегирование вир-
туальных локальных сетей VLAN. Оно настраивается в виртуальной машине для каж-
дого сетевого адаптера (нужно указать идентификатор VLAN). Для того чтобы тегиро-
вание VLAN работало с максимально возможной производительностью, физический
сетевой адаптер должен поддерживать функцию Large Send Offload и разгрузку кон-
трольных сумм TCP IPv4. Наивысшая производительность достигается тогда, когда
драйвер мини-порта NDIS 6.0 для физического сетевого адаптера поддерживает для
обеих этих функций инкапсуляцию NDIS_ENCAPSULATION_IEEE_802_3_P_AND_
Q_IN_OOB. Без такой поддержки Hyper-V не может использовать разгрузку оборудо-
вания при обработке пакетов, которым требуется тегирование VLAN, поэтому сетевая
производительность не будет оптимальной.
Беспроводные сети
Внешние виртуальные сети Hyper-V нельзя напрямую привязать к беспроводным сете-
вым адаптерам. Виртуальные машины Hyper-V должны иметь уникальный МАС-адрес,
а поскольку стандарт IEEE 802.11 не позволяет модифицировать МАС-адрес беспро-
водной сети, то виртуальные машины не могут получить уникальную идентификацию.
Виртуальную сеть Hyper-V можно привязать к сетевому адаптеру Ethernet и уже этот
адаптер подключить к беспроводному маршрутизатору (чтобы трафик передавался без
проводов).
Родительский раздел Hyper-V использовать беспроводные сетевые адаптеры может. Для
этого должен быть загружен драйвер беспроводного сетевого адаптера и инсталлирована
служба Wireless LAN Service сервера Windows Server 2008.
Тестирование сетевой производительности

Если у вас плохая сетевая производительность, то посмотрите в табл. 7.5 некоторые
тесты, которые можно провести для выявления причин этой проблемы.
Таблица 7.5. Тесты сетевой производительности
Тест Описание
Network Воспользуйтесь утилитой ping для того, чтобы проверить задержки сети. Выполните
latency эту проверку с локального хоста, с виртуальных машин этого хоста, а затем с других
физических или виртуальных машин подсети. На локальных сетях время отклика
должно быть меньше 1 мс
Packet loss Используйте утилиту Pathping.exe для проверки потерь пакетов между виртуальными
машинами хоста, а также другими физическими или виртуальными машинами подсети.
Pathping.exe измеряет потери пакетов на сети. Она посылает пачку из 100 ping-запро-
сов на каждый узел сети и подсчитывает количество возвращенных откликов.
На локальных сетях потерь откликов быть не должно
Network file Скопируйте 100-мегабайтный файл между двумя виртуальными машинами (на одном
transfer хосте), а также между другими физическими или виртуальными машинами подсети.
Измерьте время копирования. На нормальной 100-мегабитной сети такой 100-мега-
байтный файл должен копироваться от 10 до 20 секунд. На нормальной гигабитной
сети такой 100-мегабайтный файл должен копироваться от 3 до 5 секунд. Превышение
этого времени копирования говорит о наличии сетевых проблем
Наблюдение за сетевой производительностью

Слежение за сетевой производительностью позволяет вам определить, правильно ли
сконфигурированы сетевые адаптеры виртуальной машины, хорошо ли сбалансирована
рабочая нагрузка и не нужны ли виртуальной машине дополнительные сетевые адап-
теры.
Для измерения использования сети гостевой операционной системой (инсталлирован-
ной в виртуальной машине Hyper-V) вы можете использовать целый ряд счетчиков
производительности. Измерение использования сети может указать на наличие про-
блем сетевой производительности. Для наблюдения за производительностью сетевых
интерфейсов используйте в виртуальной машине счетчик \Network Interface(*)\Bytes
Total/sec. После получения этих значений вам нужно конвертировать их в процент ис-
пользования сети, для этого необходимо умножить значение Bytes Total/sec на 8 (чтобы
превратить его в биты), потом полученный результат умножить на 100, а затем разде-
лить на полосу пропускания сетевого адаптера.
При оценке значения этого счетчика производительности нужно руководствоваться
следующим:
используется меньше 40% пропускной способности интерфейса — безопасно;
используется 41—74% — наблюдать (внимание);
75—100% — критично, производительность может упасть.
Для наблюдения за количеством потоков, находящихся в состоянии ожидания на сете-
вом интерфейсе, используйте в виртуальной машине счетчик \Network Interface(*)
\Output Queue Length.
При оценке значения этого счетчика производительности нужно руководствоваться

следующим:
0 — безопасно;
1—2 — наблюдать (внимание);
больше 2 — критично, производительность может упасть.
Если на сетевом адаптере находится в состоянии ожидания больше двух потоков, то в
сети, возможно, имеется узкое место. Обычными причинами этого являются большие
сетевые задержки и/или высокий уровень конфликтов в сети.
Если очередь вывода на сетевом адаптере виртуальной машины постоянно больше чем 2,
то виртуальной машине нужен дополнительный сетевой адаптер для того, чтобы справ-
ляться с сетевой нагрузкой. Дополнительный адаптер может быть привязан к той же самой
(либо к другой) виртуальной сети.
Чтобы определить, может ли существующая виртуальная сеть справиться с дополнитель-
ным трафиком, измерьте значение счетчика производительности \Network
Interface(*)\Output Queue Length на самом хосте (для определения длины очереди). Если
длина очереди на сетевом адаптере хоста больше 2, то вам следует добавить дополни-
тельный физический сетевой адаптер, создать привязанную к нему новую внешнюю вирту-
альную сеть и перенести виртуальные машины в эту новую сеть (чтобы сбалансировать
сетевую нагрузку).
Сконфигурируйте все физические и виртуальные сетевые адаптеры сервера Hyper-V на
одно и то же значение MTU (maximum transmission unit).
Максимизация производительности системы хранения

Производительность системы хранения виртуальной машины является ключевым фак-
тором общей производительности виртуальной машины. Дисковый ввод/вывод — это
самый медленный компонент физической и виртуальной машин. Выбор правильного
виртуального жесткого диска и контроллера очень важен для получения наилучшей
возможной дисковой производительности.
Типы виртуальных жестких типов

Виртуальная машина сервера Hyper-V может иметь четыре типа виртуальных жестких
дисков: динамически расширяющиеся, фиксированные, разностные и транзитные.
В табл. 7.6 приведено сравнение различных типов виртуальных жестких дисков.
Таблица 7.6. Сравнение виртуальных жестких дисков
Тип Описание
Динамически Виртуальный жесткий диск, инкапсулированный в один файл. Первоначально
расширяющиеся создается с главной загрузочной записью и таблицей файлов, но без простран-
ства данных. Пространство для хранения данных выделяется по требованию и
имеет вид виртуальных дорожек и секторов. Когда в файл впервые записывается
блок, то сначала в файле VHD необходимо выделить пространство для блока,
а затем записать данные. Пространство выделяется кусками по 2 Мбайт
Фиксированного Виртуальный жесткий диск, инкапсулированный в один файл. Первоначально

размера создается с главной загрузочной записью и таблицей файлов и со всеми блока-
ми данных, заполненными нулями. Производительность лучше, поскольку
операция записи не порождает операции выделения блока (как в динамическом
диске)
Разностные Динамически расширяющийся виртуальный жесткий диск, который работает как
оверлей для существующего родительского виртуального жесткого диска. Любая
операция записи блока пишет в файл оверлея. Любая операция чтения обслужи-
вается родительским диском (если в оверлее нет обновленного блока данных)
Транзитные Виртуальный жесткий диск, которому соответствует физический диск или LUN
(а не файл VHD). Этот физический диск или LUN сервером Hyper-V использо-
ваться не должен. Это единственный виртуальный жесткий диск, который может
быть больше, чем 2 Тбайт
С точки зрения производительности дискового ввода/вывода самым лучшим является

транзитный диск. Однако транзитные диски не поддерживают моментальных снимков
и хуже переносятся (чем состоящие из одного файла VHD). Следующий — виртуаль-
Рис. 7.5. Блок-схема для определения типа жестких дисков

ный жесткий диск фиксированного размера (разница в производительности очень ма-

ла). Они также меньше склонны к фрагментации (поскольку пространство выделяется
при создании). Динамические диски медленнее, чем фиксированные виртуальные же-
сткие диски (из-за издержек на выделение блоков). Разностные диски являются самым
медленным типом виртуальных жестких дисков, но они — самые эффективные по ис-
пользованию дискового пространства. На рис. 7.5 показана блок-схема, которая помо-
жет вам при определении типа виртуального жесткого диска для вашей виртуальной
машины.
Для сбалансированного подхода используйте фиксированные виртуальные диски. Они да-
ют самую быструю комбинацию производительности, переносимости и поддержки момен-
тальных снимков.
Синтетический контроллер SCSI

Контроллер SCSI в Hyper-V — это синтетическое устройство, которое загружается во
время начальной загрузки как карта расширения. Поскольку до загрузки синтетическо-
го драйвера контроллера SCSI нет, то для начальной загрузки виртуальной машины его
использовать нельзя. Синтетический контроллер SCSI обеспечивает гораздо более вы-
сокие возможности для расширения, чем контроллер IDE (на одном контроллере SCSI
может быть 64 виртуальных жестких диска). Синтетический драйвер контроллера SCSI
инсталлируется как часть служб интеграции. Несмотря на то, что в сервере Virtual
Server 2005 R2 разность по производительности между контроллерами IDE и SCSI бы-
ла большой, архитектура VMBus сервера Hyper-V дает для них вполне сравнимую про-
изводительность (при одном подключенном виртуальном жестком диске). Синтетиче-
ский контроллер SCSI при подключении нескольких виртуальных дисков дает некото-
рые дополнительные возможности оптимизации.
Для достижения наивысшей производительности и минимальных процессорных накладных
расходов под диски данных виртуальных машин следует использовать подключенные
к контроллеру SCSI виртуальные жесткие диски.
Для улучшения производительности размещайте файлы виртуальных жестких дисков на
разных физических дисках.
Наблюдение за производительностью дисков

Измерение дисковой производительности виртуальных машин скажет вам о том, нуж-
но ли изменить тип виртуального жесткого диска либо поменять конфигурацию кон-
троллера. Для измерения дисковой производительности (инсталлированной в вирту-
альной машине Hyper-V) гостевой операционной системы вы можете использовать це-
лый ряд счетчиков производительности. Измерение времени реакции (операций чтения
и записи) на запросы операционной системы может указать на проблемы с дисковой
производительностью. Для наблюдения за дисковой производительностью используйте
в виртуальной машине счетчики производительности \Logical Disk(*)\Avg. sec/Read и

\Logical Disk(*)\Avg. sec/Write. Рекомендуется использовать счетчики производитель-
ности для логических, а не для физических дисков — поскольку приложения и службы
Windows используют именно логические диски (представленные в виде букв дисков), а
представленный операционной системе физический диск (LUN) может являться масси-
вом из нескольких физических дисков.
При оценке значения среднего времени реакции (данного счетчика производительно-
сти) нужно руководствоваться следующим:
1—15 мс — безопасно;
16—25 мс — предупреждение (наблюдать);
26 мс и более — критично, производительность может упасть.
Среднее время реакции более 26 мс означает проблему с дисковой производитель-
ностью. Она может быть вызвана: перегруженным контроллером виртуальной машины
или хоста; выбором медленного формата виртуального жесткого диска (вследствие
наличия требований по переносимости или ограниченности дискового пространства);
недостаточным количеством свободного места на жестком диске.
Если на обслуживающем несколько виртуальных машин сервере Hyper-V проблемы с
дисковой производительностью испытывает только одна виртуальная машина, тогда
это, скорее всего, специфичная для конфигурации данной виртуальной машины (или ее
приложения) проблема. Если проблемы испытывают многие виртуальные машины, то,
скорее всего, это означает проблему с драйвером родительского раздела или с физиче-
ским контроллером, либо с физическим жестким диском.
Эксплуатационные соображения
Использование Hyper-V в тестовой и промышленной среде (а также в среде разработ-
ки) требует выработки эксплуатационных стандартов (для поддержания эффективно-
сти). В этом разделе рассматриваются стандарты именования, а также создание биб-
лиотеки виртуальных машин и работа с ней.
Выработка стандартов
Выработка стандартов конфигураций (до того как вы начнете развертывать виртуали-
зацию в масштабе предприятия) сбережет вам много часов работы по модификации
этих конфигураций. Стандарты очень важны для минимизации трудозатрат на мигра-
цию виртуальных машин между хостами, для подготовки виртуальных машин, а также
для того, чтобы виртуальные машины и виртуальные сети можно было без труда иден-
тифицировать.
Виртуальные машины перечисляются в менеджере Hyper-V Manager по названию вир-
туальной машины и сортируются в восходящем алфавитном порядке. Однако название
виртуальной машины не обязано соответствовать реальному имени компьютера в гос-
тевой операционной системе. Такой подход дает гибкость и создает путаницу. Вы мо-
жете указать для виртуальной машины такое название, которое отличается от названия
гостевой операционной системы (что дает вам гибкость при сортировке и группирова-
нии в пользовательском интерфейсе). Однако вы должны помнить соответствие между
названием виртуальной машины и названием гостевой операционной системы.
Название виртуальной машины не обязано быть уникальным на данном хосте (или да-
же на нескольких хостах), но место ее хранения на хосте должно быть уникальным.
При создании виртуальным машинам присваивается глобальный уникальный иденти-
фикатор (GUID). Именно этот GUID обеспечивает уникальную идентификацию на сер-
верах Hyper-V.
Разработайте стандарты именования для названий виртуальных машин, а также для на-
звания компьютера гостевой операционной системы. Названия имен компьютеров в госте-
вых операционных системах должны следовать стандартам именования серверов компа-
нии. Названия виртуальных машин должны совпадать либо с названием гостевой операци-
онной системы, либо с названием компьютера, либо давать возможность группировать
машины в пользовательском интерфейсе (и содержать в то же время название компьютера
в гостевой операционной системе).
Например, стандартом наименования в компании может быть трехбуквенное название ме-
стоположения, за которым следует обозначение роли сервера, а за ним — уникальное чи-
словое значение:
HOUFS01
Использование стандартных трехбуквенных кодов аэропортов является признанным стан-
дартом. Соответственно название виртуальной машины могло бы быть одним из сле-
дующих:
HOUFS01
F&P — HOUFS01
Использование F&P в начале названия виртуальной машины позволяет группировать в
пользовательском интерфейсе Hyper-V Manager все серверы печати и хранения файлов.
Разработайте стандарт именования виртуальных жестких дисков, который позволит вам
быстро определять название компьютера, тип диска, а также его номер. Избранный вами
стандарт должен быть хорошо документирован и строго выполняться, чтобы можно было
вести имущественный учет.
Пример стандарта именования VHD

Простой стандарт именования VHD использует название компьютера, тип диска, а
также номер диска для формирования названия вроде такого:
ComputerName-Drivetype-drivenumber.vhd
В табл. 7.7 дана сводка по компонентам для стандарта именования VHD.

При использовании такого стандарта виртуальная машина HOUFS01 с двумя дисками
SCSI могла бы дать нам следующие названия:
HOUFS01-S-01.vhd — Disk 1
HOUFS01-S-02.vhd — Disk 2
Таблица 7.7. Компоненты для примера стандарта по именованию
Компонент стандарта Описание

Название компьютера Название компьютера виртуальной машины
Тип диска • I — диск IDE
• S — диск SCSI
• ID — разностный диск IDE
• SD — разностный диск SCSI
Номер диска Номер диска VHD (при наличии нескольких подключенных к одной машине
дисков VHD)
Резюме
В этой главе описаны лучшие практики для решения часто встречающихся проблем
конфигурации и производительности (а также эксплуатационных проблем), возникаю-
щих при развертывании Hyper-V. Вы можете избежать конфигурационных проблем,
если модифицируете настроенные по умолчанию каталоги хранения виртуальных ма-
шин (и виртуальных дисков), переименуете внешнюю виртуальную сеть, активируете
удаленный рабочий стол и сделаете резервную копию хранилища авторизации.
Проблем с производительностью хоста можно избежать при помощи: выбора подхо-
дящих конфигураций памяти; выбора и корректной настройки правильных сетевых
адаптеров; покупки сети хранения данных (SAN) с высокоскоростными жесткими дис-
ками SATA или SAS (и с поддержкой iSCSI); а также использования RAID 0+1 для
обеспечения максимальной производительности и отказоустойчивости.
Проблем производительности виртуальных машин можно избежать посредством: сле-
дования лучшим практикам по конфигурированию оборудования хоста; использования
надлежащих настроек управления ресурсами; инсталляции служб интеграции вирту-
альных машин; использования поддерживающих функции разгрузки сетевых адапте-
ров; а также использования виртуальных дисков фиксированного размера, подключен-
ных к синтетическим контроллерам SCSI.
И наконец, вы можете свести к минимуму эксплуатационные проблемы при помощи
разработки стандартов именований, которые позволят вам быстро и легко идентифи-
цировать и отслеживать виртуальные машины и виртуальные жесткие диски.

"Performance Tuning Guidelines for Windows Server 2008" — информация по на-
стройке производительности сервера Windows Server 2008 для различных сценари-
ев, доступная по ссылке:
http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv.mspx;
"Measuring Performance on Hyper-V" — указания по измерению производительности

процессора, сети, системы хранения и памяти сервера Hyper-V, доступные по ссыл-
ке: http://msdn.microsoft.com/en-us/library/cc768535.aspx;
"Troubleshooting Hyper-V" — указания по поиску причин проблем производитель-
ности (и прочих проблем Hyper-V), доступные по ссылке:
"Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct
Memory Access features in Windows Server 2008" — информация и указания по кон-
фигурированию расширенных сетевых функций, доступные по ссылке:
ГЛАВА 8
Переход с Virtual Server 2005 R2

на Hyper-V
Переход с сервера Virtual Server 2005 R2 на Hyper-V влечет за собой миграцию как
хоста Virtual Server, так и виртуальных машин. Вследствие произошедших в архитек-
туре изменений процесс это не простой — для такого перехода нельзя выполнить "об-
новление на месте". Вместо этого приходится миграцию хоста и виртуальных машин
делать по отдельности. Процесс этот не очень трудный, но его многочисленные шаги
должны быть выполнены в правильном порядке. В этой главе мы дадим вам указания
о том, что именно нужно перенести, как это перенести, когда это переносить, а также
прочие важные соображения, которые вы должны учесть в этом процессе.
Анализ перед миграцией хоста

Virtual Server 2005 R2 на Hyper-V
Virtual Server 2005 R2 SP1 — это решение виртуализации на базе хоста, которое рабо-
тает поверх операционной системы, а Hyper-V — это гипервизор, который работает
под операционной системой. Поскольку это весьма существенное изменение архитек-
туры, то возможности произвести "обновление на месте" с сервера Virtual Server 2005
R2 SP1 на Hyper-V нет.
Целью является миграция хоста Virtual Server и виртуальных машин с минимальными
проблемами и временем простоя. Лучший способ — мигрировать на новое серверное
оборудование. Это позволит вам инсталлировать Windows Server 2008 и роль Hyper-V
(или сервер Microsoft Hyper-V Server 2008), сконфигурировать компьютер для мигра-
ции и оптимизировать эту конфигурацию в соответствии с указаниями главы 7. После
оптимизации инсталляции виртуальные машины можно будет мигрировать с сервера
Virtual Server 2005 R2 SP1 на новый сервер Hyper-V.
Обслуживание хостов Virtual Server 2005 R2

Несмотря на соблазн мигрировать все хосты Virtual Server 2005 R2 SP1, неплохо будет
все же сохранить Virtual Server для некоторых гостевых операционных систем. Virtual
Server 2005 R2 SP1 поддерживает следующие операционные системы, которые Hyper-V

не поддерживает:
Windows NT Server 4.0 Service Pack 6a;
Windows XP SP2 (только в Virtual Server 2005 R2);
OS/2 4.5;
Red Hat Enterprise Linux 2.1 (обновление 7);
Red Hat Enterprise Linux 5.0;
Red Hat Linux 9.0;
SUSE Linux 9.3;
SUSE Linux 10.0;
SUSE Linux 10.1;
SUSE Linux 10.2.
Если у вас есть виртуальные машины с этими гостевыми операционными системами,
то мы рекомендовали бы оставить их на сервере Virtual Server, а не переносить их на
Hyper-V.
Поддержка беспроводных сетей

Virtual Server 2005 R2 SP1 имеет поддержку беспроводных сетей, которую можно ис-
пользовать для привязки виртуальных сетей. В Hyper-V прямое подключение внешних
виртуальных сетей к беспроводным сетевым адаптерам не реализовано, поскольку
Hyper-V строго соблюдает спецификации стандарта 802.11 (а эти спецификации не по-
зволяют беспроводным сетям модифицировать МАС-адрес).
Поддержка серверного оборудования

Перед обновлением на Hyper-V вы должны оценить ваше серверное оборудование. То
оборудование, которое вы планируете использовать для сервера Hyper-V, должно быть
64-битным и иметь аппаратную поддержку виртуализации. Поскольку вы не можете
напрямую обновить имеющийся сервер Virtual Server 2005 R2 SP1 до Hyper-V, то либо
вы должны купить новое серверное оборудование, либо имеющееся у вас оборудова-
ние должно соответствовать минимальным аппаратным требованиям Hyper-V (чтобы
его можно было повторно использовать).
Минимизация времени простоя

Когда вы мигрируете виртуальные машины с Virtual Server на Hyper-V, то для мигра-
ции их необходимо выключить. Это повлечет за собой простой виртуальных машин.
Кроме того, в зависимости от выбранного вами подхода к миграции хоста Virtual
Server, у самого хоста также может получиться простой (что приведет к простою всех
Глава 8. Переход с Virtual Server 2005 R2 на Hyper-V 325
виртуальных машин). Поэтому перед выбором подхода к миграции хоста, вам следует
определить, какой простой допустим для хоста и виртуальных машин.
Миграция хоста
Virtual Server 2005 R2 на Hyper-V
Миграция с Virtual Server 2005 R2 SP1 на Hyper-V — это многошаговый процесс, при-
чем эти шаги могут различаться в зависимости от текущей конфигурации вашего хоста
Virtual Server. Из предыдущих глав вы уже знаете, что для Hyper-V вам нужно иметь
либо Windows Server 2008 64-bit, либо Microsoft Hyper-V Server 2008. Если ваша ны-
нешняя инсталляция Virtual Server 2005 R2 SP1 работает не на Windows Server 2008
64-bit, то сначала вам придется создать новую инсталляцию Windows Server 2008 x64
или Microsoft Hyper-V Server 2008.
Если хост Virtual Server работает на Windows Server 2008 x64, то можно создать ре-
зервную копию хоста, деинсталлировать Virtual Server, инсталлировать роль Hyper-V, а
потом произвести миграцию виртуальных машин. Этот метод позволяет вам использо-
вать при миграции то же самое оборудование (и не нужно копировать файлы виртуаль-
ных машин на другой компьютер), но он требует вывода в автономное состояние и
Virtual Server, и виртуальных машин (так что у пользователей получится простой). Этот
метод означает также, что если что-то пойдет неправильно, то процесс восстановления
будет не простым и не быстрым. Для минимизации простоев хоста и виртуальных ма-
шин более удачным вариантом будет создать новый сервер Hyper-V и мигрировать
виртуальные машины на новый сервер. При таком подходе вы получаете несколько
преимуществ:
возможность делать миграцию виртуальных машин по мере необходимости;
возможность создать нужную конфигурацию оборудования (чтобы удовлетворить
имеющиеся требования);
отсутствие простоя существующего хоста Virtual Server;
консолидация нескольких хостов Virtual Server на один сервер Hyper-V (или кластер
хостов).
Кроме того, если при миграции что-то пойдет неправильно, то виртуальные машины
по-прежнему остаются на хосте Virtual Server и их можно быстро загрузить.
Обсуждающийся в следующих разделах процесс миграции хоста рассматривает мигра-
цию с сервера на сервер (а не "миграцию на месте"). В этот процесс входят такие шаги,
как: разработка спецификации на оборудование сервера Hyper-V; сборка серверов
Hyper-V; миграция конфигурации. После завершения миграции вы сможете добавить
новые функциональные возможности, имеющиеся в Hyper-V.
Разработка спецификации
на оборудование сервера Hyper-V
Первый шаг процесса миграции — изучение и документирование конфигурации среды
Virtual Server 2005 R2 SP1 (для определения минимальных требований к оборудованию
сервера Hyper-V). Для этого нужно изучить нынешние спецификации памяти, дисковой
подсистемы, сети и процессора. Кроме того, нужно подсчитать количество сконфигу-
рированных в данное время на хосте Virtual Server виртуальных сетей. После сбора
этой информации вы можете начать разработку спецификации сервера Hyper-V. Ис-
пользуйте для этого следующие указания.
В конфигурации памяти Hyper-V должна быть учтена: память для родительского раз-
дела — обычно это минимум 1 Гбайт; память виртуальных машин — это размер памя-
ти виртуальной машины плюс накладные расходы в размере 32 Мбайт памяти на пер-
вый гигабайт и по 8 Мбайт на каждый последующий гигабайт; а также память для всех
одновременных сеансов VMConnect.exe (по 20 Мбайт на каждый). Всегда очень хоро-
шо добавить некоторое дополнительное количество памяти (от 1 до 2 Гбайт). Новый
сервер Hyper-V должен иметь памяти как минимум столько же, как и нынешний хост
Virtual Server.
Дисковая система хранения имеет много характеристик, в том числе: скорость дисков,
размер дисков, конфигурация RAID, контроллеры и т. д. Если рассматривать только
объем системы хранения, то для сервера требуется: место для операционной системы
родительского раздела; место для виртуальных жестких дисков всех виртуальных ма-
шин; место для файлов сохраненного состояния (которое зависит от количества опера-
тивной памяти виртуальной машины); место для моментальных снимков (зависит от
планируемого количества моментальных снимков); место для дополнительных файлов
(таких, как образы дисков CD и DVD). Вам понадобится как минимум столько же дис-
кового пространства, что и на нынешнем хосте Virtual Server, плюс дополнительное
место для моментальных снимков (если вы планируете их использовать).
В сетевой конфигурации необходимо учесть потребности родительского раздела, ин-
терфейсов для обмена по протоколу iSCSI, интерфейсов для кластеризации сервера
Hyper-V (если сервер Hyper-V является членом кластера хостов), а также интерфейсов
для необходимого количества виртуальных сетей. Сервер Hyper-V должен иметь как
минимум одну гигабитную карту Ethernet (выделенную для задач управления роди-
тельского раздела), одну гигабитную карту Ethernet для обмена по iSCSI (если этот
протокол будет использоваться), две гигабитных карты Ethernet для кластерного обме-
на (если сервер является членом кластера) и одну гигабитную карту Ethernet для каж-
дой внешней виртуальной сети.
Virtual Server позволял на одну карту сетевого интерфейса конфигурировать несколько вир-
туальных сетей, но Hyper-V позволяет привязывать к карте сетевого интерфейса только
одну виртуальную сеть.
В процессорной конфигурации необходимо учесть потребности родительского раздела

и всех виртуальных машин, а также предусмотреть резерв на случай неожиданных
всплесков производительности. Родительский раздел Hyper-V должен иметь как мини-
мум одно зарезервированное за ним ядро процессора (для управления совместно ис-
пользуемыми ресурсами родительского раздела); каждая виртуальная машина должна
иметь как минимум одно ядро процессора; необходимо также предусмотреть резерв
(одно или больше ядер) на случай всплесков производительности и для возможности
расширения. Виртуальные машины в Virtual Server 2005 R2 SP1 могли иметь только
один процессор. В Hyper-V каждая виртуальная машина может иметь до четырех вир-
туальных процессоров (в зависимости от операционной системы). Если работающие на
существующем сервере Virtual Server виртуальные машины используют большое коли-
чество процессорных ресурсов, то при миграции можно будет добавить виртуальных
процессоров. Не забудьте учесть при оценке необходимые для этого дополнительные
процессоры.
Инсталляция Hyper-V
Когда вы определили требующуюся вам конфигурацию Hyper-V, купили и собрали
сервер, вы готовы инсталлировать на него Hyper-V. В главе 4 подробно описана ин-
сталляция Hyper-V и дан обзор необходимых после инсталляции изменений конфигу-
рации.
Миграция виртуальных сетей

После того как вы закончили инсталляцию по умолчанию и ее оптимизацию, вы гото-
вы мигрировать нынешнюю конфигурацию виртуальных сетей Virtual Server 2005 R2
SP1 на сервер Hyper-V. Это ручной процесс, который включает в себя повторное соз-
дание на сервере Hyper-V необходимых виртуальных сетей, существовавших на хосте
Virtual Server. Для этого вы должны установить соответствие между существующими
виртуальными сетями и физическими адаптерами (или адаптерами замыкания на себя
для случаев внутренних сетей). Когда вы поймете это соответствие, запишите настрой-
ки TCP/IP сетевого адаптера для идентификации подсети. Это позволит вам опреде-
лить, какой физический адаптер сервера Hyper-V вам необходимо использовать при
воссоздании внешних виртуальных сетей, а также сколько внутренних или частных
виртуальных сетей нужно создать.
Следующий шаг — воссоздание внешних виртуальных сетей на новом сервере Hyper-V
на правильных физических сетевых адаптерах при помощи собранной вами информа-
ции. Несмотря на то, что название виртуальной сети не обязано совпадать с тем назва-
нием, которое было у нее на хосте Virtual Server, во избежание путаницы было бы хо-
рошо его сохранить. После завершения настройки внешних виртуальных сетей воссоз-
дайте все необходимые внутренние и частные виртуальные сети.
Для обеспечения внутреннего для сервера Hyper-V обмена между гостевым и родитель-
ским разделом вам больше не надо добавлять адаптер замыкания на себя. Это можно сде-
лать при помощи внутренней сети. Для каждой (созданной с помощью адаптера замыкания
на себя) сети сервера Virtual Server создайте на сервере Hyper-V внутреннюю виртуальную
сеть.
Если сервер Hyper-V был снабжен дополнительными физическими сетевыми адапте-

рами для расширения количества внешних виртуальных сетей, то пришло время их
сконфигурировать. Помните об использовании выработанного вами соглашения об
именовании виртуальных сетей.
Выделите один адаптер для родительского раздела (не привязывайте его ни к одной внеш-
ней виртуальной сети).
Для каждой созданной вами внешней виртуальной сети вы должны деактивировать вирту-
альный сетевой адаптер родительского раздела, чтобы внешняя виртуальная сеть была
выделена исключительно для обмена между виртуальными машинами.
Соображения по миграции
Hyper-V не предоставляет возможности импорта тех виртуальных машин, которые
имеются на хосте Virtual Server 2005 R2 SP1; виртуальные машины вам придется миг-
рировать вручную. Основные составные блоки виртуальных машин в Virtual Server
2005 R2 SP1 и Hyper-V по существу одни и те же — виртуальный жесткий диск и кон-
фигурационный файл. Виртуальный жесткий диск не изменился, и его можно легко
мигрировать с Virtual Server на Hyper-V. Однако конфигурационный файл полностью
поменялся, и компания Microsoft не предоставляет инструментов для миграции настро-
ек из старого формата в новый.
Конфигурация загрузочного диска

Виртуальную машину сервера Virtual Server 2005 R2 SP1 можно подключить к вирту-
альному адаптеру SCSI, и она в такой конфигурации загрузится (это было рекомендуе-
мым для достижения наивысшей производительности вариантом). Так можно было
сделать потому, что адаптер SCSI был эмулированным и поэтому был доступен на ста-
дии загрузки. Однако на сервере Hyper-V виртуальные машины загружаться с адаптера
SCSI не могут (поскольку он синтетический, а синтетические устройства на стадии за-
грузки не доступны). Поэтому настроенные на загрузку с SCSI виртуальные машины
сервера Virtual Server должны быть (в процессе миграции на Hyper-V) преобразованы
для загрузки с IDE.
В отличие от виртуальных жестких дисков с интерфейсом IDE на сервере Virtual Server, на
сервере Hyper-V виртуальные жесткие диски с интерфейсом IDE имеют практически не
уступающую дискам с интерфейсом SCSI производительность.
Дополнения Virtual Machine Additions

Для обеспечения эмулированных устройств и для повышения производительности вир-
туальных машин сервер Virtual Server 2005 R2 SP1 использует улучшенные драйверы.
Hyper-V предоставляет виртуальным машинам синтетические устройства и улучшения
производительности. Архитектура и интерфейсы этих двух технологий несовместимы,
поэтому в процессе миграции на Hyper-V вы должны удалить дополнения Virtual
Machine Additions. Несмотря на то, что есть вариант удалить эти дополнения и после
миграции виртуальных машин на Hyper-V, ваша возможность сделать это зависит от

инсталлированной версии Virtual Machine Additions. Лучший вариант — удалить
Virtual Machine Additions до миграции на Hyper-V.
Диски Undo
Эта функциональная возможность в Hyper-V отсутствует, она заменена более мощной
функцией моментальных снимков. Вы не сможете мигрировать диски Undo в Hyper-V,
до миграции жесткого диска виртуальной машины на Hyper-V их необходимо удалить
или зафиксировать.
Сохраненные состояния
Как Virtual Server 2005 R2 SP1, так и Hyper-V могут сохранять состояние работающей
виртуальной машины на диск. Эта концепция аналогична режиму "спячки" (гиберна-
ция). В сервере Virtual Server 2005 R2 файл сохраненного состояния — это vsv-файл,
который хранит содержимое памяти и информацию по выполняющимся процессам,
потокам и стеку процессора. Сервер Hyper-V разбивает файл сохраненного состояния
на две части: содержимое памяти (bin) и информацию стека и процессов (vsv). Вслед-
ствие таких изменений сохраненные состояния мигрировать нельзя, поэтому их необ-
ходимо объединять или удалять до миграции.
Разница в уровне абстракции Hardware Abstraction Layer

Работающие на сервере Virtual Server 2005 R2 виртуальные машины могут иметь толь-
ко один виртуальный процессор. Hyper-V позволяет сконфигурировать виртуальной
машине до четырех виртуальных процессоров. Это создает проблему совместимости с
уровнем абстрагирования от оборудования (hardware abstraction layer, HAL). Для вир-
туальных машин Hyper-V требуется многопроцессорный Advanced Configuration and
Power Interface (ACPI) HAL. Виртуальные машины сервера Virtual Server 2005 R2 мо-
гут иметь HAL как с поддержкой ACPI, так и без нее (в зависимости от того, как они
были созданы и какая версия дополнений загружена). Вне зависимости от того, какой
HAL имеет существующая виртуальная машина, он должен быть изменен во время ее
миграции на Hyper-V. Инструкции по изменению HAL для виртуальных машин Vista и
Windows 2008 см. по адресу: http://technet.microsoft.com/en-us/library/dd296684.aspx.
Разностные диски
Как Hyper-V, так и Virtual Server 2005 R2 поддерживают разностные диски, и техноло-
гия эта не изменилась. Для разностных дисков требуется, чтобы относительный путь к
родительскому и дочернему дискам (при их переносе с компьютера на компьютер или
на одном и том же компьютере) сохранялся неизменным. Относительный путь к роди-
тельскому VHD хранится в верхнем заголовке диска дочернего VHD. Если дочерний
VHD копируется, а родитель — нет (или если относительный путь двух этих файлов не
сохраняется), то дочерний VHD не будет иметь всей необходимой ему информации и
разностный диск станет нерабочим.
Во время миграции вы можете пожелать модифицировать структуру каталогов хранения
виртуальных машин. Если изменения в структуре каталогов нарушают относительный
маршрут разностного диска, то вы можете отремонтировать виртуальный жесткий диск при
помощи функции Inspect Disk оснастки Hyper-V Manager консоли ММС.
Кластеры виртуальных машин

с совместно используемой шиной SCSI
Эмулированные контроллеры виртуальных машин в Virtual Server 2005 R2 предостав-
ляли режим, который назывался "совместное использование SCSI" (параллельной ши-
ны SCSI). Этот режим контроллера позволял создать из виртуальных машин кластер
Windows Server 2003. Hyper-V перешел на использование синтетических контроллеров
SCSI и не имеет возможности перевода контроллеров SCSI в режим параллельной ши-
ны SCSI. Вы по-прежнему можете создать кластер из виртуальных машин в Hyper-V,
но для подключения удаленных LUN iSCSI к виртуальным машинам вам придется ис-
пользовать инициатор iSCSI Initiator. Кластеры виртуальных машин Virtual Server
должны быть мигрированы на Hyper-V вручную.
Миграция виртуальных машин

В последующих разделах будут даны указания по процессу миграции виртуальных
машин с сервера Virtual Server 2005 R2 SP1 на Hyper-V. Для вашей инсталляции серве-
ра Virtual Server, скорее всего, понадобятся не все шаги этого процесса (это зависит от
используемых вами на сервере Virtual Server функциональных возможностей). Этот
процесс содержит следующие задачи:
определение совместимости с Hyper-V;
преобразование загрузки со SCSI в загрузку с IDE;
удаление дополнений Virtual Server Additions;
удаление сетевых адаптеров;
фиксация всех дисков Undo (или их удаление);
объединение или удаление сохраненных состояний;
объединение всех разностных дисков;
проверка уровня HAL;
копирование виртуального жесткого диска на новый сервер Hyper-V;
создание новой виртуальной машины с использованием существующего VHD;
инсталляция служб интеграции Integration Services.
Определение совместимости
Перед миграцией виртуальной машины вы должны определить, поддерживается ли ее
операционная система и поддерживает ли поставщик программного обеспечения рабо-
тающие в ней приложения в режиме промышленного использования на сервере Hyper-V.

Сравните операционную систему со списком поддерживаемых сервером Hyper-V гос-
тевых операционных систем (и не забудьте обратить внимание на версии и сервисные
пакеты).
Преобразование загрузки со SCSI в загрузку с IDE

Мы уже обсуждали, что Hyper-V не поддерживает загрузку с синтетического контрол-
лера SCSI. Поэтому до миграции загружающейся с адаптера SCSI виртуальной маши-
ны сервера Virtual Server 2005 R2 на Hyper-V вы должны преобразовать ее для загрузки
с контроллера IDE. Для миграции загрузочного диска с контроллера SCSI на контрол-
лер IDE выполните следующие шаги:
1. Запустите административную Web-консоль Virtual Server.
2. В меню Virtual Machines выберите Configure, а затем в списке — название вирту-
альной машины.
3. В меню Configuration выберите Hard Disks, чтобы отобразить страницу Virtual
Hard Disk Properties, которая показывает текущую конфигурацию всех жестких
дисков виртуальной машины (рис. 8.1).
Рис. 8.1. Страница Virtual Hard Disk Properties
4. Для преобразования виртуального жесткого диска, чтобы он загружался с первич-

ного контроллера IDE (с идентификатором ID 0), выберите Primary channel (0)
в раскрывающемся списке Attachment (рис. 8.2).
5. Для сохранения изменений нажмите кнопку OK.
Мигрируйте VHD с контроллера SCSI на контроллер IDE
Если вы стандартно подключали VHD к контроллерам SCSI (как это делало большинство из
соображений производительности), то ручная миграция этих дисков на контроллеры IDE
может занять у вас много времени. Далее приведен скрипт, который может помочь автома-
тизировать этот процесс. Сохраните его под именем SCSI2IDE.vbs и запускайте с парамет-
ром, указывающим название виртуальной машины, для которой вы хотите переконфигури-
ровать загрузочный диск (с использования SCSI на использование IDE).
Тони Сопер (Tony Soper, Senior Technical Writer (Windows Server Technical Writing Team))
Рис. 8.2. Виртуальный жесткий диск с выбранным каналом Primary IDE
Этот скрипт содержится на приложенном к данной книге диске в каталоге \Scripts\Chapter 8.
Option Explicit
dim colArgs, colVMs

dim hdskConnections
dim objhdskConnection
dim strFile
Set objVS = CreateObject("VirtualServer.Application")

set colVMs = objVS.VirtualMachines
set colArgs = wscript.Arguments
id = 0
For Each objVM in colVMs

If objVM.Name = colArgs.item(0) Then
set hdskConnections = objVM.HardDiskConnections
For Each objhdskConnection In hdskConnections
set objHardDisk = objhdskConnection.HardDisk
strFile = objHardDisk.File
wscript.echo "VM Disk File" & strFile
If objhdskConnection.BusType = 1 Then
rtn = objhdskConnection.SetBusLocation (0,0,id)
id = id+1
End If
Next
End if
Next
Перед запуском этого скрипта вы должны убедиться, что все виртуальные машины хоста
Virtual Server выключены.
Удаление дополнений Virtual Machine Additions

Дополнения Virtual Machine Additions сервера Virtual Server 2005 R2 SP1 несовмести-
мы с архитектурой Hyper-V и не смогут с ней правильно работать. Несмотря на то, что
можно удалить дополнения Virtual Machine Additions (версии 13.813 и более новые) из
уже мигрировавшей виртуальной машины, гораздо менее рискованно удалить допол-
нения до миграции виртуальной машины.
Для удаления дополнений Virtual Machine Additions необходимо выполнить следующие
шаги:
1. Включить виртуальную машину и зарегистрироваться с административными пра-
вами.
2. В виртуальной машине открыть Control Panel, а затем дважды щелкнуть по значку
Add Or Remove Programs или Programs And Features (в зависимости от версии
операционной системы).
3. Выбрать Virtual Machine Additions, а потом выбрать Remove, либо щелкнуть пра-
вой кнопкой мыши и выбрать Uninstall (в зависимости от версии операционной
системы).
4. Нажать в появившемся диалоговом окне кнопку Yes для подтверждения.
5. После успешного удаления дополнений Virtual Machine Additions перезапустить
виртуальную машину.
Удаление карты эмулированных сетевых интерфейсов

Виртуальные машины сервера Virtual Server 2005 R2 SP1 имеют одну инсталлирован-
ную по умолчанию карту сетевого интерфейса. Карта сетевого интерфейса эмулирует
адаптер Intel 21140. В Hyper-V сетевым интерфейсом по умолчанию является не обыч-
ный сетевой адаптер (который также эмулирует адаптер Intel 21140), а синтетический
сетевой адаптер. Если вы попытаетесь перенести виртуальную машину с инсталлиро-
ванным адаптером Intel 21140, то сетевой адаптер станет скрытым устройством. Вы
можете инсталлировать службы интеграции Hyper-V, и все будет казаться как будто бы
в порядке, но если эмулированный адаптер Intel 21140 имел статический адрес IP, то
любая попытка присвоить этот статический адрес IP новому синтетическому сетевому
адаптеру приведет к выдаче окна предупреждения с сообщением, что данный IP-адрес
уже используется.
Для удаления сетевого адаптера из виртуальной машины выполните следующие шаги:
1. Включите виртуальную машину.
2. Зарегистрируйтесь с административными правами.
3. Откройте Control Panel и дважды щелкните по значку Device Manager.
4. Раскройте узел Network Adapters.
5. Щелкните правой кнопкой мыши по адаптеру Intel 21140 и выберите пункт
Uninstall.
6. Выключите виртуальную машину.
После миграции виртуальной машины на Hyper-V в ней будет инсталлирован синтети-

ческий адаптер. Однако он может не заработать до тех пор, пока вы не инсталлируете
службы интеграции.
Синтетический сетевой адаптер в Hyper-V не поддерживает загрузку PXE. Для использова-
ния загрузки РХЕ необходимо применять обычный адаптер.
Фиксирование или удаление дисков Undo

Сервер Virtual Server 2005 R2 обеспечивал такой дисковый режим, в котором все изме-
нения записывались в отдельный файл. Этот режим (под названием Undo) позволял
вам делать на диске изменения (для проверки ваших различных предположений) и не
опасаться того, что они останутся там навсегда. Однако диски Undo не были достаточ-
но гибким решением в том случае, если нужно проверять множество различных пред-
положений. Поэтому в Hyper-V данная технология была заменена моментальными
снимками. Это означает, что все диски Undo виртуальных машин сервера Virtual Server
должны быть удалены или зафиксированы на жестком виртуальном диске до его ми-
грации на Hyper-V.
Если в виртуальной машине настроено использование дисков Undo, но активного дис-
ка Undo нет, тогда никаких дополнительных шагов делать не надо. Если же вам нужно
зафиксировать или удалить диск Undo, то эта процедура несколько варьируется в зави-
симости от того, включена виртуальная машина или нет.
Для фиксации или удаления дисков Undo включенной виртуальной машины выполните
следующие инструкции:
1. Выключите виртуальную машину.
2. Если вы хотите внести изменения в виртуальный диск, то выберите Select Turn Off
Virtual Machine And Commit Undo Disks; либо выберите Turn Off Virtual
Machine And Discard Undo Disks для удаления изменений диска Undo.
Для фиксации или удаления дисков Undo выключенной виртуальной машины выпол-
ните следующие инструкции:
1. Запустите Web-сайт администрирования Virtual Server 2005 Administration Web site.
2. На странице Master Status найдите в списке нужную виртуальную машину и щелк-
ните по стрелке для показа меню действий.
3. На рис. 8.3 показаны имеющиеся пункты меню. Выберите в меню либо пункт
Merge Undo Disks, либо пункт Discard Undo Disks.
Рис. 8.3. Меню действий Undo Disk для виртуальной машины

Восстановление или удаление сохраненных состояний

Сохраненные состояния Virtual Server 2005 R2 не совместимы с сохраненными состоя-
ниями Hyper-V, поэтому виртуальную машину следует должным образом выключить
(либо удалить сохраненное состояние). Если виртуальная машина включена, то завер-
шите ее работу (изнутри виртуальной машины) и не сохраняйте при этом ее состояние.
Для удаления сохраненного состояния включенной виртуальной машины выполните
следующие инструкции:
2. На странице Master Status найдите в списке нужную виртуальную машину и щелк-
ните по стрелке для показа меню действий.
3. На рис. 8.4 показаны имеющиеся пункты меню. Выберите в меню либо пункт
Restore From Saved State, либо пункт Discard Saved State.
Рис. 8.4. Меню действий Saved State для виртуальной машины
4. Если вы выбрали восстановление сохраненного состояния, то после восстановления

виртуальной машины ее работу необходимо завершить.
5. Если вы выбрали удаление сохраненного состояния, тогда никаких дальнейших
действий не требуется.
Слияние разностных дисков

Разностные диски позволяют вам экономить дисковое пространство (создавая цепочку
зависимых друг от друга виртуальных жестких дисков). Это избавляет от необходимо-
сти дублировать данные. Если вы мигрируете все (содержащие разностные диски) вир-
туальные машины с хоста Virtual Server 2005 R2 на один и тот же сервер Hyper-V, то-
гда вам не нужно делать объединений разностных дисков. Однако на обоих хостах вам
придется сохранить одинаковый относительный путь (в противном случае вам придет-
ся восстанавливать связи родитель-потомок).
Если вы планируете мигрировать виртуальные машины (которые зависят от одного
разностного диска) на разные серверы Hyper-V, то вам придется объединить разност-
ные диски, чтобы убрать эту зависимость.
Для объединения разностных дисков виртуальной машины выполните следующие ин-
струкции:
1. Выключите виртуальную машину с разностным диском.
3. На странице Master Status выберите Inspect Disk в меню Virtual Disks.
4. Укажите тот виртуальный жесткий диск, который имеет родителя и подлежит объ-
единению (рис. 8.5), и нажмите кнопку Inspect.
Рис. 8.5. Страница Inspect Virtual Hard Disk
5. Будет показана страница Properties and Actions (рис. 8.6). Выберите Merge Virtual
Hard Disk в меню Actions (для объединения родительского и дочернего виртуаль-
ных жестких дисков).
Рис. 8.6. Страница Properties and Actions разностного диска
6. Будет показана страница Merge Virtual Hard Disk (рис. 8.7). Отметьте переключа-
тель Merge to New Virtual Hard Disk и укажите полный путь к новому виртуально-
му жесткому диску, который будет создан в результате операции объединения. По
желанию вы можете указать и тип создаваемого виртуального жесткого диска —
динамический или фиксированный.
7. После выбора всех опций нажмите кнопку Merge.
Рис. 8.7. Страница опций Merge Virtual Hard Disk

Полученный в результате объединения виртуальный жесткий диск вы будете мигриро-

вать на сервер Hyper-V.
Проверка уровня Hardware Abstraction Layer

Hyper-V использует многопроцессорный HAL с поддержкой ACPI. Несмотря на то, что
вы, вероятно, получите подсказку о необходимости обновления HAL при инсталляции
служб интеграции, лучше еще до миграции подготовить компьютер для определения
HAL, чтобы он был правильно определен и обновлен.
Перед миграцией виртуальной машины выполните следующие шаги для смены HAL:
1. Включите виртуальную машину.
2. Зарегистрируйтесь с административными правами.
3. Запустите утилиту System Configuration (MSConfig.exe). Для этого нужно нажать
кнопку Start, затем выбрать пункт Run, потом ввести msconfg, а затем нажать кноп-
ку OK.
4. Перейдите на вкладку Boot, а потом выберите Advanced Options.
5. Установите флажок Detect HAL, нажмите кнопку OK, а затем завершите работу
виртуальной машины.
Завершение миграции
После выполнения всех необходимых предварительных шагов последние задачи — это
копирование виртуального жесткого диска с сервера Virtual Server 2005 R2 на новый
сервер Hyper-V и создание новой виртуальной машины, которая будет использовать
этот виртуальный жесткий диск.
Для создания новой виртуальной машины выполните следующие шаги:
1. На сервере Hyper-V создайте каталог для хранения новой виртуальной машины (не
на системном диске). Используйте в качестве имени каталога название виртуальной
машины (например, D:\VMs\NEWVM).
2. Скопируйте виртуальный жесткий диск с хоста Virtual Server 2005 R2 в новый ка-
талог.
3. Откройте оснастку Hyper-V Manager консоли ММС.
4. Выберите New в меню Actions, а затем выберите Virtual Machine. Запустится мас-
тер New Virtual Machine Wizard. Нажмите кнопку Next.
5. Укажите название виртуальной машины (используйте то же самое название, что и
у созданного вами каталога) в текстовом поле Name.
6. Установите флажок Store the virtual machine in a different location и введите путь
к каталогу на уровень выше, чем созданный вами каталог виртуальной машины
(т. е. это будет, например, D:\VMs) в текстовом поле Location (рис. 8.8). Нажмите
кнопку Next.
Это позволит мастеру использовать созданный вами каталог для всех файлов вирту-
Рис. 8.8. Укажите название и местоположение для хранения новой виртуальной машины
7. На странице Assign Memory укажите требуемое для виртуальной машины количе-

ство памяти и нажмите кнопку Next.
8. На странице Configure Networking выберите виртуальную сеть, которую надо
подключить к виртуальной машине, а потом нажмите кнопку Next.
9. На странице Connect Virtual Hard Disk (рис. 8.9) выберите опцию Use An existing
virtual hard disk и укажите путь к виртуальному жесткому диску (такому, как
D:\VMs\NEWVM.VHD), а затем нажмите кнопку Next.
10. На странице Completing The New Virtual Machine Wizard отметьте опцию Start
The virtual machine after it is created, а затем нажмите кнопку Finish.
11. Виртуальная машина включится.
12. После загрузки виртуальной машины на экране регистрации войдите в систему
с административными правами.
13. В меню VMConnect Actions выберите пункт Insert Integration Services Setup Disk.
После этого должна начаться инсталляция служб интеграции для виртуальной ма-
шины. Завершите инсталляцию и перезагрузите виртуальную машину.
Теперь виртуальная машина мигрирована на Hyper-V.
Рис. 8.9. Страница Connect Virtual Hard Disk
Инструмент миграции VMC to Hyper-V
Для миграции виртуальной машины с Virtual Server на Hyper-V требуется до миграции вне-
сти изменения в виртуальную машину, мигрировать виртуальный жесткий диск на сервер
Hyper-V, создать новую виртуальную машину (использующую мигрировавший виртуальный
жесткий диск), модифицировать конфигурацию виртуальной машины. Несмотря на то, что
вы можете выполнить все шаги миграции вручную, инструмент VMC to Hyper-V (называе-
мый также VMC2HV) может импортировать полную конфигурацию виртуальной машины
Virtual Server на Hyper-V и модифицировать конфигурацию виртуальной машины (и все это
за один шаг).
VMC2HV можно использовать как локально, так и удаленно. При локальном использовании
инструмент работает на сервере Hyper-V, что ограничивает его использование системами
под управлением Windows Server 2008 с графическим интерфейсом пользователя (по-
скольку для работы ему нужна .NET Framework). Для инсталляций типа Server Core серве-
ров Windows Server 2008 и Hyper-V Server 2008 его можно использовать с удаленной ин-
сталляции Windows Server 2008 или Windows Vista с инсталлированной .NET Framework.
Для максимально простого использования этого инструмента мы рекомендуем скопировать
VMC и файлы виртуальных жестких дисков на сервер Hyper-V в каталог с названием новой
виртуальной машины. Например, вы могли бы скопировать файлы Machine1.vmc и
Machine1.vhd в каталог D:\vm\machine1. Когда инструмент импортирует файл Machine1
в D:\vm, он будет использовать каталог D:\vm\machine1 и создаст новую виртуальную ма-
шину в этом каталоге. Таким образом, все принадлежащие машине Machine1 файлы будут
содержаться в одном каталоге.
При импорте VMC2HV читает конфигурационный файл и отображает все свойства. Те
свойства, которые больше не существуют в Hyper-V, просто игнорируются, а новые свойст-
ва вы можете настроить в Hyper-V вручную. На рис. 8.10 показан этот инструмент с уда-
ленным подключением (после импорта файла VMC).
Рис. 8.10. Стартовая страница VMC2HV
Инструмент имеет несколько вкладок со свойствами виртуальной машины. Вкладка

Processor позволяет указать количество логических процессоров, управление ресурсами и
функциональность процессора. На вкладке Drives (рис. 8.11) показаны такие виртуальные
диски, как дисководы гибких дисков, дисководы CD/DVD, а также виртуальные жесткие дис-
ки и их местоположение (IDE/SCSI и идентификатор ID устройства).
Для такой виртуальной машины, которая в сервере Virtual Server загружалась с SCSI, инст-
румент VMC2HV предоставляет возможность поменять диск SCSI в позиции 0 на диск IDE
в позиции 0.
Вкладка Networking (рис. 8.12) показывает количество сетевых адаптеров и позволяет вам
установить их в тип Legacy (в сервере Virtual Server адаптер всегда является эмулирован-
ным адаптером Dec/Intel). По умолчанию VMC2HV создает синтетический адаптер (так же,
как это делается по умолчанию в Hyper-V). Данный инструмент также позволяет вам ука-
зать, к какой виртуальной сети и к какой VLAN вы хотите подключить адаптер.
Специальные функции включают: распознавание гостевой операционной системы; ограни-
чение количества логических процессоров (в соответствии с политикой поддержки); преду-
преждение о том, что виртуальный диск не найден в текущем местоположении. Новые пути
для виртуальных жестких дисков можно редактировать при помощи инструмента VMC2HV,
который доступен для скачивания по ссылке: http://blogs.technet.com/matthts/.
Мэттис тен Сэлдам (Matthijs ten Seldam, Technology Specialist (Microsoft Sales))
Рис. 8.11. Вкладка Drives свойств виртуальной машины VMC2HV
Рис. 8.12. Вкладка Networking свойств виртуальной машины VMC2HV

Резюме
Миграция виртуальных машин с сервера Virtual Server 2005 R2 на Hyper-V включает в
себя миграцию и конфигурации хоста, и самих виртуальных машин. В этой главе мы
обсудили все, что вам нужно обдумать перед миграцией хоста и виртуальных машин.
Ключевое решение, которое вам необходимо принять до миграции хоста — это опре-
делить, имеются ли виртуальные машины с такими операционными системами, кото-
рые не поддерживаются на Hyper-V (в этом случае вам придется сохранить хост Virtual
Server).
Данная глава снабдила вас важными соображениями и шагами по подготовке жестких
дисков виртуальной машины к миграции. Среди них: учет разницы в оборудовании
(контроллеры SCSI, сетевые адаптеры, а также HAL); очистка виртуального жесткого
диска (Undo, сохраненные состояния, а также разностные диски); удаление дополнений
Virtual Machine Additions. Вы узнали также, что после миграции хоста вы можете соз-
дать новую виртуальную машину с использованием существующего виртуального же-
сткого диска, а затем вы должны инсталлировать службы интеграции Integration
Services (для обеспечения поддержки синтетических устройств и повышения произво-
дительности).

руководство Virtual Machine Migration Guide — информация о миграции виртуаль-
ных машин Virtual Server 205 R2 на Hyper-V, доступная по ссылке:
http://technet.microsoft.com/en-us/library/dd296684.aspx;
инструмент миграции VMC2HV Migration Tool для упрощения процесса миграции,
доступный по ссылке: http://blogs.technet.com/matthts/.
ГЛАВА 9
Знакомимся с сервером
Windows Server 2008 R2 Hyper-V
В главе 2 мы предложили вам общий обзор основных функциональных возможностей,
которые реализованы в самой последней версии Hyper-V. В данной главе вы найдете
более подробный обзор новых функций, которые имеются в серверах Windows Server
2008 Release 2 (R2) Hyper-V и Hyper-V Server 2008 R2. Поскольку представленная
в этой главе информация основывается на бета-версиях, то в окончательных версиях
могут появиться некоторые отличия. Своими продуктами Windows Server 2008 R2
Hyper-V и Hyper-V Server 2008 R2 компания Microsoft продолжает расширять список
возможностей Hyper-V, чтобы повысить гибкость, масштабируемость и готовность
платформы виртуализации.
В этой главе Hyper-V Version 1 (V1) относится к Windows Server 2008 Hyper-V, а Hyper-V R2
относится к Windows Server 2008 R2 Hyper-V.
Инсталляция роли Hyper-V

на Windows Server 2008 R2
Для того чтобы как можно быстрее начать изучение новых функций Hyper-V R2, сле-
дует выполнить полную инсталляцию Windows Server 2008 R2, а затем использовать
консоль Server Manager для инсталляции роли Hyper-V.
Вы можете скачать версию Windows Server 2008 R2 Beta с Web-сайта компании Microsoft по
ссылке: http://www.microsoft.com/windowsserver2008/en/us/default.aspx.
Для сервера Windows Server 2008 R2 Hyper-V нужно включить в BIOS компьютера ап-
паратную функцию Data Execution Prevention (DEP). Точнее говоря, необходимо акти-
вировать бит XD архитектуры Intel или бит NX архитектуры AMD.
Для инсталляции роли Hyper-V на полной инсталляции Windows Server 2008 R2 необ-
ходимо при помощи Server Manager выполнить следующие шаги:
1. В левом нижнем углу панели задач щелкните по значку Server Manager (рис. 9.1).
2. В менеджере Server Manager выберите в левой панели узел Roles (рис. 9.2). В пра-
вой панели в Roles Summary вы увидите список всех инсталлированных на сервере
ролей, а также элементы управления для добавления и удаления ролей.
Рис. 9.1. Значок Server Manager
Рис. 9.2. Инсталлированные роли и средства добавления и удаления ролей
3. Нажмите кнопку Add Roles для запуска мастера Add Roles Wizard.
4. На странице Before You Begin (рис. 9.3) нажмите кнопку Next.
Глава 9. Знакомимся с сервером Windows Server 2008 R2 Hyper-V 345
Рис. 9.3. Страница Before You Begin мастера Add Roles Wizard
5. На странице Select Server Roles (рис. 9.4) установите флажок роли Hyper-V, а за-
тем нажмите кнопку Next.
6. Прочитайте информацию на вводной странице роли Hyper-V (рис. 9.5), а затем на-
7. На странице Create Virtual Networks (рис. 9.6) вы видите список инсталлирован-
ных на сервере сетевых адаптеров и можете выбрать один или несколько. Выби-
рать адаптер не обязательно, но если вы это сделаете, то во время инсталляции ро-
ли Hyper-V для каждого выбранного адаптера будет создана внешняя виртуальная
сеть. Кроме того, один сетевой адаптер автоматически резервируется и выделяется
для сетевого трафика раздела управления (родительского раздела). После выбора
адаптеров нажмите кнопку Next.
8. Просмотрите информацию на странице Confirm Installation Selections (рис. 9.7),
а затем нажмите кнопку Install.
9. После инсталляции файлов Hyper-V вы получите сообщение о необходимости пе-
резапуска сервера (рис. 9.8). Нажмите кнопку Close для перезапуска сервера.
10. После перезапуска сервера запускается мастер Resume Configuration Wizard, кото-
рый показывает результаты процесса инсталляции роли Hyper-V (рис. 9.9). Про-
смотрите информационные сообщения, а затем нажмите кнопку Close.
Рис. 9.4. Выбор роли Hyper-V на странице Select Server Roles
Рис. 9.5. Вводная страница роли Hyper-V

Рис. 9.6. На странице Create Virtual Networks выберите один или несколько сетевых адаптеров
Рис. 9.7. Страница Confirm Installation Selections

Рис. 9.8. После инсталляции вы получаете сообщение о перезагрузке сервера
Рис. 9.9. Результаты процесса инсталляции роли Hyper-V

Вы можете скачать версию Hyper-V Server 2008 R2 Beta с Web-сайта компании Microsoft по
ссылке: http://www.microsoft.com/servers/Hyper-V-server/default.mspx.
Обзор новых функций Hyper-V

В табл. 9.1 дана сводка основных функций сервера Windows Server 2008 R2 Hyper-V
версий Enterprise и Datacenter, а также бесплатного продукта Hyper-V Server 2008 R2.
Существует также и версия Windows Server 2008 R2 Hyper-V Standard Edition, но она в
этой таблице не показана. Существенным изменением в версии Hyper-V R2 является
поддержка 32 процессорных ядер (для серверов с восемью четырехъядерными процес-
сорами). Сервер Windows Server 2008 Hyper-V поддерживает 16 ядер, а после инстал-
ляции дополнительного обновления KB956710 он сможет поддерживать 24 ядра.
Таблица 9.1. Сравнение функциональных возможностей Hyper-V R2
Microsoft Hyper-V Windows Server 2008 R2 Windows Server 2008 R2

Функция
Server 2008 R2 Enterprise Datacenter
Поддержка х86 Только Только Только

для гостевой ОС для гостевой ОС для гостевой ОС
Поддержка х64 Для хоста и для Для хоста Для хоста
гостевой ОС и для гостевой ОС и для гостевой ОС
Количество VM Максимум 256 Максимум 256 Максимум 256
Количество памяти 1 1 1
хоста, Тбайт
Количество процессо- Максимум 32 ядра Максимум 32 ядра Максимум 32 ядра
ров хоста
Количество виртуаль- Не ограничено Не ограничено Не ограничено
ных сетей
Память гостевой VM, Максимум 64 Максимум 64 Максимум 64
Гбайт
Процессоров Максимум 4 Максимум 4 Максимум 4
в гостевой VM на одну VM на одну VM на одну VM
Виртуальных сетевых 4 устаревших, 4 устаревших, 4 устаревших,
карт в гостевой VM 8 синтетических 8 синтетических 8 синтетических
Адаптеров системы 2 IDE, 4 SCSI 2 IDE, 4 SCSI 2 IDE, 4 SCSI
хранения в гостевой
VM
Устройств хранения 4 IDE, 256 SCSI 4 IDE, 256 SCSI 4 IDE, 256 SCSI
в гостевой VM
Поддержка кластери- Да Да Да
зации
Quick Migration Да Да Да
Live Migration Да Да Да
Включено лицензий Нет 1 физическая, 1 физическая, количество
на использование 4 VM VM не ограничено
В дополнение к функции Quick Migration (быстрая миграция) сервер Windows Ser-

ver 2008 R2 Hyper-V поддерживает и функцию Live Migration ("горячая" миграция). Эта
функция позволяет вам переносить виртуальную машину между узлами кластера без
прерывания в обслуживании, что позволяет более гибко управлять плановыми и не-
плановыми простоями, а также балансировать нагрузку на фермах серверов Hyper-V.
Функциональные возможности Live Migration и ее настройка обсуждаются в следующем
разделе.
Набор функциональных возможностей сервера Hyper-V Server 2008 R2 был сущест-

венно расширен и теперь он вполне сравним с версией Windows Server 2008 R2
Enterprise Edition. Сервер Hyper-V Server 2008 R2 поддерживает до 1 Тбайт физической
памяти сервера, выделение памяти виртуальной машине может достигать 64 Гбайт,
максимальное количество виртуальных машин — 256. Все это позволяет разворачивать
его как решение для широкого спектра конфигураций виртуализации. Кроме того, сер-
вер Hyper-V Server 2008 R2 поддерживает отказоустойчивую кластеризацию, Quick
Migration и Live Migration (в версии Hyper-V Server 2008 этих функций нет). В отличие
от Windows Server 2008 R2 Hyper-V, сервер Hyper-V Server 2008 R2 имеет для управле-
ния только локальную командную строку и утилиту конфигурации с текстовым интер-
фейсом, хотя им можно управлять и удаленно при помощи менеджеров Hyper-V
Manager и Failover Cluster Manager.
ВАЖНО
Так же, как и Hyper-V Server 2008, сервер Hyper-V Server 2008 R2 не является версией сер-
вера Windows, и вместе с ним вы не получаете никаких лицензий Windows. Поэтому для
каждой виртуальной машины на базе Windows вы должны купить лицензию Windows.
Функция Live Migration

В сервере Hyper-V (V1) функция Quick Migration для переноса виртуальной машины
(без потери данных и с минимальным прерыванием в обслуживании) между узлами
кластера использует технологию Windows Server 2008 Failover Clustering. Прерывание
в обслуживании происходит потому, что виртуальная машина переводится в сохранен-
ное состояние (для записи ее памяти и состояния процессоров на диск, чтобы затем
передать ее на узел назначения). После переноса на узел назначения, а также переза-
грузки памяти виртуальной машины и состояния ее процессоров обслуживание возоб-
новляется.
При помощи функции Live Migration сервер Hyper-V R2 обеспечивает возможность
переносить виртуальные машины между узлами кластера без потери данных и без пре-
рывания в обслуживании. Подобно функции Quick Migration, функция Live Migration не
зависит от работающей в виртуальной машине операционной системы. Более того,
поддерживающие функцию Quick Migration конфигурации кластеров поддерживают
также и функцию Live Migration, но только при выполнении следующих требований:
все узлы кластера Hyper-V должны использовать процессоры одного изготовителя и
одного типа;
все узлы кластера Hyper-V должны находиться на одной подсети TCP/IP;

все узлы кластера Hyper-V должны иметь доступ к совместно используемой системе
хранения.
Сервер Hyper-V R2 поддерживает те же системы хранения, что и сервер Hyper-V (V1).
Миграцию Live Migration можно запустить из менеджеров Failover Cluster Manager и

System Center Virtual Machine Manager, а также при помощи скрипта WMI или
PowerShell.
ВАЖНО
Если вы используете System Center Virtual Machine Manager, то для запуска миграции Live
Migration серверов Windows Server 2008 R2 Hyper-V и Hyper-V Server 2008 R2 вам понадо-
бится System Center Virtual Machine Manager версии R2.
Процесс миграции Live Migration

Миграция Live Migration — это многошаговый процесс, который начинается с созда-
ния ТСР-подключения от узла-источника к узлу-назначению. При помощи этого под-
ключения на узел назначения передаются данные по конфигурации виртуальной ма-
шины, которые используются для создания новой виртуальной машины с идентичными
настройками. Эти настройки включают: определение виртуальных адаптеров хранения,
виртуальные сетевые адаптеры, выделение виртуальных процессоров и памяти, а также
прочие параметры конфигурации виртуальной машины.
После завершения конфигурации виртуальной машины на узле назначения, на него
передаются с узла-источника страницы памяти виртуальной машины. Поскольку вир-
туальная машина на узле-источнике продолжает работать, то Hyper-V отслеживает мо-
дификации страниц памяти и итеративно копирует модифицированные страницы на
узел-назначение. Этот процесс продолжается до тех пор, пока не будет достигнут пре-
дел этих итераций (или пока все модифицированные страницы памяти не будут скопи-
рованы на узел-назначение).
Следующим шагом необходимо приостановить работу виртуальной машины, скопиро-
вать оставшиеся модифицированные страницы памяти, а также передать (на узел-
назначение) состояние регистров процессора и устройств. На этой стадии вы уже не
можете отменить процесс Live Migration.
Пока виртуальная машина приостановлена, управление системой хранения виртуаль-
ной машины (в том числе виртуальными и транзитными жесткими дисками) передает-
ся узлу-назначению. Затем, когда виртуальная машина достигает согласованного со-
стояния, ее работа возобновляется на узле-назначении.
И наконец, физический сетевой коммутатор обновляет свои таблицы данными нового
порта (это тот порт физического сетевого коммутатора, к которому подключен узел
назначения), на который будет направляться сетевой трафик для виртуальной машины,
после чего виртуальная машина удаляется из узла-источника.
Производительность при миграции Live Migration

Во избежание прерывания обслуживания время приостановки виртуальной машины
нужно минимизировать (чтобы не превысить тайм-аутов приложения или протокола
ТСР). Поэтому совершенно необходимым архитектурным элементом кластера Hyper-V
является высокоскоростное сетевое подключение (как минимум гигабитный
Ethernet) — для оптимизации передачи данных памяти и состояния между узлами ис-
точника и назначения. Кроме того, необходимое для выполнения миграции Live
Migration время зависит еще и от следующих переменных:
размер памяти виртуальной машины. Чем больше размер памяти виртуальной ма-
шины, тем больше времени займет процесс миграции;
уровень активности виртуальной машины. Чем выше активность виртуальной ма-
шины, тем выше частота модификаций страниц памяти. Это приводит к дополни-
тельным итерациям для создания согласованного состояния памяти на узле-
назначении;
нагрузка на узлы источника и назначения. Высокий уровень использования узлов
удлиняет время процесса миграции;
ширина полосы пропускания и пропускная способность сети. Высокоскоростная
сеть уменьшит время копирования информации страниц памяти и состояния вирту-
альной машины с узла-источника на узел-назначение;
конфигурация совместно используемой системы хранения. Передача номера LUN
от узла-источника к узлу-назначению также влияет на продолжительность мигра-
ции. Можно существенно снизить (и даже исключить) этот фактор при помощи но-
вой функции Cluster Shared Volumes (CSV) сервера Windows Server 2008 R2.
Если вы собираетесь использовать в вашей среде миграцию Live Migration и хотите
оптимизировать конфигурацию совместно используемой системы хранения, то вам
следует реализовать Cluster Shared Volumes. Эта функция снижает сложность вашей
конфигурации, а также время, требующееся для выполнения миграции Live Migration.
ВАЖНО
При миграции Live Migration любой узел кластера может быть либо источником, либо на-
значением только для одной миграции. То есть кластер из 16 узлов может одновременно
выполнять только восемь миграций виртуальных машин.
Совместно используемые тома кластера

Начиная с операционной системы Windows NT 4.0, продукты семейства Windows
Server предоставляли решение для обеспечения высокой готовности Failover Clustering,
но они позволяли только одному узлу кластера владеть номером LUN и осуществлять
доступ к сохраненным на нем данным. В Windows Server 2008 при переносе виртуаль-
ной машины на другой узел кластера Hyper-V при помощи функции Quick Migration,
выбираемое для выполнения миграции время отчасти зависит от быстроты передачи
владения номером LUN. Кроме того, для миграции (между узлами кластера Hyper-V
сервера Windows Server 2008) только одной виртуальной машины вы должны сохра-
нить виртуальную машину на устройстве LUN (если вы не реализуете более сложных

точек подключения).
Дополнительную информацию по точкам подключения см. во врезке "Информация из пер-
воисточника. Преодоление ограничения по количеству букв дисков при помощи точек
подключения" главы 5.
Для преодоления этих ограничений Windows Server 2008 R2 вводит совместно исполь-
зуемые тома кластера Cluster Shared Volumes (CSV). Эти тома реализуют и предостав-
ляют единообразное пространство имен файлов для всех узлов кластера и позволяют
нескольким узлам кластера одновременно получать доступ к LUN в совместно исполь-
зуемой системе хранения. Тома CSV создаются и хранятся как каталоги под корневым
каталогом с названием ClusterStorage. Это наименование по умолчанию для корневого
каталога, но вы можете его изменить. Например, вы можете подключить LUN к букве
S и при помощи CSV создать том для каждой виртуальной машины:
S:\ClusterStorage\Volume1\VM1;
S:\ClusterStorage\Volumen\VMn.
Для виртуальной машины том CSV выглядит так, как будто он хранится на своем соб-
ственном LUN. Однако все области хранения виртуальных машин находятся на одном
и том же LUN, и каждый узел кластера может получать доступ к томам при помощи
полностью заданного пути. Вот некоторые дополнительные преимущества CSV:
полная совместимость с NTFS;
реализация не требует переформатирования носителей системы хранения;
уменьшение количества букв дисков, используемых для хранения виртуальных ма-
шин;
поддержка устройств хранения SAN и iSCSI.
Функция CSV включается на уровне кластера при помощи Failover Cluster Manager.
Для ее поддержки вам не нужно больше никаких других специализированных инстру-
ментов управления.
В разд. "Использование Live Migration" далее в этой главе вы найдете пошаговую процеду-
ру, в которой описывается настройка использующего тома CSV кластера хостов Hyper-V и
запуск миграции (типа Live Migration) виртуальной машины из менеджера Failover Cluster
Manager.
Трансляция адресов второго уровня

Как было описано в главе 3, гипервизор Windows Hypervisor управляет двумя уровнями
преобразований адресного пространства (для работающих в виртуальных машинах
гостевых операционных систем). Первый уровень преобразования сопоставляет вирту-
альное адресное пространство гостевой операционной системы с ее физическим адрес-

ным пространством. Второй уровень преобразования сопоставляет физическое адрес-
ное пространство гостевой операционной системы с физическим адресным простран-
ством системы. Для этого гипервизор Windows поддерживает теневую таблицу страниц
Shadow Page Table, которая комбинирует два уровня преобразования адресного про-
странства в одной таблице страниц. В версии Hyper-V (V1) накладные расходы на под-
держание этой таблицы могли составлять до 10% процессорного времени и требовали
большого количества мегабайтов памяти для каждой виртуальной машины.
Версия Hyper-V R2 избавлена от необходимости поддерживать эту таблицу, т. к. в ней
используется реализованная в процессорах семейств AMD-V и Intel VT функция пре-
образования адресов второго уровня Second Level Address Translation (SLAT). В AMD-V
функция SLAT реализована через механизм вложенных таблиц страниц (Nested Page
Tables, NPT), называемых также быстрой индексацией виртуализации (Rapid
Virtualization Indexing, RVI). Технология SLAT в Intel VT называется расширенными
таблицами страниц (Extended Page Tables, EPT). При помощи NPT или EPT процессо-
ры AMD-V и Intel VT могут поддерживать и выполнять два уровня (требующихся для
каждой виртуальной машины) преобразований адресного пространства аппаратным
способом, что снижает сложность гипервизора Windows и количество переключений
контекста, необходимых для управления ошибками страниц виртуальных машин.
В результате исчезают накладные расходы процессора и памяти на обработку таблицы
Shadow Page Table, что позволяет версии Hyper-V R2 обеспечить более высокую мас-
штабируемость серверов Hyper-V. Эта технология дает определенные преимущества
тем серверам Hyper-V, на которых работает большое количество виртуальных машин
или таких рабочих нагрузок, которые очень часто модифицируют память.
Подробности по технологиям NPT и RVI семейства AMD-V см. во врезке "Информация
с места событий. Индексирование AMD-V (Rapid Virtualization Indexing)" главы 1.
Функция остановки ядра

Спецификация интерфейса Advanced Configuration and Power Interface (ACPI) опреде-
ляет состояния электропитания процессора (называемые также С-состояниями), в ко-
торые процессор или его ядра (для некоторых многоядерных процессоров) могут быть
переведены при простое. В зависимости от того С-состояния, в которое переходит со-
вместимое с ACPI процессорное ядро, оно может отключить некоторые свои компо-
ненты и приостановить выполнение команд (обеспечив таким образом снижение на-
пряжения на ядре и более низкое потребление энергии).
В Windows Server 2008 R2 реализована новая функция управления электропитанием
Core Parking, которая обеспечивает возможность перевести процессор в такие "глубо-
кие" С-состояния (состояния низкого энергопотребления), когда рабочая нагрузка сер-
вера обслуживается меньшим числом процессорных ядер (чем для нее выделено). По
умолчанию Core Parking работает со всеми ядрами процессора и не может применяться
к отдельным ядрам. Для того чтобы оптимизировать использование имеющихся про-
цессорных ядер, в версии Hyper-V (V1) рабочая нагрузка виртуальной машины плани-
руется. Введение функции Core Parking привело к модификации планировщика версии

Hyper-V R2 гипервизора Windows. В зависимости от указанных в политике энергопо-
требления сервера пороговых значений, ядро раздела управления (родительского раз-
дела) определяет набор тех процессорных ядер, которые необходимо остановить, и вы-
дает эту информацию гипервизору Windows версии Hyper-V R2. Когда гипервизор
планирует выполнение виртуальной машины, то он использует информацию по Core
Parking для того, чтобы по возможности избежать использования остановленных про-
цессоров. Если рабочая нагрузка требует дополнительных процессорных ядер, то про-
цессоры выводятся из С-состояния.
В большинстве ситуаций вам, скорее всего, не понадобится модифицировать политику
энергопотребления для настройки связанных с Core Parking параметров. Однако для про-
смотра и модификации настроек энергопотребления можно использовать настройки груп-
повых политик Active Directory или утилиту Powercfg.exe, которая поставляется вместе
с сервером Windows Server 2008 R2. Вы можете просмотреть процессорные параметры по
умолчанию в политике энергопотребления при помощи следующей команды:
powercfg /qh SCHEME_CURRENT SUB_PROCESSOR
Динамическое добавление и удаление

объемов хранения
В версии Hyper-V (V1) для добавления (или удаления) виртуальных жестких дисков
(или транзитных дисков) необходимо было выключить виртуальную машину. Версия
Hyper-V R2 поддерживает добавление и удаление виртуальных жестких дисков и тран-
зитных дисков на работающей виртуальной машине без необходимости ее перезагруз-
ки (если инсталлированы службы интеграции Integration Services и диски подключены
к виртуальным контроллерам SCSI).
Поддержка разгрузки ТСР

Функция TCP Offload в Hyper-V R2 позволяет виртуальной машине передать обработку
протокола TCP/IP на физические сетевые адаптеры (которые поддерживают эту функ-
цию). Несмотря на то, что такая возможность в Windows Server 2008 имеется, для вир-
туальных машин она не поддерживается. С расширением использования десятигига-
битных сетей Ethernet и существенным возрастанием процессорных издержек на обра-
ботку протокола TCP/IP в таких высокоскоростных сетях поддержка функции TCP
Offload на уровне виртуальных машин становится весьма важной. В большинстве слу-
чаев поддержка разгрузки ТСР в Hyper-V R2 снижает нагрузку на ядра процессора, что
высвобождает процессорное время и улучшает общую производительность сетевой
работы виртуальных машин.
Поддержка очередей виртуальных машин

Для снижения сложности и издержек доставки полученных (физическим сетевым
адаптером) сетевых пакетов в виртуальную машину Hyper-V R2 поддерживает также
очереди виртуальных машин Virtual Machine Queue (VMQ). На сетевом адаптере для
каждой виртуальной машины создается очередь виртуальной машины, причем каждой

виртуальной машине присваивается идентификатор VMQ. Когда поступает сетевой
пакет, для быстрой идентификации его целевой виртуальной машины используется
идентификатор VMQ. Затем сетевые пакеты напрямую копируются в память целевой
виртуальной машины, что дает существенное снижение процессорных издержек и уве-
личение производительности по сравнению с версией Hyper-V (V1).
Пакеты увеличенного размера

Аналогично функции TCP Offload, поддержка пакетов TCP/IP увеличенного размера в
Windows Server 2008 ограничена только физическими сетевыми адаптерами. В версии
же Hyper-V R2 поддержка пакетов увеличенного размера расширена и на виртуальные
сетевые адаптеры. Пакет увеличенного размера — это такой пакет Ethernet, полезные
данные которого могут иметь размер до 9000 байтов (в отличие от стандартных
1500 байтов). Использование таких пакетов снижает издержки передачи данных по
сети. В результате достигается повышение производительности (вследствие сущест-
венного снижения процессорных издержек на обработку протокола TCP/IP).
В версии Hyper-V R2 пакеты увеличенного размера поддерживаются на синтетических се-
тевых адаптерах при ведении обмена виртуальных машин с физическими устройствами, а
также для внутренних или частных сетей при ведении обмена между виртуальными маши-
нами.
Настройка диапазона МАС-адресов

Версия Hyper-V (V1) при инсталляции автоматически создает пул МАС-адресов для
присваивания виртуальным сетевым адаптерам. Однако в менеджере Hyper-V Manager
нет возможности модифицировать пул МАС-адресов. Если вам нужно модифициро-
вать пул МАС-адресов, то вы должны отредактировать реестр.
В версии Hyper-V R2 вы можете редактировать пул МАС-адресов при помощи Virtual
Network Manager. Для управления пулом МАС-адресов откройте менеджер Virtual
Network Manager в консоли Hyper-V Manager и выберите опцию MAC Address Range
в разделе Global Network Settings. Это позволит вам модифицировать конфигурацию
пула МАС-адресов на сервере Hyper-V.
По умолчанию только 256 виртуальным сетевым адаптерам может быть одновременно
присвоен динамический МАС-адрес. Если вам требуется более 256 одновременных
динамических МАС-адресов на сервере Hyper-V или вам нужно модифицировать пул
МАС-адресов (во избежание дублирования МАС-адресов), то вы можете использовать
эту возможность для внесения необходимых изменений (не прибегая к более риско-
ванным манипуляциям с реестром).
Изменение пула МАС-адресов не влияет на конфигурацию уже существующих виртуальных
сетевых адаптеров.
Подмена МАС-адресов
В Windows Server 2008 R2 Hyper-V и Hyper-V Server 2008 R2 в настройках виртуального се-
тевого адаптера есть новая опция Enable Spoofing Of MAC Addresses (для включения
подмены МАС-адресов). Если вы не включите подмену МАС-адресов, то выполняются сле-
дующие правила:
• порт виртуального коммутатора, к которому подключен виртуальный сетевой адаптер,
посылает и принимает пакеты с любыми допустимыми МАС-адресами;
• МАС-адрес виртуального сетевого адаптера не может быть перемещен или связан
с другим портом виртуального коммутатора;
• порт виртуального коммутатора не пересылает однонаправленных лавинных пакетов
(которые направляются во все порты коммутатора при отсутствии в таблице коммута-
тора МАС-адреса назначения) виртуальному сетевому адаптеру;
• вы не можете изменить МАС-адрес виртуального сетевого адаптера при помощи ключа
NetworkAddress в реестре виртуальной машины.
Кейт Мэйнг (Keith Mange, Software Design Engineer (Windows Virtualization))
Конфигурация виртуального сетевого адаптера (в том числе ключ NetworkAddress, содер-
жащий значение МАС-адреса) находится в ключе HKEY_LOCAL_MACHINE\System
\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}. Каждое число
из четырех цифр (0000, 0001 и т. д.) в поддереве этого ключа представляет собой отдель-
ный сетевой адаптер (который вы можете легко идентифицировать по его значению
DriverDesc).
Если вы включите подмену МАС-адресов, то можно будет узнать МАС-адреса на других
портах и будут разрешены следующие действия:
• порт виртуального коммутатора (к которому подключен виртуальный сетевой адаптер)
может посылать и принимать пакеты с любыми МАС-адресами;
• порт виртуального коммутатора динамически узнает новые МАС-адреса и виртуальный
коммутатор может добавлять их в свою таблицу пересылки;
• порт виртуального коммутатора будет получать и пересылать однонаправленные ла-
винные пакеты виртуальному сетевому адаптеру;
• вы можете изменить МАС-адрес виртуального сетевого адаптера при помощи ключа
NetworkAddress в реестре виртуальной машины.
Если вы переведете виртуальный сетевой адаптер в "неразборчивый" (promiscuous) режим
и включите подмену МАС-адресов, то виртуальный сетевой адаптер сможет получать
однонаправленные лавинные пакеты.
Работа моментальных снимков виртуальных машин

В версии Hyper-V R2 имеется новая операция Allow Virtual Machine Snapshot, которую
можно использовать для более точного делегирования права на создание моменталь-
ных снимков виртуальных машин при помощи политики Authorization Manager. В вер-
сии Hyper-V (V1) для предоставления разрешения на создание моментальных снимков
виртуальных машин требуется также разрешение на остановку и запуск виртуальной
машины, а это две таких операции, которые не всегда желательно делегировать совме-
стно с более безобидной операцией создания снимков виртуальных машин.
Новые каталоги по умолчанию сервера Hyper-V

При инсталляции версия Hyper-V R2 создает два новых каталога по умолчанию (для
хранения файлов виртуальных машин). Вот эти каталоги:
%SystemDrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots Cache;
%SystemDrive%\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines Cache.
Версия Hyper-V R2 использует эти каталоги для хранения XML-файлов, которые со-
держат глобально уникальные идентификаторы (GUID) и названия виртуальных ма-
шин. Это позволяет версии Hyper-V R2 разрешать и отображать названия виртуальных
машин (а не только GUID) даже в том случае, если место хранения виртуальной маши-
ны находится в автономном режиме или если нет доступа к конфигурационному файлу
В отличие от Hyper-V (V1), в версии Hyper-V R2 по умолчанию дисковод для гибких дисков
не создается.
Использование Live Migration

Миграция Live Migration позволяет вам реализовать решение высокой готовности для
критичных виртуальных машин без применения осведомленных о кластеризации гос-
тевых операционных систем или приложений, а также позволяет приложениям управ-
ления в масштабе предприятия (таким, как SCVMM R2) обеспечить динамическую ба-
лансировку нагрузки виртуальных машин без прерывания их работы.
В этом разделе вы научитесь конфигурировать кластер Hyper-V из двух узлов
(рис. 9.10) таким образом, чтобы он поддерживал миграцию Live Migration. Кластер
Hyper-V будет использовать устройство хранения на базе протокола iSCSI (такое, как
устройство Windows Storage Server) с совместно используемыми томами кластера
Cluster Shared Volumes. При использовании iSCSI на каждом сервере Hyper-V для дос-
тупа к системе хранения вы должны выделить физический сетевой адаптер. На каждом
узле кластера Hyper-V требуется iSCSI-инициатор (для доступа к iSCSI-целям на со-
вместно используемой системе хранения).
iSCSI-инициатор — это программный компонент, который позволяет подключить хост
Windows к внешнему массиву хранения (на базе протокола iSCSI) по сети TCP/IP.
После конфигурирования кластера Hyper-V, томов Cluster Shared Volumes и виртуаль-

ных машин для поддержки миграции Live Migration вы узнаете о том, как иницииро-
вать миграцию типа Live Migration виртуальной машины (при помощи менеджера
Failover Cluster Manager).
Создание кластера из двух хостов Hyper-V

Приведенная в этом разделе процедура предполагает, что вы инсталлировали сервер
Windows Server 2008 R2 на обоих физических серверах, а также инсталлировали и роль
Рис. 9.10. Кластер Hyper-V с совместно используемой системой хранения на базе iSCSI
и томами Cluster Shared Volumes
Hyper-V (при помощи описанных в разд. "Инсталляция роли Hyper-V на сервере

Windows Server 2008 R2" ранее в этой главе шагов). Для создания кластера из двух хос-
тов Hyper-V с использованием совместного устройства хранения на базе протокола
iSCSI вы должны выполнить следующие основные шаги:
сконфигурировать диск-свидетель на каждом сервере Hyper-V (при помощи iSCSI-
инициатора);
добавить опцию Failover Clustering на каждом сервере Hyper-V;
сконфигурировать опцию Failover Clustering на каждом сервере Hyper-V;
проверить конфигурацию кластера и создать кластер.
Конфигурирование
совместно используемых дисков iSCSI
Перед тем как приступить к предложенной далее процедуре, вы должны согласовать
создание целевых и дисковых устройств iSCSI с работниками вашей команды управле-
ния системами хранения. Они должны создать на системе хранения iSCSI диск-
свидетель (размером не менее 600 Мбайт) и диск для хранения виртуальных машин, а
также предоставить обоим серверам Hyper-V доступ к этой iSCSI-цели. После создания
iSCSI-цели для конфигурирования диска-свидетеля на серверах Hyper-V выполните
1. Зарегистрируйтесь на первом сервере Hyper-V под учетной записью с правами
администратора домена.
2. Нажмите кнопку Start, выберите Administrative Tools | iSCSI Initiator.

3. Нажмите кнопку Yes в диалоговом окне Microsoft iSCSI, чтобы запустить службу
Microsoft iSCSI.
4. В диалоговом окне iSCSI Initiator Properties перейдите на вкладку Discovery, а за-
тем в разделе Target Portals щелкните по Discover Portal.
5. Введите название или IP-адрес того сервера, где определено целевое iSCSI-
устройство, а затем нажмите кнопку OK.
6. Перейдите на вкладку Targets для отображения списка обнаруженных целей. Для
обновления списка вам может понадобиться нажать кнопку Refresh.
7. Выберите соответствующее название цели и нажмите кнопку Connect.
8. Убедитесь в том, что установлен флажок Add this connection to the list of favorite
targets. Это позволяет серверу Hyper-V автоматически восстановить подключение
к iSCSI-цели после рестарта компьютера. Вам может также понадобиться устано-
вить флажок Enable multipath (если у вас инсталлировано соответствующее про-
граммное обеспечение).
9. Нажмите кнопку OK для подключения к iSCSI-цели.
10. Нажмите кнопку OK для того, чтобы закрыть диалоговое окно iSCSI Initiator
Properties.
11. Откройте менеджер Server Manager, разверните в левой панели Storage и выберите
Disk Management.
12. В нижней панели Disk Management щелкните (в левой панели) правой кнопкой
мыши по диску-свидетелю (размером 600 Мбайт) и выберите пункт Online в кон-
текстном меню.
13. Щелкните еще раз правой кнопкой мыши по диску-свидетелю (в левой панели)
и выберите пункт Initialize Disk в контекстном меню.
15. Щелкните еще раз правой кнопкой мыши по диску-свидетелю (в правой панели)
и выберите пункт New Simple Volume в контекстном меню.
16. На начальной странице мастера New Simple Volume Wizard нажмите кнопку Next.
18. На странице Assign Drive Letter Or Path выберите в раскрывающемся списке
Assign the following drive letter букву диска (например, W), а затем нажмите кноп-
ку Next.
settings, введите название (например, Witness) в текстовом поле Volume Label,
21. Повторите шаги 1—11 для второго сервера Hyper-V.

22. В консоли Disk Management щелкните правой кнопкой мыши по диску Witness
(в левой панели) и выберите пункт Online в контекстном меню.
23. Щелкните еще раз правой кнопкой мыши по диску Witness (в правой панели) и вы-
берите пункт Change Drive Letter And Paths в контекстном меню.
24. В диалоговом окне Change Drive Letter And Paths For нажмите кнопку Change.
25. В диалоговом окне Change Drive Letter Or Path выберите в раскрывающемся
списке Assign the following drive letter ту же самую букву диска (в данном приме-
ре это W), которая была использована для первого узла кластера, а затем нажмите
кнопку OK.
Добавление опции Failover Clustering Feature на сервер Hyper-V

Перед созданием кластера необходимо на каждый сервер Hyper-V добавить опцию
Failover Clustering Feature. Для этого на каждом сервере Hyper-V необходимо выпол-
нить следующие шаги:
1. На первом сервере Hyper-V откройте менеджер Server Manager и щелкните по узлу
Features в левой панели.
2. В правой панели нажмите кнопку Add Features, чтобы запустить мастер Add
Features Wizard.
3. На странице Select Features выберите Failover Clustering, а затем нажмите кнопку
Next.
6. Повторите шаги 1—5 на втором сервере Hyper-V.
Конфигурирование Failover Clustering на серверах Hyper-V

Когда вы создаете первый узел кластера, то указываете все параметры, которые опре-
деляют конфигурацию кластера. Мастер Cluster Configuration Wizard дает вам указания
по инсталляции и выполняет настройку кластера после ввода вами всей необходимой
информации.
Для настройки отказоустойчивой кластеризации Failover Clustering на первом узле кла-
стера Hyper-V выполните следующие шаги:
1. Нажмите кнопку Start, выберите Administrative Tools | Failover Cluster Manager.
2. В панели Management выберите Validate A Configuration, чтобы запустить мастер
Validate A Configuration Wizard.
4. На странице Select Servers Or A Cluster введите названия всех серверов Hyper-V
в текстовом поле Enter Name и нажмите кнопку Add. После выполнения всех этих
действий нажмите кнопку Next.
6. На странице Confirmation просмотрите список тестов и убедитесь в том, что оши-
бок не было, после чего нажмите кнопку Next.
7. Исправьте все обнаруженные в процессе проверки ошибки, а затем повторно про-
верьте конфигурацию.
9. В панели Management выберите Create A Cluster (для запуска мастера Create
Cluster Wizard).
11. На странице Select Servers введите названия всех серверов Hyper-V в текстовом
поле Enter Server Name, а затем нажмите кнопку Add. После выполнения этих
действий нажмите кнопку Next.
12. На странице Validation Warning выберите соответствующий вариант, после чего
ра (в текстовом поле Cluster Name). Вам может понадобиться также ввести
IP-адреса для каждой сконфигурированной сети. После выполнения этих действий
14. На странице Confirmation просмотрите информацию кластера, а затем нажмите
кнопку Next.
После завершения всех этих действий все серверы Hyper-V становятся узлами отказо-
устойчивого кластера. Для быстрой проверки работы отказоустойчивого кластера вы
можете завершить работу первого узла кластера Hyper-V. Когда вы откроете Failover
Cluster Management на втором узле кластера, то увидите, что он владеет всеми ресурса-
ми кластера.
Конфигурирование
совместно используемых томов кластера
Перед конфигурированием виртуальной машины для миграции типа Live Migration вы
должны включить для кластера Hyper-V опцию Cluster Shared Volumes. Для этого при
помощи менеджера Failover Cluster Manager необходимо выполнить следующие шаги:
1. На первом узле кластера Hyper-V откройте менеджер Failover Cluster Manager,
щелкните правой кнопкой мыши на названии кластера (в левой панели), а затем вы-
берите Enable Cluster Shared Volumes.
2. В диалоговом окне Enable Shared Volumes установите флажок I accept these terms
and restrictions, а затем нажмите кнопку OK.
3. Откройте Server Manager, разверните в левой панели Storage и выберите Disk
Management.
4. В нижней панели Disk Management щелкните правой кнопкой мыши на диске для
хранения виртуальных машин (в левой панели) и выберите пункт Online контекст-
ного меню.
5. Щелкните по этому диску правой кнопкой мыши еще раз (в левой панели) и выбе-
рите пункт Initialize Disk контекстного меню.
7. Щелкните по этому диску правой кнопкой мыши еще раз (в правой панели) и вы-
берите пункт New Simple Volume контекстного меню.
8. На начальной странице New Simple Volume Wizard нажмите кнопку Next.
10. На странице Assign Drive Letter Or Path в раскрывающемся списке Assign the
following drive letter выберите букву диска S, а затем нажмите кнопку Next.
11. На странице Format Partition выберите Format This volume with the following
settings, введите VMs в текстовом поле Volume Label, а затем нажмите кнопку Next.
13. В менеджере Failover Cluster Manager разверните в левой панели узел кластера,
щелкните правой кнопкой мыши по Storage и выберите пункт Add Disk.
14. В диалоговом окне Add Disks To A Cluster установите флажок рядом с соответст-
вующим диском, а затем нажмите кнопку OK. После добавления диска вы увидите
его в списке Summary Of Storage.
15. В левой панели щелкните правой кнопкой мыши по Cluster Shared Volumes и вы-
берите пункт Add Storage.
16. В диалоговом окне Add Storage установите флажок рядом с соответствующим
диском, а затем нажмите кнопку OK.
Если вы откроете Windows Explorer, то увидите, что на всех узлах кластера хостов
Hyper-V в %SystemRoot%\ClusterStorage появился новый том Cluster Shared Volume.
В %Systemroot%\ClusterStorage появляется каталог для всех томов того диска (или дисков),
который вы добавили в Cluster Shared Volumes. Список томов вы можете просмотреть
в менеджере Failover Cluster Manager.
Создание новой виртуальной машины

После конфигурирования кластера хостов Hyper-V и до создания новой виртуальной
машины высокой готовности вам следует сконфигурировать и подключить на каждом
узле кластера Hyper-V одинаково названные внешние виртуальные сети. После этого
следующим шагом можно будет создать виртуальную машину на одном из узлов кла-
стера Hyper-V.
1. На первом узле кластера Hyper-V откройте консоль Hyper-V Manager.

2. В панели Actions под названием сервера щелкните по пункту New и выберите
пункт Virtual Machine в меню (для запуска мастера New Virtual Machine Wizard).
4. На странице Specify Name And Location введите название новой виртуальной ма-
шины. Затем выберите Store the virtual machine in a different location и нажмите
кнопку Browse, чтобы использовать Windows Explorer для выбора Volume1
в %SystemRoot%\ClusterStorage. После выполнения этих действий нажмите кнопку
Next.
5. На странице Assign Memory укажите выделение памяти для виртуальной машины,
6. На странице Configure Networking выберите внешнюю виртуальную сеть, создан-
ную для не связанного с кластеризацией сетевого трафика.
7. На странице Connect Virtual Hard Disk выберите Create A Virtual Hard Disk и
введите информацию Name, Location и Size для новой виртуальной машины. По-
сле выполнения этих действий нажмите кнопку Next.
8. На странице Installation Options выберите соответствующий метод для инсталля-
ции гостевой операционной системы в виртуальной машине, а затем нажмите
кнопку Next.
9. На странице Completing The New Virtual Machine Wizard нажмите кнопку Finish.
10. Инсталлируйте в новую виртуальную машину гостевую операционную систему и
приложения.
Превращаем виртуальную машину

Для конфигурирования виртуальной машины высокой готовности выполните следую-
щие шаги:
1. На первом узле Hyper-V откройте консоль Hyper-V Manager и выключите виртуаль-
ную машину.
2. Закройте Hyper-V Manager и откройте консоль Failover Cluster Manager.
3. В левой панели щелкните правой кнопкой мыши на пункте Services And
Applications (под названием кластера) и выберите пункт Configure A Service Or
Application меню (для запуска мастера High-Availability Wizard).
5. На странице Select Service Or Application выберите Virtual Machine в списке
опций.
6. На странице Select Virtual Machine выберите соответствующую виртуальную ма-
шину, а затем нажмите кнопку Next.
7. На странице Confirmation проверьте информацию и нажмите кнопку Next.
8. На странице Summary просмотрите отчет и щелкните Summary.

9. После выполнения этих действий откройте менеджер Hyper-V Manager и выберите
Start под названием виртуальной машины (для перевода ее в оперативный режим).
Конфигурирование кластерных сетей

для миграции Live Migration
Последний (необязательный) шаг перед инициализацией миграции Live Migration вир-
туальной машины — это конфигурирование и определение приоритетов кластерных
сетей. Для настройки конфигурации кластерных сетей под миграцию типа Live
Migration выполните следующие шаги:
1. На первом узле Hyper-V откройте менеджер Failover Cluster Manager, а затем выбе-
рите в левой панели название кластера.
2. Разверните узел Services And Applications и выберите в левой панели виртуальную
машину.
3. В центральной панели (под сводкой виртуальной машины) щелкните правой кноп-
кой мыши по ресурсу виртуальной машины, а затем выберите пункт Properties.
4. Перейдите на вкладку Network For Live Migration и выберите одну (или более) се-
тей кластера для миграции Live Migration. Вы можете также перемещать сети вверх
и вниз по списку, чтобы определить предпочтительную сеть.
5. После выполнения ваших настроек нажмите кнопку OK.
Миграция Live Migration будет использовать сети кластера в указанном в списке по-
рядке. Если подключение к узлу кластера по первой сети выходит из строя, то исполь-
зуется следующая по списку сеть (и так до тех пор, пока список не закончится или не
будет достигнуто успешное подключение через одну из имеющихся в списке сетей).
Инициирование миграции Live Migration

Для инициирования миграции типа Live Migration виртуальной машины при помощи
менеджера Failover Cluster Manager выполните следующие шаги:
1. На первом узле Hyper-V откройте менеджер Failover Cluster Manager.
2. Разверните узел Services And Applications и выберите в левой панели виртуальную
машину.
3. Щелкните правой кнопкой мыши на виртуальной машине, выберите Live Migrate
Virtual Machine To Another Node, а затем выберите второй узел кластера.
4. После завершения миграции Live Migration виртуальная машина работает на втором
узле кластера.
Управление Hyper-V R2
Сервером Windows Server 2008 R2 Hyper-V можно управлять либо локально, либо уда-
ленно с другого сервера Windows Server 2008 R2 (при помощи консоли Hyper-V
Manager). Поскольку Hyper-V Server 2008 R2 не предоставляет графического интер-

фейса пользователя, им нужно управлять удаленно.
Менеджер System Center Virtual Machine Manager 2008 не поддерживает Windows Server
2008 R2 Hyper-V или Hyper-V Server 2008 R2. Однако следующая версия (System Center
Virtual Machine Manager 2008 R2) будет полностью поддерживать как Hyper-V R2, так и
Hyper-V (V1).
Другой вариант управления серверами Windows Server 2008 R2 Hyper-V и Hyper-V

Server 2008 R2 — это использование пакета инструментов Remote Server Administration
Tools (RSAT) для Windows 7. Вы можете инсталлировать RSAT на Windows 7 как вер-
сии х86, так и версии х64. В состав инструментов RSAT для Windows 7 входят (в том
числе) и Hyper-V Manager, и Failover Cluster Manager.
Вы можете скачать пакет RSAT для Windows 7 с Web-сайта Microsoft по ссылке:
http://www.microsoft.com/downloads/details.aspx?FamilyID=82516c35-c7dc-4652-b2ea-
2df99ea83dbb.
После скачивания и инсталляции пакета RSAT для Windows 7 вы можете задейство-

вать либо все имеющиеся инструменты, либо только их часть (при помощи приложе-
ния Windows Features панели управления); вы можете также получать к ним доступ
через Administrative Tools.
Резюме
Серверы Windows Server 2008 R2 Hyper-V и Hyper-V Server 2008 R2 предоставляют
новые важные функции, в том числе: Live Migration, Cluster Shared Volumes, Second
Level Address Translation и Core Parking; а также (связанные с виртуальными жесткими
дисками и виртуальными сетями) функции и улучшения, повышающие производитель-
ность Hyper-V R2. Для быстрого начала работы с Hyper-V R2 вам следует начать с
полной инсталляции Windows Server 2008 R2 и добавления роли Hyper-V (при помощи
Server Manager). Для тестирования миграции Live Migration используйте предоставлен-
ные вам процедуры для: создания кластера Hyper-V из двух узлов, конфигурирования
томов Cluster Shared Volumes, определения новой виртуальной машины, настройки ее
высокой готовности и инициирования Live Migration. Кроме того, убедитесь, что вы
понимаете имеющиеся возможности управления сервером Hyper-V R2 при помощи
Windows Server 2008 R2 и Windows 7.

документ Microsoft "Windows Server 2008 R2 Reviewers Guide", доступный по ссыл-
ке: http://www.microsoft.com/windowsserver2008/en/us/R2-Beta.aspx;
документ Microsoft "Microsoft Hyper-V Server 2008 R2 (Beta) Overview", доступный

по ссылке:
http://www.microsoft.com/downloads/details.aspx?familyid=F81A38D2-A152-4DDE-
96E6-2AA184FDF9B7;
документ Microsoft "Microsoft Hyper-V Server 2008 R2 (Beta) Setup and Configuration
Tool Guide", доступный по ссылке:
http://www.microsoft.com/downloads/details.aspx?familyid=5C88B04D-2896-4FA4-
9E59-7BC4442FF333;
документ Microsoft "Windows Server 2008 R2 Hyper-V Live Migration", доступный по
ссылке:
http://www.microsoft.com/downloads/details.aspx?FamilyID=fdd083c6-3fc7-470b-
8569-7e6a19fb0fdf&displaylang=en;
Web-сайт Microsoft Technet, руководство "Hyper-V: Step-by-Step Guide to Using Live
Migration in Windows Server 2008 R2", доступное по ссылке:
http://technet.microsoft.com/en-us/library/dd446679.aspx.
часть III
Управление инфраструктурой
Глава 10. Обзор управления сервером Hyper-V
Глава 11. Управление одним сервером Hyper-V
Глава 12. Управление фермой серверов
Глава 13. Резервное копирование и восстановление сервера Hyper-V
Глава 14. Миграция серверов при помощи менеджера

System Center Virtual Machine Manager
Глава 15. Наблюдение за сервером при помощи пакета управления

Windows Server 2008 Hyper-V Management Pack
для менеджера System Center Operations Manager 2007
Глава 16. Управление сервером Hyper-V при помощи

Windows PowerShell
ГЛАВА 10
Обзор управления
сервером Hyper-V
Данная часть посвящена управлению конфигурациями одного или нескольких серверов
Hyper-V. Эта глава дает обзор продуктов и технологий, которые можно сочетать для
полноценного решения задач управления сервером Hyper-V и виртуальными машина-
ми. Продукты разбиты на три группы: решения по управлению, решения по устране-
нию последствий катастроф, решения по наблюдению.
Решения по управлению — это такие продукты или инструменты, которые позволяют
вам управлять конфигурацией сервера Hyper-V или работающих на нем виртуальных
машин. Раздел, в котором излагаются решения по преодолению последствий катаст-
роф, описывает такие продукты или инструменты, которые позволяют вам делать ре-
зервные копии и восстанавливать из них конфигурацию сервера Hyper-V, родитель-
ский раздел и виртуальные машины. Решения по наблюдению включают в себя такие
продукты или инструменты, которые позволяют вам отслеживать состояние сервера
Hyper-V, работающих виртуальных машин и выполняющихся в них приложений.
Главы в данной части описывают подробности использования этих продуктов и инст-
рументов:
глава 11 объясняет, как поставляющиеся вместе с серверами Microsoft Hyper-V
Server и Windows Server 2008 инструменты можно использовать для управления од-
ним сервером Hyper-V;
глава 12 объясняет, как можно использовать менеджер System Center Virtual
Machine Manager 2008 для управления фермой серверов Hyper-V;
глава 13 объясняет, как в качестве решений по преодолению последствий катастроф
используются Microsoft Server Backup и менеджер System Center Data Protection
Manager 2007 SP1;
глава 14 объясняет, как выполнять миграцию физических и виртуальных серверов
на виртуальные серверы;
глава 15 объясняет, как настроить и использовать менеджер System Center
Operations Manager 2007 для наблюдения за сервером Hyper-V и работающими на
нем виртуальными машинами;
372 Часть III. Управление инфраструктурой Windows Server 2008 Hyper-V
глава 16 объясняет, как использовать Windows PowerShell и интерфейс WMI серве-

ра Hyper-V для управления сервером Hyper-V и виртуальными машинами.
Решения по управлению
Решения по управлению компании Microsoft позволяют вам управлять отдельным сер-
вером, конфигурацией из нескольких серверов, а также кластерной конфигурацией.
Менеджер Hyper-V Manager — это бесплатный инструмент, который позволяет вам
управлять одновременно только одним сервером Hyper-V. Менеджер Hyper-V Manager
можно инсталлировать на любую версию Windows Server 2008 с графическим интер-
фейсом пользователя, а также как часть пакета инструментов Remote Server
Administration Tools (RSAT) для Vista. Менеджер System Center Virtual Machine
Manager позволяет вам управлять из одной консоли целой фермой серверов Hyper-V.
Приложение Failover Cluster Manager для MMC — это бесплатный инструмент для
управления отказоустойчивыми кластерами, имеющийся в версиях Windows Server
2008 Enterprise и Datacenter.
В следующем разделе дано описание каждого инструмента и его использования для
управления сервером Hyper-V, фермой серверов Hyper-V, а также кластером серверов
Hyper-V.
Менеджер Hyper-V Manager для ММС

Менеджер Hyper-V Manager для ММС — это консоль ММС, предоставляющая графи-
ческий интерфейс для управления сервером Hyper-V. Менеджер Hyper-V Manager ав-
томатически инсталлируется при активировании роли Hyper-V на полной инсталляции
Windows Server 2008. На инсталляции типа Server Core сервера Windows Server 2008 и
на сервере Microsoft Hyper-V Server 2008 менеджер Hyper-V Manager не инсталлирует-
ся (поскольку они не имеют графического интерфейса пользователя). Для этих двух
конфигураций сервера Hyper-V необходимо использовать менеджер Hyper-V Manager с
другого компьютера. Это может быть либо компьютер с полной инсталляцией сервера
Windows Server 2008 (имеющий графический интерфейс пользователя для работы
ММС), либо компьютер под управлением Windows Vista SP1 (на котором вы инстал-
лировали пакет инструментов Remote Server Administration Tools (RSAT)). Вне зависи-
мости от того, где и как вы инсталлировали Hyper-V Manager для ММС, вы можете
использовать его для удаленного управления сервером Hyper-V.
Сервер Windows Server 2008 R2 и пакет RSAT для Windows 7 можно скачать в виде бета-
версии с сайта Microsoft Downloads по ссылке: http://www.microsoft.com/downloads.
Консоль ММС для Hyper-V позволяет вам управлять конфигурацией сервера Hyper-V,
конфигурацией зарегистрированных на нем виртуальных машин, а также состоянием
зарегистрированных виртуальных машин. Несмотря на то, что Hyper-V Manager для
ММС может подключаться к нескольким серверам Hyper-V, одновременно вы можете
управлять только одним из них.
Глава 10. Обзор управления сервером Hyper-V 373
По умолчанию Hyper-V Manager для ММС предоставляет членам группы локальных

администраторов полный контроль над хостом и зарегистрированными на сервере вир-
туальными машинами. Это позволяет администратору управлять такими вещами, как:
место хранения по умолчанию для виртуальных машин; сокращенные клавиатурные
комбинации; учетные данные пользователей; регистрация виртуальных машин; а также
конфигурация виртуальных машин. Когда виртуальные машины зарегистрированы на
сервере Hyper-V, то менеджер Hyper-V Manager для ММС позволяет администратору
управлять процессором, сетью, памятью, состоянием и работой всех виртуальных
машин.
Несмотря на то, что полные права по умолчанию имеют члены группы локальных ад-
министраторов, для управления сервером и зарегистрированными виртуальными ма-
шинами Hyper-V локальным администратором быть не требуется. Hyper-V использует
Authorization Manager (AZMAN) для того, чтобы обеспечивать безопасность на основе
ролей. Менеджер Authorization Manager позволяет вам определять роли, присваивать
этим ролям выполняемые ими операции, а также ограничивать те объекты, которыми
может управлять данная роль. Hyper-V предоставляет набор предопределенных опера-
ций, роль администратора, а также область действия по умолчанию (сервер Hyper-V и
Рис. 10.1. Менеджер Hyper-V Manager для ММС

все его виртуальные машины). Если вам нужно более детальное управление безопас-
ностью, то вы можете либо определить новую роль (с ограниченным набором опера-
ций), либо новую область действия (содержащую только определенную группу вирту-
альных машин). Вы можете присвоить эту роль пользователям или группам (как ло-
кальным, так и доменным).
Более подробное описание AZMAN см. в главе 6.
Менеджер Hyper-V Manager позволяет вам регистрировать и создавать конфигурации

виртуальных машин (а также управлять ими), но он зависит от другого инструмента —
VMConnect.exe, который обеспечивает удаленный доступ к виртуальной машине (ви-
део, клавиатура, мышь). Для удаленного подключения к виртуальной машине
VMConnect использует протокол Remote Desktop Protocol (RDP).
На рис. 10.1 показан интерфейс менеджера Hyper-V Manager для ММС. Он выглядит
как стандартная консоль управления компании Microsoft. Вертикальная панель слева
показывает те серверы Hyper-V, которыми вы управляете; центральные панели позво-
ляют вам выбрать виртуальную машину для управления; в нем также приведены под-
робности по состоянию выбранной виртуальной машины, по имеющимся моменталь-
ным снимкам, а также миниатюрное изображение видеобуфера виртуальной машины.
В правой панели имеется меню действий для управляемого в данный момент сервера
Hyper-V и для текущей выбранной виртуальной машины. Панель действий имеет чув-
ствительность к контексту и отображает только те действия, которые доступны в зави-
симости от сделанного в центральной панели выбора.
Менеджер Failover Cluster Manager

В какой-то момент развертывания виртуализации серверов вы захотите обеспечить вы-
сокую готовность серверов Hyper-V и работающих на них виртуальных машин. Для
обеспечения высокой готовности Hyper-V использует опцию Failover Clustering сер-
вера Windows Server 2008. Эта опция сервера Windows Server 2008 инсталлируется от-
дельно.
Функция Failover Clustering управляется при помощи менеджера Failover Cluster
Manager для MMC, который устанавливается автоматически во время инсталляции
функции Failover Clustering, а также может инсталлироваться вручную как администра-
тивный инструмент в составе пакета RSAT. На рис. 10.2 показан вид по умолчанию
консоли Failover Cluster Manager для MMC.
Failover Cluster Manager позволяет создавать кластеры хостов Hyper-V и виртуальных
машин, а также управлять ими. Кластер хостов — это кластер серверов Hyper-V (до
16 штук), на котором работают виртуальные машины высокой готовности. Ни вирту-
альные машины, ни приложения этих виртуальных машин не обязаны быть осведом-
ленными о кластеризации. Кластер виртуальных машин — это кластер из виртуальных
машин (до 16 штук), на котором работает осведомленное о кластеризации приложение.
Каждый узел кластера виртуальных машин должен работать на отдельном сервере
Hyper-V (для достижения высокой готовности).
Рис. 10.2. Менеджер Failover Cluster Manager для MMC
Построение кластера состоит из шести шагов. Первый шаг — это сборка оборудования
и подключение совместно используемых систем хранения. Второй шаг — инсталляция
на каждом узле кластера сервера Windows Server 2008 и активация роли Hyper-V. Шаг
третий — инсталляция опции Failover Clustering. Шаг четвертый — использование
Failover Cluster Manager для проверки конфигурации кластера. Шаг пятый — использо-
вание Failover Cluster Manager для создания кластера. Шаг шестой — использование
Failover Cluster Manager для управления кластером и его ресурсами.
Для обеспечения высокой готовности виртуальной машины вы сначала должны соз-
дать кластер хостов Hyper-V (с совместно используемой системой хранения). После
создания кластера вы можете создать (на совместно используемой системе хранения)
виртуальную машину. После создания виртуальной машины ее можно превратить в
машину высокой готовности при помощи опции Configure A Service Or Application
менеджера Failover Cluster Manager (выбрав в качестве типа приложения Virtual
Machine). Выберите ту виртуальную машину, которую вы хотите превратить в машину
высокой готовности, и ресурсы будут добавлены в качестве управляемых кластером
ресурсов. После добавления всех ресурсов виртуальная машина станет видна как при-
ложение высокой готовности. Последний шаг — нужно щелкнуть по этому приложе-
нию правой кнопкой мыши и перевести его в оперативный режим. Когда оно перейдет
в оперативный режим, виртуальная машина высокой готовности станет управляемым
кластерным ресурсом, при этом любой сбой сервера Hyper-V приведет к перезапуску
виртуальной машины на другом узле кластера.
Менеджер System Center Virtual Machine Manager 2008

В то время как Hyper-V Manager предназначен для управления одновременно только
одним сервером Hyper-V, менеджер System Center Virtual Machine Manager 2008
(SCVMM) предназначен для управления целым пулом серверов Hyper-V из одной кон-
соли. SCVMM состоит из множества компонентов, которые обеспечивают его единый
консольный интерфейс. Эти компоненты могут быть инсталлированы на одном сервере
или распределены по нескольким серверам (в зависимости от нагрузки и требований).
Компоненты SCVMM включают:
сервер Virtual Machine Manager (VMM);
библиотеку Virtual Machine Manager Library;
консоль Virtual Machine Manager Administrator Console;
портал Virtual Machine Manager Self-Service Portal;
базу данных Virtual Machine Manager;
агента Virtual Machine Manager Agent.
Сервер Virtual Machine Manager

Сервер Virtual Machine Manager — это центральное ядро управления в SCVMM. Он
предоставляет команды, их обработку, возможность передачи файлов, а также управ-
ляет обменом между прочими компонентами VMM. Он также ведет обмен со всеми
хостами виртуальных машин и серверами библиотек VMM Library (через инсталлиро-
ванный агент VMM).
Библиотека Virtual Machine Manager Library

Библиотека VMM Library — это центральное хранилище для многократно используе-
мых объектов (виртуальных жестких дисков, виртуальных флоппи-дисков, образов ISO
и скриптов). Эти объекты представлены файлами и хранятся в совместно используе-
мом ресурсе библиотеки (для скачивания серверами Hyper-V). Кроме того, библиотека
VMM Library хранит шаблоны виртуальных машин, а также профили оборудования и
гостевых операционных систем (которые используются для создания виртуальных ма-
шин). Эти конфигурации хранятся в базе данных Virtual Machine Manager, но физиче-
скими файлами конфигурации в совместно используемом ресурсе библиотеки они не
представлены. По умолчанию инсталляция SCVMM должна иметь одну библиотеку
VMM Library. Она инсталлируется с сервером VMM. Вы можете также создать и заре-
гистрировать дополнительные серверы библиотек VMM Library.
Консоль Virtual Machine Manager Administrator Console

Консоль VMM Administrator Console (рис. 10.3) — это основной графический интер-
фейс пользователя (GUI), который вы используете для того, чтобы:
создавать и разворачивать виртуальные машины, а также управлять ими;
наблюдать за хостами и серверами библиотек, а также управлять ими;
управлять глобальными настройками конфигураций;

управлять безопасностью доступа.
Консоль VMM Administrator Console инсталлируется после сервера VMM, а затем под-
ключается к серверу VMM (для управления им). Вы можете инсталлировать консоль
VMM Administrator Console на тот же самый компьютер, что и сервер VMM (либо на
другой компьютер). Консоль VMM Administrator Console можно использовать для под-
ключения к любому серверу VMM и управления им (но только одним сервером VMM
одновременно). Консоль VMM Administrator Console может управлять пулом отдель-
ных серверов Hyper-V и одним (или несколькими) кластерами хостов (до 16 узлов на
кластер) Hyper-V, использующими опцию Failover Clustering.
Рис. 10.3. Консоль Administrator Console в SCVMM
Консоль VMM Administrator Console создана на базе целого набора командлетов

Windows PowerShell. Когда вы инсталлируете консоль VMM Administrator Console, то
процедура инсталляции создает также и ярлык для специальной среды Windows
PowerShell с названием "командный процессор Virtual Machine Manager". Вы можете
использовать командную строку этого командного процессора для ввода команд, по-
зволяющих выполнять все те функции управления, которые вы можете выполнить
в консоли VMM Administrator Console.
Портал Virtual Machine Manager Self-Service Portal

VMM Self-Service Portal — это необязательный Web-портал, который позволяет поль-
зователям создавать и обслуживать собственные виртуальные машины. Этот портал
использует определяемые администратором роли, которые описывают область дейст-
вия операций пользователей (на их собственных виртуальных машинах). Кроме того,
Web-портал можно ограничить, чтобы он управлял только определенным набором сер-
веров Hyper-V. Когда пользователь самостоятельно создает виртуальную машину, то
она автоматически размещается на самом подходящем по рейтингу хосте (из имею-
щейся группы хостов). Администратор VMM может настроить квоту виртуальных ма-
шин в роли пользователя портала и присвоить шаблонам виртуальных машин показа-
тели квотирования, чтобы ограничить количество виртуальных машин, которое может
разворачивать пользователь или группа.
База данных Virtual Machine Manager Database

База данных Virtual Machine Manager Database хранит всю конфигурационную инфор-
мацию VMM, информацию библиотеки и информацию о состоянии заданий. Для базы
данных VMM требуется SQL Server 2005 SP2 или более новая его версия. Вы можете
указать как локальный, так и удаленный экземпляр уже существующей базы данных
Microsoft SQL Server, либо мастер Setup Wizard может инсталлировать на сервере
VMM версию SQL Server 2005 Express Edition SP2. Несмотря на то, что VMM поддер-
живает версию SQL Server 2005 Express Edition SP2, при управлении более чем
150 хостами или при интеграции с Operations Manager 2007 рекомендуется использо-
вать версию SQL Server 2005 SP2 Standard или Enterprise.
Агент Virtual Machine Manager Agent

На каждом сервере Hyper-V и сервере библиотеки должен быть инсталлирован агент
VMM Agent (для того, чтобы консоль VMM Administrator Console могла управлять сер-
вером). Агент VMM Agent можно инсталлировать с компакт-диска VMM, либо как
часть процесса регистрации сервера Hyper-V. Агент обеспечивает обмен между серве-
ром Hyper-V и консолью VMM Administrator Console.
Дополнительные компоненты SCVMM

В дополнение к описанным в предыдущих разделах основным компонентам, SCVMM
предоставляет также возможность выполнения миграций физических машин на вирту-
альные машины (P2V), а также виртуальных машин на виртуальные машины (V2V).
Миграция физических машин на виртуальные может выполняться как в оперативном,
так и в автономном состоянии. При выполнении миграции в оперативном состоянии
исходный физический компьютер продолжает работать, а для миграции текущего со-
стояния физической машины на виртуальную машину используются моментальные
снимки VSS. Это ограничивает миграции P2V только такими операционными систе-
мами, которые имеют поддержку VSS.
Автономные миграции P2V требуют выключения исходной физической машины. По-
сле этого физическая машина загружается со специального загрузочного образа WinPE
и производится миграция. Это позволяет образу WinPE получить полный доступ к дис-
кам физического компьютера. Во время процесса миграции учет изменения конфигу-
рации оборудования (виртуальной машины по сравнению с физической) производится
автоматически. Автономная миграция P2V — это режим по умолчанию для преобразо-
вания работающих под управлением Windows Server 2000 компьютеров. Это единст-
венный надежный способ преобразования контроллера домена Active Directory или
компьютера с томами FAT.
Миграция виртуальных машин на виртуальные позволяет мигрировать виртуальные
машины VMWare на виртуальные машины Hyper-V. Миграцию V2V можно выполнить
с виртуальной машины под управлением сервера VMWare ESX или с виртуальной ма-
шины VMWare, хранящейся в библиотеке VMM Library. Для миграции виртуальные
машины VMWare должны использовать формат хранения VMDK. Для успешной ми-
грации в виртуальной машине должна работать поддерживаемая сервером Hyper-V
гостевая операционная система.
Новые функциональные возможности SCVMM 2008 R2
Менеджер System Center Virtual Machine Manager 2008 R2 имеет такие функциональные
возможности, которые позволяют реализовать новые сценарии управления; он обеспечи-
вает также поддержку сервера Windows Server 2008 R2. Новые функции имеют поддержку
следующих возможностей.
• Live Migration. Управление функцией Live Migration сервера Hyper-V R2 как при плано-
вых, так и при неплановых простоях.
• Несколько виртуальных машин на один LUN. При помощи функции Cluster Shared
Volumes (CSV) сервера Windows Server 2008 R2 менеджер VMM R2 позволяет несколь-
ким виртуальным машинам находиться на одном и том же номере логического устрой-
ства (имеющего поддержку CSV). В такой конфигурации виртуальная машина может
мигрировать независимо от других машин, находящихся на этом же LUN.
• Миграция SAN в кластеры и из них. При помощи VMM R2 вы можете мигрировать вир-
туальную машину из одного кластера в другой, либо с отдельного хоста в кластер и на-
оборот.
• Улучшенная работа с сетью в версии Hyper-V R2. Версия Hyper-V R2 обеспечивает
поддержку канала TCP/IP и виртуальных очередей машин Virtual Machine Queues
(VMQ), многократного использования групп портов VMware, а также дает вам возмож-
ность включить/выключить подмену МАС-адресов для каждой виртуальной машины
в отдельности.
• Режим обслуживания Maintenance Mode. Версия Hyper-V R2 поддерживает концепцию
режима обслуживания хоста. Если управляемый хост переводится в режим обслужива-
ния и поддерживает миграцию Live Migration, то виртуальные машины могут мигриро-
вать в режиме Live Migration на другой хост. Если хост не поддерживает Live Migration,
то виртуальные машины можно перевести в сохраненное состояние.
• Непересекающиеся домены. VMM 2008 R2 автоматически создает специальный SPN
для DNS-имени, когда хост имеет разные полные доменные имена в Active Directory
и DNS.
Ракеш Малхотра (Rakesh Malhotra, Principal Group Program Manager
(System Center Virtual Machine Manager Team))
Решения
по преодолению последствий катастроф
Решения по преодолению последствий катастроф дают возможность создавать резерв-
ные копии (и восстанавливаться с них) на случай плановых или неплановых сбоев ро-
дительского раздела Hyper-V или виртуальных машин (либо того и другого одновре-
менно). Резервное копирование и восстановление родительского раздела Hyper-V ос-
новано на настройках родительского раздела Hyper-V, файлах InitialStore.xml, а также
системных состояниях. Резервное копирование и восстановление родительского разде-
ла вместе с виртуальными машинами включает в себя: конфигурацию виртуальных
машин, сохраненные состояния, моментальные снимки, соответствующие виртуальные
жесткие диски, конфигурацию родительского раздела Hyper-V.
Компания Microsoft предоставляет два основных решения для преодоления последст-
вий катастроф: Windows Server Backup и менеджер System Center Data Protection
Manager 2007 SP1.
Windows Server Backup

WSB — это решение для преодоления последствий катастроф, поставляющееся в со-
ставе Windows Server 2008. Для предоставления доступа к созданию резервных копий и
восстановлению с них Windows Server Backup использует пользовательский интерфейс
ММС или инструмент командной строки (WBAdmin.exe). На рис. 10.4 показан вид по
умолчанию консоли Windows Server Backup для ММС.
Рис. 10.4. Windows Server Backup
Windows Server Backup имеет следующие ограничения:

резервное копирование делается на уровне томов;
копируемый том должен быть подключен локально;
том должен быть отформатирован в NTFS;

копирование на ленту не поддерживается;
резервные копии могут храниться на внутренних или внешних дисках, дисках DVD,
а также в совместно используемых ресурсах;
для операции восстановления приложения требуется специальный модуль записи
VSS Writer.
Windows Server Backup обеспечивает возможность создания резервных копий только
для отдельных томов или для всей системы, но восстанавливать он позволяет как фай-
лы, каталоги, приложения и тома, так и всю систему целиком (рис. 10.5).
Рис. 10.5. Опции восстановления в Windows Server Backup
Способность восстанавливать файлы, каталоги и тома является стандартной возмож-

ностью Windows Server Backup. Однако для восстановления приложений требуется
специальный модуль записи Volume Shadow Copy Service (VSS) Writer, который имеет
специальные команды для сброса содержимого памяти приложения на диск и создания
резервных копий состояния приложения и его файлов. Это позволяет приложению
обеспечить отсутствие потерь содержимого памяти или очередей записи на диск.
Сервер Hyper-V инсталлирует специальный модуль записи VSS Writer, который "по-
нимает", как создавать резервные копии и восстанавливать конфигурацию Hyper-V и
виртуальные машины. Для того чтобы разрешить WSB восстановление информации
Hyper-V и виртуальных машин, модуль записи VSS Writer должен быть зарегистриро-
ван в Windows Server Backup. После его регистрации WSB может восстанавливать
конфигурацию Hyper-V, файл безопасности InitialStore.xml, а также виртуальные ма-

шины.
Несмотря на то, что резервное копирование сервера Hyper-V должно выполняться на
уровне томов, восстановление приложения Hyper-V приведет к восстановлению файла
безопасности InitialStore.xml и виртуальных машин (из резервной копии). Во время
восстановления у вас есть возможность восстановить файлы как в их исходное место-
положение, так и в другое место (рис. 10.6). Если вы восстановите файлы в исходное
местоположение, то все существующие там файлы будут перезаписаны.
Рис. 10.6. Варианты мест восстановления
Для восстановления отдельных файлов виртуальной машины вы должны сначала вос-

становить в другое место всю виртуальную машину, потом смонтировать виртуальный
жесткий диск в файловую систему хоста, а затем скопировать нужные файлы.
Приложение Windows Server Backup в составе инсталляций Server Core (серверов Windows
Server 2008 и Microsoft Hyper-V Server 2008) не устанавливается. Для резервного копиро-
вания вам придется использовать инструмент командной строки или делать удаленное
резервное копирование.
Менеджер System Center Data Protection Manager 2007 SP1

Менеджер System Center Data Protection Manager 2007 SP1 (DPM) — это главное при-
ложение компании Microsoft для резервного копирования данных и восстановления
Hyper-V. Кроме того, DPM также поддерживает резервное копирование и восстановле-
ние файловых служб, служб Windows SharePoint Services (WSS) и сервера Microsoft
Office SharePoint Server (MOSS), серверов Exchange Server и SQL Server, рабочих стан-
ций под управлением Windows XP и Windows Vista, а также сервера Virtual Server 2005
R2 SP1. На рис. 10.7 показана диаграмма функциональности DPM.
Рис. 10.7. Функциональность резервного копирования DPM
Менеджер DPM 2007 SP1 (при инсталлированном на сервере Hyper-V агенте DPM)
поддерживает для Hyper-V следующие сценарии:
оперативное резервное копирование виртуальных машин с операционными систе-
мами Windows, имеющими поддержку VSS (Windows Vista, Windows Server 2003 и
Windows Server 2008);
оперативное резервное копирование серверов Hyper-V;
автономное резервное копирование виртуальных машин с более старыми операци-
онными системами Windows, не имеющими поддержки VSS (Windows 2000,
Windows XP, Windows NT4), а также с Linux;
оперативное резервное копирование кластеризированных серверов Hyper-V.
Для любого из этих сценариев резервного копирования виртуальные жесткие диски
должны храниться локально на сервере Hyper-V. При этом поддерживаются Direct
Attached Storage (DAS), Storage Area Networks (SAN), а также диски на базе протокола
iSCSI (подключенные при помощи iSCSI-инициатора хоста). Виртуальные машины
с подключенными при помощи iSCSI-инициатора системами хранения, с транзитными
дисками, а также хранящиеся на удаленных совместно используемых ресурсах — все
это не видно с сервера Hyper-V и не может копироваться при помощи DPM.
DPM 2007 SP1 (при инсталлированном в виртуальной машине агенте DPM) поддержи-
вает также для Hyper-V следующий сценарий: оперативное резервное копирование
файлов, каталогов и приложений виртуальной машины. В этом сценарии поддержива-
ются: локально подключенные к виртуальной машине системы хранения; подключен-
ные через iSCSI-инициатор (к виртуальной машине) системы хранения; транзитные
диски; удаленные совместно используемые ресурсы.
DPM может быть развернут либо как решение резервного копирования в масштабе
предприятия, либо как локальное решение резервного копирования. Для первого уров-
ня хранения резервных копий DPM использует диски, для архивирования же исполь-

зуются ленты. DPM должен иметь полный контроль над используемыми им дисками.
Сервер DPM должен получить систему хранения в инициализированном виде, но она
должна находиться в автономном режиме. Система хранения импортируется в консоль
DPM и автоматически управляется из DPM. DPM использует технологию хранения
единственных экземпляров (для уменьшения потребности в объеме хранения для
резервных копий файлов).
Менеджер DPM SP1 можно инсталлировать либо на выделенном сервере (чтобы защи-
тить удаленные серверы Hyper-V), либо непосредственно на сервере Hyper-V (для ло-
кальной его защиты). Даже несмотря на то, что DPM использует технологию инкре-
ментального резервного копирования (для снижения трафика, посылаемого по сети во
время резервного копирования), в офисных сетях с невысокой пропускной способ-
ностью, возможно, имеет смысл инсталлировать DPM SP1 локально на сервере Hyper-V.
Локальная инсталляция DPM позволяет хранить все данные резервного копирования
прямо в офисе, что существенно ускоряет процесс восстановления после катастрофы.
DPM SP1 можно использовать (в распределенной конфигурации) для защиты самого
себя. Для резервного копирования и восстановления серверов DPM можно инсталли-
ровать центральный сервер DPM SP1. Это дает возможность разместить серверы DPM
ближе к защищаемым ими серверам, что позволяет быстрее выполнять резервное
копирование и восстановление (при этом сервер DPM защищается центральным сер-
вером).
Решения по наблюдению
Решения по наблюдению дают вам возможность исследования и получения определен-
ных предупреждений о потенциальных проблемах физического хоста, родительского
раздела Hyper-V, а также дочерних разделов. Наблюдение за физическим хостом со-
средоточено на таких вещах, как температура, электропитание, а также время наработ-
ки. Наблюдение за родительским разделом Hyper-V сосредоточено на логических про-
цессорах, использовании памяти системы, производительности системы хранения, се-
тевой производительности системы, гипервизоре Windows, а также службах
родительского раздела. Наблюдение за дочерними разделами сосредоточивается на
выделении виртуального оборудования (виртуальных процессоров, памяти, систем
хранения, сетевых адаптеров), а также на работающих в дочернем разделе службах и
приложениях.
Компания Microsoft предоставляет два основных решения для ведения наблюдения:
монитор Reliability and Performance Monitor и менеджер System Center Operations
Manager 2007.
Монитор Reliability and Performance Monitor

Монитор Reliability and Performance Monitor стандартно поставляется с полными ин-
сталляциями сервера Windows Server 2008. Это приложение на базе ММС, которое
может наблюдать за локальной или удаленной системой. Монитор Reliability and
Performance Monitor — это два инструмента в одном. Монитор Reliability Monitor дает
информацию о стабильности системы и тех событиях, которые влияют на надежность;
а монитор Performance Monitor дает подробную информацию по производительности
компонентов, служб и приложений системы (в реальном времени).
Монитор Reliability Monitor отслеживает историю событий (таких, как инсталляция
программного обеспечения, сбои приложений, сбои оборудования, а также многие дру-
гие сбои). Данные представляются в двух формах: диаграмма System Stability Chart или
отчет System Stability Report. Как представлено на рис. 10.8, диаграмма System Stability
Chart показывает события за последние 30 дней и дает индексное значение от 1 (наи-
менее стабильное) до 10 (наиболее стабильное). Этот индекс стабильности — взвешен-
ный показатель, полученный по количеству сбоев за период времени. Отчет System
Stability Report дает подробности по реальным событиям и сбоям.
Рис. 10.8. Монитор Reliability Monitor
Монитор Performance Monitor может работать в двух режимах: захват данных в реаль-
ном времени и воспроизведение записанных данных. Захват данных в реальном време-
ни позволяет вам увидеть информацию по производительности в реальном времени по
выбранным счетчикам производительности (рис. 10.9). Счетчики производительности
определяются операционной системой, приложением или службой.
Счетчики организованы в группы; причем счетчик может либо давать единый показа-
тель производительности системы, либо состоять из нескольких экземпляров. Напри-
Рис. 10.9. Монитор Performance Monitor
мер, если вы посмотрите на группу счетчиков производительности LogicalDisk, то

увидите список из 23 счетчиков. На рис. 10.10 показана группа счетчиков производи-
тельности LogicalDisk (в диалоговом окне Add Counters). Если вы выберете из списка
счетчик, то будет создан отдельный его экземпляр для каждого дисковода вашего ком-
пьютера, а также экземпляр _Total и экземпляр <All instances>. На рис. 10.10 мы вы-
брали счетчик % Disk Read Time и экземпляр этого счетчика для диска C:. В мониторе
Performance Monitor этот счетчик будет показывать процент времени, в течение кото-
рого система читает данные с дисковода C:.
Сервер Hyper-V имеет длинный список групп счетчиков производительности, причем
в каждой из них можно выбрать детальные счетчики. В следующем списке даны
имеющиеся в Hyper-V группы счетчиков:
Hyper-V Hypervisor;
Hyper-V Hypervisor Logical Processor;
Hyper-V Hypervisor Partition;
Hyper-V Hypervisor Root Partition;
Hyper-V Hypervisor Root Virtual Processor;
Hyper-V Hypervisor Virtual Processor;
Hyper-V Legacy Network Adapter;
Рис. 10.10. Диалоговое окно Add Counters
Hyper-V Task Manager Detail;

Hyper-V Virtual IDE Controller;
Hyper-V Virtual Machine Bus
Hyper-V Virtual Machine Health Summary;
Hyper-V Virtual Machine Summary;
Hyper-V Virtual Network Adapter;
Hyper-V Virtual Storage Device;
Hyper-V Virtual Switch;
Hyper-V Virtual Switch Port;
Hyper-V VM IO APIC;
Hyper-V VM Remoting;
Hyper-V VM Save, Snapshot, and Restore;
Hyper-V VM VID Driver;
Hyper-V VM VID Message Queue;
Hyper-V VM VID NUMA Node;
Hyper-V VM VID Partition;
Hyper-V VM Worker Process Manager.
Способность записи данных монитора Performance Monitor позволяет регистрировать

историческое состояние счетчиков производительности, а не только получать их пред-
ставление в реальном времени. При сборе данных в реальном времени график данных
все время перезаписывает старые данные. Для сохранения истории собранных данных
необходимо использовать режим записи данных.
Менеджер System Center Operations Manager 2007

Менеджер System Center Operations Manager 2007 — это решение компании Microsoft
для наблюдения в масштабе предприятия за оборудованием, операционными система-
ми, службами и приложениями. Для сбора информации с удаленных систем и сохране-
ния этих данных для анализа в базе данных SQL, менеджер Operations Manager 2007
использует реализованный на основе агентов механизм сбора данных. Конфигурация
сбора данных базируется на концепции "пакета управления". Пакет управления содер-
жит правила, мониторы и задачи для приложения, операционной системы или обору-
дования.
Правила определяют сбор данных из различных источников, таких как Perfmon,
EventLog, SNMP и файлы журналов. Эти данные затем сохраняются в базе данных
Operations Manager и используются для отчетов. Мониторы — это конечные автоматы,
которые определяют состояние того, за чем они наблюдают. Монитор может находить-
ся либо в одном из двух состояний (зеленое или красное), либо в одном из трех состоя-
ний (зеленое, желтое и красное). Состояние монитора изменяется в ответ на информа-
цию наблюдения. Мониторы могут задавать определенные пределы, которые отслежи-
ваются в собираемых (по правилам) данных, и предпринимать действия (в зависимости
от превышенного предела). Например, можно описать монитор, наблюдающий за сете-
вой производительностью виртуальной машины, который при превышении определен-
ного значения производительности выставляет желтое состояние (предупреждение) и
посылает сигнал тревоги на консоль Operations Manager 2007 Operations Console. Зада-
ча — это инициированное пользователем из консоли Operations Manager 2007
Operations Console действие, которое выполняется на удаленном сервере при помощи
агента Operations Manager. В пакетах управления описаны готовые задачи, причем вы
можете описывать свои дополнительные задачи.
При наблюдении за инфраструктурой Hyper-V при помощи менеджера System Center
Operations Manager 2007 SP1 ваша способность поддерживать систему в "здоровом"
состоянии будет зависеть от импортированных и описанных вами пакетов управления.
Вам понадобится как минимум самый свежий пакет управления для операционной сис-
темы Windows Server Base Operating System management pack (с поддержкой Windows
Server 2008). Он позволит вам наблюдать за готовностью и производительностью опе-
рационной системы, служб, систем хранения, сети, процессора и памяти.
Необходимые для наблюдения за серверами Hyper-V, виртуальными машинами и сер-
верами SCVMM 2008 инструменты сведены в единый пакет управления System Center
Virtual Machine 2008 management pack. Этот пакет управления обеспечивает вам спо-
собность наблюдать за серверами Virtual Server 2005 R2, Hyper-V и VMware ESX, а
также создавать соответствующие отчеты.
Для наблюдения за серверами VMWare ESX они должны управляться из менеджера
SCVMM 2008.
Пакет управления SCVMM 2008 наблюдает за производительностью сервера Hyper-V

(отслеживает системы хранения, память, процессор, физическую сеть, виртуальную
сеть, а также такие вещи, как количество виртуальных машин). Пакет управления
SCVMM 2008 также наблюдает за производительностью виртуальных машин (отсле-
живает виртуальные процессоры, виртуальные и транзитные жесткие диски, использо-
вание памяти виртуальных машин, а также виртуальные сети). Все это делается при
помощи загруженного на сервер Hyper-V агента Operations Manager 2007. Если вы ин-
сталлировали агент Operations Manager 2007 также и в виртуальную машину, то вы
сможете получать информацию по производительности приложений (если соответст-
вующий пакет управления для данного приложения был импортирован в менеджер
Operations Manager 2007).
Пакет управления SCVMM 2008 предоставляет правила и отчеты:
VM Utilization Report. Данный отчет дает информацию по коэффициенту использо-
вания виртуальных машин. Для выбранного периода времени отчет показывает
среднее использование (а также суммы и максимумы) по процессорам виртуальных
машин, памяти и дисковому пространству;
Host Utilization Report. Показывает количество работающих на каждом хосте вирту-
альных машин. Для выбранного периода времени и группы хостов этот отчет пока-
зывает среднее, суммарное и максимальное использование по процессорам, памяти
и дисковому пространству хостов;
Virtualization Candidates Report. Помогает выявить те физические компьютеры, ко-
торые являются хорошими кандидатами на превращение в виртуальные машины.
В отчете показаны средние значения для заданного набора счетчиков производи-
тельности (процессор, память, использование дискового пространства, а также кон-
фигурация оборудования (в том числе скорость процессора, количество процессо-
ров и общее количество RAM);
Host Utilization Growth Report. Показывает процентный рост ресурсов хоста и коли-
чество работающих на нем виртуальных машин (за выбранный период времени);
VM Allocation. Дает информацию, которую вы можете использовать для вычисле-
ния списания средств по статьям расходов на виртуальные машины.
При помощи интегрирования менеджера System Center Virtual Machine Manager 2008 и
менеджера System Center Operations Manager 2007 SP1 можно активировать расширен-
ную функцию Performance and Resource Optimization (PRO). Эта функция является
функциональной возможностью менеджера Virtual Machine Manager, она использует
информацию по производительности из Operations Manager 2007 для того, чтобы по-
мочь клиентам обеспечить эффективную работу инфраструктуры виртуальных машин.
Расширяя способности наблюдения менеджера System Center Operations Manager 2007,
функция PRO позволяет администраторам реагировать на плохую производительность
или сбои виртуализированного оборудования, операционных систем и приложений.
PRO обеспечивает два варианта реагирования: первый — это выдаваемые сигналы тре-
воги о существующей проблеме (с предоставлением рекомендаций по ее устранению).
Администратор может реализовать предложенные рекомендации одним щелчком мы-
ши. Рекомендации могут содержать некие предварительно определенные действия,
например миграцию виртуальных машин с одного сервера Hyper-V (на котором пре-
вышен порог допустимого использования процессора) на другой сервер Hyper-V. PRO
можно расширить вашими собственными действиями (например, для использования
Wake-on-LAN с целью включения резервного сервера Hyper-V, что позволяет вам ди-
намически расширять пул серверов и адаптироваться к новым потребностям). При вто-
ром варианте реагирования система автоматически реализует рекомендованные дейст-
вия (без всякого взаимодействия с администратором).
Резюме
В этой главе был дан обзор продуктов и технологий, которые можно сочетать для по-
лучения комплексного решения по управлению серверами Hyper-V и виртуальными
машинами. Эти продукты разбиты на три группы: решения по управлению, решения по
преодолению последствий катастроф, решения по наблюдению.
Вы увидели, что в каждой из этих групп есть инструменты, которые поставляются
в составе операционной системы; есть также и инструменты масштаба предприятия,
которые значительно расширяют функциональные возможности встроенных инстру-
ментов. Если вы хотите управлять небольшим количеством серверов Hyper-V или вир-
туальных машин, тогда поставляемые в составе операционной системы инструменты
послужат хорошей стартовой точкой. Однако по мере роста вашей инфраструктуры
виртуализации вы вероятно захотите дополнить эти встроенные инструменты набором
инструментов System Center. В следующих главах будет дан более подробный обзор:
управления одним сервером и множеством серверов; сценариев устранения последст-
вий катастроф, а также наблюдения.

System Center Data Protection Manager 2007, техническая информация по самому
продукту, а также по его инсталляции, доступная по ссылке:
http://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/default.aspx;
System Center Virtual Machine Manager 2008, техническая информация по самому
продукту, а также по его инсталляции, доступная по ссылке:
http://www.microsoft.com/systemcenter/virtualmachinemanager/en/us/default.aspx;
System Center Operations Manager 2007, техническая информация по самому продук-
ту, а также по его инсталляции, доступная по ссылке:
http://www.microsoft.com/systemcenter/operationsmanager/en/us/default.aspx;
пакет управления System Center Virtual Machine Manager 2008 Management Pack,
доступный по ссылке:
http://www.microsoft.com/downloads/details.aspx?FamilyID=d6d5cddd-4ec8-4e3c-
8ab1-102ec99c257f&displaylang=en;
Hyper-V Management Tools for Vista x86 — ресурс, предоставляющий доступ к вер-
сии клиента администрирования Hyper-V для Vista 32-bit. Доступен по ссылке:
http://www.microsoft.com/downloads/details.aspx?familyid=BF909242-2125-4D06-
A968-C8A3D75FF2AA&displaylang=en;
Hyper-V Management Tools for Vista x64 — ресурс, предоставляющий доступ к вер-
сии клиента администрирования Hyper-V для Vista 64-bit. Доступен по ссылке:
http://www.microsoft.com/downloads/details.aspx?FamilyID=88208468-0ad6-
47de-8580-085cba42c0c2&DisplayLang=en.
ГЛАВА 11
Управление
одним сервером Hyper-V
В этой главе вы узнаете о том, как использовать поставляемые в составе Windows
Server 2008 Hyper-V инструменты для выполнения каждодневных задач управления.
Мы изложим три основные темы: управление Hyper-V и виртуальными машинами,
восстановление после катастроф, а также наблюдение за производительностью. В чис-
ло этих инструментов входят: менеджер Hyper-V Manager для MMC (называемый так-
же менеджером Hyper-V Manager или консолью Hyper-V Manager), приложение
Windows Server Backup, а также монитор Reliability and Performance Monitor. В частно-
сти, вы узнаете о возможных вариантах конфигурации Hyper-V и виртуальных машин
и получите пошаговую процедуру для создания и управления новой виртуальной ма-
шиной при помощи Hyper-V Manager для MMC. Эта процедура содержит: определение
конфигурации виртуальной машины, создание виртуального жесткого диска (VHD),
подключение к виртуальной сети, настройку конфигурации виртуальной машины, ин-
сталляцию гостевой операционной системы, а также инсталляцию служб интеграции
Integration Services (для улучшения производительности и функциональности). Кроме
того, вы изучите варианты резервного копирования и восстановления Hyper-V и вирту-
альных машин при помощи Windows Server Backup. И наконец, вы получите понима-
ние того, как нужно использовать монитор Reliability and Performance Monitor для сбо-
ра информации по состоянию и производительности вашего сервера Hyper-V, а также
по ресурсам виртуальных машин.
Управление сервером Hyper-V

Когда вы добавляете роль Hyper-V в полную инсталляцию Windows Server 2008, то
инсталлируется и менеджер Hyper-V Manager для MMC, который представляет собой
основной графический интерфейс пользователя (GUI) для управления сервером Hyper-V
и виртуальными машинами. В инсталляциях же Windows Server 2008 Server Core и
Hyper-V Server 2008 имеется только интерфейс командной строки, поэтому при уста-
новке роли Hyper-V менеджер Hyper-V Manager для MMC не инсталлируется. Для
управления Hyper-V на инсталляции Windows Server 2008 Server Core или сервером
Hyper-V Server 2008, вы должны инсталлировать Hyper-V Manager для MMC на другой
системе Windows Server 2008 или на рабочей станции с Windows Vista Service Pack 1
(SP1).
Инсталляция инструментов управления

сервером Hyper-V
Для активации инструментов Remote Server Administration Tools (RSAT) на полной ин-
сталляции Windows Server 2008 (без роли Hyper-V) выполните следующие шаги:
1. Откройте Server Manager.
2. В Server Manager выберите в левой панели узел Features. В правой панели в списке
Features Summary вы увидите те функциональные возможности, которые в данный
момент инсталлированы на сервере. Там же имеются средства для добавления и
удаления этих функциональных возможностей (рис. 11.1).
Рис. 11.1. Список Features Summary в Server Manager
3. Щелкните Add Features для запуска мастера Add Features Wizard.

4. На странице Select Features разверните узел Remote Server Administration Tools
(рис. 11.2).
5. Разверните Role Administration Tools, установите флажок Hyper-V Tools
(рис. 11.3), а затем нажмите кнопку Next.
6. На странице Confirm Installation Selections (рис. 11.4) просмотрите информацию,
а затем нажмите кнопку Install.
7. На странице Installation Results (рис. 11.5) нажмите кнопку Close.
8. После того как мастер Add Features Wizard будет закрыт, страница Features
Summary будет показывать наличие инструментов Hyper-V Tools (рис. 11.6).
Инструменты RSAT Hyper-V Tools инсталлируются в каталог %SystemDrive%\Program
Files\Hyper-V и включают менеджер Hyper-V Manager (Virtmgmt.msc) и приложение
Virtual Machine Connection (Vmconnect.exe).
Глава 11. Управление одним сервером Hyper-V 395
Рис. 11.2. Узел Remote Server Administration Tools
Рис. 11.3. Узел Hyper-V Tools

Рис. 11.4. Страница Confirm Installation Selections
Рис. 11.5. Страница Installation Results

Рис. 11.6. Страница Features Summary в Server Manager
Для инсталляции инструментов RSAT Hyper-V Tools из командной строки введите следую-
щее: ocsetup MicrosoftHyper-V-Management-Clients.
Вы можете также инсталлировать инструменты Hyper-V Tools на рабочей станции под

управлением операционной системы Windows Vista SP1 (версии x86 или x64). Эти ин-
струменты имеются в составе пакета удаленного управления KB952627 для Hyper-V.
Аналогично версии для Windows Server 2008, версия инструментов под Windows Vista
SP1 поддерживает удаленное управление одним или несколькими серверами Hyper-V.
Вы можете скачать обновление для удаленного управления Hyper-V под операционную
систему Windows Vista x64 SP1 с Web-сайта компании Microsoft по ссылке:
http://www.microsoft.com/DownLoads/details.aspx?familyid=88208468-0AD6-47DE-8580-
085CBA42C0C2.
Для инсталляции обновления удаленного управления Hyper-V на рабочую станцию

с Windows Vista SP1 выполните следующие шаги:
1. Запустите инсталляцию обновления удаленного управления Hyper-V (рис. 11.7).
2. В диалоговом окне Windows Update Standalone Installer (рис. 11.8) нажмите кноп-
ку OK.
3. Пакет обновления инсталлирует инструменты удаленного управления Hyper-V в ка-
талог %SystemDrive%\Program Files\Hyper-V.
4. После завершения инсталляции (рис. 11.9) нажмите кнопку Close.
Рис. 11.7. Скачайте и запустите инсталляцию удаленного управления Hyper-V
Рис. 11.8. Диалоговое окно Windows Update Standalone Installer
Рис. 11.9. Инсталляция обновления удаленного управления завершена

Ярлык для Hyper-V Manager добавляется в группу Administrative Tools и в апплет

Administrative Tools в Control Panel.
По умолчанию ссылка на Administrative Tools в меню кнопки Start в Windows Vista не вклю-
чается. Для включения ее в меню кнопки Start щелкните правой кнопкой мыши по кнопке
Start, а затем выберите пункт Properties. На вкладке Start Menu нажмите кнопку
Customize и поставьте флажок Display on the all programs menu and the start menu (под
System Administrative Tools), после чего дважды нажмите кнопку OK (для того, чтобы за-
крыть диалоговое окно Taskbar and Start Menu Properties).
Активирование удаленного управления

В дополнение к инсталляции на удаленной системе инструментов управления сервером
Hyper-V вы должны сконфигурировать сервер Hyper-V (для того, чтобы он позволил
выполнять удаленное управление). Если вы этого не сделаете, то не сможете подклю-
читься к серверу Hyper-V со своего удаленного компьютера. В частности, когда вы от-
кроете Hyper-V Manager и попытаетесь подключиться к серверу, то получите следую-
щую ошибку: "You do not have the required permission to complete this task. Contact the
administrator of the authorization policy for the computer ‘COMPUTERNAME’" (У вас нет
необходимых прав для выполнения этой задачи. Свяжитесь с администратором поли-
тики авторизации компьютера ‘COMPUTERNAME’).
Конфигурирование удаленного управления — это многошаговый процесс, в котором
вы должны модифицировать настройки как того сервера Hyper-V, которым вы хотите
управлять, так и той рабочей станции, на которой работают инструменты управления.
Одним из самых часто встречающихся сценариев является управление входящим в со-
став домена сервером Hyper-V с входящей в этот же домен рабочей станции Windows
Vista SP1 (без использования учетной записи с правами администратора домена).
В этом случае требуется выполнить четыре основных шага конфигурации:
создать в домене учетную запись для управления сервером Hyper-V;
сконфигурировать политику Authorization Manager;
сконфигурировать настройки Distributed Component Object Model (DCOM);
сконфигурировать настройки Windows Management Instrumentation (WMI).
Для активации удаленного управления сервером Hyper-V с рабочей станции Windows
Vista SP1 (с использованием учетной записи без прав администратора домена) необхо-
димо выполнить следующие шаги:
1. Используя подключение удаленного рабочего стола к контроллеру домена (либо
при помощи инструментов RSAT, инсталлированных на вашей рабочей станции
Windows Vista SP1), откройте консоль Active Directory Users And Computers и соз-
дайте в домене учетную запись HyperVMgr.
2. Зарегистрируйтесь на сервере Hyper-V под учетной записью с правами администра-
тора домена и откройте консоль Authorization Manager (рис. 11.10).
3. В консоли Authorization Manager щелкните правой кнопкой мыши в левой панели
по пункту Authorization Manager и выберите Open Authorization Store
(рис. 11.11).
Рис. 11.10. Открываем консоль Authorization Manager (из меню Start)
Рис. 11.11. Консоль Authorization Manager
4. В диалоговом окне Open Authorization Store (рис. 11.12) отметьте переключатель

XML file, введите C:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xml в
текстовом поле Store name, а затем нажмите кнопку OK.
5. Разверните в левой панели узел Hyper-V services, а затем — узел Role Assignments
(рис. 11.13).
6. Щелкните правой кнопкой мыши по узлу Administrator, выберите Assign Users and
Groups | From Windows and Active Directory (рис. 11.14).
Рис. 11.12. Диалоговое окно Open Authorization Store
Рис. 11.13. Разверните в левой панели узел Role Assignments
Рис. 11.14. Выбор пользователей и групп из Windows и Active Directory

7. В диалоговом окне Select Users, Computers, or Groups (рис. 11.15) введите

HyperVMgr, нажмите кнопку Check Names, а затем — кнопку OK.
Рис. 11.15. Диалоговое окно Select Users, Computers, or Groups
8. Теперь доменная учетная запись HyperVMgr является обладателем роли

Administrator (рис. 11.16), что позволяет ей управлять сервером Hyper-V и ресурса-
ми виртуальных машин. Однако она не дает записи HyperVMgr никаких прав для
управления другими ресурсами сервера и не делает запись HyperVMgr членом ло-
кальной группы администраторов.
В зависимости от ваших политик управления и безопасности вы, возможно, не станете до-
бавлять учетной записи HyperVMgr роль Administrator. В менеджере Authorization Manager
можно создать новые роли и сделать их присваивания. Подробности см. в главе 6.
Рис. 11.16. Доменная учетная запись HyperVMgr имеет роль Administrator

10. Откройте консоль Server Manager, разверните узел Configuration (в левой панели),
раскройте узел Local Users and Groups, выберите узел Groups, а затем —
Distributed COM Users (рис. 11.17).
Рис. 11.17. Выберите Distributed COM Users в Local Users and Groups
11. Щелкните правой кнопкой мыши по пункту Distributed COM Users и выберите
команду Add To Group.
12. В диалоговом окне Distributed COM Users Properties (рис. 11.18) нажмите кнопку
Add.
13. В диалоговом окне Select Users, Computers, or Groups введите HyperVMgr, нажмите
кнопку Check Names, а затем — кнопку OK.
14. В диалоговом окне Distributed COM Users Properties нажмите кнопку OK.
15. В Server Manager разверните узел Configuration (в левой панели), а затем выберите
узел WMI Control (рис. 11.19).
16. Щелкните правой кнопкой мыши по узлу WMI Control, выберите пункт
Properties, а затем — вкладку Security в диалоговом окне WMI Control Properties
(рис. 11.20).
17. Разверните узел Root, выберите CIMV2, а затем нажмите кнопку Security.
18. В диалоговом окне Security for ROOT\CIMV2 (рис. 11.21) нажмите кнопку Add и
добавьте доменную учетную запись HyperVMgr с правами по умолчанию.
19. В диалоговом окне Security for ROOT\CIMV2 выберите в верхней панели имя
пользователя HyperVMgr, а затем нажмите кнопку Advanced.
Рис. 11.18. Диалоговое окно Distributed COM Users Properties
Рис. 11.19. Выберите WMI Control в Server Manager
20. В диалоговом окне Advanced Security Settings for CIMV2 (рис. 11.22) выберите
имя пользователя HyperVMgr, а затем нажмите кнопку Edit.
21. В диалоговом окне Permission Entry for CIMV2 выберите This namespace and
subnamespaces в раскрывающемсясписке Apply to.
22. В списке Permissions в столбце Allow отметьте флажок Remote Enable, а затем
установите флажок Apply these permissions to objects and/or containers within this
container only (рис. 11.23).
Рис. 11.20. Вкладка Security диалогового окна WMI Control Properties
Рис. 11.21. Диалоговое окно Security for ROOT\CIMV2

Рис. 11.22. Диалоговое окно Advanced Security Settings for CIMV2
Рис. 11.23. Диалоговое окно Permission Entry for CIMV2

23. Для возвращения в диалоговое окно WMI Control Properties три раза нажмите
кнопку OK.
24. В окне WMI Control Properties в узле Root выберите Virtualization, а затем на-
жмите кнопку Security (рис. 11.24).
Рис. 11.24. Диалоговое окно WMI Control Properties
25. Повторить шаги 18—23 для того, чтобы разрешить удаленное управление про-
странством имен virtualization.
26. Нажмите кнопку OK (чтобы закрыть диалоговое окно WMI Control Properties).
27. Закройте Server Manager, а затем перезапустите сервер Hyper-V.
После перезапуска сервера Hyper-V вы можете зарегистрироваться на рабочей станции
Windows Vista SP1 под учетной записью HyperVMgr, открыть Hyper-V Manager и под-
ключиться к серверу Hyper-V с полными правами для управления им и всеми вирту-
альными машинами.
Для данного примера в менеджере Authorization Manager роль Administrator была присвоена
единственной доменной учетной записи с областью действия по умолчанию Hyper-V
Services. Однако новые роли Hyper-V вы должны создавать в соответствии с имеющимися
в вашей рабочей среде функциями управления. Затем создавайте новые группы безопас-
ности и используйте для присваивания новых ролей Hyper-V хорошо известную модель
вложения групп. Например, создайте в домене новую глобальную группу (такую, как Hyper-V
Admins — GG, чтобы обозначить глобальную группу) и добавьте в эту группу соответст-
вующие пользовательские учетные записи. Затем создайте в домене локальную группу (та-
кую, как Hyper-V Local Admins — DLG, чтобы обозначить локальную группу домена) и вло-
жите в нее глобальную группу. И наконец, используйте эту локальную группу домена при
присваивании ролей Hyper-V.
Скрипт конфигурации HVRemote
Настройка удаленного управления сервером Hyper-V в том случае, когда сервер Hyper-V и
клиент управления находятся в одном домене, является относительно простой процедурой.
Она становится сложнее в том случае, когда один или оба компьютера находятся в рабочих
группах. Для упрощения этого процесса конфигурации имеется скрипт HVRemote, который
быстро настраивает сервер Hyper-V и клиентский компьютер. Он написан на VBScript, по-
скольку это очень часто используемая платформа для написания скриптов, имеющаяся на
всех платформах Windows.
Поддержка серверов в скрипте HVRemote

Скрипт HVRemote поддерживает следующие конфигурации Hyper-V:
• Windows Server 2008 с инсталлированной ролью Hyper-V (как полные инсталляции, так
и типа Server Core);
• Microsoft Hyper-V Server 2008;
• Windows Server 2008 R2 с инсталлированной ролью Hyper-V (как полные инсталляции,
так и типа Server Core);
• Microsoft Hyper-V Server 2008 R2.
Поддержка клиентов в скрипте HVRemote

Скрипт HVRemote поддерживает следующие клиентские операционные системы:
• Windows Server 2008 x86 (полная инсталляция);
• Windows Server 2008 x64 (полная инсталляция, как с ролью Hyper-V, так и без нее);
• Windows Vista SP1 (версии Business, Enterprise и Ultimate);
• Windows 7 Client (версии Professional, Enterprise и Ultimate).
Поддержка конфигурирования в скрипте HVRemote

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

Скрипт HVRemote при добавлении или удалении пользователей модифицирует на сервере
Hyper-V следующие настройки:
• присваивание роли администратора в хранилище авторизации Authorization Store по
умолчанию;
• членство в группе Distributed COM Users;
• разрешения безопасности WMI для пространства имен Root\CIMV2;
• разрешения безопасности WMI для пространства имен Root\Virtualization;
• конфигурацию сетевого экрана Windows Firewall для активации правил Hyper-V (необя-
зательно).
На клиенте HVRemote модифицирует следующие настройки:
• исключение Windows Firewall для Microsoft Management Console;
• исключения Windows Firewall для Hyper-V Management Clients;
• анонимный доступ DCOM (нужен не всегда).
Поддержка HVRemote
HVRemote не является официальным инструментом компании Microsoft и поэтому не под-
держивается компанией. Однако он доступен на условиях лицензии Microsoft Public License
и лицензии Creative Common Attribution 3.0.
Джон Ховард (John Howard, Senior Program Manager
(Hyper-V Team, Windows Core Operating System Division))
Скачать HVRemote и его документацию можно по ссылке:
http://code.msdn.microsoft.com/HVRemote.
Настройка представления Hyper-V Manager

Менеджер Hyper-V Manager позволяет вам настраивать свое представление. По умол-
чанию менеджер Hyper-V Manager содержит три панели:
Console Tree Pane. Эта панель содержит древовидное представление всех серверов
Hyper-V, которые вы подключили к менеджеру Hyper-V Manager;
Virtual Machines Pane. Эта панель содержит подробности о зарегистрированных
виртуальных машинах, моментальных снимках виртуальных машин, а также ми-
ниатюрное изображение дисплея виртуальной машины;
Actions Pane. Данная панель содержит список действий, которые разрешены для
управления сервером Hyper-V и выделенной виртуальной машиной.
Рис. 11.25. Выбор настройки представления Hyper-V Manager

Рис. 11.26. Диалоговое окно Customize View
Рис. 11.27. Панель Virtual Machines

Для настройки представления Hyper-V Manager выполните следующие шаги:

1. Откройте менеджер Hyper-V Manager.
2. В панели Actions щелкните по пункту View, а затем выберите Customize
(рис. 11.25).
3. В диалоговом окне Customize View (рис. 11.26) установите или снимите флажки в
группах MMC и Snap-in (чтобы показать или скрыть элементы Hyper-V Manager).
При выборе этих опций вы будете динамически видеть соответствующие изменения
в консоли Hyper-V Manager.
4. После выполнения всех настроек нажмите кнопку OK.
5. Как показано в представлении Hyper-V Manager (рис. 11.27), если вы скроете пане-
ли Console Tree и Actions, то останется только панель Virtual Machines.
Настройки сервера Hyper-V

В табл. 11.1 приведен список настроек Hyper-V, в состав которых входят параметры
конфигурации уровня сервера и уровня пользователя. Если вы создаете новый вирту-
альный жесткий диск или виртуальную машину, то можете изменить их местоположе-
ние по умолчанию (заданное в настройках Hyper-V).
Таблица 11.1. Настройки Hyper-V
Настройка Hyper-V Описание
Virtual Hard Disks Определяет каталог по умолчанию для хранения файлов новых виртуальных
жестких дисков
Virtual Machines Определяет каталог по умолчанию для хранения конфигурационных файлов
новых виртуальных машин
Keyboard Определяет способ применения клавиатурных комбинаций Windows (при
использовании приложения Virtual Machine Connection). Вот варианты:
• использовать на физическом компьютере;
• использовать на виртуальной машине;
• использовать на виртуальной машине только при работе в полноэкранном
режиме
Mouse Release Key Определяет ту комбинацию клавиш, которую вы хотите использовать для
освобождения мыши (если службы интеграции в виртуальной машине не ус-
тановлены). Вот возможные варианты:
• <Ctrl>+<Alt>+<←>;
• <Ctrl>+<Alt>+<→>;
• <Ctrl>+<Alt>+<Пробел>;
• <Ctrl>+<Alt>+<Shift>
User Credentials Указывает, хотите ли вы по умолчанию предоставлять учетные данные ваше-
го текущего сеанса Windows (при создании нового подключения к работающей
виртуальной машине при помощи приложения Virtual Machine Connection)
Delete Saved Позволяет вам удалять те учетные данные, которые были использованы для
Credentials подключения к работающей виртуальной машине (при помощи приложения
Virtual Machine Connection)
Настройка Hyper-V Описание
Reset Check Boxes Позволяет вам восстановить подтверждающие сообщения Hyper-V и страницы
мастеров (которые вы ранее решили скрыть)
Для модификации настроек Hyper-V выполните следующие шаги:

2. В панели Actions щелкните по пункту Hyper-V Settings.
3. В диалоговом окне Hyper-V Settings модифицируйте настройки, а затем нажмите
кнопку Apply.
4. После завершения модификаций нажмите кнопку OK.
Изменение состояния службы

Virtual Machine Management Service
В менеджере Hyper-V Manager вы можете запустить и остановить службу Virtual
Machine Management Service (VMMS). В течение того времени, пока служба VMMS
остановлена, вы не сможете управлять сервером Hyper-V или виртуальными машина-
ми. Однако виртуальные машины продолжают работать (несмотря на остановку служ-
бы VMMS).
Для остановки и запуска службы VMMS выполните следующие шаги:
2. В панели Actions щелкните по пункту Stop Service.
3. В диалоговом окне Stop Virtual Machine Management service (рис. 11.28) нажмите
кнопку Yes.
Рис. 11.28. Диалоговое окно Stop Virtual Machine Management service
4. После остановки службы VMMS менеджер Hyper-V Manager обновит окно и пока-
жет, что служба VMMS недоступна (рис. 11.29).
5. Для перезапуска VMMS в панели Actions щелкните по пункту Start Service.
6. После перезапуска VMMS менеджер Hyper-V Manager обновится и покажет ресур-
сы Hyper-V (рис. 11.30).
Рис. 11.29. Служба VMMS недоступна
Рис. 11.30. Отображение ресурсов Hyper-V после перезапуска VMMS

Вы можете также остановить и запустить службу VMMS из командной строки (командой net
stop vmms или net start vmms). Убедитесь, что вы выполняете эти команды в командном
окне с привилегиями локального администратора.

при помощи Hyper-V Manager
Создание новой виртуальной машины при помощи Hyper-V Manager — это простой
процесс. Однако перед началом вам следует определить перечисленные в табл. 11.2
элементы конфигурации. Это базовые параметры для создания новой виртуальной ма-
шины.
Таблица 11.2. Основные параметры для создания новой виртуальной машины
Название виртуаль- Название для новой виртуальной машины. Это название будет отображать-
ной машины ся в менеджере Hyper-V Manager
Каталог виртуальной Новый или существующий каталог для хранения файла конфигурации вирту-
машины альной машины (xml), а также файлов сохраненных состояний (vsv и bin).
Если вы не выберете каталог, виртуальная машина будет храниться в ката-
логе по умолчанию (указанном в настройках Hyper-V)
Память Количество памяти, которое нужно выделить новой виртуальной машине (до
32 Гбайт в случае Windows Server 2008 Standard Edition и до 64 Гбайт в слу-
чае версий Enterprise или Datacenter). Выделение памяти должно учитывать
количество памяти физического сервера, а также требования к памяти роди-
тельского раздела и других работающих виртуальных машин
Виртуальный Виртуальная сеть для подключения сетевого адаптера виртуальной машины.
сетевой адаптер Можно также указать отключенное от сети состояние виртуального адаптера
Виртуальный жесткий Название, место хранения, а также размер нового виртуального жесткого
диск диска. Максимальный размер виртуального жесткого диска 2040 Гбайт. Если
к виртуальной машине надо подключить уже существующий виртуальный
жесткий диск, то здесь указывается местоположение виртуального жесткого
диска. Конфигурирование виртуального жесткого диска для новой виртуаль-
ной машины можно отложить
Опции Используемый для инсталляции гостевой операционной системы носитель.
инсталляции Гостевая операционная система может инсталлироваться с: физического
дисковода CD/DVD или с образа ISO, подключенного к виртуальному диско-
воду DVD; с загрузочного флоппи-диска, подключенного к виртуальному дис-
ководу флоппи-диска; с сетевого сервера инсталляции. Инсталляцию госте-
вой операционной системы можно отложить
После определения этих основных параметров вы можете создать новую виртуальную

машину при помощи менеджера Hyper-V Manager.
Создание новой виртуальной машины

Мастер New Virtual Machine Wizard проведет вас по процессу создания новой вирту-
Для создания новой виртуальной машины выполните следующие шаги:

1. В панели Actions менеджера Hyper-V Manager щелкните по пункту New, а затем
выберите Virtual Machine.
2. На странице Before You Begin мастера New Virtual Machine Wizard нажмите кнопку
Next.
3. На странице Specify Name And Location введите название виртуальной машины.
Если вы не хотите хранить виртуальную машину в местоположении по умолчанию,
выберите Store the virtual machine in a different location, введите полный путь
к каталогу хранения, а затем нажмите кнопку Next.
4. На странице Assign Memory укажите выделение памяти для виртуальной машины
(в мегабайтах). Значение по умолчанию — это минимальная цифра, которую вы
должны заменить с учетом факторов табл. 11.2. Когда закончите, нажмите кнопку
Next.
5. На странице Configure Networking выберите ту виртуальную сеть, к которой будет
подключен виртуальный сетевой адаптер по умолчанию. Если вы не хотите под-
ключать виртуальный сетевой адаптер по умолчанию, выберите Not Connected. Ко-
гда закончите, нажмите кнопку Next.
Если вы планируете инсталлировать операционную систему, которой необходимы обнов-
ления, то вам, возможно, следует выбрать Not Connected или подключиться к частной вир-
туальной сети. Это поможет обеспечить изоляцию новой виртуальной машины до полного
ее обновления.
6. На странице Connect Virtual Hard Disk у вас есть следующие варианты:

• для создания нового динамически расширяющегося виртуального жесткого дис-
ка выберите Create a virtual hard disk. Затем введите полный путь к каталогу
хранения. И наконец, введите размер виртуального жесткого диска в гигабайтах.
По умолчанию виртуальный жесткий диск подключается к виртуальному кон-
троллеру IDE;
• если вы хотите использовать уже существующий виртуальный жесткий диск, то
выберите Use an existing virtual hard disk. Затем введите полный путь и имя
файла;
• если вы хотите отложить подключение виртуального жесткого диска, выберите
Attach a virtual hard disk later.
7. После того как вы сделаете ваш выбор, нажмите кнопку Next.
8. На странице Installation Options у вас есть следующие варианты:
• если вы хотите отложить инсталляцию гостевой операционной системы, выбери-
те вариант Install an operating system later;
• выберите Install an operating system from a boot CD/DVD-ROM, а затем укажи-
те местоположение инсталляционного носителя. Это может быть носитель в фи-
зическом дисководе CD/DVD или образ ISO, который вы подключаете к вирту-
альному дисководу DVD по умолчанию;
• выберите Install an operating system from a boot floppy disk, а затем укажите
образ гибкого диска для подключения к виртуальному дисководу гибких дисков
по умолчанию;
• если вы хотите инсталлировать гостевую операционную систему при помощи
метода Pre-Execution Environment (PXE), выберите Install an operating system
from a network-based installation server.
9. После того как вы сделаете ваш выбор, нажмите кнопку Next.
10. На странице Completing the New Virtual Machine Wizard (рис. 11.31) просмотри-
те сделанные вами настройки. Если вы хотите, чтобы виртуальная машина старто-
вала немедленно после ее создания, установите флажок Start The virtual machine
after it is created, а затем нажмите кнопку Finish.
Рис. 11.31. Страница со сводкой параметров мастера New Virtual Machine Wizard
в менеджере Hyper-V Manager
Создается каталог новой виртуальной машины, а также файл конфигурации виртуаль-

ной машины и виртуальный жесткий диск. Вы увидите, что при создании нового вир-
туального жесткого диска он имеет размер всего в несколько килобайтов. Поскольку
тип виртуального жесткого диска по умолчанию — это динамически расширяющийся
диск, то до загрузки операционной системы этот файл содержит только основную ин-
формацию заголовка. Пространство файла будет выделяться виртуальному жесткому
диску по мере необходимости (до указанного максимального размера). Когда файл
конфигурации и виртуальный жесткий диск созданы, виртуальная машина регистриру-

ется, и ее подробности появляются в менеджере Hyper-V Manager.
Для того чтобы подключить виртуальный жесткий диск фиксированного размера или разно-
стный виртуальный жесткий диск, используйте мастер New Virtual Hard Disk Wizard в ме-
неджере Hyper-V Manager (в панели Actions щелкните по пункту New, а затем выберите
Hard Disk) для создания виртуального жесткого диска до создания новой виртуальной ма-
шины. При помощи мастера вы можете создать виртуальный жесткий диск любого поддер-
живаемого типа. Когда вы создаете новую виртуальную машину, выберите вариант Use an
existing virtual hard disk и укажите созданный ранее виртуальный жесткий диск.
Настройка ключевых параметров конфигурации

Когда вы создаете новую виртуальную машину, то конфигурируете несколько вирту-
альных компонентов (таких, как дисковод DVD, дисковод гибких дисков, COM-порты,
а также сетевой адаптер), причем некоторые из них — установками по умолчанию.
Однако вы можете пожелать настроить один или несколько этих ключевых компонен-
тов до того, как начать загружать в виртуальную машину операционную систему и
приложения. В большинстве случаев при добавлении или удалении компонентов вир-
туальная машина должна быть выключена. Другие настройки конфигурации (такие,
как изменение букв виртуальных дисков DVD или подключение виртуального сетевого
адаптера к другой виртуальной сети) можно модифицировать даже на работающей
виртуальной машине. Доступ ко всем компонентам конфигурации имеется на странице
настроек виртуальной машины в менеджере Hyper-V Manager.
Для выбора и модификации компонентов (при помощи настроек виртуальной машины
в менеджере Hyper-V Manager) надо выполнить следующие шаги:
1. В панели Virtual Machines менеджера Hyper-V Manager щелкните правой кнопкой
мыши на виртуальной машине и выберите пункт Settings.
2. На странице Settings for выберите компонент в разделе Hardware или Management
(чтобы отобразить его подробности). Если вы хотите добавить новые компоненты
виртуального оборудования либо модифицировать компоненты типа выделения па-
мяти или процессоров виртуальной машины, то вы сможете сделать это только
в том случае, если виртуальная машина будет выключена.
3. Нажмите кнопку Apply для сохранения ваших изменений, а затем кнопку OK для
того, чтобы закрыть страницу настроек виртуальной машины.
Можно также эти модификации настроек виртуальной машины вывести в скрипт. В гла-
ве 16 вы узнаете о том, как разрабатывать скрипты при помощи Windows PowerShell.
Добавление устройств виртуального оборудования

По мере изменения потребностей рабочих нагрузок может возникнуть необходимость
модифицировать устройства виртуального оборудования (или добавить новые такие
устройства). Hyper-V поддерживает добавление синтетических устройств контроллера
SCSI и сетевого адаптера (которые не эмулируют физических устройств), а также

обычных сетевых адаптеров (эмуляция устройства Multiport DEC 21140). Hyper-V под-
держивает до четырех контроллеров SCSI, восемь синтетических сетевых адаптеров и
четыре обычных сетевых адаптера (для каждой виртуальной машины). Вы можете до-
бавить новое оборудование только тогда, когда виртуальная машина выключена.
Для добавления устройств виртуального оборудования выполните следующие шаги:
1. В панели Virtual Machines менеджера Hyper-V Manager убедитесь, что виртуальная
машина находится в состоянии Off, щелкните правой кнопкой мыши по виртуаль-
ной машине и выберите пункт Settings.
2. На странице Settings for выберите Add Hardware.
3. В правой панели выберите виртуальное устройство и нажмите кнопку Add.
4. Сконфигурируйте устройство (подключите виртуальный жесткий диск к контролле-
ру SCSI или настройте виртуальную сеть и прочие параметры для сетевого адап-
тера).
5. Нажмите кнопку OK, чтобы закрыть страницу настроек виртуальных машин.
Синтетические устройства вы сможете использовать только в том случае, если в гостевой
операционной системе виртуальной машины поддерживаются (и инсталлированы) службы
интеграции Integration Services. Когда вы инсталлируете службы интеграции, в хранилище
драйверов виртуальной машины копируются драйверы устройств (клавиатуры, мыши, ви-
део, систем хранения) и сетевые компоненты.
Конфигурирование настроек BIOS виртуальных машин

В Hyper-V есть только две настройки BIOS виртуальной машины, которые вы можете
изменять. Вы можете выбрать включение/выключение Num Lock и модифицировать
порядок начальной загрузки с устройств. В большинстве случаев единственное, что
вам нужно изменить, — это порядок загрузки.
Для модификации настроек BIOS виртуальных машин выполните следующие шаги:
2. На странице Settings for выберите BIOS.
3. В правой панели выберите Num Lock (чтобы убедиться, что этот режим включен
при загрузке гостевой операционной системы).
4. Если вы хотите изменить порядок загрузки с устройств, то используйте стрелки
вверх и вниз в разделе Startup Order.
5. Нажмите кнопку OK.
Порядок проверки загрузочных устройств на наличие операционной системы или за-
грузчика по умолчанию таков:
CD;
IDE;
обычный сетевой адаптер;

дисковод гибких дисков.
Если в дисководе CD не найден носитель, с которого можно загрузиться, то виртуаль-
ная машина начнет сканировать каналы виртуальной шины IDE в поисках загрузочного
диска. Виртуальная машина не может загрузиться с синтетического устройства SCSI,
поскольку драйверы синтетических устройств до загрузки гостевой операционной сис-
темы недоступны.
Изменение настроек памяти

В зависимости от требующейся производительности (которая зависит от таких требо-
ваний, как обслуживание большего количества пользователей или существенное уве-
личение количества рабочих транзакций) вам может понадобиться изменить настройку
памяти виртуальной машины. При пересмотре выделения памяти для виртуальной ма-
шины важно оценить, возможно ли выделение дополнительной памяти (исходя из ус-
тановленного на сервере Hyper-V количества физической памяти и требований других
виртуальных машин). Для настройки количества памяти виртуальной машины выпол-
2. На странице Settings for выберите Memory в разделе Hardware.
3. Введите новое значение в мегабайтах.
4. Нажмите кнопку Apply для сохранения ваших изменений, а затем кнопку OK.
В зависимости от количества инсталлированной на физическом сервере памяти и вы-
деления памяти под родительский раздел, менеджер Hyper-V Manager покажет вам
максимально доступное количество памяти (которое может быть выделено виртуаль-
ной машине). Если вы попытаетесь выделить больше этого количества, то сервер
Hyper-V выдаст ошибку, вроде показанной на рис. 11.32.
Рис. 11.32. Ошибка выделения памяти для виртуальной машины
Сервер Hyper-V не поддерживает чрезмерного выделения памяти или совместного ее ис-
пользования. Суммарное выделение памяти для виртуальных машин должно быть меньше,
чем общее количество инсталлированной на физическом сервере памяти.
Изменения процессорных настроек

Вы можете подстроить несколько процессорных настроек для виртуальной машины
(рис. 11.33). В зависимости от инсталлированной в виртуальной машине гостевой опе-
рационной системы вы можете выделить и использовать (для поддержки рабочих на-
грузок) до четырех виртуальных процессоров. Вы можете также указать управление
ресурсами (чтобы сбалансировать использование процессорных ресурсов виртуальны-
ми машинами). Кроме того, вы можете ограничить функциональность процессора (для
работы со старыми операционными системами типа Windows NT). По существу, огра-
ничение функциональности процессора не позволяет виртуальному процессору воз-
вращать коды тех функциональных возможностей, которые не поддерживаются ста-
рыми операционными системами (такими, как Windows NT).
Для изменения процессорных настроек выполните следующие шаги:
Рис. 11.33. Процессорные настройки виртуальной машины

2. На странице Settings for выберите Processor (в разделе Hardware).

3. Измените выделение процессоров, ресурсы и функциональность процессоров.
В главе 2 вы можете найти список поддерживаемых сервером Hyper-V гостевых операци-
онных систем, а также максимальное количество виртуальных процессоров, которое может
быть выделено каждой из них. Для того чтобы узнать дополнительные подробности по на-
стройке управления ресурсами процессора, см. разд. "Управление ресурсами процессора"
главы 7.
Изменение настроек виртуальных жестких дисков

Мастер New Virtual Machine Wizard в менеджере Hyper-V Manager позволяет опреде-
лить во время создания новой виртуальной машины только один виртуальный жесткий
диск. Однако для большинства рабочих нагрузок требуется два или более виртуальных
жестких диска — для разделения файлов гостевой операционной системы и файлов
данных приложений (для повышения уровня восстанавливаемости, безопасности и
производительности). К одной виртуальной машине может быть подключено макси-
мум 260 виртуальных жестких дисков (4 диска IDE и 256 дисков SCSI). Для загрузки с
виртуального жесткого диска он должен быть подключен к виртуальному контроллеру
IDE. Кроме того, вы можете также загрузить гостевую операционную систему, под-
ключенную при помощи транзитного диска. Транзитные диски позволяют виртуальной
машине получить доступ к физическому диску, который сопоставлен непосредственно
серверу Hyper-V, но не имеет сконфигурированного тома. Транзитные диски также
позволяют вам превзойти предельный размер виртуального жесткого диска в
2040 Гбайт.
Для того чтобы узнать о конфигурировании транзитных дисков, см. главу 5.
Для подключения дополнительных виртуальных жестких дисков (или транзитных дис-

ков) к виртуальной машине (при помощи виртуального контроллера SCSI) выполните
2. Если в виртуальной машине уже инсталлирован виртуальный адаптер SCSI, то для
подключения нового виртуального жесткого диска вы можете использовать именно
его и перейти прямо к пункту 4.
3. Для инсталляции в виртуальной машине нового виртуального адаптера SCSI выбе-
рите Add Hardware в разделе Hardware левой панели, выберите в правой панели
SCSI Controller, а затем нажмите кнопку Add.
4. В левой панели выберите новый контроллер SCSI, который добавился в раздел
Hardware.
5. В правой панели нажмите кнопку Add для подключения нового виртуального жест-
кого диска к виртуальному контроллеру SCSI.
6. В правой панели выберите для подключения нового виртуального жесткого диска
одну из 64 позиций (при помощи раскрывающегося списка Location), как это пока-
зано на рис. 11.34.
Рис. 11.34. Выберите позицию для подключения нового виртуального жесткого диска
7. Для создания нового виртуального жесткого диска (для подключения его к вирту-
альному контроллеру SCSI) нажмите кнопку New в разделе Media правой панели.
Запустится мастер New Virtual Hard Disk Wizard, который позволит вам создать ди-
намически расширяющийся, фиксированный или разностный виртуальный жесткий
диск. По завершении работы мастера нажмите кнопку Apply для сохранения ваших
изменений, а затем нажмите кнопку OK.
8. Если вы хотите указать уже существующий виртуальный жесткий диск, то введите
полный путь к тому каталогу, где он хранится (либо нажмите кнопку Browse для то-
го, чтобы использовать Windows Explorer для перехода к нужному каталогу). После
того как вы все это закончите, нажмите кнопку Apply для сохранения ваших изме-
нений, а затем кнопку OK.
9. Если вы хотите указать транзитный диск, то обратитесь к описанной в главе 5 про-
цедуре подготовки диска и подключения его к серверу Hyper-V. Затем выберите
транзитный диск в раскрывающемся списке Physical hard disk в разделе Media.
После того как вы все это закончите, нажмите кнопку Apply для сохранения ваших
изменений, а затем кнопку OK.
Если вы не можете найти транзитный диск в раскрывающемся списке Physical hard disk,
то откройте приложение Disk Management и убедитесь в том, что диск находится в авто-
номном режиме.
Если вы хотите просмотреть тип, местоположение, текущий и максимальный размеры

виртуального жесткого диска, выберите Inspect Disk в панели Actions менеджера
Hyper-V Manager. Диалоговое окно Windows Explorer позволит вам перейти к местопо-
ложению нужного виртуального жесткого диска. После того как вы выберете вирту-
альный жесткий диск, в диалоговом окне Virtual Hard Disk Properties будут показаны
свойства этого диска.
Общий обзор типов виртуальных жестких дисков см. в главе 2. Если вам нужна подробная
информация по использованию разностных дисков и прочих расширенных функциональных
возможностей виртуальных жестких дисков, обратитесь к главе 5.
Изменение настроек виртуального дисковода DVD

При создании новой виртуальной машины ко вторичному виртуальному каналу IDE
подключается виртуальный дисковод DVD. По умолчанию виртуальному дисководу
DVD не сопоставляется никакой носитель. Сервер Hyper-V позволяет сконфигуриро-
вать в виртуальной машине до 4 виртуальных дисководов DVD (используя для этого
все виртуальные каналы IDE). Помните, что для добавления или удаления виртуальных
дисководов DVD виртуальная машина должна быть выключена.
Виртуальному DVD можно также сопоставить физический дисковод CD/DVD или
стандартный образ ISO 9660. В состав поставки Hyper-V входит один основной ISO-
образ Vmguest.iso (для поддержки инсталляции служб интеграции Integration Services).
Если виртуальному дисководу DVD сопоставлен ISO-образ операционной системы, то
виртуальную машину можно загрузить и инсталлировать с этого дисковода, что снижа-
ет время инсталляции (вследствие высокой скорости доступа к образу ISO).
Для создания и подключения дополнительного дисковода DVD к виртуальной машине
ной машине и выберите Settings.
2. Для добавления нового виртуального дисковода DVD выберите целевой виртуаль-
ный контроллер IDE (с номером 0 или 1) в разделе Hardware левой панели.
3. В правой панели выберите DVD Drive в разделе IDE Controller, а затем нажмите
кнопку Add.
4. В разделе DVD Drive в правой панели у вас есть такие варианты:
• если вы не хотите немедленно сопоставить виртуальному DVD-дисководу физи-
ческий дисковод или образ ISO, вам следует выбрать None;
• выбрать Image File и ввести полный путь к образу ISO;
• выбрать Physical CD/DVD Drive, а затем выбрать физический дисковод (в рас-
крывающемся списке).
Изменение настроек
виртуального сетевого адаптера
Виртуальная машина создается с одним виртуальным сетевым адаптером. Однако в
виртуальную машину можно добавить до четырех обычных сетевых адаптеров. Кроме
того, если в гостевой операционной системе инсталлированы службы интеграции, то
вы сможете добавить в виртуальную машину до восьми синтетических сетевых адап-
теров. Сервер Hyper-V динамически присваивает уникальный МАС-адрес (по умолча-
нию это адрес из диапазона 00-15-5D-xx-xx-xx) каждому виртуальному сетевому адап-
теру, что позволяет каждому из этих адаптеров подключаться к одной из имеющихся
виртуальных сетей.
Подробности об управлении МАС-адресами в сервере Hyper-V см. в разд. "Пулы МАС-
адресов" главы 5.
Сервер Hyper-V поддерживает три типа виртуальных сетей: внешние, внутренние и

частные (рис. 11.35). Внешняя виртуальная сеть позволяет вести обмен с внешними
физическими сетями. Внутренняя виртуальная сеть позволяет вести обмен между вир-
туальными машинами одного и того же сервера Hyper-V и с самим сервером Hyper-V.
Частная виртуальная сеть позволяет вести обмен только между теми виртуальными
машинами, которые работают на одном сервере Hyper-V.
Например, если вы хотите импортировать несколько производственных серверов в ра-
ботающие на одном сервере Hyper-V виртуальные машины (без риска передачи данных
через производственную сеть), то используйте частную или внутреннюю сеть и под-
ключите к ней все виртуальные машины (при помощи виртуальных сетевых адапте-
ров). Если вы должны распространять виртуальные машины по многим серверам
Hyper-V, то создайте внешнюю виртуальную сеть, которая будет подключена к физи-
ческим сетевым адаптерам всех серверов Hyper-V. Физические сетевые адаптеры
должны быть подключены к изолированной физической сети (чтобы данные не пере-
давались по производственной сети). Затем подключите все виртуальные машины к
внешней виртуальной сети (чтобы обеспечить объединение сетей). Сервер Hyper-V
поддерживает неограниченное количество виртуальных сетей, что позволяет достичь
гибкости при настройке сетевых подключений виртуальных машин.
Рис. 11.35. Варианты виртуальных сетей
Дополнительную информацию по движению данных по внешним, внутренним и частным
сетям вы можете получить в главе 5.
Помимо добавления или удаления виртуальных сетевых адаптеров и модификации ти-

па виртуальной сети (к которой подключен виртуальный сетевой адаптер), вы можете
указать: присваивать ли динамический или статический МАС-адрес, а также использо-
вать ли идентификатор (VLAN ID) для виртуальной LAN.
Если вас интересуют подробности реализации VLAN в сервере Hyper-V, обратитесь к гла-
ве 3 за описанием сетевой архитектуры Hyper-V и к главе 5 за описанием функциональных
возможностей VLAN.
Для создания, подключения и модификации дополнительных сетевых адаптеров в вир-

туальной машине выполните следующие шаги:
Рис. 11.36. Выбор устройств для добавления в вашу виртуальную машину
2. Для инсталляции нового виртуального сетевого адаптера в виртуальной машине

выберите Add Hardware в разделе Hardware левой панели.
3. В правой панели у вас есть следующие варианты (рис. 11.36):
• для инсталляции синтетического виртуального сетевого адаптера выберите
Network Adapter, а затем нажмите кнопку Add. Несмотря на то, что, возможно,
вы и сможете добавить синтетический виртуальный сетевой адаптер, помните
о том, что виртуальная машина может использовать этот вариант только в том
случае, если для гостевой операционной системы поддерживаются службы инте-
грации Integration Services;
• для инсталляции эмулированного виртуального сетевого адаптера выберите
Legacy Network Adapter, а затем нажмите кнопку Add.
4. В разделе Network Adapter в правой панели выберите виртуальную сеть для под-
ключения при помощи раскрывающегося списка Network (рис. 11.37).
5. Укажите, следует ли использовать динамический либо статический МАС-адрес.
Если вы выбираете Static, то введите МАС-адрес.
Рис. 11.37. Выберите виртуальную сеть для подключения
Убедитесь, что этот статический МАС-адрес в вашей сети не используется. В противном
случае после загрузки гостевой операционной системы вы получите ошибку дублированно-
го МАС-адреса.
6. Если вы хотите указать идентификатор VLAN ID, то вам необходимо установить

флажок Enable virtual LAN identification, а затем ввести его в разделе VLAN ID.
Изменение настроек виртуальных СОМ-портов

Для обмена с виртуальной машиной через именованные каналы имеются два виртуаль-
ных СОМ-порта. По умолчанию виртуальные СОМ-порты конфигурируются без вся-
ких к ним подключений. В общем случае виртуальный СОМ-порт подключается к
именованному каналу для обмена с отладчиком ядра. На сервере Hyper-V вы не можете
подключить виртуальный СОМ-порт к физическому СОМ-порту. Более того, вирту-
альные СОМ-порты нельзя удалить из конфигурации виртуальной машины.
В табл. 11.3 описаны имеющиеся в Hyper-V настройки виртуального СОМ-порта.
Таблица 11.3. Настройки виртуального СОМ-порта
Настройка Описание
None Это установка по умолчанию для новой виртуальной машины, которая гарантирует
отсутствие подключенного к виртуальному СОМ-порту устройства
Named Pipe Эта настройка позволяет установить соответствие между виртуальным СОМ-портом
и именованным каналом на физическом хосте (либо на подключенном к той же сети
удаленном хосте)
Для конфигурирования настроек виртуального СОМ-порта выполните следующие шаги:

2. На странице Settings for (рис. 11.38) в разделе Hardware выберите СОМ 1 или
СОМ 2.
Рис. 11.38. Раздел Hardware страницы Settings for

3. В правой панели у вас есть следующие варианты:

• если вы не хотите подключать СОМ-порт к какому-либо устройству, выберите
None;
• выберите Named pipe и укажите название канала.
Изменение настроек
виртуального дисковода гибких дисков
При создании виртуальной машины конфигурируется один дисковод для гибких дис-
ков (без всякого сопоставления носителей). Аналогично виртуальным СОМ-портам,
виртуальный дисковод гибких дисков нельзя удалить из виртуальной машины и нельзя
добавить в нее дополнительные дисководы для гибких дисков. Виртуальный дисковод
для гибких дисков можно сопоставить только с образом виртуального гибкого диска
(vfd). Записываемый образ виртуального гибкого диска можно сопоставить только од-
ной виртуальной машине. Однако доступ к образу "только для чтения" виртуального
гибкого диска можно осуществлять из нескольких виртуальных машин. Hyper-V под-
держивает образы гибких дисков размером 720 Кбайт и 1,44 Мбайт, но создавать обра-
зы может только в формате 1,44 Мбайт.
Для изменения сопоставлений виртуального дисковода гибких дисков выполните сле-
2. На странице Settings for в разделе Hardware выберите Diskette Drive.
3. В правой панели у вас есть следующие варианты:
• если вы не хотите настроить сопоставление с образом гибкого диска, выберите
None;
• если вы хотите настроить сопоставление с образом гибкого диска, выберите
Virtual floppy disk (.vfd) file. Затем введите полный путь к образу гибкого диска
или нажмите кнопку Browse для того, чтобы при помощи Windows Explorer ука-
зать нужный файл.
Сервер Hyper-V имеет один пустой образ гибкого диска, который вы можете найти в
%SystemDrive%\Users\Public\Documents\Hyper-V\Blank floppy disk.vfd.
Изменение имени виртуальной машины

Если вы сделали ошибку в названии виртуальной машины или хотите изменить его
(для приведения в соответствие с новым стандартом именования), то выполните сле-

мыши по виртуальной машине и выберите пункт Rename.
2. Введите новое название в поле Name, а затем нажмите клавишу <Enter>.
3. Новое название виртуальной машины немедленно появится в менеджере Hyper-V
Manager.
Выполнение этого действия изменит только название виртуальной машины. Все назва-
ния файлов конфигурации, моментальных снимков и сохраненных состояний сохранят
свои основанные на GUID значения. Название виртуального жесткого диска также не
изменится.
Вы можете также изменить название виртуальной машины и в настройках виртуальной
машины. На странице Settings for выберите Name в разделе Management и введите новое
название в правой панели. Вы можете также внести примечания о виртуальной машине,
которые будут отображаться в менеджере Hyper-V Manager после выбора этой виртуальной
машины.
Модификация настроек служб интеграции

Как описано в табл. 5.6, сервер Hyper-V предоставляет службы интеграции для множе-
ства поддерживаемых гостевых операционных систем. Для использования служб инте-
грации вы сначала должны инсталлировать их в гостевой операционной системе. Даже
если гостевая операционная система поддерживает данный конкретный компонент
служб интеграции, вы можете модифицировать тот набор служб, который предлагается
виртуальной машине.
Для конфигурирования предлагаемых виртуальной машине служб интеграции выпол-
мыши по виртуальной машине и выберите пункт Settings.
2. На странице Settings for выберите Integration Services в разделе Management
(рис. 11.39).
3. В правой панели установите или сбросьте флажки предлагаемых служб интегра-
ции.
Если вы инсталлируете новое обновление сервера Hyper-V, которое устанавливает новую
версию компонента служб интеграции, то вы должны инсталлировать его в каждой вирту-
альной машине, чтобы получить эффект от улучшений, сделанных в драйверах устройств и
в производительности служб.
Рис. 11.39. Опции служб интеграции Integration Services
Модификация местоположения файлов

моментальных снимков
По умолчанию моментальные снимки виртуальной машины хранятся в %SystemDrive%
\ProgramData\Microsoft\Windows\Hyper-V. Однако Hyper-V позволяет вам указать дру-
гое место хранения (для каждой виртуальной машины).
Для настройки местоположения хранения моментальных снимков виртуальной маши-
ны выполните следующие шаги:
2. На странице Settings for выберите Snapshot File Location в разделе Management.
3. В правой панели введите полный путь к каталогу или нажмите кнопку Browse, что-
бы использовать Windows Explorer для указания каталога.
После выполнения первого моментального снимка виртуальной машины вам уже не

разрешается изменять местоположение файлов моментальных снимков (рис. 11.40).
Рис. 11.40. Местоположение файлов моментальных снимков виртуальной машины
Подробности о реализации моментальных снимков виртуальных машин и о их создании на
сервере Hyper-V см. в главе 5.
Модификация действий при автоматическом запуске

По умолчанию новая виртуальная машина конфигурируется на автоматический запуск
при перезапуске сервера Hyper-V (если она работала в тот момент, когда сервер Hyper-V
выключали). Вы можете изменить это действие — отменить запуск или указать авто-
матический запуск всегда. Кроме того, вы можете указать также и задержку запуска
(для уменьшения состязания за ресурсы при автоматическом запуске множества вирту-
альных машин после включения сервера Hyper-V). Для изменения действия при авто-
матическом запуске виртуальной машины выполните следующие шаги:
2. На странице Settings for выберите Automatic Start Action в разделе Management.
3. В разделе Automatic Start Action у вас есть следующие варианты:
• если вы не хотите, чтобы виртуальная машина перезапускалась автоматически,
выберите Nothing;
• если вы хотите, чтобы виртуальная машина автоматически перезапускалась (ес-
ли она работала в момент выключения сервера Hyper-V), то выберите
Automatically start if it was running when the service stopped;
• если вы хотите, чтобы виртуальная машина автоматически перезапускалась не-
зависимо от ее состояния в момент выключения сервера Hyper-V, выберите
Always start this virtual machine automatically.
4. Если вы выбрали один из вариантов автоматического перезапуска, то укажите за-
держку запуска (если одновременно запускается много виртуальных машин). По
умолчанию задержка равна 0 секунд, и все сконфигурированные таким образом
виртуальные машины перезапустятся (примерно) в тот же самый момент, когда
службы Hyper-V перейдут в оперативное состояние.
Если вы указываете задержку автоматического перезапуска для многих виртуальных ма-
шин, скорректируйте ее значения. Например, если вы конфигурируете три виртуальные
машины, то укажите задержку автоматического перезапуска 0 секунд для первой машины,
20 секунд для второй и 40 секунд для третьей. Конечно, вы должны подстроить эти значе-
ния в зависимости от времени запуска каждой виртуальной машины. Реальное значение
времени перезапуска изменится также в случае запуска виртуальной машины из сохранен-
ного состояния.
Модификация действий
при автоматическом останове виртуальной машины
Вы можете также указать действие при автоматическом останове виртуальной маши-
ны. Действие по умолчанию — сохранить состояние виртуальной машины при выклю-
чении питания сервера Hyper-V. Этот вариант позволяет виртуальной машине переза-
пуститься из сохраненного состояния с минимальной задержкой. В этой конфигурации
Hyper-V записывает и сохраняет в файлы информацию состояния виртуальной машины
(такую, как регистры процессора) и содержимое памяти. Информация состояния вир-
туальной машины сохраняется в двоичном файле, который получает название по тому
же идентификатору GUID, что и файл конфигурации виртуальной машины, но имеет
расширение bin. Содержащиеся в этих двух файлах данные используются для переза-
грузки содержимого процессора и памяти при перезапуске виртуальной машины из
сохраненного состояния.
Для изменения действия при автоматическом останове виртуальной машины выполни-

те следующие шаги:
2. На странице Settings for выберите Automatic Start Action в разделе Management.
3. В разделе Automatic Stop Action у вас есть следующие варианты:
• если вы хотите при выключении сервера Hyper-V записать информацию состоя-
ния в файлы, выберите вариант Save the virtual machine state;
• для выключения виртуальной машины при выключении сервера Hyper-V выбе-
рите вариант Turn off the virtual machine;
• если в виртуальной машине инсталлированы службы интеграции и вы хотите,
чтобы виртуальная машина завершила свой останов до выключения питания
сервера Hyper-V, то выберите вариант Shutdown the guest operating system.
Возможно, вы захотите избежать использования опции Turn off the virtual machine,
поскольку это равнозначно выдергиванию шнура питания на физическом компьютере
и может привести к повреждению данных.
Если у вас есть необходимость перемещать виртуальные машины между серверами Hyper-V,
то вам следует реализовать миграцию Quick Migration с использованием функции Failover
Clustering. Для переноса виртуальных машин между серверами Hyper-V можно также ис-
пользовать функции импорта и экспорта сервера Hyper-V.
Дополнительную информацию по миграции Quick Migration, а также функциям импорта и
экспорта виртуальных машин см. в главах 5 и 2 соответственно.
ВНИМАНИЕ!
Нельзя перенести виртуальную машину в сохраненном состоянии с сервера Virtual Server
2005 R2 (или с Virtual PC) на сервер Hyper-V. Нельзя также перенести виртуальную машину
в сохраненном состоянии между серверами Hyper-V с разными архитектурами процессоров
(такими, как AMD-V и Intel VT). Несмотря на то, что некоторые файлы виртуальных машин
(такие, как виртуальные жесткие диски (vhd)) совместимы для серверов Virtual Server и
Hyper-V (а также между серверами Hyper-V), файлы сохраненного состояния (vsv, bin) со-
вместимыми не являются.
Дополнительную информацию по процессу миграции виртуальных машин с сервера Virtual
Server 2005 R2 на сервер Hyper-V см. в главе 8.
Удаление виртуальной машины

Для полного удаления с сервера Hyper-V виртуальной машины и соответствующих ее
файлов требуются два шага. Во-первых, вы удаляете информацию конфигурации вир-
туальной машины при помощи менеджера Hyper-V Manager. Этот шаг не удаляет ни-
каких файлов виртуальной машины (за исключением символической ссылки, которая
указывает на файл конфигурации виртуальной машины). Таким образом предотвраща-
ется ошибочное удаление файлов виртуальной машины с сервера Hyper-V. Если вы
уверены, что вам больше не нужна виртуальная машина на сервере Hyper-V, то вы
должны вручную удалить все соответствующие файлы (после удаления виртуальной
машины).
Для удаления виртуальной машины с сервера Hyper-V выполните следующие шаги:
мыши по виртуальной машине и выберите пункт Delete.
2. После удаления символической ссылки название виртуальной машины больше не
отображается в панели Virtual Machines менеджера Hyper-V Manager.
3. Если вы хотите удалить все файлы виртуальной машины, откройте Windows
Explorer, перейдите к каталогу виртуальной машины и вручную удалите файлы.
Перед удалением в менеджере Hyper-V Manager виртуальной машины она должна быть
выключена или находиться в сохраненном состоянии.
Символические ссылки на конфигурационные файлы виртуальной машины создаются в
%SystemDrive%\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines. Это каталог по
умолчанию для хранения на сервере Hyper-V конфигурационных файлов виртуальной ма-
шины.
Инсталляция гостевой операционной системы

Обычно виртуальная машина не предоставляет никаких полезных служб до тех пор,
пока на ней не будет сконфигурирована рабочая нагрузка, состоящая из операционной
системы и одного или нескольких приложений. Инсталляция операционной системы в
виртуальной машине похожа на процесс инсталляции для физического компьютера.
Операционная система виртуальной машины может быть инсталлирована с использо-
ванием оригинального носителя, инструмента создания образов, ISO-образа или при
помощи PXE-инсталляции. В табл. 11.4 перечислены требования виртуальной машины
ко всем этим методам инсталляции.
Таблица 11.4. Опции инсталляции гостевой операционной системы

Оригинальный Виртуальному дисководу DVD должен быть сопоставлен дисковод физического
носитель хоста, содержащий оригинальный носитель
Инструмент Виртуальному дисководу DVD должен быть сопоставлен дисковод физического
создания образов хоста, содержащий образ диска CD. Или виртуальная машина создается с
использованием виртуального жесткого диска, который был подготовлен при
помощи инструмента System Preparation (Sysprep)
Образ ISO Виртуальному дисководу DVD должен быть сопоставлен файл образа ISO
PXE-инсталляция Виртуальная машина должна выполнить PXE-загрузку для подключения либо
к службам Windows Deployment Services (WDS), либо к инструменту миграции
физического компьютера на виртуальный (P2V), либо к другой сетевой службе
инсталляции. Этот вариант поддерживается только обычными виртуальными
сетевыми адаптерами
Если операционную систему необходимо устанавливать с нуля, используйте ISO-образ,

сохраненный по возможности на диске хоста (вместо оригинального носителя). Ин-
сталляция операционной системы с ISO-образа (сопоставленного дисководу DVD вир-
туальной машины) гораздо быстрее, чем инсталляция с оригинального носителя. Кроме
того, если вы многократно собираетесь развертывать одну и ту же конфигурацию опе-
рационной системы, используйте инструмент Sysprep для создания базового виртуаль-
ного жесткого диска, который вы сможете копировать и многократно использовать для
быстрого предоставления новых виртуальных машин. Утилита Sysprep подготавливает
операционную систему для распространения, для этого она запускает процедуру на-
Рис. 11.41. Выберите дисковод DVD, используемый для инсталляции гостевой операционной системы
стройки при следующей загрузке, что избавляет от проблем с идентификатором безо-

пасности (SID) и дублированием названия компьютера. Sysprep следует использовать
только после того, как операционная система была обновлена, были установлены
службы интеграции, а также все основные приложения.
Совместимый с сервером Windows Server 2008 инструмент Sysprep инсталлируется авто-
матически и находится в %SystemDrive%\Windows\System32\Sysprep\Sysprep.exe.
Вот основные шаги инсталляции операционной системы в виртуальной машине с ис-

пользованием ISO-образа (в предположении, что имеется один виртуальный диско-
вод DVD):
2. На странице Settings for выберите виртуальный дисковод DVD в разделе Hardware
(рис. 11.41).
3. В разделе DVD Drive правой панели отметьте переключатель Image file и введите
полный путь к файлу ISO-образа.
Рис. 11.42. Начало инсталляции операционной системы

мыши по виртуальной машине и выберите пункт Start.
6. Щелкните по контрольному изображению виртуальной машины (для запуска при-
ложения Virtual Machine Connection и подключения к консоли виртуальной машины).
7. После того как виртуальная машина загрузится и начнется процесс настройки, вы-
полните нормальную инсталляцию операционной системы (рис. 11.42).
Инсталляция служб интеграции

После того как конфигурация гостевой операционной системы виртуальной машины
будет завершена, вам следует инсталлировать службы интеграции. Integration
Services — это целый набор улучшений производительности, интеграции и функцио-
нальности, который инсталлируется в гостевую операционную систему виртуальной
машины. Производительность ввода/вывода виртуальной машины значительно увели-
чивается тогда, когда стандартные драйверы гостевой операционной системы заменя-
ются специфичными для виртуальных машин обновлениями драйверов мыши, клавиа-
туры, видео, сети и контроллеров SCSI. Службы интеграции время от времени обнов-
ляются, поэтому очень важно включить эти обновления в состав ваших процедур
обслуживания (чтобы использовать новейшие версии драйверов по мере их появ-
ления).
Службы интеграции можно инсталлировать в виртуальной машине при помощи со-
держащего компоненты служб интеграции образа Vmguest.iso, который сопоставляется
виртуальному дисководу DVD (либо при помощи скрипта инсталляции).
Для инсталляции служб интеграции Integration Services при помощи приложения
Virtual Machine Connection выполните следующие шаги:
мыши по виртуальной машине и выберите пункт Connect.
2. Зарегистрируйтесь на виртуальной машине при помощи учетной записи с правами
локального администратора.
3. В меню Action приложения Virtual Machine Connection выберите пункт Insert
Integration Services Setup Disk (рис. 11.43).
4. Выберите Install Hyper-V Integration Services в диалоговом окне AutoPlay
(рис. 11.44) и нажмите клавишу <Enter>.
5. В диалоговом окне Upgrade Hyper-V Integration Services нажмите кнопку OK.
6. При появлении запроса нажмите кнопку Yes для перезапуска виртуальной машины.
Содержащий службы интеграции файл Vmguest.iso находится на сервере Hyper-V в катало-
ге %SystemDrive%\Windows\System32.
Рис. 11.43. Выберите Insert Integration Services Setup Disk
Рис. 11.44. Выберите Install Hyper-V Integration Services

Управление состоянием виртуальной машины

В табл. 11.5 содержится список опций, которые имеются в Hyper-V для изменения со-
стояния виртуальной машины. Имеющиеся опции во всех случаях зависят от сущест-
вующего состояния виртуальной машины. Во избежание разрушения или потери дан-
ных, а также прерываний в обслуживании (которые могут быть вызваны несовмести-
мостями с приложениями или службами виртуальной машины), очень важно понимать
состояния виртуальной машины и пути перехода между ними. Для изменения состоя-
ния виртуальной машины щелкните правой кнопкой мыши по виртуальной машине
в менеджере Hyper-V Manager, а затем выберите соответствующее действие.
Таблица 11.5. Опции управления состоянием виртуальной машины
Состояние Описание
Start Включить виртуальную машину или включить виртуальную машину и восстановить ее

к состоянию в момент сохранения
Turn Off Выключить виртуальную машину без сохранения информации состояния. Это равно-
значно выдергиванию шнура питания физического компьютера
Shut Down Завершить работу гостевой операционной системы, имитировав чистый останов
физического компьютера
Save Сохранить текущее состояние виртуальной машины в файлы (vsv, bin) и остановить ее
работу. Это позволяет восстановить виртуальную машину в то состояние, в котором
она находилась в момент сохранения
Pause Приостановить работу виртуальной машины, сохранив текущее состояние памяти
Resume Возобновить работу виртуальной машины в том состоянии, в котором она находилась
в момент приостановки
Reset Сброс виртуальной машины. Это равнозначно нажатию кнопки Reset на физическом
компьютере
Например, сконфигурированную в качестве контроллера домена виртуальную машину

не следует переводить в сохраненное состояние, а затем восстанавливать. Перевод ба-
зы данных Active Directory (после ее сохранения) в оперативное состояние может при-
вести к повреждению базы данных и к сбоям репликации, которые могут иметь серьез-
ные последствия для целостности домена и леса Active Directory. Любым приложением
с временными зависимостями транзакций следует управлять очень осторожно (во из-
бежание серьезных проблем с целостностью данных, вызванных некорректной приос-
тановкой или выключением виртуальной машины и возобновлением ее работы по ис-
течении значительного промежутка времени).
Обновление виртуальных машин

При составлении процедур обновления и обслуживания физических компьютеров не-
обходимо учитывать и виртуальные машины. Это гарантирует наличие на виртуальных
машинах новейших наборов обновлений. Управление обновлениями можно выполнять
несколькими разными способами: при помощи компакт-диска с обновлениями и
скриптом инсталляции, при помощи специальных инструментов управления вроде

Microsoft Windows Server Update Service (WSUS), посредством обычных инструментов
вроде System Center Configuration Manager (SCCM) и других аналогичных приложений.
Одновременное обновление множества виртуальных машин (на одном сервере Hyper-V)
может снизить производительность обновляемых машин, что увеличит время инсталляции
обновлений, а также снизит количество доступных рабочим нагрузкам ресурсов. Во избе-
жание проблем с производительностью планируйте обновления виртуальных машин сер-
вера Hyper-V таким образом, чтобы они выполнялись последовательно.
Выполнение резервного копирования

и восстановления сервера Hyper-V
Сервер Windows Server 2008 предоставляет решение для резервного копирования и
восстановления под названием Windows Server Backup (WSB). Это приложение ис-
пользует (для выполнения обычных в среде предприятия операций резервного копиро-
вания и восстановления) службу Volume Shadow Copy Service (VSS). В частности, WSB
обеспечивает поддержку резервного копирования и восстановления для операционной
системы, томов, каталогов и файлов сервера. Кроме того, WSB поддерживает операции
резервного копирования и восстановления для ролей и приложений (которые имеют
совместимый с VSS модуль записи), и в том числе для роли Hyper-V.
Инсталляция Windows Server Backup

Windows Server Backup — это функциональная возможность сервера Windows Server
2008 и поэтому по умолчанию она не инсталлируется. Для инсталляции Windows Server
Backup и конфигурирования ее для поддержки сервера Hyper-V выполните следующие
шаги:
1. Откройте менеджер Server Manager и выберите Features (в левой панели).
2. В правой панели диалогового окна Features Summary щелкните по пункту Add
Features.
3. На странице Select Features мастера Add Features Wizard (рис. 11.45) разверните
узел Windows Server Backup Features.
4. В узле Windows Server Backup Features установите флажок Windows Server
Backup. По желанию вы можете также выбрать и Command-Line Tools.
5. По завершении ваших настроек нажмите кнопку Next.
6. На странице Confirm Installation Selections (рис. 11.46) просмотрите сделанные ва-
ми настройки, а затем нажмите кнопку Install.
Сервер Windows Server 2008 инсталлирует Windows Server Backup для MMC, инстру-
мент командной строки (для резервного копирования) Wbadmin.exe, а также соответст-
вующие службы. Если вы укажете также и инсталляцию инструментов Command-Line
Рис. 11.45. Выберите Windows Server Backup Features
Рис. 11.46. На странице Confirm Installation Selections просмотрите сделанные вами настройки
Tools for Windows Server Backup, то вы сможете планировать резервное копирование

(и управлять им) при помощи скриптов Windows PowerShell.
Конфигурирование Windows Server Backup

для поддержки Hyper-V
Приложение Windows Server Backup поддерживает модули записи VSS для ролей и
приложений, но оно не может автоматически импортировать или регистрировать но-
вые модули записи VSS. Поэтому вы должны сделать это вручную. Для конфигуриро-
вания в Windows Server Backup модуля записи VSS для Hyper-V вы должны модифи-
цировать реестр Windows Server Backup и зарегистрировать идентификатор GUID мо-
дуля записи VSS для Hyper-V. Вы можете сделать это при помощи редактора реестра
Registry Editor или при помощи reg-файла.
Определение идентификатора GUID модуля записи VSS для Hyper-V

Для регистрации модуля записи VSS для Hyper-V вам нужно определить идентифика-
тор GUID модуля записи VSS для Hyper-V. Инструмент командной строки Volume
Shadow Copy Service Administrative (VSSAdmin.exe) может дать список инсталлирован-
ных на сервере Hyper-V модулей записи VSS, а также их идентификаторы GUID. Для
выявления идентификатора GUID модуля записи VSS для Hyper-V при помощи
VSSAdmin выполните следующие шаги:
1. Откройте командную строку (при помощи варианта Run As Administrator).
2. В командной строке введите VSSadmin list Writers >C:\temp\VSSWriters.txt.
3. Через несколько секунд в текстовый файл C:\Temp\VSSWriters.txt будет выведен
список всех инсталлированных и зарегистрированных в службе VSS модулей
записи.
4. Откройте файл C:\Temp\VSSWriters.txt и найдите GUID модуля записи VSS для
Hyper-V (поиском по строке Microsoft Hyper-V VSS Writer).
5. Убедитесь, что идентификатор GUID модуля записи VSS для Hyper-V равен
66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE.
Модификация реестра при помощи редактора реестра

Registry Editor (REGEDIT)
Для модификации реестра при помощи редактора Regedit выполните следующие шаги:
2. В командной строке введите Regedit.
3. В редакторе Registry Editor найдите ключ: HKEY_LOCAL_MACHINE\Software
\Microsoft\Windows NT\CurrentVersion\WindowsServerBackup.
4. Если этот ключ не существует, щелкните правой кнопкой мыши по ключу
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion и выбе-
рите последовательно New | Key.
5. Введите WindowsServerBackup в качестве названия ключа и нажмите клавишу

<Enter>.
6. Щелкните правой кнопкой мыши по ключу WindowsServerBackup, выберите New |
Key.
7. Введите Application Support в качестве названия ключа и нажмите клавишу
<Enter>.
8. Щелкните правой кнопкой мыши по ключу Application Support, выберите New |
Key.
9. Введите {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} в качестве названия ключа и на-
жмите клавишу <Enter>.
10. Щелкните правой кнопкой мыши по ключу {66841CD4-6DED-4F4B-8F17-
FD23F8DDC3DE} (рис. 11.47), выберите New | String Value для создания строки
REG_SZ. Введите Application Identifier в качестве названия значения и установи-
те это значение в Hyper-V VSS Writer.
ВАЖНО
При модификации реестра соблюдайте осторожность. Повреждение реестра может при-
вести к нестабильности работы системы и вызвать отказ загрузки операционной системы.
Рис. 11.47. Выберите ключ в редакторе Registry Editor

Модификация реестра при помощи reg-файла

Если вам нужно выполнить модификацию реестра на множестве серверов, или если вы
хотите минимизировать возможные ошибки, то можете создать reg-файл и импортиро-
вать его в реестр сервера Hyper-V. Вы можете создать reg-файл при помощи стандарт-
ного текстового редактора (такого, как Notepad). Если вы уже сделали модификацию
реестра на сервере Hyper-V, то можете экспортировать ключ реестра и создать
reg-файл.
Для создания reg-файла путем экспортирования его из реестра существующего сервера
Hyper-V выполните следующие шаги:
2. В командной строке введите Regedit.
3. В редакторе Registry Editor найдите и щелкните правой кнопкой мыши по ключу:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
\WindowsServerBackup.
4. Выберите пункт Export, введите название для reg-файла, а затем нажмите кнопку
Save.
5. Закройте редактор Registry Editor.
6. Откройте reg-файл и убедитесь, что он содержит следующие ключи и значения:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
\WindowsServerBackup]
\WindowsServerBackup\Application Support]
\WindowsServerBackup\Application Support\{66841CD4-6DED-4F4B-8F17-
FD23F8DDC3DE}] "Application Identifier"="Hyper-V VSS Writer"
После создания reg-файла вы можете скопировать его на другой сервер Hyper-V, ин-
сталлировать Windows Server Backup, щелкнуть правой кнопкой мыши по reg-файлу и
выбрать пункт Merge для импорта новых ключей в реестр сервера Hyper-V.
Соображения относительно приложения

Windows Server Backup
При создании плана резервного копирования сервера Hyper-V с использованием
Windows Server Backup вы должны учитывать следующее:
для сохранения конфигурационной информации сервера Hyper-V и хранилища
Authorization Manager (%SystemDrive%\ProgramData\Microsoft\Windows\Hyper-V
\InitialStore.xml) вы должны сделать резервную копию системного диска;
вы не можете делать резервные копии отдельных виртуальных машин; вы можете

делать резервное копирование только томов сервера Hyper-V;
вы должны сделать копии всех томов, которые содержат файлы и данные виртуаль-
ных машин. Если же вы храните файл конфигурации виртуальной машины отдель-
но от файлов виртуальных жестких дисков, то вы должны сделать резервные копии
обоих томов (чтобы иметь возможность восстановить виртуальную машину);
когда вы выполняете операцию восстановления, то должны выбрать восстановление
на основе приложения.
Восстановление виртуальной машины при помощи Windows Server Backup — это опе-
рация по принципу "все или ничего". Вы не можете восстановить отдельные файлы
виртуальной машины — только виртуальную машину целиком. После восстановления
виртуальных жестких дисков виртуальной машины вы можете подключить их к другой
виртуальной машине (или исходной виртуальной машине) и извлечь нужные файлы.
Резервное копирование виртуальной машины в оперативном режиме возможно только для
тех гостевых операционных систем, которые поддерживают модуль записи VSS для Hyper-V
из служб интеграции. Поэтому резервное копирование в оперативном режиме можно вы-
полнять для Windows Server 2008, Windows Server 2003 и Windows Vista. Виртуальные ма-
шины Windows 2000 Server и Windows XP не поддерживают резервное копирование с ис-
пользованием служб Volume Shadow Copy Services.
Резервное копирование виртуальной машины

при помощи Windows Server Backup
Для конфигурирования резервного копирования виртуальной машины с использовани-
ем Windows Server Backup выполните следующие шаги:
1. Откройте консоль Windows Server Backup (рис. 11.48). Вы можете сделать это в
Administrative Tools.
2. В панели Actions выберите пункт Backup Schedule.
3. На странице Getting started мастера Backup Schedule Wizard (рис. 11.49) нажмите
кнопку Next.
4. На странице Select backup configuration (рис. 11.50) выберите Custom, а затем на-
5. На странице Select backup items (рис. 11.51) выберите те тома, которые содержат
файлы виртуальных машин. По умолчанию выбраны системные тома.
6. После выполнения всех ваших настроек нажмите кнопку Next.
7. На странице Specify backup time у вас есть следующие варианты (рис. 11.52):
• выберите Once a day и укажите время начала резервного копирования;
• выберите More than once a day и укажите несколько резервных копий.
8. После выполнения всех настроек нажмите кнопку Next.
9. На странице Select destination disk (рис. 11.53) нажмите кнопку Show All Available
Disks, а затем выберите диск для хранения ваших резервных копий.
Рис. 11.48. Консоль Windows Server Backup
Рис. 11.49. Мастер Backup Schedule Wizard

Рис. 11.50. Страница Select backup configuration
Рис. 11.51. Страница Select backup items

Рис. 11.52. Указание времени резервного копирования
Рис. 11.53. Страница Select destination disk


11. Здесь вы можете получить предупреждение, что выбранные диски будут перефор-
матированы и все существующие на них тома будут удалены. Нажмите кнопку Yes
для подтверждения.
12. На странице Label destination disk нажмите кнопку Next (рис. 11.54).
Рис. 11.54. Страница Label destination disk
13. На странице Confirmation просмотрите сделанные вами настройки и нажмите

кнопку Finish.
14. На странице Summary нажмите кнопку Close.
15. Перезапустите сервер Hyper-V.
Восстановление виртуальной машины

при помощи Windows Server Backup
Для восстановления виртуальной машины при помощи Windows Server Backup выпол-
1. Откройте консоль Windows Server Backup.
2. В панели Actions выберите пункт Recover.
3. На странице Getting started мастера Recovery Wizard (рис. 11.55) отметьте пере-
ключатель This server, а затем нажмите кнопку Next.
Рис. 11.55. Страница Getting started мастера Recovery Wizard
4. На странице Select backup date выберите резервную копию (рис. 11.56), а затем на-
Рис. 11.56. Страница Select backup date

5. На странице Select recovery type (рис. 11.57) отметьте переключатель Applications,

6. На странице Select application (рис. 11.58) выберите Hyper-V.
Рис. 11.57. Страница Select Recovery Type
Рис. 11.58. Страница Select application

7. Нажмите кнопку View Details, чтобы получить список виртуальных машин и кон-
фигурационную информацию Hyper-V, которая записана в резервной копии. При-
мер списка показан на рис. 11.59.
Рис. 11.59. Просмотрите список виртуальных машин и информацию конфигурации
8. Нажмите кнопку OK, а затем кнопку Next.

9. На странице Specify recovery options у вас есть следующие варианты (рис. 11.60):
• если вы хотите использовать исходные местоположения, выберите Recover to
original location;
Рис. 11.60. Страница Specify recovery options

• если вы не хотите использовать исходные местоположения, выберите Recover

to another location.
11. На странице Confirmation (рис. 11.61) просмотрите сделанные вами настройки и
нажмите кнопку Recover.
Рис. 11.61. Страница Confirmation мастера Recovery Wizard
Рис. 11.62. Состояние восстановления ресурсов

12. Приложение Windows Server Backup начинает процесс восстановления и выдает

состояние для каждого восстанавливаемого ресурса (рис. 11.62).
13. Когда восстановление на странице Recovery progress будет закончено (рис. 11.63),
нажмите кнопку Close.
Рис. 11.63. По завершении восстановления закройте мастер Recovery Wizard
Наблюдение за состоянием
и производительностью сервера Hyper-V
Как описано в главе 10, вы можете наблюдать за состоянием и производительностью
сервера Hyper-V при помощи приложения Reliability and Performance Monitor, которое
инсталлируется по умолчанию вместе с сервером Windows Server 2008. Наблюдение за
производительностью сервера Hyper-V, виртуальных машин и их нагрузок является
критичным аспектом обслуживания вашей виртуализированной инфраструктуры. На-
блюдение за производительностью помогает вам делать следующее:
понять профили рабочих нагрузок и тенденции использования ресурсов (чтобы пла-
нировать мощность);
определить — как настроить ресурсы для повышения производительности рабочих
нагрузок;
диагностировать проблемы и выявлять их составляющие.
Стандартные инструменты измерения производительности (такие, как Performance
Monitor) и более сложные приложения (такие, как System Center Operations Mana-
ger 2007) могут отслеживать производительность как виртуализированных, так и физи-

ческих ресурсов.
Вам следует наблюдать вашу виртуализированную инфраструктуру при помощи тех же
самых методов и процедур, которые вы используете в вашей физической среде. Для
оценки изменений производительности вы можете использовать данные по производи-
тельности физических рабочих нагрузок (собранные до миграции физического сервера
на виртуальную машину). При помощи этих данных вы можете определить — нужно
ли выделить для рабочей нагрузки виртуальной машины дополнительные ресурсы;
нужно ли ее перенести на сервер Hyper-V с более мощными процессорами, большим
количеством памяти и более емкими системами хранения; и в очень редких случаях —
стоит ли мигрировать данную нагрузку обратно (из виртуальной машины на физиче-
ский сервер).
Для того чтобы больше узнать об основных счетчиках производительности (которые могут
помочь вам оценить производительность памяти, процессора, сети и дисков), обрати-
тесь к MSDN-статье "Measuring Performance on Hyper-V", доступной по ссылке:
http://msdn.microsoft.com/en-us/library/cc768535.aspx. Несмотря на то, что она посвяще-
на работе сервера BizTalk на Hyper-V, эта информация имеет широкое применение.
Резюме
Вы можете управлять сервером Hyper-V локально или при помощи удаленной рабочей
станции управления. Для удаленного управления сервером вы должны сконфигуриро-
вать и сервер Hyper-V, и рабочую станцию. Скрипт HVRemote может быть очень поле-
зен для автоматизации конфигурирования сервера Hyper-V и удаленной рабочей стан-
ции управления (особенно в сложных ситуациях со многими доменами или рабочими
группами). Для управления настройками Hyper-V и виртуальными машинами исполь-
зуйте менеджер Hyper-V Manager. Перед созданием виртуальной машины убедитесь,
что вы задали основные параметры конфигурации. После создания новой виртуальной
машины перед инсталляцией гостевой операционной системы вы должны настроить
конфигурацию тех виртуальных компонентов, которые не были указаны при создании.
Если вы хотите удалить виртуальную машину насовсем, то вы должны вручную уда-
лить соответствующие файлы (поскольку сервер Hyper-V автоматически их не удаля-
ет). Для инсталляции операционной системы в виртуальной машине существует не-
сколько способов, но мы рекомендуем использовать ISO-образы (это повышает произ-
водительность инсталляции). Если планируются повторные развертывания, то следует
использовать утилиту Sysprep и подготовить виртуальный жесткий диск для дублиро-
вания и быстрой подготовки новых виртуальных машин.
После конфигурирования операционной системы инсталлируйте службы интеграции
Integration Services (чтобы улучшить производительность и функциональность вирту-
альных машин). Разберитесь, как сконфигурировать и использовать Windows Server
Backup для резервного копирования и восстановления виртуальных машин. При по-
мощи Windows Server Backup вы можете сделать резервную копию всей виртуальной
машины, однако возможности копировать отдельные файлы виртуальной машины нет.
И наконец, вы можете использовать монитор Reliability and Performance Monitor для

оценки производительности вашего сервера Hyper-V и планирования его мощности,
а также для реализации предупредительных мер (с целью обеспечения достаточного
количества физических ресурсов для поддержки рабочих нагрузок виртуальных
машин).
Дополнительные ресурсы
Следующие ресурсы содержат дополнительную информацию по темам этой главы:
статья KB952627, "Description of the Windows Vista Service Pack 1 Management Tools
update for the release version of Hyper-V", доступная по ссылке:
http://support.microsoft.com/kb/952627;
материал на Web-сайте Microsoft MSDN с названием "Hyper-V Remote Management
Configuration Utility", доступный по ссылке:
http://code.msdn.microsoft.com/HVRemote.
ГЛАВА 12
Управление фермой серверов
Для управления фермой серверов Hyper-V требуется такое решение, которое позволит
вам видеть отдельные компоненты фермы серверов (хосты, виртуальные машины, со-
вместно используемые библиотеки), а также и их ресурсы в едином интерфейсе. Ме-
неджер System Center Virtual Machine Manager (SCVMM) 2008 — это решение компа-
нии Microsoft для управления фермой серверов. SCVMM предоставляет возможность
просмотра сервера Hyper-V (или фермы серверов Hyper-V), чтобы понять имеющиеся
на хосте проблемы производительности и масштабируемости. SCVMM также предос-
тавляет возможность просмотра всех виртуальных машин всех серверов (чтобы вы
могли принять решения по балансировке нагрузки). Данная глава описывает, как ис-
пользовать SCVMM 2008 для управления фермой серверов Hyper-V.
Инсталляция менеджера
System Center Virtual Machine Manager 2008
Для того чтобы вы могли разобраться в использовании менеджера System Center Virtual
Machine Manager 2008 для управления фермой серверов Hyper-V, вам нужно иметь ин-
сталляцию этого менеджера для работы с ним. SCVMM 2008 состоит из множества
компонентов, которые сообща обеспечивают единый консольный интерфейс.
Компоненты SCVMM включают:
сервер Virtual Machine Manager (VMM);
консоль Virtual Machine Manager Administrator Console;
библиотеку Virtual Machine Library;
портал Virtual Machine Manager Self-Service Portal;
базу данных Virtual Machine Manager;
интерфейс Virtual Machine Manager Windows PowerShell;
отчетность Virtual Machine Manager Reporting.
Сервер VMM — это основной структурный блок, который собирает информацию по
ферме серверов и управляет ею. Консоль VMM Administrator Console — это пользова-
тельский интерфейс для сервера VMM, который позволяет вам видеть все ресурсы
SCVMM и управлять ими. Библиотека VMM Library хранит все используемые для под-
готовки новых виртуальных машин объекты. Портал Self-Service Portal обеспечивает
Web-интерфейс, который позволяет пользователю удаленно управлять работающими
на ферме серверов виртуальными машинами (без необходимости знать, на каком
именно сервере Hyper-V они работают). База данных VMM предоставляет важную ин-
формацию о конфигурации фермы серверов, имеющихся в библиотеке объектах, а
также о данных наблюдения. Интерфейс VMM Windows PowerShell — это тот интер-
фейс прикладного программирования, на котором основан сервер VMM, он предостав-
ляет также мощное ядро для скриптов и автоматизированного управления. VMM
Reporting — это интерфейс между SCVMM 2008 и менеджером System Center
Operations Manager 2007 (для оптимизации ресурсов по производительности и управ-
ления ими).
Опции инсталляции
Все компоненты менеджера System Center Virtual Machine Manager 2008 могут быть
либо инсталлированы на одном сервере, либо распределены по нескольким серверам
(в зависимости от нагрузки и требований). Инсталляция на одном сервере рекоменду-
ется при количестве хостов до 20 штук, распределенная же инсталляция компонентов
SCVMM была протестирована при работе с 400 хостами.
Для установки сервера VMM, консоли Administrative Console, портала Self-Service
Portal и интерфейса отчетности требуется выполнить отдельные процедуры установки
(как при инсталляции на одном сервере, так и при распределенной инсталляции). Для
инсталляции сервера VMM необходимо установить также библиотеку VMM Library и
интерфейс Windows PowerShell. Если вы укажете использование версии SQL Server
2005 Express, то база данных VMM будет инсталлирована для вас автоматически (либо
вы можете инсталлировать SQL до инсталляции SCVMM 2008).
Требования к программному и аппаратному обеспечению

Для инсталляции SCVMM 2008 в любой его конфигурации (для одиночного сервера
или распределенной) вам нужно сначала инсталлировать оборудование и подготовить
программное обеспечение. Для инсталляции одиночного сервера перед инсталляцией
SCVMM необходимо предварительно инсталлировать все необходимые программные
компоненты. Для распределенной инсталляции компонентов предварительно нужно
инсталлировать то программное обеспечение, которое требуется для этого компонента.
Требования к программному обеспечению

В табл. 12.1 дана разбивка по программному обеспечению, которое необходимо для
инсталляции на одном сервере, а также требования к программному обеспечению при
инсталляции в распределенном режиме. Требования к программному обеспечению для
инсталляции на одном сервере предполагают, что вы хотите иметь все компоненты
SCVMM на одном сервере (в том числе и интеграцию с менеджером System Center
Operations Manager).
Глава 12. Управление фермой серверов 461
Таблица 12.1. Требования к программному обеспечению для отдельного сервера

и распределенной инсталляции
Режим Инсталлированные
Требуемое программное обеспечение
инсталляции компоненты
На одном • Сервер Virtual Machine • Windows Server 2008 x64 версии Standard,
сервере Manager (VMM) Enterprise или Datacenter
• Библиотека Virtual Machine • Microsoft .NET Framework 3.0
Library
• Windows PowerShell 1.0
• Консоль Virtual Machine
Manager Administrator Console • Windows Automated Installation Kit (WAIK) 1.1
(требуется для миграций P2V)
• Портал Virtual Machine
Manager Self-Service Portal • Локальный или удаленный SQL Server 2005
SP2 или SQL Server 2008 (версии Express,
• База данных Virtual Machine Standard или Enterprise)
Manager
• Internet Information Server (IIS)
• Интерфейс Virtual Machine
Manager Windows PowerShell • Operations Manager 2007 SP1
• Отчетность Virtual Machine • Operations Manager 2007 SP1 Reporting Server

Manager Reporting
• Агент Operations Manager 2007 SP1 на всех
хостах, за которыми вы хотите наблюдать
• System Center Virtual Machine Manager 2008
Management Pack для Operations Manager 2007
(требуется для PROTips)
Распре- Сервер Virtual Machine Manager • Windows Server 2008 x64 версии Standard,
деленная (VMM) Enterprise или Datacenter
инсталляция
• Microsoft .NET Framework 3.0
• Windows PowerShell 1.0
• Windows Automated Installation Kit (WAIK) 1.1
Библиотека Virtual Machine • Windows Server 2008 x64 версии Standard,
Library Enterprise или Datacenter
• Windows Server 2003 (или R2) с SP2
Консоль Virtual Machine • Windows Server 2008 x64 версии Standard,
Manager Administrator Console Enterprise или Datacenter
• Windows Vista SP1
• Windows XP SP2
Портал Virtual Machine Manager • Windows Server 2008 x64 версии Standard,
Self-Service Portal Enterprise или Datacenter
• Internet Information Server (IIS)
База данных Virtual Machine • SQL Server 2005 SP2 версии Express,
Manager
• Standard или Enterprise
• SQL Server 2008 версии Express, Standard
или Enterprise
Режим Инсталлированные
Требуемое программное обеспечение
инсталляции компоненты
Отчетность Virtual Machine • Operations Manager 2007 SP1

Manager Reporting
• Operations Manager 2007 SP1 Reporting Server
• Агент Operations Manager 2007 SP1 на всех
хостах, за которыми вы хотите наблюдать
• System Center Virtual Machine Manager 2008
Management Pack для Operations
Manager 2007
• SQL Server 2005 SP2 версии Standard или
Enterprise
• SQL Server 2008 версии Standard или
Enterprise
Требования к оборудованию
Далее в таблицах даны рекомендуемые требования к оборудованию для варианта ин-
сталляции на одном сервере и варианта распределенной инсталляции компонентов.
Требования к оборудованию для инсталляции

на одном сервере
Для инсталляции на одном сервере при повышении количества управляемых хостов
требуется больше памяти и процессорных ресурсов. При количестве управляемых хос-
тов больше 150 потребуются дополнительные аппаратные ресурсы. В табл. 12.2 дан
список требований к оборудованию (для инсталляции на одном сервере).
Таблица 12.2. Требования к оборудованию (инсталляция на одном сервере)
Аппаратный
Минимально рекомендуется
компонент
Процессор • Два двухъядерных процессора х64 с частотой 2 ГГц или больше

(при количестве управляемых хостов до 150)
• Два двухъядерных процессора х64 с частотой 3,6 ГГц или больше
(при количестве управляемых хостов более 150)
Память • 4 Гбайт (при количестве хостов до 150)
• 8 Гбайт (при количестве хостов более 150)
Объем жестких • 50 Гбайт (при использовании (по умолчанию) локальной инсталляции сервера
дисков Microsoft SQL Server 2005 Express Edition)
• 40 Гбайт (при использовании удаленной базы данных SQL Server 2005)
• 80 Гбайт (при использовании сервера VMM как сервера библиотеки)
Сеть Гигабитный Ethernet
Требования к оборудованию
для распределенной инсталляции
При распределении компонентов по нескольким серверам получается максимально
производительная и масштабируемая инфраструктура SCVMM. За это придется пла-
тить увеличенным количеством управляемых систем и оборудования.
Основным распределенным компонентом инфраструктуры SCVMM является сервер
Virtual Machine Manager (VMM). Это необходимый компонент распределенной инфра-
структуры SCVMM. При масштабировании сервера VMM для большого количества
хостов рекомендуется инсталлировать базу данных и библиотеку на разные серверы.
В табл. 12.3 показана минимальная рекомендуемая конфигурация оборудования для
сервера VMM на 150 и более хостов.
Таблица 12.3. Требования к оборудованию для компонентов сервера VMM
компонент
Процессор • Два двухъядерных процессора х64 с частотой 2 ГГц или больше

• Два двухъядерных процессора х64 с частотой 3,6 ГГц или больше
Объем жестких • 50 Гбайт (при использовании (по умолчанию) локальной инсталляции сервера
дисков Microsoft SQL Server 2005 Express Edition) — до 150 хостов
• 50 Гбайт при более чем 150 хостах; базу данных и библиотеку разместите
на других серверах
Еще один важный распределенный компонент инфраструктуры SCVMM — консоль

Administrative Console. Это необходимый компонент распределенной инфраструктуры
SCVMM. Рекомендуется инсталлировать консоль Administrative Console на сервер
VMM или на рабочую станцию удаленного администрирования. Для использования
отчетности SCVMM Reporting надо инсталлировать консоль Administrative Console на
сервер VMM. Если вам нужны дополнительные выделенные административные консо-
ли, используйте рекомендации по оборудованию из табл. 12.4, в которой приведена
минимальная рекомендуемая конфигурация для административной консоли.
Таблица 12.4. Требования к оборудованию для консоли Administrative Console
компонент
Процессор • Процессор Pentium 4 с частотой 2 ГГц (х64) или больше

• Двухъядерный процессор с частотой 3,6 ГГц (х64) или больше
компонент
Объем жестких • 2 Гбайт (при количестве хостов до 150)
дисков
Сервер библиотеки обеспечивает хранение файловых объектов, которые раздаются

серверам Hyper-V (виртуальные машины, виртуальные жесткие диски, образы ISO,
скрипты). Сервер VMM имеет по умолчанию свою совместно используемую библиоте-
ку, но в некоторых ситуациях вы захотите иметь дополнительные серверы библиотек.
Например, выделение отдельного совместно используемого ресурса под библиотеку
для сервера, который управляет более чем 150 хостами, позволит разгрузить его от
дискового ввода/вывода. Другой пример — сервер Hyper-V в филиале компании, когда
вы хотите инсталлировать локальный сервер библиотеки, чтобы предоставлять ресур-
сы библиотеки локально (вместо передачи их через глобальную сеть WAN). Серверы
библиотек должны быть расположены как можно ближе к тем хостам, которые они
обеспечивают виртуальными машинами. Это приведет к повышению количества сер-
веров библиотек в тех средах, где хосты географически разбросаны.
Таблица 12.5 содержит минимально рекомендуемое оборудование для выделенного
сервера библиотеки.
Таблица 12.5. Требования к оборудованию для сервера библиотеки
компонент
Процессор Двухъядерный процессор с частотой 3,2 ГГц (х64)
Память 2 Гбайт
Объем жестких Зависит от количества хранящегося в совместно используемом ресурсе
дисков библиотеки содержимого:
• виртуальные жесткие диски;
• виртуальные гибкие диски;
• образы ISO;
• скрипты;
• хранящиеся виртуальные машины
Портал Self-Service Portal — это необязательный компонент, который позволяет поль-

зователям создавать собственные виртуальные машины и управлять ими; либо предос-
тавляет администраторам серверов возможность при помощи Web-интерфейса удален-
но управлять работающими в виртуальных машинах операционными системами. Web-

портал использует описанные в SCVMM 2008 пользовательские роли, которые опреде-
ляют область действий пользователя (с их собственными виртуальными машинами).
Кроме того, Web-портал может быть ограничен в управлении только теми виртуаль-
ными машинами, которые находятся на определенной группе хостов Hyper-V.
В табл. 12.6 содержатся рекомендации по минимальной конфигурации оборудования
для выделенных серверов порталов Self-Service Portal.
Таблица 12.6. Требования к оборудованию портала Self-Service Portal
компонент
Процессор • Один двухъядерный процессор (х64) с частотой 3,2 ГГц (при количестве
одновременных пользователей до 10 человек)
• Два двухъядерных процессора (х64) с частотой 3,2 ГГц (при количестве
одновременных пользователей более 10 человек)
Память • 4 Гбайт (при количестве одновременных пользователей до 10 человек)
• 8 Гбайт (при количестве одновременных пользователей более 10 человек)
Объем жестких • 20 Гбайт (при количестве одновременных пользователей до 10 человек)
дисков
• 40 Гбайт (при количестве одновременных пользователей более 10 человек)
Сеть • Один гигабитный Ethernet (при количестве одновременных пользователей
до 10 человек)
• Два гигабитных Ethernet (при количестве одновременных пользователей
более 10 человек)
База данных Virtual Machine Manager хранит всю информацию по конфигурации VMM,
информацию библиотеки и информацию по состоянию заданий. Для базы данных
VMM требуется сервер Microsoft SQL Server 2005 SP2 (или более новая версия). Вы
можете указать в этом качестве локальный или удаленный экземпляр существующей
базы данных Microsoft SQL Server или позволить мастеру Setup Wizard инсталлировать
на сервер VMM базу данных SQL Server 2005 Express Edition SP2. Несмотря на то, что
VMM поддерживает использование SQL Server 2005 Express Edition SP2, при управле-
нии более чем 150 хостами или при интеграции с Operations Manager 2007 рекоменду-
ется использовать версию SQL Server 2005 SP2 Standard или Enterprise. В табл. 12.7
содержится минимально рекомендуемая конфигурация оборудования для выделенного
сервера базы данных VMM.
Таблица 12.7. Требования к оборудованию сервера базы данных
компонент
Процессор • Два двухъядерных процессора (х64) с частотой 2 ГГц или больше

• Два двухъядерных процессора (х64) с частотой 3,6 ГГц или больше
компонент

Объем жестких • 150 Гбайт (при количестве хостов до 150)
дисков
Компонент отчетности SCVMM 2008 Reporting — это интерфейс между инсталляцией

менеджера System Center Operations Manager 2007 и сервером VMM. Компонент System
Center Operations Manager Reporting может быть уже существующей инсталляцией
System Center Operations Manager, либо при ее отсутствии вы можете инсталлировать
выделенную инфраструктуру System Center Operations Manager. В табл. 12.8 содержит-
ся минимальная рекомендуемая конфигурация оборудования для выделенных серверов
VMM Reporting.
Таблица 12.8. Требования к оборудованию сервера VMM Reporting
Аппаратный компонент Минимально рекомендуется

Процессор Два двухъядерных процессора с частотой 3,6 ГГц (х64) или более
Память 4 Гбайт или более
Объем жестких дисков 100 Гбайт или более
Пошаговая инсталляция
В этом разделе мы выполним пошаговую инсталляцию SCVMM 2008 на одном серве-
ре. Мы сосредоточимся на инсталляции самого SCVMM и не будем рассматривать ин-
сталляцию требующегося для него программного обеспечения. Однако перед выпол-
нением наших указаний вам нужно будет сделать следующее:
активировать Windows PowerShell;
инсталлировать Windows Automation Installation Kit (WAIK) для Windows
Server 2008;
инсталлировать роль Web Server (IIS), если вам нужен локальный портал Self-
Service Portal;
инсталлировать SQL Server 2005 SP2 (рекомендуется для управления фермой сер-
веров).
Инсталляция SQL Server 2005 SP2 на отдельном от VMM сервере даст повышение
производительности.
Оценка имеющейся конфигурации

Перед началом инсталляции SCVMM 2008 вы должны убедиться, что выполнены
предварительные требования. SCVMM 2008 имеет анализатор конфигурации
Configuration Analyzer, который вы можете использовать для проверки инсталляции и
правильной настройки всех необходимых компонентов. SCVMM Configuration
Analyzer — это надстройка для анализатора Microsoft Baseline Configuration Analyzer
(MBCA), которая предоставляет для МВСА все подлежащие анализу требования и со-
общает об аномалиях конфигурации.
Как МВСА, так и SCVMM 2008 Configuration Analyzer можно скачать с сайта Microsoft
Download Center по ссылке: http://www.microsoft.com/downloads/en/default.aspx.
SCVMM 2008 Configuration Analyzer можно использовать для сканирования локально-

го или удаленного компьютера (для проверки соблюдения предварительных требова-
ний любой роли SCVMM). Для анализа сервера на соблюдение выполнения всех пред-
варительных требований для инсталляции SCVMM 2008 выполните следующие шаги:
1. Выполните последовательно Start | All Programs | Virtual Machine Manager
Configuration Analyzer | Configuration Analyzer.
2. В разделе названий ролей VMM и компьютеров укажите те роли VMM, которые вы
хотите оценить, и введите названия тех компьютеров, которые вы хотите проскани-
ровать.
3. После указания всех ролей или функций VMM и названий компьютеров нажмите
кнопку Scan.
4. После завершения сканирования вы получите отчет, в котором будут представлены
подробности по всем обнаруженным проблемам. Перед инсталляцией VMM 2008
необходимо эти проблемы устранить.
Когда вы сканируете локальный компьютер, то анализатор SCVMM 2008 Configuration
Analyzer использует учетные данные той записи, под которой вы зарегистрированы на нем
(это должна быть запись локального администратора). Для сканирования локального ком-
пьютера другие учетные данные использовать нельзя.
Когда вы сканируете удаленный компьютер, то анализатор SCVMM 2008 Configuration

Analyzer использует учетные данные той записи, под которой вы зарегистрированы (если
вы не указали в разделе Credentials других данных). Учетными данными для удаленного
компьютера должна быть такая доменная учетная запись, которая имеет права локального
администратора на удаленном компьютере.
Инсталляция компонента Virtual Machine Manager Server

Для инсталляции компонента SCVMM 2008 VMM выполните следующие шаги:
1. Зарегистрируйтесь на компьютере под учетной записью администратора домена.
2. Вставьте диск DVD с сервером SCVMM 2008 и запустите Setup.
3. На начальном экране в разделе Setup щелкните по пункту VMM Server (рис. 12.1).
Процедура установки скопирует некоторые необходимые для инсталляции времен-
ные файлы, а затем запустит мастер инсталляции.
Рис. 12.1. Начальный экран инсталляции SCVMM 2008
4. На странице License Terms выберите вариант I accept the terms of this agreement и
5. На странице Customer Experience Improvement Program выберите вариант и на-
6. На странице Product Registration задайте информацию о пользователе и организа-
ции и нажмите кнопку Next.
7. На странице Prerequisites Check убедитесь, что все предварительные требования
выполнены, а затем нажмите кнопку Next. Если вам необходимо решить проблему с
каким-то предварительным требованием, то сделайте изменение, а затем вернитесь
на страницу Prerequisite Check и нажмите кнопку Check Again.
8. На странице Installation Location убедитесь в том, что путь для инсталляции задан
верно, и нажмите кнопку Next.
9. На странице SQL Server Settings (рис. 12.2) задайте название сервера SQL (или
localhost в случае локального компьютера), выберите экземпляр SQL и задайте на-
звание существующей базы данных (либо поставьте флажок для создания новой).
После указания всех необходимых опций нажмите кнопку Next.
Рис. 12.2. Страница SQL Server Settings мастера инсталляции SCVMM 2008
10. На странице Library Share Settings укажите вариант создания нового совместно
используемого ресурса Library и нажмите кнопку Next.
11. На странице Installation Settings (рис. 12.3) вы можете модифицировать порты по
умолчанию для консоли, агентов и передачи файлов, а также изменить сервисную
учетную запись для VMM; после этого нажмите кнопку Next.
Запишите все сделанные вами изменения номеров портов, поскольку они понадобятся вам
при инсталляции дополнительных компонентов.
12. На странице Summary of Settings просмотрите сделанные вами настройки, а затем

нажмите кнопку Install для запуска инсталляции сервера SCVMM 2008.
13. Во время инсталляции вы будете видеть состояние каждого инсталлируемого ком-
понента, а также состояние всей инсталляции. После завершения процесса инстал-
ляции вы получите сообщение о его успехе или неудаче. По окончании просмотра
страницы состояния инсталляции нажмите кнопку Close.
Теперь вы можете перейти к инсталляции консоли Administrative Console.
Рис. 12.3. Страница Installation Settings
Инсталляция консоли Administrative Console

для менеджера Virtual Machine Manager
После инсталляции сервера VMM вы можете перейти к инсталляции консоли
Administrative Console. Эта консоль является основным интерфейсом, который админи-
страторы SCVMM используют для управления фермой серверов Hyper-V.
Для инсталляции консоли SCVMM 2008 VMM Administrative Console выполните сле-
1. На начальном экране инсталляции Virtual Machine Manager 2008 (см. рис. 12.1)
в разделе SETUP щелкните по варианту VMM Administrator Console.
2. Файлы инсталляции будут скопированы на сервер. На странице License Terms вы-
берите вариант I accept the terms of this agreement и нажмите кнопку Next.
3. На странице Customer Experience Improvement Program (CEIP) обратите внима-
ние на то, как можно выйти из CEIP, и нажмите кнопку Next.
4. На странице Prerequisites Check убедитесь в том, что все предварительные требо-
вания выполнены, и нажмите кнопку Next. Если вам нужно решить проблему с ка-
ким-то предварительным требованием, то вы должны произвести необходимые
изменения, а затем вернуться на страницу Prerequisite Check и нажать кнопку

Check Again.
5. На странице Installation Location убедитесь в том, что путь указан правильно, и
6. На странице Port Assignments модифицируйте (при желании) порты по умолчанию
для консоли, а затем нажмите кнопку Next.
7. На странице Summary Of Settings просмотрите сделанные вами настройки и на-
жмите кнопку Install для начала инсталляции консоли Administrative Console для
SCVMM 2008.
Теперь вы можете перейти к инсталляции портала Self-Service Portal.
Инсталляция портала Self-Service Portal

для менеджера Virtual Machine Manager
После инсталляции консоли VMM Administrative Console вы можете перейти к инстал-
ляции портала Self-Service Portal. Этот портал — основной интерфейс, который адми-
нистраторы и конечные пользователи используют для управления принадлежащими им
виртуальными машинами (работающими на ферме серверов Hyper-V).
Для инсталляции портала Self-Service Portal выполните следующие шаги:
1. На начальном экране инсталляции (см. рис. 12.1) в разделе SETUP щелкните по ва-
рианту VMM Self-Service Portal.
2. Файлы инсталляции будут скопированы на сервер. На странице License Terms вы-
берите вариант I accept the terms of this agreement и нажмите кнопку Next.
3. На странице Prerequisites Check убедитесь в том, что все предварительные требо-
вания выполнены и нажмите кнопку Next. Если вам нужно решить проблему с ка-
ким-то предварительным требованием, то вы должны произвести необходимые из-
менения, а затем вернуться на страницу Prerequisite Check и нажать кнопку Check
Again.
4. На странице Installation Location убедитесь в том, что путь указан правильно,
и нажмите кнопку Next.
5. На странице Web Server Settings проверьте полное доменное имя сервера VMM,
измените (при необходимости) значения по умолчанию для портов консоли
Administrative Console, модифицируйте порт консоли портала Self-Service, а затем
Если Web-сайт по умолчанию использует порт 80 и вы не модифицировали значе-
ния по умолчанию, то вы получите показанную на рис. 12.4 ошибку. Либо измените
используемый Web-порт, либо настройте заголовок хоста на продолжение исполь-
зования порта 80.
Рис. 12.4. Ошибка инсталляции порта Web-сайта портала Self-Service Portal
6. На странице Summary Of Settings просмотрите сделанные вами настройки и на-

жмите кнопку Install для того, чтобы начать инсталляцию портала Self-Service Portal
для SCVMM 2008.
Обновления Hyper-V
После выпуска Hyper-V были сделаны исправления некоторых ошибок и выполнены неко-
торые улучшения. TechNet — это отличный ресурс, который отслеживает все обновления,
вы можете найти их все в одном месте по ссылке: http://technet.microsoft.com/en-
us/library/dd430893.aspx.
Для управления сервером Hyper-V с сервера SCVMM 2008 требуются, по меньшей мере,
два обновления:
• KB956589 — исправление проблемы, возникающей при обмене между агентом SCVMM
2008 и сервером SCVMM;
• KB956774 — исправление проблемы со службой Background Intelligent Transfer Services
(BITS), которая не позволяет инсталляции агента SCVMM Agent закончиться неудачей.
KB956774 следует инсталлировать на сервере Hyper-V до добавления хоста в SCVMM
2008. KB956589 следует инсталлировать на сервере Hyper-V после добавления хоста
в SCVMM 2008 и инсталляции агента. До инсталляции KB956589 статус сервера Hyper-V
будет отображаться в консоли SCVMM 2008 как Needs Attention.
Брион Сурэйс (Bryon Surace, Senior Program Manager (Windows Virtualization))
Управление фермой серверов

Фермы серверов создаются для предоставления консолидированного набора ресурсов,
которым можно управлять как единым ресурсом. Это дает масштабируемость и про-
стоту управления. Управление фермой серверов Hyper-V при помощи SCVMM 2008
требует определенного планирования (чтобы установить соответствие между возмож-
ностями SCVMM 2008 и необходимыми сценариями управления). Чаще всего фермы
серверов Hyper-V нужны в центрах обработки данных, тестовых лабораториях, средах
разработки программного обеспечения, а также для предоставления виртуальных рабо-
чих столов. Несмотря на то, что в каждом из этих сценариев участвует пул серверов
Hyper-V, способы их конфигурирования и управления отличаются. Сочетание сценария

управления и требований делегирования определяет количество необходимых серверов
SCVMM 2008. На рис. 12.5 показана начальная страница консоли VMM Administrator
Console при ее первом запуске. Вы можете считать ее чистым холстом, который вы
подстроите под требования своего сценария управления.
Рис. 12.5. Консоль VMM Administrator Console
Типы управляемых хостов

SCVMM 2008 может управлять хостами под управлением сервера Virtual Server 2005
R2 SP1, роли Hyper-V сервера Windows Server 2008, сервера Microsoft Hyper-V Server
2008, а также хостами ESX (через Virtual Center). Эти хосты должны быть в одной из
следующих конфигураций:
сервер Windows в домене Active Directory, который связан двусторонними довери-
тельными отношениями с доменом Active Directory сервера SCVMM 2008;
сервер Windows, который находится в домене Active Directory, не имеющем дву-
сторонних доверительных отношений с доменом Active Directory сервера
SCVMM 2008;
сервер Windows в демилитаризованной зоне;
сервер Windows, находящийся в непересекающемся пространстве имен (когда пол-

ное доменное имя хоста (FQDN), разрешенное при помощи DNS, не совпадает с тем
именем, которое получено из Active Directory);
хост VMware ESX Server, расположенный в любом месте вашей среды.
Для управления хостом ESX он должен быть под управлением центра VMware Virtual
Center. Для управления хостом ESX вам нужно добавить сервер Virtual Center, после чего
все управляемые этим сервером хосты добавляются и автоматически распределяются по
группам (в соответствии с иерархией сервера). Серверы VMware ESX должны оставаться
внутри своей родительской группы хостов (или потомка этой группы хостов). Если в даль-
нейшем в сервере Virtual Center добавляется новое определение центра обработки данных,
то он появляется в консоли SCVMM Administrative Console как новая группа хостов (после
следующего обновления сервера VMware VirtualCenter Server).
Управление хостами
Перед тем как вы сможете начать управление своим первым сервером Hyper-V, вы
должны зарегистрировать его на сервере SCVMM 2008 (чтобы на нем можно было ин-
сталлировать агента VMM). Агент получает инструкции и команды с сервера VMM из
консоли Administrative Console, либо команды SCVMM из Windows PowerShell (и вы-
полняет их на сервере Hyper-V). Эти инструкции могут быть какими угодно — от мо-
дификации настроек сервера Hyper-V и до создания виртуальных машин и управления
ими.
Процесс регистрации сервера Hyper-V выполняется при помощи мастера, который вы
можете запустить щелчком по действию Add Host в меню Actions. Если роль Hyper-V
на сервере Windows Server 2008 еще не установлена, то в процессе инсталляции агента
SCVMM это будет сделано, после чего будет выполнена перезагрузка сервера.
Группирование хостов
По умолчанию SCVMM имеет только одну группу хостов с названием All Hosts. Путем
создания новых групп хостов вы можете сформировать логические группировки. Если
вы хотите создать группировки, то вы можете, например, организовать группы хостов
иерархическим образом (когда родительские группы хостов связаны с дочерними
группами хостов). Когда вы добавляете хост на сервер VMM, имеющий множество
групп хостов, вы можете выбрать ту группу, в которую он будет добавлен. Вы можете
модифицировать иерархические группы хостов при помощи перетаскивания.
Группы хостов имеют настраиваемые свойства, и в том числе такие свойства общего
характера, как: описание; аппаратные резервы хоста (процент CPU, память, дисковое
пространство, дисковый ввод/вывод в секунду, процент сетевой производительности);
конфигурация оптимизации ресурсов Performance Resource Optimization (PRO). Резер-
вы хоста используются при вычислении размещения виртуальных машин, чтобы опре-
делить, есть ли достаточное количество ресурсов для работы виртуальной машины.
Оптимизация ресурсов Performance Resource Optimization в менеджере Virtual Machine
Manager 2008 дает возможность применить оптимизацию ресурсов для рабочих нагрузок и
приложений виртуализированных сред. Для PRO нужна интеграция SCVMM 2008 и System
Center Operation Manager 2007. Данные по состоянию и производительности предоставля-
ются поддерживающими PRO пакетами управления из System Center Operation Manager
2007. При помощи этой информации PRO может автоматически (или вручную) реализовы-
вать рекомендации по минимизированию времени простоев и сокращению времени реше-
ния проблем. Эти рекомендации называются подсказками PROTips.
Настройка PRO дает вам возможность: активировать или деактивировать PRO для
группы хостов; определить минимальный уровень серьезности подсказки (только
Critical, или Warning и Critical), который будет отображаться в интерфейсе PROTips
в SCVMM 2008; определить реализацию подсказки (ручная или автоматическая); на-
значить тот уровень серьезности подсказки, который будет запускать реализацию. Если
у вас есть иерархия групп хостов, то дочерние группы могут наследовать настраивае-
мые свойства от своих родительских групп.
SCVMM использует группы хостов как структурные блоки своей модели делегирова-
ния. Группирование хостов обычно определяется сценарием управления. Поскольку в
консоли SCVMM Administrative Console вы можете делегировать только на уровне
группы хостов, то решение по группированию окажет влияние и на размещение вирту-
альных машин по хостам.
Например, если ваши серверы (физические или виртуальные) управляются по их функ-
ции (серверы сообщений, печати, контроллеры доменов и т. д.) и администрирование
разделяется на функциональном уровне, то виртуальные машины следует группировать
по их функциям. SCVMM позволяет вам создавать группы хостов и делегировать ад-
министрирование на уровне групп. Самая мелкая единица делегирования — это группа
хостов, содержащая всего один сервер Hyper-V с единственной виртуальной машиной.
Управление по функциональности требует от вас присваивания виртуальных машин
серверам Hyper-V по их функциям, при этом на одном сервере Hyper-V не следует со-
четать нескольких функций. Если же вы управляете по бизнес-группам, тогда все вир-
туальные машины для конкретной бизнес-группы должны содержаться на хостах
Hyper-V внутри одной группы хостов.
Для такого сценария управления, как тестовая лаборатория, можно управлять не по
функции или бизнес-группе, а по проекту. В такой ситуации вам следует создать груп-
пу хостов и выделить серверы Hyper-V для конкретного проекта (и виртуальные маши-
ны для этого проекта должны находиться на этих хостах). Обычно в тестовой лабора-
тории у вас есть некий общий пул ресурсов, и все хосты могут находиться в одной
группе хостов.
В сценарии управления виртуальными рабочими столами для обеспечения совмести-
мости приложений вам может потребоваться сгруппировать виртуальные машины либо
по версии операционной системы (Windows XP или Windows Vista), либо по их воз-
можностям (32- или 64-битные).
Для такого сценария управления, как обычная среда разработки программного обеспе-
чения, вам может потребоваться сгруппировать виртуальные машины по разрабаты-
ваемому проекту, по географии, либо по их особым потребностям в сетевом доступе
к серверным системам.
Делегирование административного доступа к консоли SCVMM выполняется на уровне
групп хостов и применяется к пользователю или группе. Если вы хотите, чтобы поль-
зователь или группа могли управлять набором хостов (и, следовательно, всеми вирту-
альными машинами этих хостов), то вам нужно создать новую пользовательскую роль
для делегирования. Такое делегирование создается при помощи мастера (в разделе
Administration консоли SCVMM Administrative Console). Мастер выполняет простой
процесс из трех шагов:
1. Выбрать пользователя или группу (которым будет производиться делегирование).
2. Выбрать область действия (группы хостов и сервера библиотек) для делегирования.
3. Создать делегирование.
На рис. 12.6 показана страница Select Scope этого мастера. Вы видите, что группы хос-
тов могут быть вложенными и что для делегирования вы можете выбрать как все дере-
во, так и любую группу хостов этого дерева. После делегирования хостов соответст-
вующим командам, эти команды могут управлять своими серверами Hyper-V.
Рис. 12.6. Страница Select Scope

(первый шаг создания пользовательской роли для делегирования)
Управление свойствами хостов

Каждый хост имеет целый набор свойств, которыми можно управлять (для этого надо
щелкнуть по хосту правой кнопкой мыши и выбрать пункт Properties). В число этих
свойств входят: описание хоста; способность принять дополнительную нагрузку в виде

виртуальных машин; состояние регистрации виртуальных машин; резервы хоста; про-
смотр текущей конфигурации оборудования (процессор, память, системы хранения,
флоппи-дисководы, сетевые адаптеры, дисководы CD/DVD); доступные виртуальные
сети; пути по умолчанию; порт удаленной консоли TCP/IP; а также множество специ-
фичных свойств. На рис. 12.7 показано диалоговое окно Host Properties.
Рис. 12.7. Диалоговое окно Host Properties сервера Hyper-V
Если хост нуждается в обслуживании, то его можно удалить из активного списка хос-
тов фермы серверов (которые доступны для размещения виртуальных машин). Для
этого выберите вкладку Status свойств хоста и сбросьте опцию This host is available
for placement. После этого хост удаляется из того алгоритма, который определяет рей-
тинг хоста для размещения виртуальных машин.
Если вы добавляете в SCVMM хост Hyper-V, то все его зарегистрированные виртуаль-
ные машины автоматически добавляются в консоль SCVMM Administrative Console и
становятся доступными для управления. Если вы развернете при помощи SCVMM
2008 новую виртуальную машину, то она будет автоматически зарегистрирована на
хосте. Если есть виртуальные машины, которые необходимо импортировать на хост
Hyper-V при помощи SCVMM, то для импорта вы должны использовать вкладку VMs
в свойствах хоста Hyper-V. Файлы для импорта должны при этом уже находиться на
системе хранения сервера Hyper-V.
Для управления при помощи SCVMM 2008 виртуальными сетями сервера Hyper-V вы
должны использовать вкладку Networking в свойствах хоста Hyper-V. Щелчок по
кнопке Add позволит вам определить подключение к новой (частной, внутренней или
внешней) виртуальной сети и задать тег VLAN для родительского раздела Hyper-V.
Для модификации существующей виртуальной сети необходимо выбрать эту вирту-
альную сеть и изменить ее свойства или тип виртуальной сети. Для удаления сущест-
вующей виртуальной сети выберите эту виртуальную сеть в списке и нажмите кнопку
Remove.
Для модификации существующего пути по умолчанию для хранения на сервере Hyper-V
виртуальной машины (или если вам нужно определить новый альтернативный путь по
умолчанию при помощи SCVMM 2008) вы должны использовать вкладку Placement
свойств сервера Hyper-V. Вкладка Placement позволяет вам просмотреть файловую
систему удаленного сервера Hyper-V и выбрать путь для размещения виртуальных
машин. Если вам нужно создать новый каталог, то вы должны выбрать опцию Explore
Directory (в левом нижнем углу окна просмотра).
Для модификации порта TCP/IP (для удаленного подключения виртуальных машин на
сервере Hyper-V) при помощи SCVMM 2008 вы должны использовать вкладку Remote
свойств сервера Hyper-V. Значение порта по умолчанию — 2179, но его можно изме-
нить на любое другое значение в диапазоне от 1 до 65 535.
Управление сетью хостов

SCVMM 2008 позволяет вам мигрировать виртуальные машины между серверами
Hyper-V. Для того чтобы миграция была успешной и виртуальная машина могла вести
обмен по сети, она должна иметь возможность подключиться во время миграции к
правильной виртуальной сети. В данном случае лучшая практика такова: определить на
всех серверах Hyper-V виртуальные сети, подключенные к одним и тем же подсетям,
чтобы они имели одинаковое название, с соблюдением регистра. Например, если на
каждом сервере Hyper-V имеется физический сетевой адаптер, подключенный к сети
10.10.10.0, то вам следует на каждом хосте создать виртуальную сеть с одним и тем же
названием (например, External-10.10.10.0).
Представление сети хостов

В SCVMM 2008 добавлена новая функциональная возможность выдачи графического
представления сетевой конфигурации сервера Hyper-V. Для доступа к этому сетевому
представлению щелкните правой кнопкой мыши по серверу Hyper-V в представлении
хостов менеджера SCVMM 2008 и выберите пункт View Networking. Вы увидите гра-
фическую диаграмму всех виртуальных сетей хоста и подключения виртуальных ма-
шин. На рис. 12.8 показано представление сервера Hyper-V, имеющего две виртуаль-
ные машины, которые были созданы и подключены к одной и той же внутренней вир-
туальной сети.
Рис. 12.8. Представление сетевой диаграммы сервера Hyper-V
Управление SCVMM при помощи Windows PowerShell
Менеджер System Center Virtual Machine Manager 2008 для всех своих действий управления
использует Windows PowerShell. Все, что вы можете сделать в пользовательском интер-
фейсе SCVMM 2008, вы можете так же сделать и при помощи скрипта Windows PowerShell.
Во многих местах пользовательского интерфейса SCVMM имеется кнопка, после нажатия
которой вы увидите тот код Windows PowerShell, который сервер VMM собирается выпол-
нить (чтобы вы могли скопировать его для повторного использования в ваших собственных
скриптах).
Компания Microsoft выпустила три книги, которые могут вам помочь изучить основы
Windows PowerShell:
• Wilson E. Microsoft Windows PowerShell Step By Step (Microsoft Press, 2007);
1
• Wilson E. Windows PowerShell Scripting Guide (Microsoft Press, 2008) ;
• Windows PowerShell 2.0 Administrator’s Pocket Consultant (Microsoft Press, 2009).
Компания Microsoft также разместила два ресурса, которые помогут вам понять использо-
вание Windows PowerShell совместно с SCVMM 2008 и предоставят код примеров, который
вы сможете быстро использовать. Эти два справочных документа можно найти по следую-
щим ссылкам:
• "Managing Virtualization with SCVMM and PowerShell" доступен по ссылке:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=
0c3a871d-9e80-46dd-85bc-3f759f007416;
• справочное руководство "System Center Virtual Machine Manager 2008 Cmdlet Reference"
доступно по ссылке:
http://www.microsoft.com/downloads/details.aspx?familyid=58E79A68-CEA8-4E73-
840F-CDD8FEB9DE87&displaylang=en.
Дэвид Зиембики (David Ziembicki, Principal Consultant (Microsoft Consulting Services))
1
Уилсон Э. Руководство по сценариям Windows PowerShell. — М.: ЭКОМ Паблишерз, 2009.
Управление порталом Self-Service Portal

Портал Self-Service Portal предназначен для конечных пользователей и администрато-
ров серверов (для создания виртуальных машин и доступа к ним). Для доступа к пор-
талу Self-Service Portal вы должны создать пользовательскую роль и добавить ее поль-
зователям. Пользователи портала не могут управлять аппаратными свойствами вирту-
альных машин (за исключением подключения носителей для виртуальных CD/DVD).
Администраторы SCVMM могут быть обладателями роли пользователя портала и ис-
пользовать его для управления виртуальными машинами, но они будут ограничены
теми правами, которые присвоены этой пользовательской роли.
Для конфигурирования портала Self-Service Portal необходимо выполнить четыре шага.
Первый шаг — инсталлировать портал (см. разд. "Инсталляция Self-Service Portal для
менеджера Virtual Machine Manager" ранее в этой главе). Второй шаг — определить те
серверы Hyper-V, которые должны стать выделенными порталами Self-Service Portal
для виртуальных машин. Третий шаг — создать группу хостов и переместить все сер-
веры-кандидаты на роль портала Self-Service в эту группу хостов. Четвертый шаг —
создать пользовательскую роль, в которой определено следующее:
название роли;
обладатели роли;
права, которые имеют обладатели роли;
права по созданию виртуальных машин;
совместно используемые ресурсы библиотек, доступные этой роли.
Права пользователя портала включают в себя управление состоянием виртуальной ма-
шины и права доступа. Вы можете предоставить определяемой вами пользовательской
роли как все, так и отдельные права. Имеются следующие права:
Start — запуск виртуальной машины;
Stop — останов виртуальной машины;
Pause and Resume — приостановка и возобновление работы виртуальной машины;
Checkpoint — создание моментальных снимков и управление ими;
Remove — удаление виртуальных машин;
Local Administrator — предоставить права локального администратора на виртуаль-
ных машинах;
Remote Connection — удаленно подключаться к виртуальной машине;
Shutdown — останов виртуальной машины.
Право на создание виртуальной машины позволит обладателям пользовательской роли
создавать собственные виртуальные машины. Вы можете ограничить те предваритель-
но подготовленные шаблоны виртуальных машин, которыми они могут воспользовать-
ся для создания виртуальных машин; вы можете также задать показатель квоты для
каждой виртуальной машины, которую пользователь развертывает на хосте Self-
Service. Виртуальные машины засчитываются в квоту только в том случае, если они
находятся на хосте (как в работающем состоянии, так и нет). Если пользователь выби-
рает свою квоту, то он не сможет больше включать новые виртуальные машины. Вы

можете также задать квоту для всех обладателей роли. Если вы это сделаете, то каждая
работающая виртуальная машина будет засчитываться в глобальную квоту данной ро-
ли (вне зависимости от того, кому данная виртуальная машина принадлежит).
Право на совместно используемый ресурс библиотеки определяет возможность поль-
зователя хранить свои виртуальные машины в библиотеке. Если такое право есть, то
вы можете сделать выбор из тех совместно используемых библиотек, которыми могут
пользоваться обладатели роли. Вы не можете ограничить некоторое подмножество об-
ладателей роли и дать им доступ только к определенным ресурсам библиотек.
После определения всех прав и опций для роли пользователя портала обладатели этой
роли могут получить доступ к порталу Self-Service Portal. На рис. 12.9 показано окно по
умолчанию портала Self-Service Portal (при зарегистрировавшемся обладателе роли).
Рис. 12.9. Окно портала Self-Service Portal
В одной ферме серверов может быть определено несколько порталов Self-Service

Portal. Хост Hyper-V может быть членом только одной группы хостов, а портал Self-
Service Portal определяет доступ по группе хоста. Можно определить несколько поль-
зовательских ролей для одной и той же группы хостов, что позволит вам иметь разные
права или квоты для каждой группы хостов.
Управление серверами библиотек

Серверы библиотек — это средство подготовки новых виртуальных машин. По умол-
чанию сервер библиотеки создается на том же компьютере, где инсталлирован сервер
VMM. Вы можете создать серверы библиотек и на других серверах вашей инфраструк-

туры. Когда виртуальная машина поставляется из SCVMM 2008, то она может быть
создана либо с нуля, либо вы можете использовать шаблоны виртуальных машин
с сервера библиотеки (для уменьшения времени поставки). На рис. 12.10 показана
конфигурация по умолчанию сервера библиотеки (инсталлированного на сервере
VMM). По умолчанию библиотека содержит только два пустых виртуальных жестких
диска (VHD): 16-гигабайтный динамически расширяющийся диск Blank Disk — Small
и 60-гигабайтный динамически расширяющийся VHD с названием Blank Disk — Large.
Рис. 12.10. Управление сервером библиотеки
Управление существующим сервером библиотеки состоит из следующих действий:

создание нового шаблона виртуальной машины;
создание нового профиля оборудования виртуальной машины;
создание нового профиля гостевой операционной системы;
управление файлами библиотеки;
управление настройками библиотеки.
В дополнение к управлению существующим сервером библиотеки вы можете также
создать новый сервер библиотеки. Дополнительные серверы библиотек следует созда-
вать для каждой площадки, где виртуальные машины будут поставляться серверам
Hyper-V. Не следует поставлять виртуальные машины через глобальную сеть (WAN) в

удаленный филиал компании (или даже через скоростной канал на другую производст-
венную площадку). Во избежание передачи файлов виртуальных машин через медлен-
ные каналы связи создайте сервер библиотеки в каждом удаленном филиале. Вы може-
те создать его непосредственно на сервере Hyper-V и уменьшить время поставки.
Создание удаленных серверов библиотек требует поддержания их актуальности при
помощи центрального сервера библиотеки. Серверы библиотек — это просто совмест-
но используемые файловые ресурсы, которые содержат используемые при поставке
виртуальных машин файловые объекты (виртуальные жесткие диски, виртуальные
гибкие диски, образы CD/DVD, скрипты, конфигурационные файлы и т. д.). Здесь по-
дойдет любая система репликации, которая позволит вам реплицировать содержимое
этого ресурса. Лучше всего использовать такой инструмент, который реплицирует
только изменения файла, а не весь файл целиком (из-за размера этих файловых объ-
ектов).
SCVMM 2008 не предоставляет никакого метода репликации (между серверами библиотек)
этих файловых объектов (из библиотеки) и объектов метаданных из базы данных. SCVMM
не поддерживает также и использования Distributed File Services Namespaces (DFSN) для
репликации объектов физических файлов.
Управление шаблонами виртуальных машин

Шаблоны виртуальных машин создаются по существующим виртуальным машинам
или по хранящимся в библиотеке виртуальным машинам. Сначала существующая вир-
туальная машина должна быть подготовлена при помощи Sysprep.exe (чтобы она могла
быть развернута с уникальным идентификатором безопасности (SID).
Создание шаблона — это многошаговый процесс, который зависит от выбранного ва-
ми источника. Если вы хотите использовать уже существующий шаблон (хранящийся
в библиотеке), то данный процесс будет состоять из пяти шагов:
1. Выбрать источник для шаблона.
2. Назвать шаблон.
3. Сконфигурировать профиль оборудования.
4. Сконфигурировать профиль гостевой операционной системы.
5. Создать шаблон по выбранным опциям.
Шаблон будет создан на том же сервере библиотеки, с которого был взят исходный
шаблон.
Если исходным материалом послужила развернутая на сервере Hyper-V существующая
виртуальная машина, то процесс будет состоять из семи шагов:
1. Выбрать источник для шаблона.
2. Назвать шаблон.
3. Сконфигурировать профиль оборудования.
4. Сконфигурировать профиль гостевой операционной системы.

5. Выбрать сервер библиотеки для хранения шаблона.
6. Выбрать путь в ресурсе библиотеки для хранения шаблона.
7. Создать шаблон по выбранным опциям.
Часто встречается необходимость создать шаблон по VHD в библиотеке. Для создания
шаблона по VHD, который был подготовлен при помощи Sysprep.exe и хранится
в библиотеке, выполните следующие шаги:
1. В представлении Library в панели Actions щелкните по пункту New Template.
2. На странице Select Source выберите Use an existing template or virtual hard disk
stored in the library, а затем нажмите кнопку Select.
3. В диалоговом окне Select Template Source выберите нужный вам VHD, нажмите
кнопку OK, а потом кнопку Next.
4. Введите название для шаблона и его описание, укажите также и владельца шаблона.
Владелец шаблона должен иметь доменную учетную запись.
5. На странице Configure Hardware адаптируйте настройки оборудования (при необ-
ходимости), а затем нажмите кнопку Next.
• Модифицируйте порядок загрузки в BIOS виртуальной машины (только для ра-
ботающих на хосте Hyper-V гостевых систем).
• Модифицируйте требуемое количество процессоров.
• Модифицируйте количество выделяемой памяти.
• Сконфигурируйте сопоставление виртуального гибкого диска.
• Добавьте виртуальный дисковод DVD.
• Добавьте виртуальный жесткий диск на контроллер IDE или SCSI.
• Сконфигурируйте один (или более) виртуальных сетевых адаптеров.
• Сконфигурируйте выделение ресурсов процессора (и при необходимости высо-
кую готовность виртуальной машины).
• Укажите, будут ли созданные по этому шаблону виртуальные машины обладать
высокой готовностью.
6. На странице Guest Operating System в разделе General Settings сконфигурируйте
следующие настройки:
• название компьютера (используйте знак * для случайного генерирования назва-
ния компьютера);
• пароль локального администратора (используйте знак * для запроса пароля);
• ключ продукта;
• часовой пояс;
• операционная система.
7. На странице Guest Operating System в разделе Networking сконфигурируйте сле-

дующие настройки:
• членство в домене;
• членство в рабочей группе.
8. На странице Guest Operating System в разделе Scripts сконфигурируйте следую-
щие настройки:
• Answer File — укажите файл ответов для Sysprep.exe (c дополнительными на-
стройками, кроме указанных мастером);
• [GUIRunOnce] commands — укажите любые команды, которые вы хотите вы-
полнить при первой регистрации.
9. На странице Guest Operating System после изменения всех настроек нажмите
кнопку Next.
10. На странице Summary просмотрите все сделанные вами настройки, а затем на-
жмите кнопку Create.
После создания шаблона вы можете управлять им (путем редактирования его свойств).
На рис. 12.11 показано диалоговое окно Virtual Machine Properties для существующе-
го шаблона.
В диалоговом окне Properties шаблона вы можете редактировать свойства общего ха-
рактера, конфигурацию оборудования по умолчанию, существующие контрольные
точки, настройки значений квоты и PRO, 10 специфичных настроек, а также действия
по умолчанию при запуске и останове сервера Hyper-V.
Перед созданием шаблона виртуальных машин по исходной виртуальной машине об-
думайте следующие аспекты:
виртуальная машина должна находиться на хосте, управляемом из SCVMM 2008;
виртуальная машина будет готовиться при помощи Sysprep.exe и будет удалена
с хоста на время этого процесса;
в виртуальной машине должна работать Windows XP или более новая операционная
система;
для того чтобы утилита Sysprep.exe могла работать, пароль администратора вирту-
альной машины должен быть пустым.
Если вы не хотите, чтобы исходная виртуальная машина для создания шаблона удалялась
с производственного сервера, используйте опцию Clone для клонирования исходной
виртуальной машины, не подключайте ее к сети и используйте этот клон для создания
шаблона.
Если шаблон будет использоваться для создания виртуальных машин через портал Self-
Service Portal, то свойства шаблона должны быть отредактированы (с целью указания вла-
дельца). Только владелец шаблона (пользователь или группа, присвоенные в политике
портала) сможет создавать, просматривать и управлять созданными по этому шаблону
виртуальными машинами.
Рис. 12.11. Диалоговое окно Virtual Machine Properties для существующего шаблона
Управление скриптами Windows PowerShell в библиотеке

Хранение скриптов Windows PowerShell в библиотеке VMM позволяет просматривать,
редактировать и выполнять их из представления Library. Для запуска скриптов
Windows PowerShell из консоли Administrator Console компьютер с консолью должен
иметь инсталлированный Windows PowerShell.
Из библиотеки VMM вы можете просматривать, модифицировать, удалять или добав-
лять новые скрипты Windows PowerShell.
Для добавления скрипта Windows PowerShell в библиотеку VMM выполните следую-
щие шаги:
1. Создайте скрипт Windows PowerShell и сохраните его с расширением ps1.
2. Установите сетевое подключение к серверу библиотеки VMM (при помощи пути
\\Servername\MSVMMLIBRARY).
3. Скопируйте скрипт Windows PowerShell в каталог или подкаталог совместно ис-
пользуемого сетевого ресурса.
4. В представлении Library выберите Refresh (в действиях Library Server Actions).
Для просмотра или редактирования скрипта Windows PowerShell из библиотеки VMM

сделайте следующее:
1. В представлении Library выберите тот скрипт, который хотите просмотреть.
2. В панели Actions (под Script) щелкните по пункту View PowerShell Script.
3. После этого в редакторе Notepad откроется копия скрипта для просмотра.
4. Если вы редактируете скрипт, то должны сохранить модифицированную версию
(при помощи команды Save As) в том же самом сетевом ресурсе. Скрипт будет до-
бавлен в библиотеку во время следующего обновления библиотеки.
Для выполнения скрипта Windows PowerShell требуется настройка политики выполне-
ния PowerShell. По умолчанию политика установлена в значение Restricted, что не по-
зволит выполняться никаким скриптам Windows PowerShell. Для определения вашей
политики выполнения вы можете использовать командлет Get-ExecutionPolicy.
Существуют четыре возможных варианта политики выполнения:
Restricted — скрипты выполняться не могут. Windows PowerShell может использо-
ваться только в интерактивном режиме;
AllSigned — могут выполняться только те скрипты, которые подписаны доверен-
ным издателем;
RemoteSigned — скачанные скрипты перед выполнением должны подписываться
доверенным издателем;
Unrestricted — ограничений нет; могут выполняться все скрипты Windows
PowerShell.
Для выполнения скриптов Windows PowerShell из библиотеки VMM у вас есть два ва-
рианта. Первый — подписать скрипты и установить политику выполнения в значение
AllSigned или RemoteSigned. Второй — не подписывать скрипты и установить поли-
тику выполнения в значение Unrestricted.
Для установки политики выполнения в значение Unrestricted используйте командлет
Set-ExecutionPolicy с единственным параметром (Unrestricted).
Для выполнения скрипта Windows PowerShell из библиотеки VMM при правильно
установленной политике выполнения:
1. В представлении Library выберите нужный вам скрипт.
2. В панели Actions (под Script) щелкните по пункту Run PowerShell Script (чтобы
открыть окно Windows PowerShell и выполнить скрипт).
Управление профилями оборудования

Профили оборудования создаются с нуля и хранятся в библиотеке для использования
при поставке виртуальных машин. Показанный на рис. 12.12 профиль оборудования
состоит из:
настройки BIOS;
настройки процессора (количество и скорость);
настройки памяти;
конфигурации дисковода гибких дисков;

конфигурации коммуникационных портов СОМ1 и СОМ2;
конфигурации дисководов контроллера IDE;
конфигурации дисководов контроллера SCSI;
конфигурации сетевого адаптера (количество и тип);
приоритета процессоров;
конфигурации высокой готовности.
Рис. 12.12. Диалоговое окно New Hardware Profile
Управление профилями гостевых операционных систем

Профили гостевых операционных систем используются для определения стандартных
настроек операционных систем, которые могут импортироваться в шаблон для его по-
следующей подстройки. При помощи создания профилей для различных развертывае-
мых вами гостевых операционных систем вы можете быстро сформировать стандарт-
ный подход к конфигурированию. На рис. 12.13 показано диалоговое окно профиля
гостевой операционной системы.
Профили гостевых операционных систем позволяют вам сконфигурировать следующие

опции:
название профиля;
описание профиля;
владельца профиля;
название компьютера гостевой операционной системы;
информацию об организации (из гостевой операционной системы);
пароль администратора (гостевой операционной системы);
ключ продукта (гостевой операционной системы);
часовой пояс по умолчанию для гостевой операционной системы;
гостевую операционную систему;
рабочую группу или домен гостевой операционной системы;
файл ответов утилиты Sysprep.exe для гостевой операционной системы;
команды GUIRunOnce гостевой операционной системы.
Рис. 12.13. Диалоговое окно New Guest OS Profile

Управление файлами библиотеки

Серверы библиотек состоят из совместно используемого сетевого ресурса, из которого
можно во время поставки виртуальных машин скачивать файлы. Для того чтобы эти
файлы можно было использовать в SCVMM 2008, они должны быть добавлены в сете-
вой ресурс библиотеки. Это делается при помощи копирования файлов в сетевой ре-
сурс на сервере библиотеки и последующего обновления сетевого ресурса. Когда вы
копируете файлы в существующий сетевой ресурс библиотеки, эти файлы не видны и
не могут быть использованы до следующего обновления библиотеки. Библиотека ав-
томатически обновляется по регулярному расписанию, которое настраивается админи-
стратором. По умолчанию это делается один раз в час. Вы можете также немедленно
проиндексировать эти файлы при помощи обновления сетевого ресурса библиотеки
вручную.
Для добавления файлов в существующий сетевой ресурс библиотеки и последующего
его ручного обновления выполните следующую процедуру:
1. Скопируйте файлы в сетевой ресурс на сервере библиотеки.
2. В консоли Administrator Console выберите представление Library.
3. В панели перехода разверните Library Server и перейдите к сетевому ресурсу биб-
лиотеки, в который вы скопировали файлы.
4. При выделенном сетевом ресурсе библиотеки в панели Actions под Library Share
щелкните по пункту Refresh.
5. Все файлы в сетевом ресурсе немедленно индексируются в менеджере Virtual
Machine Manager и становятся доступны для использования.

Показанная на рис. 12.14 консоль Administrator Console отображает все виртуальные
машины, к которым имеет доступ администратор SCVMM (в зависимости от делегиро-
ванной ему роли). Все виртуальные машины будут отображаться в центральной панели
All Hosts в виде списка. По умолчанию отображается следующая информация:
название виртуальной машины;
текущее состояние;
состояние задания;
хост, на котором в настоящее время находится виртуальная машина;
владелец виртуальной машины;
текущий средний процент использования процессора.
Вы можете настроить отображаемую в столбцах информацию (при помощи щелчка
правой кнопкой мыши по заголовку столбца и выбора имеющихся заголовков столб-
цов):
название компьютера;
количество процессоров;
операционная система;
описание;
добавление виртуальных машин;
добавлено;
модифицировано;
память;
дисковый ввод;
дисковый вывод;
сетевой ввод;
сетевой вывод;
тег;
статья затрат;
показатель квоты;
готовность;
особые свойства.
Рис. 12.14. Представление Virtual Machines консоли Administrator Console

На рис. 12.14 показана панель Actions (справа), которая содержит доступные для выде-
ленной виртуальной машины действия. В табл. 12.9 дан список всех возможных дейст-
вий и их описание.
Таблица 12.9. Действия виртуальной машины
Действие Описание
Start Включить или возобновить из сохраненного состояния
Stop Выключить
Pause Приостановить использование процессора, но использование памяти остается

тем же самым
Save state Приостановить виртуальную машину и сохранить текущее состояние памяти
и информацию по обработке на диск
Discard saved Удалить информацию о памяти и обработке с диска, чтобы виртуальная машина
state перезагрузилась "с чистого листа"
Shut down Закончить работу операционной системы при помощи стандартных вызовов API
операционной системы Windows
Connect to Начать сеанс удаленного рабочего стола с виртуальной машиной. Если вирту-
virtual machine альная машина не работает, будет выдана ошибка
New checkpoint Сделать моментальный снимок
Manage Управлять текущим деревом моментальных снимков

checkpoints
Install virtual Инсталлировать службы интеграции сервера Hyper-V. Работает только для под-
guest services держиваемых операционных систем Windows
New template Создать новый шаблон на базе выбранной виртуальной машины. Выбранная
виртуальная машина не может иметь никаких моментальных снимков
Clone Создать копию текущей виртуальной машины
Store in library Сохранить состояние виртуальной машины и записать его в совместно исполь-
зуемый сетевой ресурс сервера библиотеки
Delete Отменить регистрацию виртуальной машины на сервере Hyper-V и в консоли
VMM Console
View networking Показать текущие виртуальные сетевые подключения для виртуальной машины
Properties Показать диалоговое окно Properties, чтобы можно было управлять свойствами
Управление контрольными точками

Для описания различных используемых серверами Virtual Server, Hyper-V и VMware
ESX технологий SCVMM 2008 использует обобщенный термин "контрольные точки".
В Hyper-V контрольной точке соответствует моментальный снимок. Моментальные
снимки — это коллекции сохраненных состояний и конфигураций оборудования вир-
туальных машин в разные моменты времени. Моментальные снимки позволяют поль-
зователям Hyper-V проверять различные гипотезы, а потом возвращаться в исходное
состояние виртуальной машины при помощи моментального снимка.
SCVMM дает возможность управлять контрольными точками (моментальными сним-

ками). Выберите виртуальную машину и укажите Manage checkpoints в меню Virtual
Machine панели Actions (чтобы отобразить показанный на рис. 12.15 интерфейс управ-
ления контрольными точками). Интерфейс Checkpoint Management — это вкладка
в диалоговом окне Virtual Machine Properties.
В этом интерфейсе вы можете создать новую контрольную точку, удалить существую-
щую контрольную точку, восстановить виртуальную машину в состояние на тот мо-
мент времени, когда была выполнена контрольная точка (восстановиться из момен-
тального снимка Hyper-V), а также просмотреть свойства контрольной точки. Вкладка
Checkpoints диалогового окна Virtual Machine Properties позволяет вам увидеть тот
момент времени, в который была выполнена контрольная точка, а также конфигура-
цию оборудования виртуальной машины на этот момент времени.
Рис. 12.15. Вкладка Checkpoints диалогового окна Virtual Machine Properties
Клонирование виртуальных машин

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

состоять из пяти шагов:
1. Дайте название клону.
2. Сконфигурируйте профиль оборудования.
3. Выберите сервер библиотеки.
4. Выберите путь к месту хранения клона.
5. Создайте клон с указанными опциями.
Если вы выбрали в качестве места размещения клона виртуальной машины сервер
Hyper-V, то процесс будет состоять из шести шагов:
1. Дайте название клону.
2. Сконфигурируйте профиль оборудования.
3. Выберите хост для размещения клона.
4. Выберите путь на хосте для хранения клонированной виртуальной машины.
5. Выберите используемые виртуальные сети.
6. Создайте клон виртуальной машины с указанными опциями.
Управление свойствами виртуальных машин

Каждая виртуальная машина имеет целый набор свойств, которыми можно управлять
при помощи щелчка правой кнопкой мыши по названию виртуальной машины и по-
следующего выбора пункта Properties контекстного меню (или при помощи выбора
Properties в меню Actions). Свойства виртуальной машины разбиты на несколько
вкладок: General, Hardware Configuration, Checkpoints, Custom Properties, Settings и
Actions. На рис. 12.16 показана вкладка General диалогового окна Virtual Machine
Properties.
Общие свойства General позволяют вам управлять такими вещами, как название, вла-
делец и операционная система виртуальной машины. Вы можете также просмотреть и
другие свойства: время добавления виртуальной машины в консоль VMM Console;
время ее последней модификации; были ли в нее загружены службы интеграции.
В табл. 12.10 даны описания всех общих свойств, которыми можно управлять.
Таблица 12.10. Общие свойства виртуальных машин
Name Уникальное название виртуальной машины (так, как оно видно в SCVMM). Оно не обя-
зано совпадать с названием компьютера в операционной системе, но такая схема
облегчает управление
Description Описание виртуальной машины (все, что вы хотите о ней сообщить)
Owner Владелец виртуальной машины. По умолчанию это тот пользователь, который создал
виртуальную машину, но это можно изменить
Cost center Это статья затрат, на которую следует относить информацию по использованию вир-
туальной машины
Tag Присвоить тег виртуальной машине, чтобы сделать возможной фильтрацию или груп-
пирование по тегу в представлении виртуальных машин. Все введенные теги будут
добавлены в список фильтрации по тегам
Operating Выберите операционную систему, которая будет инсталлирована на виртуальной
system машине
Рис. 12.16. Вкладка General диалогового окна Virtual Machine Properties
Вкладка Hardware Configuration предоставляет вам обычные опции конфигурации

оборудования для создания новой виртуальной машины, шаблона или клона.
В табл. 12.11 дано описание всех настроек конфигурации оборудования, которыми
можно управлять.
Таблица 12.11. Конфигурация оборудования виртуальной машины
BIOS Настройка порядка загрузки с устройств: CD, жесткий диск IDE, PXE, гибкий диск.
Также включение/выключение режима Num Lock
Processor Конфигурация процессоров. Выберите количество, тип и скорость процессора
Memory Сконфигурируйте количество резервируемой памяти
Floppy Drive Конфигурация гибкого диска (отсутствует; физический; виртуальный образ)
COM1, COM2 Конфигурация коммуникационных портов (СОМ1 и СОМ2). Не подключен;

подключение именованного канала
IDE Devices Конфигурация дисководов на контроллере IDE. Виртуальные жесткие диски
(размер, тип, порт контроллера), виртуальные дисководы CD/DVD (отсутствует;
физический; виртуальный образ)
SCSI Devices Конфигурация дисководов контроллера SCSI. Виртуальные жесткие диски (раз-
мер, тип, порт контроллера)
Network adapter Конфигурация сетевого адаптера (подключение, тег, VLAN, MAC-адрес)
Integration Службы интеграции (завершение работы; синхронизация времени; обмен

services данными; тактовые импульсы; резервное копирование)
Priority Процессорный приоритет (высокий, нормальный, низкий, нестандартный)
Availability Конфигурация высокой готовности (включена/выключена)
Вкладка Settings позволяет настраивать квоту и конфигурацию PRO. В табл. 12.12 дано
описание всех настроек виртуальных машин, которыми можно управлять.
Таблица 12.12. Настройки виртуальных машин
Quota Определить показатель квоты для отслеживания использования портала Self-Service

Portal и самой виртуальной машины
PRO Опция конфигурации для исключения виртуальной машины из реализаций PRO. Она
исключит миграцию виртуальной машины системой PRO
Вкладка Actions позволяет выполнить конфигурирование действий, которые происхо-

дят с виртуальной машиной при запуске и останове сервера Hyper-V. В табл. 12.13 да-
но описание всех настроек Action, которыми можно управлять.
Таблица 12.13. Действия виртуальных машин
Action when physical Сконфигурировать действие при запуске сервера Hyper-V:

server starts
• никогда автоматически не включать виртуальную машину;
• всегда автоматически включать виртуальную машину;
• автоматически включать виртуальную машину в том случае, если она
работала в момент останова физического сервера;
• задержка запуска в секундах
Action when physical Сконфигурировать действие при останове сервера Hyper-V:

server stops
• сохранить состояние;
• выключить виртуальную машину;
• завершить работу гостевой операционной системы
Управление кластером серверов Hyper-V

SCVMM 2008 может управлять кластерами Hyper-V, имеющими до 16 узлов. Чтобы
быть членом кластера хостов Hyper-V, узел должен работать под управлением Hyper-V
и Failover Clustering.
Добавление кластера хостов Hyper-V

Добавление кластера хостов Hyper-V в менеджер SCVMM 2008 делается точно так же,
как и добавление любого узла Hyper-V. Если SCVMM обнаруживает, что сервер Hyper-V
является частью кластера, то он показывает диалоговое окно (рис. 12.17). Если вы со-
гласитесь на добавление кластера хостов, то SCVMM добавит все узлы кластера.
Рис. 12.17. Обнаружение кластера в процессе Add Host
После того как кластер хостов добавлен в SCVMM 2008, он отображается в представ-
лении групп хостов (в виде названия кластера со всеми узлами под ним). На рис. 12.18
показан кластер RK-Cluster с двумя узлами: RK-HOST1 и RK-HOST2.
Рис. 12.18. Кластер хостов внутри группы хостов

Управление кластером хостов

Управление кластером хостов при помощи SCVMM 2008 ограничено всего нескольки-
ми действиями. Вы можете либо перенести кластер хостов в другую группу хостов,
либо удалить кластер хостов из SCVMM (и, следовательно, удалить все узлы кластера),
либо модифицировать свойства кластера хостов. Все прочее управление кластером
хостов вы должны выполнять на уровне серверов или виртуальных машин.
Перенос кластера хостов в другую группу хостов позволяет вам изменить модель деле-
гирования (или модель для Self-Service). Удаление кластера хостов обычно делается
очень редко (только в случаях выполнения серьезных задач по обслуживанию или по-
иску неисправностей). Самая обычная задача управления кластером хостов состоит
в управлении свойствами кластера.
Управление свойствами кластера хостов

Когда вы управляете кластером хостов Hyper-V, вы управляете свойствами всего кла-
стера. Для этого необходимо выбрать в представлении Hosts нужный кластер и вы-
брать Properties в меню Host Cluster в панели Actions.
Свойства Host Cluster позволяют вам наблюдать за состоянием узлов кластера,
настраивать резервы кластера на случай сбоя узлов, просматривать имеющиеся в кла-
Рис. 12.19. Диалоговое окно Host Cluster Properties

стере сети, просматривать совместно используемые системы хранения кластера и

имеющееся свободное пространство, а также включать Physical Resource Optimiza-
tion (PRO) для кластера. На рис. 12.19 показано диалоговое окно Host Cluster
Properties.
Резервирование на случай сбоя узлов (на вкладке General) позволяет вам выбрать ко-
личество узлов кластера, которые будут использоваться в случае сбоя узлов. Если вы
укажете один узел, то кластер сможет пережить отказ одного узла и будет по-прежнему
иметь достаточно ресурсов для поддержки работы всех виртуальных машин. Каждый
узел кластера оценивается по требованиям к ресурсам его виртуальных машин. Сбой
одного узла приведет к миграции его виртуальных машин на другие узлы кластера
(в соответствии с имеющимися ресурсами). Если для миграции всех виртуальных ма-
шин (за один прием) не хватает места, то кластер считается переполненным. Если кла-
стер окажется в переполненном состоянии после добавления виртуальной машины, то
такое размещение виртуальной машины будет заблокировано.
На вкладке PRO вы можете включить Performance Resource Optimization для кластера и
выбрать уровень серьезности, при котором будут выдаваться подсказки. Вы можете
также включить автоматическую реализацию подсказок PRO после их получения.
Резюме
Данная глава дала вам обзор использования менеджера System Center Virtual Machine
Manager 2008 для управления фермой серверов Hyper-V. Вы научились инсталлировать
System Center Virtual Machine Manager 2008 в конфигурации одного сервера и в рас-
пределенной конфигурации (чтобы должным образом масштабировать инсталляцию
для выполнения требований к управлению фермой серверов). Вы узнали также об
управлении и конфигурировании хостов, библиотек, порталов Self-Service Portal, вир-
туальных машин, а также кластеров хостов.

System Center Virtual Machine Manager 2008 — ресурс, который предоставляет дос-
туп к технической информации, а также информации по продукту и его инсталля-
ции, доступен по ссылке:
System Center Virtual Machine Manager 2008 Management Pack — ресурс, который
предоставляет доступ к информации по продукту, доступен по ссылке:
http://www.microsoft.com/downloads/details.aspx?FamilyID=d6d5cddd-4ec8-
4e3c-8ab1-102ec99c257f&displaylang=en;
System Center Virtual Machine Manager System Requirements — ресурс, который пре-
доставляет подробную информацию по программным и аппаратным требованиям
к инсталляции на одном сервере и для распределенной инсталляции, доступен по

ссылке: http://technet.microsoft.com/en-us/library/cc764328.aspx;
System Center Virtual Machine Manager 2008 Configuration Analyzer — инструмент,
который позволяет вам проанализировать сервер до или после инсталляции
SCVMM 2008 (для того, чтобы обеспечить его правильную настройку), его можно
скачать по ссылке: http://go.microsoft.com/fwlink/?LinkID=100597;
Microsoft Baseline Configuration Analyzer (MBCA) — инструмент, который требуется
для SCVMM 2008 Configuration Analyzer, его можно скачать по ссылке:
http://go.microsoft.com/fwlink/?LinkID=97952.
ГЛАВА 13
Резервное копирование
и восстановление сервера Hyper-V
В этой главе вы узнаете о тех возможностях резервного копирования и восстановления,
которые можно использовать в среде серверов Hyper-V. В частности, вы разберетесь в
службе Volume Shadow Copy Service (VSS), а также в использовании ее для приложе-
ний уровня предприятия (вроде System Center Data Protection Manager (DPM) 2007 SP1)
с целью выполнения резервного копирования и восстановления локальных и удален-
ных серверов Hyper-V и виртуальных машин. Вы узнаете также и о том, как использо-
вать для резервного копирования виртуальных машин более традиционные средства.
И наконец, вы найдете здесь подробные процедуры, которые описывают процесс ин-
сталляции и конфигурирования приложения DPM 2007 SP1 (которое поддерживает
резервное копирование и восстановление конфигурационной информации Hyper-V и
виртуальных машин).
Резервное копирование среды виртуализации

Среда виртуализации требует такого же планирования резервного копирования, как и
физическая среда; при этом особое внимание следует уделять тем зависимостям, кото-
рые связаны с уровнем виртуализации. В отличие от физического сервера, степень ис-
пользования ресурсов которого не влияет непосредственно на производительность ра-
бочих нагрузок другого физического сервера, виртуальные машины совместно исполь-
зуют одно и то же оборудование, что потенциально влияет на производительность и
рабочие нагрузки виртуальных машин. Поэтому стратегия резервного копирования
сервера Hyper-V должна включать в себя такое расписание резервного копирования
виртуальных машин, которое оказывало бы минимальное воздействие на производи-
тельность и готовность приложений.
В случае единственного физического сервера областью действия резервного копирова-
ния является только отдельный сервер. В виртуализированной же среде область дейст-
вия резервного копирования может включать в себя как сервер Hyper-V, так и одну
(или более) виртуальных машин. Поэтому стратегия резервного копирования сервера
Hyper-V должна сбалансировать расписания резервного копирования виртуальных ма-
шин и сервера Hyper-V.
В действительности же при разработке успешной стратегии резервного копирования

для виртуализированной среды определяющим является метод резервного копирова-
ния. Если при выполнении резервного копирования сервера Hyper-V и виртуальных
машин вы сможете использовать службу Volume Shadow Copy Service и модуль записи
VSS для Hyper-V, то вы сможете реализовать очень простую стратегию резервного ко-
пирования. Однако если в вашей виртуализированной среде вам нужно использовать
традиционные методы резервного копирования, то это существенно усложнит вашу
стратегию резервного копирования.
Модуль записи VSS для Hyper-V

В общем смысле модуль записи VSS — это интерфейс, предоставляемый приложением
для: управления информацией о данных и состоянии; обеспечения сброса на диск всей
очереди данных; а также обеспечения отсутствия активности приложения перед нача-
лом выполнения моментального снимка тома при помощи VSS. Все это необходимо
для обеспечения непротиворечивого состояния приложения перед выполнением ре-
зервного копирования. Hyper-V предоставляет модуль VSS, который поддерживает
резервное копирование конфигурации сервера Hyper-V и виртуальных машин.
Без модуля записи VSS приложение тоже может копироваться при помощи VSS, но с
некоторыми существенными ограничениями. В частности, не может быть гарантирова-
на непротиворечивость состояния приложения, а следовательно, и самой резервной
копии. Если сделать таким способом резервную копию виртуальной машины, то вос-
становление ее при помощи моментального снимка VSS было бы равнозначно выклю-
чению виртуальной машины и включению ее обратно, что привело бы к потере всей
информации состояния приложений и служб, а также всех хранящихся в памяти дан-
ных.
В сервере Hyper-V модуль записи VSS реализован в службе Virtual Machine
Management Service (VMMS) и предлагает следующую функциональность:
резервное копирование и восстановление сервера Hyper-V и всех настроек конфи-
гурации;
оперативное резервное копирование виртуальных машин Windows Server 2003 и
более новых (при инсталлированных службах интеграции);
автономное резервное копирование всех поддерживаемых гостевых операционных
систем виртуальных машин (когда службы интеграции не инсталлированы);
восстановление отдельных виртуальных машин на исходный (или другой) сервер
Hyper-V.
Резервное копирование конфигурационной информации сервера Hyper-V имеет особую
важность, поскольку в ней хранятся такие данные, как: настройки Hyper-V, виртуальные се-
ти, зарегистрированные виртуальные машины и т. д. Без этой информации не может рабо-
тать ни сервер Hyper-V, ни виртуальные машины.
Модуль записи VSS для Hyper-V не обеспечивает следующую функциональность:

оперативное резервное копирование Windows Server 2003 (или более поздних вер-
сий) при отсутствии инсталлированных служб интеграции;
Глава 13. Резервное копирование и восстановление сервера Hyper-V 503
оперативное резервное копирование виртуальных машин с отличными от семейства

Windows операционными системами;
оперативное резервное копирование виртуальных машин с томами FAT или FAT32;
оперативное резервное копирование виртуальных машин с динамическими дисками;
оперативное или автономное резервное копирование виртуальных машин с удален-
ными виртуальными жесткими дисками;
оперативное или автономное резервное копирование виртуальных машин (с загру-
женным в гостевой операционной системе поставщиком iSCSI), подключенных
к удаленным дискам iSCSI.
Инструменты модуля записи VSS для Hyper-V
Для использования модуля записи VSS для Hyper-V необходим инициатор запросов VSS.
Набор для разработки программного обеспечения Volume Shadow Copy Service SDK, кото-
рый можно бесплатно скачать с сайта Microsoft Download Center, содержит два тестовых
приложения, имеющих реализацию интерфейса инициатора запросов VSS. BETest и
VShadow — это отличные приложения для иллюстрации функциональности модуля записи
VSS для Hyper-V, а также для выполнения резервного копирования и восстановления в
тестовой среде.
Сервер Windows Server 2008 содержит инструмент командной строки DiskShadow. Это при-
ложение использует интерфейс прикладного программирования VSS для выполнения ре-
зервного копирования и теневых копий. DiskShadow — это полный инициатор запросов
VSS, который позволяет пользователю перечислить все активные модули записи VSS (и их
компоненты), все поставщики VSS и теневые копии, либо выполнить теневую копию (с ис-
пользованием модуля записи VSS) целого набора томов. Для использования DiskShadow
вы можете запустить скрипт или использовать интерфейс командной строки. DiskShadow
имеет также и некоторые расширенные функции, которые вы можете использовать для та-
ких задач, как предоставление теневой копии в локальную файловую систему или превра-
щение тома в теневую копию.
Сервер Windows Server 2008 содержит также еще один инициатор, который можно инстал-
лировать вместе с необязательной функциональной возможностью Windows Server Backup
Features. Windows Server Backup можно сконфигурировать для поддержки сервера Hyper-V
(для этого необходимо зарегистрировать идентификатор модуля записи VSS для Hyper-V
в системном реестре).
Мишель Мишель (Michael Michael, Architect (Virtual Machine Manager Team))
Дополнительную информацию по DiskShadow вы можете найти по ссылке:
http://technet.microsoft.com/en-us/library/cc772172.aspx. Если вы хотите узнать больше
об использовании Windows Server Backup, см. главу 11.
Компоненты VSS
На рис. 13.1 показаны основные компоненты, участвующие в процессе резервного ко-
пирования VSS. Служба VSS (\%SystemDrive%\Windows\system32\vssvc.exe) является
коммуникационным посредником между инициатором запросов VSS, модулем записи
VSS и поставщиком VSS.
Инициатор запросов VSS делает запрос на создание теневой копии или восстановление
с нее; обычно это приложение резервного копирования (но не только). Инициатор за-
просов VSS ведет обмен со службой VSS (чтобы перечислить имеющиеся модули
записи VSS и получить информацию от целевого модуля записи VSS о тех данных,
которые необходимо скопировать, а также об особенностях резервного копирования
этих данных). Как уже упоминалось во врезке "Информация из первоисточника. Ин-
струменты модуля записи VSS для Hyper-V" (ранее в этой главе), приложение
Windows Server Backup является инициатором запросов VSS. Приложение System
Center DPM 2007 SP1 также является инициатором запросов VSS. Прочие инициаторы
запросов VSS можно получить у независимых разработчиков программного обеспече-
ния (independent software vendors, ISV), которые разрабатывают приложения управле-
ния или резервного копирования.
Рис. 13.1. Компоненты процесса теневого копирования Volume Shadow Copy
Модуль записи VSS предоставляет инициатору запросов VSS информацию (через

службу VSS) относительно данных (которые нужно включить в теневую копию или
исключить из нее) и о том, как делать резервное копирование этих данных. Он также
обеспечивает непротиворечивое состояние этих данных перед созданием теневой ко-
пии. Модуль записи VSS — это компонент, который предоставляется приложением
или ролью (такими, как серверы SQL Server и Exchange Server, а также роль Hyper-V).
Сервер Windows Server 2008 предоставляет также модуль записи VSS для файловой
системы NTFS. Если приложение не имеет модуля записи VSS, то теневую копию соз-
дать все равно можно; однако непротиворечивость данных при этом не гарантируется.
Несогласованность данных вызывается незавершенными транзакциями приложения,
которые приводят к наличию незафиксированных на диске данных. Поэтому компо-
ненты модуля записи VSS дорабатываются разработчиками приложений (чтобы обес-
печить фиксацию всех данных приложения и отсутствие неоконченных операций запи-
си на момент создания теневой копии).
Поставщик VSS фактически создает и обслуживает одну (или несколько) теневых ко-
пий. Служба VSS дает указание поставщику VSS создать теневую копию (по запросу
от инициатора запросов VSS); это делается после того, как модуль записи VSS переве-
дет приложение в состояние покоя. Сервер Windows Server 2008 содержит поставщик
VSS для системного программного обеспечения. Однако производитель системы хра-
нения может разработать свой аппаратный поставщик VSS, который оптимизирован
для его системы хранения, а производители других решений могут реализовать свои
(более гибкие) программные поставщики VSS.
Процесс резервного копирования Hyper-V при помощи VSS

Далее следует пошаговое описание того, как показанные на рис. 13.1 компоненты
взаимодействуют при выполнении резервного копирования Hyper-V с использованием
VSS:
1. Инициатор запросов VSS (приложение резервного копирования) запрашивает спи-
сок модулей записи VSS у службы VSS.
2. Инициатор запросов VSS выбирает модуль записи VSS для Hyper-V и запрашивает
метаданные резервного копирования, в которых содержится информация по кон-
фигурации и томам.
3. Модуль записи VSS для Hyper-V собирает информацию метаданных и отправляет
ее службе VSS (чтобы она была предоставлена инициатору запросов VSS).
4. Инициатор запросов VSS использует метаданные для выбора информации о под-
лежащих резервному копированию конфигурациях, томах и виртуальных машинах.
5. Служба VSS уведомляет модуль записи VSS для Hyper-V о необходимости ини-
циировать подготовку выполнения теневого копирования.
6. Модуль записи VSS для Hyper-V уведомляет целевые виртуальные машины о не-
обходимости сбросить все буферы и кэши и по завершении этого сброса информи-
рует службу VSS о своей готовности.
7. Служба VSS уведомляет модуль записи VSS для Hyper-V о необходимости начать
фазу фиксации теневой копии.
8. Модуль записи VSS для Hyper-V информирует целевые машины о необходимости
прекратить активность данных, буферов и кэшей, а затем временно замораживает
все запросы на запись (чтения по-прежнему выполняются).
9. Служба VSS сбрасывает буфер файловой системы и замораживает файловую сис-
тему.
10. Служба VSS дает команду поставщику VSS о необходимости создать теневую ко-
пию (это занимает всего несколько секунд).
11. Поставщик VSS отвечает службе VSS, что он успешно создал теневую копию.
12. Служба VSS размораживает файловую систему и инструктирует модуль записи
VSS для Hyper-V о необходимости разморозиться.
13. Модуль записи VSS для Hyper-V включает выполнение записи, и все отложенные
операции записи выполняются.
14. Служба VSS проверяет успешное завершение всех поставленных в очередь опера-
ций записи (от всех модулей записи).
15. Если все в норме, то служба VSS предоставляет указатель на теневую копию ини-
циатору запросов VSS.
16. Инициатор запросов VSS делает резервную копию конфигурации и виртуальных
машин из теневой копии.
17. Инициатор запросов VSS сохраняет копию метаданных модуля записи VSS для
Hyper-V в XML-файл (для последующих операций восстановления).
Документ метаданных модуля записи VSS для Hyper-V

Для того чтобы инициатор запросов VSS использовал VSS API для создания теневой
копии, ему требуется подробная информация о том, что именно следует включить
в теневую копию, где информация хранится в настоящее время и на каких томах она
находится. Для передачи этой информации от модулей записи VSS к инициатору за-
просов VSS служит документ метаданных.
Документ метаданных модуля записи VSS для Hyper-V включает следующую инфор-
мацию:
GUID и дружественное имя модуля записи VSS для Hyper-V;
информация конфигурационного файла Hyper-V;
информация по конфигурации виртуальных машин и файлам компонентов;
поддерживаемый каждой виртуальной машиной сценарий резервного копирования
(оперативный или автономный).
Документ метаданных фактически является набором информации, собранной при по-
мощи VSS и интерфейса API модулей записи VSS; он хранится инициатором запросов
VSS в виде XML-документа для последующих операций восстановления. XML-
документ включает следующую информацию:
раздел идентификации (для идентификации того модуля записи VSS, который пре-
доставил метаданные);
раздел метода восстановления (который детализирует выполнение восстановления
и указывает наличие или отсутствие необходимости выполнить перезагрузку);
раздел оперативного резервного копирования, указывающий все виртуальные
машины, которые можно копировать в оперативном режиме;
раздел автономного резервного копирования, указывающий все виртуальные маши-
ны, которые можно копировать в автономном режиме;
раздел конфигурации Hyper-V, детализирующий все конфигурационные файлы, ко-
торые должны быть скопированы для восстановления конфигурации Hyper-V.
Именно приложение резервного копирования (а не модуль записи VSS для Hyper-V) опре-
деляет детализацию резервного копирования, следует ли включить в него весь том (на ко-
тором хранятся виртуальные машины) или только сами файлы виртуальных машин. Доку-
мент метаданных предоставляет всю необходимую информацию по конфигурации и путям.
Использование традиционных методов

для резервного копирования сервера Hyper-V
и виртуальных машин
Если в вашей среде нельзя реализовать резервное копирование с использованием VSS,
то вы по-прежнему можете использовать традиционные методы резервного копирова-
ния (чтобы обеспечить восстановление сервера Hyper-V или виртуальных машин). При
традиционном методе копирования используется приложение резервного копирования,
которое инсталлирует в операционную систему своего агента и копирует данные на
устройство внешнего хранения. Поэтому такой традиционный метод резервного копи-
рования можно использовать также и для виртуальной машины (инсталлировав агента
в гостевой операционной системе). Важным преимуществом является возможность
выполнения резервного копирования при нахождении виртуальной машины в опера-
тивном режиме (однако производительность виртуальной машины из-за резервного
копирования снижается). Дополнительные преимущества резервного копирования с
использованием агента — более тонкая настройка содержимого резервной копии; воз-
можность выполнять резервное копирование по сети; возможность восстанавливать из
резервной копии отдельные файлы.
Если вы используете для резервного копирования ваших виртуальных машин метод на
основе агента, то должны убедиться, что ваше приложение (или стратегия) резервного
копирования учитывают все файлы, которые составляют конфигурацию виртуальной
машины. Виртуальная машина состоит не только из одного (или нескольких) файлов
данных, представляющих собой подключенные к виртуальной машине виртуальные
диски, но включает в себя также и конфигурационный файл (xml), который содержит:
настройки виртуальной среды, выделение ресурсов, а также конфигурацию особых ха-
рактеристик виртуальной машины.
Один из недостатков метода резервного копирования на основе агента — это то, что
для выполнения резервного копирования виртуальная машина должна быть в опера-
тивном режиме. Поэтому если у вас есть виртуальные машины в состоянии приоста-
новки, в сохраненном состоянии, либо хранящаяся в библиотеке виртуальных машин,
то метод с использованием агента не сможет обеспечить полноценную стратегию
резервного копирования.
Если ваши виртуальные машины сконфигурированы с дисками iSCSI или с удаленно хра-
нящимися виртуальными жесткими дисками, то модуль записи VSS для Hyper-V не сможет
скопировать эти виртуальные машины, и вам придется использовать метод резервного ко-
пирования на основе агента.
Резервное копирование виртуальной машины

контроллера домена Active Directory
При создании стратегии резервного копирования работающего на виртуальной машине
контроллера домена следует учитывать некоторые особенности. Контроллеры домена
следует копировать только при помощи такого приложения, которое при операциях
резервного копирования и восстановления правильно взаимодействует с Active

Directory. Поскольку Active Directory имеет транзакционный характер, то приложение
резервного копирования должно обеспечить сохранение в резервной копии непротиво-
речивого состояния базы данных. По умолчанию при восстановлении контроллера до-
мена приложение резервного копирования должно модифицировать версию базы дан-
ных Active Directory (чтобы указать, что она была восстановлена из резервной копии и
должна получить все последние обновления от своих партнеров по репликации).
В частности, контроллеры домена Windows 2000 Server, Windows Server 2003 и
Windows Server 2008 используют для отслеживания обновлений с локального контрол-
лера домена номер последовательного обновления (update sequence numbers, USN).
Каждый контроллер домена использует USN для отслеживания последнего (полученного
им от каждого партнера по репликации) обновления, а также состояния всех остальных
контроллеров домена (которые хранят реплики каталога). Когда контроллер домена
восстановлен после сбоя, он запрашивает у своих партнеров по репликации все обнов-
ления с номерами USN, превышающими имеющиеся в его записях значения USN.
В дополнение к USN контроллеры домена отслеживают идентификацию баз данных
исходящих партнеров по репликации (при помощи атрибута invocationID объекта
NTDS Settings). Когда контроллер домена восстановлен, то атрибут invocationID сбра-
сывается и реплицируется на все контроллеры домена в лесу. Контроллеры домена в
лесу обновляют свои USN, чтобы они соответствовали наивысшему USN восстанов-
ленного контроллера. Комбинация нового invocationID и выполнения обновлений USN
после восстановления позволяет правильно работать репликации с восстановленного
контроллера домена.
Для резервного копирования и восстановления контроллеров домена можно использо-
вать как модуль записи VSS для Hyper-V, так и разработанные с учетом поддержки
Active Directory приложения резервного копирования на основе агентов.
ВНИМАНИЕ!
Для резервного копирования работающих в виртуальных машинах контроллеров домена
Active Directory моментальные снимки виртуальных машин использовать нельзя. При вос-
становлении с моментального снимка не будет сделано обновление invocationID и USN ба-
зы данных Active Directory. Для резервного копирования и восстановления работающих на
виртуальных машинах производственных контроллеров домена Active Directory обязатель-
но использование совместимых с Active Directory приложений (таких, как Windows Server
Backup или System Center DPM 2007 SP1).
Подробности о том, как система репликации отслеживает изменения каталога; о процессе
регенерации после процедуры восстановления; а также об изменениях операционной сис-
темы, защищающих от неуместной репликации, можно прочитать в документе "Backup
and Restore Considerations for Virtualized Domain Controllers", доступном по ссылке:
Использование VSS для резервного копирования

Hyper-V и виртуальных машин
При использовании интерфейса модуля записи VSS для Hyper-V резервное копирова-
ние инфраструктуры Hyper-V проще, чем при использовании традиционных методов
резервного копирования. Однако до реализации стратегии резервного копирования на

основе VSS вы должны определить существующие в вашей инфраструктуре Hyper-V
сценарии и убедиться, что ваша среда соответствует требованиям табл. 13.1. Как уже
упоминалось ранее, тремя основными категориями резервного копирования (при по-
мощи модуля записи VSS для Hyper-V) являются следующие:
копирование конфигурационной информации Hyper-V;
оперативное копирование виртуальной машины;
автономное копирование виртуальной машины.
Таблица 13.1. Сценарии резервного копирования при помощи VSS
Резервное копирование
Сценарий Требования
с использованием VSS
Сервер Hyper-V Windows Server 2008 Hyper-V или Конфигурационная инфор-
Microsoft Hyper-V Server 2008 мация Hyper-V
Windows Server 2003 Виртуальная машина без удаленных Оперативное резервное
и более поздние версии виртуальных жестких дисков или без копирование виртуальной
дисков iSCSI. Виртуальная машина машины
с последней версией служб интеграции
Windows Server 2003 Виртуальная машина без удаленных Автономное резервное
и более поздние версии виртуальных жестких дисков или копирование виртуальной
(без служб интеграции) без дисков iSCSI машины
Windows XP SP2 и более Виртуальная машина без удаленных Автономное резервное
поздние версии виртуальных жестких дисков или без копирование виртуальной
дисков iSCSI. Виртуальная машина машины
с последней версией служб интеграции
Windows XP SP2 и более Виртуальная машина без удаленных Автономное резервное
поздние версии (без служб виртуальных жестких дисков или копирование виртуальной
интеграции) без дисков iSCSI машины
Windows Server 2000 Виртуальная машина без удаленных Автономное резервное
и более ранние версии виртуальных жестких дисков или копирование виртуальной
без дисков iSCSI машины
Операционная система Виртуальная машина без удаленных Автономное резервное
не из семейства Windows виртуальных жестких дисков или копирование виртуальной
без дисков iSCSI машины
Без прерывания обслуживания (в оперативном режиме) при помощи VSS можно сде-
лать резервное копирование только Windows Vista и более новых клиентских операци-
онных систем, а также Windows Server 2003 и более новых серверных операционных
систем. Ранние версии операционных систем Windows и операционные системы не из
семейства Windows не поддерживают службу Volume Shadow Copy Service и поэтому
не имеют механизма для приведения системы в состояние покоя (чтобы обеспечить
непротиворечивость данных).
После того как вы определили различные сценарии резервного копирования для вашей
среды, вы должны определить и использующее VSS приложение резервного копирова-
ния, которое будете применять для защиты вашей инфраструктуры виртуализации.
Если в вашей среде есть только несколько серверов Hyper-V, то вы можете использо-
вать приложение Windows Server Backup, которое включено в состав сервера Windows
Server 2008. Если вы развертываете целую ферму серверов Hyper-V или управляете ею,
тогда вам следует рассмотреть вариант использования System Center Data Protection
Manager 2007 SP1.
Использование менеджера
System Center Data Protection Manager 2007 SP1
Менеджер System Center Data Protection Manager 2007 SP1 использует VSS для того,
чтобы дать вам возможность выполнять резервное копирование виртуальных машин
Hyper-V на уровне сервера. При резервном копировании Hyper-V на уровне сервера вы
инсталлируете агент DPM только на сервере Hyper-V, а не в каждой виртуальной ма-
шине. При помощи такого метода резервного копирования вы можете восстановить
целиком виртуальную машину, а не гостевую операционную систему или файлы дан-
ных. Такой тип резервного копирования делает возможным восстановление исходного
состояния виртуальной машины. DPM 2007 SP1 обеспечивает резервное копирование и
восстановление для следующих продуктов виртуализации компании Microsoft:
Windows Server 2008 Hyper-V;
Hyper-V Server 2008;
Virtual Server 2005 R2.
System Center DPM 2007 SP1 обеспечивает также резервное копирование и восстановле-
ние для Windows Server 2008 и таких приложений компании Microsoft, как Exchange Server
2007, SQL Server 2008 и Office Sharepoint Server 2007. Подробности см. по ссылке:
http://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/default.aspx.
При помощи DPM 2007 SP1 вы можете выполнять оперативное резервное копирование
виртуальных машин Hyper-V (при помощи служб интеграции и VSS), а также тех вир-
туальных машин, которые работают на сервере Virtual Server 2005 R2 с дополнениями
Virtual Machine Additions и службой VSS. Когда DPM 2007 SP1 выполняет оперативное
резервное копирование виртуальной машины, то он дает серверу Hyper-V указание
перевести виртуальную машину в состояние приостановки, создает теневую копию, а
затем дает Hyper-V указание перевести виртуальную машину обратно в оперативный
режим. DPM 2007 SP1 продолжает обработку теневой копии и может скопировать на-
бор данных резервного копирования на ленту или любой другой сервер DPM (без
дальнейшего прерывания обслуживания).
Менеджер DPM 2007 SP1 поддерживает также и автономное резервное копирование не
имеющих поддержки VSS виртуальных машин. Для выполнения автономного резерв-
ного копирования DPM 2007 SP1 дает серверу Hyper-V указание перевести виртуаль-
ную машину в сохраненное состояние, создает теневую копию, а затем дает указание
Hyper-V вернуть виртуальную машину в оперативное состояние. При помощи такого
процесса резервного копирования (в автономном режиме) минимизируется прерывание
обслуживания виртуальной машины.
Если вам нужна возможность восстановления отдельных файлов виртуальной машины
или вы хотите обеспечить резервное копирование и восстановление только определен-
ного (работающего в виртуальной машине) приложения, то DPM 2007 SP1 поддержи-
вает развертывание агента в гостевой операционной системе. Для восстановления це-

лой виртуальной машины или отдельных файлов вы можете сделать резервное копиро-
вание виртуальной машины Hyper-V на уровне сервера (в сочетании с копированием
нужных данных при помощи развернутого в гостевой операционной системе агента
DPM). Однако вы должны убедиться, что вы не запланировали выполнение обеих этих
резервных копий на одно и то же время.
Менеджер DPM 2007 SP1 поддерживает резервное копирование и восстановление серве-
ров Windows Server 2008 с ролью Hyper-V в варианте инсталляции Server Core, а также
кластерных серверов Hyper-V.
Если в вашей нынешней среде есть развернутые серверы DPM 2007, то для успешного
копирования и восстановления (при помощи резервного копирования на уровне серве-
ра Hyper-V) конфигурационной информации Hyper-V и виртуальных машин вам нужно
выполнить следующие основные шаги:
1. Обновить серверы Hyper-V обновлениями KB956697 и KB959962.
2. Обновить службы интеграции виртуальных машин.
3. Инсталлировать DPM 2007 SP1.
4. Развернуть агенты DPM 2007 SP1 на серверах Hyper-V.
5. Сконфигурировать DPM 2007 SP1.
KB956697 содержит обновление службы VMMS, которое гарантирует распознавание и
правильное применение (при резервном копировании с использованием VSS) модуля
записи VSS для Hyper-V. KB959962 содержит обновленные файлы для основных ком-
понентов Hyper-V (и в том числе служб интеграции). Обновленные службы интеграции
Integration Services должны быть инсталлированы на всех поддерживаемых виртуаль-
ных машинах (чтобы обеспечить успешное выполнение резервного копирования
DPM 2007 SP1).
Вы можете скачать KB956697 по ссылке http://support.microsoft.com/kb/956697, а
KB959962 — по ссылке http://support.microsoft.com/kb/959962.
Обновление служб интеграции виртуальных машин

Когда вы инсталлируете на сервере Hyper-V обновление KB959962, в систему копиру-
ется новый файл Vmguest.iso. Этот файл содержит обновленную версию служб инте-
грации, которую вы должны инсталлировать на все поддерживаемые виртуальные ма-
шины, которые вы хотите копировать при помощи DPM 2007 SP1.
Если вы хотите определить инсталлированную в виртуальной машине версию служб
интеграции, выполните следующие шаги:
1. Откройте менеджер Hyper-V Manager, щелкните правой кнопкой мыши по вирту-
альной машине и выберите пункт Connect.
2. Зарегистрируйтесь в гостевой операционной системе и откройте Device Manager
в панели Control Panel.
3. Разверните System Devices, щелкните правой кнопкой мыши по Hyper-V Volume

Shadow Copy, а затем выберите пункт Properties.
4. В диалоговом окне Hyper-V Volume Shadow Copy Properties перейдите на вкладку
Driver.
5. Как показано на рис. 13.2, свойство Driver Version отражает номер версии служб
интеграции Integration Services. В данном случае номер версии 6.0.6001.18016 (эта
версия была выпущена вместе с сервером Hyper-V).
6. Нажмите кнопку OK, чтобы закрыть диалоговое окно.
Рис. 13.2. Диалоговое окно Hyper-V Volume Shadow Copy Properties
Для инсталляции (в виртуальной машине) новой версии служб интеграции выполните

1. Откройте менеджер Hyper-V Manager, щелкните правой кнопкой мыши по вирту-
альной машине и выберите пункт Connect.
2. Зарегистрируйтесь в гостевой операционной системе под учетной записью с права-
ми локального администратора.
3. В меню Action приложения Virtual Machine Connection (рис. 13.3) выберите команду
Insert Integration Services Setup Disk.
4. Откройте в виртуальной машине Windows Explorer и дважды щелкните по дисково-
ду CD/DVD.
5. В диалоговом окне Upgrade Hyper-V Integration Services (рис. 13.4) нажмите
кнопку OK, чтобы начать инсталляцию.
Рис. 13.3. Меню Action приложения Virtual Machine Connection
Рис. 13.4. Диалоговое окно Upgrade Hyper-V Integration Services
6. В диалоговом окне Installation Complete нажмите кнопку Yes для перезапуска вир-
туальной машины.
7. После перезагрузки виртуальной машины повторно подключитесь к ней и убеди-
тесь, что в свойстве Driver Version показана версия 6.0.6001.22334 (или более позд-
няя).
8. Выйдите из виртуальной машины и закройте сеанс Virtual Machine Connection.
Инсталляция
System Center Data protection Manager 2007 SP1
Вы можете бесплатно получить обновление DPM 2007 SP1 на Web-сайте компании
Microsoft (по ссылке: http://technet.microsoft.com/en-us/dpm/dd296757.aspx). Для ин-
сталляции обновления DPM 2007 SP1 на всех серверах DPM 2007 (которые вы хотите
использовать для выполнения резервного копирования на уровне сервера Hyper-V) вы-
1. Убедитесь в том, что в данный момент не выполняется ни одно резервное копиро-
вание.
2. Дважды щелкните обновление DPM 2007 SP1.
3. На странице Welcome (рис. 13.5) просмотрите все предупреждения, примите соот-
ветствующие меры, а затем нажмите кнопку Next.
Рис. 13.5. Страница Welcome инсталлятора DPM 2007 SP1
4. На странице License agreement просмотрите информацию, а затем выберите вари-

ант I Accept (если вы согласны с условиями лицензии).
5. Нажмите кнопку Next, чтобы начать инсталляцию DPM 2007 SP1 (рис. 13.6).
6. На странице Installation Success (рис. 13.7) нажмите кнопку Close.
7. Нажмите кнопку OK в диалоговом окне с запросом на перезагрузку сервера Hyper-V.
Активация локальной защиты данных в DPM 2007 SP1

Хотя это и не рекомендуется, но вы можете инсталлировать DPM 2007 SP1 на сервере
Hyper-V и создавать локальные резервные копии конфигурации Hyper-V и виртуаль-
ных машин. Однако DPM 2007 SP1 не позволит вам делать такие резервные копии до
тех пор, пока вы не активируете защиту локальных данных Local Data Protection. Вы
можете активировать Local Data Protection (при помощи ядра управления DPM) по-
средством ввода такой команды:
Set-DMGGlobalProperty –AllowLocalDataProtection $true
Рис. 13.6. Процесс инсталляции DPM 2007 SP1
Рис. 13.7. Страница Installation Success инсталляции DPM 2007 SP1

Если вы хотите отключить защиту Local Data Protection, то введите такую команду:
Set-DMGGlobalProperty –AllowLocalDataProtection $false
Не следует использовать локальное резервное копирование сервера DPM в качестве един-
ственного метода защиты конфигурации и виртуальных машин сервера Hyper-V, а также
данных сервера DPM 2007 SP1. Для того чтобы обеспечить восстановление после полной
потери сервера Hyper-V, на котором также работает DPM 2007 SP1, вам следует сохранять
резервные копии на ленты и хранить их вне пределов данной производственной площадки,
либо делать резервное копирование локального сервера при помощи находящегося на дру-
гой площадке сервера DPM 2007 SP1, сохранять резервные копии на ленту и хранить их за
пределами площадки (в соответствии с вашими политиками управления и безопасности).
Развертывание агента менеджера DPM 2007 SP1

Чтобы выполнять резервное копирование виртуальных машин на уровне сервера
Hyper-V, вы должны инсталлировать на сервере агента DPM. После инсталляции DPM
2007 SP1 он сможет перечислить серверы, которые он может защитить (из вашего
Active Directory) и представить их как цели для развертывания агента DPM. Вы можете
инициировать инсталляцию агента DPM из консоли DPM 2007 Administrator Console, а
также через политику Active Directory Group Policy, либо при помощи таких ин-
струментов управления, как System Center Configuration Manager 2007 или Systems
Management Server 2003.
Чтобы развернуть на сервере агента DPM, вам может понадобиться отключить сетевой эк-
ран Windows Firewall. После развертывания агента откройте порт TCP с номером 135 и
укажите файл агента DPM (Data Protection Manager\DPM\bin\MsDpmFsAgentCA.exe) в каче-
стве исключения для сетевого экрана Windows Firewall.
Для выполнения инсталляции агента DPM на сервере Hyper-V при помощи консоли
DPM 2007 Administrator Console выполните следующие шаги:
1. Откройте консоль DPM 2007 Administrator Console, выберите область задач
Management, а затем выберите вкладку Agents (рис. 13.8).
2. В панели Actions выберите Install для запуска мастера Protection Agent Installation
Wizard.
3. На странице Select Computers менеджер DPM 2007 SP1 показывает список серве-
ров, собранный в домене Active Directory (куда входит и сам сервер DPM 2007 SP1).
Этот список серверов (рис. 13.9) представляет собой список потенциальных целей
для развертывания агента DPM.
4. Выберите те серверы Hyper-V, на которые вы хотите разместить агент DPM, и на-
жмите кнопку Add для переноса их в список Selected Computers. После выполне-
ния ваших настроек нажмите кнопку Next.
5. На странице Enter Credentials (рис. 13.10) введите имя и пароль пользователя
с учетной записью из группы администраторов домена (для выбранных серверов),
Рис. 13.8. Область задач Management в консоли DPM 2007 Administrator Console
Рис. 13.9. Страница Select Computers мастера Protection Agent Installation Wizard
Рис. 13.10. Страница Enter Credentials мастера Protection Agent Installation Wizard
6. Как показано на рис. 13.11, DPM 2007 SP1 может выдать вам предупреждение, что
он не смог определить, не являются ли выбранные компьютеры кластерными. По-
сле прочтения информации нажмите кнопку OK.
Рис. 13.11. Предупреждение о кластеризации из DPM 2007 SP1
7. На странице Choose Restart Method (рис. 13.12) у вас есть следующие варианты:
• если вы хотите, чтобы сервер Hyper-V автоматически перезагрузился после ин-
сталляции агента DPM 2007, то выберите вариант Yes. Restart the selected
computers after installing the protection agents;
• если вы хотите перезагрузить сервер Hyper-V вручную после инсталляции агента

DPM 2007, то выберите вариант No. I will restart the selected computers later.
Рис. 13.12. Страница Choose Restart Method мастера Protection Agent Installation Wizard
8. После выбора нажмите кнопку Next.

9. На странице Summary (рис. 13.13) просмотрите сделанные вами настройки, а за-
тем нажмите кнопку Install.
10. На странице Installation вы можете наблюдать за процессом инсталляции агента
DPM. Вы можете также закрыть мастер Protection Agent Installation Wizard и на-
блюдать за процессом инсталляции в представлении Agents консоли DPM
Administrator Console.
11. По завершении инсталляции агента DPM (рис. 13.14) нажмите кнопку Close.
12. В консоли DPM 2007 Administrator Console на вкладке Agents щелкните по пункту
Refresh information в панели Action. Если сервер DPM 2007 SP1 успешно под-
ключился к агенту DPM сервера Hyper-V, то в столбце Agent Status будет указан
статус OK (рис. 13.15).
Рис. 13.13. Страница Summary мастера Protection Agent Installation Wizard
Рис. 13.14. Страница Installation мастера Protection Agent Installation Wizard

Рис. 13.15. Статус агента DPM в консоли DPM 2007 Administrator Console
Конфигурирование пула хранения

менеджера DPM 2007 SP1
Следующим шагом конфигурирования DPM 2007 SP1 является выделение дисков для
создания пула хранения. Пул хранения DPM включает в себя один или несколько ди-
намических томов, которые используются исключительно для хранения данных ре-
зервного копирования DPM. DPM 2007 SP1 отформатирует эти тома, так что все ранее
хранившиеся там данные будут утрачены. DPM 2007 SP1 может использовать три типа
дискового пространства:
Direct Attached Storage (DAS);
Storage Area Networks (SAN);
диски iSCSI.
Для выделения динамических томов под создание пула хранения DPM 2007 SP1 вы-
1. Откройте консоль DPM 2007 Administrator Console, выберите область задач
Management, а затем выберите вкладку Disks (рис. 13.16).
2. В панели Actions выберите пункт Add.
3. В диалоговом окне Add Disks to Storage Pool (рис. 13.17) вам представлен список
всех имеющихся дисков, которые DPM 2007 SP1 может использовать как часть пу-
ла хранения. Выберите те диски, которые вы хотите добавить в пул хранения, а за-
тем нажмите кнопку Add. По завершении выбора нажмите кнопку OK.
Рис. 13.16. Вкладка Disks консоли DPM 2007 Administrator Console
Рис. 13.17. Диалоговое окно Add Disks to Storage Pool

4. DPM 2007 SP1 может выдать вам предупреждение, что выбранные диски будут
преобразованы в динамические и все существующие тома будут преобразованы
в простые тома (рис. 13.18). После прочтения этой информации нажмите кнопку Yes.
Рис. 13.18. Предупреждение в DPM 2007 SP1 о преобразовании дисков
5. В консоли DPM 2007 Administrator Console на вкладке Disks вы увидите список

дисков, добавленных в пул хранения (рис. 13.19).
Рис. 13.19. Заполненный пул хранения в консоли DPM 2007 Administrator Console
Конфигурирование группы защиты DPM 2007 SP1

После конфигурирования пула хранения DPM 2007 SP1 для выполнения резервного
копирования виртуальных машин (на уровне сервера Hyper-V) вы должны сконфигу-
рировать группу защиты. Группа защиты позволяет вам определить все подробности
резервного копирования (конфигурационная информация Hyper-V, виртуальные маши-

ны и прочие ресурсы, которые вы хотите включить в состав резервной копии). Вы мо-
жете также определить расписание резервного копирования, срок хранения резервной
копии, расписание копирования на ленту (не обязательно, но рекомендуется), а также
точки восстановления.
Для конфигурирования группы защиты DPM 2007 SP1 выполните следующие шаги:
1. Откройте консоль DPM 2007 Administrator Console и выберите область задач
Protection (рис. 13.20).
Рис. 13.20. Область задач Protection консоли DPM 2007 Administrator Console
2. В панели Actions выберите пункт Create protection group.

3. На странице Welcome to the New Protection Group Wizard (рис. 13.21) просмотри-
те информацию о группах защиты, а затем нажмите кнопку Next.
4. На странице Select Group Members разверните целевой сервер Hyper-V, а затем
разверните элемент Microsoft Hyper-V (рис. 13.22).
5. Для каждой работающей на сервере Hyper-V виртуальной машины вы можете уви-
деть тип резервного копирования (с использованием VSS), который можно выпол-
нить. Резервное копирование в оперативном режиме возможно в том случае, когда
перед названием виртуальной машины присутствует Backup Using Child Partition
Snapshot; резервное копирование в автономном режиме обозначено как Backup
Using Saved State. Элемент Initial Store представляет собой хранилище авторизации
Authorization Manager для сервера Hyper-V.
Рис. 13.21. Страница Welcome to the New Protection Group Wizard
Рис. 13.22. Страница Select Group Members

6. Выберите те виртуальные машины, которые вы хотите включить в группу защиты, а

также Initial Store, а затем нажмите кнопку Next.
7. На странице Select Data Protection Method (рис. 13.23) введите название для груп-
пы защиты и выберите такой метод защиты, который соответствует требованиям
вашей стратегии резервного копирования. В нашем примере выбрана краткосрочная
защита (на дисках), но для стратегии восстановления после катастроф следует ис-
пользовать долгосрочную защиту (на лентах).
Рис. 13.23. Страница Select Data Protection Method
8. На странице Specify Short-Term Goals введите нужный срок хранения (рис. 13.24).
Срок по умолчанию равен 5 дням.
9. После выполнения выбора нажмите кнопку Next.
10. На странице Review Disk Allocation (рис. 13.25) нажмите кнопку Modify для на-
стройки выделения дискового пространства, чтобы обеспечить достаточное коли-
чество места для резервных копий, затем нажмите кнопку Next.
11. На странице Choose Replica Creation Method (рис. 13.26) у вас есть следующие
варианты.
• Если вы хотите, чтобы DPM 2007 SP1 создал исходную реплику при помощи
передачи данных по сети, то установите переключатель Automatically. Если вы
выбираете этот вариант, то вам, возможно, понадобится установить переключа-
тель Later и указать для передачи данных такое время, когда сеть не очень
загружена. После этого нажмите кнопку Next.
Рис. 13.24. Страница Specify Short-Term Goals
Рис. 13.25. Страница Review Disk Allocation

Рис. 13.26. Страница Choose Replica Creation Method

Рис. 13.28. Страница Status
Рис. 13.29. Состояние реплики в консоли DPM 2007 Administrator Console

• Если вы хотите создать реплику на сервере DPM 2007 SP1 на сменных носите-
лях, отметьте переключатель Manually. Если ваш сервер Hyper-V подключен по
медленной глобальной сети (WAN), то вам, возможно, лучше выбрать именно
этот вариант. После выбора нажмите кнопку Next.
12. На странице Summary (рис. 13.27) просмотрите сделанные вами настройки, убеди-
тесь в точности этой информации, а затем нажмите кнопку Create Group.
13. На странице Status вы можете следить за процессом создания группы (рис. 13.28).
14. После завершения процесса нажмите кнопку Close.
15. Вы можете следить за созданием реплики в консоли DPM 2007 Administrator
Console (рис. 13.29).
Восстановление виртуальной машины

при помощи DPM 2007 SP1
После конфигурирования группы защиты DPM 2007 SP1 и создания одной или более
теневых копий виртуальных машин вы можете восстанавливать виртуальные машины.
Для этого вы должны выбрать имеющуюся резервную копию и определить место ее
восстановления (исходное или альтернативное).
Для восстановления виртуальной машины при помощи DPM 2007 SP1 выполните сле-
1. Откройте консоль DPM 2007 Administrator Console и выберите область задач
Recovery (рис. 13.30).
2. В левой панели разверните узел Data on Disk and Tapes, элемент домена, элемент
сервера Hyper-V и элемент All DPM Protected Data (рис. 13.31).
3. В левой панели выберите виртуальную машину для восстановления, а затем дату и
время нужной точки восстановления (в средней панели).
4. В средней панели выберите Recoverable Item, а затем выберите пункт Recover
в панели Actions (справа) для запуска мастера Recovery Wizard.
5. На странице Review Recovery Selection (рис. 13.32) проверьте точность информа-
ции, а затем нажмите кнопку Next.
6. На странице Select Recovery Type (рис. 13.33) у вас есть следующие варианты:
• если вы хотите при восстановлении перезаписать файлы в исходном каталоге, то
выберите переключатель Recover to original instance;
• если вы хотите восстановить файлы в другое местоположение, то отметьте пере-
ключатель Copy to a network folder;
• если вы хотите сохранить файлы на ленту для отправки на другую площадку, то
установите переключатель Copy to tape.
7. После выбора нажмите кнопку Next.
Рис. 13.30. Область задач Recovery в консоли DPM 2007 Administrator Console
Рис. 13.31. Выбор точки восстановления виртуальной машины

Рис. 13.32. Страница Review Recovery Selection
Рис. 13.33. Страница Select Recovery Type

8. На странице Specify Recovery Options (рис. 13.34) у вас есть следующие варианты:
• для ограничения используемой полосы пропускания сети и указания пределов
полосы пропускания для рабочих и нерабочих часов щелкните по ссылке
Modify;
• если вы используете SAN с функцией аппаратных моментальных снимков, ус-
тановите флажок Enable SAN based recovery using hardware snapshots;
• для того чтобы DPM 2007 SP1 отправлял почтовые сообщения о процессе вос-
становления, воспользуйтесь группой Notification.
Рис. 13.34. Страница Specify Recovery Options
9. После завершения всех настроек нажмите кнопку Next.

10. На странице Summary (рис. 13.35) проверьте точность указанной вами информа-
ции, а затем нажмите кнопку Recover, чтобы начать процесс восстановления.
11. На странице Recovery Status вы можете следить за процессом восстановления
(рис. 13.36).
12. Нажмите кнопку Close для возвращения в консоль DPM 2007 Administrator
Console.
13. В консоли DPM 2007 Administrator Console щелкните по области задач Monitoring,
перейдите на вкладку Jobs, а затем выберите Protection group в раскрывающемся
списке Group by (рис. 13.37).
Рис. 13.36. Страница Recovery Status

Рис. 13.37. Область задач Monitoring консоли DPM 2007 Administrator Console
14. Разверните узел Total jobs, чтобы следить за процессом восстановления.

15. Если процесс восстановления завершится успешно, то рядом с соответствующей
задачей появится зеленый шарик с галочкой.
Резюме
Сервер Hyper-V предоставляет модуль записи VSS, который позволяет приложениям
вроде Windows Server Backup и System Center DPM 2007 SP1 обеспечивать службы ре-
зервного копирования и восстановления для вашей инфраструктуры виртуализации.
Приложения на основе VSS могут при помощи теневых копий значительно упростить
резервное копирование (и сократить его время) конфигурационной информации серве-
ра Hyper-V и виртуальных машин. Если имеются службы интеграции и они установле-
ны в гостевой операционной системе виртуальной машины (и поддерживается VSS),
тогда виртуальную машину можно копировать без прерывания обслуживания (опера-
тивное резервное копирование). Если гостевая операционная система виртуальной ма-
шины не поддерживает VSS, то прерывание обслуживания будет минимизировано за
счет перевода машины в сохраненное состояние на время создания теневой копии (ав-
тономное резервное копирование). Если выполнение резервных копий виртуальных
машин с использованием VSS невозможно, то вы можете реализовать обычные спосо-
бы резервного копирования при помощи инсталлированного в гостевую операционную
систему агента. Для резервного копирования и восстановления контроллеров домена

Active Directory необходимо следовать строгой процедуре (во избежание нарушений
топологии репликации и повреждения базы данных Active Directory). До использова-
ния DPM 2007 SP1 для резервного копирования и восстановления серверов Hyper-V вы
должны инсталлировать определенные обновления на серверы Hyper-V, инсталлиро-
вать новую версию служб интеграции на поддерживаемых виртуальных машинах, раз-
вернуть агенты DPM на серверах Hyper-V, сконфигурировать пул хранения DPM 2007
SP1 для хранения резервных копий, а также настроить одну или несколько групп защи-
ты (которые определяют цели, расписание, метод защиты и срок хранения резервных
копий).

статья "How Volume Shadow Copy Service Works" в Microsoft TechNet доступна по
ссылке: http://technet.microsoft.com/en-us/library/cc785914.aspx;
Web-сайт компании Microsoft, документ "Windows SDK for Windows Server 2008 and
.NET Framework 3.5" доступен по ссылке http://www.microsoft.com/downloads
/details.aspx?familyid=F26B1AA4-741A-433A-9BE5-FA919850BDBF;
Web-сайт компании Microsoft, документ "What’s New in DPM 2007 Service Pack 1"
доступен по ссылке
http://www.microsoft.com/systemcenter/dataprotectionmanager/en/us
/whats-new.aspx;
Web-сайт компании Microsoft, документ "What’s New in Microsoft System Center
Data Protection Manager 2007 Service Pack 1" доступен по ссылке:
ГЛАВА 14
Миграция серверов
при помощи менеджера
System Center Virtual Machine Manager
Менеджер System Center Virtual Machine Manager (SCVMM) 2008 — это решение ком-
пании Microsoft для миграции физических серверов на виртуальные машины и мигра-
ции виртуальных машин VMware на платформу Microsoft. Это делается посредством
миграции физического сервера либо во время его работы (когда он включен), либо при
помощи выключения сервера и миграции в автономном состоянии. Выбираемый вами
вариант будет зависеть от используемой вами операционной системы и от рекоменда-
ций лучших практик. В этой главе будут объяснены опции миграции, а также требова-
ния и процедуры для выполнения оперативных и автономных миграций с физической
машины на виртуальную.
Опции миграции
Миграция сервера из физического мира в виртуальный может быть полезной тогда,
когда вы реализуете проект по консолидации недоиспользуемых физических серверов.
Но даже если серверы и недоиспользуются, это не означает, что вы можете себе позво-
лить длительное время простоя. Менеджер System Center Virtual Machine Manager 2008
предоставляет инструмент миграции серверов с физических на виртуальные (P2V)
и с виртуальных на виртуальные (V2V). Этот инструмент использует службу теневого
копирования Volume Shadow Copy Service (VSS) для преобразований в оперативном
режиме, чтобы минимизировать простои тех операционных систем, которые предос-
тавляют поддержку VSS.
Для поддерживающих VSS операционных систем работающий сервер может сделать
моментальный снимок VSS и передать информацию из этого моментального снимка
(без всякого простоя сервера). Это называется оперативной миграцией P2V. Для не
поддерживающих моментальные снимки VSS операционных систем требуется другой
подход. Такие машины необходимо выключать и загружать с образа Windows
PreInstallation Environment (WinPE). Этот образ позволяет получить неограниченный
доступ к жестким дискам сервера, чтобы послать поток данных с жесткого диска по
сети на вновь создаваемую виртуальную машину. Это называется автономной мигра-

цией P2V.
В табл. 14.1 приведена разбивка операционных систем по признакам поддержки ми-
граций P2V (автономных и оперативных) и миграций V2V.
Таблица 14.1. Опции миграции
Операционная система Оперативная P2V Автономная P2V V2V
Windows Server 2008 с ролью Hyper-V Нет Нет Нет
Windows Server 2008 без роли Hyper-V Да Да Да
Windows Server 2003 SP1 и более поздние Да Да Да
Windows Server 2003 х64 SP1 и более поздние Да Да Да
Windows 2000 Server SP4 Нет Да Да
Windows Vista Да Да Да
Windows Vista x64 Да Да Да
Windows XP SP2 и более поздние Да Да Да
Windows XP х64 SP2 и более поздние Да Да Да
SCVMM 2008 не поддерживает миграцию с физической машины на виртуальную для
Windows NT 4.0. Если вам нужно мигрировать физический сервер Windows NT 4.0 на Hyper-V,
то для этого компания Microsoft предоставляет набор Virtual Server Migration Toolkit (VSMT).
При помощи VSMT вы должны сначала мигрировать физический сервер на виртуальную
машину под управлением Virtual Server 2005 R2 SP1, а затем мигрировать виртуальную
машину на Hyper-V. Другой вариант — использовать инструмент миграции P2V стороннего
поставщика, который сможет мигрировать физический сервер Windows NT 4.0 напрямую на
Hyper-V.
Информацию по использованию VSMT для миграции физического сервера Windows NT 4.0
на виртуальную машину под управлением сервера Virtual Server 2005 R2 SP1 см. в главе 10
книги Robert Larson, Janique Carbone, Windows Virtualization Team. Virtual Server 2005 R2
Resource Kit. — Microsoft Press, 1997.
Требования для миграции

Для выполнения миграции с физической машины на виртуальную (или с виртуальной
на виртуальную) система SCVMM должна понять конфигурацию исходного сервера,
понять возможности целевой виртуальной машины и знать, как выполнить такой пере-
ход. Это налагает определенные требования на исходную систему (с точки зрения ее
размера и состояния); например, вам может потребоваться установить дополнительные
драйверы или программные заплатки; вам также нужно будет убедиться в том, что от-
крыты определенные пути обмена.
Глава 14. Миграция серверов при помощи менеджера System Center Virtual Machine... 539
Требования для сервера SCVMM и целевого хоста для миграций P2V и V2V:
для миграций P2V целевой хост должен работать под управлением сервера Windows
Server 2008 с ролью Hyper-V, сервера Microsoft Hyper-V Server 2008 или сервера
Virtual Server 2005 R2 SP1; он должен управляться с сервера SCVMM (выполняю-
щего миграцию P2V);
для миграции P2V вам может понадобиться добавить некоторые файлы во внутрен-
ний кэш программных заплаток SCVMM. Мастер P2V подскажет вам, какие именно
обновления необходимы;
при миграции V2V в наличии должен иметься целевой хост под управлением Hyper-V
(для размещения новой виртуальной машины).
Требования к исходному серверу:
во время автономного преобразования P2V вы должны иметь в наличии драйверы
для сетевых интерфейсов и интерфейсов систем хранения (чтобы WinPE могла вы-
полнить перенос во время миграции). Возможно, что вам понадобится добавить эти
драйверы (для оборудования исходного сервера) на носитель с WinPE;
для автономного преобразования P2V исходная машина должна иметь, по меньшей
мере, 512 Мбайт физической памяти;
для автономного преобразования P2V исходный сервер должен иметь BIOS с под-
держкой Advanced Configuration and Power Interface (ACPI);
исходный сервер не может иметь плохих секторов, иначе миграция закончится не-
удачей. Перед миграцией запустите на исходной машине инструмент обслуживания
дисков (такой, как chkdsk);
исходный сервер должен либо находиться в рабочей группе, либо быть членом того
домена, в котором инсталлирован SCVMM, либо находиться в домене, с которым
домен SCVMM имеет двусторонние доверительные отношения;
исходный сервер должен быть доступен по сети из VMM и из того сервера Hyper-V,
на котором он будет размещен.
Оперативная миграция
с физической машины на виртуальную
Оперативные миграции P2V возможны почти для всех операционных систем Windows,
которые поддерживаются сервером Hyper-V и менеджером SCVMM 2008 (за исключе-
нием Windows Server 2000). Во время оперативной миграции на исходный сервер ко-
пируется агент, делается моментальный снимок VSS и этот моментальный снимок VSS
передается по сети во вновь создаваемую виртуальную машину на сервере Hyper-V.
Когда копирование завершается, то новая виртуальная машина модифицируется, чтобы
обеспечить загрузку правильного hardware abstraction layer (HAL) и драйверов, а также
инсталляцию служб интеграции. Во время этого процесса производительность исход-
ного физического сервера (из-за создания моментального снимка и передачи его по
сети) снижается очень незначительно.
Процесс миграции P2V использует свой мастер для сбора необходимой информации,
принятия решений на основе этой информации, а также создания задания, которое бу-
дет запущено для выполнения миграции. Мастер миграции выполняет для оперативной
миграции P2V следующие шаги:
1. Проверяем выполнение предварительных условий (перед запуском мастера).
2. Указываем исходный физический сервер.
3. Даем название виртуальной машине.
4. Собираем системную информацию по исходному физическому серверу.
5. Модифицируем конфигурацию томов.
6. Модифицируем конфигурацию процессоров и памяти мигрированной виртуальной
машины.
7. Выбираем сервер Hyper-V для размещения.
8. Выбираем путь для размещения файлов виртуальной машины.
9. Выбираем соответствие сетей для каждого сетевого адаптера.
10. Выбираем дополнительные свойства (вроде действий при запуске и останове).
11. Решаем все потенциальные проблемы преобразования.
12. Запускаем процесс преобразования.
Во время фактического выполнения задания миграции выполняются следующие дей-
ствия:
1. Создается новая виртуальная машина.
2. Делается моментальный снимок VSS исходного сервера.
3. Моментальный снимок VSS исходной машины упаковывается в формат VHD и пе-
редается на целевой сервер Hyper-V.
4. С исходного физического сервера удаляется агент.
5. Модифицируется оборудование виртуальной машины.
Оперативная миграция P2V и контроллеры домена Active Directory
Во время процесса преобразования P2V новая виртуальная машина и физический кон-
троллер домена не должны быть включены одновременно (во избежание возникновения
ситуации отката USN, описанной в приложении А документа "Running Domain Controllers in
Hyper-V", доступного по ссылке: http://technet.microsoft.com/en-us/library/57eab7f4-3563-
407f-8e4c-a87f908aa3c2).
Преобразование P2V контроллера домена следует выполнять в автономном режиме, чтобы
при включении контроллера домена обратно в работу данные его каталога были непроти-
воречивыми. Во время преобразования P2V виртуальная машина не должна быть подклю-
чена к сети. Сетевая карта виртуальной машины должна быть активирована только после
завершения (и проверки) процесса преобразования. В этот момент физическая исходная
машина должна быть выключена. Не подключайте исходную физическую машину к сети до
полного переформатирования ее жесткого диска.
Грегори Гуэтат (Gregoire Guetat, Program Manager (Directory Services Product Group))
Рис. 14.1. Страница Select Source
Следующие шаги проведут вас по процедуре преобразования сервера Windows

Server 2003 с названием PHYSICAL1, который является членом того же домена, что и
сервер SCVMM.
1. В меню Actions в SCVMM выберите команду Convert Physical Server.
2. На странице Select Source (рис. 14.1) введите имя того физического компьютера,
который вы хотите преобразовать; введите данные учетной записи, которая имеет
права локального администратора на сервере; затем нажмите кнопку Next.
3. На странице Virtual Machine Identity введите название виртуальной машины, мо-
дифицируйте владельца виртуальной машины, введите описание (по желанию), а
затем нажмите кнопку Next.
4. На странице System Information (рис. 14.2) нажмите кнопку Scan System для ска-
нирования физического сервера. Когда сканирование закончится, в поле системной
информации внизу будет показана операционная система, количество процессоров,
информация по жестким дискам и сетевым адаптерам. Когда вы закончите про-
смотр этой информации, нажмите кнопку Next.
Во время сканирования системы менеджер VMM копирует на исходную машину инструмент
Vmmp2vagent.exe. Именно этот инструмент сканирует систему и передает системную ин-
формацию в мастер преобразования. Инструмент Vmmp2vagent также запрашивает момен-

тальный снимок VSS и передает его во время процесса преобразования.
Рис. 14.2. Страница System Information
5. На странице Volume Configuration (рис. 14.3) измените тип жесткого диска, его
размер, а также адаптер, к которому том должен быть подключен. В этот момент вы
можете увеличить размер жесткого диска (если виртуальной машине нужно больше
дискового пространства). После выполнения всех необходимых изменений нажмите
кнопку Next.
6. На странице Virtual Machine Configuration (рис. 14.4) вы увидите, что можно мо-
дифицировать количество выделяемых новой виртуальной машине процессоров и
памяти. Сделайте все необходимые изменения, а затем нажмите кнопку Next.
7. На странице Select Host (рис. 14.5) доступные серверы отранжированы по интел-
лектуальному алгоритму. Рекомендуемый сервер будет наверху списка. Выберите
тот сервер Hyper-V, на который вы хотите поместить новую виртуальную машину, а
затем нажмите кнопку Next.
8. На странице Select Path модифицируйте путь для хранения новой виртуальной ма-
шины на сервере Hyper-V, а затем нажмите кнопку Next.
Рис. 14.3. Страница Volume Configuration
Рис. 14.4. Страница Virtual Machine Configuration

Рис. 14.5. Страница Select Host
9. На странице Select Networks выберите привязку к сетевому подключению для вир-

туальной машины или выберите для нее состояние Not Connected (для предотвра-
щения нежелательного сетевого обмена до тех пор, пока вы не проверите, что все
работает правильно), а затем нажмите кнопку Next.
10. На странице Additional Properties выберите нужные вам действия Automatic Start
и Stop, а затем нажмите кнопку Next.
11. На странице Conversion Information просмотрите нерешенные проблемы физи-
ческого сервера и после решения этих проблем нажмите кнопку Next.
12. На странице Summary (рис. 14.6) просмотрите настройки преобразования и на-
жмите кнопку Create для запуска процесса миграции физической машины на вир-
туальную.
Щелчок по кнопке View Script (рис. 14.6) приведет к показу скрипта Windows PowerShell, ко-
торый SCVMM запустит в фоновом режиме для выполнения этой миграции. Используйте
этот скрипт для того, чтобы быстро разобраться в правилах написания скриптов Windows
PowerShell, которые вы сможете использовать для автоматизации процессов вроде P2V.
13. Во время процесса преобразования отображается окно Jobs (рис. 14.7). Вы можете
использовать его для отслеживания продвижения процесса преобразования.
14. Когда задание преобразования завершится, окно Jobs покажет успех операции и
выдаст информацию о свойствах конфигурации исходного физического сервера и
о результирующих свойствах после процесса преобразования P2V (рис. 14.8).
15. Если статус задания обозначен как Completed, то вы можете протестировать пре-
образованную виртуальную машину (чтобы проверить, что она работает так, как
ожидается). Если вы попытаетесь запустить виртуальную машину до завершения
задания, то оно может закончиться неудачей.
Превращаем виртуальную машину в машину высокой готовности
Если во время процесса размещения вы выберете тот сервер Hyper-V, который является
узлом кластера хостов, то получите диалоговое окно (рис. 14.9), которое позволит вам пре-
вратить виртуальную машину в машину высокой готовности.
После того как вы нажмете кнопку Yes в этом диалоговом окне, никакого дальнейшего кон-
фигурирования не понадобится. Машина появится в Failover Cluster Management как управ-
ляемая виртуальная машина высокой готовности.
Том Экер (Tom Acker, Senior Support Engineer (Virtualization Support Team))
Рис. 14.7. Отображаемое во время преобразования окно Jobs
Рис. 14.8. Окно Jobs, демонстрирующее завершенное преобразование P2V (в оперативном режиме)
Рис. 14.9. Предложение превратить виртуальную машину

Автономная миграция физической машины

в виртуальную
Для всех поддерживаемых операционных систем можно выполнять автономные
миграции P2V (см. табл. 14.1), однако только для сервера Windows 2000 Server такая
миграция требуется. Сервер Windows 2000 Server не поддерживает оперативную
миграцию P2V (по причине отсутствия поддержки VSS в операционной системе). При
миграции физической машины на виртуальную исходный физический сервер загружа-
ется в среду WinPE (для сохранения диска). Поэтому во время миграции P2V сервера
Windows 2000 Server получится простой (который скажется на пользователях).
Процесс автономной миграции P2V использует тот же самый мастер миграции (что и
при оперативной миграции) для сбора всей необходимой информации, принятия реше-
ний на ее основе, а также создания задания, которое будет запущено для выполнения
самой миграции. Мастер миграции для автономной миграции P2V выполняет следую-
щие шаги:
1. Просмотр предварительных требований.
2. Указание исходного физического сервера.
3. Именование виртуальной машины.
4. Сбор системной информации об исходном физическом сервере.
5. Модификация конфигурации тома.
6. Модификация IP-адреса, используемого для миграции.
7. Модификация конфигурации процессоров и памяти мигрировавшей виртуальной
машины.
8. Выбор сервера Hyper-V для размещения.
9. Выбор пути для размещения файлов виртуальной машины.
10. Выбор соответствия виртуальных сетей для каждого сетевого адаптера.
11. Выбор дополнительных свойств (вроде действий при запуске и останове).
12. Решение всех потенциальных проблем преобразования.
13. Запуск процесса преобразования.
Во время фактического процесса автономной миграции требуется выполнить следую-

щие шаги:
1. Собрать информацию о конфигурации машины при помощи агента.
2. Создать виртуальную машину.
3. Перезагрузить исходный сервер в среду WinPE.
4. Упаковать содержимое жесткого диска в формат VHD.
5. Передать VHD по сети на целевой сервер Hyper-V.
6. Выключить исходный сервер (не обязательно).
7. Модифицировать оборудование виртуальной машины.
8. Удалить агента из виртуальной машины.
Предварительные требования
для автономной миграции P2V
Для автономной миграции P2V вы должны обеспечить выполнение определенных тре-
бований. Для того чтобы мастер миграции мог собрать информацию об исходном фи-
зическом сервере (во время фазы сканирования), менеджер SCVMM развертывает на
сервере удаленного клиента. Этот клиент идет в виде пакета для инсталлятора Windows
Installer 3.1. Для того чтобы выполнить фазу сканирования, вы должны убедиться
в том, что на сервере установлен Windows Installer 3.1. На серверах Windows 2000 по
умолчанию Windows Installer 3.1 не инсталлирован, поэтому если вы получите ошибку,
вроде показанной на рис. 14.10, то вам нужно инсталлировать обновление Windows
Installer 3.1, которое есть в составе KB893803.
Рис. 14.10. Сообщение об ошибке,

выдаваемое во время процесса сканирования
Сбор системной информации

Сбор системной информации по физическому серверу делается для того, чтобы мастер
миграции мог оценить текущий сервер. Для оценки нужна следующая информация:
несовместимости по оборудованию;
несовместимости по программному обеспечению;
доступные для операционной системы методы миграции (оперативный или авто-

номный);
системная информация.
Когда сканирование системы закончится, будет выдана сводка системной информации
(рис. 14.11). Если будут выявлены несовместимости, то они будут показаны, и вы смо-
жете устранить их, а затем вернуться на страницу System Information. Затем вы
сможете нажать кнопку Scan System еще раз (для повторного сканирования системы
с целью повторной ее оценки).
Рис. 14.11. Результат сканирования
Модификация конфигурации томов

Страница Volume Configuration (рис. 14.12) показывает все тома, обнаруженные при
сканировании системы. Для каждого тома представлены: буква диска; текущее количе-
ство использованного пространства; рекомендуемый размер виртуального жесткого
диска (в зависимости от размера физического диска); рекомендуемый тип виртуально-
го жесткого диска (по умолчанию — динамически расширяющийся); тип контроллера
и рекомендуемый для подключения тома канал. В этот момент у вас есть возможности:
изменить размер создаваемого жесткого диска; изменить тип виртуального жесткого
диска (с динамически расширяющегося на фиксированный); выбрать другой контрол-
лер и канал для подключения тома. Вы можете также сбросить флажок диска, если не
хотите включать его в процесс миграции P2V. Хорошими кандидатами на исключение
из миграции P2V являются диски с данными, их можно переподключить к целевой
виртуальной машине при помощи транзитных подключений (или iSCSI-подключений)
без миграции содержимого.
Рис. 14.12. Страница Volume Configuration
На рис. 14.12 показаны также опции Conversion Options, которые имеются при этой
миграции. Если физический сервер соответствует предъявляемым к оперативной ми-
грации P2V требованиям, тогда станет доступной опция Online conversion. В против-
ном случае будет доступна только опция Offline conversion. У вас есть также возмож-
ность выключить исходный компьютер после преобразования.
На рис. 14.12 вы заметите внизу страницы предупреждение, которое означает, что ис-
ходная машина является сервером Windows 2000 Server и для нее возможно только
преобразование в автономном режиме.
Модификация автономного IP-адреса

Во время автономной миграции физического сервера он будет перезагружен в среду
WinPE, чтобы можно было мигрировать диски. По умолчанию предполагается, что
WinPE получит IP-адрес по протоколу Dynamic Host Configuration Protocol (DHCP).
Если это невозможно, то на рис. 14.13 показаны опции, имеющиеся для указания ста-
тического адреса IPv6 или IPv4 (который будет использоваться в WinPE). Если вы ука-
жете адрес IPv4, то вам будет нужно задать IP-адрес, маску подсети и шлюз по умолча-
нию, а также выбрать сетевой адаптер, к которому этот IP-адрес будет привязан (если
адаптеров имеется несколько).
Рис. 14.13. Страница Offline Conversion Options
Для решения некоторых проблем при автономных преобразованиях в подсетях с адресами
из частных диапазонов было выпущено специальное обновление. За дополнительной ин-
формацией обращайтесь к статье KB959596, расположенной по ссылке:
Модификация конфигурации виртуальной машины

Показанная на рис. 14.14 страница Virtual Machine Configuration демонстрирует оп-
ции для модификации конфигурации процессоров и памяти мигрировавшего физиче-
ского сервера. По умолчанию количество процессоров настраивается равным количе-
ству процессоров физического сервера, а количество памяти выставляется равным ко-
личеству памяти физического сервера.
Рис. 14.14. Страница Virtual Machine Configuration
Вы можете увеличить это значение (для процессоров), если поддерживаемое сервером

Hyper-V предельное для данной операционной системы количество процессоров боль-
ше, чем это значение. Например, работа сервера Windows 2000 поддерживается в
Hyper-V только на одном виртуальном процессоре. Если вы попытаетесь преобразо-
вать имеющий два процессора физический сервер Windows 2000, то количество про-
цессоров будет установлено в 1. (Фактически же шаг сканирования системы выявит эту
проблему и выдаст вам эту несовместимость.)
Для памяти у вас есть возможность как увеличить, так и уменьшить ее количество. Ве-
роятно, вы захотите увеличить количество памяти виртуальной машины (если физиче-
скому серверу часто не хватало памяти) или уменьшить ее количество (если физиче-
ский сервер часто недоиспользовал имеющуюся память).
Выбор хоста для размещения

Показанная на рис. 14.15 страница Select Host демонстрирует результаты работы ин-
теллектуального алгоритма размещения для всех хостов, которые управляются с серве-
ра SCVMM. Алгоритм ранжирует имеющиеся хосты и дает рекомендацию по наилуч-
шему хосту для новой виртуальной машины. Вы можете либо принять эту рекоменда-
цию (выбрать хост на самом верху списка), либо выбрать любой хост из списка.
Рис. 14.15. Страница Select Host
В разделе Details внизу страницы вы можете увидеть состояние, пояснение по рейтин-

гу, а также подробности по типу передачи выбранного сервера. Пояснения по рейтингу
и типу передачи дадут вам информацию о том, какие проблемы могут возникнуть
в случае выбора этого сервера в качестве назначения для миграции.
Выбор пути хранения

Страница Select Path позволяет вам указать местоположение для файлов виртуальной
машины на выбранном вами сервере. Показан путь по умолчанию, и вы можете нажать
кнопку Browse для выбора другого пути.
Выбор сетей
Показанная на рис. 14.16 страница Select Networks демонстрирует обнаруженные на
исходном физическом сервере сетевые адаптеры и позволяет вам выбрать ту виртуаль-
ную сеть, которую вы хотите привязать к новому виртуальному сетевому адаптеру.
Вам будут представлены все имеющиеся виртуальные сети (в зависимости от выбран-
ного на странице Select Host сервера).
Рис. 14.16. Страница Select Networks
Дополнительные свойства
Показанная на рис. 14.17 страница Additional Properties демонстрирует опции конфи-
гурирования тех действий, которые виртуальная машина будет выполнять при старте и
останове сервера Hyper-V. Опции представлены в виде раскрывающихся списков.
Вот те возможные действия, которые виртуальная машина может выполнять при
включении питания сервера Hyper-V:
Never automatically turn on the virtual machine (Не включать автоматически вир-
туальную машину);
Always automatically turn on the virtual machine (Автоматически включать вирту-

альную машину);
Automatically turn on the virtual machine if it was running when the physical server
was stopped (Автоматически включать виртуальную машину, если она работала в
момент останова физического сервера).
Действие по умолчанию — Never automatically turn on the virtual machine. Если вы
выберете автоматическое включение виртуальной машины, то сможете указать время
задержки запуска в секундах, которое будет использоваться для того, чтобы все вирту-
альные машины стартовали в разное время.
Рис. 14.17. Страница Additional Properties
Вот те возможные действия, которые виртуальная машина может выполнять при вы-
ключении питания сервера Hyper-V:
Save State (Cохранение состояния);
Turn Off Virtual Machine (Выключение виртуальной машины);
Shut Down Guest OS (Завершение работы гостевой операционной системы).
Действие по умолчанию — Save State.
Информация по преобразованию
Страница Conversion Information демонстрирует выявленные проблемы преобразова-
ния, которые вы можете устранить (рис. 14.18). Именно здесь мастер P2V перечислит
все элементы, которые должны быть устранены до того, как вы сможете начать авто-
номную миграцию физической машины в виртуальную. Перечисленные на странице
Conversion Information проблемы могут включать: отсутствие драйверов или пакетов
исправлений; недостаток аппаратных ресурсов; оборудование физического сервера,
которое не существует в виртуальной машине, и т. д. Если здесь имеются какие-либо
проблемы, устраните их, а затем вернитесь на эту страницу и опять нажмите кнопку
Check Again для повторного сканирования исходного физического сервера, чтобы оп-
ределить, были ли устранены данные проблемы. Не следует пытаться выполнить ми-
грацию до устранения всех проблем.
Рис. 14.18. Страница Conversion Information
Если страница Conversion Information указывает на проблемы, требующие пакетов

исправлений или обновлений, которые должны быть инсталлированы во время мигра-
ции, то вам придется скопировать эти файлы в каталог P2V Patch Import.
Для добавления нужных файлов в каталог P2V Patch выполните следующие шаги:
1. Скачайте указанные на странице Conversion Information пакеты с Web-сайта ком-
пании Microsoft. Пакеты нужно будет переименовать (и возможно, разархиви-
ровать).
Например, указанный пакет исправлений может иметь имя файла Windows2000-
KB935839-x86-ENU.exe. Его следует переименовать в нечто вроде KB935839.exe
(чтобы соблюсти правило 8.3 для имени файла).
2. Скопируйте переименованные пакеты в каталог C:\Program Files\Microsoft System
Center Virtual Machine Manager 2008\P2V Patch Import.
Если на странице Conversion Information указаны проблемы с дополнительными
драйверами, которые требуются для выполнения миграции, то вам нужно будет скопи-
ровать соответствующие файлы в каталог Driver Import:
1. Скачайте нужные драйверы, указанные на странице Conversion Information. При
необходимости разархивируйте драйверы (чтобы получить исходные файлы драй-
веров). Используйте драйверы, созданные для операционной системы Windows
Vista или более поздних (поскольку используемая версия WinPE сделана на базе
Windows Vista).
2. Скопируйте файлы драйверов в каталог C:\Program Files\Microsoft System Center
Virtual Machine Manager 2008\Driver Import.
Выполнение миграции
Когда все проблемы устранены, взгляните на показанные на странице Summary под-
робности (рис. 14.19). Вы увидите там то, что произойдет во время миграции. В дан-
ный момент вы можете управлять тем, что произойдет с вновь созданной виртуальной
машиной после завершения миграции — вы можете выбрать ее запуск или оставить ее
выключенной. Вы можете также нажать кнопку View Script, чтобы увидеть те команды
Windows PowerShell, которые будут использованы в задании миграции.
Нажатие кнопки Create запустит процесс создания новой виртуальной машины на вы-
бранном сервере Hyper-V и миграции содержимого физического сервера.
Резюме
В этой главе вы получили обзор того, как менеджер System Center Virtual Machine
Manager 2008 поддерживает преобразование физических серверов в виртуальные ма-
шины. Вы узнали о тех вариантах миграции (оперативной и автономной), которые
поддерживаются менеджером System Center Virtual Machine Manager 2008 и о предва-
рительных требованиях к ним. Вы также узнали, что для устаревших операционных
систем вроде Windows NT 4.0 (которые SCVMM 2008 не поддерживает) есть альтерна-
тивный инструмент компании Microsoft (называемый Virtual Server Migration Toolkit), а
также инструменты сторонних поставщиков. Для снижения времени простоя физиче-
ских серверов в процессе преобразования следует по возможности использовать опера-
тивную миграцию P2V, однако для всех серверов Windows 2000 потребуется автоном-
ная миграция P2V.

ресурс, который предоставляет информацию по продукту, техническую информа-
цию, а также информацию по инсталляции System Center Virtual Machine Manager
2008, доступен по ссылке:
System Center Virtual Machine Manager System Requirements — ресурс, который пре-
доставляет информацию по аппаратным и программным требованиям к инсталля-
ции на одном сервере и к распределенной инсталляции, доступен по ссылке:
System Center Virtual Machine Manager 2008 Configuration Analyzer — инструмент,
который дает возможность проанализировать сервер до или после инсталляции
SCVMM 2008 (для обеспечения его правильной конфигурации), доступен для ска-
чивания по ссылке: http://go.microsoft.com/fwlink/?LinkID=100597;
документация по System Center Virtual Machine 2008, "P2V: Converting Physical
Computers to Virtual Machines in VMM", доступна по ссылке:
инструментальный набор Virtual Server Migration Toolkit 1.1 для выполнения мигра-
ций P2V для компьютеров Windows NT 4.0. Он включен в пакет обновлений
Automated Deployment Services 1.1, который можно скачать по ссылке:
http://www.microsoft.com/downloads/details.aspx?familyid=
D99A89C9-4321-4BF6-91F9-9CA0DED26734&displaylang=en.
ГЛАВА 15
Наблюдение за сервером
при помощи пакета управления
Windows Server 2008
Hyper-V Management Pack
для менеджера System Center
Operations Manager 2007
Эта глава содержит информацию, которая вам нужна для инсталляции, управления и
наблюдения за серверами Hyper-V при помощи пакета управления Windows Ser-
ver 2008 Hyper-V Management Pack для менеджера System Center Operations Manager
2007. Представленная в данной главе информация основана на бета-версии пакета
управления Windows Server 2008 Hyper-V Management Pack, поэтому в окончательном
варианте вы можете обнаружить определенные изменения по сравнению с тем, что
представлено здесь. В основном глава посвящена тому, как пакет управления Windows
Server 2008 Hyper-V Management Pack может помочь вам наблюдать за состоянием и
производительностью вашей инфраструктуры Hyper-V.
Обзор консоли System Center Operations

Manager 2007 Operations Console
Пакет управления Windows Server 2008 Hyper-V Management Pack — это необязатель-
ный компонент, импортируемый в сервер System Center Operations Manager 2007
Management Server, который: управляет доступом к базе данных System Center
Operations Manager 2007; управляет инсталляцией, конфигурацией и сбором данных
для агентов Operations Manager; фиксирует данные агентов в базе данных. Сервер
System Center Operations Manager 2007 Management Server представляет собой цен-
тральную точку управления, которая позволяет вам выполнять как задачи конфигури-
рования (развертывать агентов, создавать новые задачи и т. д.), так и эксплуатацион-
ные задачи (просматривать оповещения и решать проблемы, отслеживать состояние

виртуальных машин и т. д.).
Консоль System Center Operations Manager 2007 Operations Console имеет пять разных
рабочих областей: Monitoring, Authoring, Reporting, Administration и My Workspace.
Область Monitoring (рис. 15.1) — это основной интерфейс пользователя для просмотра
данных наблюдения и манипуляции ими. Собираемые через агентов менеджера System
Center Operations Manager 2007 данные компилируются и обрабатываются для того,
чтобы выдать информацию по состоянию, оповещениям, событиям и производитель-
ности, а также диаграммы иерархии сетевых устройств. Область Monitoring также
предоставляет интерфейс для выполнения заготовленных задач с указанными отслежи-
ваемыми устройствами.
Рис. 15.1. Область Monitoring консоли System Center Operations Manager 2007 Operations Console
Функциональные возможности наблюдения в System Center Operations Manager 2007

усилены посредством импорта специфичных для приложений пакетов Management
Packs, которые определяют то, как сервер System Center Operations Manager 2007
Management Server собирает, обрабатывает и реагирует на данные, собранные из при-
ложений. Пакет Management Pack определяет некоторые важные вещи, такие как: эле-
менты для наблюдения (и их связи), мониторы, правила управления, скрипты, группы,
представления данных, задачи, а также базу данных по знаниям (которая помогает вам
исправить уже известные проблемы приложений).
Глава 15. Наблюдение за сервером при помощи пакета управления... 563
Microsoft System Center Operations Manager 2007 R2 — это последняя версия приложения
управления. Вы можете импортировать пакет Windows Server 2008 Hyper-V Management
Pack в System Center Operations Manager 2007 R2.
В области Monitoring вы можете использовать Health Explorer (рис. 15.2) для диагно-
стики сбоев наблюдаемых объектов и выполнения действий в ответ на ошибки. Вы
можете также по своему усмотрению либо запускать задачи диагностики или восста-
новления, либо сконфигурировать задачи для автоматического их запуска (при появле-
нии сигналов тревоги). Результаты задачи диагностики отображаются тогда, когда вы
выделяете событие изменения состояния.
Рис. 15.2. Health Explorer в консоли System Center Operations Manager 2007 Operations Console
В области Monitoring вы можете также перевести наблюдаемый объект в режим об-

служивания. В режиме обслуживания все сигналы тревоги, правила, мониторы, авто-
матические отклики и изменения состояния подавляются прямо в агенте. Если обслу-
живаемый объект вывести в автономный режим для обслуживания без предваритель-
ного перевода его в режим обслуживания, то менеджер System Center Operations
Manager 2007 перестанет получать тактовые импульсы от агента и в результате может
быстро сгенерировать огромное количество сигналов тревоги и уведомлений.
Рекомендуется не переводить сервер System Center Operations Manager 2007 в режим об-
служивания. Если вы переведете его в режим обслуживания, то сигналы тревоги, оповеще-
ния, правила, мониторы, автоматические ответы, изменения состояний и новые сигналы
(генерируемые на сервере Management Server) будут подавляться. Однако служба Health
Service на сервере System Center Operations Manager 2007 Management Server будет про-
должать работать. Поэтому сигналы тревоги, оповещения, правила, мониторы, автомати-
ческие ответы, изменения состояний и новые сигналы от управляемых агентами компьюте-
ров будут обрабатываться и отображаться как положено.
Вы можете инициировать режим обслуживания при помощи щелчка по пункту Start

Maintenance Mode в панели Actions области Monitoring (рис. 15.3). Вы можете скон-
фигурировать режим обслуживания либо только для выделенного наблюдаемого объ-
екта, либо для выделенного наблюдаемого объекта и содержащихся в нем объектов.
Вы можете также указать длительность в минутах режима обслуживания или заплани-
ровать время возвращения наблюдаемого объекта из режима обслуживания.
Рис. 15.3. Диалоговое окно Start Maintenance Mode
Область Authoring (рис. 15.4) позволяет вам создавать новые группы компьютеров,
создавать и конфигурировать новые правила и задачи, а также присваивать правила
одной или нескольким группам компьютеров.
Рис. 15.4. Область Authoring
Область Reporting менеджера System Center Operations Manager 2007 (рис. 15.5) непо-
средственно интегрирована в консоль Operations Console. Для не имеющих своих отче-
тов пакетов управления существуют обобщенные отчеты, которые представляют дан-
ные по основным параметрам готовности и производительности. При помощи менед-
жера System Center Operations Manager 2007 группы управления могут использовать
единое хранилище данных отчетности. Кроме того, безопасность на основе ролей по-
зволяет администраторам управлять доступом к отчетам (при помощи групп безопас-
ности Active Directory).
Задачи конфигурирования System Center Operations Manager 2007 выполняются в об-
ласти Administration (рис. 15.6). Область Administration — это основной интерфейс
пользователя для конфигурирования и администрирования среды System Center
Operations Manager 2007. Выполняемые в этой области действия включают в себя: об-
наружение компьютеров и сетевых устройств; развертывание агентов System Center
Operations Manager 2007; создание логических групп наблюдения за компьютерами;
импорт новых пакетов управления на сервер System Center Operations Manager 2007
Management Server и т. д.
Область My Workspace (рис. 15.7) позволяет вам создавать представления, сохранять
часто используемые представления и поиски, конфигурировать нестандартные подпис-
ки на сигналы тревоги.
Рис. 15.5. Область Reporting
Рис. 15.6. Область Administration

Рис. 15.7. Область My Workspace в консоли System Center Operations Manager 2007 Operations Console
Рис. 15.8. Web-консоль System Center Operations Manager 2007

Менеджер System Center Operations Manager 2007 предоставляет также и Web Console
(рис. 15.8), которая позволяет получить доступ к тем же самым данным областей
Monitoring и My Workspace, которые имеются в консоли System Center Operations
Manager 2007 Operations Console. Web Console имеет ту же компоновку, что и
Operations Console (включая полнофункциональную панель Actions для выполнения
задач), а также возможность переводить наблюдаемые устройства в режим обслужива-
ния. Более того, Web Console предоставляет RSS-канал, который поставляет сигналы
тревоги в Outlook 2007 или другое средство сбора RSS.
Характеристики пакета управления

Пакет управления Windows Server 2008 Hyper-V Management Pack поддерживает сле-
дующие версии сервера Hyper-V:
Hyper-V на 64-битной версии Windows Server 2008 Standard Edition;
Hyper-V на 64-битной версии Windows Server 2008 Enterprise Edition;
Hyper-V на 64-битной версии Windows Server 2008 Datacenter Edition.
После импорта и конфигурирования пакета управления Windows Server 2008 Hyper-V
Management Pack на сервере System Center Operations Manager 2007 Management Server
вы можете использовать его для наблюдения за параметрами серверов Hyper-V и вир-
туальных машин (табл. 15.1).
Таблица 15.1. Отслеживаемые компоненты пакета

Компонент Описание
Hyper-V Server Отслеживает состояние сервера Hyper-V при помощи состояний служб Hyper-V,
Health состояние виртуальных машин, неустраненные ошибки и сигналы тревоги, генери-
руемые службами Hyper-V
Virtual Machine Отслеживает дисковое пространство динамически расширяющихся VHD,

Health хранящихся на сервере Hyper-V
Virtual Networks Отслеживает виртуальные сети, их тип (внешние или внутренние), а также связан-
ные с каждой виртуальной сетью серверы Hyper-V
Пакет Windows Server 2008 Hyper-V Management Pack включает также перечисленные
в табл. 15.2 мониторы.
Таблица 15.2. Мониторы пакета Windows Server 2008 Hyper-V Management Pack
Монитор Описание
Image Отслеживает состояние службы Image Management Service сервера Hyper-V.
Management Когда служба работает, то состояние монитора — Healthy. Если служба не рабо-
Server тает, то состояние монитора — Critical. При переходе состояния монитора
из Healthy в проблемное состояние выдается сигнал тревоги.
Монитор Описание
При переходе монитора в проблемное состояние запускает задачу автоматиче-
ского восстановления. Задача восстановления пытается перезапустить службу
Image Management Service. Если ей удается вернуть службу в рабочее состоя-
ние, то монитор возвращается в состояние Healthy и сигнал тревоги автомати-
чески устраняется. Если задаче восстановления не удается перезапустить служ-
бу, то монитор остается в состоянии Critical и сигнал тревоги остается дейст-
вующим
Networking Отслеживает состояние службы Networking Management Service сервера Hyper-V.
Management Когда служба работает, то состояние монитора — Healthy. Если служба
Service не работает, то состояние монитора — Critical. При переходе состояния
монитора из Healthy в проблемное состояние выдается сигнал тревоги.
Networking Management Service. Если ей удается вернуть службу в рабочее со-
стояние, то монитор возвращается в состояние Healthy и сигнал тревоги автома-
тически устраняется. Если задаче восстановления не удается перезапустить
службу, то монитор остается в состоянии Critical и сигнал тревоги остается дей-
ствующим
Virtual Machine Отслеживает состояние службы Virtual Machine Management Service сервера
Management Hyper-V. Когда служба работает, то состояние монитора — Healthy. Если служба
Service не работает, то состояние монитора — Critical. При переходе состояния монито-
ра из Healthy в проблемное состояние выдается сигнал тревоги.
Virtual Machine Management Service. Если ей удается вернуть службу в рабочее
состояние, то монитор возвращается в состояние Healthy и сигнал тревоги ав-
томатически устраняется. Если задаче восстановления не удается перезапус-
тить службу, то монитор остается в состоянии Critical и сигнал тревоги остается
действующим
Hyper-V Virtual Отслеживает количество свободного пространства на том диске сервера Hyper-V,
Drive Free Space который содержит динамически расширяющийся VHD. Состояние меняется
в зависимости от значений параметров Warning и Error State Size. Несмотря на
то, что параметры можно сконфигурировать, их значения по умолчанию приво-
дят к следующим состояниям:
• Healthy — имеется более 2 Гбайт свободного дискового пространства на том
диске, где хранится динамически расширяющийся VHD (либо это VHD не
является динамически расширяющимся);
• Warning — есть меньше 2 Гбайт, но больше 200 Мбайт свободного дискового
пространства на том диске, где хранится динамически расширяющийся VHD;
• Critical — есть меньше 200 Мбайт свободного дискового пространства на том
диске, где хранится динамически расширяющийся VHD
Virtual Hardware Отслеживает состояние компонентов виртуального оборудования виртуальных
Component машин
Availability
Список мониторов пакета Windows Server 2008 Hyper-V Management Pack имеется в
области Authoring консоли System Center Operations Manager 2007 Operations Console
(рис. 15.9).
Рис. 15.9. Область Authoring консоли Operations Console

со списком мониторов Hyper-V Management Pack
Рис. 15.10. Диалоговое окно Scope Management Pack Objects by target(s)

Для того чтобы просмотреть только те мониторы, которые включены в пакет Windows
Server 2008 Hyper-V Management Pack, выполните следующие шаги:
1. Откройте консоль System Center Operations Manager 2007 Operations Console и выбе-
рите область Authoring.
2. В левой панели разверните корневой элемент Authoring, затем разверните
Management Packs Objects и выберите узел Monitors.
3. В центральной панели щелкните по ссылке Change Scope (под Monitors).
4. В диалоговом окне Scope Management Pack Objects by target(s) выберите цели
Hyper-V (рис. 15.10).
5. После завершения выбора нажмите кнопку OK.
6. В центральной панели (под Monitors) будет показан список выбранных целей.
7. При желании вы можете развернуть элементы, чтобы просмотреть список содержа-
щихся в них мониторов.
Инсталляция пакета управления

При подготовке к инсталляции пакета управления Windows Server 2008 Hyper-V
Management Pack вы должны убедиться, что в вашей среде выполнены требования из
табл. 15.3.
Таблица 15.3. Предварительные требования пакета

Инсталлировать System Center Operations Перед тем как вы сможете импортировать и использо-
Manager 2007 SP1 вать пакет Windows Server 2008 Hyper-V Management
Pack, вы должны инсталлировать как минимум один
сервер System Center Operations Manager 2007 SP1
Management Server
Импортировать пакеты Нужно импортировать версию 6.0.6321.5 или более

Microsoft.Windows.Server Library Pack новую
и Microsoft.Windows.Server.2008.Discovery
Management Pack
Обновить пакеты Последние версии включены в состав пакета Windows

System.Virtualization.Library Pack and Server 2008 Hyper-V Management Pack
System.Hardware.Library Management Pack
Инсталлировать службы интеграции на все Если службы интеграции не инсталлированы, то ме-

виртуальные машины неджер System Center Operations Manager 2007 не
может отслеживать тактовые импульсы виртуальной
машины и точно сообщать о состоянии виртуальной
машины
Запуск инсталлятора пакета управления

Файлы, необходимые для импорта пакета управления Windows Server 2008 Hyper-V
Management Pack на сервер System Center Operations Manager 2007 Management Server,
содержатся в инсталляторе (Windows Server 2008 Hyper-V Management Pack for
Operations Manager 2007.msi). Для импорта пакета Management Pack вы должны запус-
тить инсталлятор (чтобы извлечь его содержимое в файловую систему).
После выпуска новейшей версии пакета Windows Server 2008 Hyper-V Management Pack его
инсталлятор будет доступен на Web-сайте каталога System Center Operations Manager 2007
Catalog по ссылке: http://technet.microsoft.com/en-us/opsmgr/cc539535.aspx.
Для запуска инсталлятора пакета Windows Server 2008 Hyper-V Management Pack вы-
1. На сервере System Center Operations Manager 2007 Management Server откройте
Windows Explorer, а затем выберите тот каталог, который содержит инсталлятор па-
кета Windows Server 2008 Hyper-V Management Pack (Windows Server 2008 Hyper-V
Management Pack for Operations Manager 2007.msi).
2. Дважды щелкните по инсталлятору пакета Windows Server 2008 Hyper-V
Management Pack, чтобы начать инсталляцию файлов пакета управления.
3. Если появится диалоговое окно, нажмите кнопку Run.
4. В диалоговом окне License Agreement выберите I Accept, а затем нажмите кнопку
Next.
5. В диалоговом окне Select Installation Folder нажмите кнопку Next.
6. В диалоговом окне Confirm Installation нажмите кнопку Install.
7. В диалоговом окне Installation Complete нажмите кнопку Close.
Импорт пакета Windows Server 2008

После успешного выполнения инсталлятора пакета управления Windows Server 2008
Hyper-V Management Pack вы можете использовать консоль System Center Operations
Manager 2007 Operations Console для импорта Management Pack на ваш сервер System
Center Operations Manager 2007 Management Server.
Для импорта пакета Windows Server 2008 Hyper-V Management Pack на сервер
Management Server выполните следующие шаги:
1. Откройте консоль System Center Operations Manager 2007 Operations Console и выбе-
рите область Administration.
2. В левой панели разверните корневой элемент Administration, а затем выберите
Management Packs (рис. 15.11).
3. В правой панели (под Actions) выберите пункт Import Management Packs.
Рис. 15.11. Панель Management Packs
4. В Windows Explorer перейдите к тому каталогу, который содержит файлы пакета

Windows Server 2008 Hyper-V Management Pack, выберите файлы
System.Hardware.Library.mp, System.Virtualization.Library.mp,
Microsoft.Windows.HyperV.2008.Discovery.mp,
Microsoft.Windows.HyperV.2008.Monitoring.mp и
Microsoft.Windows.HyperV.Library.mp, а затем нажмите кнопку Open.
5. В диалоговом окне Import Management Packs нажмите кнопку Import.
6. После успешного импорта пакетов управления нажмите кнопку Close.
Проверка версии пакета управления Windows Server 2008

Поскольку время от времени выпускаются обновления Management Pack, которые со-
держат программные заплатки или улучшения, то вам понадобится проверять версию
импортированного на сервер System Center Operations Manager 2007 Management Server
пакета Windows Server 2008 Hyper-V Management Pack. Для проверки версии пакета
управления выполните следующие шаги:
1. На сервере System Center Operations Manager 2007 Management Server откройте кон-
соль Operations Console.
2. В левой панели (под узлом Administration) выберите Management Packs.

3. В центральной панели (под Management Packs) найдите пакеты управления
Microsoft Windows Hyper-V.
4. Проверьте номер версии, показанный в поле Version.
Инсталляция агента System Center Operations

Manager 2007 Agent
Агент System Center Operations Manager 2007 Agent должен быть развернут на сервере
Hyper-V для наблюдения за службой Hyper-V и состоянием виртуальных машин. Если
вам нужно наблюдать за состоянием виртуальных машин или за данными по произво-
дительности и состоянию приложений (таких, как Microsoft Exchange Server), то вы
должны развернуть на виртуальной машине агента и инсталлировать специфичный для
приложения пакет управления. Если вы не установите в гостевой операционной систе-
ме виртуальной машины агента System Center Operations Manager 2007 Agent, то соби-
раемые данные по производительности и состоянию будут ограничены только той
информацией, которая собирается с сервера Hyper-V. Не будут также отслеживаться
и приложения, которые работают в гостевой операционной системе виртуальной
машины.
Менеджер System Center Operations Manager 2007 предоставляет автоматизированную
процедуру инсталляции для развертывания агентов на физические и виртуальные
машины. Для развертывания агентов на серверы Hyper-V и виртуальные машины вы-
1. На сервере System Center Operations Manager 2007 Management Server откройте кон-
соль Operations Console.
2. В левой панели откройте область Administration.
3. В левой панели разверните корневой элемент Administration, затем узел Device
Management, а затем щелкните правой кнопкой мыши по узлу Agent Managed
(рис. 15.12).
4. В контекстном меню выберите пункт Discovery Wizard.
5. На странице Auto or Advanced? (рис. 15.13) установите переключатель Automatic
computer discovery. После этого будет выполнено сканирование домена Active
Directory для поиска всех входящих в состав домена компьютеров под управлением
операционных систем семейства Windows. Если вы предпочитаете указать типы
устройств для обнаружения, то можете выбрать Advanced discovery и указать спо-
соб сужения поиска. После выполнения выбора нажмите кнопку Next.
6. На странице Administrator Account (рис. 15.14) установите переключатель Use
selected Management Server Action Account, а затем нажмите кнопку Discover.
7. Далее менеджер System Center Operations Manager 2007 выдает состояние процесса
обнаружения (рис. 15.15).
Рис. 15.12. Устройства Agent Managed
Рис. 15.13. Выбор метода обнаружения компьютеров

Рис. 15.14. Выбор Administrator Account
Рис. 15.15. Состояние процесса обнаружения

Рис. 15.16. Выбор устройств на странице Select Objects to Manage
8. После завершения процесса обнаружения на странице Select Objects to Manage

выберите те устройства, на которые менеджер System Center Operations Manager
2007 должен будет развернуть агента (рис. 15.16), а затем нажмите кнопку Next.
9. На странице Summary просмотрите каталог для инсталляции агента, укажите
учетные данные для выполнения инсталляции агента (рис. 15.17), а затем нажмите
кнопку Finish.
10. В диалоговом окне Agent Management Task Status вы можете наблюдать за со-
стоянием инсталляции агента.
11. После завершения инсталляции нажмите кнопку Close.
ВАЖНО
По умолчанию для инсталляции агента используется учетная запись Local System. Однако
вы можете указать учетные данные доменной или локальной учетной записи, если вам
нужно задать учетную запись с более низкими правами (во исполнение требований полити-
ки безопасности). В принципе это возможно, но вы должны помнить, что некоторые задачи
нельзя выполнить при помощи учетной записи с низкими правами, и что для их выполнения
необходимо, чтобы та учетная запись, от лица которой действует агент, имела админист-
ративные права на целевом сервере Hyper-V.
Рис. 15.17. Выбор учетных данных
Наблюдение за серверами Hyper-V

При помощи менеджера System Center Operations Manager 2007, пакета Windows Server
2008 Hyper-V Management Pack и развернутых на каждом сервере Hyper-V агентов
System Center Operations Manager 2007 вы можете использовать сервер Management
Server (и консоль Operations Console) для централизованного наблюдения за состояни-
ем инфраструктуры Hyper-V.
Представления наблюдения
за серверами Hyper-V
Консоль System Center Operations Manager 2007 Operations Console предоставляет не-
сколько представлений для просмотра и анализа данных по состоянию и производи-
тельности. В табл. 15.4 перечислены специфичные для сервера Hyper-V представления
и даны описания типов предоставленных в каждом представлении данных.
Таблица 15.4. Представления наблюдения за серверами Hyper-V

Alert Это представление (рис. 15.18) дает список сигналов тревоги, которые генерируются для
View наблюдаемых серверов Hyper-V. По умолчанию представление Alert View показывает
имя сервера Hyper-V, название сгенерировавшего сигнал тревоги компонента, состояние
решения проблемы, временную метку создания сигнала тревоги, а также возраст сигнала
тревоги.
Если вы выберете сигнал тревоги, то в панели Alert Details будет показана дополнитель-
ная информация, в том числе: описание сигнала тревоги, ссылка на информацию по дан-
ному сигналу тревоги, информация о запущенных задачах восстановления, причины сиг-
нала тревоги, сводка сигналов тревоги, а также ссылки на дополнительные ресурсы
Server Это представление (рис. 15.19) дает список наблюдаемых серверов Hyper-V, а также
Role состояние серверов. Состояние может быть Green (нормальное), Yellow (предупрежде-
View ние) или Red (критическое) — в зависимости от состояния служб Hyper-V.
Если вы выберете сервер Hyper-V, то в панели Details View будет показана дополни-
тельная информация сервера
Virtual Это представление (рис. 15.20) дает список виртуальных машин, которые относятся
Machine к наблюдаемым серверам Hyper-V, а также состояние тех физических дисков сервера
View Hyper-V, которые хранят динамически расширяющиеся VHD виртуальных машин. Состоя-
ние может быть Green (нормальное), Yellow (предупреждение) или Red (критическое) —
в зависимости от количества свободного пространства на диске.
Если вы выберете виртуальную машину, то в панели Details View будет показана
информация о виртуальной машине, в том числе: идентификатор GUID виртуальной
машины, название виртуальной машины, название компьютера виртуальной машины
Virtual Это представление (рис. 15.21) дает список виртуальных сетей, которые связаны
Network с наблюдаемыми серверами Hyper-V.
View Если вы выберете виртуальную сеть, то в панели Details View будет показана информа-
ция о виртуальной сети, в том числе: идентификатор GUID виртуальной сети, название
виртуальной сети, тип виртуальной сети, а также соответствующий сервер Hyper-V
Рис. 15.18. Представление Alert View

Рис. 15.19. Представление Server Role View
Рис. 15.20. Представление Virtual Machine View

Рис. 15.21. Представление Virtual Network View
Стандартные представления наблюдения

за серверами Hyper-V
В табл. 15.5 перечислены стандартные представления, которые имеются для всех от-
слеживаемых компонентов, хотя для появления данных в этих представлениях может
потребоваться дополнительная настройка.
Таблица 15.5. Стандартные представления для серверов Hyper-V
Alert View Это представление показывает сигналы тревоги по определенному критерию,

такому как уровень серьезности сигнала тревоги, состояние его разрешения и т. д.
Diagram View Это представление (рис. 15.22) показывает графическое представление связей
между сервером Hyper-V и виртуальными машинами, а также конфигурацию
виртуальных компонентов
Event View Это представление показывает результаты запросов к журналам событий по опре-
деленным критериям, указанным в свойствах представления событий
Performance Это представление показывает данные по производительности, собранные
View из объектов и счетчиков производительности, определенных для наблюдаемых
устройств
State View Это представление (рис. 15.23) показывает состояние наблюдаемого устройства
Рис. 15.22. Представление Diagram View
Рис. 15.23. Представление State View

Инструмент System Center Operations Manager 2007

Health Explorer Tool
Инструмент System Center Operations Manager 2007 Health Explorer представляет собой
еще одно средство просмотра: состояния серверов Hyper-V, изменений состояния и
прочих критичных вещей. На рис. 15.24 показан Health Explorer для сервера Hyper-V,
на котором произошло несколько переходов службы VMMS из рабочего в остановлен-
ное состояние.
Рис. 15.24. Health Explorer для сервера Hyper-V
В обозревателе Health Explorer вы можете просмотреть историю задач восстановления,

которые были запущены автоматически; вы можете также изучить выходные данные
этих задач. Если вам нужно выполнить поиск неисправности, то Health Explorer пре-
доставляет статьи из базы данных по знаниям, в которых имеются пояснения по при-
чинам изменения состояний и соответствующим сигналам тревоги. Как показано на
рис. 15.25, приведена также информация о задачах диагностики и восстановления,
которые выполняются для разрешения проблем.
Отчетность
System Center Operations Manager 2007 Reporting
Пакет Windows Server 2008 Hyper-V Management Pack в настоящее время не содержит
никаких специфичных для Hyper-V отчетов. Однако имеется много стандартных отче-
Рис. 15.25. Данные из базы данных знаний в Health Explorer
Рис. 15.26. Стандартные отчеты Windows Server 2008 Operating System

тов, которые вы можете использовать для оценки производительности вашей инфра-

структуры Hyper-V (рис. 15.26). Кроме того, вы можете создать новые отчеты, которые
будут фиксировать только специфичные подробности, необходимые для нужной вам
оценки производительности.
Основой отчетности в System Center Operations Manager 2007 является отчетность SQL
Server Reporting, наличие которой требуется для создания и просмотра отчетов. Для
стандартных отчетов никакой специальной настройки не нужно.
Во всех отчетах, где требуется указывать промежуток времени для генерирования графи-
ческих данных, следует ограничиваться разумным его размером. Необходимое для обра-
ботки объемных отчетов время зависит от многих факторов, и в том числе от: размера ба-
зы данных System Center Operations Manager 2007, серверов System Center Operations
Manager 2007 Management Servers, а также от указанного промежутка времени.
Резюме
Менеджер System Center Operations Manager 2007 в сочетании с пакетом управления
Windows Server 2008 Hyper-V Management Pack представляет собой централизованное
решение по наблюдению за состоянием и производительностью инфраструктуры
Hyper-V. При помощи консоли System Center Operations Manager 2007 Operations
Console можно наблюдать за серверами Hyper-V, сигналами тревоги, производитель-
ностью и диаграммами иерархии. Пакет Windows Server 2008 Hyper-V Management
Pack обеспечивает набор мониторов, которые позволяют вам оценивать состояние
служб Hyper-V и систем хранения (на которых находятся динамически расширяющие-
ся диски). Кроме того, для оценки производительности вашей инфраструктуры Hyper-
V вы можете использовать отчеты менеджера System Center Operations Manager 2007.

Следующие источники содержат дополнительную информацию по темам данной
главы:
документ компании Microsoft под названием "Introducing Microsoft System Center
Operations Manager 2007", доступный по ссылке:
http://www.microsoft.com/systemcenter/operationsmanager/en/us
/white-papers.aspx;
Web-сайт Microsoft TechNet, документ "Getting Started with Operations Manager 2007",
доступный по ссылке:
http://technet.microsoft.com/en-us/library/bb309673.aspx;
Web-сайт компании Microsoft, документ "Evaluate Microsoft System Center Operations
Manager 2007 SP1 Today", доступный по ссылке:
http://technet.microsoft.com/en-us/bb738014.aspx.
ГЛАВА 16
Управление сервером Hyper-V

при помощи Windows PowerShell
Программное создание и управление виртуальными машинами и конфигурацией сер-
вера всегда было важной возможностью предоставляемых компанией Microsoft реше-
ний по виртуализации серверов (с момента первого выпуска Virtual Server 2005). В сер-
вере Virtual Server 2005 это был интерфейс прикладного программирования (API) мо-
дели Component Object Model (COM), к которому можно было без труда обращаться
при помощи скриптов или управляемого кода. В сервере Hyper-V стратегия изменилась
и было начато использование Windows Management Instrumentation (WMI) (для того,
чтобы стандартизировать интерфейс вызовов и привести его в соответствие со страте-
гическим направлением развития других продуктов). Применение WMI сохранило
гибкость использования скриптов и управляемого кода для взаимодействия с вирту-
альными машинами и управления ими.
Эта глава сосредоточена на взаимодействии с WMI API для Hyper-V при помощи ново-
го стандарта скриптов (Windows PowerShell) компании Microsoft. Мы предполагаем,
что у вас есть некоторые знания о Windows PowerShell и опыт работы с ним, поэтому
основы работы с Windows PowerShell обсуждаться не будут. Глава начинается с объяс-
нения доступа к классам WMI для Hyper-V при помощи Windows PowerShell и некото-
рых простых скриптов, которые помогут вам начать работу. В оставшейся части этой
главы мы сосредоточимся на использовании библиотеки Windows PowerShell, которая
была разработана для своих нужд компанией Microsoft и доступна по адресу:
http://www.codeplex.com. Несмотря на то, что эта библиотека не поддерживается ком-
панией Microsoft, она содержит некоторые отличные базовые блоки для создания и
обслуживания вашей инфраструктуры Hyper-V.
Разработка всех примеров скриптов для этой главы выполнялась при помощи Windows
PowerShell 2.0 на компьютерах под управлением операционных систем Windows Server
2008 SP2 или Windows Server 2008 R2.
За дополнительной информацией по Windows PowerShell вы можете обратиться к следую-
щим книгам: William R. Stanek. Windows PowerShell 2.0 Administrator's Pocket Consultant
(Microsoft Press, 2009), Wilson E. Windows PowerShell Scripting Guide (Microsoft Press,
1
2008) ; Wilson E. Microsoft Windows PowerShell Step By Step (Microsoft Press, 2007).
Классы WMI для Hyper-V

Классы WMI для Hyper-V позволяют вам управлять почти всеми аспектами сервера
Hyper-V и виртуальных машин. Существует более ста классов, разделенных на 13 кате-
горий. Каждый класс имеет свойства "только для чтения", которые можно легко запро-
сить, чтобы получить состояние или текущую настройку конфигурации. Некоторые
классы имеют методы, которые позволяют вам модифицировать и конфигурировать
настройки, компоненты оборудования, ресурсы и прочие аспекты сервера Hyper-V или
В табл. 16.1 приведен список категорий WMI для Hyper-V и описание того, что каждый
класс позволяет конфигурировать, запрашивать или управлять.
Таблица 16.1. Категории классов WMI для Hyper-V
Категория
Описание
класса
BIOS Классы "только для чтения", которые позволяют вам получить информацию из BIOS
Input Классы для запроса и управления интерфейсами клавиатуры и мыши для виртуаль-
ных машин. Включают методы для управления клавиатурой и мышью
Integration Набор классов, используемых для взаимодействия с компонентами Integration вир-
Components туальных машин. Позволяет вам запрашивать состояние и управлять настройками
компонентов интеграции
Memory Набор классов, используемый для запроса конфигурации памяти виртуальной ма-
шины. Не содержит методов для изменения настроек
Networking Набор классов, используемых для запроса и управления сетевой инфраструктурой
сервера Hyper-V и виртуальных машин. Включает классы для виртуальных коммута-
торов, портов коммутаторов, сетевых адаптеров
Processor Набор классов, используемых для запроса и управления конфигурацией процессо-
ров виртуальных машин. Позволяет взаимодействовать с одним виртуальным про-
цессором или с целым пулом процессоров, выделенных виртуальной машине
Profile Набор классов, используемых для управления глобальным набором ресурсов и ком-
Registration понентов сервера Hyper-V
Resource Набор классов, который позволяет клиенту определить допустимый диапазон на-
Management строек по умолчанию для виртуального ресурса. Предоставляет объект для описа-
ния параметров выделения данного ресурса (минимального и максимального значе-
ний, значения по умолчанию и размера приращения)
Serial Devices Классы "только для чтения", используемые для запроса конфигурации последова-
тельного контроллера и двух последовательных портов виртуальной машины
Storage Набор классов, используемых для запроса и управления объектами хранения.
Объекты хранения состоят из: контроллеров IDE и SCSI, виртуальных жестких дис-
ков, виртуальных флоппи-дисководов, а также виртуальных CD/DVD
1
Уилсон Э. Руководство по сценариям Windows PowerShell. — М.: ЭКОМ Паблишерз, 2009.
Глава 16. Управление сервером Hyper-V при помощи Windows PowerShell 589
Категория
Описание
класса
Video Набор классов, используемых для запроса и управления эмулированным видеокон-

троллером S3, синтетическим видеоадаптером, а также службами удаленного тер-
минала
Virtual System Набор классов, используемых для запроса и управления сервером Hyper-V, вирту-
альными машинами, а также компонентами (вроде моментальных снимков)
Virtual System Набор классов, используемых для взаимодействия с интерфейсами управления
Management системой и управления возможностью импорта и экспорта виртуальных машин
Классы виртуализации WMI более подробно рассматриваются в сети разработчиков
Microsoft Developer Network по адресу http://go.microsoft.com/fwlink/?LinkID=108564.
Подключение к WMI для Hyper-V

Для взаимодействия с сервером Hyper-V или виртуальными машинами вы должны
установить подключение к корневому пространству имен виртуализации (root\vir-
tualization) соответствующего класса WMI для Hyper-V. Например, если вы хотите за-
просить сервер Hyper-V для определения количества зарегистрированных в системе
виртуальных машин, то вам нужно подключиться к классу MSVM_ComputerSystemWMI.
При помощи Windows PowerShell вы можете использовать командлет Get-WMIObject
для подключения к конкретному классу пространства имен virtualization. Приведен-
ный далее код получает для локального компьютера подключение к пространству имен
виртуализации (при помощи класса MSVM_ComputerSystem):
Get-WMIObject -class "MSVM_ComputerSystem" -namespace "root\virtualization"
-computername "."
Эта строка должна присутствовать в каждом скрипте Windows PowerShell, который вы

пишете для взаимодействия с пространством имен WMI для Hyper-V. В зависимости от
того действия, которое вы хотите выполнить, вам понадобится указать здесь тот класс,
с которым вам нужно взаимодействовать. После того как вы получите подключение,
вы сможете напрямую обращаться к свойствам класса и запускать методы класса.
После получения этого подключения есть два способа использования его в скрипте.
Если вы программируете на языке VBScript, тогда возможно вам будет удобнее при-
сваивать результат этого подключения объектной переменной, на которую вы сможете
ссылаться. Для этого вы в начале строки добавляете присваивание ссылке объектной
переменной:
$VM = Get-WMIObject -class "MSVM_ComputerSystem" -namespace "root\virtualization"
-computername "."
Если вы программируете на Windows PowerShell, то вы обычно будете просто пере-

давать через канал вывод этой строки в следующую строку (при помощи добавления
команды канала в конце строки):

-computername "." |
Если вы выполните приведенный выше вызов Get-WMIObject с классом WMI для

Hyper-V, то получите объектную ссылку на коллекцию соответствующих объектов, а в
выводе на экране вы увидите список свойств всех объектов. Например, если вы ис-
пользуете класс MSVM_ComputerSystem, то получите дамп родительского и дочерних раз-
делов локального сервера с перечислением стандартного набора свойств для каждого
раздела. Следующий пример вывода показывает родительский раздел тестового ком-
пьютера. Вы видите, что это родительский раздел, потому что значение Caption равно
Hosting Computer System. Если бы это была виртуальная машина, то значение Caption
было бы равно Virtual Machine.
PS C:\Users\Administrator> gwmi -class "MSVM_ComputerSystem" -namespace
"root\virtualization" -computername "."
__CLASS : Msvm_ComputerSystem
__SUPERCLASS : CIM_ComputerSystem
__DYNASTY : CIM_ManagedElement
__RELPATH : Msvm_ComputerSystem.CreationClassName=
"Msvm_ComputerSystem",Name="M4400R2"
__PROPERTY_COUNT : 29
__DERIVATION : {CIM_ComputerSystem, CIM_System, CIM_
EnabledLogicalElement, CIM_LogicalElement...}
__SERVER : M4400R2
__NAMESPACE : root\virtualization
__PATH : \\M4400R2\root\virtualization:
Msvm_ComputerSystem.CreationClassName=
"Msvm_ComputerSystem",Name="M4400R2"
AssignedNumaNodeList :
Caption : Hosting Computer System
CreationClassName : Msvm_ComputerSystem
Dedicated :
Description : Microsoft Hosting Computer System
ElementName : M4400R2
EnabledDefault : 2
EnabledState : 2
HealthState : 5
IdentifyingDescriptions :
InstallDate :
Name : M4400R2
NameFormat :
OnTimeInMilliseconds :
OperationalStatus : {2}
OtherDedicatedDescriptions :
OtherEnabledState :
OtherIdentifyingInfo :
PowerManagementCapabilities :
PrimaryOwnerContact :
PrimaryOwnerName :
ProcessID :
RequestedState : 12
ResetCapability : 1
Roles :
Status :
StatusDescriptions : {OK}
TimeOfLastConfigurationChange :
TimeOfLastStateChange :
Запросы к локальному серверу Hyper-V

Когда у вас есть подключение к пространству имен WMI для Hyper-V при помощи
класса MSVN_ComputerSystem, вы можете взаимодействовать с сервером Hyper-V (запра-
шивать или устанавливать информацию). Например, если вы хотите получить список
всех виртуальных машин локального сервера Hyper-V и вывести в нем только некото-
рое подмножество свойств виртуальных машин, то вам нужно получить подключение
к пространству имен виртуализации, выполнить запрос для получения всех объектов
виртуальных машин, отфильтровать нужные вам свойства и показать их.
При использовании Windows PowerShell необходим такой код:
GWMI MSVM_ComputerSystem -namespace "root\virtualization" -computername "." |
where {$_.Caption -eq "Virtual Machine"} | Format-List ElementName, Name,
EnabledState
Обратите внимание на переход от полной формы Get-WMIObject к псевдониму GWMI

(для сокращения строки).
Этот скрипт Windows PowerShell получает подключение к пространству имен виртуа-
лизации и передает эту объектную ссылку на коллекцию объектов. Эта коллекция за-
тем передается в условный оператор where для фильтрации только тех объектов, у ко-
торых параметр Caption равен Virtual Machine. Эта отфильтрованная коллекция затем
передается в функцию Format-List, где отображаются три параметра объекта вирту-
альной машины (ElementName, Name и EnabledState).
При использовании VBScript код получился бы несколько другим, но конечный ре-
зультат был бы тем же самым:
$VMCol = GWMI -class "MSVM_ComputerSystem" -namespace "root\virtualization" -
computername "."
foreach ($VM in $VMCol)

{
if ($VM.Caption -match "Virtual Machine")
{
write-host "=================================="
write-host "VM Name: " $VM.ElementName
write-host "VM GUID: " $VM.Name
write-host "VM State: " $VM.EnabledState
}
}
Здесь коллекция объектов виртуальных машин хранится в переменной $VMCol. Этот

объект передается в цикл foreach, чтобы по всей коллекции прошел поиск объектов,
имеющих значение Caption равное Virtual Machine. Если объект удовлетворяет этому
условию, тогда три его параметра выводятся на экран.
На прилагающемся к книге компакт-диске в каталоге \Scripts\Chapter 16 вы найдете те
скрипты PowerShell, которые обсуждаются в этом разделе. Они названы соответственно
Get-VMList.ps1 и Get-VMList_VBS.ps1
Запросы к удаленным серверам Hyper-V

Изменить скрипт для того, чтобы сделать запрос к удаленному компьютеру, очень про-
сто. Для этого необходимо изменить свойство Computername в строке Get-WMIObject ко-
да. Следующий код получает подключение к пространству виртуализации удаленного
компьютера под именем REMOTESVR:
-computername "REMOTESVR"
Для того чтобы запрос был успешным, пользователь, выполняющий скрипт Windows
PowerShell, должен иметь соответствующие права на удаленном сервере.
Запрос по конкретной виртуальной машине

На данный момент мы показали, как получить список виртуальных машин сервера
Hyper-V при помощи Windows PowerShell. Очень часто вам будет нужно выполнить
операцию с конкретной виртуальной машиной. Для того чтобы получить объект-
ную ссылку на конкретную виртуальную машину, вам нужно изменить вызов
Get-WMIObject для класса, введя фильтр для конкретной виртуальной машины.
Фильтр в Windows PowerShell работает следующим образом:
1. Указать имя виртуальной машины или сделать запрос названия.
2. Создать запрос для выбора только этой нужной вам машины из коллекции вирту-
альных машин (по ее имени).
3. Передать запрос в класс при помощи опции -query командлета Get-WMIObject.
4. Выполнить требуемое действие с виртуальной машиной (при помощи новой объ-
ектной ссылки).
Давайте создадим скрипт для этого процесса. Сначала нам нужно получить название
виртуальной машины и для простоты мы присвоим это название переменной. Сле-
дующая строка кода присваивает название виртуальной машины TESTSVR1 перемен-
ной $VMName:
$VMName = "TESTSVR1"
Теперь нам нужно создать запрос. Язык запросов очень похож на T-SQL, так что впол-
не подойдет стандартный оператор SELECT. Если для построения запроса вы используе-
те имя переменной, то вам нужно убедиться в том, что запрос имеет соответствующие
скобки, иначе он закончится неудачей. В следующем коде показан оператор запроса
для выборки всех объектов из класса MSVM_ComputerSystem, но он фильтрует результаты
и показывает только те, у которых ElementName равен указанному в переменной $VMName
названию виртуальной машины. Запрос построен как строка и присвоен переменной

(чтобы его было легко использовать в вызове Get-WMIObject). Обратите внимание на
использование двойных кавычек вокруг одиночной кавычки:
$query = "SELECT * FROM MSVM_ComputerSystem WHERE ElementName='" + $VMName + "'"
После создания строки запроса вы можете использовать его в модифицированном вы-

зове Get-WMIObject для возвращения объектной ссылки на конкретную виртуальную
машину. Нужно просто добавить опцию -query, за которой должна идти строка запро-
са. Следующий код показывает добавленную в вызов Get-WMIObject опцию -query;
объектная ссылка присваивается переменной $VM:
$VM = GET-WMIObject -query $query -namespace "root\virtualization" -computername "."
Теперь, когда у вас есть объектная ссылка на виртуальную машину ($VM), вы можете
ссылаться на любые свойства (для получения их значений) или вызывать любые
имеющиеся методы. Для получения свойства виртуальной машины вы делаете прямую
ссылку на него (при помощи синтаксиса $VM.свойство). Следующий код извлечет то
время, в течение которого виртуальная машина была включена (в миллисекундах) при
помощи свойства OnTimeInMilliseconds:
$VM.OnTimeInMilliseconds
Для ссылки на метод виртуальной машины вы должны указать все требуемые парамет-
ры. Например, если вы хотите запросить старт виртуальной машины, то можете ис-
пользовать метод RequestStateChange() с указанием значения 2. Следующий код вызы-
вает метод RequestStateChange и возвращает результат вызова в переменную, которую
можно проверить на значение состояния:
$Result = $VM.RequestStateChange(2)
Если мы скомбинируем эти отдельные строки кода в скрипт Windows PowerShell, ко-
торый по значению OnTimeInMilliseconds проверяет, включена ли в данный момент
виртуальная машина, а затем запрашивает ее запуск, то мы получим следующий код:
$query = "SELECT * FROM MSVM_ComputerSystem WHERE ElementName='" +
$VMName + "'"
$VM = GET-WMIObject -query $query -namespace "root\virtualization" -
computername "."
if ($VM.OnTimeInMilliseconds -eq 0)
{
$Result = $VM.RequestStateChange(2)
}
На прилагающемся к книге компакт-диске в каталоге \Scripts\Chapter 16 вы найдете тот
скрипт PowerShell, который обсуждается в этом разделе. Он имеет название StartVM.ps1.
Запрос нескольких классов

Иногда действие, которое вы хотите выполнить, требует использования более чем
одного класса. Хорошим примером является попытка завершить работу виртуальной
машины. Несмотря на то, что было бы вполне разумно иметь в объекте виртуальной
машины метод для завершения ее работы, все не так просто. Вы можете использовать
метод RequestStateChange виртуальной машины для ее выключения, но завершение
работы виртуальной машины — это такое действие, которое должно быть иницииро-
вано гостевой операционной системой виртуальной машины. Архитектура Hyper-V
имеет (при помощи инсталлированных в виртуальной машине служб интеграции) ин-
терфейс для инициирования управляемого завершения работы. Поэтому для заверше-
ния работы виртуальной машины вы должны сделать следующее:
1. Получить доступ к объекту конкретной виртуальной машины.
2. Получить доступ к компоненту ShutdownComponent виртуальной машины.
3. Вызвать метод InitiateShutdown компонента ShutdownComponent.
Первый шаг процесса был уже описан в предыдущем разделе, поэтому повторяться мы
не будем. Давайте начнем с того факта, что у нас в переменной $VM есть объектная
ссылка на конкретную виртуальную машину.
Для того чтобы получить доступ к классу MSVM_ShutdownComponent виртуальной маши-
ны, вы должны написать запрос, который получает объектную ссылку на этот класс
(при помощи объектной ссылки на виртуальную машину). Строка запроса приведет
к созданию такой строки кода Windows PowerShell:
$query = "SELECT * FROM MSVM_ShutdownComponent WHERE SystemName='" + $VM.Name + "'"
После создания строки запроса вы можете использовать опцию -query командлета Get-
WMIObject для выполнения запроса с целью получения объектной ссылки на компо-
нент ShutdownComponent конкретной виртуальной машины.
$Shutdown = GET-WMIObject -query $query -namespace "root\virtualization" -
computername "."
Когда у вас есть объектная ссылка на компонент ShutdownComponent виртуальной маши-

ны, то вы можете вызвать метод InitiateShutdown и запросить завершение работы. Ме-
тод InitiateShutdown имеет два параметра: первый указывает, следует ли принудитель-
но выполнить завершение работы в том случае, когда этому процессу что-то препятст-
вует; второй — задаваемая пользователем строка с описанием причины завершения
работы. Эта строка будет занесена в журнал вместе с событием завершения работы.
Следующий код показывает вызов метода InitiateShutdown с требованием принуди-
тельного завершения работы и с предоставлением строки для описания причины:
$Result = $Shutdown.InitiateShutdown($true, "Shutting down due to data center move")
Если вы сведете этот процесс в один скрипт Windows PowerShell, который пытается
завершить работу виртуальной машины TESTSVR1 на локальном сервере Hyper-V, то
получите следующий код:

$VMName + "'"
$VM = GET-WMIObject -query $query -namespace "root\virtualization"
-computername "."
$query = "SELECT * FROM MSVM_ShutdownComponent WHERE SystemName='" +

$VM.name + "'"
$Shutdown = GET-WMIObject -query $query -namespace "root\virtualization"
-computername "."
$Result = $Shutdown.InitiateShutdown($true,
"Shutting down due to data center move ")
скрипт PowerShell, который обсуждается в этом разделе. Он имеет название
ShutdownVM.ps1.
Модификация настроек виртуальной машины

Для модификации настроек виртуальной машины требуется получить доступ к конфи-
гурационной информации, модифицировать настройку, а затем использовать службу
управления для реализации изменения. Возможно, вы помните из главы 3, что это тре-
буется потому, что все изменения в конфигурации виртуальной машины должны за-
прашиваться из службы Virtual Machine Management Service (VMMS) и должны выпол-
няться компонентом Configuration Component.
Для модификации настройки виртуальной машины требуется:
1. Получить объектную ссылку на конкретную виртуальную машину.
2. Получить объектную ссылку на текущие настройки конфигурации виртуальной ма-
шины.
3. Модифицировать ту настройку, которую вы хотите изменить.
4. Получить объектную ссылку на MSVM_VirtualSystemManagementService.
5. Использовать метод ModifyVirtualSystem объекта MSVM_VirtualSystemManagementService
и передать ему путь к объекту виртуальной машины и объект данных модифициро-
ванной конфигурационной настройки.
Для демонстрации использования этого процесса изменения настройки виртуальной
машины мы будем использовать пример переименования виртуальной машины. Для
переименования виртуальной машины вам понадобятся существующее название и но-
вое название:
$VMNameOld = "TESTSVR1"
$VMNameNew = "TESTSERVER1"
Затем вам нужна объектная ссылка на виртуальную машину:

$VMNameOld + "'"
-computername "."
Теперь вам нужно получить объектную ссылку на конфигурационные настройки вир-

туальной машины. VirtualSystemManagementService поддерживает эту ссылку как класс
Associator. Вместо использования запроса SELECT для получения ссылки на класс
Associator, вы должны использовать новый запрос ASSOCIATORS OF. Определение

ASSOCIATORS для виртуальной машины делается при помощи запроса такого формата:
ASSOCIATORS OF {$VM}
Здесь $VM — объектная ссылка на виртуальную машину.

Для получения доступа к определенному классу Associator при помощи запроса
ASSOCIATORS OF вам нужно использовать фильтр в выражении WHERE. Класс Associator,
который содержит информацию о настройках виртуальной машины, называется
MSVM_SettingsDefineState. Следующий код дает пример строки запроса ASSOCIATORS OF
и реального запроса для получения объектной ссылки на настройки виртуальной ма-
шины:
$query = "Associators of {$VM} WHERE AssocClass=MSVM_SettingsDefineState"
$VMSettings = GET-WMIObject -query $query –namespace "root\virtualization"
-computername "."
Теперь, когда у вас есть объектная ссылка на настройки виртуальной машины, вы мо-
жете получить доступ к свойству ElementName виртуальной машины и модифицировать
его (путем присвоения нового значения с использованием переменной, которой при-
своено новое название виртуальной машины):
$VMSettings.ElementName = $VMNameNew
При этом модифицируется настройка, которая в данный момент загружена в память, но

это изменение еще не записано в конфигурационный xml-файл виртуальной машины.
Для того чтобы произвести это изменение, нам нужна объектная ссылка на
MSVM_VirtualSystemManagementService. Для того чтобы получить объектную ссылку на
службу управления, нужно использовать командлет Get-WMIObject и имя класса
MSVM_VirtualSystemManagementService.
$VMManagementService = GET-WMIObject –class "MSVM_VirtualSystemManagementService"

–namespace "root\virtualization" -computername "."
Когда у вас есть объектная ссылка на MSVM_VirtualSystemManagementService, вы можете

использовать метод ModifyVirtualSystem для записи изменений в памяти обратно в
конфигурационный файл. Для метода ModifyVirtualSystem требуются два входных па-
раметра: путь к конфигурационному файлу виртуальной машины и строка, которая
представляет собой текущий объект SystemSettingData в памяти. Путь к конфигураци-
онному файлу виртуальной машины — это стандартное свойство объекта виртуальной
машины (__PATH). Для того чтобы конвертировать объект SystemSettingData из памяти
в строку, вы должны использовать функцию GetText (для выполнения сериализации
текста):
$Result = $VMManagementService.ModifyVirtualSystem
($VM.__PATH,$VMSettings.GetText(1))
Для вызова функции GetText при помощи Windows PowerShell требуется доступ к исход-
ному объекту; это делается при помощи psbase. В PowerShell 1.0 вам пришлось бы исполь-
зовать $VMSettings.psbase.GetText(1) (вместо $VMSettings.GetText(1) в версии
PowerShell 2.0).
Если свести весь код в один скрипт Windows PowerShell 2.0 (который будет переиме-
новывать виртуальную машину из TESTSVR1 в TESTSERVER1), то получится сле-
дующий код:
$VMNameOld = "TESTSVR1"
$VMNameNew = "TESTSERVER1"

$VMNameOld + "'"
-computername "."
$query = "Associators of {$VM} WHERE AssocClass=MSVM_SettingsDefineState"

$VMSettings = GET-WMIObject -query $query -namespace
$VMSettings.ElementName = $VMNameNew
$VMManagementService = GET-WMIObject -class

"MSVM_VirtualSystemManagementService"
-namespace "root\virtualization" -computername "."
$Result = $VMManagementService.ModifyVirtualSystem
$VM.__PATH, $VMSettings.GetText(1))
На прилагающемся к книге диске в каталоге \Scripts\Chapter 16 вы найдете тот скрипт
PowerShell, который обсуждается в этом разделе. Он имеет название RenameVM.ps1.
Для получения более подробной информации по Associators и о том, как делать к ним за-
просы, обратитесь на сайт разработчиков Microsoft Developer Network по следующей ссыл-
ке: http://msdn.microsoft.com/en-us/library/aa384793(VS.85).aspx.
Использование библиотеки
Windows PowerShell Hyper-V Library
Если вы не хотите начинать все с нуля, то библиотека функций Windows PowerShell
будет отличным пособием как для изучения, так и для использования. Сотрудники
компании Microsoft разработали образцовую библиотеку управления Windows
PowerShell для Hyper-V. Эта библиотека доступна на сайте проектов с открытым кодом
компании Microsoft по адресу: http://pshyperv.codeplex.com. Предоставленная в этой
главе информация основана на версии 1.00b библиотеки.
Библиотека состоит из набора функций, которые позволяют вам управлять следующи-
ми компонентами:
конфигурация виртуальной машины и ее состояние;
виртуальные жесткие диски;
виртуальные гибкие диски;

виртуальные образы CD/DVD;
виртуальные сетевые адаптеры;
виртуальные сетевые коммутаторы;
моментальные снимки.
Кроме того, библиотека имеет целый набор вспомогательных функций, которые помо-
гают оптимизировать многократное использование кода и поддерживать согласован-
ное взаимодействие с функциями.
Изменение политики
Windows PowerShell Execution Policy
После скачивания библиотеки вам нужно будет инсталлировать ее на вашем компью-
тере (для использования имеющихся в ней функций). Перед ее инсталляцией вам нуж-
но будет модифицировать политику выполнения для вашего Windows PowerShell. Для
того чтобы увидеть вашу текущую настройку политики выполнения, используйте ко-
мандлет Get-ExecutionPolicy. Существуют четыре возможные политики выполнения:
Restricted — скрипты выполняться не могут. Windows PowerShell может использо-
ваться только в интерактивном режиме;
AllSigned — могут выполняться только скрипты, подписанные доверенным издате-
лем;
RemoteSigned — скачанные скрипты перед их выполнением должны быть подписа-
ны доверенным издателем;
Unrestricted — отсутствие ограничений; могут выполняться все скрипты Windows
PowerShell.
Политика по умолчанию — Restricted. Для использования библиотеки управления
PowerShell для Hyper-V вам нужно загрузить ее в память, чтобы все функции были дос-
тупны. По умолчанию эта библиотека не подписана, так что единственный режим,
в котором вы можете ее использовать, — это Unrestricted.
Для настройки текущей политики выполнения в значение Unrestricted используйте ко-
мандлет Set-ExecutionPolicy в командной строке Windows PowerShell (с Unrestricted в
качестве единственного передаваемого параметра):
Set-ExecutionPolicy Unrestricted
Создание самозаверенных скриптов
Когда вы разрабатываете скрипты, то у вас есть возможность создать собственный само-
заверенный сертификат и подписать скрипты, чтобы они могли выполняться при политике
AllSigned на вашем локальном компьютере.
Для создания самозаверенного сертификата используйте MakeCert.exe из Microsoft .NET
Framework или набора Platforms SDK. MakeCert позволяет вам создать локальный центр
сертификации на вашем локальном компьютере, а затем создать самозаверенный серти-
фикат при помощи этого центра сертификации. Этот сертификат может быть защищен па-
ролем закрытого ключа.
Когда у вас есть самозаверенный сертификат, вы можете подписать скрипт при помощи
командлета Set-AuthenticodeSignature, передав ему файл скрипта для подписи и сертифи-
кат для его подписи.
Чтобы получить более подробную информацию и пошаговые процедуры, в командной стро-
ке Windows PowerShell запустите Get-Help about_signing.
Майк Вильямс (Mike Williams, Senior Consultant (Microsoft Consulting Services))
Загрузка библиотеки в память

После изменения политики выполнения вы можете загрузить библиотеку в память,
чтобы функции стали доступны. Для загрузки библиотеки в память используйте сле-
дующую процедуру:
1. Откройте командную строку Windows PowerShell.
2. Перейдите в тот каталог, который содержит скачанную вами библиотеку управле-
ния PowerShell для Hyper-V.
3. Выполните следующую команду:
..\hyperv.ps1
4. Теперь вы можете использовать функции библиотеки. Проверьте это при помощи
выполнения следующей функции в командной строке Windows PowerShell:
Get-VhdDefaultPath
5. Если команда выполнится без ошибок и выдаст путь по умолчанию для хранения
виртуальных жестких дисков на сервере Hyper-V, то библиотека загрузилась пра-
вильно.
Функции библиотеки
Hyper-V PowerShell Management Library
Библиотека управления Hyper-V PowerShell имеет четыре основных категории функ-
ций для создания скриптов Windows PowerShell для управления: виртуальными маши-
нами; виртуальными дисководами (дисками, DVD- и гибкими дисками); виртуальными
сетями; а также моментальными снимками. В число этих функций входят стандартные
(такие, как get, set, add и new), а также специфичные для Hyper-V (такие, как start,
stop, remove, import, export и т. д.). Кроме непосредственно используемых функций
есть еще и вспомогательные функции, которые облегчают использование библиотеки.
Эти функции предоставляют возможности: проверки конфигураций; выдачи пользова-
телю запросов на выбор из списка значений; выбора нескольких элементов за один раз;
а также форматирования вывода.
Следующие несколько таблиц дают списки главных категорий функций с кратким опи-
санием того, что делает каждая функция. Полный список функций см. в документации
на библиотеку управления.
В табл. 16.2 приведен список всех имеющихся в библиотеке функций для управления
виртуальными машинами и дано описание каждой функции.
Таблица 16.2. Функции Windows PowerShell для виртуальных машин
Choose-VM Позволяет пользователю выбрать виртуальные машины из списка
New-VM Создает новую виртуальную машину
New-VMConnectSession Запускает сеанс VMConnect с виртуальной машиной
Get-VM Возвращает объектную ссылку WMI на виртуальную машину
Get-VMBackupScript Получает скрипт для резервного копирования одной или нескольких
Get-VMByMACaddress Обнаруживает виртуальную машину по ее МАС-адресу
Get-VMJPEG Получает JPEG-изображение текущего экрана виртуальной машины
Get-VMSettingData Возвращает объект данных настройки для виртуальной машины
Get-VMMemory Возвращает количество памяти, выделенное виртуальной машине
Get-VMCPUCount Получает количество и удельные веса выделенных виртуальной
машине процессоров
Get-VMProcessor Получает активные виртуальные процессоры и данные по их
загрузке
Get-VMDiskController Получает контроллер IDE или SCSI
Get-VMSerialPort Возвращает информацию о последовательных портах
Set-VM Устанавливает свойства существующей виртуальной машины
Set-VMState Вызывается функциями Start-VM, Stop-VM и Suspend-VM для
установки запрошенного состояния
Set-VMMemory Устанавливает количество выделенной виртуальной машине
памяти
Set-VMCPUCount Устанавливает количество выделенных виртуальной машине
виртуальных процессоров
Set-VMSerialPort Устанавливает соответствие между последовательными портами
виртуальной машины и именованными каналами
Add-VMSCSIcontroller Добавляет синтетический контроллер SCSI в виртуальную машину
Remove-VM Удаляет виртуальную машину
Remove-VMSCSIcontroller Удаляет синтетический контроллер SCSI из виртуальной машины
Export-VM Вызывает процесс экспорта Hyper-V
Import-VM Вызывает процесс импорта Hyper-V
Shutdown-VM Завершает работу операционной системы виртуальной машины при
помощи интерфейса завершения работы служб интеграции
Start-VM Запускает виртуальную машину или перезапускает сохраненную
виртуальную машину
Stop-VM Выключает виртуальную машину без предварительного запроса
на завершение работы операционной системы
Suspend-VM Переводит виртуальную машину в сохраненное состояние
Test-VMHeartBeat Тестирует отклики от обеспечивающего тактовые импульсы компо-
нента служб интеграции
В табл. 16.3 дан список всех функций, имеющихся в библиотеке для управления вирту-
альными жесткими дисками и краткое описание каждой функции.
Таблица 16.3. Функции Windows PowerShell для виртуальных жестких дисков
New-VHD Создает файл нового виртуального жесткого диска
Get-VMDriveByController Получает подключенные к контроллеру виртуальные жесткие диски
Get-VMDisk Получает список используемых образов виртуальных жестких дисков
Get-VMDiskByDrive Получает образ виртуального жесткого диска, подключенный к диско-
воду
Get-VMDefaultPath Получает путь по умолчанию, используемый сервером Hyper-V для
файлов виртуальных жестких дисков
Get-VHDInfo Получает информацию о виртуальном жестком диске, такую как его
родитель или размер на диске
Add-VMDrive Подключает виртуальный жесткий диск к контроллеру
Add-VMDisk Монтирует образ виртуального жесткого диска в дисковод
Add-VMNewHardDisk Подключает новый образ виртуального жесткого диска к новому диско-
воду
Set-VMDisk Изменяет подключенный к дисководу образ виртуального жесткого
диска
Test-VHD Проверяет, что виртуальный жесткий диск может быть смонтирован
и что все его родители также могут быть смонтированы
Compact-VHD Сжимает динамический виртуальный жесткий диск для экономии места
на сервере
Convert-VHD Изменяет тип виртуального жесткого диска
Expand-VHD Увеличивает размер виртуального жесткого диска
Merge-VHD Сливает дочерний виртуальный диск с его родителем (для формиро-
вания нового диска)
Mount-VHD Монтирует виртуальный жесткий диск на сервере
UnMount-VHD Демонтирует ранее смонтированный виртуальный жесткий диск с сер-
вера
Remove-VMDRIVE Удаляет виртуальный жесткий диск с контроллера
В табл. 16.4 дан список всех функций, имеющихся в библиотеке для управления вирту-
альными сетями и виртуальными сетевыми коммутаторами (с кратким описанием каж-
дой функции).
Таблица 16.4. Функции Windows PowerShell для виртуальных сетей и коммутаторов
Choose-VMExternalEthernet Позволяет пользователю выбрать сетевую карту сервера
Choose-VMSwitch Позволяет пользователю выбрать виртуальный коммутатор
New-VMExternalSwitch Создает виртуальный коммутатор, подключенный к сетевой карте
сервера
New-VMInternalSwitch Создает виртуальный коммутатор, доступный для виртуальных
машин и сервера
New-VMPrivateSwitch Создает виртуальный коммутатор, доступный для виртуальных
машин
New-VMSwitchPort Определяет новый порт на виртуальном коммутаторе
Get-VMSwitch Возвращает информацию о виртуальных коммутаторах
В табл. 16.5 дан список всех функций, имеющихся в библиотеке для управления мо-
ментальными снимками виртуальных машин (с описанием каждой функции).
Таблица 16.5. Функции Windows PowerShell для моментальных снимков
Apply-VMSnapshot Применяет моментальный снимок к виртуальной машине
Choose-VMSnapshot Позволяет пользователю выбрать моментальный снимок для виртуаль-
ной машины
New-VMSnapshot Создает новый моментальный снимок виртуальной машины
Get-VMSnapshot Получает информацию о моментальных снимках виртуальной машины
Get-VMSnapshotTree Форматирует представление моментальных снимков виртуальной маши-
ны в виде дерева
Remove-MSnapshot Удаляет моментальный снимок или дерево моментальных снимков
Rename-MSnapshot Переименовывает моментальный снимок
Update-VMSnapshot Удаляет моментальный снимок и создает новый с тем же самым назва-
нием

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

Библиотека Hyper-V PowerShell содержит функцию New-VM, которая позволяет создать
новую виртуальную машину одной строкой кода Windows PowerShell. Эта функция
принимает два параметра командной строки. В табл. 16.6 приведен синтаксис парамет-
ров функции New-VM.
Таблица 16.6. Параметры командной строки функции New-VM
Ключ Параметр Пример

-name Название виртуальной машины -name "TestVM1"
-server Имя удаленного сервера -server "Server1"
Требуется только один параметр — название виртуальной машины. Если имя сервера
отсутствует, то по умолчанию принимается локальный сервер. Для создания новой
виртуальной машины достаточно ввести в командной строке Windows PowerShell сле-
дующую строку (и нажать клавишу <Enter>):
New-VM "TestVM1"
Вы заметили, что параметр -name указан не был. Функция предполагает, что поскольку
есть один обязательный параметр и в командной строке указан один параметр, то это и
есть обязательный параметр.
Когда вы создаете новую виртуальную машину при помощи функции New-VM, то она
создает только профиль виртуальной машины, регистрирует виртуальную машину на
сервере Hyper-V, добавляет один виртуальный процессор, а также конфигурирует вир-
туальной машине 512 Мбайт оперативной памяти. Если вы хотите изменить эти значе-
ния по умолчанию или добавить в виртуальную машину дополнительное оборудова-
ние, то вам нужно будет написать код Windows PowerShell для внесения этих измене-
ний, либо (что еще лучше) можно использовать для выполнения этих изменений
другие функции библиотеки.
Например, если вы хотите увеличить память по умолчанию до 1 Гбайт, увеличить ко-
личество виртуальных процессоров до 2, добавить виртуальный жесткий диск на пер-
вичный контроллер IDE, добавить виртуальный жесткий диск на порт 3 контроллера
SCSI, смонтировать ISO-образ виртуального DVD на второй порт контроллера IDE, а
также добавить сетевой адаптер и подключить его к виртуальной сети, то вам нужно
использовать следующие функции библиотеки:
Set-VMMemory;
Set-VMCPUCount;
Add-VMDrive;
Add-VMDisk;
Add-VMNic.
В табл. 16.7 перечислены параметры функции Set-VMMemory.
Таблица 16.7. Параметры командной строки функции Set-VMMemory

-vm Объектная ссылка на виртуальную машину $VM
-memory Размер памяти, который надо установить -memory 1 GB

В табл. 16.8 перечислены параметры функции Set-VMCPUCount.
Таблица 16.8. Параметры командной строки функции Set-VMCPUCount
-CPUCount Количество выделяемых процессоров -CPUCount 2
В табл. 16.9 перечислены параметры функции Add-VMDrive.
Таблица 16.9. Параметры командной строки функции Add-VMDrive
-controllerID К какому контроллеру подключить дисковод -controllerID 0
-lun Порт контроллера для подключения дисковода -lun 3
-DVD Ключ, который настраивает выполнение действий с DVD -DVD

(вместо действий с виртуальным жестким диском)
-SCSI Ключ, который устанавливает тип контроллера SCSI -scsi
В табл. 16.10 перечислены параметры функции Add-VMDisk.
Таблица 16.10. Параметры командной строки функции Add-VMDisk
-controllerID К какому контроллеру подключить дисковод -controllerID 0
-lun Порт контроллера для подключения дисковода -lun 3
-DVD Ключ, который настраивает выполнение дейст- -DVD

вий с DVD (вместо действий с виртуальным
жестким диском)
-SCSI Ключ, который устанавливает тип контроллера -scsi

SCSI
-vhdpath Путь к тому месту, где должен храниться вир- "F:\VMs\TESTVM1\TEST.VHD"

туальный жесткий диск. Если путь не указан, то "TEST.VHD"
виртуальный жесткий диск создается в место-
положении по умолчанию
В табл. 16.11 перечислены параметры функции Add-VMNic.
Таблица 16.11. Параметры командной строки функции Add-VMNic

-vm Объектная ссылка на виртуальную $VM
машину
-virtualswitch Виртуальный коммутатор, к которому -virtualSwitch "Internal Network"

следует привязать сетевой адаптер
-mac Статический МАС-адрес для присваи- -mac "00155D010110"
вания виртуальной машине
Следующий скрипт Windows PowerShell дает пример того, как нужно комбинировать
соответствующие функции для модификации существующих настроек и создания но-
вой конфигурации виртуальной машины сразу же после ее создания:
$VMName = "TestVM2"
$NewVM = (New-VM $VMName)
Set-VMMemory $NewVM -memory 1GB

Set-VMCPUCount $NewVM -CPUCount 2
Add-VMDrive $NewVM 0 0
Add-VMDisk $NewVM 0 0 "Existingvhd.vhd"
Add-VMDrive $NewVM 0 1 -dvd
Add-VMDisk $NewVM 0 1 "Windows.iso" -dvd
Add-VMDrive $NewVM 0 3 -scsi
Add-VMDisk $NewVM 0 3 "Datavhd.vhd" -scsi
Add-VMNIC $NewVM (choose-VMSwitch) -virtualSwitch "Internal Network"
Скрипт начинается с того, что название виртуальной машины TestVM2 передается в

функцию New-VM; объектная ссылка на новую виртуальную машину сохраняется в пе-
ременной $NewVM. Все использованные в скрипте функции конфигурирования прини-
мают в качестве первого параметра объектную ссылку на виртуальную машину. Не-
смотря на то, что большинство шагов конфигурирования представляют собой одиноч-
ные вызовы функций, для добавления в виртуальную машину виртуального жесткого
диска или образа DVD требуются два вызова. Первый вызов функции Add-VMDrive ре-
зервирует порт для фактического добавления диска при помощи функции Add-VMDisk.
Функции Add-VMDisk и Add-VMDrive поддерживают как виртуальные жесткие диски, так
и образы виртуальных DVD. Для выполнения операций с DVD (вместо виртуального
жесткого диска) используется ключ -dvd. Для выполнения операций с контроллером
SCSI (вместо IDE) используется ключ -scsi. Второй и третий параметры функций Add-
VMDisk и Add-VMDrive указывают тип контроллера и номер порта, который следует ис-
пользовать при операции.
Функция Add-VMNic позволяет вам добавить в виртуальную машину виртуальный сете-

вой адаптер, сконфигурировать этот адаптер, а также (необязательно) подключить его
к виртуальному сетевому коммутатору. Если вы не укажете параметр -virtualswitch,
то виртуальный сетевой адаптер останется в отключенном состоянии.
Итак, десятью строками кода Windows PowerShell вы создали новую виртуальную ма-
шину, модифицировали имеющееся в ней количество памяти и виртуальных процессо-
ров, добавили существующий виртуальный жесткий диск на контроллер IDE в качестве
загрузочного диска, добавили существующий виртуальный жесткий диск на контрол-
лер SCSI в качестве диска данных, а также добавили сетевой адаптер и подключили его
к виртуальной сети сервера.
скрипт PowerShell, который обсуждается в этом разделе. Он имеет название CreateVM.ps1.
Удаление виртуальных машин

Удаление виртуальных машин с локального или удаленного серверов Hyper-V — это
одна операция командной строки с использованием функции Remove-VM.
В табл. 16.12 перечислены параметры функции Remove-VM.
Таблица 16.12. Параметры командной строки функции Remove-VM
-wait Ключ для ожидания выполнения функции перед продол- -wait

жением
Использование функции Remove-VM позволяет вам указать одну виртуальную машину

для удаления, но вам нужно знать название виртуальной машины.
Remove-VM "TESTVM1"
Если вы используете функцию Remove-VM вместе с функцией Choose-VM, то вы сможете

создать единую командную строку Windows PowerShell, которая выдаст пользователю
список имеющихся виртуальных машин.
В табл. 16.13 перечислены параметры функции Choose-VM.
Таблица 16.13. Параметры командной строки функции Choose-VM

-multiple Ключ для того, чтобы пользователь мог выбрать -server "Server1"
несколько виртуальных машин из списка
Если вы не задали параметров командной строки, то функция Choose-VM подразумевает

локальный сервер Hyper-V, и пользователь может выбрать из списка одну виртуальную
машину.
Choose-VM | Remove-VM
Когда вы выполняете эту командную строку, вам выдаются: таблица всех зарегистри-
рованных виртуальных машин с уникальными идентификаторами ID и подсказка
"Which One?". Введите идентификатор ID той машины, которую вы хотите выбрать, и
нажмите клавишу <Enter>. Когда пользователь выбирает виртуальную машину из спи-
ска, то объектная ссылка на виртуальную машину автоматически передается в функ-
цию Remove-VM и функция Remove-VM выполняется.
Если вы хотите указать сервер для выбора виртуальных машин, тогда добавьте ключ
-server и укажите имя сервера. Когда вы делаете
это для функции Choose-VM, функция
Remove-VM автоматически понимает, что действие удаления должно произойти на уда-
ленном сервере.
Choose-VM -Server HVServer1 | Remove-VM
Если вы хотите быстро удалить все виртуальные машины с сервера, то можете совме-
стно использовать функции Get-VM и Remove-VM в единой командной строке:
Get-VM | Remove-VM
Используйте такую комбинацию очень осторожно. Она удалит все виртуальные

машины с локального сервера и не выдаст вам никаких запросов или предупреждений
о том, что собирается это сделать.
Управление виртуальными жесткими дисками

Для создания новых виртуальных жестких дисков при помощи библиотеки управления
Hyper-V PowerShell требуется только одна функция New-VHD. В табл. 16.14 перечислены
ее параметры. Она имеет только один обязательный параметр -vhdpath (путь к тому
месту, где нужно создать виртуальный жесткий диск).
Таблица 16.14. Параметры командной строки функции New-VHD

-vhdpath Путь к месту хранения виртуального диска. Если "F:\VMs\TESTVM1\TEST.VHD"
путь не указан, то виртуальный жесткий диск соз- "TEST.VHD"
дается в месте по умолчанию
-size Размер виртуального жесткого диска 200GB
-fixed Указывает виртуальный жесткий диск фиксирован- -fixed

ного типа
-parent Путь к родительскому виртуальному жесткому дис- "F:\ParentDisks\BaseVHD.VHD"

ку при создании разностного диска
-wait Ключ для ожидания выполнения перед продолже- -wait

нием
Обратите внимание, что если указан параметр -parent, то параметры -size и -fixed
игнорируются.
Далее приведено несколько примеров использования параметров командной строки.
Первый пример создает новый виртуальный жесткий диск размером в 20 Гбайт в ука-
занном месте:
New-VHD "F:\VMs\NewDisk.vhd" -size 20GB
Второй пример создает фиксированный виртуальный жесткий диск размером

200 Гбайт в месте хранения виртуальных дисков по умолчанию и ждет завершения его
создания, после чего передает управление следующей строке скрипта Windows
PowerShell:
New-VHD "NewDisk2.vhd" -size 200GB -fixed -wait
Третий пример создает дочерний разностный диск размером 40 Гбайт из указанного

родительского диска, который является обработанным утилитой Sysprep диском
Windows Server 2008 SP2:
New-VHD "NewChildDisk.vhd" -size 40GB -parent "F:\ParentDisks\SysprepWin2K8SP2.vhd"
Функция New-VHD создает виртуальный жесткий диск, но не подключает этот диск к

виртуальной машине. Для подключения нового виртуального жесткого диска вы долж-
ны использовать функции Add-VMDrive и Add-VMDisk (как это было показано в предыду-
щем разделе).
Вполне допустимо использовать эти функции в одном скрипте и даже объединять их
при помощи канала, чтобы уменьшить количество строк кода, однако если вы делаете
это регулярно, то, возможно, будет более эффективным иметь одну функцию, которая
будет комбинировать все действия. Функция Add-VMNewHardDisk предназначена как раз
для этого. Она включает в себя три функции — New-VHD, Add-VMDrive и Add-VMDisk —
и представляет собой всего одну строку кода Windows PowerShell.
Функции Add-VMNewHardDisk требуется только один параметр (объектная ссылка на
виртуальную машину). Если указана только ссылка на виртуальную машину, то
Add-VMNewHardDisk создает динамически расширяющийся виртуальный жесткий диск
(с именем виртуальной машины) размером 127 Гбайт в месте хранения по умолчанию,
подключенный к порту 0 первичного контроллера IDE.
Таблица 16.15. Параметры командной строки функции Add-VMNewHardDisk

-size Размер виртуального жесткого диска 200GB
-fixed Указывает виртуальный жесткий диск фикси- -fixed
рованного типа
-server Имя удаленного сервера Server1
-parent Путь к родительскому виртуальному жестко- "F:\ParentDisks\BaseVHD.VHD"
му диску при создании разностного диска
-controllerID К какому контроллеру подключить виртуаль- 0
ный жесткий диск

-lun Порт контроллера для подключения вирту- 3
ального жесткого диска
-vhdpath Путь к тому месту, где должен храниться "F:\VMs\TESTVM1\TEST.VHD"
виртуальный жесткий диск. Если путь не ука-
"TEST.VHD"
зан, то виртуальный жесткий диск создается
в местоположении по умолчанию
-scsi Ключ, который устанавливает тип контролле- -scsi
ра SCSI
Далее приведено несколько примеров использования параметров командной строки

функции Add-VMNewHardDisk. Первый пример создает новый виртуальный жесткий диск
размером в 20 Гбайт в указанном месте и подключает его к порту 0 контроллера IDE:
Add-VMNewHardDisk -vm $VM -vhdpath "F:\VMs\NewDisk.vhd" -size 20GB
Второй пример создает фиксированный виртуальный жесткий диск размером

200 Гбайт в месте хранения виртуальных дисков по умолчанию и подключает его
к порту 4 контроллера SCSI:
New-VHD -vm $VM -vhdpath "NewDisk2.vhd" -size 200GB -fixed -controllerID 1 -lun 4
-scsi
Третий пример создает дочерний разностный диск размером 40 Гбайт из указанного

родительского диска и по умолчанию подключает его к порту 0 контроллера IDE 0:
New-VHD -vm $VM -vhdpath "NewChildDisk.vhd" -size 40GB -parent "F:\ParentDisks
\SysprepWin2K8SP2.vhd"
Управление виртуальными сетями

Виртуальные сети — это пути для обмена между виртуальными машинами. Существу-
ют три типа виртуальных сетей: внешние, внутренние и частные. Внешние виртуаль-
ные сети привязаны к физическим сетевым адаптерам сервера Hyper-V, чтобы вирту-
альные машины могли вести обмен по физической локальной сети (LAN). Внутренние
виртуальные сети позволяют виртуальным машинам обмениваться с тем сервером
Hyper-V, на котором они работают (но не с физической LAN). Внутренние виртуаль-
ные сети не привязаны к физическим сетевым адаптерам сервера. Частные виртуаль-
ные сети позволяют виртуальным машинам обмениваться с другими виртуальными
машинами, подключенными к этой же частной виртуальной сети (но не с сервером
Hyper-V и не с физической LAN).
Создание виртуальных коммутаторов

При создании сетевых виртуальных коммутаторов их параметры и опции зависят от
типа создаваемой вами виртуальной сети. Библиотека управления Hyper-V PowerShell
имеет отдельную функцию для каждого типа создаваемой виртуальной сети, и каждая
функция имеет свои параметры командной строки. Все функции описаны далее в таб-
лицах (с примерами использования параметров командной строки).
В табл. 16.16 перечислены параметры функции New-VMExternalSwitch.
Таблица 16.16. Параметры командной строки функции New-VMExternalSwitch

-virtualswitchname Название нового виртуального -virtualswitchname "External Net"
коммутатора
-ext Строка, которая определяет тот "Broadcom"
физический адаптер сервера,
к которому надо привязаться
-server Имя удаленного сервера -server Server1
-ports Количество портов виртуального -ports 2048
В следующих двух примерах показано, как использовать функцию New-

VMExternalSwitch и параметры командной строки. В первом примере создается внеш-
ний виртуальный коммутатор (количество портов которого равно 2048) с названием
"External Network", привязанный к физическому адаптеру (название которого начина-
ется с "Broadcom") на удаленном сервере Host23:
New-VMExternalSwitch -virtualSwitchNameName "External Network" -ext "Broadcom"
-Server Host23 -ports 2048
Параметр -ext трактуется как строка поиска. Подойдет любой сетевой адаптер, кото-
рый содержит текст "Broadcom", поэтому нет необходимости знать всю строку сетево-
го адаптера.
Следующий пример показывает использование функции Choose-VMExternalEthernet для
того, чтобы представить пользователю список физических сетевых адаптеров сервера и
выдать (через канал) выбранный адаптер в функцию New-VMExternalSwitch:
choose-VMExternalEthernet -Server Host23 | New-VMExternalSwitch
-virtualSwitchNameName "External Network" -ports 2048
В табл. 16.17 перечислены параметры функции New-VMInternalSwitch.
Таблица 16.17. Параметры командной строки функции New-VMInternalSwitch

-virtualswitchname Название нового виртуального -virtualswitchname "Internal Net"
Следующий пример иллюстрирует использование параметров функции New-

VMInternalSwitch:
New-VMInternalSwitch -virtualSwitchNameName "Internal Network" -Server Host23
-ports 2048
В табл. 16.18 перечислены параметры функции New-VMPrivateSwitch.
Таблица 16.18. Параметры командной строки функции New-VMPrivateSwitch

-virtualswitchname Название нового виртуального -virtualswitchname "Private Net"
Следующий пример иллюстрирует использование параметров функции New-

VMPrivateSwitch:
New-VMPrivateSwitch -virtualSwitchNameName "Private Network" -Server Host23

-ports 2048
Удаление виртуальных коммутаторов

Библиотека управления Hyper-V PowerShell версии 1.00b не имеет функции уда-
ления коммутатора, но это несложно сделать при помощи метода DeleteSwitch
класса MSVM_VirtualSwitchManagementService. Вы можете также использовать функцию
Choose-VMSwitch для получения объектной ссылки на тот коммутатор, который хотите
удалить.
Следующий код демонстрирует удаление существующего виртуального коммутатора.
Начинаем с получения объектной ссылки на класс MSVM_VirtualSwitchManagementService,
затем используем функцию Choose-VMSwitch библиотеки для выбора виртуального
коммутатора для удаления и, наконец, применяем метод DeleteSwitch для удаления
выбранного виртуального коммутатора.
$SwitchObj = Get-WMIObject -class "MSVM_VirtualSwitchManagementService" -namespace
$Switch = Choose-VMSwitch
$SwitchObj.DeleteSwitch($Switch)
Управление моментальными снимками

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

управления моментальными снимками. В следующих разделах описано, как использо-
вать эти функции для создания, применения и удаления моментальных снимков.
Создание моментальных снимков

Вы создаете новый моментальный снимок при помощи функции New-VMSnapshot биб-
лиотеки управления Hyper-V PowerShell. В табл. 16.19 перечислены параметры функ-
ции New-VMSnapshot.
Таблица 16.19. Параметры командной строки функции New-VMSnapshot

-note Текстовая строка для заполнения поля примечания моменталь- -note "Test Note"
ного снимка
-wait Ключ для ожидания выполнения функции перед продолжением -wait
Следующий пример иллюстрирует использование параметров командной строки

функции New-VMSnapshot:
New-VMSnapshot $VM -note "Before test begins" -Server Host1 -wait
Эта командная строка создаст моментальный снимок для виртуальной машины (на ко-
торую ссылается объект $VM), находящейся на хосте Host1, присвоит полю примечания
значение "Before test begins" и дождется завершения моментального снимка перед пе-
реходом к следующей строке кода Windows PowerShell.
Переименование моментальных снимков

Функция New-VMSnapshot не имеет возможности дать название моментальному снимку
при его создании. Если вы хотите задать или изменить название моментального сним-
ка, то должны использовать функцию Rename-VMSnapshot. В табл. 16.20 перечислены
параметры функции Rename-VMSnapshot.
Таблица 16.20. Параметры командной строки функции Rename-VMSnapshot

-snapname Название или объектная ссылка на сущест- -snapname "Snapshot14"

вующий моментальный снимок
-newname Текстовая строка, которая будет использована -newname "Snapshot before XYZ
как новое название моментального снимка application install"

функции Rename-VMSnapshot:
Rename-VmSnapshot $VM -snapname (Choose-VMSnapshot $VM).ElementName -newname
"Snapshot before XYZ application install"
Эта командная строка переименует моментальный снимок виртуальной машины, на

которую ссылается объект $VM. Применяется функция Choose-VMSnapshot для вывода
пользователю списка имеющихся моментальных снимков виртуальной машины, полу-
чается Elementname выбранного моментального снимка, передается как название суще-
ствующего моментального снимка и присваивается новое название "Snapshot before
XYZ application install".
По умолчанию названия моментальных снимков формируются по дате и времени соз-
дания снимка. Если вы не знаете названия моментального снимка, то функция Choose-
VMSnapshot значительно облегчит вам процесс получения названия моментального
снимка.
Применение моментальных снимков

Когда у вас есть один или несколько моментальных снимков виртуальной машины, то
вы можете использовать функцию Apply-VMSnapshot для переключения между ними.
В табл. 16.21 перечислены параметры функции Apply-VMSnapshot.
Таблица 16.21. Параметры командной строки функции Apply-VMSnapshot

-snapshot Объектная ссылка на моментальный снимок $Snap
-force Принудительно применяет моментальный снимок (даже если виртуаль- -force
ная машина работает)
-restart Перезапускает виртуальную машину после применения моментального -restart
снимка
-wait Ожидает применения моментального снимка, но не перезапускает его -wait

функции Apply-VMSnapshot:
Choose-VMSnapshot $VM | Apply-VMSnapshot -force -restart
Эта командная строка применяет моментальный снимок к виртуальной машине (на

которую ссылается объект $VM), используя функцию Choose-VMSnapshot для выдачи
пользователю списка имеющихся моментальных снимков виртуальной машины. После
выбора моментального снимка он будет принудительно применен и виртуальная ма-
шина будет перезапущена (по завершении применения моментального снимка).
Удаление моментальных снимков

Когда вы закончите свои эксперименты и моментальные снимки вам будут больше не
нужны, будет неплохо от них избавиться. Библиотека управления Hyper-V PowerShell
предоставляет функцию для быстрого удаления существующих моментальных сним-
ков. Эта функция называется Remove-VMSnapshot, и в табл. 16.22 перечислены ее пара-

метры.
Таблица 16.22. Параметры командной строки функции Remove-VMSnapshot

-snapshot Объектная ссылка на моментальный снимок $Snap
-tree Ключ для активации удаления моментальных снимков в той ветви -tree
дерева моментальных снимков, которая находится ниже удаляемого
снимка

функции Remove-VMSnapshot:
Choose-VMSnapshot $VM | Remove-VMSnapshot -tree
Эта командная строка удалит моментальный снимок виртуальной машины (на которую
ссылается объект $VM) при помощи функции Choose-VMSnapshot для выдачи пользовате-
лю списка текущих моментальных снимков виртуальной машины. Опция -tree инфор-
мирует функцию Remove-VMSnapshot о том, что ей необходимо рекурсивно вызывать
саму себя для удаления всех остальных моментальных снимков, начиная от текущего
листа и вниз по ветви дерева.
При использовании параметра -tree будьте очень осторожны. После выбора момен-
тального снимка в функции Choose-VMSnapshot не будет ни подсказок, ни предупрежде-
ний — так что если вы выберете неверный моментальный снимок и примените пара-
метр -tree, то можете быстро потерять целое дерево моментальных снимков.
Резюме
Эта глава показала вам, как взаимодействовать с API WMI при помощи Windows
PowerShell. Было также разъяснено, как при помощи Windows PowerShell получить
доступ к классам WMI сервера Hyper-V, как запрашивать виртуальные машины ло-
кального и удаленного сервера Hyper-V, как использовать классы для сбора информа-
ции, а также как управлять настройками виртуальных машин (при помощи собствен-
ных классов WMI). Несмотря на то, что умение писать скрипты Windows PowerShell
с нуля очень важно, использование уже имеющихся скриптов и функций поможет
вам сэкономить время. Для демонстрации возможностей библиотеки функций
мы представили вам библиотеку Windows PowerShell, которая была разработана
компанией Microsoft для своих внутренних нужд (ее можно скачать с сайта
http://www.codeplex.com). Используя функции библиотеки, мы описали основы управ-
ления виртуальными машинами, виртуальными сетевыми коммутаторами, виртуаль-
ными жесткими дисками, а также моментальными снимками. Несмотря на то, что эта
библиотека не поддерживается компанией Microsoft, она может быть ценным источни-
ком информации для создания и обслуживания вашей инфраструктуры Hyper-V, а так-
же позволит вам изучить работу классов WMI сервера Hyper-V и сэкономить время.

дополнительную информацию по классам WMI сервера Hyper-V см. в сети
Microsoft Developer Network в статье "Virtualization WMI Provider", в которой под-
робно описываются классы виртуализации WMI; она доступна по ссылке:
http://go.microsoft.com/fwlink/?LinkID=108564;
скачайте последнюю версию библиотеки Hyper-V PowerShell Management Library по
ссылке: http://pshyperv.codeplex.com;
дополнительную информацию по Associators и о том, как делать к ним запросы,
см. в сети Microsoft Developer Network в статье "ASSOCIATORS OF Statement"; она
доступна по ссылке: http://msdn.microsoft.com/en-us/library/aa384793(VS.85).aspx;
блог Джеймса О’Нейла (James O’Neill), посвященный Windows PowerShell, — от-
личный ресурс с дополнительной информацией по библиотеке Hyper-V PowerShell
Management Library. О’Нейл является основным разработчиком этой библиотеки,
его блог находится по адресу: http://blogs.technet.com/jamesone.
часть IV
Методология проекта
Глава 17. Сценарии виртуализации серверов
Глава 18. Инфраструктура виртуальных рабочих столов
Глава 19. Проект виртуализации серверов: фаза представления
Глава 20. Проект виртуализации серверов: фаза обнаружения
Глава 21. Проект виртуализации серверов: фаза оценки
Глава 22. Проект виртуализации серверов: фаза планирования

и проектирования
Глава 23. Проект виртуализации серверов: пилотная фаза

ГЛАВА 17
Сценарии
Проекты виртуализации серверов попадают в один из четырех сценариев: центр обра-
ботки данных, филиал, тестовая лаборатория, разработка программного обеспечения.
Каждый из этих сценариев имеет свои особенности, которые оказывают влияние на
проектирование, управление и эксплуатацию соответствующей инфраструктуры.
В этой главе дано описание всех сценариев и обсуждается все то, что вы должны учи-
тывать при запуске проекта, соответствующего одному из этих сценариев.
Сценарий центра обработки данных

Проекты виртуализации центра обработки данных обычно зарождаются в центре обра-
ботки данных, которому не хватает ресурсов и который поэтому начинает отставать от
потребностей бизнеса. Экономические тенденции заставляют компании делать больше
меньшими ресурсами (снижая капитальные, управленческие и эксплуатационные рас-
ходы).
Соображения по проектированию хостов

Конструкция хостов центра обработки данных обычно подчинена максимизации коли-
чества виртуальных машин на один сервер (для достижения наилучших показателей
консолидации при наименьшей стоимости). Обычно серверы центров обработки дан-
ных имеют больше процессоров, ядер, памяти, сетевых подключений, а также больший
объем систем хранения, чем используемые в других сценариях серверы. Поскольку
серверы виртуализации центров обработки данных обычно обслуживают большое ко-
личество виртуальных машин, то для обеспечения их высокой готовности рекоменду-
ется использовать отказоустойчивые кластера серверов Hyper-V.
Решение использовать стоечный или плоский (blade) сервер зависит от требований к
емкости вашего сервера Hyper-V, конструкции плоского сервера и его шкафа. Монти-
руемые в стойку серверы могут в принципе дать больше возможностей для расширения
и большую емкость, чем плоские серверы, но они требуют больше места и больше
электроэнергии. Плоские серверы обычно имеют общую заднюю панель, которая име-
620 Часть IV. Методология проекта виртуализации серверов
ет некоторое ограниченное количество слотов расширения, совместно используемых

всем шкафом серверов, что лимитирует максимальную пропускную способность шка-
фа серверов.
Сетевые соображения
В сценарии центра обработки данных пропускная способность и отказоустойчивость
сети являются ключевыми для обеспечения высокой готовности сервера Hyper-V и
виртуальных машин. Как уже обсуждалось в главе 7, каждый сервер должен иметь как
минимум два сетевых адаптера: один резервируется для обмена родительского раздела,
а другой — для обмена виртуальных машин. В сценарии центра обработки данных вы
будете консолидировать большое количество виртуальных машин на одном сервере,
поэтому один сетевой адаптер не даст достаточной производительности. Поэтому вам
понадобятся дополнительные сетевые адаптеры (для того, чтобы справиться с требова-
ниями виртуальных машин по сетевому обмену). Их количество будет зависеть от не-
обходимой суммарной пропускной способности сети.
Кроме тех сетевых адаптеров, которые используются для обмена сервера и виртуаль-
ных машин, в сценарии центра обработки данных вам, возможно, также понадобится
сетевая пропускная способность для:
iSCSI;
кластерного обмена;
сетей резервного копирования.
Если вы используете систему хранения на базе iSCSI, то вам придется выделить как
минимум один гигабитный адаптер для трафика iSCSI. Если же вы хотите гарантиро-
вать отказоустойчивость (посредством обеспечения нескольких путей к серверу iSCSI),
то вам понадобятся два гигабитных адаптера для трафика iSCSI. Для достижения наи-
лучшей производительности обмена с сервером iSCSI вам следует обдумать возмож-
ность использования таких сетевых адаптеров, которые на аппаратном уровне поддер-
живают разгрузку обмена по протоколу iSCSI.
Предоставляющие разгрузку iSCSI сетевые адаптеры используют программные драйверы
изготовителя, которые понимают, что выполняется аппаратная разгрузка обмена iSCSI.
Разгрузка iSCSI работает для тех подключений, которые установлены из родительского
раздела (но не из дочерних разделов). Дочерние разделы не могут использовать такие
драйверы сетевых адаптеров, которые используют разгрузку iSCSI.
В отказоустойчивом кластере Windows Server 2008 через адаптер может идти кластер-
ный обмен и осуществляться доступ клиентов. Для обеспечения высокой готовности
кластера каждый узел должен иметь два сетевых адаптера (которые кластерный обмен
будет использовать как первичный и вторичный пути обмена). Сетевой кластерный
трафик имеет небольшой объем и не влияет сколько-нибудь заметно на обмен по сети.
Допустимо для кластерного обмена использовать сетевой адаптер управления, но не
рекомендуется для кластерного трафика использовать адаптеры iSCSI или виртуальных
сетей.
Глава 17. Сценарии виртуализации серверов 621
При использовании кластеризации хостов в среде центра обработки данных вы будете

делать миграцию виртуальных машин между серверами как в плановом режиме, так и
в неплановых обстоятельствах. Вне зависимости от плановости ситуации вам нужно,
чтобы виртуальная машина при миграции на другой сервер сохраняла подключение к
сети. Из-за большого количества виртуальных машин на сервере Hyper-V, вам, скорее
всего, потребуется несколько виртуальных сетей (для обслуживания потребностей по
сетевому вводу/выводу). Когда вы переносите виртуальную машину между серверами
Hyper-V, то отказоустойчивый кластер будет сначала пытаться подключить виртуаль-
ную машину к виртуальной сети с тем же самым GUID, а затем попробует подключить
ее к виртуальной сети с тем же самым названием. Если не удается найти ни GUID, ни
название виртуальной сети, то виртуальная машина переводится в состояние "Not
Connected", и вы должны будете присвоить виртуальной машине одну из доступных
сетей. Если вы последуете лучшим практикам и стандартизируете названия виртуаль-
ных сетей, то при миграции с одного сервера Hyper-V на другой сеть сможет присво-
иться автоматически, и виртуальная машина будет иметь подключение к сети.
В сценарии центра обработки данных миграция виртуальных машин с одного сервера
Hyper-V на другой может привести к перегрузке виртуальной сети. Несмотря на то, что
вы можете вручную сбалансировать нагрузку между несколькими подключенными к
одной и той же подсети виртуальными сетями, будет лучше, если это автоматически
сделает сама система.
Одним из решений этой проблемы является совместная работа сетевых адаптеров в
команде. Командная работа сетевых адаптеров позволяет использовать разные режимы
работы:
балансировка нагрузки — несколько физических адаптеров работают как один сете-
вой адаптер (для балансировки нагрузки сетевого трафика);
отказоустойчивость — несколько физических сетевых адаптеров в конфигурации
"активный — пассивный". Активный узел посылает и принимает трафик, а пассив-
ный узел ожидает (в готовности принять нагрузку при сбое активного адаптера);
агрегирование — несколько физических сетевых адаптеров в конфигурации сумми-
рования полосы пропускания. Когда первый адаптер перегружается, то сетевой тра-
фик начинает передавать следующий сетевой адаптер.
Для того чтобы обеспечить минимальное влияние (на существующий трафик) мигра-
ции виртуальной машины с одного хоста на другой (с обеспечением в то же время ав-
томатической балансировки трафика), можно использовать режим командной работы
"балансировка нагрузки". Это позволяет серверу Hyper-V рассматривать несколько фи-
зических адаптеров как один логический адаптер. Если на сервере Hyper-V есть только
один сетевой адаптер для использования виртуальными машинами, то потребуется
только одна виртуальная сеть. Это минимизирует издержки на управление виртуаль-
ными сетевыми подключениями.
Компания Microsoft не поддерживает работу в командном режиме — за это отвечает произ-
водитель сетевого адаптера. Если вы обратитесь в компанию Microsoft за поддержкой по
поводу сервера, который работает в командном режиме, то Microsoft для поиска неисправ-
ности может потребовать расформировать команду адаптеров и удалить программное
обеспечение командной работы.
Использование режима командной работы "балансировка нагрузки" имеет один недос-

таток — весь трафик собирается в одной сети. Комбинация виртуальных локальных
сетей (VLAN) и "балансировки нагрузки" позволит вам разделить трафик между раз-
ными виртуальными подсетями (с использованием одного и того же физического сете-
вого подключения).
Соображения по высокой готовности

В сценарии центра обработки данных вы обычно сосредоточены на максимизации ко-
эффициента консолидации серверов Hyper-V, чтобы минимизировать требуемое коли-
чество серверов и капитальные расходы. Это приводит к тому, что на серверах Hyper-V
работает много виртуальных машин одновременно. Если сервер отказывает, то отказы-
вают также и все его виртуальные машины, что приводит к масштабному перебою в
работе. Будет весьма благоразумно убедиться в том, что программное и аппаратное
обеспечение сервера гарантируют максимально возможную безотказность.
Несмотря на то, что вы можете спроектировать свои серверы на максимальную безот-
казность (при помощи резервирования компонентов), отказы все-таки случаются. От-
казоустойчивая кластеризация Microsoft’s Failover Clustering позволяет вам спроекти-
ровать такое решение, которое обеспечит как плановую, так и внеплановую отказо-
устойчивость. Компания Microsoft называет это кластером Hyper-V на уровне сервера
(это называется также кластером хостов Hyper-V). При плановом отказе работающие
на одном узле кластера виртуальные машины могут мигрировать на другой узел. Вы
можете сделать это для выполнения какого-то обслуживания узла кластера или для ба-
лансировки рабочей нагрузки. При неплановом сбое (если сбой узла кластера происхо-
дит внезапно) кластерные ресурсы виртуальных машин мигрируют на другой узел кла-
стера и виртуальные машины перезапускаются из выключенного состояния.
Отказоустойчивая кластеризация Windows Server 2008 Failover Clustering позволяет вам
создать кластер Hyper-V из 16 узлов. На каждом узле могут активно работать вирту-
альные машины. При проектировании многоузлового кластера для центра обработки
данных вы должны принять решение относительно размещения виртуальных машин в
случае сбоя узла. Виртуальные машины со сбойного узла могут размещаться по всем
оставшимся узлам (для распределения нагрузки), либо вы можете выделить для этой
цели один узел кластера и мигрировать все виртуальные машины на этот узел.
Hyper-V также поддерживает кластеры виртуальных машин для осведомленных о кла-
стеризации приложений. Для этого все узлы кластера виртуальных машин должны на-
ходиться на разных кластерах хостов. При проектировании кластера хостов для под-
держки кластера виртуальных машин наилучшим вариантом для перехода в случае
сбоя является выделенный узел кластера (чтобы гарантировать, что сбой узла не при-
ведет к тому, что несколько узлов кластера виртуальных машин попадет на один узел
кластера серверов Hyper-V).
Соображения по системам хранения

В сценарии центра обработки данных серверы находятся в непосредственной близости
друг от друга. Это позволяет для оптимального использования жестких дисков и дос-
тижения высокой производительности использовать технологии Storage Area Network
(SAN) или Internet SCSI (iSCSI). SAN позволяет распределять операции дискового вво-
да/вывода на большое количество дисков. При сочетании SAN и массивов дисков
RAID можно минимизировать перебои в работе по причине выхода из строя дисков.
Чаще всего вместе с SAN используются уровни RAID 5 и RAID 10. RAID 5 использует
минимум три диска и чередует данные по всем дискам. RAID 5 защищает от потери
одного диска (при помощи сохранения битов четности, которые позволяют реконст-
руировать потерянные данные). Для RAID 10 требуется минимум четыре диска; он со-
четает чередование и зеркалирование дисков, что позволяет пережить потерю одного
комплекта чередования или зеркалирования без потери данных. Другие технологии,
используемые в центрах обработки данных (такие, как кластеризация хостов), требуют
применения совместно используемых систем хранения (чтобы виртуальные машины
могли быстро мигрировать с одного сервера Hyper-V на другой без необходимости ко-
пировать виртуальные машины по сети).
Конфигурация iSCSI для кластеров
Такие системы SAN, как Compellent Storage Center, дают возможность выбрать тот транс-
порт, который наилучшим образом соответствует вашим потребностям в хранении данных.
Обычно в качестве транспорта поддерживаются как iSCSI, так и Fiber Channel, и оба они
есть одновременно на одном и том же контроллере системы хранения.
Несмотря на то, что в качестве интерфейса между серверами и системами хранения можно
использовать адаптеры iSCSI Host-Bus Adapters (HBAs), инициатор Microsoft’s iSCSI
Software Initiator является вполне подходящей альтернативой для подключения по iSCSI,
причем он может использовать стандартные гигабитные порты Ethernet (которые есть в на-
стоящее время на большинстве серверов). Для кластеров iSCSI Software Initiator требуется
использовать Software Initiator версии 2.0 или более новую.
На отказоустойчивом кластере Windows Server 2008 Failover Cluster вы должны правильно
сконфигурировать постоянные привязки и монтирование томов в Software Initiator, чтобы
обеспечить привязку томов инициатором iSCSI Software Initiator до запуска службы Cluster
Service. Если вы этого не сделаете, то служба Cluster Service не сможет стартовать, по-
скольку тома являются необходимыми ресурсами кластера.
Джастин Браун (Justin Braun, Senior Microsoft Product Specialist (Compellent Technologies))
В настоящее время производители SAN поставляют многоуровневые системы хране-

ния и обеспечивают автоматические правила миграции между уровнями. Обычно име-
ются три уровня: уровень Level 1 содержит самые быстрые диски SCSI (со скоростью
вращения 15 000 оборотов в минуту), уровень Level 2 может содержать более медлен-
ные диски SCSI (со скоростью вращения 10 000 оборотов в минуту), а уровень Level 3
может содержать диски SATA, которые работают еще медленнее (со скоростью вра-
щения 7200 оборотов в минуту). Хранение на первом уровне обеспечивает наилучшую
скорость операций ввода/вывода и должно использоваться для кластеризации серверов
Hyper-V. Второй уровень обеспечивает обычные повседневные операции хранения
виртуальных машин, а третий уровень — хранение тех данных, обращение к которым
происходит нечасто (например, хранящиеся в библиотеке SCVMM виртуальные ма-
шины).
Соображения по резервному копированию

Резервные копии серверов Hyper-V можно делать при помощи агентов, инсталлиро-
ванных на сервере или виртуальных машинах (а также инсталлированных и на сервере,
и на виртуальных машинах). Windows Server 2008 предоставляет службу теневого ко-

пирования Volume Shadow Copy Service (VSS) для выполнения быстрых моментальных
снимков томов (для целей резервного копирования). VSS минимизирует простои сер-
вера при резервном копировании и предоставляет приложениям интерфейс для созда-
ния подключаемых модулей, которые могут правильно информировать приложение
о необходимости сбросить все изменения из буферов и создать очередь для любых до-
полнительных операций записи (на время выполнения моментального снимка). Когда
снимок закончен, дополнительный модуль информируется о том, что можно продол-
жить запись изменений. Резервные копии обычно сначала хранятся на диске, а потом
мигрируют на ленты (для хранения в безопасном месте за пределами производствен-
ной площадки).
Резервные копии в сценарии центра обработки данных обычно выполняются по сети из
некоего центра резервного копирования. Для того чтобы этот процесс оказывал мини-
мальное влияние на производственные нагрузки, следует отделить сетевой трафик ре-
зервного копирования от производственного бизнес-трафика при помощи отдельной
сети или виртуальной LAN (VLAN). Для такого разделения на сервере Hyper-V обычно
требуется дополнительный сетевой адаптер.
Если обращаться с виртуальной машиной как с физической, то приходится разверты-
вать агента резервного копирования в виртуальной машине. Это позволяет сохранять
приложения, файлы, а также состояние операционной системы и восстанавливать их
как на физическом сервере. При этом конфигурация виртуальной машины не сохраня-
ется, так что если вам нужно восстановить виртуальную машину на другом хосте, то
вам придется создать новую виртуальную машину и сделать восстановление при по-
мощи программного обеспечения резервного копирования. Это означает, что вы долж-
ны сохранять конфигурационную информацию виртуальной машины отдельно от ре-
зервной копии виртуальной машины. Преимущество такого подхода состоит в воз-
можности делать восстановление отдельных файлов, каталогов, дисков, приложений
или всей машины целиком.
Для сохранения конфигурации виртуальной машины и одновременного резервного
копирования виртуальной машины вы должны:
использовать такое приложение резервного копирования, которое поддерживает
модуль записи VSS Writer для Hyper-V;
инсталлировать агент резервного копирования на сервер Hyper-V;
сделать резервные копии всех томов, которые содержат компоненты виртуальной
машины (конфигурационный файл, моментальные снимки и виртуальные жесткие
диски).
Недостаток такого подхода в том, что для восстановления нужного файла необходимо
восстановить виртуальную машину и смонтировать виртуальный жесткий диск.
Приложение Windows Server Backup, которое входит в состав Windows Server 2008, может
создавать резервные копии: конфигурации Hyper-V, конфигурации виртуальной машины, а
также файлов виртуальной машины.
Соображения по схеме управления

В состоянии поставки управление сервером Hyper-V производится при помощи ме-
неджера Hyper-V Manager для консоли Microsoft Management Console (MMC), который
входит в состав Hyper-V. Консоль ММС может управлять одновременно только одним
сервером Hyper-V. В сценарии центра обработки данных у вас, скорее всего, будет
много серверов Hyper-V, поэтому использовать Hyper-V Manager нереально. Для
управления целым пулом серверов Hyper-V из одной консоли существует другое реше-
ние компании Microsoft — это менеджер System Center Virtual Machine Manager
(SCVMM) 2008. В следующих разделах обсуждается развертывание SCVMM в центре
обработки данных.
Развертывание
SCVMM поддерживает не меньше 400 серверов и 8000 виртуальных машин в одной
консоли управления. В большинстве организаций одна консоль сможет управлять всей
виртуализированной инфраструктурой центра обработки данных. Если имеется больше
одного центра обработки данных, то консоль управления должна находиться в том
центре обработки данных, где больше всего серверов, чтобы минимизировать трафик
по глобальной сети WAN.
Несмотря на то, что SCVMM поставляется вместе с SQL Server 2005 Express Edition,
в центрах обработки данных следует использовать версию SQL Server 2005 x64 Standard
или Enterprise. Это устраняет пределы масштабирования, имеющиеся у сервера SQL
Server 2005 Express Edition. Все данные и сохраненные состояния хранятся в базе дан-
ных SCVMM 2008. Для того чтобы обеспечить легкое восстановление инсталляции
SCVMM в центре обработки данных, сервер SQL не следует инсталлировать на тот же
самый компьютер, что и консоль SCVMM Administration Console. Если оборудование
консоли Administration Console даст сбой, то для ее восстановления нужно будет ин-
сталлировать новую консоль SCVMM Administration Console, указав ей (при инсталля-
ции) уже существующую базу данных SQL.
SCVMM будет центром управления и обеспечения для вашей (основанной на Hyper-V)
среды центра обработки данных. Для обеспечения высокой готовности данных базу
данных SCVMM следует разместить на кластере серверов SQL и делать ее резервное
копирование каждую ночь.
Библиотека
Схема размещения совместно используемых ресурсов библиотек может влиять на вре-
мя развертывания новых виртуальных машин. По умолчанию при инсталляции
SCVMM создается локальный совместно используемый ресурс библиотеки. Если это
единственный совместно используемый ресурс библиотеки, то все виртуальные маши-
ны будут развертываться на свои серверы из этой библиотеки при помощи службы
Background Intelligent Transfer Service (BITS). Такая поставка виртуальных машин
в центре обработки данных приведет к увеличению трафика на производственной сети
и увеличит время копирования шаблона на целевой сервер.
Для ускорения поставки виртуальной машины из библиотеки и для уменьшения воз-

действия на производственную сеть у вас есть два варианта:
использовать для трафика поставки отдельную сеть;
развернуть ресурсы библиотек на серверах Hyper-V центра обработки данных.
Развертывание отдельной сети изолирует трафик поставки, но требует дополнительно-
го сетевого адаптера, а также усложняет конфигурацию сети. Развертывание дополни-
тельных ресурсов библиотек требует репликации данных библиотеки на все серверы
Hyper-V и большое количество дискового пространства (для хранения реплик файлов
библиотеки). Если содержимое библиотеки изменяется не сильно, то развертывание
дополнительных ресурсов библиотек на всех серверах Hyper-V может существенно
снизить время поставки. Если же библиотека меняется регулярно, но из нее поставля-
ется мало виртуальных машин, то выделенная сеть будет лучшим вариантом решения.
Если в центре обработки данных используется много ресурсов библиотек, то для обес-
печения использования самой последней версии библиотеки необходимо выполнять
репликацию библиотек. В центре обработки данных в качестве первичного источника
следует использовать один библиотечный ресурс. Это должен быть ресурс библиотеки
на сервере SCVMM. Репликацию можно делать разными способами:
простым копированием файлов;
зеркалированием каталогов;
при помощи DFS-R;
при помощи специального программного обеспечения для репликации.
Независимо от используемого варианта очень важно обеспечить своевременное вы-
полнение репликации, чтобы ресурсы библиотек были одинаковыми.
Делегированное администрирование
SCVMM имеет два уровня администраторов — полный администратор и делегирован-
ный администратор. Полный администратор имеет неограниченный контроль над все-
ми серверами, виртуальными машинами и библиотеками среды SCVMM. Делегиро-
ванный администратор может быть ограничен определенным набором серверов, со-
стоящих в некоей группе хостов, или конкретными серверами библиотек. В пределах
этой группы и этих серверов библиотек делегированный администратор имеет полный
контроль над всеми виртуальными машинами и объектами библиотек. Делегирован-
ный администратор имеет также доступ к консоли SCVMM, но этот доступ будет огра-
ничен той группой хостов, серверами и серверами библиотек, права на администриро-
вание которых у него имеются.
В центре обработки данных использование делегированных администраторов опреде-
ляется структурой подразделения информационных технологий и требованиями по ад-
министрированию. Если подразделение ИТ использует централизованный подход к
управлению серверами и все администраторы работают со всеми серверами, то модель
делегирования не нужна. В распределенных подразделениях ИТ модель делегирования
может быть очень полезной как для разделения ролей управления, так и для самого
управления определенными серверами, виртуальными машинами и библиотеками.
Если делегированному администратору нужно управлять одним сервером Hyper-V, то

вы должны создать группу хостов и поместить в нее этот конкретный сервер. Вы
должны также создать новую пользовательскую роль, которой предоставлено право
делегированного администрирования, а затем присвоить делегированному админист-
ратору эту роль.
Портал Self-Service Web Portal

Портал Self-Service Web Portal предоставляет пользователям Web-доступ для управле-
ния виртуальными машинами или их создания на серверах Hyper-V. Портал может
управляться политикой (для ограничения возможностей пользователей управлять вир-
туальными машинами или создавать их через портал), но это не ограничивает возмож-
ность пользователя напрямую подключиться к службе удаленного рабочего стола, если
она включена в виртуальной машине. Политика применяется к группе хостов и дейст-
вует на все серверы Hyper-V, помещенные в эту группу. Сервер Hyper-V не может быть
одновременно членом более чем одной группы хостов, поэтому серверы, помещенные
в ту группу хостов, к которой применяется политика, должны использоваться только
порталом Self-Service Portal. Кроме того, Web-портал не должен инсталлироваться на
тех серверах Hyper-V, которыми вы хотите управлять. Он может инсталлироваться на
сервере SCVMM или на отдельном компьютере, выделенном под Self-Service Portal.
В среде производственного центра обработки данных портал Self-Service Portal исполь-
зуется в основном для предоставления пользователям возможности удаленно управ-
лять существующими виртуальными машинами (при помощи Web-интерфейса), не
предоставляя им для этого прав делегированного администратора консоли SCVMM
Administration Console. Для этого нужно создать одну или несколько пользовательских
ролей, ограничивающих те действия, которые их обладатели могут выполнять. Пользо-
вательские роли можно создать для персонала службы поддержки, для администрато-
ров приложений, для администраторов производственных площадок, а также для лю-
бых других типов администраторов (которым нужен доступ к администрированию
только виртуальной машины, а не того хоста, на котором она работает).
Пользовательская роль не может редактировать настройки конфигурации виртуальной
машины, но при наличии разрешения пользователь может создавать новые виртуаль-
ные машины и сохранять их в библиотеке, а также: останавливать, запускать, приоста-
навливать, завершать работу виртуальных машин; создавать контрольные точки и уда-
ленно управлять виртуальными машинами. Эти ограничения налагаются на пользова-
тельскую роль для того, чтобы ее обладатели не увеличивали нагрузку на ресурсы
сервера Hyper-V без предварительного согласования.
В среде центра обработки данных сервер Hyper-V развертывается на множестве серве-
ров одной площадки, при этом достигается высокая плотность виртуальных машин на
один сервер. Это означает, что потеря одного сервера может иметь серьезные послед-
ствия. Несмотря на то, что кластер хостов справится с отказом одного сервера, в идеале
(если бы вы узнали о проблеме до того, как она произошла) вы могли бы сделать упре-
ждающий перенос виртуальных машин для снижения времени простоя.
Менеджер System Center Operations Manager 2007 может вести упреждающее наблюде-
ние за вашими серверами Hyper-V и работающими на них виртуальными машинами.
Для обычного наблюдения необходимо загрузить пакеты управления для Hyper-V, опе-
рационных систем Windows и работающих у вас приложений. Это позволит вам обес-
печить наблюдение, отчетность, а также выдачу сигналов тревоги для операционных
систем и приложений, работающих на серверах Hyper-V и виртуальных машинах. Па-
кеты управления обеспечивают получение подробностей по производительности, вво-
ду/выводу, использованию памяти и процессоров и т. д. Используя эти функциональ-
ные возможности, встроенные правила будут выдавать вам сигналы тревоги по сбоям,
перегрузкам и проблемам производительности. Вы можете даже создавать собствен-
ные правила для наблюдения за конкретными ситуациями.
При помощи интеграции System Center Operations Manager 2007 и SCVMM 2008 вы
можете получить доступ к расширенной функции Performance Resource Optimization
Tips (PROTips). Вы можете настроить PROTips либо вручную, либо при помощи пре-
допределенного пакета правил и действий. PROTips наблюдает за серверами Hyper-V и
виртуальными машинами (отслеживая определенные тенденции использования ресур-
сов и производительности) и выдает сигналы тревоги вместе с рекомендованными дей-
ствиями. Вы можете сконфигурировать PROTips таким образом, чтобы эти действия
выполнялись автоматически.
Например, PROTips обеспечивает автоматическое наблюдение за виртуальными ма-
шинами (отслеживается возникновение проблем производительности). Если обнару-
живается проблема с производительностью, то PROTips может выдать рекомендацию
мигрировать виртуальную машину на другой сервер (имеющий избыток мощности).
Вы можете сконфигурировать PROTips так, чтобы она либо выдавала сигнал тревоги
с рекомендацией мигрировать, либо сама автоматически мигрировала (имеющие про-
блемы с производительностью) виртуальные машины на новый сервер, который имеет
мощность, позволяющую справиться с данной нагрузкой.
В таком центре обработки данных, который имеет несколько крупных серверов в непо-
средственной близости друг от друга, при комбинировании менеджера System Center
Operations Manager 2007 (для наблюдения за серверами и виртуальными машинами) и
менеджера SCVMM 2008 для управления ими, вы можете использовать PROTips для
наблюдения за производительностью и использованием ресурсов, а также для автома-
тизации миграции виртуальных машин между серверами с минимальным простоем.
Сценарий филиала
Филиал можно определить как удаленную площадку, доступную через глобальную
сеть (WAN), которая имеет ограниченные локальные ресурсы и обычно не имеет сво-
его персонала администрирования. Локально, как правило, предоставляются только
самые важные службы; производственные приложения предоставляются из центра об-
работки данных.
При проектировании решения виртуализации филиала нужно минимизировать стои-
мость этого решения, обеспечить простоту управления им и наблюдения за ним, мини-
мизировать его влияние на WAN, а также обеспечить способ управления системой
в случае выхода из строя глобальной сети (WAN).
Соображения по проектированию хостов

В большинстве филиалов на единственном сервере Hyper-V работают не более пяти
виртуальных машин. Такая конфигурация снижает потребности центра обработки дан-
ных в объеме систем хранения, в количестве процессоров, памяти и сетевых подклю-
чений. Кроме того, сервер Hyper-V в филиале не будет выполнять миграцию виртуаль-
ных машин между серверами, поэтому отказоустойчивый кластер хостов не требуется,
хотя некоторые клиенты могут реализовать такой уровень защиты для важных фи-
лиалов.
Даже при таких ограниченных требованиях не рекомендуется забывать о готовности и
производительности. Это уменьшит потребность в технической поддержке на самой
площадке. Обеспечение высокой готовности позволит также снизить простои сервера
Hyper-V и работающих (в дочерних разделах) виртуальных машин.
Сервер Hyper-V для филиала, который будет поддерживать пять виртуальных машин,
должен иметь как минимум один четырехъядерный процессор с 8 Гбайт оперативной
памяти и собственным жестким диском. Он должен также иметь как минимум две се-
тевые карты (одну для трафика управления сервером Hyper-V, а другую — для трафика
виртуальных машин). Жесткие диски должны быть сконфигурированы в RAID. Необ-
ходимо использовать как минимум RAID 1 для раздела операционной системы и
RAID 1 для хранения виртуальных машин (чтобы защититься от сбоя диска). Для по-
вышения производительности при хранении виртуальных машин следует использовать
RAID 5 или RAID 10. Несмотря на то, что RAID 0 (чередование) может обеспечить от-
личную производительность, потеря одного диска из такого массива приведет к потере
данных массива.
Соображения по управлению
Управление сервером Hyper-V в филиале не отличается от управления в центре обра-
ботки данных — лучше всего использовать SCVMM 2008 с центральной площадки.
Однако в таком варианте может стать проблемой WAN, поскольку потеря подключе-
ния к глобальной сети не позволит вам управлять сервером Hyper-V с центральной
консоли SCVMM 2008. Другой вариант — использовать (при отсутствии подключения
к WAN) для управления сервером Hyper-V и запуска виртуальных машин локальную
консоль менеджера Hyper-V Manager для ММС.
Подготовка новых машин в филиале может быть весьма длительной (если вы попытае-
тесь делать это через WAN). Для повышения эффективности этого процесса вы можете
развернуть совместно используемый ресурс библиотеки на сервере Hyper-V в филиале.
Это позволит консоли SCVMM 2008 поставлять виртуальные машины из локального
ресурса библиотеки и избавиться от необходимости копирования файлов виртуальных
машин через WAN. Если подключение к WAN оборвется, то новую виртуальную ма-
шину все равно можно будет подготовить из локальной библиотеки при помощи кон-
соли Hyper-V Manager, хотя может потребоваться некоторая дополнительная работа по
копированию машины и обработке ее утилитой Sysprep. Для снижения требований
к дисковому пространству и времени репликации в локальном ресурсе библиотеки фи-
лиала следует разместить только шаблоны виртуальных машин и соответствующие
файлы ресурсов.
Соображения по резервному копированию

В филиале, где нет местной технической поддержки или администратора, резервное
копирование обычно выполняется с центральной площадки. Используя такое про-
граммное обеспечение, как System Center Data Protection Manager (SCDPM) 2007
Service Pack 1, вы можете делать резервное копирование сервера Hyper-V и виртуаль-
ных машин при помощи одного агента, инсталлированного в родительском разделе.
Резервные копии по умолчанию сохраняются через WAN на центральной площадке.
SCDPM использует инкрементальную репликацию, чтобы пересылать только те байты,
которые изменились с момента выполнения последней резервной копии, что снижает
объем сетевого трафика от филиала к центральному серверу резервного копирования.
Альтернативой для такого резервного копирования на центральный сервер является
резервное копирование в филиале на локальную систему хранения. Преимущество это-
го метода в том, что время восстановления существенно короче; кроме того, создание
резервных копий и восстановление с них не оказывает влияния на трафик в сети WAN.
Кроме того, можно делать резервное копирование и восстановление даже в том случае,
когда подключение к WAN не работает.
У вас есть два варианта локального резервного копирования: Windows Server Backup
или SCDPM SP1. Приложение Windows Server Backup входит в состав Windows Server
2008, его нужно просто сконфигурировать для использования модуля записи VSS для
Hyper-V; в этом случае вы настраиваете копирование на локальный диск. SCDPM 2007
SP1 можно использовать путем инсталляции DPM и Hyper-V в родительском разделе
филиала. При использовании любого из этих методов резервного копирования в фи-
лиале потребуется дополнительный объем хранения (для хранения резервных копий).
Это дисковое пространство должно представлять собой отдельные диски (не те, на ко-
торых хранятся виртуальные машины Hyper-V), причем они должны находиться на
отдельном RAID-контроллере для повышения производительности.
Филиалы не имеют такого же уровня административной и технической поддержки, как
центры обработки данных. Учитывая, что в филиале нет местного персонала админи-
страторов и технической поддержки, важно спроектировать сервер Hyper-V в филиале
таким образом, чтобы обслуживать его и работать с ним в максимальной степени уда-
ленно.
Для того чтобы обеспечить удаленное обслуживание в такой ситуации, когда сбой обо-
рудования не позволяет серверу загрузиться, установите на сервере Hyper-V карту уда-
ленного доступа или модуль удаленного управления. Это позволит произвести удален-
ный поиск неисправностей, но для этого требуется наличие сетевого подключения, по-
этому нужно запланировать некий альтернативный способ подключения при
неработающей WAN — например, настроить карту удаленного доступа таким образом,
чтобы она использовала другое подключение (коммутируемое или DSL).
Сервер Hyper-V не требует, чтобы его администратор был также и локальным админи-
стратором сервера. По умолчанию только локальный администратор имеет админист-
ративный доступ к Hyper-V для управления конфигурацией и локальными виртуаль-
ными машинами. Для того чтобы неадминистраторы могли управлять сервером Hyper-V,
в хранилище авторизации необходимо добавить дополнительные учетные записи.
Если на сервере Hyper-V происходит сбой сетевого адаптера управления и к нему нель-
зя получить удаленный доступ, то вам понадобится кто-то с соответствующими права-
ми за локальной консолью сервера, чтобы сохранить состояние или выключить вирту-
альные машины, чтобы вы могли заняться поиском причин возникшей проблемы. Вы
можете предварительно настроить для таких случаев административную учетную
запись для использования только в аварийных ситуациях. Такая аварийная админист-
ративная учетная запись должна иметь права на запуск консоли Hyper-V Manager и
управление состоянием виртуальных машин, поставку новых виртуальных машин и
удаление виртуальных машин, но она не должна иметь прав на управление операцион-
ной системой сервера Hyper-V или виртуальных машин. Когда авария устранена, вы
можете изменить пароль этой аварийной учетной записи.
Сценарий тестовой лаборатории

В тестовой лаборатории исследуют функциональность, производительность и жизне-
способность некоего решения, которое (по соображениям безопасности или защиты от
сбоев) изолируется от производственной среды. Каждый тест должен рассматриваться
как единое решение для всех используемых для него виртуальных машин, а не только
для той машины, на которой выполняется сам тест. Это позволяет вам рассматривать
любые последствия, возникающие от перемен в среде; при этом также минимизируется
влияние любых выполняющихся во время теста действий. Тесты могут быть коротки-
ми или длиться до нескольких месяцев.
При проектировании тестовой лаборатории необходимо обеспечить: простоту пере-
конфигурирования хостов Hyper-V и самой среды, а также поддержку ими быстрой
подготовки и хранения тестовых решений; наличие удаленного доступа к тестовым
машинам; возможность изоляции тестовой среды не только от производственной сре-
ды, но и от других работающих тестовых решений.
Если в вашей производственной среде используется Hyper-V, то ваша тестовая лабора-
тория должна иметь копии вашего производственного оборудования для проведения
функционального тестирования и тестирования производительности (и в том числе
кластерных конфигураций, если они используются в производстве).
В тестовой лаборатории понадобится как минимум один сервер Hyper-V и SCVMM
2008 для управления средой, обеспечения поставки виртуальных машин, а также для
хранения виртуальных машин в библиотеке.
Соображения по проектированию сервера

Тестовое решение — это все виртуальные машины и ресурсы, которые требуются для
выполнения и завершения одного тестового случая. В зависимости от выполняемых
тестов, тестовое решение может использовать целый набор стандартных служб (Active
Directory, DHCP, DNS, сетевые экраны и т. д.), либо тестовому решению могут потре-
боваться эти службы в виде части целого набора виртуальных машин тестового реше-
ния. Иначе говоря, количество требуемых для одного теста виртуальных машин может
отличаться, поэтому тестовой лаборатории нужен целый пул серверов Hyper-V для
обеспечения сборки тестовых решений.
Тест должен поставляться и храниться как комбинированное решение. Несмотря на то,
что было бы очень хорошо, если бы любой тест можно было реализовать на одном
сервере Hyper-V, фактический размер тестового решения может превысить емкость
одного сервера Hyper-V. В зависимости от типа теста (функциональный или произво-
дительности) может быть не очень хорошей идеей реализовать весь тест на одном сер-
вере — поскольку ограниченная производительность сервера может повлиять на ре-
зультаты тестирования.
При проектировании тестовой лаборатории лучше всего проектировать сервер Hyper-V
под тестовое решение среднего размера (если это допустимо по стоимости). Это позво-
ляет и процесс подготовки, и весь сетевой обмен изолировать на одном сервере Hyper-V,
что позволяет вам масштабировать количество серверов Hyper-V в пуле тестовой лабо-
ратории в соответствии с количеством тестовых решений, которые должны работать
одновременно. Для проектирования сервера Hyper-V под типичное тестовое решение
нужно определить: типичное тестовое решение, требуемое количество виртуальных
машин, а также размер этих виртуальных машин (память, процессоры, дисковое про-
странство, сетевые подключения), а затем просуммировать эти требования к ресурсам,
чтобы определить минимальные требования к хосту.
Соображения по системе хранения

Тестирование проверяет, что предлагаемое решение работает так, как задумано и с
проектной производительностью. Функциональное тестирование требует значительно-
го количества дискового пространства для подготовки и работы функциональных тес-
тов на серверах Hyper-V. Для тестирования производительности требуется как мини-
мум то же количество дискового пространства, что и при функциональном тестирова-
нии, дополнительное дисковое пространство для тестов емкости, а также
производительность оборудования наравне с производственной средой. Если в произ-
водственной среде для хранения используется SAN, то среда тестовой лаборатории
также должна иметь SAN. Система хранения SAN позволяет быстро добавить допол-
нительное дисковое пространство для серверов Hyper-V (в зависимости от требований
тестирования).
Тестирование — это итеративный процесс, во время которого вы отыскиваете пробле-
мы проекта, выявляете ошибки в готовых продуктах или написанном вами программ-
ном обеспечении, а также ищете проблемы в области безопасности. Во всех этих си-
туациях вам нужно будет сохранять текущее состояние тестового решения (для после-
дующего восстановления), поэтому у вас должно быть достаточно дискового
пространства для такого сохранения.
Для сохранения тестовых решений есть два варианта:
хранение сохраненных виртуальных машин на серверах Hyper-V;
хранение сохраненных виртуальных машин в библиотеке SCVMM.
Для каждого из этих вариантов потребуется соответствующее количество дискового
пространства. Для кратковременного хранения используйте сервер Hyper-V. Для дли-
тельного хранения следует использовать библиотеку SCVMM. Поскольку хранение

виртуальных машин в библиотеке SCVMM может потребовать их копирования по се-
ти, то лучше использовать библиотеку только тогда, когда у вас недостаточно места на
серверах Hyper-V или если виртуальные машины будут длительный период времени
находиться в автономном режиме.
Если вы можете поставить тестовое решение на один сервер Hyper-V, тогда весь обмен
может происходить на этом сервере через внутреннюю или частную виртуальную сеть.
Виртуальная сеть может быть подготовлена в то же время, когда вы готовите тестовое
решение на сервере Hyper-V, либо виртуальные сети можно подготовить заранее и
присваивать их виртуальным машинам тестового решения. Для решения проблем мар-
шрутизации вам придется создать виртуальную машину со службой Routing and Remote
Access Services (RRAS), которая будет обеспечивать маршрутизацию между разными
виртуальными сетями.
Как уже обсуждалось ранее, тестовая лаборатория в конечном итоге потребует от вас
развертывания тестового решения на нескольких серверах Hyper-V из пула тестовой
лаборатории. Это порождает проблемы сетевого обмена, поскольку трафик должен
быть изолирован в пределах тестового решения. Hyper-V предоставляет способ изоля-
ции трафика, но он требует ручной настройки. При помощи виртуальных локальных
сетей VLAN или 802.1q (тегирования VLAN) вы можете быстро настроить (между сер-
верами Hyper-V) изолированные тестовые сетевые сегменты для каждого тестового
решения.
VLAN требуют выделения сетевого адаптера для каждой VLAN. Такой подход ограни-
чивает количество одновременно работающих на сервере Hyper-V тестовых решений
количеством сетевых адаптеров (доступных для виртуальных сетей). При помощи те-
гирования VLAN один сетевой адаптер может поддерживать несколько VLAN. Каждая
виртуальная машина может быть настроена на использование уникального идентифи-
кационного тега VLAN, что быстро и эффективно изолирует трафик.
Заблаговременная настройка в тестовой лаборатории нескольких идентификационных
тегов VLAN и отслеживание того, какому тестовому решению они присвоены, позво-
лит вам быстро переконфигурировать виртуальные машины на конкретный идентифи-
катор VLAN (что изолирует трафик). Для переконфигурирования виртуальных машин
нужно будет вручную выбрать идентификатор VLAN для каждой виртуальной машины
или написать скрипт, который берет список виртуальных машин сервера и конфигури-
рует их с правильным идентификатором VLAN.
Соображения по управлению
Тестовые лаборатории обычно не управляются той же самой командой, которая управ-
ляет производственной средой. Поэтому мы не рекомендуем управлять тестовой лабо-
раторией при помощи той инсталляции SCVMM 2008, которую вы используете для
управления производственной средой серверов Hyper-V. Кроме того, изоляция тесто-
вой лаборатории не должна позволять производственному SCVMM 2008 видеть серве-
ра Hyper-V тестовой лаборатории.
Отдельная инсталляция SCVMM 2008 для управления тестовой лабораторией должна

включать в себя центральный совместно используемый ресурс библиотеки и инсталля-
цию портала Self-Service Portal. Центральный ресурс библиотеки должен быть источ-
ником всех предварительно созданных виртуальных машин и шаблонов, которые будут
поставляться в тестовой лаборатории. Наличие предварительно созданных инсталля-
ций операционных систем и приложений сократит время и усилия, требующиеся для
подготовки тестового решения. Репликация ресурса библиотеки на все серверы пула
тестовой лаборатории позволит вам поставлять виртуальные машины с локального
сервера Hyper-V и избавит от проблем с пропускной способностью сети.
Поскольку на пуле серверов может работать несколько тестов, было бы непрактичным
пытаться управлять тестом из Hyper-V Manager, поскольку вы видите одновременно
только один сервер. Использование консоли SCVMM Administrative Console создает
другую проблему — вы получите представление сразу всех виртуальных машин, а вы
не хотите давать тестерам доступ к консоли Administrative Console (из соображений
безопасности). В такой ситуации идеально подходит консоль портала SCVMM Self-
Service Portal. Она дает единое представление всех виртуальных машин, которыми
владеет один пользователь, — вне зависимости от того, на каком сервере Hyper-V ра-
ботает виртуальная машина.
Для использования портала Self-Service Portal в тестовой лаборатории вам необходимо
для каждой инсталляции портала Self-Service Portal поместить пул серверов Hyper-V
в группу хостов. После того как серверы станут членами группы хостов, вы можете
создавать пользовательские роли для портала. Пользовательские роли позволяют вам:
указать область действия роли (группы и пользователи); указать те действия, которые
обладатель пользовательской роли может выполнять (Start, Stop, Pause, Resume,
Checkpoint, Remove, Remote Connection, Shutdown, а также настройку пароля локально-
го администратора Local Administrator Password); определить, может ли обладатель
пользовательской роли создавать виртуальные машины и шаблоны; определить те ре-
сурсы библиотек, которые он может использовать; а также определить квоту, которой
он обладает для развертывания виртуальных машин.
В сценарии тестовой лаборатории могут присутствовать разные классы пользователей,
которые взаимодействуют с тестовой средой:
Test creator (Создатель тестов) — готовит тестовое решение;
Tester (Тестировщик) — работает с виртуальными машинами и выполняет тестовые
действия;
Developer (Разработчик) — работает с виртуальными машинами и занимается поис-
ком программных ошибок;
Support Engineer (Инженер поддержки) — обеспечивает компетенцию по спе-
цифичным проблемам программного обеспечения, которые возникают в тестовой
среде.
Каждая роль ограничена определенным набором требуемых для нее действий. Напри-
мер, создателю тестов понадобится право на создание виртуальных машин, в то время
как тестировщику, разработчику и инженеру поддержки такое право будет не нужно.
После конфигурирования портала Self-Service Portal и пользовательских ролей сле-

дующим шагом вам нужно будет разобраться с доступом к порталу Self-Service Portal.
В современных условиях глобальных компаний, надомной работы и использования
контрактной рабочей силы вы не можете предполагать, что каждый человек, которому
понадобится работать с тестовой лабораторией, будет физически находиться в месте ее
расположения, т. е. вы должны будете обеспечить удаленный доступ к тестовой лабо-
ратории. Вы можете предполагать, что каждый, кому нужно подключение к порталу
Self-Service Portal, будет иметь доступ к корпоративной сети. Эти пользователи могут
сидеть в офисе, они могут быть подключены через VPN, либо они могут подключиться
через терминальный шлюз. Вы можете просто выложить им Web-сайт портала Self-
Service Portal на границе тестовой лаборатории через сетевой экран и предоставить
удаленный доступ через интерфейс браузера. В этом случае вы должны защитить пор-
тал Self-Service Portal при помощи сертификата SSL (для шифрования всего обмена).
Несмотря на то, что тестовая лаборатория не считается производственной средой, экс-
плуатационные проблемы в тестовой лаборатории могут негативно влиять на доведе-
ние нового приложения до производства (или на быстрый поиск проблем в уже суще-
ствующей производственной системе или приложении). Поэтому тестовую лаборато-
рию следует эксплуатировать как производственную среду.
Для наблюдения за состоянием серверов Hyper-V разверните менеджер System Center
Operations Manager 2007. Это будет отдельная инсталляция в тестовой лаборатории
(специально для управления средой лаборатории). Для выполнения функционального
тестирования и тестирования производительности разверните в виртуальных машинах
агенты System Center Operations Manager. Наблюдайте во время тестирования за произ-
водительностью, чтобы определить, не влияет ли на результаты тестов конфигурация
серверов Hyper-V или других параллельно выполняющихся на этом же самом сервере
тестов (либо использование одной и той же сети).
Разверните приложение для резервного копирования (такое, как System Center Data
Protection Manager), чтобы определить продолжительность резервного копирования
решения. Выполните тестирование восстановления, чтобы определить, сколько време-
ни займет восстановление решения с резервной копии (или после катастрофы) и с ка-
кими проблемами вам придется при этом столкнуться. Резервное копирование серве-
ров SCVMM и серверов Hyper-V также может уменьшить время восстановления тесто-
вого решения.
Используйте контрольные точки SCVMM для минимизации переделок при тестирова-
нии. При использовании контрольных точек вам нужно учесть не только виртуальную
машину, для которой вы делаете контрольную точку, но и потенциальные осложнения
отката. Если вы делаете контрольную точку для сервера, выполняете тест, а затем при-
нимаете решение вернуться к предыдущему состоянию, то можете создать проблемы в
своей тестовой среде. Например, пароль безопасного канала для сервера мог изменить-
ся после того, как вы сделали контрольную точку. Когда вы возвращаетесь к предыду-
щему состоянию, этот пароль будет неправильным и у сервера начнутся проблемы при
обмене с доменом Active Directory. Другой пример — контроллеры домена. Использо-
вание контрольных точек для контроллеров домена может привести к откату номера
последовательности обновлений (update sequence number, USN) и вызвать серьезные
проблемы со стабильностью леса Active Directory. При использовании контрольных
точек лучше всего делать контрольную точку для всех машин тестового решения в
один и тот же момент времени. Это позволит вам вернуть все решение в согласованное
состояние.
Соображения по альтернативному использованию

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

Соображения по разработке хостов
В таком сценарии участвуют серверы Hyper-V с виртуальными машинами для рабочих
станций разработки, выделенных репозитариев кодов для каждого проекта, а также
необходимых вспомогательных систем. Некоторые вспомогательные системы, такие,
как базы данных, выделяются команде проекта, а такие, как Active Directory, совместно
используются многими проектами. В среде разработки программного обеспечения
обычно нет постоянной подготовки виртуальных машин. Когда среда разработки для
проекта настроена, она обычно так и существует в течение всего времени жизни про-
екта.
Когда вы проектируете серверы Hyper-V под рабочие станции разработки программно-
го обеспечения, производительность играет очень важную роль. Процесс компиляции
программного обеспечения интенсивно использует процессор и требует оптимальной
дисковой производительности. Виртуальные машины для разработки программного
обеспечения должны иметь минимум два виртуальных процессора и от 4 до 8 Гбайт
оперативной памяти, а дисковая подсистема должна использовать RAID 10 для повы-
шения производительности и защиты от сбоев. Такая конфигурация ограничивает то
количество рабочих станций, которые вы сможете разместить на одном сервере Hyper-V.
Типичный четырехпроцессорный четырехъядерный сервер может обеспечить работу
максимум семи рабочих станций, если для них резервируется соответствующее коли-
чество виртуальных процессоров. Вспомогательные службы и репозитарии кодов
потребуют минимального количества виртуальных машин для каждого проекта; их
можно разместить как на выделенных серверах Hyper-V, так и вместе с рабочими стан-
циями.
Соображения по системам хранения

Рабочие станции для разработки программного обеспечения во время компиляции по-
казывают высокий уровень операций дискового ввода/вывода. Переход от физических
рабочих станций разработки к виртуализированным станциям, сконцентрированным на
одном сервере Hyper-V может привести к увеличению времени компиляции, если ин-
фраструктура хранения не спроектирована должным образом. Вы можете обеспечить
оптимальную производительность при помощи применения системы хранения SAN
с большим количеством дисков, организованных в массив RAID 10.
Сочетание команд разработчиков одного проекта или таких команд, которые делают
компиляцию в одно и то же время дня, может привести к всплеску операций дискового
ввода/вывода. Сочетание рабочих станций из разных проектов или разных часовых
поясов может помочь более равномерно распределить дисковый ввод/вывод в течение
дня.
Несмотря на то, что можно сконцентрировать все рабочие станции одного проекта раз-
работки на одном и том же сервере Hyper-V, более вероятна такая ситуация, когда они
будут распределены по нескольким серверам Hyper-V. Если для проекта разработки

требуется изоляция сетевого трафика, то вам нужно будет спроектировать сеть таким
образом, чтобы серверы Hyper-V соединялись изолированными сегментами. Для этого
можно использовать виртуальные локальные сети VLAN (точно так же, как и в сцена-
рии тестовой лаборатории).
Соображения управления
Разработчики в основном работают со своими виртуализированными рабочими стан-
циями. Это можно сделать двумя способами: пользователь может либо использовать
стандартного клиента удаленного рабочего стола Remote Desktop для прямого подклю-
чения к машине, либо использовать портал Self-Service Portal. Если же разработчик
будет работать с виртуальными машинами нескольких рабочих станций, либо со своей
рабочей станцией и с виртуальными машинами вспомогательных служб, тогда лучше
использовать портал Self-Service Portal, чтобы иметь единую консоль с представлением
всех виртуальных машин.
Резюме
В этой главы были выделены четыре разных сценария виртуализации серверов, кото-
рые часто встречаются у клиентов. При разработке сценария виртуализации центра
обработки данных необходимо обеспечить: снижение необходимого количества физи-
ческих серверов для организации рабочей инфраструктуры (для этого надо правильно
определить емкость серверов Hyper-V); отказоустойчивость решения; создание надеж-
ных процедур резервного копирования и восстановления; а также централизованное
управление и поставку виртуальных машин. При разработке сценария филиала необхо-
димо настроить один сервер Hyper-V для предоставления основных служб на каждой
площадке, а также предусмотреть возможности для управления, резервного копирова-
ния и эксплуатации (как при наличии подключения через WAN, так и при его отсутст-
вии). При разработке сценария тестовой лаборатории необходимо: создать изолиро-
ванную среду тестирования и проверки, предоставив в то же самое время пользовате-
лям доступ к серверам; обеспечить минимальное взаимное влияние выполняющихся
тестов; а также предусмотреть другие варианты ее использования (для восстановления
после катастроф). При анализе сценария разработки программного обеспечения необ-
ходимо обеспечить: наличие у рабочих станций разработчиков требуемой для компи-
ляции производительности; наличие безопасного удаленного доступа; а также наличие
репозитариев кода для безопасного хранения исходных кодов.

руководство "Infrastructure Planning and Design Guides" дает указания по проектиро-
ванию физических и виртуальных сред, доступно по ссылке:
руководство "Windows Server 2008 Security Guide", в котором содержатся рекомен-

дации по обеспечению безопасности сервера Windows Server 2008, в том числе
имеющего роль Hyper-V, доступно по ссылке:
статья TechNet с названием "Windows Server 2008 Failover Cluster", в которой дан
обзор отказоустойчивой кластеризации Windows Server 2008, доступна по ссылке:
http://technet.microsoft.com/en-us/magazine/2008.07.failover.aspx?pr=blog;
документация по конфигурированию портала SCVMM 2008 Self-Service Portal,
в которой описаны опции конфигурации портала, доступна по ссылке:
центр SCVMM TechNet TechCenter — централизованное хранилище технической
документации и информации поддержки по семейству продуктов SCVMM, доступ-
но по ссылке: http://technet.microsoft.com/en-us/scvmm/default.aspx.
ГЛАВА 18
Инфраструктура
виртуальных рабочих столов
Самыми частыми причинами выбора отделами ИТ технологий виртуализации (таких,
как Microsoft Windows Server 2008 Hyper-V) является желание решить такие проблемы,
как: разрастание серверного парка, низкий уровень коэффициента использования сер-
веров, проблемы с электропитанием и охлаждением, размеры центров обработки дан-
ных, уменьшение бюджетов на информационные технологии. Несмотря на то, что ин-
фраструктура виртуальных рабочих столов (Virtual Desktop Infrastructure, VDI) — это
еще не вполне зрелая технология, она является той областью, в которой тестируются и
развертываются решения виртуализации (для упрощения подготовки рабочих столов
пользователей и управления ими); а также содействует дальнейшему снижению бюд-
жетных затрат и эксплуатационных расходов на ИТ.
Решение VDI позволяет организации размещать виртуальные рабочие столы на фермах
серверов в центрах обработки данных, а также предоставлять доступ к виртуальному
рабочему столу из самых разных "тонких" или богатых клиентов (начиная с терми-
нальных устройств и заканчивая полноценными настольными компьютерами). При
использовании VDI операционная система и приложения рабочего стола хранятся и
выполняются на серверах центра обработки данных, а пользовательский интерфейс
отображается на клиентских устройствах при помощи протокола удаленного рабочего
стола. Аналогично инфраструктуре виртуализации серверов, решение VDI состоит из
целой комбинации оборудования и программного обеспечения виртуализации, а также
инструментов управления, которые представляют собой комплексное решение по под-
готовке, конфигурированию и управлению виртуализированными рабочими столами.
Главная цель данной главы — представить вам введение в концепции VDI и те облас-
ти, для которых актуально решение VDI. Точнее говоря, вы изучите ключевые атрибу-
ты решения VDI, узнаете о двух главных типах виртуализированных рабочих столов
(статических и динамических), а также и о двух главных компонентах, составляющих
решение VDI. Несмотря на то, что технология VDI не является еще достаточно зрелой
для того, чтобы заменить собой все возможные варианты пользовательских рабочих
столов, некоторые конкретные сценарии являются прекрасными кандидатами для реа-
лизации VDI. После обсуждения этих сценариев данная глава завершится обзором ре-
шений VDI компании Microsoft по состоянию на сегодняшний день.
Важнейшие атрибуты VDI

Отделы информационных технологий (ИТ) уже давно используют различные стратегии
для улучшения управления рабочими столами и упрощения подготовки, обновлений,
резервного копирования и восстановления рабочих столов пользователей, а также
обеспечения их безопасности; для упрощения развертывания, инсталляции и обслужи-
вания приложений, требующихся разным группам пользователей. Например, решения
Citrix и Microsoft Terminal Server широко использовались для поддержки централизо-
ванных служб рабочих столов, использовавших один экземпляр операционной систе-
мы. Несмотря на то, что архитектура на основе сервера терминалов является достаточ-
но эффективным способом консолидации рабочих столов конечных пользователей, она
может создавать проблемы с совместимостью приложений, а также ограничивать спо-
собность пользователя персонализировать свой рабочий стол и управлять им. Эти про-
блемы являются врожденными, поскольку служба терминалов совместно использует
один экземпляр операционной системы для всех пользователей и потому, что прило-
жения работают в серверной операционной системе Windows, а не в клиентской опера-
ционной системе Windows. По этим причинам (и по некоторым другим) и развиваются
технологии VDI, которые используют преимущества технологии виртуализации для
увеличения гибкости развертывания рабочих столов, а также для централизации
управления средой конечного пользователя, обеспечивая в то же время (присущие ре-
шениям консолидации рабочих столов на базе серверов) безопасность данных и пре-
имущества по управлению.
Независимые от оборудования
виртуальные рабочие столы
Многие предприятия определяют для себя стандартные конфигурации оборудования
серверов, которые позволяют минимизировать количество образов серверов (и их
сложность), а также упрощать общие процессы управления в рабочей среде. Несмотря
на то, что такой же подход часто применяется и к оборудованию пользовательских ра-
бочих столов, персоналу ИТ часто приходится поддерживать множество образов рабо-
чих столов, которые охватывают все разнообразие развернутых пользовательских сис-
тем — от настольных компьютеров и ноутбуков до более специализированных уст-
ройств, таких, как планшетные ноутбуки и КПК. Кроме того, поскольку многие
предприятия обновляют оборудование постепенно, персоналу ИТ приходится поддер-
живать и устаревшие образы (для загрузки старых систем) и создавать дополнительно
новые образы (для поддержки нового оборудования).
Инфраструктура VDI существенно уменьшает эти сложности, т. к. она абстрагирует
оборудование от рабочих нагрузок, т. е. от гостевой операционной системы и стека
приложений, работающих в виртуальной машине. Поскольку виртуальная машина
предоставляет рабочей нагрузке стандартную среду, которая не зависит от оборудова-
ния сервера (на котором она работает), а для доступа к ней используется клиентское
устройство, то количество образов может быть в принципе уменьшено до одной базо-
вой сборки (содержащей общий набор служб), которая может быть использована для
быстрой подготовки новых виртуальных рабочих столов.
Глава 18. Инфраструктура виртуальных рабочих столов 643
Выделенные, изолированные и безопасные

виртуальные рабочие столы
Способность инкапсулировать разные рабочие нагрузки в разные виртуальные машины
(называемые также разделами) позволяет закреплять виртуальные рабочие столы за
конкретными пользователями. Поскольку виртуальные машины могут работать одно-
временно (каждая в своем изолированном и безопасном разделе), то ошибки приложе-
ний и отказы гостевых операционных систем виртуальных машин не влияют на рабо-
тающие в других виртуальных машинах виртуальные рабочие столы. Кроме того, за-
крепленные виртуальные рабочие столы могут перезагружаться, включаться и
выключаться без всякого влияния на других пользователей, что позволяет создать та-
кой тип взаимодействия стола с пользователем, который эквивалентен физическому
настольному компьютеру.
Динамическая доставка и конфигурирование приложений

Хотя это встречается не только в VDI, но само отделение слоя приложений от опера-
ционной системы делает возможной работу с одним базовым образом (для виртуаль-
ных рабочих столов). Как виртуализация приложений с потоковой их выдачей, так и
приложения на серверах позволяют персоналу ИТ отвязать приложения от базового
образа, поэтому они могут заняться персонализацией виртуальных рабочих столов при
помощи динамической доставки приложений (в соответствии с ролью пользователя и
членством в группах).
Есть два способа, которыми приложения могут быть отделены от виртуального рабоче-
го стола и динамически доставлены на него. В первом случае среда приложения ин-
сталлируется на виртуальный рабочий стол (для изоляции работающего в гостевой
операционной системе приложения). Точнее говоря, виртуальная среда оказывается
слоем между операционной системой и стеком приложения. Виртуализированные при-
ложения не инсталлируются в гостевую операционную систему; вместо этого код мож-
но динамически посылать потоком и кэшировать в виртуальной среде (по мере необ-
ходимости в новых порциях приложения). Виртуальная среда изолирует каждое вир-
туализированное приложение от других приложений (а также и от гостевой
операционной системы), так что несколько версий приложения могут работать одно-
временно без конфликтов, которые могли бы произойти при инсталляции этих прило-
жений в гостевую операционную систему и модификации ее ресурсов. Во втором слу-
чае отделение уровня приложения достигается при помощи работы приложений на
сервере терминалов и предоставления их на виртуальный рабочий стол. При таком
подходе приложения не направляются потоком на виртуальный рабочий стол и не ин-
сталлируются в его образ; они предоставляются удаленным образом на виртуальный
рабочий стол (точно так же, как при работе сервера терминалов с обычным (физиче-
ским) настольным компьютером).
Гибкое выделение ресурсов

Когда физический настольный компьютер уже не способен дать при работе с приложе-
ниями требуемую от него производительность (из-за ограниченности ресурсов), т. е.
два варианта: либо модернизация аппаратных компонентов компьютера (памяти, гра-

фической подсистемы и/или процессора), либо полная замена компьютера более мощ-
ной системой. В обоих случаях конечный пользователь не сможет выполнять свои
обычные ежедневные обязанности, причем это может занять как несколько часов
(в случае модернизации оборудования), так и вылиться в несколько недель или месяцев
работы с пониженной производительностью (до того момента, когда будет куплен и
развернут новый настольный компьютер).
При реализации инфраструктуры VDI выделение (или изъятие) ресурсов виртуальным
рабочим столам может выполняться из имеющегося на физическом сервере пула. В то
время как большинство физических настольных компьютеров не поддерживает добав-
ления аппаратных компонентов без выключения системы, серверы обычно обладают
способностью добавлять оборудование "на ходу", что позволяет наращивать ресурсы
сервера по мере роста требований к его емкости. Если же сервер или служба виртуали-
зации требует перезапуска для распознавания нового оборудования (либо если у серве-
ра нет нужной емкости для выделения дополнительных ресурсов), то виртуальные ра-
бочие столы можно быстро мигрировать на другие серверы, на которых нужная ем-
кость имеется.
Кроме того, выделение ресурсов виртуальным рабочим столам можно модифицировать
по мере изменения требований рабочей нагрузки. Это справедливо не только для ос-
новных ресурсов (таких, как память и процессоры), но и для прочих виртуализирован-
ных ресурсов (таких, как сетевые адаптеры, дисковые контроллеры, а также устройства
хранения). В некоторых случаях возможно динамическое выделение ресурсов, для ко-
торого не требуется приостанавливать или выключать виртуальную машину. Для вы-
деления других ресурсов может потребоваться выключить машину. Однако прерыва-
ние работы конечного пользователя будет измеряться минутами, а не часами или
днями.
Быстрая поставка и вывод из эксплуатации

рабочих столов
Поставка (или вывод из эксплуатации) физического настольного компьютера конечно-
му пользователю в обычной среде чаще всего является ручным процессом, который
может занять несколько дней. В среде VDI этот процесс можно выполнить за несколь-
ко минут. По существу поставка нового виртуального рабочего стола — это создание
новой виртуальной машины из базового образа и развертывание ее на существующем
сервере. После этого пользователь может подключаться к виртуальному рабочему сто-
лу из клиентского устройства при помощи протокола удаленного рабочего стола. Для
вывода из эксплуатации виртуального рабочего стола нужно отменить регистрацию
виртуальной машины на сервере виртуализации и сохранить ее в библиотеке (в архив-
ных целях).
Поставка в среде VDI может быть выполнена так быстро потому, что виртуальная ма-
шина состоит всего из нескольких файлов, которые содержат: настройки конфигурации
виртуализации, гостевую операционную систему, приложения и данные. Для создания
новой виртуальной машины нужно: выделить область хранения для новой виртуальной
машины; скопировать файл с базовым образом для конечного пользователя; сконфигу-
рировать настройки виртуальной машины; развернуть ее на сервере виртуализации;

предоставить пользователю права на подключение и доступ к виртуальной машине.
Сегодня существует много различных решений VDI, позволяющих автоматизировать
этот процесс при помощи: предварительного создания шаблонов, которые определяют
настройки виртуальной машины и рабочей нагрузки; оптимального развертывания
новой виртуальной машины в зависимости от производительности и емкости сервера;
и даже при помощи управляемого политиками интерфейса, который позволяет пользо-
вателям создавать экземпляры собственных виртуальных машин.
Быстрая миграция рабочих столов

Решения VDI обеспечивают быструю миграцию рабочих столов (для поддержки пла-
нового и непланового обслуживания оборудования, а также как средство переноса вир-
туальных рабочих столов на другой сервер в зависимости от требований рабочего сто-
ла к производительности). В среде физических настольных компьютеров (даже там, где
многие персональные настройки зависят от сети) миграция образа настольного компь-
ютера на новое оборудование потребует значительного количества ручной работы и
длительного прерывания работы конечного пользователя. В среде VDI с фермами сер-
веров для централизованной виртуализации и системами совместного хранения (а так-
же при наличии решений высокой готовности и распределения нагрузки) миграция
виртуального рабочего стола — это процесс, который может быть полностью автома-
тизирован для минимального прерывания работы пользователя.
Для планового обслуживания оборудования или для миграции с целью повышения
производительности VDI предоставляет следующие возможности: сохранение состоя-
ния виртуальной машины (и в том числе памяти и регистров) в файлы, приостановка
выполнения, миграция виртуальной машины на другой сервер фермы и возобновление
работы. Если ферма серверов подключена к системе совместного хранения (такой, как
Storage Area Network (SAN), Network Attached Storage (NAS) или другой подобной ин-
фраструктуре), то миграция виртуального рабочего стола может быть выполнена таким
образом, что пользователь сможет подключиться к своему виртуальному рабочему
столу буквально через несколько секунд (и возобновить свою работу с того места, где
он ее оставил). На случай непланового сбоя оборудования VDI поддерживает решения
высокой готовности, которые позволяют мигрировать виртуальные рабочие столы на
другие компьютеры фермы серверов (в случае отсутствия отклика от исходного серве-
ра). В этом случае состояние виртуальной машины не сохраняется, но виртуальный
рабочий стол может быть переназначен на новый сервер, что позволит пользователю
повторно подключиться буквально через несколько минут после сбоя.
Централизованное и безопасное хранение данных

Проблемным аспектом среды с физическими настольными компьютерами является
распыление бизнес-данных на тысячи локальных жестких дисков. Конечно, в боль-
шинстве предприятий развернуты файловые серверы и политики (для централизации,
хранения и обеспечения безопасности данных), но эти меры не гарантируют того, что
критичная информация не будет записана на локальный жесткий диск (или съемный
носитель). Если к тому же нет надежных резервных копий локальных устройств хране-
ния, тогда есть дополнительный риск повреждения и потери данных, а также их воров-
ства (которые могут привести к значительным потерям для бизнеса).
В среде VDI (и особенно той, где используются "тонкие" клиенты) пользователи могут
обращаться к своим виртуальным рабочим столам локально, а данные будут храниться
и защищаться в центре обработки данных (при использовании SAN или NAS). Без ло-
кальных устройств хранения данных риск серьезного повреждения данных, их потери
или воровства на данном уровне отсутствует.
Централизованное резервное копирование

Вместе с проблемой распыления данных (по традиционным физическим настольным
компьютерам) приходит и проблема локального резервного копирования. Поскольку
физические настольные компьютеры могут находиться за многими локальными сетями
(LAN) и даже глобальными сетями (WAN), то невозможно реализовать единое и про-
стое решение резервного копирования. Фактически локальные данные часто и вовсе не
копируются, поскольку проталкивание пользовательских данных (от тысяч пользова-
телей) по сетям LAN (или WAN), безусловно, перегрузит большую часть сетей. Кроме
того, некоторые пользователи подключаются к корпоративной сети нерегулярно, а по-
ручение удаленным пользователям задачи резервного копирования их данных не
позволяет добиться надежных результатов.
В такой среде VDI, где фермы серверов виртуализации и системы совместного хране-
ния централизованы в центре обработки данных, процесс резервного копирования
можно локализовать в сети центра обработки данных. При помощи использования
поддерживающей моментальные снимки технологии резервного копирования (которая
записывает только изменения данных, а не делает повторно резервные копии всех дан-
ных) можно не только снизить влияние выполнения резервного копирования на произ-
водительность сервера, но и повысить скорость этого процесса, а также минимизиро-
вать количество хранимых данных.
Расширенная поддержка клиентских устройств

В то время как для традиционной среды настольных компьютеров обычно требуется
развертывание систем с большим количеством компонентов и высокой сложностью,
среда VDI предоставляет широкий выбор устройств для подключения конечного поль-
зователя к виртуальному рабочему столу. Например, среда VDI поддерживает развер-
тывание устройств "тонких" клиентов (без локальной клиентской операционной систе-
мы) для тех пользователей, которые выполняют узкий набор задач и не нуждаются
в доступе к локальным ресурсам. Она также поддерживает подключение с богатых
клиентов (например, ноутбуков) для мобильных пользователей, которым требуется
возможность работы и в автономном режиме тоже.
"Тонкие" клиенты (которые предоставляют доступ к виртуальному рабочему столу при
минимальном количестве программных компонентов) предлагают лучшие возможно-
сти в смысле возврата инвестиций (return on investment, ROI). Вот некоторые преиму-
щества развертывания "тонких" клиентов, которые следует учитывать:
незначительные запросы в отношении электроэнергии, охлаждения и занимаемого
места;
увеличение среднего времени между сбоями (mean time between failures, MTBF)
вследствие снижения количества компонентов;
снижение ручных трудозатрат на выполнение замены компонентов;
более длительный цикл обновления (вследствие более продолжительного жизнен-
ного цикла устройства);
минимальные требования по конфигурированию.
Конечно, развертывание "тонких" клиентов очень зависит от наличия надежной и отка-
зоустойчивой сети и строгого управления решением VDI (чтобы обеспечить пользова-
телям высококачественный доступ к их виртуальным рабочим столам).
Определение главных компонентов VDI

Точно так же, как и в любой технической реализации, используемые в инфраструктуре
VDI компоненты зависят от тех функциональных требований, которые она должна вы-
полнять. Основной набор компонентов общий для всех решений VDI; однако такие
элементы, как размер среды, требования по доступу к виртуальному рабочему столу,
стратегия развертывания приложений, политики управления, бюджетные ограничения
(и масса прочих соображений), определяют тот набор компонентов, которые будут ис-
пользоваться для реализации эффективного решения VDI. На рис. 18.1 демонстрирует-
ся упрощенная среда, которая включает в себя основные компоненты VDI и показыва-
ет развязку базовой операционной системы, пользовательских настроек и приложений
(которой можно достичь при помощи динамического решения VDI).
Определение статических и динамических виртуальных

рабочих столов
Одним из катализаторов при определении компонентов решения VDI является тип
виртуального рабочего стола, который вы хотите развернуть. Поэтому важно понять
две разные модели виртуального рабочего стола: статическую и динамическую.
Статический виртуальный рабочий стол

Статический виртуальный рабочий стол — это по существу прямая замена физическо-
го настольного компьютера, он работает в постоянной виртуальной машине и закреп-
лен за конкретным пользователем. Пользователь может подключаться напрямую к
виртуальному рабочему столу (при помощи клиента для подключения к удаленному
рабочему столу). Статический виртуальный рабочий стол может состоять из гостевой
операционной системы и инсталлированных приложений, либо он может использовать
виртуализацию приложений и потоковую их выдачу (для изоляции и динамической
доставки приложений).
Динамический виртуальный рабочий стол

Динамический виртуальный рабочий стол готовится и собирается из одного главного
образа и использует виртуализацию приложений и потоковую выдачу (а также про-
Рис. 18.1. Основные компоненты решения Virtual Desktop Infrastructure (VDI)
филь пользователя) для поставки пользователю персонализированного (но не сохра-

няемого) виртуального рабочего стола. Хранение данных пользователя может быть
постоянным и выполняться на виртуальном жестком диске, который подключается при
инициализации виртуального рабочего стола и отключается при деактивации вирту-
ального рабочего стола. Подключения пользователей к динамическим рабочим столам
управляются брокером подключений (или брокером рабочих столов).
Основные компоненты виртуализации

Основные компоненты виртуализации — это фундаментальные строительные блоки
любого решения VDI. В эту категорию входят физические серверы, программное обес-
печение виртуализации, а также устройства хранения.
Физические серверы
Для работы программного обеспечения виртуализации и выполнения виртуальных ра-
бочих столов нужен один или несколько физических серверов, а также (необязательно)
виртуализация приложений и службы управления VDI. Несмотря на то, что одного
сервера может быть вполне достаточно для поддержки основной тестовой среды,
в производственных конфигурациях потребуется еще одна или две фермы серверов для
обеспечения высокой готовности или отказоустойчивости, распределения нагрузки, а
также для обеспечения резерва емкости для роста.
Программное обеспечение виртуализации

Программное обеспечение виртуализации (такое, как Virtual Server 2005 R2 или Hyper-V)
поддерживает создание, изоляцию и одновременное выполнение виртуальных машин,
позволяет выделять и управлять системными ресурсами, а также позволяет реализовать
расширенные функциональные возможности (такие, как высокая готовность и отказо-
устойчивость). Например, сервер Virtual Server 2005 R2 может работать как на 32-, так
и на 64-битных платформах AMD-V и Intel VT, в то время как для Hyper-V требуется
64-битный процессор AMD-V или Intel VT.
Устройства хранения
Устройства хранения обеспечивают репозитарии для файлов виртуальных машин, ко-
торые инкапсулируют конфигурацию виртуальных рабочих столов, приложений, дан-
ных, а также информации состояния. Устройства хранения могут быть самыми разны-
ми — от непосредственно подключенных систем хранения (Direct Attached Storage,
DAS) для реализации в виде единственного сервера и до NAS (для небольшой или
средней фермы серверов), а также до подключенных через оптику или протокол iSCSI
сетей хранения данных (для поддержки ферм серверов масштаба предприятия).
Клиентские компоненты
Основные компоненты виртуализации представляют собой базовую инфраструктуру
серверов для работы виртуальных рабочих столов. Обратной стороной медали в дан-
ном случае является то, что конечному пользователю нужно такое устройство, которое
позволит ему удаленно подключаться к своему виртуальному рабочему столу. Несмот-
ря на то, что количество и типы устройств (которые можно использовать как клиенты
виртуального рабочего стола) постоянно растут, их можно разделить на два класса:
богатые устройства и "тонкие" устройства.
Богатые клиентские устройства

Богатый клиент — это обычно многоцелевой настольный компьютер (или ноутбук),
который может использоваться как устройство подключения к виртуальному рабочему
столу, но который также поддерживает и работу в автономном режиме при помощи
локальных ресурсов. Мобильный богатый клиент лучше всего подходит мобильным
или специальным пользователям и его использование в среде VDI должно быть мини-
мальным, чтобы получить максимальные возможности от управления. Такое устройст-
во требует наличия локальной операционной системы, и как минимум на нем должно

быть настроено клиентское приложение для удаленного рабочего стола, чтобы предос-
тавить пользователю интерфейс к виртуальному рабочему столу.
"Тонкие" клиентские устройства

"Тонкий" клиент — это "одноцелевое" устройство, которое содержит все компоненты,
необходимые для подключения к виртуальному рабочему столу и предоставления кли-
енту богатого пользовательского интерфейса. Устройство "тонкого" клиента прекрасно
подходит для любого пользователя, которому нужен доступ к ресурсам только через
виртуальный рабочий стол (и не нужны особые графические возможности). Поскольку
в "тонких" клиентах нет сложных компонентов, их легко заменять, они потребляют
мало электроэнергии, занимают мало места и не требуют наличия полной операцион-
ной системы, то они являются ключевыми для такой реализации VDI, которая должна
обеспечить простоту управления и снизить долговременные эксплуатационные рас-
ходы.
Компоненты виртуализации приложений

Если каждый виртуальный рабочий стол представляет собой статическую рабочую на-
грузку (гостевая операционная система и инсталлированные приложения), то такой
комбинации основных компонентов виртуализации и клиентских компонентов вполне
достаточно для формирования базовой реализации VDI, которая обеспечивает соответ-
ствие "один-к-одному" между пользователями и виртуальными рабочими столами. Од-
нако такой тип решения VDI имеет ограниченную применимость (даже для предвари-
тельной проверки концепций). Замена тысяч физических настольных компьютеров
виртуальными рабочими столами без реализации таких решений, которые уменьшат
количество экземпляров операционных систем, минимизируют процессы доставки и
обновления приложений, а также решат другие дорогие задачи управления, не сможет
максимально раскрыть потенциал решения VDI по долгосрочному возврату инвести-
ций (ROI).
Фактически для реализации масштабируемого и гибкого решения VDI, которое сможет
поддерживать сотни или тысячи пользователей с различными профилями приложений,
требуется включение в него дополнительных компонентов (таких, как виртуализация
приложений и потоковая их выдача, или работающих на серверах приложений, чтобы
отделить доставку приложений от основного образа виртуального рабочего стола). Без
динамической доставки приложений вы не сможете минимизировать количество
управляемых вами образов виртуальных рабочих столов. Однако если в состав среды
VDI включены технологии динамической доставки виртуализированных приложений,
то вы вполне сможете получить один базовый образ виртуального рабочего стола, цен-
трализованное управление, а также доставку гостевой операционной системы и прило-
жений в соответствии с динамическими требованиями пользователей.
Виртуализация приложений
Технология виртуализации приложений состоит из клиентских и серверных компонен-
тов. Серверные компоненты позволяют вам хранить и обслуживать пакеты приложе-
ний в центральном репозитарии, а также управлять доставкой приложений при помо-

щи политик, которые определяют, как приложения доставляются пользователям. Если
приложению требуются обновления, то их можно установить один раз в хранящийся на
центральном сервере пакет приложения, а затем он будет распространен пользова-
телям.
Клиентские компоненты интегрированы в виртуальный рабочий стол и создают среду
изоляции, которая не дает приложению производить постоянные изменения в локаль-
ных ресурсах настольного компьютера (таких, как системные файлы и реестр). Прило-
жения по-прежнему могут читать информацию из реестра и файлов локальной систе-
мы, но поддающиеся записи версии этих ресурсов находятся внутри среды изоляции.
Преимуществом такого подхода является то, что параллельно может выполняться не-
сколько версий приложения, и они не будут создавать помех друг другу.
Поточная доставка приложений

Поточная доставка приложений помогает минимизировать влияние задержек, вноси-
мых в среде виртуализации приложений. Вместо того чтобы при первом же запросе
отправить на виртуальный рабочий стол весь код приложения, в среду изоляции от-
правляются (и там кэшируются) только те части кода, которые необходимы для запус-
ка приложения. Затем по мере необходимости на виртуальный рабочий стол отправля-
ется дополнительный код.
Хостинг приложений
Находящиеся на сервере терминалов приложения могут динамически доставляться на
виртуальный рабочий стол, что позволяет избежать инсталляции и выполнения прило-
жения на виртуальном рабочем столе. Точно так же, как и в традиционных средах
серверов терминалов, где пользователи получают доступ к находящимся на них при-
ложениям с физического настольного компьютера, пользователи виртуальных рабочих
столов имеют доступ к размещенным на хосте приложениям, которые либо интегри-
руются в их виртуальный рабочий стол, либо доступны через сеанс браузера. Анало-
гично виртуализации приложений, размещенные на хосте приложения легко разверты-
ваются, поддерживаются и удаляются (централизованно, из центра обработки данных).
Кроме того, поскольку приложения выполняются на отдельном сервере терминалов, то
у сервера виртуализации остается больше аппаратных ресурсов, что позволяет ему
обеспечить работу дополнительных виртуальных рабочих столов.
Компоненты управления
При переходе из среды физических настольных компьютеров в среду виртуальных ра-
бочих столов очень важно, чтобы компоненты управления позволяли вам эффективно
работать как со средой виртуализации, так и с физической инфраструктурой. Решение
VDI (так же, как и решение виртуализации серверов) приносит с собой такие вещи, для
которых необходимы дополнительные или обновленные инструменты управления. Да-
вайте, в частности, рассмотрим следующие компоненты управления, которые являются
важными элементами решения VDI.
Консоль Integrated Management Console

В среде VDI вы должны одновременно наблюдать как за физическими, так и за вирту-
альными машинами, чтобы отслеживать общее состояние инфраструктуры, делать уп-
реждающее планирование проблем производительности или недостатка ресурсов, а
также реагировать на неплановые прерывания обслуживания. Интегральная консоль
управления с делегированием ролей является центральным средством наблюдения и
отображения взаимосвязей виртуальных машин и физических серверов, а также быст-
рого представления состояния среды VDI в любой момент времени. Без интегральной
консоли управления вы быстро утонете в попытках установить соответствие между
состояниями физических серверов и виртуальных машин, отображаемыми в разных
консолях управления. Кроме того, использование интегральной консоли управления с
делегированием ролей дает вам возможность определять политики и присваивать пол-
номочия распределенной команде администраторов (как это обычно делается в боль-
шинстве отделов ИТ).
Брокер подключений
Брокер подключений — это компонент решения VDI, который обеспечивает способ-
ность динамически подключать пользователя к виртуальному рабочему столу. В не-
большой по размеру среде VDI (например, менее 100 пользователей) можно виртуаль-
ный рабочий стол закрепить за пользователем (в качестве замены физического на-
стольного компьютера). В такой ситуации серверы виртуализации сконфигурированы
для поддержки определенного количества виртуальных рабочих столов, и нет необхо-
димости динамически перебрасывать ресурсы между виртуальными рабочими столами
для повышения коэффициента использования сервера. Однако в большинстве сред
VDI, которые поддерживают сотни или тысячи пользователей (без одновременного
доступа и без требования закрепленного рабочего стола), брокер подключений эффек-
тивно управляет динамическим предоставлением виртуальных рабочих столов, назна-
чением виртуальных рабочих столов пользователям, а также состояниями виртуальных
рабочих столов (например, "работает", "сохраненное состояние", "выключен"), чтобы
максимизировать использование ресурсов среды VDI и минимизировать количество
компонентов виртуализации, используемых для поддержки этой среды.
Миграция виртуальных рабочих столов

Для автоматизации миграции виртуальных машин между серверами виртуализации (на
ферме серверов) решение VDI должно содержать некий компонент управления, спо-
собный анализировать нагрузку и производительность сервера виртуализации и при-
нимать интеллектуальные решения по размещению виртуальных рабочих столов, кото-
рые приведут к балансу между максимальным использованием ресурсов и выполнени-
ем требований к ресурсам самих рабочих столов. Без такого интеллектуального
компонента для миграции виртуальных рабочих столов управление динамической сре-
дой виртуальных рабочих столов невозможно.
Репозитарий виртуальных рабочих столов

Одна из сложных задач для крупной реализации VDI — это управление большим ко-
личеством ресурсов виртуальных рабочих столов, сосредоточенных в центре обработ-
ки данных. Интегральная консоль управления является центральной точкой наблюде-

ния за активными ресурсами VDI, но есть также необходимость в репозитарии, где бу-
дут храниться и учитываться неактивные компоненты виртуальных рабочих столов
(такие, как шаблоны виртуальных машин, настройки конфигураций, виртуальные же-
сткие диски и другие компоненты виртуальных рабочих столов). Репозитарий вирту-
альных рабочих столов должен обеспечивать возможность группирования, каталогиза-
ции и быстрой идентификации соответствующих ресурсов и должен служить источни-
ком поставки новых виртуальных рабочих столов.
Резервное копирование виртуальных рабочих столов

Развертывание виртуальных рабочих столов на централизованных серверах дает вам
возможность использовать одно решение резервного копирования для защиты от по-
терь и повреждения данных как серверов виртуализации, так и виртуальных машин.
Для статических виртуальных рабочих столов (в которых могут быть инсталлированы
специальные приложения) в среду VDI можно интегрировать использующий момен-
тальные снимки компонент резервного копирования для копирования целиком вирту-
альных машин, а не только имеющихся на них файлов. Если это поддерживается гос-
тевой и серверной операционными системами, то подход на основе моментальных
снимков можно использовать для одновременного резервного копирования сервера
виртуализации и всех работающих виртуальных машин. Если гостевая операционная
система виртуального рабочего стола не поддерживает использование моментальных
снимков, то вы можете применить традиционный метод резервного копирования (на-
пример, такой, который требует инсталляции агента в виртуальном рабочем столе).
Динамические виртуальные столы имеют преимущество при планировании резервного
копирования: вам нужно копировать только сохраняемые пользователем данные, а не
всю виртуальную машину.
Описание стандартных сценариев VDI

Несмотря на то, что решения VDI не являются стратегией замены для всех вариантов
сред с пользовательскими рабочими столами, в некоторых конкретных сценариях
вполне можно использовать преимущества VDI. Эти сценарии имеют некоторые об-
щие параметры, такие как: доступ к рабочим нагрузкам независимо от физического
(офис, отель, дом) или географического положения; отсутствие необходимости в ло-
кальном доступе к ресурсам и данным; отсутствие потребности в специальной графи-
ческой обработке. По мере развития VDI и интегральных инструментов управления,
целевыми объектами для реализации VDI станут новые среды с физическими настоль-
ными компьютерами, что позволит организациям создавать динамические пользова-
тельские среды, которые помогут снизить долговременные эксплуатационные расходы.
Оффшорная разработка
Отличным примером сценария, который подходит для реализации решения VDI, явля-
ется предоставление доступа к ресурсам для разработки или тестирования новой
команде, которая находится в некоем удаленном месте (или в оффшоре). Используя
стратегию развертывания традиционных физических настольных компьютеров, при

подключении такой команды вы столкнулись бы с задержками, вызванными необхо-
димостью купить, погрузить и доставить физические настольные компьютеры в новое
место. Кроме того, вы, вероятно, столкнулись бы со многими техническими проблема-
ми, если бы попытались удаленно инсталлировать и управлять системами без своего
человека на удаленной площадке (у вас были бы трудности с доставкой и установкой
обновлений для операционных систем и приложений, с обеспечением защиты систем
от вирусов и шпионского программного обеспечения, с решением обычных проблем
оборудования и программного обеспечения, а также с обеспечением безопасности
важных данных).
В отличие от этой ситуации, при использовании решения VDI вы можете снабдить но-
вую команду "тонкими" клиентами, которые требуют минимального конфигурирова-
ния и управления. "Тонкие" клиенты могут подключиться к статическим виртуальным
рабочим столам, имеющим полную среду для разработки или тестирования. Все задачи
управления (в том числе подготовка, обеспечение безопасности, обслуживание вирту-
альных рабочих столов) могут выполняться локально персоналом отдела ИТ. При
использовании VDI подготовка к работе и роспуск удаленных команд может выпол-
няться очень быстро и при этом не надо создавать на удаленной площадке никакой
серьезной инфраструктуры. Критичный фактор в этом сценарии — то, что сетевое под-
ключение между удаленной площадкой и инфраструктурой VDI должно быть надеж-
ным, быстрым и иметь резервирование.
Центры обработки звонков,

службы технической поддержки, розничные филиалы
Другие сценарии, в которых VDI является вполне практичным выбором, — это центры
обработки звонков, службы технической поддержки и розничные филиалы, где группы
пользователей работают посменно и применяют совместно используемый набор при-
ложений и данных. Такие пользователи называются также работниками одной опера-
ции (task worker). Общей характеристикой центра обработки звонков, службы техниче-
ской поддержки и розничного филиала является то, что их работники обычно не обра-
щаются к своим рабочим столам все одновременно и могут не иметь своего
(закрепленного за ними) рабочего места (им нужно подключаться к стандартной рабо-
чей среде с любого рабочего места). Такие работники могут иметь доступ к конфиден-
циальной информации, поэтому используемые ими данные часто централизованы и
защищены.
Развертывание в таких средах динамического решения VDI с "тонкими" клиентами
позволяет таким работникам перемещаться между рабочими местами и подключаться с
любого устройства к своей рабочей нагрузке (с доступом к централизованно храня-
щимся данным). Для филиалов с большой текучестью кадров управление со стороны
отдела ИТ может ограничиваться только созданием (или удалением) учетных записей и
модификацией группового членства (которое обеспечивает доступ к соответствующей
конфигурации виртуального рабочего стола). Кроме того, такой подход может помочь
минимизировать физическую инфраструктуру, поскольку виртуальные рабочие столы
могут собираться, активироваться и деактивироваться в соответствии с текущей по-
требностью.
Обзор решения VDI компании Microsoft

Компания Microsoft (в сотрудничестве с такими сторонними поставщиками, как Citrix)
предоставляет целый набор компонентов, которые позволяют вам реализовать как ста-
тическое, так и динамическое решение VDI. Решение VDI от компании Microsoft ис-
пользует много тех компонентов, которые применяются для реализации инфраструкту-
ры виртуализации серверов. По существу решение VDI компании Microsoft создано на
базе все той же виртуализации и ее управления (с добавлением специальных компо-
нентов для управления виртуальными рабочими столами).
Сервер Windows Server 2008 Hyper-V

В решении VDI компании Microsoft сервер Microsoft Windows Server 2008 Hyper-V ра-
ботает как компонент уровня виртуализации. Будучи выполненным на базе гипервизо-
ра, Hyper-V является основным компонентом, поддерживающим изолированные и
безопасные разделы, в которых вы можете выполнять виртуальные рабочие столы.
Вследствие своей интеграции в Windows Server 2008, он обеспечивает быструю мигра-
цию (с минимальным прерыванием обслуживания) виртуальных столов между серве-
рами Hyper-V (использующими встроенную отказоустойчивую кластеризацию). При
быстрой миграции виртуальные рабочие столы переводятся в сохраненное состояние,
затем переносятся и перезапускаются на новом узле Hyper-V (все это занимает бук-
вально минуту). Это полезно в том случае, когда серверу Hyper-V требуется плановое
обслуживание или вам нужно выполнить балансировку нагрузки серверов Hyper-V.
Поддержка сервером Hyper-V отказоустойчивой кластеризации дает возможность в
случае непланового события (такого, как сбой оборудования) перезапускать виртуаль-
ные рабочие столы на другом узле Hyper-V. Hyper-V поддерживает широкий диапазон
устройств (в том числе SAN, NAS, DAS и iSCSI), что позволяет оптимально конфигу-
рировать его для поддержки как малых, так и крупных реализаций VDI. Для подклю-
чения клиентов к виртуальным рабочим столам Hyper-V предоставляет доступ через
протокол Remote Desktop Protocol (RDP).
Централизованный рабочий стол

Windows Vista Enterprise Centralized Desktop
Хотя рабочий стол Windows Vista Enterprise Centralized Desktop (VECD) и не является
компонентом этой технологии, он представляет собой имеющиеся варианты лицензи-
рования для развертывания виртуальных рабочих столов Windows в среде VDI. VECD
определяет модели лицензирования для виртуальных рабочих столов, доступ к кото-
рым производится через традиционные рабочие столы или через "тонкие" клиенты.
Лицензии выделяются по устройствам. Для традиционной лицензии на рабочий стол
требуется годовая подписка (в дополнение к Windows Software Assurance). Для лицен-
зии "тонкого" клиента требуется только годовая подписка, которая включает в себя
Windows Software Assurance. В любом случае вы можете инсталлировать неограничен-
ное количество копий Windows Vista Enterprise (или более ранних версий операцион-
ной системы), причем с лицензированного устройства вы можете получить доступ не
более чем к четырем работающим экземплярам одновременно. Лицензии действуют

как в статической, так и в динамической архитектуре виртуальных рабочих столов.
ВАЖНО
Вы должны тщательно изучить имеющиеся варианты лицензирования VECD (примени-
тельно к вашим планам по архитектуре VDI). Подробности по лицензированию VECD
см. по ссылке:
http://www.microsoft.com/windows/products/windowsvista/enterprise/benefit
s/licensing.mspx.
Рабочий стол Citrix XenDesktop

Citrix XenDesktop — это инструмент для развертывания динамического решения вир-
туальных рабочих столов в масштабе предприятия. XenDesktop работает с сервером
Hyper-V и состоит из нескольких компонентов, которые работают совместно для пре-
доставления пользователю персонализированного виртуального рабочего стола. Важ-
нейшим является компонент Desktop Delivery Controller (DDC). Это брокер подключе-
ний, который идентифицирует пользователя и динамически собирает его виртуальный
рабочий стол. После идентификации пользователя XenDesktop может выдать потоком
операционную систему в среду сервера виртуализации, применить к операционной
системе профиль пользователя, а также доставить пользователю приложения (при по-
мощи основанной на политиках технологии доставки приложений типа Microsoft
Application Virtualization или посредством удаленного использования Windows
Server 2008 Terminal Services RemoteApp).
Брокер Remote Desktop Connection Broker в Windows Server 2008 R2
В сервере Windows Server 2008 R2 новая роль Remote Desktop Services (ранее называв-
шаяся Terminal Services) содержит инфраструктуру брокера подключений, который позво-
ляет реализовать сквозное решение VDI в масштабах отдела. Новый брокер Remote
Desktop Connection Broker расширяет возможности брокера Session Broker (имеющегося
в Windows Server 2008) и создает унифицированную среду для администрирования как
традиционных сеансовых удаленных рабочих столов, так и удаленных рабочих столов на
базе виртуальных машин.
Брокер Remote Desktop Connection Broker поддерживает два основных сценария разверты-
вания: постоянные виртуальные машины и пул виртуальных машин. В первом случае име-
ется однозначное соответствие между виртуальной машиной и пользователем. Иначе го-
воря, каждому пользователю присваивается своя виртуальная машина, которую можно
персонализировать и настраивать (причем она сохраняет сделанные пользователем изме-
нения). В настоящее время большинство использующих технологию VDI людей разворачи-
вает именно такие постоянные машины (поскольку они дают конечному пользователю мак-
симальную гибкость). В случае использования пула виртуальных машин состояние пользо-
вателя можно сохранить при помощи профиля и перенаправления каталогов, но после
завершения сеанса пользователя все это теряется. В любом случае, брокер Remote
Desktop Connection Broker поддерживает хранение и развертывание образов на серверах
Hyper-V.
Кроме того, брокер Remote Desktop Connection Broker предоставляет обширный набор ин-
терфейсов прикладного программирования, которые позволяют создавать расширения для
управления и масштабируемости. Можно создать дополнительные модули для политик
(например, для определения соответствующей виртуальной машины или пула виртуальных
машин), модули для фильтрации (например, для подготовки виртуальных машин к приему
подключений по RDP), а также модули ресурсов (например, для размещения виртуальной

машины на подходящем сервере в соответствии с его загрузкой).
Макс Херрманн (Max Herrmann, Senior Product Manager (Windows Server))
Виртуализация приложений
Microsoft Application Virtualization
Виртуализация приложений Microsoft Application Virtualization (App-V) обеспечивает
централизованное хранение и управление приложениями и потоковую доставку при-
ложений (по требованию) на виртуальные рабочие столы. Клиент App-V создает на
виртуальном рабочем столе среду изоляции, в которой приложение выполняется от-
дельно от других приложений (избавляя от беспокойства по поводу нестабильности
системы, которая может быть вызвана версиями файлов или конфликтами настроек
реестра). App-V может сделать сначала потоковую выдачу только тех частей кода, ко-
торые нужны для запуска приложения, а затем выдавать дополнительные порции кода
(по реальной потребности пользователя). App-V может сохранить предпочтения при-
ложения в файловом кэше на виртуальном рабочем столе (для ускорения последующих
запусков приложения), а это очень важно для статического виртуального рабочего сто-
ла. В чисто динамической среде предпочтения приложения и пользователя применяют-
ся при каждой сборке динамического виртуального рабочего стола и доставке его ко-
нечному пользователю.
Windows Server 2008 Terminal Services RemoteApp

Windows Server 2008 Terminal Services RemoteApp — это еще один вариант решения
VDI для предоставления пользователям виртуальных рабочих столов доступа к прило-
жениям (без встраивания их в образ виртуального рабочего стола). Кроме того,
RemoteApp — это решение для пользователей, которым нужен доступ к одному или
нескольким таким приложениям, не совместимым с операционной системой виртуаль-
ного рабочего стола. При помощи этого компонента приложения инсталлируются и
работают удаленно на сервере терминалов Windows Terminal Services. Для того чтобы
добиться простого взаимодействия с пользователем, приложение на базе RemoteApp
запускается пользователем, который щелкает по значку в виртуальном рабочем столе
или выбирает пункт в меню Start. Этот значок может быть связан с пакетом RDP или
Microsoft Installer (MSI), который содержит инструкции и параметры для запуска сеан-
са RDP с сервером терминалов и запуска приложения. Когда подключение установле-
но, приложение работает в отдельном окне виртуального рабочего стола (параллельно
с локальными приложениями). Для автоматического запуска удаленного приложения
расширения файлов можно связать с RemoteApp (т. е. взаимодействие с пользователем
будет таким же, как и для локальных программ).
Менеджер System Center Virtual Machine Manager

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

Intelligent Placement для определения наилучшего сервера Hyper-V при их размещении.
Intelligent Placement использует интеграцию VMM и System Center Operations Manager
2007, который является источником данных по производительности, собираемых с су-
ществующих серверов Hyper-V. Брокер XenDesktop DDC также интегрируется с VMM
для автоматизации развертывания виртуальных рабочих столов на серверы Hyper-V.
Кроме того, VMM предоставляет встроенную функциональность для выполнения ми-
грации P2V (с физического на виртуальный) для образа диска (что позволяет выпол-
нить переход с физической на виртуальную платформу).
Подробности о функциональных возможностях менеджера System Center Virtual Machine
Manager см. в главах 12 и 14.
Менеджер System Center Data Protection Manager

Менеджер System Center Data Protection Manager (DPM) — это компонент управления,
который позволяет вам поддерживать резервное копирование (при помощи службы
Volume Shadow Copy Service (VSS)) активных виртуальных рабочих столов при усло-
вии, что их гостевая операционная система осведомлена о VSS. Для таких операцион-
ных систем, рабочие столы которых не осведомлены о VSS, DPM позволяет делать
резервное копирование виртуальных рабочих столов в автономном состоянии (путем
завершения их работы или сохранения состояния виртуальных машин и последующего
резервного копирования тех файлов, которые составляют виртуальную машину).
Подробности о менеджере System Center Data Protection Manager см. в главе 13.
Резюме
В этой главе мы дали обзор инфраструктуры Virtual Desktop Infrastructure, которая
представляет собой комбинацию оборудования, программного обеспечения виртуали-
зации, а также инструментов управления, обеспечивающих сквозное решение для под-
готовки, конфигурации и управления виртуализированными рабочими столами. Вы
узнали об основных атрибутах VDI и в частности о том, чем решение VDI отличается
от решения сервера терминалов.
Вы также узнали об отличиях между статическими и динамическими виртуальными
рабочими столами; о компонентах, которые интегрируются для обеспечения решения
VDI; а также и о некоторых стратегических сценариях, которые хорошо подходят для
реализации VDI. В обзоре решения VDI компании Microsoft были упомянуты Windows
Server 2008 Hyper-V, VECD, System Center VMM и DPM, Windows Server 2008 Terminal
Services, Application Virtualization и Citrix XenDesktop; было рассказано также о том,
какой вклад вносит каждый из них в поддержку создания статических и динамических
сред виртуальных рабочих столов. Важно учесть — несмотря на то, что VDI дает много
преимуществ, и в том числе способность предложить каждому пользователю изолиро-
ванную, динамическую и персонализированную рабочую нагрузку (клиентскую опера-

ционную систему и стек приложений) — технология VDI пока находится в стадии раз-
вития и еще не представляет собой общепринятого решения по замене рабочих столов.
Источники дополнительной информации

Microsoft Desktop Virtualization, доступный по ссылке:
http://www.microsoft.com/virtualization/solution-tech-desktop.mspx;
Microsoft Application Virtualization, доступный по ссылке:
http://www.microsoft.com/virtualization/solution-tech-application.mspx;
руководство TS Remote App Step-by-Step Guide, доступное по ссылке:
менеджер System Center Virtual Machine Manager 2008, доступный по ссылке:
http://www.microsoft.com/systemcenter/scvmm/default.mspx;
менеджер System Center Data Protection Manager 2007, доступный по ссылке:
http://www.microsoft.com/systemcenter/dpm/default.mspx;
Citrix XenDesktop, доступный по ссылке:
http://www.citrix.com/English/ps2/products/product.asp?contentID=163057;
демонстрация Microsoft Windows Vista Enterprise Centralized Desktop, доступная по
ссылке:
http://www.microsoft.com/windows/products/windowsvista/enterprise/vecddemo
/default.html;
Microsoft Windows Vista Enterprise Centralized Desktop, доступный по ссылке:
http://www.microsoft.com/windows/products/windowsvista/enterprise/benefits
/licensing.mspx.
ГЛАВА 19
Проект виртуализации серверов:

фаза представления
Несмотря на то, что всегда имеется большой соблазн перескочить непосредственно к
проектированию и реализации решения проблемы, во всех случаях (кроме самых про-
стых) следование более строгому планированию проекта поможет обеспечить успеш-
ное развертывание инфраструктуры виртуализации серверов. Информация этой главы
даст вам указания по выявлению специфики той проблемы, которая привела вас к
мысли о виртуализации, и покажет вам те шаги, которые необходимы для формирова-
ния представления о решении по виртуализации серверов, чтобы вы могли успешно
претворить план в жизнь.
Определение фаз
проекта виртуализации серверов
До реализации в производственной среде предприятия решение по виртуализации сер-
веров должно пройти пять проектных фаз.
Представление (Envisioning). Главные цели этой фазы — констатация представле-
ния о проекте, определение проблем, выявление области действия проекта и состав-
ление предварительного бюджета, назначение проектных команд, анализ возврата
инвестиций (ROI), первоначальное определение рисков проекта.
Обнаружение (Discovery). Главные цели этой фазы — ручной или автоматизиро-
ванный сбор информации по оборудованию, программному обеспечению и произ-
водительности существующей инфраструктуры (для следующей фазы проекта —
"Оценка").
Оценка (Assessment). Главная цель этой фазы — выявление физических серверов,
которые соответствуют требованиям, установленным для виртуализации серверов
(на основе собранной на стадии "Обнаружение" информации).
Планирование и проектирование (Planning and design). Главные цели этой фазы —
разработка проекта инфраструктуры серверов Hyper-V; основные компоненты ре-
шения виртуализации; план консолидации рабочих нагрузок серверов; планы раз-
вертывания, управления и эксплуатации.
Пилотная (Pilot). Главная цель этой фазы — тестирование и проверка решения вир-
туализации, которые позволяют подтвердить правильность как проекта, так и пла-
нов по развертыванию, управлению и эксплуатации.
Как видите, каждая фаза проекта имеет вполне конкретную цель и целый набор резуль-
татов. Фаза представления, скорее всего, будет самой короткой в проекте, но в конеч-
ном итоге она окажет большое влияние на успех или неудачу проекта.
Что такое "фаза представления"?

Представление — это первый шаг в успешном проекте виртуализации серверов. Во
время этой фазы первоначальная команда проекта должна сосредоточиться на сле-
дующем: определение представления о проекте; выявление конкретных проблем, кото-
рые нужно решить при помощи виртуализации; достижение согласия относительно
области действия проекта; определение ролей, ответственности и самой команды про-
екта; а также определение рисков проекта. Ваша цель на этой фазе проекта — выдать
набор результатов, который определяет проект, помогает обосновать его, устанавлива-
ет предварительный бюджет по трудозатратам и ресурсам. Эти результаты обычно ста-
новятся основой, на которой проект будет утверждаться и которая позволит ему перей-
ти на следующую фазу.
Фаза представления не занимается разработкой конкретного решения для достижения
целей проекта. Многие проекты заканчиваются неудачей потому, что команда проекта
принимает план решения без определения области действия проекта или проблем, ко-
торые необходимо решить. Обычно это приводит к одному из двух сценариев:
1. Решение недостаточное, он не выполняет всех требований проекта, а повторное
проектирование ведет к увеличению стоимости проекта.
2. Решение слишком тяжеловесное, выделенные деньги расходуются на решение не-
существующих проблем.
В обоих случаях и время, и ресурсы, и деньги используются неэффективно, а решение
не справляется с выполнением требований проекта. Именно команда фазы представле-
ния должна обеспечить тщательное определение движущих факторов проекта и согла-
сование их с приоритетами бизнеса (это должно быть сделано до перехода к решению
проблем). Команда фазы представления должна также убедиться, что проект виртуали-
зации серверов — это наилучшее решение для того набора проблем, который был вы-
явлен во время фазы представления.
Состав команды фазы представления

Команда фазы представления должна состоять из главных управленцев и технических
архитекторов, которые имеют хорошее представление о бизнес-целях и имеют полно-
мочия для запуска и разработки проекта. В конкретном случае проекта виртуализации
серверов членами команды должны быть ответственные спонсоры со стороны управ-
ленцев и архитекторы инфраструктур (серверной, сетевой, управления, эксплуатации).
Глава 19. Проект виртуализации серверов: фаза представления 663
Первые две цели команды фазы представления — определение представления о проек-

те и выработка подробных формулировок проблем, которые в дальнейшем и являются
движущими силами проекта.
Выработка представления
Формулировка представления описывает желательное конечное состояние вашей сре-
ды после завершения проекта. Формулировка представления должна быть краткой —
обычно это одно предложение (она никогда не бывает длиннее двух абзацев). В выра-
ботке формулировки должны участвовать все члены команды, чтобы гарантировать,
что это общее представление и что оно охватывает все намеченные цели. Хорошая
формулировка представления создает доверительные отношения между техническими
членами команды и управленцами-спонсорами. Формулировка представления должна
попытаться дать команде положительную мотивацию и предложить контекст для при-
нятия решений. Вот некоторые примеры формулировок представлений:
принять на вооружение современную технологию виртуализации, которая позволит
бизнесу стать более подвижным, быстрее выводить на рынок новые продукты и
увеличивать доходы;
создать более эффективный центр обработки данных, который обеспечит более вы-
сокую готовность, меньшее потребление электроэнергии, более эффективное ис-
пользование ресурсов (при одновременном снижении капитальных вложений).
Важность мотивации в формулировке представления
Иметь формулировку представления с мотивацией особенно важно в трудных проектах.
Поскольку никогда нельзя предсказать, какой проект станет трудным, то лучше предпола-
гать, что вам понадобится хорошая формулировка представления в каждом проекте.
Не все проекты спасают жизни или решают гуманитарные проблемы, но каждый из них
должен предприниматься по серьезным причинам. Копайте глубже на фазе представления,
чтобы найти эти убедительные бизнес-причины, а затем не пожалейте времени на то, что-
бы акцентировать их таким образом, чтобы они мотивировали членов команды в течение
всего проекта. Текст формулировки должен быть достаточно простым, чтобы он легко за-
поминался, и его можно было часто повторять. Если вы достаточно талантливы для того,
чтобы создать для вашей формулировки некую мантру, то ее можно будет превратить в
фирменный знак проекта и затем использовать на документах проекта, в презентациях,
футболках для членов команды, а также для обозначения помещения для команды проекта.
Цель такова: формулировку представления каждый член команды должен принять как свое
собственное представление. По мере продвижения проекта встречаются препятствия, ко-
торые мешают этому продвижению (такие, как не желающие сотрудничать местные под-
разделения или пассивные противники изменений). Могут также произойти такие организа-
ционные изменения у акционеров, которые понизят срочность или приоритет проекта прямо
в самом его разгаре. В таких обстоятельствах для поддержания концентрации команды и
продвижения вперед у вас не будет почти ничего, кроме этого четкого представления (осо-
бенно в том случае, когда ваша команда рассредоточенная, виртуальная и глобальная).
Если ваша команда начнет проявлять нерешительность, используйте вашу формулировку
представления как инструмент мотивации. Помогите им подняться над тактическими зада-
чами и сосредоточиться на стратегической цели их роли и их значении для успеха проекта.
Когда представление проекта сформулировано, команда фазы представления может со-
средоточиться на определении подробных формулировок проблем. Возможность спроекти-
ровать правильное решение зависит, прежде всего, от четкого определения реальных про-
блем, которые нужно решить для того, чтобы реализовать цели (технические и бизнеса).
Тереза М. Левандовски (Teresa M. Lewandowski, PMP,
Principal Project Manager (Microsoft Consulting Services))
Определение формулировок проблем

Определение тех проблем, которые вы пытаетесь решить при помощи своего проекта
виртуализации серверов, также помогает привнести ясность в представление о проекте
и его области действия. Формулировки проблем должны содержать как технические,
так и бизнес-проблемы, с которыми вы сталкиваетесь в вашей компании. Рассматривая
оба типа проблем, вы гарантируете, что на стадиях представления и проектирования вы
учли все аспекты вашего бизнеса.
Формулировка проблемы должна содержать описание, которое характеризует пробле-
му количественно. Таким образом, вы будете иметь более конкретный критерий, по
которому можно будет измерять эффективность предложенного решения и оценивать
степень решения выявленных проблем. Например, вместо определения проблемы как
"В центре обработки данных наблюдается дефицит места в стойках" следует опреде-
лить измеримый компонент, по которому можно будет оценивать формулировку про-
блемы, такой как "В настоящее время только 10% мест в стойках свободно и готово
принять оборудование для расширения". Если проект виртуализации увеличит это ко-
личество свободного пространства в стойках, то вы уделили данной проблеме опреде-
ленное внимание. Однако для того чтобы понять, реализовали ли вы ожидания, не хва-
тает еще одного компонента — показателя решения. Кроме постановки проблемы вам
нужно установить также и измеримую цель для решения проблемы. Для этого примера
измеримая цель могла бы быть сформулирована как "Увеличение свободного места
в стойках до 25% от общего количества мест".
В табл. 19.1 дана коллекция примеров формулировок технических проблем и проект-
ных показателей.
Таблица 19.1. Формулировки технических проблем
Формулировка проблемы Показатель
Дефицит электропитания — в центре обработ- Увеличить резерв мощности электропитания цен-

ки данных остался резерв в 2% тра обработки данных до 25%
Недостаток места в стойках — в центре обра- Увеличить количество свободного места в стойках
ботки данных осталось только 2000 квадратных центра обработки данных до 20 000 квадратных
футов свободного места в стойках футов
Низкий коэффициент использования серве- Скомбинировать рабочие нагрузки на серверах
ров — среднее его значение составляет 15% таким образом, чтобы повысить средний коэффи-
циент использования серверов до 75%
Совместимость с устаревшими приложения- Виртуализировать рабочие нагрузки, чтобы ликви-
ми — 50% устаревших приложений требуют дировать устаревшее оборудование и контракты
такой операционной системы, которая не по его поддержке
сможет работать на новом оборудовании
(т. е. необходимо продолжать поддерживать
устаревшее оборудование)

Каждый стандартный физический сервер зани- Достичь коэффициента консолидации "гость/хост",
мает 2U пространства стойки равного 16:1 для серверов тестирова-
ния/разработки и 10:1 для производственных сер-
веров (для уменьшения потребности в стоечном
пространстве)
В табл. 19.2 приведена коллекция примеров формулировок бизнес-проблем и показа-

телей.
Таблица 19.2. Формулировки бизнес-проблем
Среднее время приобретения и развертывания Уменьшить требующееся для добавления нового

нового сервера составляет две недели. Такая сервера время до 24 часов
задержка приводит к снижению возврата инве-
стиций
Обеспечение непрерывности бизнеса при Снизить стоимость оборудования для обеспечения
помощи физических серверов по стоимости непрерывности бизнеса до величины не более
оборудования вдвое дороже использования 25% от общей стоимости оборудования (при
виртуальных серверов помощи использования виртуализированных
серверов вместо физических)
Перестройка серверов при тестировании Уменьшить время перестройки серверов для
и разработке требует в среднем двух часов тестирования и разработки до величины не более
(при использовании технологий автоматическо- 10 минут
го развертывания)
Процесс определения формулировок проблем

Для того чтобы содействовать определению формулировок технических проблем для
проекта виртуализации серверов, вы должны запросить данные от разных отделов ин-
формационных технологий (из разных географических районов вашей компании).
Помните, что проблемы могут существовать в любом центре обработки данных или
удаленном офисе, так что не пропустите ни одного подразделения компании. Помните
также, что вы ищете такие проблемы, которые может охватить проект виртуализации.
Еще один источник формулировок проблем — ваши внутренние клиенты. Поговорите
с начальниками ваших бизнес-подразделений и отделов и определите те проблемы
(бизнеса или технические), с которыми они сталкиваются. Обсудите те проблемы,
с которыми сталкиваются в своих средах команды разработчиков или тестировщиков.
Поговорите с командами по эксплуатации, чтобы определить 10 главных проблем,
с которыми они сталкиваются.
Существуют разные способы сбора формулировок проблем. Например, вы можете рас-
сылать сообщения по электронной почте, собирать информацию во время встреч
команд, либо использовать электронные опросы, либо применять все эти методы.
Цель — собрать как можно больше формулировок проблем, чтобы вы были уверены
в том, что решаете ключевые проблемы имеющейся у вас среды.
Назначение приоритетов
После того как вы собрали все формулировки проблем и определили показатели про-
екта, вам нужно определить, какие проблемы следует включить в область действия
планируемого проекта, а какие можно отложить на более позднее время. Для облегче-
ния этой категоризации вам следует определить приоритеты и назначить каждой фор-
мулировке проблемы свой приоритет. Простейший набор приоритетов — это высокий,
нормальный и низкий, но при необходимости вы можете также использовать и более
детальную шкалу. Например, вы можете определить шкалу от 1 (высокий) до 5 (низ-
кий).
По приоритетам формулировок проблем необходимо достичь общего согласия, для
этого следует провести специальное собрание команды фазы представления. Сгруппи-
руйте формулировки проблем по приоритетам от высокого до низкого. Если вы обна-
ружите, что у вас получился длинный список формулировок проблем, то вы можете
использовать эти три (или больше) уровня приоритетов для деления проекта на фазы
(с целью повысить его управляемость).
Для помощи в сборе формулировок проблем на прилагаемом компакт-диске имеется элек-
тронная таблица для Microsoft Office Excel с названием Problem Statement JobAid.xls в ката-
логе Job Aids. Эта электронная таблица имеет одну страницу, которую можно использовать
для сбора информации.
Определение команды проекта

Каждый успешный проект обязан своим успехом той замечательной команде, которая
выполняла свои роли, работая по списку требований проекта. Создание команды про-
екта состоит из определения необходимых ролей проекта и выявления количества не-
обходимых для проекта людей в каждой роли. Кроме того, размер команды должен
быть пропорциональным размеру самой организации и проекта. Поэтому в небольших
организациях, возможно, и не будет необходимости в реализации всех описанных
в этом разделе команд.
После определения требований и области действия можно создавать план проекта (на
фазе планирования), который определяет, когда конкретные роли проекта будут вос-
требованы (по времени проекта). Скорее всего, вы обнаружите, что некоторые роли
в проекте не нужны или один человек может выполнять несколько ролей.
Определение необходимых для проекта команд и ролей

Каждый проект виртуализации серверов не похож на остальные, но обычно в любом
проекте требуется определенный набор проектных команд и командных ролей. Про-
ектные команды и роли отличаются в зависимости от фазы проекта. Как правило, каж-
дому проекту нужен менеджер (на все время проекта). Тестировщик может понадо-
биться только на пилотной фазе проекта, когда решение по виртуализации готово
к тестированию на соответствие требованиям. Однако тестировщик может принимать
участие в ключевых задачах других фаз проекта, чтобы обеспечить учет требований
тестирования.
В табл. 19.3 приведен список рекомендованных проектных команд и описание ролей,
выполняемых каждой командой для успешной реализации проекта по виртуализации
серверов.
Таблица 19.3. Команды проекта
Команда Описание
Руководящий комитет Обеспечивает руководство проектом и интеграцию команд проекта, акцио-

неров и ответственных спонсоров
Команда управления Управляет проектом, графиком проекта, требованиями проекта, бюджетом

проектом проекта, а также информацией о проекте. Управляет также и ожидаемыми
результатами проекта
Команда проектирова- Обеспечивает знание предметной области, управляет спецификациями

ния архитектуры проекта и рисками проекта, определяет и контролирует создание функцио-
нальных возможностей проекта, оценивает время и трудозатраты на
реализацию каждой функции, управляет специалистами по предметной
области
Команда специалистов Предоставляет технических специалистов, а также специалистов по бизне-

по предметным облас- су и приложениям, которые помогают определить требования и специфи-
тям кации проекта, создавать функциональные возможности проекта, а также
определять требования тестирования
Команда Разрабатывает стратегию тестирования, планы и процедуры, управляет

тестировщиков проблемами проекта, проводит тестирование
Команда по Определяет стратегию восстановления после катастроф, тестирует про-

эксплуатации цедуры восстановления после катастроф, определяет эксплуатационные
требования и процедуры управления, обеспечивает обучение по эксплуа-
тации
Команда наблюдения Определяет требования, процедуры и инструменты для наблюдения за

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

Каждая команда проекта имеет целый набор ролей и полномочий. Команды могут от-
личаться по размеру (от одного человека, выполняющего несколько ролей и до коман-
ды из множества людей, где каждому человеку назначена своя роль). Роли команды
могут быть назначены разным людям из вашей или сторонней организации. Главная
задача — найти нужного для выполнения роли человека (это обеспечивает успех про-
екта).
Руководящий комитет
Руководящий комитет — это мост между ответственными спонсорами, акционерами и
командой управления проектом. Руководящий комитет помогает установить область
действия проекта и бюджетные ограничения. Финансовые и бизнес-решения вносятся
в руководящий комитет на проверку и утверждение.
В члены комитета обычно входят: менеджер проекта, менеджер по бюджету, акционе-

ры, а также ответственный спонсор. Несмотря на то, что в начале проекта комитет про-
водит заседания регулярно (обычно раз в неделю), после достижения проектом страте-
гических вех заседания комитета могут проводиться реже (например, один раз
в месяц).
Во время встреч руководящего комитета менеджер проекта сообщает о его состоянии,
состоянии вех проекта, а также о рисках проекта. Менеджер по бюджету дает инфор-
мацию по состоянию бюджета проекта, возврате инвестиций (ROI), а также о потенци-
альной экономии затрат. Акционеры и ответственные спонсоры дают последнюю ин-
формацию по всем бизнес-проблемам, которые могут оказать влияние на проект.
Команда управления проектом

Команда управления проектом управляет всем проектом и является "главным лицом"
проекта. В команде управления есть четыре основных роли:
1. Менеджер проекта.
2. Планировщик проекта.
3. Менеджер по бюджету.
4. Менеджер по информации.
Ключевая роль в команде управления принадлежит менеджеру проекта. Этот человек
несет полную ответственность за своевременное завершение проекта без превышения
его бюджета. Менеджер проекта непосредственно отвечает за управление ожиданиями
(относительно области действия проекта или его требований) со стороны команды
проекта, ответственных спонсоров и клиентов. Эта роль обеспечивает также: предос-
тавление отчетов руководству (по общему состоянию проекта); управление запросами
на изменение области действия; а также согласовывает информацию за пределами
команды проекта. Менеджер проекта также поддерживает систему управления про-
блемами, чтобы проблемы проекта отслеживались и документировались.
Планировщик проекта обслуживает план проекта, предоставляет менеджеру проекта
отчеты о состоянии выполнения стратегических вех, управляет изменениями в рабочих
задачах проекта, а также управляет планированием ресурсов и запросами на них. Пла-
нировщик проекта получает от менеджера проекта утвержденные изменения области
его действия, модифицирует план проекта, а также документирует то влияние, которое
такие изменения могут оказать на план команды. Кроме того, планировщик проекта
отвечает за передачу рабочих задач членам команды и за информацию новых членов
команды об их обязанностях.
Менеджер по бюджету создает и поддерживает бюджет проекта по ресурсам и трудо-
затратам, управляет запросами на оборудование и программное обеспечение, обеспе-
чивает взаимодействие с отделом закупок (для утверждения поступающих по проекту
счетов). Менеджер бюджета участвует в процессе утверждения любых расширений
области действия проекта (чтобы проконтролировать бюджет и получить бюджетное
утверждение перед отправкой этих расширений планировщику проекта).
Менеджер по информации управляет всей информацией по проекту и опросами по
удовлетворенности, а также собирает и распространяет сообщения о проблемах. Эта
роль является единственным источником информации для команды проекта (для по-
вышения эффективности). Менеджер по информации работает с бизнес-подразде-
лениями и конечными пользователями и информирует их о недоступности серверов во
время миграций (на основе согласованного планировщиком проекта расписания).
В крупных проектах менеджер по информации распространяет внутри команды проек-
та результаты опросов удовлетворенности клиентов.
Команда проектирования архитектуры

Команда проектирования архитектуры предоставляет свое знание предметной области
по всему проекту, вырабатывает функциональные спецификации проекта, выявляет
риски проекта, определяет характеристики проекта, превращает функциональные спе-
цификации проекта в список задач, а также вызывает на помощь (при необходимости)
специалистов по приложениям и бизнесу. В команде проектирования архитектуры есть
три основные роли:
1. Ведущий архитектор проекта.
2. Функциональный архитектор.
3. Менеджер по рискам.
Ведущий архитектор проекта участвует в проекте виртуализации с самого начала и до
конца. Обладатель этой роли обеспечивает общее техническое руководство и привле-
кает по мере необходимости функциональных архитекторов и специалистов в пред-
метной области. Ведущий архитектор проекта несет персональную ответственность за
разрабатываемое техническое решение. Ведущие архитекторы определяют также об-
щие требования проекта и его спецификации. Они сводят воедино специфические
функциональные требования и спецификации функциональных архитекторов и спе-
циалистов в предметной области и создают готовые документы по требованиям и
функциональным спецификациям.
Функциональные архитекторы предоставляют знания всех аспектов виртуализации
проекта. В состав функциональных архитекторов входят (как минимум) специалисты в
следующих областях: сеть, серверы, системы хранения, клиенты, безопасность. Эти
архитекторы являются специалистами по данной предметной области внутри компании
и знают реализованную на сегодняшний день архитектуру, а также ее недокументиро-
ванные особенности. Функциональные архитекторы отвечают за разработку функцио-
нальных спецификаций в своей области знаний, за помощь в оценке времени, требуе-
мого для реализации характеристик проекта, за помощь в сборке тестовой и пилотной
среды.
Менеджер по рискам поддерживает процесс управления оценкой рисков во время про-
екта, отслеживает выявленные риски, предоставляет отчеты по состоянию выявленных
рисков, а также закрывает те риски, которые были устранены. В зависимости от слож-
ности проекта, решение по управлению рисками может выглядеть либо как простая
электронная таблица Microsoft Office Excel, либо как более сложная система управле-
ния рисками с автоматической генерацией отчетов о состоянии. Менеджер по рискам
может быть также членом команды управления проектом, чтобы обеспечить информи-
рованность членов команды о тех рисках проекта, которые непосредственно влияют на
график и бюджет проекта.
Команда специалистов по предметным областям

Команда специалистов по предметным областям собирается из специалистов по попа-
дающим в область действия проекта серверам и приложениям. Специалисты по пред-
метной области обладают специфическими знаниями о повседневной работе приложе-
ний, об уникальных конфигурациях серверов, о зависимостях приложений и бизнеса,
о деловых операциях. Эта информация требуется при создании спецификаций, опреде-
лении характеристик проекта, а также при тестировании. Уникальные знания этих чле-
нов команды используются также для определения коэффициентов консолидации сер-
веров, а также для размещения рабочих нагрузок.
Команда тестировщиков
Команда тестировщиков управляет всем, что относится к тестированию плана реализа-
ции проекта виртуализации. Она разрабатывает стратегию тестирования, пишет про-
цедуры тестирования, создает график и планы тестирования, а также выполняет тесты.
В команде тестировщиков имеются три основные роли:
1. Менеджер по тестированию.
2. Инженер по тестированию.
3. Специалист по предметной области.
Менеджер по тестированию контролирует стратегию тестирования, график тестирова-
ния, а также инженеров по тестированию. Основная ответственность менеджера по
тестированию — обеспечить минимальное влияние методики тестирования на график
тестирования.
Выбор менеджера по тестированию является ключевым вопросом
Менеджер по тестированию — это одна из самых важных ролей, которую надо правильно
заполнить для того, чтобы обеспечить успех проекта. Вам понадобится сильная и позитив-
но настроенная личность для того, чтобы отбивать такие изменения графика, которые
уменьшают время тестирования в угоду соблюдения графиков пилотной фазы и фазы раз-
вертывания. Менеджер по тестированию должен также учитывать вашу команду проекти-
рования архитектуры и ваших специалистов в предметных областях, чтобы обеспечить ка-
чество вашего подхода к миграции. Несмотря на то, что команда тестировщиков не имеет
полного состава до самых поздних стадий проекта, вы снизите свои риски, если у вас будет
опытный менеджер по тестированию уже на стадии представления для определения тре-
буемых для тестовой среды оборудования и ресурсов и на стадии планирования и проек-
тирования для определения подробного плана тестирования. Если менеджер по тестиро-
ванию имеется не на всех фазах проекта, то за него должен работать менеджер проекта,
который будет отстаивать важность задач тестирования в его отсутствие.
Инженеры по тестированию отвечают за создание тестовых процедур, построение тес-

товой среды, а также за выполнение задач тестирования. Специалисты по предметной
области отвечают за тестирование тех приложений, которые требуют уникальной ква-
лификации (в области бизнеса или технической). Этот уровень тестирования миними-
зирует специфичные для приложений проблемы.
Команда по эксплуатации
Команда по эксплуатации занимается стратегией эксплуатации после развертывания
новой инфраструктуры виртуализации. Некоторые думают, что управление группой
виртуальных машин будет таким же, как управление физическими машинами. Однако
управление виртуальными машинами должно учитывать эффект дополнительных зави-
симостей, которые отсутствуют при управлении отдельными физическими машинами.
Например, физический сервер можно обновить и перезагрузить с минимальным влия-
нием на другие физические машины. При работе на сервере Hyper-V множества рабо-
чих нагрузок любое обновление, которое потребует перезагрузки гипервизора Windows
или родительского раздела, затронет все работающие в дочерних разделах этого серве-
ра виртуальные машины. Поэтому управление фермами серверов и их эксплуатация
являются критическими областями, которые требуют должного планирования и устра-
нения рисков.
В команде по эксплуатации/управления есть три основные роли:
1. Менеджер по эксплуатации.
2. Инженер по эксплуатации.
3. Менеджер по обучению.
Менеджер по эксплуатации контролирует всю команду эксплуатации, определяет стра-
тегии эксплуатации и восстановления после катастроф, определяет требования управ-
ления, а также помогает при создании плана восстановления после катастроф. Инжене-
ры по эксплуатации отвечают за определение, создание и тестирование планов и про-
цедур по эксплуатации и восстановлению после катастроф. Менеджер по обучению
определяет и организует обучение членов команды эксплуатации по новым технологи-
ям виртуализации.
Команда наблюдения
Команда наблюдения отвечает за определение требований, процедур, а также инстру-
ментов для наблюдения за новой инфраструктурой виртуализации. Команда наблюде-
ния тесно работает с командой по проектированию архитектуры и командой по экс-
плуатации (чтобы гарантировать, что все новые инструменты для наблюдения за новой
инфраструктурой виртуализации можно интегрировать в существующую среду наблю-
дения). Все вместе они работают над определением подходящих компонентов наблю-
дения, правил, триггеров и сигналов тревоги, над разработкой любого специального
кода, а также и над любыми процедурами автоматического восстановления после
проблем, над процедурами рабочих процессов проблем, а также над генерированием
отчетов.
В команде наблюдения есть две основные роли:
1. Менеджер по наблюдению.
2. Инженер по наблюдению.
Менеджер по наблюдению контролирует команду наблюдения и отвечает за общую
систему наблюдения. Инженеры по наблюдению отвечают за определение, создание и
тестирование конфигурации, процедур и выдачи отчетов системы наблюдения.
Описанные в этом разделе команды будут иметь разный размер (в зависимости от мас-
штаба проекта). Некоторые члены команд могут выполнять по нескольку ролей, а другие
члены команд могут быть временными. Лучшие практики требуют того, чтобы обязанности
архитектурной команды и команды тестирования не совмещались. Это позволит команде
тестирования дать независимую и непредвзятую оценку технического решения.
Определение области действия проекта

Четкая область действия проекта — это точка отсчета для формулировок тех проблем,
которые будут решаться в проекте. Проблемы, которые не войдут в область действия
проекта, могут решаться в следующем проекте, либо могут быть отложены на какое-то
время. Обычно это называется определением того, что находится в области действия и
вне области действия проекта. Четкий контроль над областью действия проекта очень
важен, поскольку каждый раз, когда вы добавляете элемент в список области действия,
вы потенциально увеличиваете бюджет проекта и добавляете в график проекта новые
задачи. Если же какой-то элемент выходит из области действия, то вы потенциально
снижаете возврат инвестиций и не решаете какую-то проблему вашей среды. Опреде-
ление области действия проекта является балансом между созданием управляемого
проекта с высокой вероятностью успеха и минимизацией отложенных проблем.
Определение области действия проекта — это трехшаговый процесс. Первый шаг —
определить, какие из собранных формулировок проблем будут решаться в проекте.
Второй шаг — откладывание (или ликвидация) формулировок проблем и определение
ограничений проекта, которые могут быть основаны на бюджете, технических вопро-
сах, наличии ресурсов, сроках, бизнес-потребностях и т. д. И наконец, третий шаг —
определить, потребует ли область действия проекта реализации в несколько фаз.
Что входит в область действия?

Для того чтобы четко определить область действия проекта, формулировки проблем
должны быть достаточно подробными для того, чтобы сделать возможной разработку
целей проекта. Например, формулировка "Осталось только 2000 квадратных футов
свободного места на стойках центра обработки данных" не содержит в себе никаких
сведений насчет того, идет ли речь об одном или нескольких центрах обработки дан-
ных, какой именно центр имеет это свободное пространство, а также не дает никакой
информации, которая определяет цели центра обработки данных. Вот модифицирован-
ная формулировка, которая позволяет сделать определение области действия проекта:
"Существующие физические серверы центра обработки данных в Хьюстоне будут про-
анализированы, чтобы определить количество кандидатов на виртуализацию и количе-
ство пространства серверных стоек, которое будет освобождено для обеспечения сер-
верами дополнительных проектов". Эта более подробная формулировка проблемы обо-
значает в качестве цели центр обработки данных Хьюстона; указывает, что при
помощи виртуализации требуется произвести освобождение пространства на сервер-
ных стойках; а также определяет, что количество освобожденного пространства будет
измерителем успешности проекта. Уточнение формулировки проблемы можно было
бы продолжить, включив в нее конкретное количество освобождаемого пространства
стоек, что дало бы более точный показатель для определения области действия про-
екта.
Что не вошло в область действия проекта?

Для создания успешного плана проекта важно также определить все то, что не входит в
область его действия. Определение на ранних стадиях планирования проекта тех эле-
ментов, которые не входят в область его действия, позволяет вам уточнить допущения
и прояснить те цели, на которых сосредоточится команда проекта. Важной составляю-
щей успеха проекта является предотвращение расползания области действия (это тен-
денция добавления в проект не имеющих к нему прямого отношения проблем, которые
могут поставить под угрозу график проекта, его бюджет, а также своевременное его
завершение). Определение не входящих в область действия элементов может выпол-
няться на основе различных факторов, и в том числе:
исключения по рабочим нагрузкам сервера;
исключения по приложениям;
исключения по операционным системам;
исключения по оборудованию;
географические исключения;
бизнес-исключения, основанные на юридических вопросах либо планируемых
слияниях и приобретениях;
исключения по времени тестирования.
Несмотря на то, что конкретное определение исключений из области действия помога-
ет сократить объем вашего проекта виртуализации серверов, вы должны также четко
указать в своих материалах, что не включенные в область действия проекта элементы
считаются находящимися вне области его действия.
И НФОРМАЦИЯ НЕПОСРЕДСТВЕННО ИЗ ПЕРВОИСТОЧНИКА

Контрольная проверка списка находящихся вне области действия
элементов
Определение того, что не входит в область действия, не менее важно, чем определение то-
го, что входит в область действия. Обратите большое внимание на составление исчерпы-
вающего списка всего, что считается находящимся вне области действия, а затем сделайте
контрольную проверку этого списка вместе с акционерами вашего проекта. Явно укажите,
что все то, что отсутствует в списке области действия, по умолчанию находится вне ее.
Наличие согласия спонсора вашего проекта и вашего ответственного спонсора — это толь-
ко часть задачи. Вы можете встретить несогласие или недостаток понимания со стороны
других акционеров относительно того, что именно проект должен выполнить в контроли-
руемой ими области. Причиной этого могут быть их предположения, их технические знания,
либо виденная ими ранее презентация (если они участвовали в процессе выбора проекта).
Используйте ваш список "Вне области действия" для того, чтобы собрать за столом всех
акционеров для достижения (с участием спонсоров проекта) согласия всех сторон. Помни-
те, что не менее важным элементом определения области действия являются "Условия
приемки", которые проясняют те условия, на которых клиент будет принимать решение. Это
послужит в последующем минимизации любых политических стычек и поможет вашей про-
ектной команде оправдать ожидания акционеров.
Определение фаз проекта

Многие проекты виртуализации серверов имеют несколько фаз реализации. Например,
развертывание и миграция серверов центра обработки данных должна быть завершена
в отдельной фазе от развертывания и миграции серверов филиалов. Несмотря на то,
что конечные цели одинаковы, скорее всего, для каждой из этих фаз потребуется от-
дельное планирование и свои задачи по решению проблем или устранению специфич-
ных для этих сред ограничений. Определение фаз проекта поможет вам также снизить
общую сложность проекта. Вот несколько примеров тех областей, которые необходимо
рассмотреть при определении фаз проекта.
Сначала занимайтесь тем, что проще всего. На ранней фазе можно виртуализиро-
вать те серверы, которые можно мигрировать быстро и с минимальным планирова-
нием.
Повторное использование оборудования. Если вы собираетесь повторно использо-
вать оборудование, то должны выделить фазу, которая включает миграцию подле-
жащих повторному развертыванию серверов и последующую фазу миграции тех
серверов, которые будут работать на повторно развернутом оборудовании.
Не более одного служебного подразделения одновременно. Для уменьшения про-
блем по поддержке и минимизации количества подразделений, которые будут за-
тронуты в случае возникновения проблем при развертывании, следует выделить от-
дельную фазу для миграции каждого подразделения.
География. Может случиться так, что ограниченность ресурсов, сроки региональ-
ных проектов и другие факторы заставят вас определить в проекте и географиче-
ские фазы.
Есть еще много прочих областей, которые вы могли бы учесть (это зависит от деталей
вашего проекта и особенностей вашей среды). Важно понять, что вам следует на ран-
ней стадии выявить движущие факторы вашей среды для того, чтобы понять те задачи,
с которыми вы столкнетесь, а также составить план проекта с грамотно выделенными
фазами.
Выполнение анализа возврата инвестиций

Во время фазы представления вы должны сделать также и предварительный анализ
возврата инвестиций (ROI), что поможет вам при обосновании затрат на проект. Для
того чтобы такой анализ дал полезные результаты, он должен учесть множество пере-
менных величин, таких как текущая стоимость инфраструктуры и эксплуатации, тех-
нологические решения, специфичные для предприятия показатели, прогнозы роста
и т. д. Главные области окупаемости, которые, вероятно, будут интересовать вас с са-
мого начала проекта виртуализации серверов, включают снижение эксплуатационных
затрат, снижение совокупной стоимости владения (TCO), улучшение обслуживания,
уменьшение времени запуска новых бизнес-процессов.
Если у вас нет своего местного способа проведения анализа ROI, то вы можете скачать
бесплатные инструменты вроде Windows Integrated Virtualization ROI (разработан ком-
панией Alinean). Если у вас не хватает опыта по вашей среде для выполнения анализа
ROI, привлеките знающих консультантов для обучения вас или для помощи вам в вы-
полнении быстрого предварительного анализа, который можно будет затем уточнить
во время проекта. Важно, чтобы вы задокументировали весь ваш анализ (включая все
ваши предположения и их источники), а не только его результаты.
Инструмент Integrated Virtualization ROI Tool компании Microsoft
Инструмент Integrated Virtualization ROI Tool компании Microsoft был разработан компанией
Alinean, являющейся ведущим специалистом в области IT Value Management и анализа
ROI/TCO. Сегодня, как никогда раньше, директорам по информационным технологиям и ру-
ководителям по ИТ надо доказывать необходимость для бизнеса расходов на ИТ. Несмот-
ря на то, что исследования показывают, что более 90% всех закупок по ИТ требуют состав-
ления бизнес-плана по ROI для их обоснования, многие компании не могут сами быстро
разработать такие бизнес-планы для планируемых ими проектов.
Для решения таких задач компания Alinean разработала чрезвычайно надежные инстру-
менты анализа ROI/TCO, оценку эффективности по результатам конкурентной разведки, а
также лучшие практики. Предлагаемые исключительно через независимых консультантов и
поставщиков решений по ИТ инструменты и исследования компании Alinean дают ценные
указания и независимую проверку и, что важнее всего, помогают ИТ-профессионалам соз-
давать надежные бизнес-планы для важнейших инвестиционных решений.
Еще одной ключевой проблемой ИТ сегодня является то, что обычные эксплуатационные
расходы съедают чересчур большую часть годового бюджета. Это оставляет слишком мало
средств для инновационных вложений, которые могут дать бизнесу возможность по-
настоящему изменить правила игры. Для того чтобы решить проблему недостатка средств
на инновационные вложения, в центрах обработки данных внедряется виртуализация сер-
веров (как путь снижения эксплуатационных расходов и экономии бюджета для инноваци-
онных целей).
Возможность виртуализации
Известно, что серверы центров обработки данных используются недостаточно. Большая
часть серверов никогда не работает на близкой к пиковой мощности. Исследования пока-
зали, что в течение 24-часового периода используется менее 10% вычислительной мощно-
сти типового сервера х86/х64. Виртуализация позволяет вам консолидировать серверы,
увеличивать коэффициент их использования и повышать управляемость. Это может дать
существенные сокращения расходов и преимущества, в том числе:
• снижение стоимости серверов, систем хранения и сетей;
• снижение затрат на дорожающие электроэнергию, охлаждение и помещения;
• повышение производительности ИТ;
• снижение бизнес-рисков;
• повышение подвижности бизнеса.
Сколько стоит сервер центра обработки данных?

Типичная стоимость двухпроцессорного сервера составляет в среднем 9000 долларов в год
(суммарных прямых затрат), что предоставляет существенные возможности для экономии.
Бизнес-план виртуализации серверов

Компания Alinean считает, что реализация виртуализации серверов может помочь решить
проблему растущей стоимости владения следующими способами.
• Консолидация рабочих нагрузок серверов (обычно в диапазоне от 8:1 до 15:1), что при-
водит к:
переназначению или выводу из эксплуатации существующих серверов и ликвидации
расходов на их обслуживание и поддержку;
отсутствию необходимости добавления серверов для поддержки расширений в бу-

дущем (или добавлению меньшего их количества);
ликвидации не только серверов, но также и сопутствующих расходов на системы
хранения и сети (дисковые контроллеры, сетевые адаптеры, а также инфраструкту-
ра сетевых коммутаторов);
снижению расходов на дорожающие электроэнергию и аренду площадей центров
обработки данных.
• Сокращение времени подготовки сервера с виртуальной средой до 1,5 часов (сокраще-
ние на 92% и более).
• Снижение нагрузки по администрированию сервера на 60—90% (по сравнению с ны-
нешним уровнем).
Помимо прямой экономии виртуализация серверов может дать и другие дополнительные
преимущества, в том числе повышение устойчивости бизнеса, снижение времени/рисков
восстановления после катастроф, а также повышение готовности на 80%.
Инструмент Windows Integrated Virtualization ROI Tool помогает партнерам и клиентам
определить преимущества консолидации и выигрыш в стоимости ТСО от применения
Microsoft Integrated Virtualization как ключевого компонента перехода к Dynamic Core
Infrastructure Optimization. Этот инструмент собирает информацию о текущем производст-
венном сервере, лаборатории разработки (или контроля качества), возможностях виртуа-
лизации рабочего стола и приложений, а также по отраслевым показателям. Затем он ис-
пользует данные и результаты исследований компании Alinean для планирования потенци-
альной экономии, преимуществ по уровню обслуживания и подвижности бизнеса, расходов,
а также ROI (для реализации различных стратегий оптимизации при помощи решений
Microsoft Integrated Virtualization). Все исследования были получены из базы данных Value
Base of IT spending metrics компании Alinean и от специалистов по продуктам и ценам из
компании Microsoft, чтобы они отражали типичные расходы и экономию для аналогичных по
размерам и типам компаний.
Профессиональная возможность выдачи отчета по бизнес-плану инструмента компании
Alinean поможет вам в следующих вопросах:
• обоснование всех планируемых капиталовложений;
• улучшение сотрудничества с подразделениями компании по принятию решений относи-
тельно капиталовложений в ИТ;
• упрощение анализа ROI, анализа TCO и бюджетных процессов (более чем на 40%);
• принятие лучших инвестиционных решений, чтобы ваше предприятие могло делать
больше меньшими средствами;
• подтверждение и повышение значения ИТ для организации.
Инструмент Microsoft Integrated Virtualization ROI Tool можно использовать на фазе пред-
ставления и обоснования для создания подробного отчета по анализу ROI (в программах
Microsoft Office PowerPoint или Microsoft Office Word), который займет у вас всего полчаса
времени. Вы можете найти этот важнейший инструмент планирования по адресу:
http://www.microsoft.com/virtualization/ROItool.
Том Писелло (Tom Pisello, CEO (Alinean))
Выявление рисков
Рисков избежать нельзя, но их можно уменьшить. Однако до уменьшения риска вы
должны выявить его, присвоить ему вероятность и влияние, а также документировать
его. После того как вы поняли этот риск, вы можете разработать подход по уменьше-
нию риска. Выявление рисков — это командный процесс, поэтому все члены команды
фазы представления должны прийти на мозговой штурм по выявлению рисков. Цель
мозгового штурма — выявление всех рисков, которые могут оказать влияние на проект
виртуализации. Вы должны собрать как технические, так и бизнес-риски (чтобы гаран-
тировать, что вы выявили максимально возможное число потенциальных рисков для
проекта). Например, технические риски должны включать риск ресурсов, риск проек-
тирования, риск решения, а также риск предположения. Бизнес-риски включают бюд-
жетный риск, риск графика проекта, риск персонала, а также другие нетехнические
риски. Вот примеры наиболее часто встречающихся во многих проектах рисков.
Изменение области действия. Изменения области действия влияют на график про-
екта и его бюджет.
Потеря ключевых членов проектной команды. Члены команды проекта могут быть
переведены на другие проекты, поменять должность внутри компании, либо вовсе
покинуть компанию в поисках новой работы.
Плохая информированность. Плохой обмен информацией между членами команды
проекта, а также между командой и акционерами (находящимися вне проекта) мо-
жет увеличить возможность возникновения неверных предположений и недорабо-
ток проекта, что приведет к отсутствию удовлетворенности у клиентов.
Влияние на безопасность. Сетевая безопасность (блокированные порты на маршру-
тизаторах и сетевых экранах) может оказать влияние на автоматическое обнаруже-
ние и инвентаризацию серверов, что приведет к тому, что некоторые серверы нужно
будет инвентаризировать вручную.
Изменения финансирования. Изменения финансирования в сторону его уменьшения
могут повлиять на область действия и возврат инвестиций проекта.
Следующий список дает некоторые примеры часто встречающихся рисков, специфич-
ных для проектов виртуализации.
Изменения в процессах эксплуатации. Виртуализация потребует изменений сущест-
вующих процессов и может повысить стоимость эксплуатации.
Синдром "моего сервера". Подразделения отказываются комбинировать свои серве-
ры с серверами других подразделений, что снижает значение коэффициента консо-
лидации.
Возвратный платеж. Не удается достичь соглашения о модели возвратных пла-
тежей подразделений, что ведет к затягиванию развертывания решения виртуализа-
ции.
Плохое планирование консолидации. При планировании консолидации не была за-
фиксирована начальная точка отсчета (производительность серверного оборудова-
ния), что привело к перегрузке серверного оборудования (поскольку вместо реаль-
ных данных по производительности были использованы неточные теоретические
показатели производительности).
В табл. 19.4 дан список атрибутов, которые следует собрать для каждого документи-
руемого вами риска.
Таблица 19.4. Атрибуты риска
Атрибут Описание
Идентификатор Числовое значение, которое уникально идентифицирует риск

риска
Вероятность Вероятность того, что риск случится, указанная как числовое значение от 1
до 100, где 1 соответствует самой низкой, а 100 — самой высокой вероятности
Описание Описание риска
Последствия Результат риска. Это технические, финансовые и бизнес-последствия
План уменьше- Описание того, как уменьшить или ликвидировать влияние риска на проект
ния
Влияние Воздействие риска. Влияние указывается как числовое значение от 1 до 10,
где 1 — это минимальное, а 10 — максимальное влияние
Владелец Владелец риска и плана уменьшения риска
Для помощи в сборе и отслеживании рисков на прилагающемся компакт-диске в каталоге
Job Aids вы найдете электронную таблицу MS Excel с названием Risk Management
JobAid.xls. Эта таблица имеет всего одну страницу со столбцами для сбора рекомендован-
ных атрибутов рисков.
Ранжирование рисков
После выявления рисков их следует отранжировать (для того, чтобы определить их уро-
вень важности для проекта). Для этого вы берете присвоенную вами риску вероятность
(от 1 до 100) и умножаете ее на влияние (от 1 до 10). Это дает вам число в диапазоне от 1
до 1000. Теперь по этому рейтингу вы можете определить последовательность ваших уси-
лий по уменьшению рисков.
Майк Вильямс (Mike Williams, Senior Consultant (Microsoft Consulting Services))
Создание бюджета проекта

После определения области действия проекта, проведения анализа ROI и выявления
рисков проекта вы можете выработать предварительный бюджет проекта для следую-
щих двух его фаз: обнаружения и оценки. Данные этих двух фаз потребуются для раз-
работки подробного бюджета проекта и его графика. Предварительный бюджет проек-
та содержит следующие позиции:
бюджет трудозатрат для фаз обнаружения и оценки;
бюджет по аппаратному и программному обеспечению, которое требуется для вы-
полнения обнаружения и оценки.
Бюджет трудозатрат должен включать в себя финансирование менеджера проекта, ве-
дущего архитектора, планировщика проекта, менеджера по бюджету, а также функ-
ционального архитектора. Бюджет по аппаратному и программному обеспечению дол-
жен предусматривать финансирование: одного или нескольких физических серверов
(с необходимыми спецификациями) для выполнения задач обнаружения, программных

инструментов для обнаружения, лицензий на серверные операционные системы, соот-
ветствующих лицензий клиентского доступа (client access licenses, CAL), а также (воз-
можно) лицензии на базу данных для хранения собранных данных.
Резюме
Данная глава дала обзор первой фазы проекта виртуализации серверов — фазы пред-
ставления. Представление — это не разработка решения виртуализации серверов; это
формирование понимания имеющейся среды и существующих в ней проблем, которые
можно было бы решить при помощи решения по виртуализации серверов. Главные
задачи фазы представления — это разработка списка проблем и назначение их приори-
тетов; формирование команды проекта; определение тех проблем, которые входят в
область действия проекта, и тех, которые в нее не входят; выполнение предварительно-
го анализа ROI; выявление и ранжирование рисков проекта; а также определение пред-
варительного бюджета для выполнения стадий обнаружения и оценки.

Microsoft Solution Framework, ресурс доступен по ссылке:
http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx;
инструмент Microsoft Integrated Virtualization ROI Tool, доступный по ссылке:
http://www.microsoft.com/virtualization/ROItool/default.mspx.
ГЛАВА 20

фаза обнаружения
Во время фазы обнаружения проекта виртуализации серверов вы должны сосредото-
читься на сборе всей необходимой для определения остальных фаз проекта информа-
ции. Если вы последуете обсуждавшимся в главе 19 рекомендациям, то будете иметь
утвержденную область действия проекта, которая определяет включенные в него гео-
графические регионы или подразделения, типы серверов, для которых нужны данные
обнаружения, а также те типы серверов, которые исключены из рассмотрения. После
этого команда проектирования архитектуры или эксперты по предметным областям
могут использовать эту информацию для того, чтобы выполнить сбор данных обнару-
жения.
Во время фазы обнаружения вы будете собирать информацию в два этапа. Первый
этап — сбор данных о лесе и доменах Active Directory вашей среды (и в том числе дан-
ных по соответствию подсетей физическим площадкам). После сбора этой информации
вы сможете перейти ко второму шагу, который состоит из сбора (для каждого сервера)
следующей информации:
инвентаризация аппаратного и программного обеспечения;
показатели производительности;
информация о среде.
Эта информация используется на стадии оценки проекта для выявления серверов-
кандидатов на виртуализацию, группирования кандидатов по предварительно опреде-
ленным параметрам (приложение, местоположение, атрибуты оборудования и т. д.),
для принятия решения о наилучшем сочетании рабочих нагрузок, а также для подго-
товки отчета с подробностями относительно экономии расходов на стоечное простран-
ство, электроэнергию и охлаждение.
В этой главе вы узнаете о том, какую информацию вам нужно собрать для того, чтобы
обеспечить успех последующих фаз проекта. В конце этой главы есть разд. "Авто-
матизация процесса обнаружения", где описаны инструменты, имеющиеся на прило-
женном к книге компакт-диске, на сайте Microsoft, а также у других независимых по-
ставщиков программного обеспечения (independent software vendors, ISV), которые
можно использовать для автоматизации процесса обнаружения.
Сбор информации,
которая послужит точкой отсчета
Сбор данных с серверов Windows обычно выполняется удаленно. Для этого исполь-
зуемый инструмент должен иметь соответствующие учетные данные (обычно это учет-
ная запись, которая является членом группы локальных администраторов сервера). При
наличии соответствующих учетных данных вы можете также собрать информацию по
инвентаризации и по производительности сервера.
Отслеживание учетных данных
Для сбора информации обнаружения лучше создать отдельную учетную запись. Разверни-
те эти учетные данные на всех серверах, а потом деактивируйте или удалите их по завер-
шении процесса. Это позволит вам отслеживать по журналам любую активность или по-
пытки доступа к процессу обнаружения.
Дэвид Зиембики (David Ziembicki, Senior Consultant (Microsoft Consulting Services))
Информация по лесу Active Directory

Несмотря на то, что вы можете указать (для сбора информации инвентаризации) учет-
ную запись локального администратора сервера, лучше использовать для этой цели
учетную запись домена. Для того чтобы определить, какую доменную учетную запись
использовать и можно ли использовать одну запись для всех доменов или лесов, вам
нужно знать структуру леса и доменов Active Directory вашей среды.
При сборе информации по лесу Active Directory вам следует включить в нее название
леса, названия содержащихся в нем доменов, а также существующие между лесами и
доменами доверительные отношения. Это позволит вам создать карту инфраструктуры
леса Active Directory и доверительных отношений, чтобы вы могли определить мини-
мальное количество учетных записей, которые потребуются для получения данных по
серверам.
По умолчанию группа администраторов домена является членом группы локальных адми-
нистраторов каждого находящегося в домене сервера. Однако в некоторых ситуациях ло-
кальный администратор сервера может удалить группу администраторов домена из группы
локальных администраторов. Если вы встретитесь с такой конфигурацией, используйте в
групповой политике серверов скрипт запуска компьютера для добавления группы админи-
страторов домена в группу локальных администраторов.
Сбор информации о местоположении

Во время фазы планирования и проектирования вы определяете стратегию консолида-
ции (какие серверы будут мигрировать на один сервер Hyper-V на каждой площадке).
Для этого вам нужно создать список площадок, а также развернутых в них подсетей.
Это позволит вам собрать данные инвентаризации серверов по площадкам и группам
консолидации серверов.
Глава 20. Проект виртуализации серверов: фаза обнаружения 683
После того как вы соберете информацию по подсетям и их маскам для каждой пло-
щадки, создайте сводную таблицу с этой информацией. В табл. 20.1 дан пример такой
таблицы.
Таблица 20.1. Информация по площадкам
Площадка Подсети Маска подсети
Хьюстон 10.10.10.0 255.255.255.0

10.10.11.0 255.255.255.0
Атланта 10.10.100.0 255.255.255.0
Лондон 10.10.200.0 255.255.255.0
Есть два стандартных способа получения этой информации: можно либо получить ее
у вашей команды сетевиков, либо использовать информацию из Active Directory. Коман-
да сетевиков имеет либо карту сети, на которой показаны площадки и соответствую-
щие сети, либо таблицу с этой информацией. Информация из Active Directory Site по-
лезна в том случае, когда информация по соответствию площадок и сетей находится в
актуальном состоянии. Обычно организации используют такие названия площадок,
которые соответствуют их физическому местонахождению. Вы можете получить дан-
ные по местоположению площадок и всех их подсетей из Active Directory. Эту инфор-
мацию можно получить при помощи консоли Active Directory Sites And Services для
Microsoft Management Console (MMC) или при помощи скрипта. Однако Active
Directory Sites And Services собирает информацию только по находящимся на площад-
ке контроллерам доменов, а не по всем развернутым на данной площадке серверам.
Если сервер или клиентский компьютер находится в подсети, которая не была внесена
в Active Directory Sites And Services, то этот компьютер будет помещен во встроенный кон-
тейнер с названием Default First Site. Когда вы запрашиваете из Active Directory информа-
цию по площадке для каждого сервера, то должны убедиться, что серверы не попали в кон-
тейнер Default First Site.
Сбор информации инвентаризации

Для определения набора тех серверов, которые являются хорошими кандидатами на
виртуализацию, вы должны собрать определенную информацию по аппаратному и
программному обеспечению каждого сервера. По оборудованию вам нужно собрать
следующую информацию: тип процессора, конфигурация памяти, количество и тип
сетевых адаптеров, подробности по дисковой подсистеме, устройства USB, последова-
тельный и параллельный порты. По программному обеспечению вам нужно собрать:
список инсталлированных приложений, а также и всех обновлений, исправлений и
сервисных пакетов. Кроме того, вам нужно проинвентаризировать все работающие на
сервере службы. Вы будете использовать эту информацию и набор правил (пределов),
описанных в главе 21, для определения тех физических серверов, которые можно будет
мигрировать на виртуальные машины (работающие на серверах Hyper-V).
Инвентаризация аппаратного обеспечения

В табл. 20.2 представлен подробный список аппаратных устройств и тех настроек, ко-
торые вам следует собрать во время инвентаризации оборудования серверов. Главные
категории — это BIOS, операционная система, процессор, память, система хранения,
сетевой адаптер, подключенные к USB съемные устройства, а также подключенные к
последовательному или параллельному порту устройства. Эта информация использует-
ся в основном для составления списка тех серверов, которые будут исключены из чис-
ла кандидатов на виртуализацию.
Информация BIOS вам нужна для определения изготовителя и модели сервера. Вы бу-
дете использовать эту информацию позже в процессе сбора информации о среде, такой
как количество единиц высоты для сервера (а также о его энергопотреблении и тепло-
отдаче).
Информацию об операционной системе вы будете использовать для группирования
кандидатов на виртуализацию по версии операционной системы и версии сервисного
пакета. Вы можете также использовать ее как проверку опубликованной в Active
Directory версии операционной системы. Кроме того, сбор информации по домену и
имени сервера даст вам дополнительные уникальные значения, которые вам понадо-
бятся для объединения данных.
Таблица 20.2. Рекомендуемая для сбора при инвентаризации оборудования информация
Категория оборудования Информация инвентаризации

BIOS • Изготовитель сервера
• Номер модели
• Серийный номер
Операционная система • Операционная система
• Сервисный пакет
• Домен
• Имя сервера
• Обновления
Процессор • Изготовитель процессора (Intel, AMD)
• Модель процессора (Pentium 4, Opteron)
• Скорость процессора (в МГц)
• Количество процессоров
• Количество ядер
Память • Количество физической памяти
• Общее количество разъемов памяти*
• Емкость модулей памяти*
• Количество свободных разъемов памяти*
Категория оборудования Информация инвентаризации

Система хранения • Количество жестких дисков
• Объем каждого диска
• Тип файловой системы (FAT, NTFS)
• Разделы
• Базовый или динамический диск

• Состояние (оперативное или автономное)
Сетевой адаптер • Количество адаптеров
• Максимальная скорость каждого адаптера

• Текущая скорость каждого адаптера
• Изготовитель
• Особые конфигурации (совместная работа, VLAN)

• Сетевые настройки для каждой карты:
адрес IP;
маска подсети;
МАС-адрес
Устройства USB Все подключенные к USB устройства
Устройства на параллель- Все подключенные к параллельным портам устройства
ных портах
Устройства на последова- Все подключенные к последовательным портам устройства
тельных портах
* Необязательная информация.
Информация по процессорам собирается для того, чтобы понимать, как данный сервер
выглядит по сравнению с возможностями виртуальной машины Hyper-V. Для сравне-
ния нужна такая информация: количество процессоров (гнезд), количество процессор-
ных ядер, частота процессора в мегагерцах. Информация по изготовителю процессора
и его модели вам понадобится в том случае, если данный сервер будет повторно ис-
пользован в качестве сервера Hyper-V и ему потребуются дополнительные процессоры.
Изготовитель и номер модели также важны для того, чтобы выявить неподдерживае-
мые процессоры (например, Intel Itanium).
Информация о памяти нужна для того, чтобы понять, не превышает ли количество па-
мяти на физическом сервере предельного значения для виртуальной машины Hyper-V
(64 Гбайт). Вы можете также собрать необязательную информацию по количеству сво-
бодных разъемов памяти и по емкости используемых модулей памяти. Вы будете ис-
пользовать эту информацию для определения максимального количества памяти, кото-
рое можно поставить на данный сервер. Информация по памяти полезна для выявления
возможностей расширения памяти на тот случай, если этот сервер является кандидатом
на повторное использование в качестве сервера Hyper-V, но ему нужна дополнительная

память.
Информация по системам хранения понадобится вам для того, чтобы понять потребно-
сти в дисковом пространстве и проблемы, с которыми вы можете столкнуться при вы-
полнении миграции с физического сервера на виртуальную машину. Виртуальный же-
сткий диск с интерфейсом IDE на сервере Hyper-V ограничен размером 127 Гбайт, а
виртуальный жесткий диск с интерфейсом SCSI — размером 2,04 Тбайт. Сбор инфор-
мации по количеству дисков физического сервера и их размерам позволит вам опреде-
лить, не возникнет ли превышение этих предельных значений. Сбор информации по
разделам, типам файловых систем, состоянию активности (а также динамический диск
или нет) поможет вам разобраться в проблемах миграции физических машин на вирту-
альные (P2V). Например, многие инструменты P2V поддерживают миграцию базовых
дисков, но некоторые из них не поддерживают миграцию динамических дисков.
Вам нужно также собрать информацию по сетевым адаптерам, чтобы сравнить имею-
щуюся конфигурацию сетевых адаптеров сервера с возможностями виртуальной ма-
шины сервера Hyper-V. Виртуальные машины могут иметь одновременно максимум
восемь синтетических и четыре обычных сетевых адаптера Ethernet, причем они не
поддерживают расширенные функции (такие, как командная работа). Физические сете-
вые адаптеры Ethernet могут поддерживать несколько скоростей (10/100/1000/
10 000 Мбит/с). Вы можете установить на адаптере конкретную скорость или настро-
ить автоматическое согласование скорости. Вам нужно зафиксировать, на какую ско-
рость в настоящее время настроен сетевой адаптер, чтобы должным образом сконфи-
гурировать тот сервер Hyper-V, где будут консолидироваться серверы.
Поэтому вы должны собрать такую информацию, как количество сетевых адаптеров
сервера, текущая и максимальная скорости каждого адаптера, изготовитель адаптера, а
также все подробности по особым режимам работы адаптера (таким, как командная
работа или VLAN). Вы должны также собрать настройки TCP/IP (адрес IP, маску под-
сети и МАС-адрес) для каждого сетевого адаптера, чтобы понять, какие сетевые под-
ключения имеются, и определить виртуальные сети на сервере Hyper-V, которые будут
подключены к этим же физическим сетям.
Подключенные к USB устройства на физических серверах — это обычно специальные
устройства, которые требуются для работы некоторых приложений. Например, это мо-
жет быть устройство чтения смарт-карт для повышения безопасности или USB-флэшка
для хранения ключа шифрования. Виртуальные машины Hyper-V поддерживают под-
ключение через USB только клавиатуры и мыши. Поэтому сбор информации по всем
подключенным через USB устройствам сервера поможет вам определить, является ли
сервер потенциальным кандидатом для виртуализации.
Подключенные через параллельный порт устройства на серверах встречаются нечасто,
поскольку большинство изготовителей серверов уже не делает на своем оборудовании
параллельных портов. Виртуальная материнская плата сервера Hyper-V не имеет па-
раллельного порта и поэтому не может поддерживать требующих подключения через
параллельный порт устройств. Когда вы обнаружите на сервере параллельный порт, то
можете найти на нем аппаратный ключ, который некоторые приложения используют
как способ защиты от несанкционированного использования. Поэтому информация
о том, что имеется подключенное к параллельному порту устройство, сразу же сигна-

лизирует вам о том, что физический сервер, возможно, имеет аппаратный ключ или
нечто особенное (что может исключить его из списка кандидатов на виртуализацию).
Устройства с подключением через последовательный порт часто встречаются в филиа-
лах и в некоторых центрах обработки данных, имеющих устройства бесперебойного
электропитания. Некоторые из этих устройств используют последовательные порты
для обмена с сервером, чтобы выдавать уведомления о событиях пропадания электро-
питания и работы от батарей.
Инвентаризация программного обеспечения

Цель инвентаризации программного обеспечения — составить список всех инсталли-
рованных на сервере приложений (включая версию каждого приложения), а также и
список всех инсталлированных обновлений, исправлений и сервисных пакетов. Знание
инсталлированных на серверах приложений позволит вам принять решение о том, ка-
кие серверы виртуализировать не следует. Кроме того, знание версий приложения и
обновлений поможет вам сгруппировать исключенные из виртуализации серверы
в пулы для последующей однородной консолидации.
В табл. 20.3 приведен список той информации по программному обеспечению, кото-
рую вы должны собрать по каждому серверу.
Таблица 20.3. Информация по программному обеспечению
Категория программного обеспечения Информация
Приложение • Название
• Поставщик
• Версия
• Сервисный пакет
Обновления • Название
• Версия
• Связь с приложением
Исправления • Название
• Версия
• Связь с приложением
Поставщик приложения — это название компании, которая продвигает данное прило-

жение. Версия приложения дает вам информацию об инсталлированной версии прило-
жения и позволяет узнать, сколько разных версий приложения инсталлировано в вашей
среде. Информация по сервисному пакету показывает вам самую последнюю версию
консолидированных обновлений, установленных на сервере. Информация по обновле-
ниям указывает установленные на сервере отдельные обновления. Информация по ис-
правлениям рассказывает об инсталлированных на сервере специальных обновлениях.
Службы
Список инсталлированных на каждом сервере служб дает вам информацию для опре-
деления того, какие именно службы запущены и активно используют ресурсы. Некото-
рые приложения могут быть инсталлированы как службы, поэтому сбор этой информа-
ции тоже может выявить те серверы, которые, возможно, понадобится исключить из
списка кандидатов на виртуализацию. В табл. 20.4 приведен список информации, ко-
торую следует собрать для каждой инсталлированной на сервере службы. Ключевые
значения — название службы, режим запуска, текущее состояние, отображаемое на-
звание.
Таблица 20.4. Информация по службам
Категория службы Информация

Служба • Название
• Тип службы
• Текущее состояние
• Заголовок*
• Описание*
• Отображаемое название
• Путь
• Запущена ли
• Режим запуска
• Название учетной записи
* Необязательная информация.
Соображения по инвентаризации
При планировании времени и способа проведения инвентаризации аппаратного и про-
граммного обеспечения необходимо учесть несколько соображений. Насколько свежими
должны быть полученные вами данные? Сколько времени займет у вас эта инвентаризация
(судя по размеру и сложности вашей среды)? Если вам нужны актуальные и свежие дан-
ные, но на инвентаризацию уходят недели или месяцы, то что может измениться за этот
период? Обдумайте следующие соображения:
• разверните на всех площадках такие системы сбора информации инвентаризации, ко-
торые могут очень быстро сделать моментальный снимок;
• на фазе развертывания не вносите изменений в вашу среду;
• поддерживайте свежесть данных — создайте процесс контроля изменений и привяжите
проект виртуализации к утверждению этих изменений.
Собираемые вами данные должны быть пригодными к использованию, так что при выпол-
нении глобальной инвентаризации следите за региональными настройками и языковыми
пакетами. Языковые пакеты будут выдавать сообщения об ошибках или подсказки, которые
придется интерпретировать. Региональные настройки могут давать разные результаты —
например, в Германии и прочих европейских странах в качестве десятичной точки может
использоваться запятая.
Еще одной угрозой для точности инвентаризационных данных является наличие любых те-
кущих проектов, которые будут разворачивать новые серверы или приложения во время
проекта виртуализации серверов. Запросите у акционеров вашего проекта график всех те-
кущих проектов по ИТ. Эту информацию следует использовать для разработки плана рис-
ков и включить в него все те проекты, которые повлияют на ваши стадии оценки и развер-
тывания. Еще одно предложение: наведите справки обо всех мероприятиях по оптимизации
производительности, которые могут повлиять на вашу среду и выполняются в рамках како-
го-либо формального проекта.
Наблюдение за производительностью
Наблюдение за производительностью серверов дает важную информацию о произво-
дительности тех рабочих нагрузок, которые поддерживаются сервером, и дает идеи
относительно тех проблем производительности, которые могут возникнуть после вир-
туализации физического сервера. Наблюдение за производительностью занимает мно-
го времени. Чтобы гарантировать, что вы зарегистрировали максимумы и минимумы
производительности сервера, вам нужно записать данные за достаточно продолжи-
тельный промежуток времени.
При наблюдении за производительностью вы должны убедиться, что записываете дан-
ные за достаточно продолжительный промежуток времени, чтобы вы могли захватить
такие события, как подготовка финансовой отчетности в конце месяца, процессы ре-
зервного копирования, выполнение спланированных заданий, а также все воздействия
на производительность со стороны нормально работающих приложений. Данные по
производительности должны записываться как минимум за месяц, чтобы захватить все
месячные циклы производительности. Для снижения воздействия сбора данных на сер-
вер эти данные должны собираться через определенный интервал, измеряемый в мину-
тах или секундах. Например, если для сбора данных вы применяете монитор Reliability
And Performance Monitor, то использование интервала в пять минут (вместо интервала
по умолчанию в одну секунду) может дать достаточно данных при минимальном воз-
действии их сбора на сервер.
В табл. 20.5 показаны параметры для наблюдения по основным категориям счетчиков
производительности, которые нужно отслеживать: процессор, память, сеть, система
хранения. Многие из этих параметров — это встроенные в операционную систему
счетчики производительности, для которых может потребоваться сбор данных по не-
скольким экземплярам. Например, на многопроцессорном сервере следует наблюдать
счетчики для всех экземпляров процессоров или ядер.
Таблица 20.5. Информация по наблюдению за производительностью
Категория производительности Параметры наблюдения
Процессор • Суммарный процент процессорного времени

• Процент процессорного времени для каждого экземпляра
процессора
• Процент времени прерываний
Категория производительности Параметры наблюдения
Память • Доступное количество байтов памяти

• Страниц в секунду
Сетевой адаптер (по каждому • Суммарное количество байтов в секунду

адаптеру)
• Количество принятых байтов в секунду
• Количество отправленных байтов в секунду
Логический диск • Количество прочитанных байтов в секунду

• Количество записанных байтов в секунду
• Среднее количество байтов, прочитанных за секунду

• Среднее количество байтов, записанных за секунду
Наблюдение за процессором сосредоточено на проценте использования процессоров

сервера и на проценте времени прерываний. Процент процессорного времени говорит
о том, сколько мощности процессора требуется для рабочих нагрузок сервера. Эта ин-
формация собирается для каждого экземпляра процессора или ядра. Процент времени
прерываний говорит о том, сколько времени процессор занят обработкой прерываний
от устройств и периферии.
Наблюдение за производительностью памяти собирает информацию по счетчикам дос-
тупных байтов и страниц в секунду. Количество доступных байтов представляет собой
объем физической памяти (в байтах), доступный для запроса на выделение из процес-
са, т. е. количество свободной физической памяти. Страницы в секунду — это
скорость, с которой страницы читаются с жесткого диска (или пишутся на него) при
ошибках отсутствия страниц в памяти. Поскольку дисковый ввод/вывод — один из
самых медленных компонентов системы, то знание (поддерживаемого подсистемой
хранения) количества страниц в секунду важно для оценки того, как сервер будет вести
себя в виртуальной машине.
Наблюдение за производительностью сети собирает информацию по общему количе-
ству отправленных (и полученных) в секунду байтов по каждому сетевому адаптеру.
Если вы консолидируете несколько физических серверов на одном сервере Hyper-V, то
вы должны проанализировать (по времени) суммарную пропускную способность одно-
временно работающих виртуальных машин. Эта информация будет служить основани-
ем для решения подключить виртуальные машины через несколько виртуальных сетей,
чтобы сбалансировать сетевую нагрузку по нескольким адаптерам.
Сбор данных по производительности системы хранения дает информацию по количе-
ству данных, перемещающихся между памятью и дисковой подсистемой. Он делается
при помощи счетчиков Logical Disk, которые дают значения реального времени
(и средние) для операций чтения и записи на физический диск. Эту информацию нуж-
но собрать для каждого подключенного к физическому серверу физического диска.
Из-за большого объема собираемой информации и большого количества серверов (для ко-
торых надо собрать эту информацию на фазе обнаружения проекта виртуализации) не ре-
комендуется в качестве средства сбора данных использовать скрипты. Вместо них следует
использовать программное обеспечение, которое специально предназначено для сбора
данных по производительности и минимизирует воздействие на производительность сер-
вера, которое может исказить собранную информацию.
Информация по среде
При сборе информации на фазе обнаружения часто забывают об информации по среде.
Несмотря на то, что она не используется для принятия решений на фазах оценки или
планирования, она может быть чрезвычайно важной для обоснования проекта и демон-
страции предоставляемых виртуализацией преимуществ по снижению расходов.
Когда вы виртуализируете физический сервер, то оборудование этого физического сер-
вера вы либо используете повторно, либо выводите из эксплуатации. Если в вашем
центре обработки данных или в удаленных офисах не хватает мест в стойках, либо
если существующий уровень потребления электроэнергии не позволяет расширять сер-
верный парк с такой скоростью, которая нужна для поддержки роста вашего бизнеса,
то возможность убрать или повторно использовать серверы может стать исключитель-
ным стратегическим преимуществом.
Во время процесса обнаружения вам следует собрать информацию, которая идентифи-
цирует все имеющиеся в вашей среде модели серверов и их производителей, а также
количество развернутых серверов по каждой модели. Кроме того, каждый стоечный
сервер требует определенного количества вертикального пространства стойки, изме-
ряемого в юнитах (от англ. Unit, U). В спецификациях продуктов изготовители всегда
указывают количество юнитов, занимаемых сервером в стойке. Этот показатель может
изменяться от сервера размером в 1U и до сервера размером в 10U. Для плоских серве-
ров вы должны знать, сколько пространства в стойке требуется для размещения данно-
го корпуса и сколько плоских серверов помещается в стойке. Вам нужно будет учиты-
вать эти данные на фазе оценки проекта (чтобы правильно учесть используемое пло-
скими серверами стоечное пространство).
В дополнение к сбору информации по стоечному пространству вам нужно также со-
брать и информацию по потреблению электроэнергии для каждой модели сервера. Все
серверы обычно имеют источники питания, рассчитанные на нагрузку от максимально
укомплектованного сервера. Крупные серверы имеют резервированные источники пи-
тания. В спецификациях производителя должно быть указано энергопотребление в ват-
тах или киловаттах.
Стоечные северы имеют вспомогательную периферию (шкафы систем хранения дан-
ных, переключатели (для клавиатуры, мыши и видео — KVM), сетевые коммутаторы и
прочие смонтированные в стойках устройства), которая после виртуализации сервера
не понадобится. Сбор такой информации позволит вам точнее оценить общее стоечное
пространство и потребление электроэнергии, которое можно будет сэкономить при
условии достижения целей проекта виртуализации. К несчастью, автоматизировать
сбор информации о вспомогательной периферии непросто, поэтому эта задача потре-

бует много времени и ресурсов.
В сборе информации по вашей среде вам поможет электронная таблица MS Excel из ката-
лога Job Aids с названием Potential Cost Savings JobAid.xls. В этой таблице есть страница
Cost Savings Details, которая содержит рекомендуемую для сбора информацию по среде и
некоторые вычисления для подсчета экономии затрат по среде. Имеется также и вторая
страница, которая дает сводку потенциальной экономии расходов, достигнутой путем лик-
видации вспомогательного оборудования.
Автоматизация
процесса обнаружения
При сборе данных (по инвентаризации, по производительности и по среде) вы, скорее
всего, захотите как можно больше автоматизировать этот процесс. Возможно, вы в ва-
шей среде уже имеете такие инструменты, которые могут помочь в сборе требуемых
данных. Например, если вы используете систему управления активами типа System
Center Configuration Manager (SCCM) или Systems Management Server (SMS), то можете
создавать запросы, которые помогут вам создать список серверов (по любым правилам
исключения). Вы можете также генерировать (при помощи этих систем управления
активами) данные инвентаризации.
Если в вашей среде развернута система наблюдения за серверами вроде System Center
Operations Manager (SCOM) или Microsoft Operations Manager (MOM), то вы можете
использовать имеющийся в пакете управления Server Virtualization отчет Virtualization
Candidate для определения кандидатов на виртуализацию.
Если вы в настоящее время не используете такие системы управления активами и
решения по наблюдению за серверами, или вашим бюджетом не предусмотрено раз-
вертывание таких систем, то вы можете использовать для сбора необходимых данных
(фазы обнаружения) скрипты и другие инструменты.
Скрипты
В эту книгу включены образцы скриптов, созданные для того, чтобы помочь вам со-
брать данные фазы обнаружения.
Образцы скриптов хранятся в каталоге Scripts\Chapter 20.
В табл. 20.6 приведен список имеющихся скриптов, краткое описание каждого скрип-
та, а также требования к его выполнению или описание вывода этого скрипта. Для сбо-
ра данных скрипты используют разные интерфейсы прикладного программирования
(API) вроде Windows Management Instrumentation (WMI) и Active Directory Systems
Interface (ADSI).
Таблица 20.6. Образцы скриптов сбора данных
Название
Описание Требования
скрипта
GetDomains.vbs Собирает список Если у вас несколько лесов, то вам нужно будет
доменов внутри леса выполнить его в каждом лесу, используя при этом
учетную запись администратора домена. Перед
использованием вы должны модифицировать скрипт,
чтобы изменить имя домена по умолчанию
Contoso.com на ваше имя домена
GetSites.vbs Собирает соответст- Для выполнения GetSites.vbs вам нужно будет сначала
вие серверов площад- зарегистрироваться на контроллере домена с учетной
кам (из Active записью администратора домена. Скрипт выдает файл
Directory) с ограничителем в виде запятой (формат CSV), содер-
жащий по строке на каждый сервер, в которой указаны
название площадки и имя сервера
GetSubnets.vbs Собирает список Для выполнения этого скрипта требуются права адми-
подсетей, выделенных нистратора домена. Скрипт GetSubnets.vbs выдает
площадкам Active CSV-файл, содержащий по строке на каждую площад-
Directory ку, в которой указаны название площадки и выделен-
ные ей подсети
GetComputers.vbs Собирает список учет- Для выполнения скрипта требуются права администра-
ных записей компью- тора домена, и выполнить его нужно во всех доменах.
теров домена Скрипт GetComputers.vbs выдает CSV-файл, содержа-
щий по строке на каждый компьютер, в которой указа-
ны: название домена, имя компьютера, операционная
система, версия сервисного пакета, а также дата изме-
нения пароля учетной записи компьютера. Перед ис-
пользованием вы должны модифицировать скрипт,
заменив название домена по умолчанию Contoso.com
именем вашего домена
GetSoftware.vbs Собирает список Для выполнения скрипт требует прав локального адми-
инсталлированного нистратора, и выполнить его нужно на всех серверах.
на сервере программ- Скрипт GetSoftware.vbs выдает CSV-файл, содержа-
ного обеспечения щий по строке для каждого приложения, в которой ука-
заны: имя компьютера, название приложения, распро-
странитель приложения, а также версия приложения
GetServices.vbs Собирает список ин- Для выполнения скрипта требуются права локального
сталлированных администратора, и выполнить его необходимо
на сервере служб на каждом сервере. Скрипт GetServices.vbs выдает
CSV-файл, содержащий по строке для каждой службы,
в которой указаны: имя компьютера, название службы,
текущее состояние службы, заголовок, описание, ото-
бражаемое название, путь к исполняемому модулю
службы, запущена ли служба, режим запуска, а также
имя используемой для выполнения службы учетной
записи
Инструменты общего назначения

Использовать для сбора данных (фазы обнаружения) специальные инструменты —
лучше, чем использовать скрипты, потому что такие инструменты работают быстрее
(хотя их, может быть труднее настроить или скомбинировать полученные из них дан-
ные — если используются разные инструменты). Далее приведены некоторые инстру-
менты общего назначения, которые можно использовать для сбора информации по

серверам и из Active Directory.
Systemtools Exporter Pro

Systemtools Exporter Pro — это инструмент компании SystemTools Software, Inc., кото-
рый вы можете использовать для документирования конфигурации Active Directory и
серверов Windows, развернутых в небольших и средних организациях. Exporter Pro
предназначен для сбора широкого диапазона информации, в том числе:
объектов Active Directory (организационных подразделений, групп, учетных записей
компьютеров и т. д.);
конфигурации программного обеспечения компьютеров (операционной системы,
служб, приложений и т. д.);
конфигурации оборудования компьютеров (процессоров, памяти, сети, дискового
пространства и т. д.);
конфигурации сети компьютера (TCP/IP, МАС-адреса и т. д.);
процессов компьютера;
приложений компьютера;
совместно используемых ресурсов компьютера;
локальных групп и пользователей компьютера;
настроек безопасности для файлов, совместно используемых ресурсов, принтеров,
служб и реестра;
файлов и каталогов;
запланированных заданий;
прав пользователей;
политик учетных записей и аудита;
зарегистрированных в системе пользователей.
Exporter Pro поможет собрать эти данные для любого сервера или рабочей станции ва-
шей среды (при условии, что вы запускаете этот инструмент в контексте учетной запи-
си с достаточными разрешениями и правами доступа к источникам данных).
После того как вы определите те данные, которые вы хотите собрать, Exporter Pro ис-
пользует определенную комбинацию методов и протоколов для извлечения информа-
ции из Active Directory и непосредственно с компьютеров (при помощи запросов к рее-
стру, WMI и Active Directory). Exporter Pro имеет шаблоны реестра для извлечения ин-
формации по инсталлированному программному обеспечению и обновлениям, а также
запросы WMI для извлечения специфической для компьютера информации (оборудо-
вание, операционная система, процессы, информация журнала событий и т. д.).
Exporter Pro также поддерживает запросы пользователя по Active Directory. Exporter
Pro сохраняет собранные данные в текстовые файлы с ограничителями, которые можно
экспортировать в любую базу данных или электронную таблицу (для выполнения ана-
лиза данных и составления отчетов).
Дополнительную информацию по Systemtools Exporter Pro можно получить по адресу:
http://www.systemtools.com/exporter/index.html. С этого сайта можно также скачать и
30-дневную пробную версию.
Microsoft Active Directory Topology Diagrammer

Microsoft Active Directory Topology Diagrammer (ADTD), ранее называвшийся
ADMAP, — это бесплатный инструмент, который вы можете использовать для доку-
ментирования различных аспектов инфраструктуры Active Directory. ADTD извлекает
информацию из Active Directory при помощи протокола Lightweight Directory Access
Protocol (LDAP), интерфейса Active Directory Services Interface (ADSI), а также объек-
тов ActiveX Data Objects (ADO). В табл. 20.7 перечислена та информация Active
Directory, которая извлекается при помощи ADTD.
Таблица 20.7. Список информации из ADTD
Компонент Active
Информация
Directory
Домен • Имя домена
• Функциональный уровень домена
• Количество контроллеров домена
• Подробности по контроллерам домена
• Название
• Операционная система
• Уровень сервисного пакета
• Серверы глобального каталога
• Количество и тип доверительных отношений
• Количество учетных записей пользователей
• Владельцы роли хозяина операций
• Версия схемы
Подразделение • Иерархия подразделения
• Название подразделения
• Ссылки на объекты групповой политики
Площадка • Название площадки
• Генератор внутренней топологии площадки
• Общее количество контроллеров домена на каждой площадке
• Общее количество подсетей на каждой площадке
• Количество контроллеров домена на каждой площадке
• Количество серверов глобального каталога на каждой площадке
• Количество подсетей на каждой площадке
• IP- и SMTP-ссылки на площадки
• Подключения репликации внутри площадки
• Подключения репликации между площадками
Компонент Active
Информация
Directory
Раздел приложений • Название раздела приложений
• Общее количество контроллеров домена, имеющих раздел приложений
• Контроллеры домена, имеющие раздел приложений
Для использования ADTD вам нужно задать только имя сервера глобального каталога
домена Active Directory, выбрать необходимый вам уровень информации и ввести на-
звание и пароль учетной записи с административными правами (если появится запрос).
По умолчанию ADTD записывает собранную им информацию в файл (ADTD.csv). Од-
нако главным преимуществом этого инструмента является то, что вы можете дать ука-
зание ADTD создать диаграммы данных в формате Microsoft Visio 2003 (в том числе
структуры доменов Active Directory, иерархии подразделений, разделов приложений,
топологии площадок, каналов и подключений репликации).
Инсталляционный файл ADTD.NET Setup.msi для ADTD вы можете скачать по ссылке:
http://www.microsoft.com/downloads/details.aspx?familyid=cb42fc06-50c7-47ed-a65c-
862661742764. Процедура инсталляции ADTD создает каталог для двоичных файлов и до-
кументации ADTD. В меню Programs создается ссылка на ADTD.
Сканеры портов
Сканеры портов могут перебрать диапазон IP-адресов и попытаться подключиться ко
всем стандартным портам, чтобы выявить серверы и выполняющиеся на них приложе-
ния. Успех сканирования портов зависит от способности опросить все порты и от на-
личия на сервере или сети сетевых экранов, предназначенных для блокирования ска-
нирования портов. Кроме того, если сканер портов обнаруживает IP-адрес с открыты-
ми портами, то он должен суметь определить тип обнаруженного им устройства
(сервер, принтер, сетевой маршрутизатор или нечто другое). Несмотря на то, что в
принципе вы можете использовать инструменты такого типа, все же использование
сканеров портов для сбора информации по серверам не рекомендуется.
Сканирование портов считается угрозой для безопасности и большинство организаций
имеет политики против использования этого типа инструментов. Если вам нужно использо-
вать сканер портов, то перед его применением обязательно поставьте в известность вашу
команду управления сетью или команду безопасности.
Зондирование подсетей
В то время как сканирование портов может считаться риском для безопасности, боль-
шинство организаций менее строго относится к сканированию подсетей при помощи
ping-теста. Информация этого сканирования может помочь вам идентифицировать та-
кие активы, которые не входят в домены или устаревшие активы (которые больше не
используются).
Для простого ping-теста по подсети можно использовать и инструмент сканирования

портов, однако нужно обязательно указать "только ping" (а не сканирование портов).
Инструменты обнаружения и оценки

Компания Microsoft и сторонние поставщики программного обеспечения разработали
инструменты, которые могут помочь на фазах обнаружения и оценки проекта.
Инструментальный набор
Microsoft Assessment and Planning
Компания Microsoft выпустила инструмент из линейки приложений Solution Accelerator
с названием Microsoft Assessment and Planning (MAR) Toolkit. Этот набор является
мощным инструментом (который может выполнить инвентаризацию небольших или
крупных сред без необходимости инсталляции агентов на серверы) для инвентариза-
ции, оценки и отчетности. МАР предоставляет возможности анализа, которые могут
упростить процесс планирования миграции серверов на Windows Server 2008 и на тех-
нологии виртуализации Windows (такие, как Windows Server 2008 Hyper-V или Virtual
Server 2005 R2). МАР может также помочь при планировании миграции настольных
компьютеров на операционную систему Windows Vista и при обновлении на Microsoft
Office 2007.
Рис. 20.1. Стартовая страница МАР

МАР реализован как 32- или 64-битное приложение Windows, которое использует для
хранения собранных данных сервер Microsoft SQL Server Express Edition или SQL
Server 2005 версий Standard или Enterprise, а для создания отчетов — Microsoft Office
Word и Microsoft Office Excel. На рис. 20.1 показана главная страница Assessment при-
ложения МАР. Панель Actions разделена на четыре части: Inventory, Reports and
Proposals, Useful Information и Freedback. Кнопки Virtualization, Deployment,
Security, Operations и Product Information — это ссылки на дополнительную инфор-
мацию по инструментальному набору МАР.
Методы обнаружения серверов

МАР способен выявлять серверы при помощи нескольких методов обнаружения.
Методы обнаружения облегчают отыскание конкретных серверов, которые являются
целью для оценки. Методы обнаружения используют автоматизированные процессы
для выявления серверов и позволяют вам указывать серверы в пакетном режиме или
индивидуально. МАР поддерживает следующие методы обнаружения серверов.
Службы домена. Этот метод позволяет запросить контроллер домена через прото-
кол Lightweight Directory Access Protocol (LDAP) и выбрать компьютеры из всех или
из конкретных доменов, контейнеров или подразделений. Те компьютеры, которые
не регистрировались в домене более 90 дней, инвентаризироваться не будут.
Сетевые протоколы Windows. Этот метод использует интерфейс прикладного про-
граммирования WIN32 LAN Manager API для запроса у службы Computer Browser
всех компьютеров рабочих групп и доменов Windows NT 4.0. Метод ограничен те-
ми серверами, которые перечислены в службе Computer Browser, и подвержен воз-
действию со стороны сетевых экранов.
Импорт файлов. При помощи этого метода вы можете создать текстовый файл со
списком подлежащих инвентаризации компьютеров. Имя каждого компьютера
должно находиться на отдельной строке, и файл не должен использовать ограничи-
телей (таких, как запятая, точка, знак табуляции и т. д.).
Сканирование диапазона IP-адресов. Этот метод позволяет вам указать диапазон
адресов IP. После этого мастер просканирует все IP-адреса диапазона и проинвента-
ризирует эти компьютеры.
Определение вручную. Этот метод позволяет вам протестировать и проинвентаризи-
ровать за один раз несколько компьютеров (путем ввода имен компьютеров вруч-
ную).
Методы инвентаризации
Для сбора информации о компьютере или устройстве МАР использует несколько ме-
тодов инвентаризации. Это следующие три метода: WMI, Simple Network Management
Protocol (SNMP) и Remote Registry.
Для сбора с удаленного сервера информации по оборудованию, устройствам и про-
граммному обеспечению во всех сценариях оценки требуется WMI. При инсталляции
по умолчанию WMI поддерживают следующие серверные операционные системы:
Windows Server 2008;

Windows Server 2003 и Windows Server 2003 R2;
Windows 2000 Server.
SNMP — это протокол сетевого обнаружения, который позволяет вам считывать или
устанавливать значения атрибутов подключенных к сети устройств. По умолчанию в
операционных системах Windows служба SNMP не активирована. Этот метод инвента-
ризации используется тогда, когда вы выбираете вариант создания отчетов для всех
устройств SNMP. В других случаях этот метод не используется.
Служба Remote Registry используется для нахождения инсталлированных на сервере
ролей. Она также требуется и для работы мастера Performance Monitoring Wizard. Эта
служба инсталлируется на серверах Windows по умолчанию, но на Windows Server
2008 она по умолчанию не запускается.
Для успешной работы этого метода инвентаризации должны присутствовать следую-
щие условия:
1. Служба Remote Registry должна быть запущена.
2. Должно быть активировано исключение сетевого экрана Windows под названием
Remote Administration Exception.
3. Вы должны аутентифицироваться под учетной записью локального администратора
Работа МАР
Для обнаружения сервера и его оценки МАР выполняет трехшаговый процесс. Первый
шаг — выбор или создание базы данных для хранения данных инвентаризации (или
данных по производительности). Второй шаг — сбор данных инвентаризации и данных
по производительности. Для выполнения этого шага МАР имеет мастер Performance
Metrics Wizard. Если сервер ранее не инвентаризировался, то перед сбором данных по
производительности мастер проинвентаризирует сервер. Последний шаг — оценка
серверов как кандидатов для виртуализации, выполнение планирования консолидации,
а также выдача отчетов по проведенному анализу. МАР выполняет все эти действия
при помощи мастера Server Consolidation And Virtualization Wizard.
Создание базы данных

Когда вы инсталлируете МАР, то можете либо указать ему уже существующий сервер
базы данных SQL Server 2005, либо инсталлировать на сервере МАР сервер SQL Server
2005 Express Edition. МАР может собирать информацию как с одного места своей ин-
сталляции, так и с нескольких мест по всей глобальной сети (сохраняя данные в ука-
занной базе). МАР использует эти данные из единой базы для выполнения оценки кан-
дидатов на виртуализацию и для планирования консолидации. Если вам нужно провес-
ти оценку или планирование консолидации для каждой площадки отдельно, то вы
должны собирать данные по каждой площадке отдельно и хранить их в отдельной базе
данных (для каждой площадки).
Мастер Performance Metrics Wizard

Мастер Performance Metrics Wizard управляет процессом удаленного наблюдения за
основными счетчиками производительности дисков, сети и процессоров удаленных
серверов. Вы выбираете серверы, которые будут наблюдаться в качестве кандидатов на
консолидацию (для этого надо создать и импортировать в мастер текстовый файл с
именами компьютеров). Наблюдение за производительностью требуется для того, что-
бы определить размещение виртуальных машин в инфраструктуре виртуализации.
Мастер Server Virtualization and Consolidation Wizard выполняет анализ размещения
серверов с использованием результатов мастера Performance Metrics Wizard.
Мастер Performance Metrics Wizard выполняет следующие задачи:
выполняет инвентаризацию наблюдаемого сервера;
осуществляет подробное наблюдение за счетчиками производительности физиче-
ских и логических дисков;
выполняет подробное наблюдение за использованием памяти;
проводит подробное наблюдение за использованием сети;
выполняет подробное наблюдение за использованием процессоров;
проводит наблюдение производительности за длительный промежуток времени.
Когда вы запускаете мастер Performance Metrics Wizard, он запрашивает текстовый
файл с именами серверов. Именем сервера может быть имя хоста, имя NetBIOS, либо
полное имя хоста в формате Domain Name System (DNS). После того как вы указали
текстовый файл, мастер запрашивает учетные данные для использования при удален-
ных вызовах WMI. Учетная запись должна быть членом группы локальных админист-
раторов наблюдаемого сервера. Вы можете указать одну учетную запись для всех сер-
веров или отдельные записи для каждого сервера.
После того как вы указали данные учетной записи, вы должны указать период времени
для сбора показателей производительности. Для этого указываются дата и время за-
вершения сбора. Рекомендуется запускать сбор данных по производительности на пе-
риод не менее 30 дней, чтобы получить представительные данные.
На рис. 20.2 показано диалоговое окно МАР, которое отображается при активном сбо-
ре данных. Как вы видите, МАР показывает состояние сбора показателей по инвента-
ризации и производительности, а также состояние создания отчетов.
Мастер Performance Metrics Wizard генерирует электронную таблицу Office Excel,
в которой указана сводка общих показателей производительности, а также подробно-
сти по использованию процессоров, сети, физических и логических дисков. Кроме то-
го, в ней приводятся статистика подключений, где обозначено количество тех попыток
подключений, при которых МАР не смог связаться с серверами.
Характеристики, функции и выводные данные мастера Server Virtualization and Consolidation
Wizard описаны в главе 21. Дополнительную информацию можно получить (а также и ска-
чать МАР) по ссылке: http://www.microsoft.com/MAP.
Рис. 20.2. Диалоговое окно состояния МАР
PlateSpin PowerRecon
Компания PlateSpin, Ltd. производит продукт под названием PowerRecon, который
можно получить в разных версиях (в зависимости от тех функций, которые понадобят-
ся вам для вашего проекта виртуализации серверов): PowerRecon Inventory Edition вы-
полняет инвентаризацию аппаратного и программного обеспечения; PowerRecon
Standard Edition добавляет к инвентаризации возможности наблюдения за производи-
тельностью; а версия PowerRecon Standard Edition with Planning добавляет к стандарт-
ной версии оценку и планирование консолидации. Эти версии PowerRecon предназна-
чены для использования в долгосрочных проектах консолидации серверов и оптимиза-
ции центров обработки данных. Компания PlateSpin также поставляет версию
PowerRecon Project Edition, которая имеет все функциональные возможности
PowerRecon Standard Edition with Planning, но предназначена для проектов ограничен-
ной продолжительности.
Компания Novell приобрела компанию PlateSpin в начале 2008 г. Учтите, что названия про-
дуктов на текущий момент могли измениться. Дополнительную информацию по
PowerRecon см. по ссылке: http://www.platespin.com/Products/powerrecon/.
PowerRecon — это сложный набор инструментов для средних и больших предприятий,

который обеспечивает сквозное решение по анализу и планированию консолидации
(для проектов консолидации и виртуализации серверов). PowerRecon предлагает сле-
дующие основные возможности:
сбор информации инвентаризации по оборудованию, программному обеспечению и

службам, а также соответствующие отчеты;
сбор информации по использованию ресурсов серверов и рабочим нагрузкам, а
также соответствующие отчеты;
планирование и моделирование консолидации и распределения рабочих нагрузок.
PowerRecon поддерживает сбор данных по инвентаризации и использованию ресурсов
для операционных систем Windows, Novell SUSE, RedHat, Sun Solaris SPARC и для
других операционных систем х86.
Сбор информации инвентаризации по оборудованию,

программному обеспечению и службам. Отчеты
Для того чтобы обеспечить сбор данных инвентаризации как для сценария с одной не-
большой площадкой, так и для сценария большого географически распределенного
предприятия, PowerRecon можно развернуть как одним экземпляром, так и нескольки-
ми. Каждый экземпляр PowerRecon поддерживает до 2000 серверов и способен агреги-
ровать собранные серверами PowerRecon данные в единое главное хранилище (для
централизованного анализа и планирования).
PowerRecon собирает данные инвентаризации без инсталляции программного агента,
он собирает данные через встроенные в поддерживаемые операционные системы инст-
рументальные средства. Данные по инвентаризации оборудования включают ресурсы
процессора, памяти, сети и дисков. Данные по инвентаризации программного обеспе-
чения включают гостевую операционную систему, инсталлированные и работающие
приложения и службы, а также инсталлированные сервисные пакеты и обновления.
Сбор информации по использованию ресурсов серверов

и рабочим нагрузкам. Отчеты
PowerRecon может собрать информацию по использованию серверов и рабочих нагру-
зок для всех компьютеров своей инвентаризационной базы. Информация по использо-
ванию применяется для создания диаграмм и отчетов, которые позволяют анализиро-
вать использование ресурсов процессоров, памяти, сети и дисков. Компания PlateSpin
поставляет пакет управления для настройки интеграции MOM 2005 с PowerRecon. Па-
кет управления активирует все необходимые для PowerRecon счетчики производитель-
ности и устанавливает пятиминутный интервал наблюдения.
PowerRecon поставляется со множеством готовых отчетов (их можно настраивать), ко-
торые документируют данные инвентаризации оборудования, развернутое программ-
ное обеспечение и службы, показатели использования, а также планирование консоли-
дации. Имеются также фильтры для изготовления отчетов по определенным группам
серверов и по периодам использования ресурсов.
Планирование и моделирование консолидации и распределения

рабочих нагрузок
PowerRecon имеет модуль планирования консолидации, который предоставляет воз-
можность создавать сценарии консолидации (на основе собранных PowerRecon данных
по использованию ресурсов серверов и рабочим нагрузкам). Сценарии консолидации

могут быть ограниченными и включать только определенные типы рабочих нагрузок и
периоды использования ресурсов (для моделирования). Проектный рост рабочих на-
грузок и их колебания также могут быть учтены в сценарии консолидации.
Сценарии консолидации PowerRecon позволяют вам определить: минимальное количе-
ство серверов, необходимых для консолидации заданного набора рабочих нагрузок;
рабочие нагрузки-кандидаты на консолидацию и их распределение по заданному набо-
ру серверов. Для использования в сценариях консолидации и моделирования распреде-
ления рабочих нагрузок (по серверам виртуализации) определяются шаблоны серверов.
PowerRecon имеет несколько готовых шаблонов серверов, вы можете также опреде-
лить новые шаблоны серверов под стандарты своей среды. Для определения шаблона
сервера необходимы следующие общие данные:
название сервера, изготовитель и модель;
суммарная стоимость владения, требования к объему стойки, характеристики по-
требления электроэнергии;
программное обеспечение виртуализации (используется для определения накладных
расходов системы виртуализации).
Для каждого шаблона сервера определяются также следующие параметры конфигура-
ции и ограничения по использованию ресурсов:
количество процессоров и их скорость;
выделение памяти;
выделение дискового пространства;
суммарные пределы по процессору, памяти и дискам (в процентах);
пределы по дисковым операциям и полосе пропускания сети.
Вы можете сконфигурировать шаблоны серверов с разными выделениями процессо-
ров, памяти, сети и дисков и использовать их в сценариях консолидации для определе-
ния самой экономически эффективной архитектуры, которая сможет поддерживать
заданный набор рабочих нагрузок.
PowerRecon может генерировать сводные отчеты и отчеты по рабочим нагрузкам, ко-
торые содержат результаты из сценариев консолидации, и в том числе сравнения ис-
пользования ресурсов до консолидации с проектными показателями после консолида-
ции, а также рекомендации по распределению рабочих нагрузок. PowerConvert (инст-
румент компании PlateSpin, который используется для преобразования физических
машин в виртуальные) интегрируется с PowerRecon для реализации планов консолида-
ции серверов и рекомендаций по распределению рабочих нагрузок.
Резюме
В этой главе был дан обзор фазы обнаружения типичного проекта виртуализации сер-
веров. Фаза обнаружения занимается сбором данных, необходимых для фазы оценки и
фазы планирования и проектирования. Собранные на фазе обнаружения данные ис-
пользуются для определения тех серверов, которые являются хорошими кандидатами

на виртуализацию, а также для определения тех комбинаций рабочих нагрузок, которые
следует разместить на серверах Hyper-V для оптимального использования ресурсов.
Во время фазы обнаружения вы собираете информацию, которая содержит леса, доме-
ны, площадки и подсети Active Directory, и сопоставляете эту информацию с физиче-
скими площадками. Вы составляете список серверов, которые входят в область дейст-
вия проекта. Вы собираете инвентаризационную информацию по оборудованию и про-
граммному обеспечению для каждого сервера, а также информацию по основным
счетчикам производительности за период не менее 30 дней, чтобы проанализировать
пиковые, минимальные и средние значения использования процессоров, памяти, сети и
систем хранения. Вы используете инвентаризационные данные по оборудованию сер-
веров на фазе оценки проекта для определения того, сколько кандидатов на виртуали-
зацию имеет такие спецификации оборудования, которые позволяют их повторно ис-
пользовать в качестве серверов Hyper-V для снижения капитальных вложений. По соб-
ранной информации о среде вы сможете создать на фазе оценки отчет по анализу
преимуществ, где дается оценка экономии (стоечного пространства, потребления элек-
троэнергии, а также тепловыделения), которая будет достигнута после виртуализации
серверов.
В крупных средах автоматизация сбора данных (по инвентаризации, показателей про-
изводительности и данных среды) очень важна. Поэтому мы также представили вам
несколько программных инструментов компании Microsoft и сторонних производите-
лей, которые могут вам помочь автоматизировать сбор данных на фазе обнаружения.

Microsoft Script Center — ресурс, который содержит информацию по написанию
скриптов для локального или удаленного сбора информации с компьютеров
Windows, доступен по адресу:
http://www.microsoft.com/technet/scriptcenter/default.mspx;
Connecting to WMI on a Remote Computer — ресурс, который даст вам указания по
подключению к поставщику WMI удаленного компьютера и запросу любого интер-
фейса WMI, доступен по адресу:
http://msdn2.microsoft.com/en-us/library/aa389290.aspx;
WMI Tasks for Scripts and Applications — ресурс с простыми скриптами для сбора
данных в различных сценариях, доступен по адресу:
http://msdn2.microsoft.com/en-us/library/aa394585.aspx;
Microsoft Assessment and Planning Solution Accelerator — ресурс, который содержит
подробную информацию по MAP и дает ссылку для скачивания самого MAP, дос-
тупен по адресу: http://www.microsoft.com/MAP;
PlateSpin PowerRecon — ресурс, который дает ссылку на домашнюю страницу
PlateSpin, где вы можете получить дополнительную информацию по инструментам
PowerRecon и PowerConvert tools, доступен по адресу: http://www.platespin.com.
ГЛАВА 21

фаза оценки
Во время фазы оценки проекта виртуализации серверов команда по архитектуре ис-
пользует собранную на фазе обнаружения информацию для определения хороших кан-
дидатов на виртуализацию серверов. Для этого анализируется оборудование, про-
граммное обеспечение и данные по производительности по каждому серверу (по опре-
деленному набору ограничений). Ограничения по оборудованию определяются
имеющимся в виртуальной машине сервера Hyper-V виртуальным оборудованием.
Ограничения по производительности определяются производительностью виртуальной
машины. Установленное на сервере программное обеспечение может привести к ис-
ключению сервера из списка кандидатов по причине отсутствия поддержки (со сторо-
ны поставщика) работы приложения в виртуализированной среде или вследствие тре-
бований приложения по производительности (которые превышают установленные
ограничения).
Выявление кандидатов
на виртуализацию серверов
Процесс определения кандидатов на виртуализацию серверов начинается со списка
физических серверов, которые входят в область действия проекта виртуализации. Ис-
пользуя набор ограничений по оборудованию и производительности, вы либо включае-
те данный физический сервер в список кандидатов на виртуализацию, либо исключаете
его из списка. Ограничения по оборудованию определяются возможностями виртуаль-
ного оборудования виртуальных машин сервера Windows Server 2008 Hyper-V и ис-
пользуемым для сервера Hyper-V физическим оборудованием. Эти ограничения вклю-
чают: количество памяти, количество процессоров, максимальное дисковое простран-
ство, количество требуемых сетевых адаптеров и прочие специальные требования к
оборудованию. Ограничения по производительности отличаются в зависимости от
конфигурации того физического сервера, который используется как сервер Hyper-V.
Лучшие показатели дает реальное тестирование работающих на сервере виртуальных
машин. Оценка серверов при помощи данных по производительности также позволяет
вам выявить такие физические серверы, которые имеют больше ресурсов, чем им нуж-
но для работающих на них рабочих нагрузок.
Процесс определения кандидатов для виртуализации на самом деле больше занимается

выявлением тех физических серверов, которые следует исключить из списка кандида-
тов на виртуализацию. Предполагается, что все оставшиеся в списке (после проверки
на соблюдение ограничений) серверы являются кандидатами на виртуализацию. Это
поэтапный подход: сначала вы исключаете по ограничениям оборудования, затем вы
исключаете по ограничениям производительности и, наконец, вы исключаете по нали-
чию поддержки программного обеспечения. Исключение на любом этапе немедленно
удаляет кандидата из списка.
Ограничения
по оборудованию виртуальных машин
Виртуальные машины Windows Server 2008 Hyper-V имеют определенный набор огра-
ничений оборудования. От оборудования сервера зависит процессор виртуальной ма-
шины. Это происходит из-за архитектуры сервера Hyper-V, т. к. процессор не эмулиру-
ется, а напрямую предоставляется виртуальной машине. Поэтому оборудование вирту-
альной машины будет видеть тот же самый процессор, который установлен на сервере.
Если на сервере имеется физический процессор на 3,0 ГГц, то виртуальная машина бу-
дет иметь виртуальный процессор на 3,0 ГГц. В табл. 21.1 приведены ограничения по
оборудованию виртуальной машины.
Таблица 21.1. Ограничения по оборудованию виртуальной машины
Оборудование Максимальное ограничение

Количество процессоров 4
Скорость процессора Скорость процессора сервера
Память 64 Гбайт
Количество сетевых адаптеров 8 синтетических, 4 эмулированных
Количество дисковых контроллеров IDE — 2, SCSI — 4
Количество жестких дисков на один IDE — 2, SCSI — 64
контроллер
Размер единичного жесткого диска 2040 Гбайт — виртуальный жесткий диск IDE или SCSI,
256 Тбайт — транзитный диск (IDE или SCSI)
Суммарное дисковое пространство 528,33 Тбайт — виртуальные жесткие диски IDE или SCSI,
65 Пбайт — транзитные диски
Количество последовательных портов 2
Количество параллельных портов 0
Оценка ограничений по оборудованию

Ограничения по оборудованию виртуальной машины используются как первый слой
определения пригодности физического сервера для виртуализации. Ограничения по
оборудованию включают в себя такие компоненты, как память, дисковое пространство,
Глава 21. Проект виртуализации серверов: фаза оценки 707
процессор и сеть. Более специфичными являются ограничения по наличию последова-

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

Виртуальная машина сервера Windows Server 2008 Hyper-V имеет ограничение в четы-
ре виртуальных процессора. Физический сервер может иметь процессоры с одним или
несколькими ядрами. Виртуальный процессор — это логический эквивалент физи-
ческого ядра процессора. Несмотря на это ограничение по оборудованию, будет
неправильно утверждать, что любой физический сервер с более чем четырьмя процес-
сорными ядрами должен быть немедленно исключен из списка кандидатов на виртуа-
лизацию. Ведущим критерием для оценки физического сервера должно быть использо-
вание процессоров. Четырех- или восьмиядерный сервер с низким использованием
процессора может подпадать под данное ограничение оборудования. Поэтому оценку
ограничения по процессорам следует отложить до оценки производительности.
Ограничения оборудования по памяти

Виртуальная машина Windows Server 2008 Hyper-V имеет ограничение виртуальной
памяти в 64 Гбайт. Оценка сервера по количеству инсталлированной памяти не учиты-
вает количество фактически используемой сервером памяти. При таком подходе для
принятия решения используется только информация инвентаризации о количестве па-
мяти физического сервера. Если при этом подходе физический сервер имеет количест-
во инсталлированной памяти более 64 Гбайт, то он обычно исключается из списка кан-
дидатов на виртуализацию. Большая часть развернутых в настоящее время серверов
фактически использует не всю инсталлированную в них память. Перед добавлением
сервера в список исключенных серверов вам следует произвести оценку производи-
тельности, чтобы определить пиковое количество фактически используемой сервером
памяти.
Имеющееся на сервере количество памяти является основным ограничивающим фактором
для количества одновременно работающих виртуальных машин. Для оптимизации количе-
ства виртуальных машин, которые можно разместить на сервере Hyper-V, вы должны оце-
нить распределение памяти по ее фактическому использованию (при миграции физическо-
го сервера на виртуальную машину).
Версия Windows Server 2008 Standard Edition имеет предел в 32 Гбайт памяти. Из-за этого
ограничения работающая на такой версии виртуальная машина не сможет использовать
своего максимума в 64 Гбайт.
Ограничения по сетевому адаптеру

Виртуальная машина сервера Windows Server 2008 Hyper-V имеет ограничение вирту-
ального оборудования в 12 активных сетевых адаптеров Ethernet: 8 синтетических и
4 эмулируемых адаптера. Каждый адаптер Ethernet может иметь скорость от 10 Мбит/с
до 10 Гбит/с. Если рассматриваемому физическому серверу требуется более 12 актив-
ных сетевых адаптеров для подключения более чем к 12 различным сетям (или если
ему требуется более 12 сетевых адаптеров на той скорости, которую позволяет ваша
сеть), то этот физический сервер следует исключить из списка кандидатов на виртуали-
зацию. Если рассматриваемый физический сервер требует сетевые адаптеры другого
типа (не Ethernet), то данный сервер также следует исключить из списка кандидатов на
виртуализацию.
Ограничения оборудования по дискам

Сервер Windows Server 2008 Hyper-V был спроектирован для поддержки очень боль-
ших конфигураций жестких дисков. Виртуальная машина сервера Windows Server 2008
Hyper-V имеет два ограничения виртуального оборудования по жестким дискам. Пер-
вое — размер раздела диска. Подключенный к виртуальному контроллеру (IDE или
SCSI) виртуальный жесткий диск имеет максимальный размер раздела 2040 Гбайт.
С появлением в Hyper-V транзитных дисков используемый в качестве транзитного
диска Logical Unit Number (LUN) имеет ограничение в 256 Тбайт (при файловой систе-
ме NTFS). Поэтому если какой-либо раздел жесткого диска на физическом сервере
больше 256 Тбайт, то этот сервер виртуализировать нельзя.
Второе ограничение — суммарное количество подключенного к физическому серверу
дискового пространства. При использовании виртуальных жестких дисков виртуальная
машина имеет ограничение подключенного объема дискового пространства в
528,33 Тбайт. При использовании транзитных дисков ограничение их объема составля-
ет 65 Пбайт. Следовательно, если физический сервер имеет более 65 Пбайт дискового
пространства, то виртуализировать его нельзя.
В зависимости от вашего подхода к системе хранения виртуальных машин (виртуаль-
ные жесткие диски или транзитные диски), для оценки физического сервера следует
использовать вышеприведенные ограничения.
Виртуальные дисковые контроллеры не имеют такой функциональной возможности, как
RAID. Если исходный сервер имеет подключенные к аппаратным контроллерам RAID диски,
то они будут видны как разделы и тома операционной системы и будут подключены к кон-
троллерам SCSI или IDE во время миграции с физической машины на виртуальную. Если
вам нужна производительность RAID, тогда вы должны обеспечить подключение к аппарат-
ному RAID тех дисковых подсистем, где хранятся файлы виртуальных жестких дисков или
тома транзитных дисков.
Ограничения по периферийным портам

Виртуальная машина сервера Windows Server 2008 Hyper-V имеет следующее ограни-
чение виртуального оборудования: два последовательных порта и ноль параллельных
портов. Последовательные порты называются подключениями именованных каналов и

не являются прямым подключением к физическим портам сервера Hyper-V. Виртуаль-
ные машины не могут подключаться к тем устройствам, которые включены в физиче-
ские последовательные порты сервера Hyper-V, но они могут подключаться через эти
именованные каналы к программным портам.
Если физический сервер имеет более двух активных последовательных портов, или в
последовательный порт сервера должно быть включено некое специализированное
устройство, то данный сервер должен быть исключен из списка кандидатов на виртуа-
лизацию.
Если физический сервер имеет подключенные к параллельным портам устройства, то
данный сервер также должен быть исключен из списка кандидатов на виртуализацию.
Параллельные порты больше не поддерживаются, поскольку физические серверы больше
не имеют таких портов. Параллельные порты использовались в основном для двух целей:
локально подключенных принтеров и аппаратных ключей (для защиты от несанкциониро-
ванного использования). Принтеры сейчас в основном имеют сетевое подключение, а ап-
паратные ключи либо имеют интерфейс USB, либо вовсе не используются.
Установка пределов по производительности

Во время фазы обнаружения вы собрали данные по производительности памяти, про-
цессора, дисков и сети. Несмотря на то, что вы можете сравнивать эти данные с огра-
ничениями производительности виртуальной машины, вам следует создать определен-
ный набор пределов, не выходя за которые физический сервер может оставаться
кандидатом на виртуализацию. Эти пределы определяют границы средней производи-
тельности виртуальной машины. Если средняя производительность физического серве-
ра превышает установленные вами пределы, то данный сервер не следует включать
в список кандидатов на виртуализацию.
Пределы производительности для кандидатов на виртуализацию можно определить как
процент имеющихся ресурсов виртуальной машины или как реальное предельное зна-
чение. Если указывается процент, то вы должны превратить его в значение (для ис-
пользования в формулах). Легко определить такие пределы, как скорость процессора
или память, поскольку это фиксированные значения. Определить пределы по пропуск-
ной способности дисков не так просто, поскольку существует много нюансов конфигу-
рирования дисковой подсистемы. Пределы по пропускной способности сети зависят от
количества сетевых адаптеров в системе. В табл. 21.2 приведены некоторые процент-
ные пределы и соответствующие значения для единичных экземпляров оборудования.
Таблица 21.2. Пределы производительности виртуальных машин
Оборудование Максимальное ограничение Предел в % Значение предела

Скорость процессора Скорость процессора сервера (на- 80 2400 МГц
пример, 3000 МГц)
Память 64 Гбайт Нет 64 Гбайт
Оборудование Максимальное ограничение Предел в % Значение предела
Дисковый ввод/вывод Предел для диска сервера 70 140 Мбит/с

(например, 200 Мбит/с)
Скорость сети 700 Мбит/с 80 560 Мбит/с

(на один адаптер)
Когда виртуальным машинам нужно масштабироваться до нескольких экземпляров

процессоров, дисков и сетевых адаптеров, то эти пределы необходимо соответственно
подстраивать под максимальное количество компонентов виртуального оборудования.
Например, поскольку виртуальная машина Hyper-V может иметь до четырех процессо-
ров, то максимальный предел по процессору будет равен значению предела для одного
процессора, умноженному на четыре.
Пределы виртуальной машины не могут превышать возможностей оборудования физи-
ческого сервера. Например, виртуальная машина может иметь максимум 64 Гбайт па-
мяти, но если сервер Hyper-V не имеет 64 Гбайт памяти, то на нем не может работать
виртуальная машина такого размера.
ВАЖНО
Поскольку производительность оборудования быстро меняется и конфигурация используе-
мого вами оборудования может влиять на реальную производительность, вам следует ус-
тановить некую точку отсчета для выбора серверного оборудования (максимальные огра-
ничения дискового и сетевого ввода/вывода). Это даст вам реалистичные значения, кото-
рые вы сможете использовать в ваших вычислениях и которые дадут вам лучшие
результаты оценки.
Оценка производительности
Реальные данные по производительности процессора, дисков и сети используются как
второй этап — чтобы определить необходимость исключения физических серверов из
списка кандидатов на виртуализацию. Следующие далее разделы по процессорам, дис-
кам и сети дают указания по оценке ограничений производительности и исключению
серверов, которые превосходят ограничение производительности.
Оценка производительности процессора

При оценке физического сервера на необходимость исключения его из списка кандида-
тов на виртуализацию по процессорным требованиям вы должны изучить использова-
ние процессора в течение всей продолжительности сбора данных. Использование
среднего значения позволяет вам при принятии решения игнорировать пиковые значе-
ния. Однако эти пиковые значения становятся очень важными на фазе планирования и
проектирования, когда вы комбинируете рабочие нагрузки для определения оптималь-
ного размещения виртуальных машин на хосте.
Сегодняшние процессоры имеют по несколько ядер, а также функцию гиперпоточности.
Процессором мы называем физический процессор с одним ядром или ядро многоядерного
процессора. Гиперпоточные логические процессоры при планировании производительности
отдельными процессорами не считаются.
Для определения среднего потребления процессора в мегагерцах (МГц) для каждого

процессора физического сервера вам нужно знать среднее использование процессора,
скорость процессора физического сервера, а также количество его ядер. После получе-
ния среднего использования процессора по каждому процессору (или ядру процессора)
физического сервера вы можете просуммировать эти значения для получения суммар-
ного среднего потребления процессора:
Суммарное среднее потребление процессора (МГц) = SUM (Скорость физического процессора
сервера × Среднее использование каждого процессора или ядра).
После получения суммарного среднего потребления процессора для физического сер-
вера (в МГц) вам нужно вычислить суммарный процессорный предел для виртуальной
машины хоста:
Суммарный процессорный предел виртуальной машины (МГц) = Предел одного процессора
(МГц) × Четыре виртуальных процессора.
Если суммарное среднее потребление процессора меньше или равно суммарному про-
цессорному пределу виртуальной машины, то физический сервер является кандидатом
на виртуализацию. Если суммарное среднее потребление процессора больше, чем сум-
марный процессорный предел виртуальной машины, то физический сервер превышает
предел и не может быть оставлен в списке кандидатов на виртуализацию.
Далее приведен примерный сценарий. У вас есть старый двухпроцессорный сервер
(с одноядерными процессорами Pentium 4 с частотой 2000 МГц), на котором работает
Windows 2000 Server. Процессор 1 имеет среднее использование 24%, а процессор 2 —
29%. Суммарное среднее потребление процессора равно (0,24×2000) + (0,29×2000), что
составит суммарное среднее потребление процессора в 1060 МГц. Ваш новый сервер
Hyper-V использует процессоры по 3,0 ГГц, поэтому предел процессорного потребле-
ния вашей виртуальной машины составит 3000 МГц для виртуальной машины с одним
процессором и 12 000 МГц для четырехпроцессорной виртуальной машины. Если пре-
дельный процент составляет 80%, то суммарное значение процессорного предела вир-
туальной машины составит 9600 МГц. Получается, что суммарное среднее потребление
процессора для физического сервера (1060 МГц) меньше, чем суммарный процессор-
ный предел виртуальной машины, так что если исходить только из производительно-
сти процессора, то этот сервер следует оставить в списке кандидатов на виртуализа-
цию.
Оценка производительности памяти

Виртуальная машина Windows Server 2008 Hyper-V имеет ограничение виртуальной
памяти в 64 Гбайт. При оценке производительности памяти вы сравниваете реальное
потребление памяти на физическом сервере с пределом памяти. При таком подходе
выявляются те физические серверы, которые имеют больше физической памяти, чем
им требуется (для этого нужны данные по производительности, которые содержат дос-

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

Производительность жестких дисков — это ключевой фактор при оценке кандидата на
виртуализацию. Сочетание на одном компьютере нескольких дисковых рабочих нагру-
зок может оказать серьезное воздействие на дисковую производительность. Правиль-
ное планирование дисковой подсистемы и оптимизация рабочих нагрузок исключи-
тельно важны, они будут описаны в главе 22.
Дисковая производительность измеряется чтением и записью (в байтах в секунду). На
фазе обнаружения вы собрали фактические и средние значения этих двух счетчиков.
Для оценки производительности сервера на предмет исключения его из списка канди-
датов на виртуализацию вам следует использовать средние показатели чтения и записи.
Использование пиковых значений может вычеркнуть из списка слишком много серве-
ров (из-за какой-нибудь аномалии дисковой производительности, произошедшей в пе-
риод сбора данных).
Диски с интерфейсом Serial Attached SCSI (SAS) обычно имеют производительность
90 Мбит/с на один диск. Большинство серверов использует подсистемы аппаратного
RAID, в которых несколько дисков объединяются для повышения дисковой произво-
дительности и защиты данных. Если принять, что в RAID-массиве имеется минимум
три диска, то общая производительность такого RAID может составить 270 Мбит/с.
Чтобы определить, не превосходит ли физический сервер предел дисковой производи-
тельности, вы должны сравнить среднее потребление диска при чтении и записи
(в байтах в секунду) на физическом сервере с пределом виртуальной машины при чте-
нии и записи, который вы установили как точку отсчета производительности оборудо-
вания сервера.
Если суммарная средняя дисковая производительность при чтении или записи меньше
или равна суммарному пределу виртуальной машины по чтению или записи, то физи-
ческий сервер является кандидатом на виртуализацию. Если же суммарная средняя
дисковая производительность при чтении или записи превышает суммарный предел
виртуальной машины по чтению или записи, то физический сервер превышает уста-
новленный предел и должен быть исключен из списка кандидатов на виртуализацию.
Оценка сетевой производительности

Во время фазы обнаружения вы собрали данные по сетевой производительности (для
операций отправки/приема в байтах в секунду) для каждого сетевого адаптера. Оценка
физического сервера на предмет возможного исключения из списка кандидатов на вир-
туализацию основана на подходе выделения сетевых ресурсов и на скорости сетевых

адаптеров сервера Hyper-V. Виртуальная машина подключается к виртуальной сети,
которая привязана к физическому сетевому адаптеру сервера. Поскольку к виртуальной
сети может быть подключено несколько виртуальных машин, то несколько виртуаль-
ных машин могут совместно использовать один и тот же сетевой адаптер сервера. Ми-
нимально рекомендуемым стандартом для сервера являются гигабитные сетевые адап-
теры Ethernet.
В главе 3 вы узнали, что виртуальный сетевой адаптер не имеет фиксированной скоро-
сти. Благодаря новой архитектуре "клиент Virtualization Services Client (VSC)/постав-
щик Virtualization Services Provider (VSP)" и шине VMBus, виртуальная машина при
помощи компонентов интеграции и синтетического сетевого адаптера может достичь
ограничения скорости физического сетевого адаптера. Вы также узнали о том, что
каждая виртуальная машина может иметь до 12 сетевых адаптеров со скоростями от
10 Мбит/с до 10 Гбит/с.
Для определения суммарной средней сетевой пропускной способности при отправ-
ке/приеме (в байтах в секунду) на физическом сервере вам нужно знать среднюю про-
пускную способность при отправке/приеме (в байтах в секунду) для каждого сетевого
адаптера. После того как вы получите среднюю пропускную способность при отправ-
ке/приеме (в байтах в секунду) для каждого сетевого адаптера физического сервера, вы
можете просуммировать эти значения для получения требования по суммарной сетевой
пропускной способности при отправке/приеме (в байтах в секунду) для сервера-
кандидата:
Суммарная средняя сетевая пропускная способность при отправке (в байтах в секунду) = SUM
(Средняя пропускная способность при отправке (в байтах в секунду) каждого сетевого адаптера).
Суммарная средняя сетевая пропускная способность при приеме (в байтах в секунду) = SUM
(Средняя пропускная способность при приеме (в байтах в секунду) каждого сетевого адаптера).
Затем вы можете получить суммарную среднюю сетевую пропускную способность:

Суммарная средняя сетевая пропускная способность (в байтах в секунду) = Суммарная средняя
сетевая пропускная способность при отправке + Суммарная средняя сетевая пропускная
способность при приеме.
Теперь, когда у вас есть суммарная средняя сетевая пропускная способность (в байтах
в секунду) для физического сервера, вы должны использовать ее для вычисления пре-
дела суммарной сетевой пропускной способности виртуальной машины для сервера
Hyper-V. Она состоит из суммы пропускной способности для всех сетевых адаптеров
виртуальной машины (в байтах в секунду). Это значение будет отличаться в зависи-
мости от скорости сетевых адаптеров сервера Hyper-V:
Суммарная сетевая пропускная способность виртуальной машины (байтов в секунду) =
= SUM (Пропускная способность каждого сетевого адаптера) (байтов в секунду).
Если суммарная средняя сетевая пропускная способность сервера-кандидата меньше

или равна суммарной сетевой пропускной способности виртуальной машины, то такой
физический сервер является кандидатом на виртуализацию. Если суммарная средняя
сетевая пропускная способность больше суммарной сетевой пропускной способности

виртуальной машины, то такой физический сервер превышает предел и должен быть
исключен из списка кандидатов на виртуализацию.
Практическим ограничением для одиночного гигабитного виртуального сетевого адаптера
является примерно 900 Мбит/с. Если предполагать, что сервер Hyper-V имеет гигабитные
адаптеры Ethernet, то рекомендуемый предел производительности сервера-кандидата
(равный 80% этого значения) составит 720 Мбит/с для одиночного виртуального сетевого
адаптера.
Во время процесса планирования вам понадобится выявить всех кандидатов, которые
имеют высокое использование сети, и (возможно) выделить для них отдельный физический
адаптер и виртуальную сеть. Это может уменьшить количество кандидатов, которое можно
разместить на сервере Hyper-V (это количество будет зависеть от количества имеющихся
на сервере сетевых адаптеров).
Оценка поддержки приложений

Ограничения по поддержке приложений используются как третий этап определения
необходимости исключения физического сервера из списка кандидатов на виртуализа-
цию. Не все приложения поддерживаются в виртуальной среде. Некоторые поставщи-
ки свое приложение в среде виртуальной машины поддерживают, но только на вирту-
альной машине конкретного поставщика (из-за ограничений виртуального оборудова-
ния, производительности и пр.).
Во время фазы обнаружения для каждого сервера была собрана информация по инвен-
таризации программного обеспечения. Эта информация является базовой для опреде-
ления возможных проблем с поддержкой приложений. Сначала вам нужно создать
уникальный список приложений, имеющихся на всех серверах (которые входят в спи-
сок серверов области действия проекта). Этот список должен содержать отдельную
позицию для каждой версии приложения (и его сервисного пакета), поскольку может
оказаться так, что поставщики предоставляют поддержку в виртуальной среде только
для определенной версии (или сервисного пакета). После создания такого уникального
списка приложений их можно начать вычеркивать из этого списка (если поставщик не
поддерживает их использование в виртуальной среде).
Для сокращения списка лучше всего начать с приложений компании Microsoft. Компа-
ния Microsoft понимала, что поддержка приложений будет для технологий виртуализа-
ции большой проблемой и заранее добавила определенные требования в свои критерии
Windows Server System Common Engineering Criteria, чтобы обеспечить поддержку в
среде виртуализации Microsoft для всех новых серверных приложений. В среде виртуа-
лизации не поддерживаются следующие приложения:
сервер Microsoft Speech Server;
роль Microsoft Exchange 2007 Unified Messaging Role.
Все остальные серверные приложения компании Microsoft на виртуальных машинах

сервера Hyper-V поддерживаются. Чтобы определить наличие поддержки для прило-
жений других поставщиков, вам придется навестить соответствующие Web-сайты или
напрямую связаться с поставщиками. Не забудьте проверить поддерживаемую версию
приложения и сравнить ее с вашим инвентаризационным списком.
Когда у вас будет список неподдерживаемых в Windows Server 2008 Hyper-V приложе-
ний, вы сможете исключить все серверы, на которых работают эти приложения.
Использование МАР
для оценки и планирования высокого уровня
В главе 20 был дан обзор инструментального набора Microsoft Assessment and Planning
(MAP) Toolkit и использования мастера Performance Metrics Wizard для сбора необхо-
димых для выполнения оценки данных по инвентаризации и производительности. Если
у вас есть все эти данные, то вы можете использовать информацию из начала этой гла-
вы для исключения серверов по аппаратным и программным проблемам. После ис-
ключения тех серверов, которые превышают конфигурацию оборудования сервера или
выполняют те приложения, которые не могут быть виртуализированы, следующий
шаг — оценка оставшихся серверов на основе данных по производительности, плани-
рование консолидации для определения необходимого количества серверов Hyper-V,
а также оформление отчетов.
В предыдущих разделах этой главы мы обсуждали оценку физического сервера-
кандидата вручную (с точки зрения оборудования, производительности и программно-
го обеспечения). МАР может выполнить оценку оборудования и производительности
из единого мастера Server Consolidation and Virtualization Wizard.
В настоящее время МАР не оценивает программные приложения на наличие поддержки
поставщика или совместимость. Для выполнения этого этапа вы можете взять данные ин-
вентаризации программного обеспечения и отфильтровать по ним список потенциальных
кандидатов, которых МАР затем оценит с точки зрения оборудования и производитель-
ности.
Выявление кандидатов на виртуализацию и сценарии

консолидации серверов
Мастер Server Virtualization and Consolidation Wizard используется для оценки виртуа-
лизации и консолидации (на базе предоставляемой вами конфигурации оборудования
сервера). Мастер выполняет для оценки следующие функции:
использует (собранные мастером Performance Metrics Wizard) данные по инвентари-
зации и производительности;
по данным о производительности исключает серверы из списка кандидатов;
позволяет вам интерактивно задавать конфигурацию сервера Hyper-V, которая бу-
дет использоваться для размещения при консолидации;
определяет количество и размещение виртуальных машин на сервере Hyper-V;

выдает подробные отчеты и предложения по виртуализации серверов с указанием
того, на каких компьютерах можно выполнить консолидацию (Virtual Server 2005
R2 или Hyper-V).
То планирование консолидации, которое МАР выполняет при помощи мастера Server
Virtualization and Consolidation Wizard, предназначено для общей оценки того, как консоли-
дация могла бы выглядеть. Оно не выполняет оптимального размещения виртуальных ма-
шин для минимизации количества требуемых серверов, оно также не проверяет, что консо-
лидируемые вами серверы взяты с одной площадки. В главе 22 вы подробнее узнаете
о подходе для подробного анализа.
Как работает мастер

Server Virtualization and Consolidation Wizard
Когда вы запустите мастер Server Virtualization and Consolidation Wizard, то первой
увидите страницу Select Virtualization Technology (рис. 21.1). Она просит указать тех-
нологию, используемую при выдаче рекомендаций по размещению серверов при кон-
солидации: Virtual Server 2005 R2 или Windows Server 2008 Hyper-V.
Рис. 21.1. Начальная страница мастера Server Virtualization and Consolidation Wizard
На странице Model Host CPU мастер запрашивает конфигурацию хост-машины, кото-

рая будет использоваться для консолидации (рис. 21.2). Вы указываете информацию по
процессору: тип ЦПУ (Intel или AMD), модель ЦПУ, количество физических процес-
соров, количество ядер на процессор, количество гиперпотоков на ядро, размер кэшей
уровня L2 и L3, а также скорость системной шины сервера.
Мастер Server Virtualization and Consolidation Wizard подразумевает, что указанная вами
конфигурация будет использоваться для всех серверов в данном сценарии оценки и консо-
лидации. Если вы хотите использовать другую конфигурацию оборудования, то должны бу-
дете запустить мастер еще раз и указать другую конфигурацию.
Рис. 21.2. Указываем данные по процессору и системной шине сервера
Теперь откройте страницу Model Host Storage (рис. 21.3). На этой странице мастер
запрашивает конфигурацию системы хранения хоста: тип диска и его скорость, ем-
кость одного диска, уровень RAID, количество дисков в RAID, а также размер кэша.
Указанные вами тип диска и его емкость будут использоваться для всех дисков масси-
ва RAID (если вы его сконфигурируете).
Последняя информация по оборудованию, которую запрашивает мастер, — это конфи-
гурация сети и памяти хоста, в том числе: скорость сетевого адаптера, количество
адаптеров, количество памяти в гигабайтах (рис. 21.4).
Рис. 21.3. Страница Model Host Storage
Рис. 21.4. Страница Model Host Network Adapters and Memory

После того как вы описали оборудование, можете на странице Set Virtual Machines
per Host задать размещение либо максимального количества виртуальных машин на
хосте, либо указать конкретное их количество (рис. 21.5). Если вы выберете максимум,
то мастер будет продолжать добавлять виртуальные машины до тех пор, пока один из
аппаратных ресурсов не превзойдет предел указанной конфигурации хоста. Если вы
выберете фиксированное количество, то мастер не будет превышать это количество
даже в том случае, если на сервере есть запас мощности.
Рис. 21.5. Страница Set Virtual Machines per Host
Теперь можете указать список серверов, для которых вы хотите выполнить процесс
оценки и консолидации, для этого нужно указать имя файла в текстовом поле на стра-
нице Import Computer Names From a File (рис. 21.6). Файл должен быть в том же са-
мом формате, который вы использовали для мастера Performance Metrics Wizard (каж-
дый сервер на отдельной строке).
Пусть функция Server Inventory найдет для вас ваши серверы
Для тех ситуаций, когда у вас либо нет полного списка серверных площадок, либо вы не
уверены в том, что именно работает на них, вы можете использовать функции Server
Inventory инструментального набора MAP Toolkit. Выбрав опцию Identify Servers That Are
Capable Of Running Windows Server 2008 в МАР, вы даете инструменту указание сделать
запрос в Active Directory и выполнить сканирование IP-адресов для получения подробной
инвентаризации серверов вашей среды (и в том числе данных по оборудованию этих сер-
веров и об инсталлированных на них ролях). При помощи этого списка вы сможете затем
выявить кандидатов для консолидации и создать список машин для сбора данных по счет-
чикам производительности. После этого вы сможете запустить мастер Server Consolidation
Wizard инструментального набора МАР Toolkit и получить рекомендации по размещению
при виртуализации.
Джэй Саулс (Jay Sauls, Senior Program Manager (Solutions Accelerators Core Engineering Team))
Рис. 21.6. Страница Import Computer Names From a File
После того как вы предоставите мастеру все необходимые входные данные, МАР ис-
пользует алгоритмы оценки и размещения для определения тех компьютеров, которые
являются кандидатами на виртуализацию, а затем пытается консолидировать их на од-
ном или нескольких хостах. Окно сообщения Status позволяет наблюдать за процессом
оценки (рис. 21.7).
Когда мастер закончит работу, он выдаст: электронную таблицу Microsoft Office Excel,
которая содержит все рекомендации по кандидатам на виртуализацию и размещение
кандидатов на хостах; а также документ Microsoft Office Word, который содержит под-
готовленное предложение со сводкой результатов консолидации.
Как работает размещение гостевых систем при виртуализации?
Рекомендации по размещению гостевых систем вычисляются в МАР в два этапа. Первый
этап — преобразование замеренных уровней использования физических машин в эквива-
лентное использование указанной гипотетической хост-машины. Например, измеренное

40-процентное использование ЦПУ на физической машине Intel Pentium 4 с частотой
2,4 ГГц может быть преобразовано в 8-процентное использование четырехъядерного ЦПУ
серии Xeon 5300 (указанного для хоста виртуализации). Эти преобразования выполняются
при помощи технологии инструмента System Center Capacity Planner (SCCP), который име-
ет библиотеку моделей оборудования. При помощи этой технологии использование ЦПУ,
дисковый и сетевой ввод/вывод преобразуются из замеренных на реальных машинах фи-
зических показателей в проектные цифры для гипотетической хост-машины.
После того как для хост-машины будут вычислены эквивалентные показатели использова-
ния ресурсов, начинается второй этап вычисления размещения. Для того чтобы хост-
машина имела достаточно ресурсов для работы гостевых систем, учитываются следующие
факторы:
• ЦПУ;
• сетевой ввод/вывод;
• ввод/вывод дисковой подсистемы;
• память;
• дисковое пространство.
Для того чтобы среда виртуализации могла справиться с гостевыми операционными сис-
темами, проводятся и другие дополнительные проверки (чтобы на сервере Virtual Server
2005 не произошло размещение гостевой операционной системы х64).
Процесс размещения начинается с выделения новой гипотетической хост-машины (Host A).
Затем на Host A размещается самая тяжело нагруженная гостевая машина. Проектный
уровень использования Host A вместе с размещенной на нем гостевой машиной вычисля-
ется ядром SCCP. Если гость размещается на хосте без избыточного использования каких-
либо ресурсов хоста, тогда делается попытка разместить на Host A следующую по уровню
использования гостевую машину. Этот процесс повторяется до тех пор, пока нельзя боль-
ше найти гостевых машин, которые можно было бы разместить на хосте. После этого вы-
деляется новый хост (Host B) и делаются попытки разместить на нем оставшиеся гостевые
системы.
Этот процесс продолжается до тех пор, пока не будут размещены все гостевые системы,
которые могут поместиться на хосте, и неразмещенных гостевых систем не останется. Гос-
тевые системы могут и не поместиться, поскольку они могут и не подходить для хоста или
потому, что для гостевой системы требуется так много ресурсов, что она перегружает ре-
сурсы хоста.
Джэй Саулс (Jay Sauls, Senior Program Manager (Solutions Accelerators Core Engineering Team))
Рис. 21.7. Окно Status

Выявление экономии расходов

Оценка экономии расходов и влияния виртуализации серверов на вашу среду — это та
задача, которую на фазе оценки пропустить никак нельзя. Каждый виртуализирован-
ный вами сервер — это либо сервер для новой рабочей нагрузки, либо кандидат на вы-
вод из эксплуатации (для экономии электроэнергии, охлаждения и пространства). Вы
можете использовать эту информацию для обоснования проекта виртуализации серве-
ров и демонстрации экономии расходов. В последующих разделах подробно описана
та информация, которую вам нужно будет собрать для вычисления (вручную) эконо-
мии расходов и коэффициента возврата инвестиций (ROI).
Компания Microsoft выпустила инструмент Virtualization ROI Tool для автоматизации этого
процесса. Дополнительную информацию вы можете найти по ссылке:
http://www.microsoft.com/virtualization/roitool/default.aspx.
Экономия капитальных затрат

По завершении выбора кандидатов на виртуализацию вы можете подсчитать потенци-
альную экономию капитальных затрат. В капитальные затраты входит стоимость фи-
зических компонентов (серверов, коммутаторов, маршрутизаторов, стоек, клавиатур-
ных переключателей, дисковых подсистем). Главным компонентом экономии капи-
тальных затрат является количество тех физических серверов, которые не придется
покупать в будущем. Когда вы виртуализируете существующие физические серверы, то
экономите капитальные затраты двумя способами. Первый — ликвидация необходи-
мости обновлять этот физический сервер в будущем. Второй — возможное уменьше-
ние количества покупаемых под серверы Hyper-V компьютеров вследствие повторного
использования освобождающегося оборудования.
Для вычисления экономии затрат по отсутствию необходимости обновления сервера
вам нужно знать время, на которое было запланировано это обновление, и расчетную
стоимость оборудования для обновления. Организации обычно имеют план обновле-
ния серверов, рассчитанный на определенный период (от двух до пяти лет, средний
срок по отрасли — пять лет). Создайте электронную таблицу со столбцами для сле-
дующих пяти лет и добавьте строку для каждого сервера-кандидата на виртуализацию.
Поместите расходы для каждого сервера в столбец соответствующего года. Теперь
подсчитайте сумму значений по столбцам, чтобы получить ежегодную экономию за-
трат по следующим пяти годам.
Для тех проектов виртуализации, в которых вы не виртуализируете существующие
серверы, а создаете при помощи виртуализации новые серверы, вычисления несколько
отличаются. В этом случае сначала вы определяете то количество физических серве-
ров, которое вам пришлось бы развернуть, а также стоимость этих серверов; так вы
получите капитальные затраты на физическое развертывание. Затем вам нужно будет
определить стандартную конфигурацию сервера, которую вы будете развертывать под
серверы Hyper-V, и узнать стоимость покупки такого сервера. Потом вы определите
количество серверов Windows Server 2008 Hyper-V, которые вам нужны для работы
всех виртуализируемых серверов. Если вы еще не делали планирование для этих сер-
веров, то для определения количества серверов вы можете принять какой-то коэффи-

циент консолидации. Умножьте требуемое количество серверов на стоимость стан-
дартного сервера для Hyper-V, и вы получите капитальные расходы на виртуализиро-
ванное развертывание. Чтобы получить потенциальную экономию капитальных затрат
от виртуализированного развертывания, вычтите расходы на виртуализированное раз-
вертывание из расходов на физическое развертывание.
Для полной оценки вам нужно учесть не только серверы, но и сопутствующую перифе-
рию (такую, как дисковые шкафы, клавиатурные переключатели, сетевые коммутато-
ры), а также прочие монтируемые в стойки устройства, которые подключаются к тем
серверам, которые больше не понадобятся (после их виртуализации). К сожалению,
сбор такой информации в автоматическом режиме — задача непростая, поскольку на
таких устройствах обычно отсутствует операционная система и в Active Directory они
не значатся.
Если вы хотите учесть и эту информацию, то можете использовать два подхода. Пер-
вый подход — сделать оценку по количеству виртуализируемых вами серверов. Если
стандартный (используемый в центре обработки данных) клавиатурный переключатель
имеет восемь портов, то можно считать, что вы ликвидируете один клавиатурный пе-
реключатель на каждые восемь виртуализируемых серверов. Этот же подход вы може-
те использовать и для сетевых коммутаторов. Для дисковых шкафов такой подход про-
блематичен (если нет определенных стандартов на развертывание серверов — когда вы
знаете, что каждый сервер модели Х был развернут вместе с дисковым шкафом Y). До-
полнительная проблема такого подхода — вы не имеете понятия о том, где именно вы
ликвидируете данное устройство.
Второй подход требует от вас выполнения физической инвентаризации по каждому
серверу из списка кандидатов на виртуализацию, чтобы выявить те подключенные пе-
риферийные устройства, которые будут ликвидированы. Второй вариант более точный
и дает информацию о местонахождении устройств, но он занимает больше времени и
стоит дороже.
После того как вы примете решение относительно используемого подхода, вам нужно
будет определить стандартную цену закупки для каждого из этих устройств и количе-
ство ликвидируемых устройств, чтобы вычислить потенциальную экономию затрат по
вспомогательным периферийным устройствам.
Экономия на среде
На фазе обнаружения вы должны были выявить всех изготовителей серверов и все мо-
дели серверов. Если вы не собрали информацию по использованию стоечного про-
странства и потреблению энергии для каждого сервера, то вам придется навестить
Web-сайт изготовителя и получить там эту информацию. Когда у вас будет эта инфор-
мация для всех моделей серверов, вы сможете подсчитать экономию на среде.
Экономия стоечного пространства

Стандартная стойка центра обработки данных имеет высоту в 42U. Сервер обычно
имеет размер от 1U до 10U. Поэтому количество серверов в стойках разное (но количе-
ство единиц высоты у стойки постоянное). Для вычисления экономии стоечного про-
странства вы можете предположить, что в каждой стойке пространство используется

полностью. Если стойки заполнены не полностью, то ваше вычисление количества ос-
вобождаемых (после виртуализации серверов) стоек фактически даст даже несколько
заниженный результат.
Для вычисления количества сэкономленного стоечного пространства нужно опреде-
лить, сколько серверов каждого производителя вы будете виртуализировать, умножить
это количество на используемое сервером пространство, а затем сложить эти значения.
Для вычисления количества освобождаемых (в центре обработки данных) стоек (стан-
дартных стоек размером 42U) возьмите это суммарное количество сэкономленного
стоечного пространства и разделите его на 42.
Потребление электроэнергии
Для работы каждому серверу нужна электроэнергия, а большинство серверов работает
24 часа в день и 365 дней в году (хочется на это надеяться). Большая часть серверов
спроектирована с таким источником питания, который может обеспечивать полностью
укомплектованную систему, поэтому источник питания работает с эффективностью
всего лишь примерно 75%. В своих вычислениях вы вполне можете использовать но-
минальное значение мощности источника питания в ваттах.
Для вычисления потребления энергии каждым сервером вам нужно также знать стои-
мость киловатт-часа электроэнергии. Все ваши площадки наверняка имеют разную
стоимость киловатт-часа, так что вам придется собрать эту информацию. В приведен-
ных нами примерах используется среднее значение.
После того как вы получите потребление энергии для каждого сервера, количество
серверов, а также стоимость киловатт-часа электроэнергии, вы сможете по формулам
определить суммарную экономию расходов при виртуализации ваших серверов. Пер-
вая формула — это суммарное количество энергии, потребляемое данной моделью
сервера в течение года (в киловатт-часах) при непрерывной его работе:
Потребление энергии сервером за год (в киловаттах) = (Номинальное значение источника
питания × 365 × 24)/1000.
После вычисления потребления для модели сервера вы можете определить суммарное
потребление (путем умножения на количество серверов этой модели и вычисления
суммы):
Суммарное потребление энергии в год (в киловаттах) = SUM (Потребление энергии сервером
данной модели за год × Количество серверов).
Теперь у вас есть суммарное потребление энергии за год по всем вашим кандидатам на
виртуализацию (в киловатт-часах). Для того чтобы получить стоимость электроэнер-
гии, умножьте это значение на среднюю стоимость киловатт-часа:
Суммарная экономия затрат за год = Суммарное потребление энергии в год × Средняя стоимость
киловатт-часа.
Для примера предположим, что в списке кандидатов на виртуализацию есть 500 серве-
ров, каждый сервер имеет блок питания с номиналом 750 Вт, а стоимость киловатт-
часа равна 0,1 доллара:
Потребление энергии сервером за год = (750 × 365 × 24)/1000 = 6570 кВт.

Суммарное потребление энергии в год = 6570 × 500 = 3 285 000 кВт.
Суммарная экономия затрат за год = 3 285 000 × 0,1 = 385 000 долларов.
Расходы на охлаждение
В дополнение к расходам электроэнергии на нормальную работу серверов, серверы
также выделяют тепло, которое необходимо рассеивать. Поскольку серверы работают
постоянно, то они и тепло выделяют постоянно, следовательно, и охлаждение должно
производиться постоянно. Для простоты вычисления стоимости охлаждения вы можете
допустить, что каждый израсходованный сервером ватт энергии генерирует один ватт
тепла, которое необходимо рассеять.
Инженерам и ученым пока не удалось создать такую систему охлаждения, которая
имела бы эффективность 100%, поэтому показатель эффективности 60—70% можно
считать достаточно консервативным. Это означает, что если вам нужно рассеять
1 000 000 кВт тепла, а эффективность вашей системы охлаждения составляет 65%, то
вам потребуется 1 000 000/0,65 = 1 538 461 кВт энергии на охлаждение.
Используя цифры из предыдущего примера на 500 серверов (годовое потребление
электроэнергии в 3 285 000 кВт и предположение о том, что один ватт энергии порож-
дает один ватт тепла), мы получим 3 285 000 кВт тепла для рассеивания. При
65-процентной эффективности системы охлаждения на охлаждение серверов потребу-
ется ежегодно 5 053 846 кВт энергии. При стоимости 0,1 доллара за киловатт-час эко-
номия расходов на охлаждение составит 505 385 долларов.
ВАЖНО
Для получения более точных показателей экономии расходов не забудьте вычесть из них
стоимость пространства, электроэнергии и охлаждения для серверов Hyper-V.
Инструмент Microsoft Virtualization Return on Investment (ROI), доступный по ссылке:
http://www.microsoft.com/virtualization/roitool/default.mspx, поможет вам оценить потен-
циальную экономию на вашей среде, но он не будет использовать для этого вычисления
реальные данные ваших серверов-кандидатов на виртуализацию.
Для того чтобы помочь вам в сборе информации по экономии затрат и подготовке сводки
экономии затрат, в каталог Job Aids помещена электронная таблица MS Excel под названи-
ем Potential Cost Savings JobAid.xls. Эта электронная таблица имеет страницу, которая со-
держит рекомендуемую для сбора информацию и некоторые вычисления для подсчета по-
тенциальной экономии затрат по серверам и элементам среды (по электроэнергии, охлаж-
дению и стоечному пространству). Эта электронная таблица не учитывает стоечное
пространство, электроэнергию и охлаждение новых серверов.
Резюме
Данная глава описала подход к третьей фазе проекта виртуализации — фазе оценки.
Оценка занимается тем, что берет список потенциальных кандидатов на виртуализа-
цию серверов и определяет, какие серверы следует удалить из этого списка (в соответ-
ствии с ограничениями по оборудованию, производительности, а также по поддержке
программного обеспечения). Вы узнали, как устанавливать пределы производительно-
сти и как использовать эти пределы для принятия решений об исключении из списка.
Для того чтобы минимизировать трудозатраты оценки собранных на стадии обнаруже-
ния данных по производительности, в этой главе был дан пример сценария использо-
вания мастера Server Virtualization and Consolidation Wizard приложения Microsoft
Assessment and Planning (MAP) для выполнения оценки кандидатов на виртуализацию
и планирования консолидации. После обработки всех серверов список оставшихся
кандидатов на виртуализацию будет использоваться на следующей фазе проекта вир-
туализации — фазе планирования и проектирования. На этой фазе вы возьмете полу-
ченное из МАР общее планирование консолидации и проведете подробный анализ и
оптимизацию рабочих нагрузок.
В дополнение к изучению оценки сервера на предмет виртуализации вы узнали также и
о том, как использовать информацию по виртуализации и среде для вычисления эко-
номии расходов по серверам, стоечному пространству, электроэнергии и охлаждению.

критерии Windows Server System Common Engineering Criteria, доступные по ссылке:
http://www.microsoft.com/windowsserversystem/cer/default.mspx;
список серверного программного обеспечения Windows, не поддерживаемого в сре-
де виртуализации компании Microsoft, доступен по ссылке:
http://support.microsoft.com/kb/897614;
инструмент Microsoft Virtualization ROI Tool, доступный по ссылке:
http://www.microsoft.com/virtualization/roitool/default.aspx;
приложение Microsoft Assessment and Planning (MAP), доступное по ссылке:
http://technet.microsoft.com/en-us/library/bb977556.aspx.
ГЛАВА 22

фаза планирования
и проектирования
Фаза планирования и проектирования проекта виртуализации серверов состоит из трех
основных частей: определение требований к конфигурации сервера Hyper-V (для под-
держки миграции кандидатов на виртуализацию), определение наилучшей консолида-
ции рабочих нагрузок кандидатов (для максимизации количества виртуальных машин
на сервер Hyper-V), а также проектирование общих требований к среде виртуализации.
Главная цель консолидации серверов — максимизация количества работающих на од-
ном сервере виртуальных машин. Количество работающих на физическом сервере вир-
туальных машин называется коэффициентом консолидации. Чем выше коэффициент
консолидации, тем ниже капитальные затраты на инфраструктуру виртуализации.
Планирование консолидации серверов может выполняться по двум разным стратегиям.
Первая стратегия состоит в составлении спецификации оборудования сервера Hyper-V
и последующем определении потенциально достижимого коэффициента консолида-
ции. Вторая стратегия — установление желаемого коэффициента консолидации и по-
следующее определение требуемой спецификации сервера Hyper-V. В табл. 22.1 указа-
ны все "за" и "против" обеих стратегий.
Таблица 22.1. Стратегии консолидации
Стратегия
"За" "Против"
консолидации
Составление специфи- • Возможность использования • Более низкая степень оптимизации

кации оборудования и стандартных конфигураций рабочих нагрузок
получение коэффициен-
та консолидации • Более низкая стоимость • Отсутствие возможности оптимиза-
поддержки ции конфигурации оборудования
Установление коэффи- • Более высокий коэффициент • Все серверы имеют нестандартные
циента консолидации и консолидации конфигурации
получение требований
к оборудованию • Более высокая оптимизация • Более высокая стоимость поддержки
рабочих нагрузок
• Более сложный процесс планирова-
ния
Первая стратегия упрощает процесс планирования, при этой стратегии задается специ-
фикация оборудования сервера Hyper-V, включая: количество ЦПУ, количество памя-
ти, объем дискового пространства, количество дисков, количество сетевых адаптеров
(а также их скорость). Это дает целый набор аппаратных ограничений, которые вы мо-
жете использовать для выполнения оптимизации рабочих нагрузок. Для оптимизации
необходимо определить такое сочетание рабочих нагрузок кандидатов на виртуализа-
цию, которое максимизирует использование ресурсов (без превышения ограничений
производительности). Несмотря на то, что в управлении одинаковыми серверами
Hyper-V есть определенные преимущества, эта стратегия может и не дать таких соче-
таний рабочих нагрузок, которые полностью оптимизируют использование ресурсов.
По второй стратегии составляются оптимизированные сочетания рабочих нагрузок,
которые и определяют требования к оборудованию сервера Hyper-V. По существу вы
начинаете с указания целевого значения коэффициента консолидации. Например, если
вы установите себе в качестве цели 20 виртуальных машин на одном сервере Hyper-V,
то коэффициент консолидации составит 20 к 1. При планировании консолидации вы
определяете такой набор из 20 кандидатов на виртуализацию, который дает самое низ-
кое использование ресурсов при сочетании их рабочих нагрузок. Суммарные требова-
ния по производительности этого набора рабочих нагрузок определят и требования к
оборудованию сервера Hyper-V (и в том числе к спецификациям процессора, памяти,
дисков, а также сетевых карт). При этой стратегии основные преимущества таковы:
достигается требуемый коэффициент консолидации, а конфигурация оборудования
серверов Hyper-V приспособлена для поддержки работы с заданной конфигурацией
рабочих нагрузок. Однако управление такими серверами Hyper-V может быть более
сложным и более дорогим, поскольку вам придется поддерживать нестандартные кон-
фигурации оборудования.
Как это чаще всего и бывает, выбор наилучшей стратегии для вашей среды состоит в
анализе компромиссов и принятии такого решения, которое позволит вам достичь ва-
ших целей (бюджетных, бизнеса и технических). Использование стандартных конфи-
гураций оборудования упрощает процесс конфигурирования и увеличивает вероят-
ность получения скидок у поставщиков оборудования, но не всегда обеспечивает оп-
тимальный коэффициент консолидации и дает более низкое использование ресурсов.
Установка коэффициента консолидации обеспечивает оптимальную для поддержки
рабочих нагрузок конфигурацию оборудования, но может привести к повышению ка-
питальных затрат и расходов на управление. В этой главе вы изучите процесс консоли-
дации по первой стратегии, когда используются серверы Hyper-V со стандартными
спецификациями оборудования, а затем выполняется планирование для максимизации
коэффициента консолидации в среде данного типа.
Определение конфигурации
Перед началом процесса планирования консолидации вы должны задать конфигура-
цию оборудования Hyper-V. Конфигурация оборудования и ее характеристики произ-
водительности формируют те ограничения, которые вы должны учитывать при комби-
Глава 22. Проект виртуализации серверов: фаза планирования и проектирования 729
нировании кандидатов на виртуализацию для получения оптимизированных консоли-

дированных рабочих нагрузок. В течение проекта консолидации серверов вы, скорее
всего, будете виртуализировать физические серверы на нескольких площадках (при
этом на разных серверах Hyper-V окажется разное количество виртуальных машин).
Для учета этих изменений коэффициента консолидации вам следует задать как мини-
мум три стандартных конфигурации оборудования сервера Hyper-V: сервер небольшо-
го размера (для филиалов); сервер среднего размера (для средних офисов или неболь-
ших центров обработки данных); большой сервер (для больших центров данных).
Основная часть небольших площадок (таких, как филиалы) обычно будет иметь не
больше четырех кандидатов на виртуализацию, офис (или небольшой центр обработки
данных) может иметь 20 или более кандидатов, а большой центр обработки данных
может иметь сотни (или тысячи) кандидатов на виртуализацию.
Физические требования
Спецификации сервера Hyper-V могут быть очень разными, поскольку сервер Microsoft
Hyper-V поддерживает до 192 виртуальных машин на одном сервере. При сегодняшней
доступности 64-битных четерехъядерных процессоров Intel и AMD, сетей хранения
данных SAN, жестких дисков с интерфейсом SCSI и SAS (со скоростями вращения
10 и 15 тысяч оборотов в минуту) и гигабитных адаптеров Ethernet можно создать
множество различных конфигураций.
Hyper-V поддерживает процессоры х64 производства Intel и AMD, но не поддерживает про-
цессоры Intel Itanium.
Даже с учетом самых последних достижений серверных технологий, процессоры и па-

мять современных серверов будут (при планировании консолидации) естественным
ограничением. Большая часть серверов предприятий представляет собой одно-двух-
четырехпроцессорные конфигурации с одним, двумя или четырьмя ядрами на процес-
сор. Четерехпроцессорный четырехъядерный сервер имеет, таким образом, максимум
16 процессорных ядер. Кроме того, предельное количество памяти на новейших типах
серверов зависит от скорости памяти. Более медленная память позволяет вам исполь-
зовать модули памяти большей плотности. Типичный предел по памяти составляет
128 Гбайт, и очень мало систем поддерживает 256 Гбайт памяти.
В табл. 22.2 приведены рекомендуемые минимальные конфигурации для небольшого,
среднего и большого серверов Hyper-V. Здесь предполагается, что виртуальные маши-
ны имеют минимум 1 Гбайт памяти, еще 1 Гбайт памяти зарезервирован для родитель-
ского раздела, одно процессорное ядро также зарезервировано для родительского раз-
дела, один сетевой адаптер выделен для обмена родительского раздела и один или не-
сколько адаптеров выделены для обмена виртуальных машин. Для небольших серверов
рекомендуется использовать непосредственно подключенные к ним диски (DAS) —
это дешевле и проще в управлении. Предполагается, что средние и большие серверы
находятся на таких площадках, где предпочтительнее использовать сети хранения дан-
ных SAN.
Таблица 22.2. Рекомендуемые минимальные конфигурации оборудования серверов
Память,
Сервер Процессор Диск Сетевой адаптер
Гбайт
Небольшой 1 двух- или четырехъядер- 8 DAS 2 гигабитных адаптера Ethernet

ный
Средний 2 четырехъядерных 32 SAN 5 гигабитных адаптеров Ethernet
Большой 4 четырехъядерных 64 SAN 8 гигабитных адаптеров Ethernet
Требования по высокой готовности

Переход от среды с выделенными физическими компьютерами (выполняющими при-
ложения и службы) к наборам консолидированных рабочих нагрузок (работающим на
виртуальных машинах одного сервера) ставит следующие вопросы:
Являются ли требующие высокой готовности рабочие нагрузки вероятными канди-
датами на виртуализацию?
Как защититься от сбоя оборудования, который может затронуть сразу несколько
виртуальных машин и сотни (или тысячи) конечных пользователей?
Как инсталлировать обновления и сервисные пакеты на сервер Hyper-V без влияния
на виртуальные машины и без прерывания обслуживания ими конечных пользова-
телей?
К счастью, Hyper-V поддерживает решение для обеспечения высокой готовности сер-
вера Microsoft Windows Server 2008, которое позволяет сконфигурировать отказоустой-
чивые кластеры из серверов Hyper-V и виртуальных машин. Кластер хостов Hyper-V на
базе Windows Server 2008 поддерживает до 16 узлов. Кластеры виртуальных машин на
базе Windows Server 2003 поддерживают до восьми узлов. Если в качестве гостевой
операционной системы виртуальной машины используется Windows Server 2008, то
поддерживаются кластеры до 16 узлов.
Кластеры виртуальных машин поддерживаются только при размещении всех узлов класте-
ра на разных серверах Hyper-V. Если несколько узлов кластера виртуальных машин рабо-
тает на одном сервере Hyper-V, тогда эти узлы являются единственной точкой отказа, что
ликвидирует все преимущества решения высокой готовности.
Кластеры виртуальных машин для совместно используемых дисков кластера должны ис-
пользовать iSCSI.
Для создания кластера хостов Hyper-V нужно использовать как минимум два узла.
Каждый узел должен работать под управлением версии Windows Server 2008 Enterprise
(или более высокой), поскольку отказоустойчивая кластеризация в версии Windows
Server 2008 Standard отсутствует. После инсталляции и конфигурирования узлов вирту-
альные машины могут передавать при сбое управление между узлами. Использование
трех или четырех узлов позволяет отказоустойчивому кластеру использовать баланси-
рование нагрузок, что обеспечивает отсутствие перегрузок одного из узлов передан-

ными на него при сбоях рабочими нагрузками.
При консолидации на одном физическом сервере нескольких рабочих нагрузок настоя-
тельно рекомендуется использовать отказоустойчивую конфигурацию (для минимиза-
ции перерывов в обслуживании, которые могут затронуть большое количество конеч-
ных пользователей). Даже если большая часть ваших физических серверов в настоящее
время не требует применения решений по высокой готовности, вам следует оценить,
какие консолидированные рабочие нагрузки потребуют конфигураций высокой готов-
ности в планируемой вами инфраструктуре виртуализации.
Более подробную информацию по кластеризации хостов (по ее возможностям и инсталля-
ции) см. в главе 5. Вы можете также найти документ по быстрой миграции с помощью
Hyper-V по ссылке:
http://www.microsoft.com/windowsserver2008/en/us/high-availability.aspx.
Планирование консолидации
При планировании консолидации производится определение требуемого для поддерж-
ки рабочих нагрузок количества серверов Hyper-V. Количество требуемых серверов
Hyper-V зависит от предопределенных групп кандидатов на виртуализацию. Эти груп-
пы могут описывать физическое местоположение, стратегию администрирования и
безопасности, а также ограничения приложений. После того как вы определите группы
кандидатов на виртуализацию, вы начнете процесс определения таких комбинаций ра-
бочих нагрузок кандидатов, которые дают самый высокий коэффициент консолидации.
Затем (после определения этих комбинаций рабочих нагрузок) вы можете продумать,
оборудование каких серверов-кандидатов можно повторно использовать в качестве
серверов Hyper-V.
Планирование консолидации серверов
Планирование консолидации серверов — это ключевой элемент успеха проекта; в зависи-
мости от планирования вы можете либо достичь целей вашего проекта, либо не достичь и
получить разочарованных клиентов. Вы должны обязательно документировать все пред-
положения. Все, что допускается в качестве факта, и все то, что влияет на вычисления при
консолидации, — чрезвычайно существенно для обоснования бюджета, который будет по-
лучен по результатам планирования. Вам следует также постоянно держать под рукой биз-
нес-план проекта консолидации и регулярно сверяться с ним, чтобы не упускать из виду
цели и представление проекта.
Марк Лундэй (Mark Lunday, Project Manager (Microsoft Consulting Services))
Группировка кандидатов
Перед тем как при планировании консолидации приступать к фазе анализа рабочих
нагрузок, вы должны определить все ограничения группирования, которые влияют на
список кандидатов на виртуализацию (это список физических серверов, выявленных на
фазе оценки проекта виртуализации).
Вот эти ограничения:

физическое местоположение;
стратегия администрирования и безопасности;
приложения.
Группы по физическому местоположению определяют количество планируемых сер-
веров Hyper-V для каждой площадки. Если во время проекта виртуализации вы не кон-
солидируете площадки, то не сможете скомбинировать рабочие нагрузки на одном сер-
вере. Поэтому до того как определить группы по местоположению, не забудьте учесть
планируемую консолидацию площадок. Поскольку информация о местоположении
получена при сборе данных по серверам (во время фазы обнаружения), то консолида-
цию площадок также следует отразить в этих данных.
Группы по администрированию и безопасности могут потребоваться в том случае, если
вы хотите реализовать безопасность на уровне серверов (а не на уровне виртуальных
машин). Безопасность на уровне серверов означает, что вы создаете в Active Directory
глобальную группу для команды администрирования, помещаете эту группу в группу
локальных администраторов сервера Hyper-V, а затем размещаете на этом сервере
только те виртуальные машины, которыми данная административная группа имеет
право управлять. Несмотря на то, что такие группы администрирования и безопасности
технически создать возможно и это часто делается, такой подход приводит к менее
гибкому использованию ресурсов сервера Hyper-V и может увеличить необходимое
количество серверов Hyper-V. Он также исключает реализацию таких отказоустойчи-
вых кластеров серверов Hyper-V, на которых работают управляемые разными коман-
дами администрирования виртуальные машины.
Использование безопасности на уровне виртуальных машин дает максимально гибкую
конфигурацию серверов Hyper-V. Однако оно требует более сложной настройки и
управления.
Подробное описание обеспечения безопасности доступа к серверам Hyper-V и виртуаль-
ным машинам см. в главе 6.
Группы по приложениям могут потребоваться в том случае, когда вы хотите мигриро-

вать на сервер Hyper-V те серверы, которые выполняют одно и то же приложение. Вы
можете также использовать группы для определения тех приложений, которые не
должны работать на одном сервере (из соображений безопасности или производитель-
ности). Группы по приложениям могут быть двух видов: выделенные и совместные.
Выделенная группа позволяет размещать на данном сервере Hyper-V только те вирту-
альные машины, на которых работает одно и то же приложение. Совместная группа
позволяет размещать на одном сервере комбинацию таких виртуальных машин, на ко-
торых работают разные приложения. В совместной группе обычно задается предельное
значение для количества комбинируемых приложений.
Анализ рабочих нагрузок

Анализ рабочих нагрузок — это процесс комбинирования информации по оборудова-
нию и производительности нескольких кандидатов на виртуализацию для достижения
заданных пределов по оборудованию и производительности сервера Hyper-V. Для это-

го вы должны определить пределы для конфигураций серверов Hyper-V, собрать дан-
ные для каждой группы кандидатов на виртуализацию, а также выполнить некоторые
вычисления для определения оптимальных комбинаций кандидатов.
Установление ограничений
Во время фазы оценки проекта виртуализации вы установили набор пределов для оп-
ределения, является ли физический сервер хорошим кандидатом на виртуализацию.
Тогда нужно было обеспечить, что кандидат на виртуализацию будет иметь приемле-
мую производительность после миграции в виртуализированную среду. Во время ана-
лиза рабочих нагрузок вам нужно установить пределы для всего сервера Hyper-V. Эти
пределы будут также определять резерв ресурсов сервера. Резервные ресурсы сервера
Hyper-V будут использоваться сервером Hyper-V для обслуживания локальных потреб-
ностей и как дополнительная мощность при возникновении всплесков использования
ресурсов.
Пределы определяются для четырех основных компонентов сервера Hyper-V: процес-
сор, память, система хранения и сеть. В табл. 22.3 приведен набор примерных преде-
лов. Для тех компонентов оборудования, которые могут иметь несколько экземпляров
(таких, как процессор, диск и сеть), показанные значения относятся к одному экземп-
ляру оборудования. Операции ввода/вывода системы хранения ограничены производи-
тельностью дисков и дисковых контроллеров. Производительность сетевого интерфей-
са ограничена частотой коллизий сети и конфигурацией драйверов.
Таблица 22.3. Примеры пределов сервера Hyper-V
Оборудование Предел
Использование процессора 80% от максимальной процессорной мощности

Использование физической 80% от максимальной физической памяти
памяти
Дисковый ввод/вывод 75% от максимальной пропускной способности дискового контрол-
лера
Сетевой ввод/вывод 80% от максимальной пропускной способности сетевого адаптера
Тестируйте производительность ваших серверов Hyper-V
Максимальные значения пропускной способности дисков и сети могут сильно отличаться
в зависимости от изготовителя, качества драйверов, конфигурации и типа технологии. Не
следует делать анализ рабочих нагрузок, опираясь на предположительный уровень произ-
водительности. Лучшая практика — выполнить тестирование производительности обору-
дования Hyper-V, чтобы получить реалистичные показатели производительности. Исполь-
зование этих значений даст гораздо более высокие результаты планирования мощности,
чем использование теоретических максимальных значений.
Кен Дариган (Ken Durigan, Architect (Microsoft Consulting Services))
После установления пределов для серверов Hyper-V вы определяете пределы и для

каждой категории физических серверов. В табл. 22.4 дан пример пределов для категории
"небольшой сервер". Конфигурация оборудования этого сервера принимается такой:

один четырехъядерный процессор, 8 Гбайт памяти, один дисковый контроллер с мак-
симальной пропускной способностью 320 Мбит/с и один выделенный для использова-
ния виртуальными машинами гигабитный сетевой адаптер Ethernet с максимальной
пропускной способностью 900 Мбит/с. Значения пределов вычисляются по формуле:
Значение предела = (Максимальное значение × Количество × Предельный процент) / 100.
Максимальное значение — это максимальное значение производительности одного
экземпляра компонента (например, процессор 3,0 ГГц). Количество — это количество
экземпляров компонента, которое доступно для использования виртуальными маши-
нами (например, "небольшой сервер" имеет четыре процессорных ядра, но одно из них
зарезервировано под родительский раздел, поэтому для виртуальных машин остается
три). Предельный процент — это предел производительности, установленный для того,
чтобы родительский раздел имел резерв по ресурсам.
Таблица 22.4. Значения пределов для категории "небольшой сервер"
Количество
Предельный Максимальное для использования Значение
Ограничение
процент значение виртуальными предела
машинами
Процессор 80 3000 МГц 3 7200 МГц

Память 80 8 Гбайт 1 6,4 Гбайт
Дисковый контроллер 75 320 Мбит/с 1 240 Мбит/с
Сетевой адаптер 80 900 Мбит/с 1 720 Мбит/с
В табл. 22.5 приведены примеры пределов для категории "средний сервер". Конфигу-
рация этого сервера предполагается такая: два четырехъядерных процессора (одно яд-
ро зарезервировано для родительского раздела), 32 Гбайт памяти, два дисковых кон-
троллера с максимальной пропускной способностью 320 Мбит/с каждый, а также
четыре выделенных для виртуальных машин гигабитных адаптера Ethernet с макси-
мальной пропускной способностью 900 Мбит/с каждый.
Таблица 22.5. Значения пределов для категории "средний сервер"
машинами
Процессор 80 3000 МГц 7 16 800 МГц

В табл. 22.6 приведены примеры пределов для категории "большой сервер". Конфигу-
рация этого сервера предполагается такая: четыре четырехъядерных процессора (два
ядра зарезервировано для родительского раздела), 64 Гбайт памяти, четыре дисковых

контроллера с максимальной пропускной способностью 320 Мбит/с каждый, а также
семь выделенных для виртуальных машин гигабитных адаптеров Ethernet с макси-
мальной пропускной способностью 900 Мбит/с каждый.
Таблица 22.6. Значения пределов для категории "большой сервер"
машинами
Процессор 80 3000 МГц 14 33 600 МГц

Предварительная обработка данных

После того как вы определите значения пределов для каждой категории серверов и вы-
явите группы кандидатов на виртуализацию, можете собрать необходимую информа-
цию по инвентаризации и производительности и сделать предварительную обработку
данных (до начала анализа нагрузок). В табл. 22.7 перечислены все те значения, кото-
рые вам нужно получить из собранных на фазе обнаружения данных. Для вычисления
того значения, которое будет сравниваться со значением предела, необходимы и дан-
ные по инвентаризации, и данные по производительности. Например, данные по про-
изводительности процессора собирались как счетчик процента процессорного времени
(для каждого процессора системы). Для преобразования этих данных в значение, кото-
рое можно будет сравнить с пределом, вы должны умножить процент процессорного
времени для каждого процессора на скорость процессора в мегагерцах (чтобы полу-
чить реальные мегагерцы, потребляемые каждым процессором). Затем вы должны про-
суммировать все процессорные значения и получить суммарное потребление процес-
сорных мегагерцев.
Таблица 22.7. Категории и параметры производительности
Категория производительности Параметры
Процессор • Скорость процессора в мегагерцах

• Процент процессорного времени для каждого экземп-
ляра процессора
Память • Количество байтов доступной памяти
• Общее количество физической памяти
Сеть (для каждого экземпляра адаптера) Суммарное количество байтов в секунду
Диск (для каждого физического диска) • Количество прочитанных диском байтов в секунду
• Количество записанных диском байтов в секунду
Сбор данных по производительности рекомендуется производить с интервалом в пять

минут в течение 30-дневного периода. Несмотря на то, что при анализе рабочих нагру-
зок вы могли бы использовать все эти 8640 значений, это существенно увеличило бы
время анализа. Для упрощения процесса анализа и уменьшения времени, которое мо-
жет уйти на проверку всяческих предположений, вам следует усреднить значения дан-
ных. Вы можете усреднять значения по разным периодам времени, но рекомендуемый
минимум — один час, а рекомендуемый максимум — один день.
Вычисления для анализа рабочих нагрузок

Анализ рабочих нагрузок выполняется отдельно для каждой группы кандидатов на
виртуализацию. При этом комбинируются различные серверные рабочие нагрузки, и
суммарная рабочая нагрузка сравнивается с пределами ресурсов. Используемые вами
пределы берутся по той категории серверов, которая требуется для анализируемой ва-
ми группы виртуализации. Анализируются ресурсы процессора, памяти, системы хра-
нения и сети.
Самый простой способ комбинирования рабочих нагрузок и сравнения их со значе-
ниями пределов — использовать диаграммы Microsoft Excel или специальный отчет
SQL Reporting Services (в зависимости от того, как хранятся данные).
Используя Microsoft Excel, вы можете создать диаграммы, которые отображают произ-
водительность по времени для всех нагрузок (в виде диаграммы накопления). Диа-
граммы накопления позволяют вам комбинировать данные нескольких рядов (с сум-
мированием). Эти данные рисуются вместе со значением ограничения, чтобы опреде-
лить, не превосходит ли использование ресурсов (комбинированными рабочими
нагрузками) заданного предела. На рис. 22.1 показан пример двумерной диаграммы
накопления для рабочих нагрузок процессора за 30-дневный период. В этом примере
процессорная рабочая нагрузка скомбинирована по четырем серверам, которые будут
мигрировать на сервер категории "небольшой сервер". Диаграмма показывает, что
комбинированная рабочая нагрузка не превосходит предела в 7400 МГц.
Рис. 22.1. Пример диаграммы с накоплением процессорной нагрузки от четырех серверов

В процессе анализа рабочих нагрузок производится выбор данных по серверам (по од-
ному серверу) и добавление их к рабочей нагрузке сервера Hyper-V. По мере того как
вы выбираете серверы-кандидаты и добавляете их на диаграмму рабочих нагрузок,
становится видна тенденция накопления рабочих нагрузок. По мере добавления на
диаграмму дополнительных серверов анализируйте каждую диаграмму, чтобы опреде-
лить, не превышен ли предел.
На рис. 22.2—22.4 показаны диаграммы рабочих нагрузок памяти, дисков и сети соот-
ветственно (для показанных на рис. 22.1 четырех серверов). Если вы проанализируете
каждую из этих диаграмм, то увидите, что рабочие нагрузки по дискам и памяти пре-
высили значения пределов, а нагрузка на сеть — нет.
Рис. 22.2. Пример диаграммы с накоплением для рабочих нагрузок на память (для четырех серверов)
Рис. 22.3. Пример диаграммы с накоплением для рабочих нагрузок на диски (для четырех серверов)
Рис. 22.4. Пример диаграммы с накоплением для рабочих нагрузок на сеть (для четырех серверов)
Если предел производительности превышен, то у вас есть два варианта:

удалить сервер из списка, чтобы снизить нагрузку так, чтобы она упала ниже преде-
ла, а затем определить набор оставшихся серверов в качестве набора консолидации;
модифицировать набор серверов, чтобы определить, не будет ли другая комбинация
рабочих нагрузок серверов более эффективной.
Для максимизации коэффициента консолидации для каждого сервера и получения оп-
тимального размещения рабочих нагрузок следует использовать второй вариант — пе-
ребирать возможные комбинации рабочих нагрузок серверов. Когда вы определите,
что данная комбинация серверов максимально близка к заданным пределам (но не пре-
восходит их), то вы должны удалить эти серверы из списка кандидатов на виртуализа-
цию и присвоить этот консолидированный набор серверу Hyper-V. Затем необходимо
повторить все шаги анализа для оставшихся в списке серверов (до тех пор, пока все
рабочие нагрузки серверов не будут присвоены серверам Hyper-V).
После завершения анализа рабочих нагрузок всех серверов из всех групп кандидатов
на виртуализацию вы сможете определить то количество серверов (в каждой катего-
рии), которое потребуется для проекта виртуализации. Эта информация поможет вам
при составлении более точной оценки предварительного бюджета на покупку сервер-
ного оборудования.
Для выполнения анализа рабочих нагрузок вы найдете в каталоге Job Aids электронную
таблицу Microsoft Excel с названием Workload Analysis Jobaid.xls. Эта электронная таблица
имеет несколько страниц и диаграмм с накоплением, которые позволят вам ввести (усред-
ненные за день) данные серверов по рабочим нагрузкам на процессоры, память, системы
хранения и сети. Каждая страница имеет строку для значений ограничений и строку для
каждого набора данных сервера. После ввода серверных данных на каждой странице вы
должны отредактировать область исходных данных. Microsoft Excel 2007 позволяет вам вы-
бирать (для вывода на диаграмму) отдельную строку данных. Это дает вам возможность
легко выбирать серверы для совместного их анализа.
Повторное использование оборудования

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

и планирования
Кроме выполнения планирования консолидации серверов, проект виртуализации сер-
веров должен также сосредоточиться (на фазе планирования и проектирования) на тех
эксплуатационных изменениях, которые принесет виртуализация в вашу среду и на
влиянии этих изменений. Для эксплуатации инфраструктуры виртуализации очень
важно иметь полное решение, которое сможет управлять серверами Hyper-V и вирту-
альными машинами, наблюдать за состоянием виртуальной среды, а также решать
проблемы управления виртуализацией.
Управление инфраструктурой виртуализации

Несмотря на то, что Windows Server 2008 предоставляет модуль Hyper-V Manager кон-
соли Microsoft Management Console (MMC) для администрирования роли Hyper-V и
виртуальных машин, его интерфейс не предназначен для централизованного управле-

ния инфраструктурой виртуализации, которая содержит десятки, сотни или тысячи
серверов Hyper-V. Консоль Hyper-V Manager позволяет вам одновременно управлять
только одним сервером Hyper-V. Консоль Hyper-V Manager вполне приемлема для
управления не более чем 10 серверами Hyper-V. Если в вашем проекте виртуализации
будет более 10 серверов Hyper-V, либо если вам нужны такие расширенные функцио-
нальные возможности, как библиотека виртуальных машин или продвинутые функции
управления, то вам следует изучить менеджер System Center Virtual Machine Manager
2008 (SCVMM).
Более подробную информацию по использованию Hyper-V Manager MMC для управ-
ления Hyper-V см. в главе 11. Подробную информацию по менеджеру System Center
Virtual Machine Manager 2008, вариантам его инсталляции и сценариям использования
см. в главах 12 и 14.
Наблюдение за инфраструктурой виртуализации

При инсталлированной роли Hyper-V имеется большой набор счетчиков производи-
тельности, которые позволяют наблюдать за сервером Hyper-V и виртуальными маши-
нами. Однако инструмент Performance Monitor позволяет одновременно наблюдать за
производительностью только одного сервера Hyper-V. Несмотря на то, что это очень
полезный инструмент, который вам понадобится, для сбора данных по производитель-
ности одного сервера Hyper-V, Performance Monitor не предоставляет собой надежного
решения для наблюдения, отчетности и выдачи сигналов тревоги по инфраструктуре
виртуализации.
Для наблюдения, отчетности и выдачи сигналов тревоги по серверам Hyper-V и вирту-
альным машинам менеджер System Center Operations Manager 2007 (SCOM) предостав-
ляет центральную консоль и агентов. Кроме того, SCOM может наблюдать за всеми
физическими серверами вашей среды, что позволяет вам иметь единую консоль и для
физической, и для виртуальной среды. Для обеспечения специфичной для конкретного
приложения функциональности SCOM использует пакеты управления. Компания
Microsoft предоставляет бесплатный пакет управления, который наблюдает за вирту-
альной средой (и в том числе за Hyper-V, Virtual Server 2005 R2 SP1 и SCVMM).
Более подробную информацию по использованию менеджера System Center Operations
Manager 2007, а также об инсталляции пакетов управления и работе с ними см. в гла-
ве 15.
Управление обновлениями
инфраструктуры виртуализации
Служба Windows Software Update Service (WSUS) и менеджер System Center
Configuration Manager 2007 (SCCM) — это основные решения компании Microsoft для
управления обновлениями. В то время как WSUS является решением только для об-
новлений, SCCM обеспечивает дополнительные функциональные возможности, такие
как инвентаризация и отслеживание активов, а также развертывание программного
обеспечения.
Проектирование решения по управлению обновлениями для виртуальной среды слож-

нее, чем для традиционной инфраструктуры. Решение по управлению обновлениями
для виртуальной среды должно учитывать зависимости между сервером Hyper-V и ра-
ботающими на нем виртуальными машинами. Например, чрезвычайно важно, чтобы
используемое в инфраструктуре виртуализации решение распознавало, что оно развер-
тывает обновление на сервер Hyper-V, и не приводило к ненужным перезагрузкам и
простоям работающих на сервере виртуальных машин. Такие технологии виртуализа-
ции, как моментальные снимки, вносят дополнительные проблемы при отслеживании
состояния инсталлированных обновлений.
Более подробную информацию об адаптации вашего нынешнего решения (по управле-
нию обновлениями) к инфраструктуре виртуализации см. в главе 12.
Резервное копирование и восстановление

инфраструктуры виртуализации
Резервное копирование виртуальной машины несколько сложнее, чем резервное копи-
рование физической среды. Вы должны сделать копии сервера Hyper-V и всех вирту-
альных машин. Поскольку возможно, что вы будете делать резервное копирование
виртуальной машины в то время, когда другие виртуальные машины этого же сервера
Hyper-V предоставляют производственное обслуживание, то вы должны таким образом
спроектировать ваше решение резервного копирования, чтобы минимизировать его
влияние на производительность работающих виртуальных машин.
При выполнении резервного копирования сервера Hyper-V вам нужно обеспечить ко-
пирование следующей информации:
настройки конфигурации сервера Hyper-V;
состояния системы Hyper-V;
файловой системы сервера Hyper-V.
При выполнении резервного копирования виртуальной машины вам нужно обеспечить
копирование следующей информации:
настроек конфигурации виртуальной машины;
состояния системы виртуальной машины;
томов виртуальной машины;
иерархии моментальных снимков виртуальной машины;
иерархии разностных дисков виртуальной машины.
Стратегия резервного копирования

При резервном копировании сервера Hyper-V и виртуальных машин в оперативном
режиме у вас есть два основных варианта:
поместить агента копирования на каждый компьютер (виртуальную машину и сер-
вер Hyper-V) и делать резервное копирование по сети;
выполнить моментальный снимок Volume Shadow Copy Service (VSS) сервера
Hyper-V и виртуальных машин.
Использование локального агента позволяет вам делать резервные копии виртуальных

машин точно так же, как и физических, но копирование при его выполнении создает
дополнительную нагрузку на сервер Hyper-V, и обычно даже не известно, что это
именно виртуальная машина. Hyper-V поддерживает модуль записи VSS, который по-
зволяет выполнять резервное копирование сервера Hyper-V и всех виртуальных машин
из одного работающего на сервере агента. Такой подход сочетает в одном решении
лучшие преимущества двух подходов и является предпочтительным методом резервно-
го копирования.
ВАЖНО
Резервное копирование работающей виртуальной машины в оперативном режиме можно
выполнить только для операционной системы с инсталлированными службами интеграции,
а число таких систем ограничено гостевыми операционными системами со службой Volume
Shadow Copy Service. В конфигурации виртуальной машины должна также быть активиро-
вана настройка Backup Integration Services.
Вы можете также делать резервное копирование виртуальных машин в автономном

режиме, завершив их работу или сохранив состояние виртуальных машин, а затем сде-
лав копии этих файлов сервера Hyper-V. Резервное копирование выключенных или
сохраненных машин является простым процессом, но он не поддерживается для неко-
торых серверных ролей (таких, как контроллеры домена Active Directory).
Приложения резервного копирования

Для использования резервного копирования при помощи VSS ваше программное обес-
печение резервного копирования должно понимать и использовать модуль записи VSS
(для Hyper-V) для выполнения резервного копирования при помощи службы Volume
Shadow Copy Service. Для получения этой новой возможности вам нужно будет обно-
вить ваше программное обеспечение резервного копирования либо сменить поставщи-
ка приложения резервного копирования, чтобы получить эту возможность.
Менеджер System Center Data Protection Manager 2007 (SCDPM) SP1 поддерживает
оперативное и автономное резервное копирование для серверов Virtual Server 2005 R2
SP1 и Windows Server 2008 Hyper-V. Более подробную информацию по использова-
нию SCDPM для резервного копирования вашей инфраструктуры виртуализации
см. в главе 13.
Резюме
Данная глава была посвящена фазе планирования и проектирования проекта виртуали-
зации и трем ее главным частям: определению конфигураций оборудования Hyper-V,
планированию консолидации, а также планированию решения по управлению инфра-
структурой виртуализации. Планирование консолидации обсуждалось на основе опре-
деления стандартных спецификаций серверов Hyper-V и максимизации коэффициента
консолидации при виртуализации (путем оптимизации комбинаций рабочих нагрузок).
Вы узнали, как и почему следует определять разные конфигурации серверов для рабо-
чих нагрузок разного масштаба (которые могут потребоваться в вашей среде). Исполь-
зуя стратегию оценки реальных пределов производительности, логических групп кан-

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

System Center Virtual Machine Manager 2008, доступный по ссылке:
http://www.microsoft.com/systemcenter/scvmm/default.mspx;
System Center Operations Manager 2007, доступный по ссылке:
http://www.microsoft.com/systemcenter/opsmgr/default.mspx;
System Center Configuration Manager 2007, доступный по ссылке:
http://www.microsoft.com/systemcenter/configmgr/default.mspx;
System Center Data Protection Manager 2007, доступный по ссылке:
http://www.microsoft.com/systemcenter/dpm/default.mspx.
ГЛАВА 23

пилотная фаза
Пилотная фаза проекта виртуализации занимается проверкой планирования и проекти-
рования. На этой стадии проекта вам нужно разработать цели пилотной фазы, обозна-
чить область действия пилотного проекта, спроектировать его архитектуру, разрабо-
тать план пилотного проекта, реализовать пилотный проект и оценить его результат.
Цели пилотного проекта

Цели пилотного проекта должны отражать ключевые аспекты проекта, которые необ-
ходимо проверить перед полномасштабной реализацией в производстве решения по
виртуализации инфраструктуры. Если говорить на самом общем уровне, то пилотный
проект должен сосредоточиться на проверке процессов миграции, администрирования
и управления, а также на производительности виртуализированной среды. Вот те клю-
чевые аспекты, которые вам нужно будет проверить:
конфигурация Hyper-V;
процесс миграции физических машин на виртуальные;
процесс подготовки виртуальных машин;
административная модель безопасности;
процесс управления обновлениями;
процесс резервного копирования и восстановления;
производительность сервера Hyper-V.
В зависимости от вашего конкретного сценария проекта виртуализации серверов у вас
могут найтись и дополнительные пункты для проверки на пилотной фазе. Например,
если ваш проект включает в себя также и виртуализацию среды тестирования и разра-
ботки, вы будете дополнительно проверять: способность развертывания множества
виртуальных машин для одного тестового случая; выполнение теста; а также сохране-
ние виртуальных компонентов в библиотеке для последующего их использования.
В случае проекта виртуализации филиала вы добавите проверку политик и тех настро-
ек, которые обеспечивают безопасность виртуальных контроллеров домена. В сцена-
рии по обеспечению непрерывности бизнеса вы также будете проверять процессы пе-

редачи управления при сбоях (в вашем решении по восстановлению после катастроф).
По существу проверка технического решения и эксплуатационных процессов на пи-
лотной фазе гарантирует, что промышленное развертывание даст запланированные
функциональность и производительность.
Область действия пилотного проекта

Разработка пилотного плана осложняется тем, что он должен представлять собой та-
кую уменьшенную копию производственного развертывания, которая проверяет тех-
ническое решение и эксплуатационные процессы без необходимости реализации всего
проекта. Для достижения этой цели область действия пилотного проекта должна огра-
ничиться минимальным набором площадок и кандидатов на виртуализацию, который
позволит проверить решение виртуализации. Все аспекты проекта должны быть реали-
зованы (управление, резервное копирование, администрирование и т. д.), но это не
должно делаться в полном масштабе проекта. Например, для проверки процесса ми-
грации физических машин на виртуальные вам нужно выполнить некий представи-
тельный набор миграций (мигрировать на пилотной фазе все серверы не нужно).
Выбор пилотных площадок

Во время планирования консолидации для создания групп кандидатов на виртуализа-
цию (которые должны мигрировать на серверы Hyper-V одной площадки) используется
физическое местоположение. Некое подмножество этих мест можно использовать как
цели пилотного проекта. При этом вы можете выбрать площадки по приоритету, слож-
ности, размеру, близости или возможностям поддержки. Если проект виртуализации
содержит главный центр обработки данных и удаленные офисы, то пилотный проект
должен включать как минимум один центр обработки данных и одну удаленную пло-
щадку.
Выбор площадок для пилотного проекта зависит и от стратегии тестирования. Одна из
стратегий — выявить такие площадки, которые представляют собой самые сложные
случаи. Например, самый сложный случай можно определить как такую площадку,
которая имеет либо самый медленный канал глобальной сети, либо не имеет локальной
команды технической поддержки, либо самая труднодоступная. Использование этой
стратегии предполагает, что выбранные таким образом площадки представляют собой
самые сложные задачи для пилотной стадии, которые позволят команде развертывания
проверить и проект, и все планы по уменьшению рисков. Не удивительно, что такая
стратегия пилотного проекта может увеличить его длительность, увеличить количество
необходимых для него ресурсов и повысить стоимость пилотного проекта.
Есть и противоположный по смыслу подход — сосредоточиться на тех площадках, ко-
торые минимизируют продолжительность и стоимость пилотного проекта, снижают
потребность в ресурсах, а также выявляют стандартные проблемы. В этом случае вы
можете выбирать: те площадки, где есть техническая поддержка; более мелкие пло-
щадки, которые можно полностью мигрировать во время пилотного проекта; те пло-
щадки, где есть такое оборудование, которое можно использовать под серверы Hyper-V;
Глава 23. Проект виртуализации серверов: пилотная фаза 747
или такие удаленные площадки, которые находятся близко к центральной (для умень-
шения времени и стоимости переездов).
Выбор кандидатов на виртуализацию

После того как вы определите используемые в пилотном проекте площадки, вам следу-
ет проанализировать план консолидации для каждой площадки и выявить тех кандида-
тов на виртуализацию, которые вы будете мигрировать. На каждой площадке будет
один или несколько серверов Hyper-V с назначенными на них группами кандидатов
виртуализации. Выбор кандидатов может делаться на уровне хоста или индивидуально
(из кандидатов). Выбор хоста приводит к выбору всех кандидатов этого хоста. Выбор
отдельных кандидатов может привести к тому, что нужно будет развернуть несколько
серверов Hyper-V (для достижения проектной оптимизации рабочих нагрузок).
Если вы будете выбирать отдельных кандидатов на виртуализацию, сосредоточьтесь на
их ценности для пилотного проекта. Например, выберите серверы с разными операци-
онными системами, разными типами приложений, различными типами оборудования
(по производителю и по конфигурации), а также с различными характеристиками про-
изводительности. Такой подход даст вам возможность выявить (на фазе пилотного
проекта) большее количество потенциальных проблем.
Архитектура пилотного проекта

Реализация пилотного проекта требует развертывания всех компонентов архитектуры
решения по виртуализации: виртуализации, администрирования, управления, резервно-
го копирования, отказоустойчивости, наблюдения. Компания Microsoft имеет решения
для всех компонентов:
Windows Server 2008 и роль Hyper-V обеспечивают виртуализацию и основное ад-
министрирование;
менеджер Microsoft System Center Virtual Machine Manager 2008 (SCVMM) предос-
тавляет расширенные услуги по администрированию и управлению;
менеджер Microsoft System Center Data Protection Manager 2007 (DPM) SP1 предос-
тавляет услуги резервного копирования;
кластеризация Windows Server 2008 Failover Clustering обеспечивает отказоустойчи-
вость;
менеджер Microsoft System Center Operations Manager 2007 (SCOM) SP1 предостав-
ляет услуги по наблюдению.
Каждый из этих компонентов напрямую интегрируется с имеющейся инфраструктурой
доменов Active Directory.
Представленные здесь рекомендации по пилотной фазе предполагают реализацию на базе
решений компании Microsoft. Если у вас есть другие программные продукты, которые могут
дать ту же функциональность и совместимы с Hyper-V, то вы можете их использовать.
Однако использование продукта не от компании Microsoft может повлиять на интеграцию и
функциональность пилотного проекта и увеличить риск.
На рис. 23.1 показана архитектурная диаграмма реализации центра обработки данных

со всеми компонентами решения.
Рис. 23.1. Архитектура пилотного проекта
Планирование пилотного проекта

Для успешного пилотного проекта требуются: правильное планирование развертыва-
ния, миграции и эксплуатации; общение внутри команды проекта и с сообществом
пользователей; график проекта с вехами, документированные риски и план их потен-
циального уменьшения; критерий успеха, который позволит команде проекта оценить,
подтверждают ли результаты пилотного проекта само проектное решение по инфра-
структуре виртуализации.
Создание плана развертывания

План развертывания — это дорожная карта для развертывания архитектуры пилотной
фазы. План развертывания пилотного проекта сосредоточен на развертывании архи-
тектуры, необходимой для реализации области действия пилотного проекта. Как пока-
зано на рис. 23.1, архитектура центра обработки данных должна содержать один или
несколько хостов Windows Server 2008 с ролью Hyper-V, по крайней мере, один сервер
System Center Virtual Machine Manager 2008 с инсталлированным порталом Self-Service
Portal, консоль наблюдения Microsoft Operations Manager 2007 SP1, а также по меньшей
мере один сервер резервного копирования System Center Data Protection Manager 2007
SP1. Это даст базовую (поддерживаемую компанией Microsoft) архитектуру для хос-
тинга, подготовки, миграции, управления, наблюдения и резервного копирования сре-
ды пилотного проекта (в центре обработки данных). В зависимости от области дейст-

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

В то время как план развертывания сосредоточивается на той архитектуре, которую
следует развернуть для пилотного проекта, план поддержки посвящен стратегии и
команде, которая будет поддерживать работу пилотного проекта. План поддержки
должен ответить как минимум на следующие вопросы:
Будет ли предусмотрена отдельная команда и специальный номер телефона под-
держки?
Будет ли поддержка предоставляться только в определенное время?
Как будет предоставляться глобальная поддержка при международных развертыва-
ниях?
Будут ли в команде поддержки пилотного проекта люди, говорящие на разных язы-
ках?
Какое соглашение об уровне обслуживания для команды поддержки пилотного
проекта предполагается?
Каков процесс эскалации в том случае, когда команда поддержки пилотного проек-
та не может решить проблему?
Каков план отката в том случае, если во время пилотного проекта встретится серь-
езная проблема?
План поддержки должен быть интегрирован в разработку критерия успеха. Данные по
поддержке пилотного проекта следует проанализировать для того, чтобы определить,
как уровень обслуживания соотносится с тем, что было ранее по мигрировавшим кан-
дидатам на виртуализацию. Данные по обработке проблем службой поддержки пилот-
ного проекта следует использовать для выявления самых часто встречающихся про-
блем, для решения проблем, а также для внесения изменений в проект, которые могут
быть использованы для ликвидации или уменьшения проблем при производственном
развертывании.
Создание плана отслеживания проблем

Команда поддержки пилотного проекта будет основным интерфейсом для звонков за
поддержкой. Для документирования и отслеживания проблем, их состояния и решения
необходимо реализовать и использовать решение по отслеживанию проблем. Для не-

больших проектов можно просто использовать электронную таблицу MS Excel. Для
более крупных и сложных проектов (которые требуют координации между находящи-
мися в разных местах членами команды) рекомендуется использовать Web-часть Issues
Log портала Microsoft Office SharePoint Server (MOSS) 2007, систему Microsoft Visual
Studio Team System либо другой специальный инструмент для отслеживания проблем.
В табл. 23.1 приведен список параметров, которые должна собирать система отслежи-
вания проблем.
Таблица 23.1. Параметры отслеживания проблемы
Позиция Описание
Номер проблемы Уникальный номер для отслеживания проблемы
Фаза пилотного проекта Фаза пилотного проекта, на которой появилась проблема
Дата возникновения Дата подачи проблемы
проблемы
Инициатор Имя или адрес электронной почты инициатора проблемы
Описание проблемы Подробное описание проблемы
Влияние на пилотный проект Как проблема влияет на пилотный проект (ресурсы, время, эффек-
тивность, область действия и т. д.)
Действие Действия, которые необходимо предпринять для решения проблемы
Владелец действия Кто будет выполнять рекомендованные действия
Дата выполнения Когда действия должны решить проблему
Состояние Состояние проблемы (например, не начата, рассматривается, прово-
дятся действия, проблема решена)
Кроме сбора проблем, вам следует также составлять еженедельные отчеты, в которых
приводится количество проблем (по каждой категории состояния). Вам следует также
создать набор пределов и процесс для генерирования сигналов тревоги, чтобы обеспе-
чить работу с проблемами и их продвижение к решению. Например, если проблема
остается "не начатой" более 10 дней, то она должна выдать сигнал тревоги менеджеру
пилотного проекта, чтобы он связался с владельцем действия и выработал корректи-
рующее воздействие.
Для содействия в сборе и отслеживании проблем в каталоге Job Aids прилагающегося ком-
пакт-диска вы найдете электронную таблицу Excel с названием Issue Tracking JobAid.xls.
Эта электронная таблица имеет одну страницу, которая содержит столбцы для сбора реко-
мендуемых для отслеживания проблем атрибутов.
Использование сервера Microsoft Office SharePoint Server 2007
для отслеживания успехов пилотного проекта виртуализации
Хорошим способом обеспечить открытость проекта для руководства и проектной команды
является использование (на пилотной фазе проекта) сервера Microsoft Office SharePoint
Server 2007 для отслеживания проблем и предоставления панели показателей по состоя-

нию пилотного проекта. MOSS использует Web-компоненты под названием Web-части.
Web-части — это предопределенные модульные Web-интерфейсы, которые обеспечивают
такую функциональность, как управление документами, списки информации, календари,
списки задач и многое другое. MOSS можно использовать для создания портала проекта,
обеспечивающего управление документацией проекта (документы проекта, отслеживание
задач проекта, отчеты по показателям).
При помощи использования Web-части Document Library вы можете хранить, отслеживать
версии и категоризировать документы проекта. При помощи Web-части Project Tasks вы
можете создать план проекта вместе с задачами, отслеживанием ресурсов и диаграммами
Ганта. При помощи Web-части Issue Tracking вы можете создать список для отслеживания
проблем проекта. Комбинируя данные из Web-частей Issue Tracking и Key Performance
Indicator (KPI) List, вы можете создать систему показателей, которая содержит состояние
KPI для проблем проекта (категоризированных по значениям в столбце состояния проб-
лемы).
Дополнительную информацию по созданию KPI из списков SharePoint см. по каналу
Channel 9 в следующем видео:
http://channel9vip.orcsweb.com/ShowPost.aspx?PostID=214755.
Дэйв Гамильтон (Dave Hamilton, Architect (Microsoft Consulting Services))
Разработка плана миграции

План миграции занимается преобразованием физических серверов в виртуальные ма-
шины (с минимальным прерыванием обслуживания конечных пользователей). Мигра-
ция физических машин на виртуальные значительно упростилась после появления ин-
струментов автоматического преобразования физических машин в виртуальные (P2V).
Менеджер System Center Virtual Machine Manager (SCVMM) 2008 — это решение ком-
пании Microsoft для миграции P2V и миграции виртуальных машин на виртуальные
V2V (для миграции существующих виртуальных машин компании VMware). Кроме
Microsoft, есть много других поставщиков, которые производят аналогичные инстру-
менты. Компании PlateSpin (купленная в 2008 г. компанией Novell), LeoStream, а также
Hewlett-Packard — это только несколько примеров таких компаний, которые предос-
тавляют инструменты для автоматизации миграции (но существуют и другие).
План миграции должен решить как минимум следующие вопросы:
Можно ли выполнить оперативную миграцию физического сервера, или этот про-
цесс требует его выключения?
В каком порядке будут мигрировать физические серверы?
Каковы зависимости при миграции?
Как будет производиться наблюдение за процессом миграции?
Как будет производиться окончательное переключение с физического сервера после
тестирования виртуальной машины?
Будут ли требоваться для миграции сервера специальные разрешения?
Потребуются ли новые лицензии на программное обеспечение?
Отпадет ли необходимость в имеющихся лицензиях на программное обеспечение?
Будут ли миграции выполняться в интерактивном режиме или автоматически (при
помощи скриптов)?
Какие уведомления необходимо выдавать конечным пользователям для миграции

сервера?
Будет ли успешным процесс восстановления, если развертывание закончится неуда-
чей и потребуется откат?
Кроме того, план миграции должен содержать разработку набора процедур, которые
документируют процесс миграции. Процесс миграции нужно проверить во время пи-
лотного проекта. Процедуры миграции должны содержать пошаговые инструкции для
преобразования физических серверов в виртуальные машины и проверки производи-
тельности виртуальных машин (на соответствие ее соглашениям об уровне обслужива-
ния).
Разработка плана действий

План действий представляет собой дорожную карту для изменений в процессах и про-
цедурах, которые требуются для новой инфраструктуры виртуализации. Изменения
понадобятся в администрировании, управлении обновлениями, резервном копирова-
нии, восстановлении после катастроф, подготовке и прочих областях.
План действий должен решить как минимум следующие вопросы.
Как изменятся следующие процессы?
• Подготовка новых хостов.
• Подготовка новых виртуальных машин.
• Присваивание разрешений.
• Выполнение резервного копирования.
• Выполнение восстановления после катастроф.
• Наблюдение за компонентами виртуализации.
• Выполнение обновлений хостов и виртуальных машин.
Будет ли резервное копирование виртуальных машин выполняться с агента хоста
или с загруженных в виртуальные машины агентов?
Будет ли отдельная административная команда для управления серверами Hyper-V?
Какие понадобятся изменения в расписании окон обслуживания?
Будет ли использоваться автоматическое выравнивание рабочих нагрузок между
хостами?
Какой доступ к виртуальным машинам нужен команде технической поддержки?
Кто имеет доступ к консоли System Center Virtual Machine Manager?
План действий должен выявить все изменяющиеся области, описать новые процессы и
выдать подробные пошаговые процедуры для проверки на пилотной фазе.
Разработка плана обучения

План обучения для пилотной фазы проекта виртуализации серверов создается для об-
новления знаний администраторов, чтобы они могли эффективно управлять инфра-
структурой виртуализации. В плане обучения должны быть указаны: команда админи-

стрирования, которая будет отвечать за виртуализированную среду, уровень подготов-
ки членов команды, требующиеся для обновления их знаний курсы подготовки, а так-
же все новые (или адаптированные) процессы и процедуры, которые будут им нужны
для выполнения их административных обязанностей. Убедитесь, что вы учли и отдел
информационных технологий, и администраторов подразделений (особенно если под-
разделения сами управляют обеспечивающими бизнес серверами). Процесс эксплуата-
ции и управления виртуализированного сервера будет другим, поэтому распростране-
ние соответствующей информации должно быть одной из самых главных целей обу-
чения.
Выбранный вами метод удаленного управления виртуализированными серверами так-
же повлияет на план обучения. Если для удаленного управления сервером администра-
тор сервера использует Remote Desktop, то управление виртуализированным сервером
не будет отличаться от управления физическим сервером в традиционной среде. Если
же используется Hyper-V VMConnect или портал System Center Virtual Machine
Manager, то, вероятно, некоторое обучение все же потребуется.
Вот список часто встречающихся в плане обучения позиций:
инструменты и процессы управления обновлениями;
инструменты и процессы удаленного управления;
инструменты и процессы наблюдения;
инструменты и процессы резервного копирования;
инструменты восстановления после катастроф;
новый процесс подготовки серверов;
процесс инсталляции приложений;
отказоустойчивый кластер и управление им.
Создание плана обмена информацией

План обмена информацией может быть одним из самых важных аспектов пилотного
проекта. План описывает, как обмениваться, с кем обмениваться, когда обмениваться,
а также ту информацию, которой следует обмениваться. Чаще всего обмен информаци-
ей необходимо адаптировать к группе получателей.
Эффективный обмен информацией с пользователями пилотной фазы (или с конечными
пользователями) очень важен. Не следует полагаться на один метод обмена информа-
цией, поскольку разные пользователи предпочитают различные способы обмена. Соче-
тание сообщений электронной почты, сообщений на Web-сайтах, собраний команды и
прочих форм обмена информацией гарантирует своевременную доставку материалов
(независимо от предпочитаемого пользователем метода обмена информацией).
Правильное нацеливание информации на нужную группу повышает также и доверие
к проекту. Необходимо достичь определенного баланса: чтобы пользователи и админи-
страторы получали информацию, но не было избыточности (которая может привести
к тому, что пользователь начнет игнорировать поступающую информацию). Категори-
зируйте информацию и обеспечьте ее получение только соответствующей категорией

пользователей.
Убедитесь, что предоставление информации выполняется своевременно. Если это воз-
можно, то уведомления должны рассылаться за две недели до любого действия. На-
пример, пользователи и администраторы должны получить уведомление о миграции
физического сервера минимум за две недели. Администраторы обеспечивающих биз-
нес приложений должны быть как минимум за две недели поставлены в известность
о необходимости проверки работы, которая последует за миграцией сервера.
Выбор цели для информации
Пользователи имеют разные привычки по работе с электронной почтой. Некоторые при-
лежно читают каждое полученное сообщение, другие создают правила для категоризиро-
вания своего почтового ящика, третьи не читают ничего, что не адресовано лично им. Нет
никакой возможности помешать пользователю создать в почтовом ящике такое правило,
которое будет удалять всю информацию о пилотном проекте, но есть способы увеличить
вероятность того, что сообщение будет прочитано.
Вместо того чтобы посылать сообщение на список рассылки (который можно легко от-
фильтровать правилом), направляйте информацию непосредственно каждому пользовате-
лю. Такой подход персонализирует сообщение и увеличивает вероятность того, что данное
сообщение пройдет через любое правило фильтрации в почтовом ящике.
Для того чтобы сделать это в Microsoft Office Outlook, вы можете написать скрипт на языке
Visual Basic for Applications (который использует объект ExchangeDistributionList) для
перечисления списка рассылки, создания нового сообщения каждому члену списка рассыл-
ки, вложения стандартного сообщения в формате Rich Text и последующей автоматической
отправки сообщения. Вот пример, который вы можете использовать для настройки отправ-
ки информации по электронной почте:
Dim oDL As Outlook.ExchangeDistributionList
Dim oEU As Outlook.ExchangeUser
Dim oAE As Outlook.AddressEntry
Dim oAEs As Outlook.AddressEntries
Set oDL As <список рассылки — можно передать сюда как параметр>

Set oAEs = oDL.GetExchangeDistributionListMembers
For Each oAE in OAEs
If oAE.AddressEntryType <> olExchangeDistributionListAddressEntry then
Set oEU — oAE.GetExchangeUser
<Здесь должен быть скрипт отправки сообщения пользователю>
Else
<Рекурсия для выполнения этого скрипта
для вложенных списков рассылки>
End If
Next
Другой вариант — использовать функцию Mail Merge текстового процессора Microsoft Office
Word 2007 для отправки сообщений всем членам адресного списка. Вы можете персонали-
зировать свои электронные сообщения таким образом, чтобы в них вставлялись адреса и
имена конкретных людей.
Подробности об использовании объекта ExchangeDistributionList см. в руководстве
разработчика MS Outlook 2007 по ссылке: http://msdn2.microsoft.com/en-us/library
/bb176360.aspx. Чтобы получить помощь по использованию функции Mail Merge текстового

процессора MS Word 2007, сделайте поиск в системе помощи Word 2007 по словам "Mail
Merge".
Уилл Мартин (Will Martin, Senior Consultant (Microsoft Consulting Services))
Передача информации должна предоставлять целевому персоналу как минимум сле-

дующее:
обзор того, что должно произойти и почему;
польза от этих действий для конечного пользователя;
график тех действий, которые их затрагивают;
список тех серверов, которые это затрагивает;
список тех приложений и служб, которые это затрагивает;
процесс технической поддержки и контактная информация;
процесс эскалации.
Документирование рисков
Оценка и документирование рисков пилотного проекта позволят вам разработать пла-
ны по их уменьшению, а также процессы для повышения вероятности успеха проекта.
Все риски (бизнеса, технические и ресурсные) следует регистрировать, документиро-
вать, просматривать, а также своевременно и последовательно работать с ними. Необ-
ходимо поддерживать список рисков проекта, который должен быть доступен всей
команде пилотного проекта. Члены команды во время проекта должны поощряться
к обнаружению новых рисков, но они также должны помогать в разработке творческих
и эффективных решений для устранения или существенного уменьшения всех рисков.
В табл. 23.2 дан список необходимых параметров, которые должен содержать список
рисков проекта.
Таблица 23.2. Элементы рисков проекта
Элемент Описание
Идентификатор Числовое значение, которое уникально идентифицирует риск
риска
Название риска Описательное название риска
Описание риска Описание риска
Последствия Результат риска, в том числе последствия для бизнеса, технические и финан-
совые
Вероятность Мера вероятности возникновения риска (указывается как процент или значение
от 1 до 10)
Влияние Оценка неблагоприятного эффекта или масштабов потерь в случае возникно-
вения риска (обычно указывается как значение от 1 до 10)
План уменьшения Описание способа минимизации или устранения риска при помощи последова-
тельности задач (если план уменьшения вводится в действие, то следует об-
новить план проекта, чтобы отразить в нем эти задачи)
Владелец Тот, кому принадлежит данный риск и план уменьшения риска
Риски проекта следует поддерживать и обновлять таким образом, чтобы все члены
проекта и его акционеры имели простой доступ к этой информации. Этого можно до-
биться, предоставляя им информацию по электронной почте, при помощи размещения
регулярных обновлений электронной таблицы MS Excel либо при помощи использова-
ния такого Web-интерфейса, как Microsoft Office SharePoint Server 2007.
Для сбора и отслеживания рисков на прилагаемом компакт-диске в каталоге Job Aids вы
можете найти электронную таблицу MS Excel под названием Risk Management JobAid.xls.
Эта электронная таблица имеет одну страницу, которая содержит столбцы для сбора реко-
мендованных атрибутов рисков.
Определение вех пилотного проекта

Вехи пилотного проекта — это контрольные точки, в которых необходимо проанали-
зировать продвижение проекта. Вехи должны быть естественными точками передыш-
ки, которые позволят вам ответить на вопрос: "Как продвигается проект?". Вехи в раз-
ных проектах разные, но они всегда должны использоваться для измерения продвиже-
ния к развертыванию и его проверке. Поэтому каждая стадия пилотного проекта
виртуализации должна иметь, по крайней мере, одну веху. Не следует переходить
к следующей стадии проекта, если веха предыдущей стадии не была успешно пройде-
на, если предполагать, что стадии проекта выполняются последовательно. Кроме того,
не следует переходить к новой задаче проекта до тех пор, пока не будут выполнены
зависимости задач. Например, если вы повторно используете физические серверы под
серверы Hyper-V, то у вас есть зависимость от успешной миграции рабочих нагрузок
физического сервера (только после этого вы сможете повторно использовать его в ка-
честве сервера Hyper-V). Поэтому вехой может быть тот момент времени, когда по-
следняя рабочая нагрузка физического сервера будет успешно мигрирована.
Помимо определения вех проекта развертывания, в ключевых точках графика пилотно-
го проекта следует также реализовать проверочные вехи. Например, внутри стадии ми-
грации пилотного проекта вы можете установить проверочную веху после выполнения
первых 10% миграций. Перед тем как перейти к оставшимся 90% планируемых мигра-
ций, вам следует убедиться, что процессы и процедуры пилотного проекта дают ожи-
даемые результаты и достигают своих целей.
Определение критерия успеха

Многие проекты заканчиваются и считаются успешными, даже несмотря на то, что ни-
кто фактически не определил — что же собой представляет успех. Критерий успеха,
иногда называемый "условиями удовлетворения" (conditions of satisfaction), — это из-
меримые события, по которым можно оценить проект. Критерий успеха должен быть
определен и согласован с ответственным спонсором проекта до его начала. Это гаран-
тирует, что вы сможете набрать нужный набор данных, требуемых для оценки крите-
рия успеха проекта.
Измеримость — это главный аспект установления критерия успеха. Например, крите-

рий "повышение коэффициента использования сервера Hyper-V" не измерим. Требова-
ние должно, например, гласить, что процесс будет успешным, если "средний коэффи-
циент использования сервера Hyper-V будет составлять не менее 50%".
Критерий успеха должен быть определен для каждой стадии пилотного проекта. У вас
должны быть также критерии успеха для целей проекта. Например, если у вас есть цель
"Снизить капитальные расходы на физические серверы на 20%", то вы должны суметь
показать, получил ли проект ожидавшуюся экономию и была ли достигнута эта цель.
Реализация пилотного проекта

Во время пилотного проекта вы проверяете все планы проекта виртуализации при по-
мощи реализации некоторого подмножества области действия проекта. Уменьшенная
пилотная реализация для полномасштабного проекта позволяет вам обеспечить выяв-
ление зависимостей и потенциальных проблем еще до развертывания в производствен-
ных условиях.
Пилотная реализация — это также и возможность обучения для команды реализации
в производственных условиях. Если это возможно, укомплектуйте команду пилотного
проекта ключевыми членами той команды, которая будет делать реализацию в произ-
водственных условиях. Такой подход обеспечит вам наличие у них необходимого для
реализации в производственных условиях опыта.
Убедитесь в том, что в пилотной реализации используется такое же оборудование, ко-
торое планируется для реализации в производственных условиях. Это поможет в выяв-
лении проблем и проверке процедур на реальном оборудовании.
Важно понимать предпринимаемые на стадии пилотного проекта шаги и действия, а
также их результаты. Для отслеживания всех изменений в среде вам следует реализо-
вать процесс управления изменениями (с использованием серверов управления). Если
появляется проблема, то журнал изменений позволит вам проверить, повторяется ли
она, а также разработать процесс обхода проблемы или ее уменьшения.
Измерение успеха проекта

Во время пилотного проекта вы должны собрать данные по заданному критерию успе-
ха, которые позволят вам оценить успех проекта. Для этого нужно собрать как количе-
ственные, так и качественные данные. Количественные данные — это сбор данных при
помощи таких инструментов, как System Center Virtual Machine Manager 2008 и System
Center Operations Manager 2007. Создав отчет по каждому количественному критерию
успеха, вы сможете быстро оценить успех и тенденции проекта. Оценка тенденций
может помочь вам в выявлении потенциальных проблемных мест и позволит предпри-
нять корректирующие действия, такие как выполнение анализа основных причин, что-
бы найти способ изменения направления тенденции.
Качественные данные требуют компиляции информации посредством таких инстру-
ментов, как опросы SharePoint, при помощи которых вы можете получить обратную
связь от пользователей (относительно полученного ими опыта работы с пилотной реа-

лизацией). Не забудьте опросить не только непосредственных пользователей пилотно-
го проекта, но также и тех пользователей, которых затронул пилотный проект (по при-
чине простоя серверов, плохой производительности, увеличенного времени реакции
службы технической поддержки). Опросите также команду пилотного проекта, чтобы
определить, шел ли проект гладко, есть ли у команды предложения по улучшению ис-
пользованных в пилотном проекте процессов, процедур или методов.
Усваиваем полученные уроки

Во время пилотного проекта что-то неизбежно пойдет не так, после чего будет задей-
ствован либо план по уменьшению рисков, либо для решения проблемы будет пред-
принято другое корректирующее действие. По окончании пилотной фазы команда про-
екта должна проанализировать общий опыт пилотного проекта, усвоить эту информа-
цию, а затем модифицировать планы проекта, чтобы исключить или смягчить
аналогичные проблемы при развертывании в производственных условиях. Модифика-
ции могут также иметь вид изменений в задачах графика проекта, добавлений проект-
ных ресурсов, изменений в технических процессах и процедурах, изменений в области
действия проекта и его целях.
Если модификации достаточно существенны, то может потребоваться продление пи-
лотного проекта или дополнительный пилотный проект для надлежащей проверки всех
изменений проекта.
Резюме
Пилотный проект виртуализации серверов — это уменьшенное развертывание плана
реализации в производственных условиях. Цель пилотной фазы проекта — проверить
проект, процессы и процедуры инфраструктуры виртуализации до полномасштабного
развертывания в производственных условиях. До начала пилотного проекта следует
определить область его действия, а также разработать архитектуру для развертывания.
Для планирования пилотного проекта требуется создать планы и процедуры разверты-
вания, поддержки, миграции, действий и обмена информацией. Вы можете повысить
вероятность успеха проекта при помощи; создания процесса отслеживания проблем;
разработки плана обучения; документирования рисков проекта и создания планов их
уменьшения; установки вех проекта, а также определения измеримого критерия успеха.
Когда пилотные планы будут готовы, вы можете разворачивать архитектуру и активи-
ровать процессы технической поддержки. Затем вы можете мигрировать пилотных
кандидатов на виртуализацию и собирать количественные и качественные данные для
оценки критерия успешности проекта. Если собранные данные показывают, что пилот-
ный проект достиг своего критерия успеха или превысил его, то вы можете объявить
пилотный проект успешным. Если же на пилотной стадии возникают проблемы, то вам
следует задействовать планы уменьшения рисков, применить корректирующие дейст-
вия, а также использовать всю накопленную информацию для корректировки процес-
сов, процедур и целей (до начала развертывания в производственных условиях).

справочник Microsoft Outlook 2007 Developer Reference, доступный по адресу:
http://msdn2.microsoft.com/en-us/library/bb177050.aspx;
руководства Infrastructure Planning and Design guides, доступные по адресу:
http://go.microsoft.com/fwlink/?LinkId=100915.
Глоссарий
ACPI. Интерфейс Advanced Configuration and Power Interface — это открытая специфи-
кация, которая определяет интерфейсы для распознавания оборудования, управле-
ния электропитанием, а также конфигурирования оборудования.
ADSM. Маркер Active Directory Service Marker, компонент службы Virtual Machine
Management Service (VMMS), который обеспечивает регистрацию и управление
точками подключения служб (service connection points, SCP) в Active Directory.
Agent (агент). Программное приложение, которое предоставляет удаленные функции и
интерфейсы другому приложению.
AMD-V. Технология виртуализации компании AMD, предоставляющая такие функции
виртуализации, которые могут быть использованы поставщиками программного
обеспечения для расширения архитектуры их решений по виртуализации.
API. Интерфейс прикладного программирования.
Application-level virtualization (виртуализация на уровне приложения). Подход при
виртуализации, при котором приложения отделяются и изолируются друг от друга
для предотвращения их взаимодействия или возникновения несовместимостей.
Authorization store (хранилище данных авторизации). XML-файл, который содер-
жит конфигурацию авторизации для Hyper-V или SCVMM 2008.
BAT (Blocks Allocation Table). Таблица распределения блоков — таблица абсолютных
смещений секторов блоков данных в заголовке виртуального жесткого диска.
Binary translation (двоичное преобразование). Эмуляция одного набора инструкций
при помощи другого.
Business continuity (непрерывность бизнеса). Стратегия по определению и реализа-
ции такого программно-аппаратного решения, которое позволит в случае серьезной
катастрофы восстановить предоставление услуг через минимальное время.
Checkpoint (контрольная точка). Создание разностного диска как способа отката к
предыдущему состоянию виртуальной машины.
Child partition (дочерний раздел). Раздел, который создается гипервизором для рабо-
ты гостевой системы. Имеет доступ к синтетическому и эмулированному оборудо-
ванию.
762 Глоссарий
CIFS. Common Internet File System — сетевой протокол уровня приложений, который
обеспечивает доступ к совместно используемым файлам, принтерам и последова-
тельным портам.
Clustering (кластеризация). Использование соединенных общей дисковой подсисте-
мой двух или более серверов в качестве единой логической системы (для восста-
новления после сбоев)
Cmdlet (командлет). Команда, реализованная при помощи наследования одного из
двух специализированных базовых классов Windows PowerShell.
CMS. Однопользовательская операционная система, разработанная компанией IBM
для компьютера System/360 Model 67. Она работала внутри виртуальной машины и
предоставляла доступ к системным ресурсам каждому пользователю.
Collection (коллекция). Массив объектных ссылок, который можно перечислить.
COM. 1. Модель СОМ — интерфейс программирования. 2. Коммуникационный порт
(последовательный порт компьютера).
Compact (сжатие). Процесс удаления пустых секторов из динамически расширяюще-
гося виртуального жесткого диска (для уменьшения используемого на сервере про-
странства).
Conditions of satisfaction (условия удовлетворения). Измеримые события, по кото-
рым можно оценить успех проекта.
Constrained delegation (вынужденное делегирование). Способность указать, что
компьютер или учетная запись службы могут выполнять делегирование Kerberos
ограниченному набору служб.
CSCRIPT. Ядро обработки VBScript, выполненное в виде инструмента командной
строки.
DACL. Список управления доступом, который содержит элементы по разрешению и
запрещению доступа для объекта.
Defragmentation (дефрагментация). Процесс для обеспечения хранения файлов на
диске в виде непрерывных блоков (это улучшает производительность).
Differencing disk (разностный диск). Виртуальный жесткий диск, который является
оверлеем для другого виртуального жесткого диска (называемого "родителем") и в
котором хранятся операции записи. Разностные диски могут иметь много уровней
оверлея, а "родитель" может иметь много "дочерних" разностных дисков.
Disk geometry (геометрия диска). Комбинация цилиндров, головок и секторов, кото-
рая определяет емкость и конфигурацию жесткого диска.
Emulation (эмуляция). Процесс, при помощи которого виртуальный компьютер или
его компонент ведет себя точно так же, как физический компьютер или компонент.
External network (внешняя сеть). Виртуальная сеть, привязанная к адаптеру физиче-
ского сервера Hyper-V.
FQDN (полностью определенное доменное имя). Это комбинация имени сервера и
домена (в котором он находится). Например, для сервера с именем server1 в домене
contoso.com его FQDN будет server1.contoso.com.
Глоссарий 763
Gb/s. Гигабит в секунду.

GB. Гигабайт.
GHz. Гигагерц.
GPA. Физический адрес гостя — адресное пространство физической памяти дочернего
раздела.
Guest (гость). Виртуальная машина, которая работает на виртуальном сервере и состо-
ит из виртуального оборудования, операционной системы и инсталлированных при-
ложений.
Guest operating system (гостевая операционная система). Работающая в виртуальной
машине операционная система.
GUID (глобально уникальный идентификатор). Идентификатор, который использу-
ется программными приложениями для того, чтобы обеспечить уникальный ссы-
лочный номер для объекта.
GVA (виртуальный адрес гостя). Это адресное пространство виртуальной памяти
дочернего раздела.
HAL (уровень абстракции оборудования). Уровень, который реализуется в про-
граммном обеспечении для того, чтобы предоставить стандартный интерфейс к
оборудованию и скрыть нюансы от операционной системы и приложений.
HBA (шинный адаптер). Специальные дисковые контроллеры, которые обеспечивают
высокоскоростное подключение между хостом и дисковой системой.
Heartbeat (тактовый импульс). Сигнал, выдаваемый через регулярные интервалы
виртуальной или физической машиной для того, чтобы показать, что она отклика-
ется.
Heterogeneous consolidation (гетерогенная консолидация). Комбинирование различ-
ных рабочих нагрузок приложений с нескольких серверов на одном сервере.
Homogenous consolidation (гомогенная консолидация). Комбинирование на одном
сервере нескольких рабочих нагрузок одного и того же приложения.
Host (хост). Физический сервер, на котором работает Virtual Server 2005 R2.
Host cluster (кластер хостов). Кластер серверов Hyper-V. Минимальный размер кла-
стера — два узла, максимальный — 16 узлов.
Host group (группа хостов). Коллекция хостов, которые сгруппированы для админи-
стрирования или управления, либо по соображениям безопасности.
Host key (хост-комбинация клавиш). 1. Комбинация клавиш (по умолчанию — пра-
вая клавиша <Alt>), которую следует нажать (при использовании Virtual Server) для
переноса фокуса клавиатуры и мыши из гостевой операционной системы обратно
в операционную систему хоста. 2. Комбинация клавиш (по умолчанию <Ctrl>+
+<Alt>+<←>), которую нужно нажать при использовании Hyper-V для переноса
фокуса клавиатуры и мыши из гостевой операционной системы обратно в операци-
онную систему хоста.
Hosted virtualization (виртуализация на хосте). Приложение виртуализации работает

поверх операционной системы (например, такой как Windows Server 2003).
Hypercall (гипервызов). Специальный интерфейс, который предоставляет доступ к
машинным командам операционной системе, работающей в виртуальной машине.
Операционная система должна быть модифицирована, чтобы вместо стандартного
интерфейса она использовала гипервызовы.
Hypervisor (гипервизор). Монитор виртуальных машин (реализованный в программ-
ном обеспечении), который может работать как непосредственно на оборудовании,
так и в качестве уровня операционной системы.
IDE. Интерфейс для жестких и гибких дисков, который есть почти на каждом персо-
нальном компьютере. Электроника контроллера реализована на самом жестком
диске.
In-scope (в области действия). Задача, действие или объект, которые считаются
частью проекта.
Intel VT. Технология виртуализации компании Intel, предоставляющая такие аппарат-
ные функции виртуализации, которые могут быть использованы поставщиками про-
граммного обеспечения для расширения архитектуры их решений по виртуализа-
ции.
Integration Services (службы интеграции). Коллекция служб и программных драйве-
ров, которые максимизируют производительность и улучшают взаимодействие
пользователя с виртуальной машиной. Службы интеграции имеются только для
поддерживаемых гостевых операционных систем.
Internal network (внутренняя сеть). Виртуальная сеть в Hyper-V, которая позволяет
выполнять обмен между сервером Hyper-V и виртуальными машинами, но не по-
зволяет вести обмен за пределы сервера Hyper-V.
IOPS (количество операций ввода/вывода в секунду). Мера скорости обмена ин-
формацией с системой хранения.
iSCSI. Протокол SCSI по сети IP. Эта технология позволяет удаленному серверу пред-
ставить часть его системы хранения в виде локального диска SCSI.
ISO. Файлы ISO — это образы дисков CD или DVD, которые можно подключить
к виртуальному дисководу CD/DVD виртуальной машины.
Jumbo frames (пакеты увеличенного размера). Пакеты, которые позволяют увели-
чить полезную нагрузку пакета Ethernet от значения по умолчанию в 1500 байтов
до 9000 байтов.
KB. Килобайт.
Knowledge Base, KB (база знаний). Библиотека официальных технических статей,
предназначенная для всех, кто использует или разрабатывает программное обеспе-
чение для продуктов компании Microsoft.
Kb/s. Килобит в секунду.
Keyboard, Video, Mouse (KVM). Устройство, которое позволяет вам использовать
один комплект "клавиатура — видео — мышь" для нескольких компьютеров.
LBFO (балансировка нагрузки и передача управления). Сетевая технология, пре-

доставляемая независимыми поставщиками программного обеспечения для того,
чтобы несколько сетевых адаптеров можно было сконфигурировать таким образом,
чтобы они выглядели для сервера как один сетевой адаптер.
LDAP. Lightweight Directory Access Protocol — протокол уровня приложений для за-
проса и модификации служб каталога по протоколу TCP/IP. Этот стандарт был оп-
ределен организацией Internet Engineering Task Force в документе RFC 4510.
Library (библиотека). Контейнер для хранения виртуальных машин, файлов и шабло-
нов в менеджере Virtual Machine Manager 2008.
Live migration (живая миграция). Миграция виртуальной машины с одного сервера
Hyper-V на другой сервер Hyper-V без сколько-нибудь заметного простоя.
Logical processor (логический процессор). Представление физического процессора
(если он одноядерный) или физического ядра многоядерного процессора.
LUN (номер логического устройства). Адрес для раздела набора жестких дисков.
Размер раздела может составлять любую часть дискового массива.
МАС. Уникальный шестибайтовый аппаратный адрес, присвоенный сетевому адаптеру
(чтобы каждый посланный им пакет можно было вернуть).
Management Pack (пакет управления). Расширение для Microsoft Operations Manager,
которое определяет правила, фильтры, счетчики производительности, а также сиг-
налы тревоги, которые надо отслеживать для данного конкретного приложения или
оборудования.
Maximum capacity (максимальная емкость). Максимальный процент процессора
(или ядра), который может потребляться виртуальной машиной.
Maximum system capacity (максимальная емкость системы). Максимальный про-
цент ресурсов сервера, который может потреблять виртуальная машина.
Mb/s. Мегабит в секунду.
MB. Мегабайт.
MB/s. Мегабайт в секунду.
Merge (слияние). Процесс комбинирования секторов нескольких разностных вирту-
альных жестких дисков для получения одного виртуального жесткого диска со все-
ми изменениями.
MHz. Мегагерц.
NAS (сетевая система хранения данных). Технология, которая позволяет дисковым
системам непосредственно подключаться к IP-сети, после чего к ним можно обра-
щаться как к локальным дискам.
Native virtualization (машинная виртуализация). Подход к виртуализации, при кото-
ром процессор должен поддерживать команды для виртуализации (чтобы сократить
программную обработку).
NUMA. Архитектура Non-Uniform Memory Access — это такая функция процессора,
которая обеспечивает более быстрый доступ к той памяти, которая локально под-
ключена к процессору (для повышения производительности).
Operating system-level virtualization (виртуализация на уровне операционной сис-

темы). При этом подходе к виртуализации одна операционная система предостав-
ляет изолированные виртуализированные копии ядра, памяти и конфигурации. Вы-
полняется только одна копия операционной системы.
Options.xml. Конфигурационный файл, который содержит конфигурационную инфор-
мацию хоста Virtual Server, настройки административной консоли, а также инфор-
мацию по привязке физических сетевых адаптеров.
Out-of-scope (вне области действия). Задача, действие или объект, которые не счита-
ются частью проекта.
P2V (c физической на виртуальную машину). Процесс миграции физической маши-
ны на виртуальную.
Paravirtualization (паравиртуализация). Подход виртуализации, при котором опера-
ционной системе требуется модификация для обработки невиртуализируемых ко-
манд х86, поддерживаемых между виртуальной машиной и гипервизором при по-
мощи специальных API, которые называются гипервызовами.
Parent partition (родительский раздел). Корневой раздел гипервизора, который
управляет доступом к физическому оборудованию.
Partition (раздел). Контейнер для процессов, который изолирован от других контейне-
ров и управляется гипервизором.
Pass-through disk (транзитный диск). Физический диск сервера, который представля-
ется дочернему разделу как виртуальный жесткий диск. Сервер не может использо-
вать этот дисковый ресурс.
PerfMon. Приложение для наблюдения за производительностью, имеющееся в Win-
dows 2000 и более новых операционных системах.
Precompaction (предварительное сжатие). Процесс работы инструмента, который
очищает неиспользуемые секторы виртуального жесткого диска, записывая в них
нули.
Private network (частная сеть). Виртуальная сеть в Hyper-V, которая позволяет вы-
полнять сетевой обмен только между виртуальными машинами.
PRO (оптимизация ресурсов по производительности). Способность менеджеров
Virtual Machine Manager 2008 и Operations Manager 2007 применять оптимизацию
ресурсов для рабочих нагрузок и приложений в виртуализированной среде.
PXE. Активируемая в BIOS опция для загрузки компьютера с сетевого сервера загруз-
ки (обычно активируется при помощи нажатия клавиши <F12>).
Quiesce (замораживание). Процесс сброса всех буферов (памяти и дисков) для завер-
шения всех транзакций перед началом резервного копирования.
Quorum disk (диск кворума). Совместно используемый диск кластера, на котором
данные конфигурации хранятся в журнале кворума, контрольной точке базы данных
кластера, а также в контрольных точках ресурсов.
Raid (избыточный массив недорогих дисков). Технология для комбинирования же-
стких дисков в логическое устройство. Есть разные версии RAID, которые предна-
значены либо для высокой готовности, либо для скорости.
Relative weight (относительный вес). Числовое значение, присвоенное виртуальной

машине, которое определяет важность доступа виртуальной машины к ресурсам
(относительно других виртуальных машин). Виртуальные машины с более высоки-
ми относительными весами получают более высокий приоритет по ресурсам.
Reserved capacity (резервированная мощность). Процент процессора (или ядра), ко-
торый резервируется для использования виртуальной машиной.
Reserved system capacity (резервированная мощность системы). Процент суммар-
ной мощности процессора (или ядра) сервера, который резервируется для использо-
вания виртуальной машиной. Это значение не может быть больше, чем максималь-
ная мощность системы.
Ring compression (сжатие колец). Метод выполнения нескольких режимов колец
в одном режиме кольца физического процессора.
RIS. Служба Remote Installation Service — это приложение Windows, которое обеспе-
чивает удаленную загрузку и инсталляцию операционной системы по сети.
ROI (коэффициент эффективности инвестиций). Экономия капитальных затрат от
развертывания технологии. Экономия равняется суммарной экономии за вычетом
расходов на развертывание и эксплуатацию новой технологии. В общую сумму эко-
номии входит экономия по: капитальным затратам, электропитанию, месту в стой-
ках, охлаждению, рабочей силе и т. д.
Rule (правило). Функция менеджера Microsoft Operations Manager, которая определяет
сбор данных по событиям, сигналам тревоги и по производительности, а также ука-
зывает, что делать с этой информацией после сбора.
SAN (сеть хранения данных). Технология, которая позволяет подключить компьюте-
ры к большому массиву дисков и получать доступ к определенным его блокам
(в независимом режиме или в режиме совместного использования).
Save state (сохранение состояния). Процесс сохранения текущей конфигурации памя-
ти, процессов и дисков в файлы (чтобы работу виртуальной машины можно было
быстро возобновить). Аналогично концепции гибернации компьютера.
SCP (точка подключения службы). Функция, которая позволяет службе регистриро-
ваться в Active Directory в качестве привязанной к тому серверу, на котором она ра-
ботает.
SCSI. Интерфейс Small Computer System Interface.
SCVMM. Менеджер System Center Virtual Machine Manager — серверное приложение
компании Microsoft для управления одной или несколькими системами Hyper-V,
Virtual Server 2005 и VMware ESX.
Self-service portal (портал самообслуживания). Компонент SCVMM 2008, который
предоставляет пользователям Web-интерфейс для управления их виртуальными
машинами.
Server consolidation (консолидация серверов). Процесс уменьшения количества фи-
зических серверов, которые требуются для выполнения рабочих нагрузок (путем
комбинирования этих рабочих нагрузок на меньшем количестве серверов).
Server farm (ферма серверов). Коллекция серверов Hyper-V, которые управляются

одним сервером SCVMM 2008.
Side-by-side execution (параллельное выполнение). Способность двух приложений
выполняться в одно и то же время с использованием разных версий одной и той же
динамической библиотеки (DLL).
SLA (соглашение об уровне обслуживания). Письменное определение ожидаемого
уровня обслуживания, который управляющая сервером организация будет предос-
тавлять пользователям. Соглашение обычно определяет уровни и типы технической
поддержки, обмен информацией, а также все те последствия, которые возникнут
в случае несоблюдения уровней обслуживания.
Slipstream (встраивание). Процесс, при помощи которого вы интегрируете драйверы
или обновления в образ Windows Image (WIM) для упрощения инсталляции опера-
ционной системы.
Snapshot (моментальный снимок). Копия текущего состояния оборудования, про-
граммного обеспечения, процессов и дисков виртуальной машины, которую можно
использовать для приведения виртуальной машины в другое состояние.
Snapshot Manager (менеджер моментальных снимков). Компонент Hyper-V, кото-
рый управляет моментальными снимками виртуальных машин, когда виртуальные
машины не работают.
SPA (физический адрес системы). Адресное пространство физической памяти физи-
ческого компьютера.
SPL (модуль прослушивания Single Port Listener для RDP). Функция в VMMS, ко-
торая управляет запросами на входящие подключения от клиентов виртуальных
машин (Vmconnect.exe) и маршрутизирует их в соответствующий рабочий процесс
для обработки.
SPN (имя участника-службы). Хранящаяся в Active Directory информация, которая
определяет работающую на сервере службу и разрешает для нее аутентификацию
Kerberos.
State machine (конечный автомат). Автомат, который создает и управляет: виртуаль-
ной машиной, переходами из состояния в состояние, сохранением и восстановлени-
ем, а также моментальными снимками.
Support level (уровень поддержки). Ожидаемый уровень поддержки службы, сервиса,
приложения (в процентах).
Sysprep. Инструмент, который позволяет удалить уникальную идентификацию компь-
ютера и сбросить ее при следующей загрузке.
Teaming (совместная работа). Способность нескольких сетевых адаптеров работать
как один (для повышения производительности и отказоустойчивости). Это функция,
которую предоставляет изготовитель сетевого адаптера.
Template (шаблон). Предварительно определенная виртуальная машина на сервере
библиотеки Virtual Machine Manager 2008.
Threshold (ограничение). Значение, выбранное в качестве максимального или мини-
мального предела.
UAC. User Account Control — это функция Windows Vista, которая заставляет все про-
цессы работать по умолчанию с более низким уровнем привилегий и требует под-
тверждения каждого действия, для которого нужен более высокий уровень привиле-
гий. Эта функция доступна пользователям с административными привилегиями.
Undo disk (восстановительный диск). Виртуальный жесткий диск в Virtual Server,
который хранит все новые операции записи, чтобы исходный виртуальный жесткий
диск не модифицировался. Когда виртуальная машина выключается, у вас есть вы-
бор: либо сохранить все записи восстановительного диска, либо сбросить все опе-
рации записи и вернуться к состоянию на момент включения.
Unit (U). Стандартная единица для измерения высоты монтируемого в стойку устрой-
ства или самой стойки.
User mode (пользовательский режим). Процесс, служба или приложение работает
в контексте учетной записи пользователя.
USN (последовательный номер обновления). Этот номер присваивается в Active Di-
rectory тому объекту, который используется для отслеживания обновлений с кон-
троллера домена.
UUID. Идентификатор, который используется в качестве уникального номера для от-
слеживания объекта.
V2V (с виртуальной на виртуальную). Миграция виртуальной машины одного фор-
мата в виртуальную машину другого формата.
VID. Драйвер виртуальной инфраструктуры — это интерфейс обмена между гиперви-
зором и родительским разделом (при помощи API гипервызовов).
Virtualization (виртуализация). Такое абстрагирование физических системных ресур-
сов, которое позволяет создать несколько логических разделов для одновременного
выполнения различных операционных систем на одном сервере.
Virtualization candidate (кандидат на виртуализацию). Физический сервер, который
соответствует всем требованиям миграции на виртуальный сервер.
VSC. Клиент службы виртуализации.
VSP. Поставщик службы виртуализации.
Virtualization stack (стек виртуализации). Коллекция программных компонентов и
виртуальных устройств, которые работают совместно и поддерживают создание
виртуальных машин и управление ими.
VFD. Виртуальный гибкий диск — это представление физического гибкого диска
в виде файла (хранится и заголовок диска, и его данные).
VHD. Виртуальный жесткий диск — это представление физического жесткого диска
в виде файла (с полным воспроизведением структуры заголовка диска).
VHDMount. Утилита сервера Virtual Server, которая позволяет серверу монтировать
файл VHD как локальный диск (для операций чтения и записи).
VLAN. Виртуальная локальная сеть, технология для обеспечения работы нескольких
логических сетей на одном физическом кабеле.
VM. 1. Монитор виртуальных машин, разработанный компанией IBM для компьютера

System/360 Model 67. Он создавал виртуальные машины и управлял ими. 2. Вирту-
альная машина (компьютер, который существует только в программном обеспече-
нии).
VMBus. Шина Virtual Machine Bus служит путем обмена для доступа к устройствам и
памяти (между дочерним и родительским разделом). Дочерний раздел не может ви-
деть обмена от других дочерних разделов.
VMC. Конфигурация виртуальной машины — это файл, который содержит конфигу-
рационную информацию виртуальной машины (память, жесткий диск, сетевые
адаптеры, настройки BIOS и т. д.) на сервере Virtual Server 2005.
VMM. 1. Монитор Virtual Machine Monitor, который отвечает за создание, изоляцию и
сохранение состояния виртуальной машины, а также за организацию доступа к сис-
темным ресурсам. 2. Менеджер Virtual Machine Manager, решение компании
Microsoft для управления фермой серверов виртуализации Hyper-V, Virtual Server
2005 R2 и VMware ESX.
VMMS. Служба Virtual Machine Management Service — коллекция компонентов, кото-
рые работают совместно и управляют виртуальными машинами.
VMNS. Служба Virtual Machine Network Service, которая привязывает виртуальные
сети к физическому сетевому адаптеру хоста и позволяет трафику из виртуальных
машин совместно использовать физический сетевой адаптер.
VMRC Client. Приложение на базе Windows Forms, которое использует протокол
VMRC для удаленного управления работающими виртуальными машинами.
Virtual floppy drive (виртуальный дисковод гибких дисков). Программная эмуляция
дисковода гибких дисков размером 3,5 дюйма и емкостью 1,44 Мбайт.
Virtual floppy disk (виртуальный гибкий диск). Программное представление гибкого
диска объемом 1,44 Мбайт.
Virtual Machine Additions (дополнения виртуальных машин). Набор драйверов и
служб, инсталлируемых на виртуальной машине для повышения производительно-
сти и улучшения взаимодействия с пользователем.
Virtual machine library (библиотека виртуальных машин). Коллекция предвари-
тельно созданных виртуальных машин, доступная для модификации и быстрого
развертывания.
Virtual memory (виртуальная память). Память, зарезервированная для виртуальной
машины. Виртуальная память может выделяться только из доступной физической
памяти сервера.
VSMT. Инструментальный набор Virtual Server Migration Toolkit — это приложение,
которое позволяет вам мигрировать физический сервер в виртуальную машину.
VSMM. Менеджер памяти стека виртуализации.
VSS. Служба Volume Shadow Copy Service (имеется в Windows Server 2003 и более
новых операционных системах), которая позволяет серверу и любым совместимым
с VSS приложениям быстро копироваться без потери данных.
WAIK. Windows Automated Installation Kit — это программный инструментальный на-

бор, который помогает в создании скриптов и последовательностей задач для соз-
дания образов операционной системы Windows (для автоматизированного развер-
тывания).
WIM (образ Windows Image). Формат, который используется для транспортировки
всех нужных файлов для инсталляции операционной системы Windows.
Windows PowerShell. Новый язык скриптов компании Microsoft (оболочка командной
строки).
WinRM. Windows Remote Management — реализация компанией Microsoft протокола
WS-Management Protocol, является стандартным и дружественным к сетевым экра-
нам протоколом на базе Simple Object Access Protocol (SOAP), который позволяет
взаимодействовать оборудованию и операционным системам разных поставщиков.
WMI. Windows Management Instrumentation — это набор интерфейсов, который позво-
ляет получить информацию по аппаратному и программному обеспечению локаль-
ного сервера.
WPM. Менеджер Worker Process Manager, который запускает рабочие процессы, под-
держивает список всех работающих рабочих процессов и обеспечивает уведомле-
ния об изменениях состояния рабочих процессов всем подписчикам.
WSCRIPT. Ядро обработки VBScript (на базе Windows Forms).
XML. Язык расширенной разметки Extensible Markup Language (XML) — это формат
общего назначения для структурированных данных, который облегчает совместное
использование данных разными информационными системами или приложениями.
z/VM. Современный продукт виртуализации от компании IBM.
ПРИЛОЖЕНИЕ
Описание компакт-диска
Как использовать компакт-диск?

Меню автозапуска диска
Для того чтобы использовать этот компакт-диск, вставьте его в ваш дисковод CD-ROM.
Появится окно-меню. Если на вашем компьютере отключен автозапуск, то для того,
чтобы увидеть это меню, вам придется запустить файл StartCD.exe, который находится
в корневом каталоге компакт-диска. В меню присутствуют ссылки на все имеющиеся
на данном диске ресурсы, а также ссылка для доступа на Web-сайт поддержки компа-
нии Microsoft.
Средства просмотра файлов

Электронная версия этой книги и некоторые другие документы этого компакт-диска
представлены в формате Portable Document Format (PDF). Для их просмотра вам пона-
добится программа Adobe Acrobat или Adobe Reader. Дополнительную информацию
по этим продуктам можно получить на Web-сайте компании Adobe по адресу:
http://www.adobe.com. Там же можно скачать новейшую версию программы Adobe
Reader.
Что находится на компакт-диске?

Этот компакт диск содержит:
книгу "Windows Server 2008 Hyper-V. Resource Kit" в электронном виде (оригинал
на английском языке);
вспомогательные материалы;
скрипты;
ссылки на инструменты и ресурсы;
бонусные материалы.
774 Приложение
Книга "Windows Server 2008 Hyper-V. Resource Kit"

в электронном виде
На этом компакт-диске имеется полный текст бумажного издания книги в формате
PDF. Чтобы просмотреть эту книгу, откройте файл формата PDF, который находится
в каталоге \eBook.
Электронная книга имеет формат PDF. Для ее просмотра вам понадобится программа
Adobe Acrobat или Adobe Reader. Дополнительную информацию по этим продуктам можно
получить на Web-сайте компании Adobe по адресу: http://www.adobe.com. Там же можно
скачать новейшую версию программы Adobe Reader.
Вспомогательные материалы
В тексте книги имеются ссылки на эти файлы. Чтобы просмотреть эти файлы, откройте
каталог \Job Aids.
Скрипты
В тексте книги имеются ссылки на файлы скриптов. Чтобы просмотреть эти файлы,
откройте каталог \Scripts.
Ссылки на инструменты и ресурсы

Здесь содержатся ссылки на полезные ресурсы и инструменты, которые рекомендова-
ны авторами данной книги.
Бонусное содержимое
Каталог \Bonus Content содержит электронную книгу "Understanding Microsoft
Virtualization Solutions" издательства Microsoft Press.
Информация о поддержке
Информация по технической поддержке
Microsoft Learning Technical Support
Для того чтобы обеспечить точность этой книги и содержимого этого компакт-диска,
были предприняты все необходимые усилия. По мере сбора исправлений и изменений
они будут выложены в виде статьи базы знаний Microsoft Knowledge Base.
Компания Microsoft Press предоставляет поддержку книг и сопутствующих им ком-
пакт-дисков на следующем Web-сайте:
http://www.microsoft.com/learning/en/us/training/format-books.aspx.
Если у вас есть комментарии, вопросы или идеи по этой книге или этому компакт-
диску, либо такие вопросы, ответы на которые вы не получили после посещения вы-
Описание компакт-диска 775
шеприведенного сайта, то, пожалуйста, посылайте их в издательство Microsoft Press по

адресу электронной почты: rkinput@microsoft.com.
Обратите внимание, что поддержка программных продуктов компании Microsoft по
вышеприведенным адресам не производится.
Отказ от ответственности
Для удобства пользователей на этом компакт-диске могут содержаться программные
продукты сторонних фирм или ссылки на Web-сайты сторонних компаний.
Примите во внимание, что эти продукты не контролируются компанией Microsoft
Corporation, поэтому компания Microsoft не несет ответственности за их содержимое.
Их включение в этот компакт-диск не должно рассматриваться как одобрение этих
продуктов. Проверьте наличие на сайтах этих сторонних компаний самых свежих вер-
сий их программного обеспечения.
Предметный указатель
A F
Active Directory 508, 682 Failover Cluster Manager 374
◊ лес 682 Failover Clustering 217
Active Directory Service Marker (ADSM) 92 Fiber Channel 293
Add Features Wizard 229, 441
Add Hosts Wizard 146
Add Roles Wizard 125, 344
G
Address Space Identifier (ASID) 17 Get-WMIObject, командлет 589
Administrator Console 490
AMD-V 17
AMD-V Rapid Virtualization Indexing (RVI)
H
18 High-Availability Wizard 231
Authorization Manager (AzMan) 45, 252, 373 HVConfig.cmd 45, 154
Hyper-V:
B ◊ восстановление сервера 441
◊ запросы к локальному серверу 591
Backup Schedule Wizard 446 ◊ наблюдение 578
BIOS 120, 418 ◊ резервное копирование 508, 623, 741
Blocks Allocation Table (BAT) 112, 115 Hyper-V Image Management Service (IMS)
249
C Hyper-V Manager 58, 372
◊ конфигурирование настроек Hyper-V 79
Citrix XenDesktop 656 Hyper-V Networking Management Service
Cluster Configuration Wizard 237 (NMS) 249
Clustered Shared Volumes 49
Create Cluster Wizard 230
I
D ImageX 122
Integrated Management Console 652
Deployment Workbench 137 Integrated Virtualization ROI Tool 675
Integration Services (IS) 47, 110, 193, 302,
E 430, 438
Intel Virtualization Technology (Intel VT) 20
Edit Virtual Hard Disk Wizard 74, 173 iSCSI 293
778 Предметный указатель
L Remote Desktop 285

Remote Desktop Connection Broker 50, 656
Live Migration 49, 350, 358 Remote Desktop Protocol (RDP) 91
Logical Unit Number (LUN) 49
S
M Self-Service Portal 464
Media Access Control (MAC) 213 Self-Service Web Portal 627
Microsoft Active Directory Topology Server Consolidation And Virtualization
Diagrammer (ADTD) 695 Wizard 715
Microsoft Application Virtualization 657 Server Core 151
Microsoft Assessment and Planning (MAR) Server Manager 125
Toolkit 697 ServerManagerCmd.exe 128
Microsoft Deployment Toolkit 2008 (MDT) Single Port Listener (SPL) 91
137 Snapshot Manager 91
Microsoft Hyper-V Server 2008 130, 154 System Center Data Protection Manager
Microsoft Office SharePoint Server 2007 751 (DPM) 658
Microsoft Windows PowerShell 80 System Center Data Protection Manager 2007
SP1 382, 510
N System Center Operations Manager 2007
(SCOM) 388, 740
Nested Page Tables (NPT) 354 System Center Virtual Machine Manager 657
Nested Paging 17 System Center Virtual Machine Manager 2008
New Package Wizard 137 (SCVMM) 146, 376, 459
New Task Sequence Wizard 138 System Preparation (Sysprep) 435
New Virtual Hard Disk Wizard 73, 169, 422 Systemtools Exporter Pro 694
New Virtual Machine Wizard 61, 230, 414,
421
Non-Uniform Memory Access (NUMA) 288
T
TCP Chimney Offload 295
O Time Synchronization, служба 194
Translation-Lookaside Buffer (TLB) 17
OCSetup.exe 129
Oscdimg 124
V
P Validate A Configuration Wizard 229, 237
Virtual Desktop Infrastructure (VDI) 27, 641
Performance Monitor 740 Virtual Disk Precompactor 181
Pkgmgr 123 Virtual hard disks 47
PlateSpin PowerRecon 701 Virtual hard drive (VHD) 55
Virtual LAN (VLAN) 209, 313
Q Virtual Machine Connection (VMC) 48, 77,
438
Quick Migration 46, 49, 350 Virtual Machine Management Service
(VMMS) 88, 95, 98, 184, 249, 502
R Virtual Machine Manager (VMM) 90
Virtual Machine Manager Agent 378
Rapid Virtualization Indexing (RVI) 17, 354 Virtual Machine Manager Database 378
RDP Encoder 102 Virtual Machine Monitor (VMM) 21
Recovery Wizard 450 Virtual Memory Control Block (VMCB) 17
Reliability and Performance Monitor 384 Virtual Network Manager 75, 210
Предметный указатель 779
Virtual Server 2005 R2 323

Virtualization Infrastructure Driver (VID 95
W
Virtualization Service Clients (VSC) 41, 94 Web-часть 751
Virtualization Service Providers (VSP) 41, 93 Windows Automated Installation Kit (WAIK)
Virtualization Stack Memory Manager 120, 121
(VSMM) 97, 100 Windows BitLocker Drive Encryption 273
VMBus 41, 58, 94, 194, 312 Windows Defrag 181
VMConnect.exe 284 Windows Management Instrumentation (WMI)
VMM Administrator Console 376 98
VMM Library 376 ◊ классы 588
VMM Self-Service Portal 378 ◊ клиент 98
Volume Shadow Copy 503 Windows Server 2008 Failover Clustering 350
Volume Shadow Copy Service (VSS) 45, 92, Windows Server 2008 Hyper-V Management
197, 624 Pack 561
Volume Shadow Copy Service Administrative Windows Server 2008 Terminal Services
443 RemoteApp 657
VSS Framework 92 Windows Server Backup 380, 441
VSS Requestor 92 WMI Provider 89
VSS Writer 93 Worker Process Manager (WPM) 90
Б ◊ автоматический останов 433

◊ восстановление 450, 530
Беспроводная сеть 313 ◊ высокой готовности 231
Брокер подключений 652 ◊ действия 492
◊ удаленного рабочего стола 50 ◊ импорт 47, 63
Быстрая миграция 46, 49, 350 ◊ клонирование 493
◊ моментальный снимок 48, 65, 91, 184,
В 431
◊ настройка 595
Виртуализация: ◊ обновление 440
◊ на уровне машин 21 ◊ оптимизация производительности 301
◊ на уровне операционной системы 24 ◊ резервное копирование 446, 508, 741
◊ на уровне приложений 25 ◊ создание 61, 414, 602
◊ паравиртуализация 23 ◊ состояние 69
◊ полная 22 ◊ удаление 434, 606
◊ программная 21 ◊ удаленный доступ 77
◊ рабочего стола 27 ◊ управление 60, 414
◊ собственная 22 конфигурацией 70
Виртуальная материнская плата 99 состоянием 440
Виртуальная машина 16, 24, 86 ◊ шаблон 483
◊ автоматический запуск 432 ◊ экспорт 47, 63
780 Предметный указатель
Виртуальная память 103, 308, 419 Д

◊ управление 97
Виртуальная сеть 56, 107, 198, 424, 609 Диск 290
◊ внешняя 57, 200, 424 ◊ iSCSI 56
◊ внутренняя 57, 203, 424 ◊ iSCSI 235
◊ локальная 209 ◊ динамический 170
◊ создание 75 ◊ конфигурирование 292
◊ частная 57, 206, 424 ◊ производительность 291
Виртуальное устройство 86, 101, 102 ◊ разностный 168
◊ компонентов интеграции 102 ◊ транзитный 56, 111, 214
Виртуальный COM-порт 427 ◊ физический 176
Виртуальный гибкий диск 74, 115
Виртуальный дисковод DVD 423
Виртуальный дисковод гибких дисков 74,
К
429 Кластер хостов Hyper-V 622
Виртуальный жесткий диск 47, 55, 110, 170, Кластеризация:
315, 421 ◊ высокоустойчивая 46
◊ дефрагментация 180 ◊ отказоустойчивая 217
◊ конвертирование 178 Компонент конфигурирования 93
◊ расширение 183 Конечный автомат 101
◊ редактирование 74
◊ сжатие 179, 182 М
предварительное 181
◊ создание 73 Менеджер:
◊ структура 112 ◊ памяти 100
Виртуальный интерфейс: ◊ политик 108
◊ IDE 56 Миграция:
◊ SCSI 56 ◊ виртуальных машин на виртуальные 379
Виртуальный коммутатор 108 ◊ сервера 537
оперативная P2V 539
◊ создание 609
◊ удаление 611 ◊ физических машин на виртуальные 378,
Виртуальный процессор 106, 302, 420 547
Моментальный снимок 431, 611
◊ производительность 306
Монитор виртуальных машин 21
◊ управление 96 Мониторы 388
Виртуальный рабочий стол 641
◊ динамический 647
◊ миграция 645 П
◊ резервное копирование 653 Память 287
◊ репозитарий 652 Паравиртуализация 23
◊ статический 647 План:
Виртуальный сетевой адаптер 57, 108, 424 ◊ миграции 751
◊ обмена информацией 753
Г Подкачка страниц 104
Поставщик WMI 89
Гипервизор 24, 39, 120
◊ Windows 84
Гипервызов 95
Р
"Горячая" миграция 49, 350 Рабочий процесс 99
Гостевая операционная система 301, 430 Раздел 16, 24, 85
◊ инсталляция 435 ◊ дочерний 41, 86, 211
Предметный указатель 781
◊ поддержка работы 97 У
◊ родительский 41, 86, 210
◊ управление 95 Удаленное управление 399
Риск, выявление 676 Удаленный рабочий стол 285
Роль Hyper-V, инсталляция 125 Устройство:
◊ синтетическое 86
◊ эмулированное 86
С
Сервер Virtual Machine Manager 376 Ф
Служба:
◊ завершения работы 195 Файл:
◊ интеграции 47, 109, 193, 302, 430, 438 ◊ Unattend.xml 135
◊ обмена парами "ключ/значение" 195 ◊ виртуального жесткого диска 73
◊ конфигурации виртуальной машины 63
◊ синхронизации времени 194
◊ подкачки 104
◊ тактовых импульсов 195
◊ расширение:
◊ теневого копирования 197
avhd 176
Стек виртуализации 86, 102, 184
bin 185
Страница памяти 103
exp 63
vfd 115
Т vhd 55, 170
vsv 185
Таблица выделения блоков 115 Ферма серверов 459, 472
Транкинг 209 Физическая память 103

0203..Платформа виртуализации Hyper-V

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

0203..Платформа виртуализации Hyper-V

Загружено:

Авторское право:

Доступные форматы

Роберт Ларсон, Жаник Карбон

совместно с Windows Virtualization Team

«Русская Редакция» «БХВ-Петербург»

© 2009-2012, Translation Russian Edition Publishers.

© 2009-2012, *   FFF «

ЧАСТЬ I. ПРИСТУПАЕМ К ИЗУЧЕНИЮ WINDOWS SERVER 2008

Сценарии виртуализации серверов ..............................................................................................33

Глава 2. Обзор Hyper-V ................................................................................................ 39

Глава 3. Архитектура Hyper-V ................................................................................... 83

Стек виртуализации ....................................................................................................................... 86

ЧАСТЬ II. РАЗБИРАЕМСЯ С СЕРВЕРОМ WINDOWS SERVER 2008

Глава 5. Расширенные функции Hyper-V .............................................................. 167

Глава 6. Безопасность Hyper-V................................................................................. 241

Обзор лучших практик по безопасности Hyper-V .................................................................... 271

Глава 7. Лучшие практики и оптимизация сервера Hyper-V ............................ 281

Глава 8. Переход с Virtual Server 2005 R2 на Hyper-V ......................................... 323

Миграция хоста Virtual Server 2005 R2 на Hyper-V .................................................................. 325

Глава 9. Знакомимся с сервером Windows Server 2008 R2 Hyper-V.................. 343

ЧАСТЬ III. УПРАВЛЕНИЕ ИНФРАСТРУКТУРОЙ WINDOWS

Глава 11. Управление одним сервером Hyper-V................................................... 393

Соображения относительно приложения Windows Server Backup .................................. 445

Глава 12. Управление фермой серверов ................................................................. 459

Глава 13. Резервное копирование и восстановление сервера Hyper-V ............ 501

Глава 14. Миграция серверов при помощи менеджера System Center

Автономная миграция физической машины в виртуальную ................................................... 547

Глава 15. Наблюдение за сервером при помощи пакета управления

Управление виртуальными сетями ..................................................................................... 609

ЧАСТЬ IV. МЕТОДОЛОГИЯ ПРОЕКТА ВИРТУАЛИЗАЦИИ

Глава 18. Инфраструктура виртуальных рабочих столов .................................. 641

Обзор решения VDI компании Microsoft ................................................................................... 655

Глава 19. Проект виртуализации серверов: фаза представления ..................... 661

Глава 20. Проект виртуализации серверов: фаза обнаружения ........................ 681

Резюме .......................................................................................................................................... 703

Глава 21. Проект виртуализации серверов: фаза оценки ................................... 705

Глава 22. Проект виртуализации серверов: фаза планирования

Глава 23. Проект виртуализации серверов: пилотная фаза ............................... 745

Глоссарий ...................................................................................................................... 761

Предметный указатель .............................................................................................. 777

Я посвящаю эту книгу двум моим детям — Алексу и Ксавье. Они

Джени Карбон (Janique Carbone) работает в области информационных технологий

Роберт Ларсон (Robert Larson) — ведущий разработчик консультационной службы

граммным продуктам. На вопросы по кодам нам отвечало несколько других разработ-

Поддержка Microsoft Partner

ных функциональных возможностей), по конфигурированию безопасности, по на-

Используемые условные обозначения

И НФОРМАЦИЯ С МЕСТА СОБЫТИЙ

Врезки написаны специалистами исключительно в информационных целях и могут

Примеры командной строки

Жирный шрифт Используется для указания элементов интерфейса

личных аспектов инфраструктур Hyper-V). Эти скрипты можно использовать либо в

либо откройте скрипт в редакторе Notepad и прочитайте комментарии скрипта.

Настройте сервер скриптов локального компьютера по умолчанию на Cscript.exe

Политика поддержки сборника ресурсов

Глава 1. Представляем виртуализацию

Глава 2. Обзор Hyper-V

Глава 3. Архитектура Hyper-V

фраструктура представляет собой более гибкую в управлении среду и помогает быст-

Виртуализация на основе процессоров семейства х86

И НФОРМАЦИЯ С МЕСТА СОБЫТИЙ

Виртуализация страничной организации процессора х86

Программные методики виртуализации трансляции адресов

Индексирование AMD-V (Rapid Virtualization Indexing)

Процессоры AMD (которые поддерживают RVI и вложенные таблицы) имеют вложенный

Экономия памяти при помощи NPT

© 2009-2012, * FFF «