Миграция виртуальной машины с SCVMM 2008

Как вы знаете, не так давно вышел продукт Microsft System Center Virtual Machine Manager 2008 (далее по тексту — VMM2008).
 
Одной из поддерживаемых конфигураций является установка VMM2008 на виртуальную машину. Первый же вопрос, который у меня возник — а сможет ли VMM2008 мигрировать виртуальную машину, где он сам и установлен? :)
 
Ответ меня удивил на столько же, на сколько и порадовал — да, может!
 
Моя конфигурация: 2 нода, в кластере, дисковое хранилище SAN.
При миграции виртуальной машины с VMM2008 с использованием Transfer Type = Cluster, виртуальная машина отлично смигрировала, даже не выдав ни одной ошибки.
 
Единственным минусом установки VMM2008 в виртуальной машине является то, что будет не доступен Transfer Type= SAN, т.к. такой перенос требует наличия VDS Hardware Provider-а и прямого доступа в SAN. Т.е. VMM2008 должен быть установлен на сервере с HBA.

Hyper-V и синхронизация времени

В очередной раз убедился, что надо внимательно читать документацию..

У нас основные котроллеры домена виртуальные,  находялся на хост-сервере под управление Windows 2008. С месяц назад люди начали жаловаться, что на компьютерах в домене время отличается от московсого на 1 минуту. Тогда этому особого значения не придали: сеть доменная, контроллеры домена обновляются из интернета, логи проверяются. Но когда недавно разница с сервисами точного времени (н-р http://www.direct-time.ru/) стала уже более 4 минут, стало совсем не до шуток.

Я долго и нудно проверял все настройки Службы Времени на контроллере домена, проверял доступность NTP-серверов — всё было вроде как нормально.

При попытка установить время руами, оно сбрасывается обратно на 4 минуты вперед. И только после долгово рассматривания логов меня превлек тот факт, что события синхронизации (источник — W32Time, ID — 35) идут парами. И только тогда меня осенило зайти и посмотреть, что именно происходит в этих событиях.

Первое событие — это моя вызванная руками синхронизация:

Описание:
Служба времени выполняет синхронизацию системного времени с источником времени ntp.mobatime.ru (ntp.m|0x0|**********************).

А вот второе, гораздо более интересное:

Описание:
Служба времени выполняет синхронизацию системного времени с источником времени VM IC Time Synchronization Provider.

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

Смысл басни таков — читайте внимательно документацию. И в доменных сетях, особено если виртуальной машиной является контроллер домена, отключайте синхронизацию времени в Hyper-V.

Best Practice — виртуальные сети в Hyper-V

 
Как я уже писал ранее, в Hyper-V имеются особенности работы при использовании в многоинтерфейсных конфигурациях.
Напомню в кратце. Есть 2 физических сетевых интерфейса, хотелось бы максимально использовать производительность обоих.
После долгих проб и ошибок, испробовав разные методы, я пришел к выводу, что  в случае, когда хост-сервер и все гостевые ОС находятся в одной подсети, оптимальна и работоспособна только одна конфигурация:
1. Настраиваем сетевые параметры, актуальные для вашей сети, на первом интерфейсе.
2. Настраиваем в Hyper-V виртуальную сеть на втором интерфейсе. Hyper-v отключает на нем все протоколы, кроме Microsoft Virtual Network Switch Protocol.
3. Отключаем вновь появившейся виртуальный интерфейс (его имя соответствует имени виртуальной сети в Hyper-V)
 
В этом случае обмен хост-сервера с гостевыми виртуальными ОС будет происходить через физический свитч.
 
В других случаях у меня были проблемы с доступностью гостевых систем с хост-сервера.
Н-р в случае, когда одна из виртуальных машин была контроллером домена, на хост-сервере netdiag "повисал" на этапе "Gathering the list of Domain Controllers for domain ‘MYDOMAIN’"
dcdiag выдавал ошибки
Testing server: MYDOMAIN\MYDC
      Starting test: Replications
         [Replications Check,MYDC] DsReplicaGetInfo(NEIGHBORS,DC=MYDOMAIN,DC=ru) failed with error 1728,
         Ошибка протокола удаленного вызова процедур (RPC)..
и
Starting test: ObjectsReplicated
   Failed to read object metadata on MYDC, error Неверный дескриптор.
   Failed to read object metadata on MYDC, error Неверный дескриптор.
 
После применения конфигурации, указанной выше все ошибки пропали. Да и доступ по сети к хост-серверу и виртуальным ОС стал происходить заметно быстрее.

Первые Best Practice при использовании Hyper-V

Hyper-V была создана с нуля, поэтому к ней нужно привыкать так же с нуля.
Первый нюанс, с котором я сталкнулся — это использование виртуальных сетей. Если раньше, в  Virtual Server 2005 R2, у меня вирутальные сетевые карты были подключены к тому же интерфейсу, который был основным для хостовой машины и проблем особо не наблюдалась, то после перехода на Hyper-V и использовании той же конфигурации, мы сталкнулись с проблемами.
 
На одной из виртуальных машин работает контроллер домена. Хост машина входит в этот домен, и должна авторизоваться на этот самом DC. Так вот через несколько часов после старта хост-машина просто "потеряла" соединение с доменом. Выглядело это как проблемы с DNS — не возможно найти DC, ошибки получения GroupPolicy, крайне долгий вход в систему и прочее. При этом все остальные компьютеры в сети отлично авторизовались, DC был доступен.
После долгих проб и ошибок пришла идея разнести основной сетевой интерфейс хост-сервера и виртуальные сетевые интерфейсы гостевых машин по разным физическим интерфейсам. Данная мера помогла.
 
Вывод: рекомендуется разделять основной сетевой интерфейс хост-сервера и виртуальные интерфейсы гостевых машин по разным физическим интерфейсам.

Миграция с Virtual Server 2005 R2 на Hyper-V

 
В связи со скорым выходом окончательной версии Hyper-V — нового средства виртуализации, встроенного в Windows 2008 Server, думаю у многих встанет вопрос о том, как максимально безболезнено перейти с Virtual Server 2005 на Hyper-V.
Процесс миграции достаточно прост, т.к. Hyper-V умеет работать с виртуальными дисками (.vhd) Virtual Server 2005 R2. но при этом, есть несколько подводных камней, знание которых поможет съэкономить массу времени и нервов.
Я буду описывать процесс миграции на основе Hyper-V RC1. Процесс разбит на 3 части: Подготовительная, Установка Windows 2008 Server и Hyper-V и Настройка виртуальных машин.

Ресурсы:
 
Часть 1. Подготовительная.
Перед началос процесса миграции необходимо произвести ряд подготовительных действий, начать которые я крайне рекомендую с прочтения документации, и в особоенности системных требований к Windows 2008 Server с ролью Hyper-V.
Основные требования к "железу", на котором будет работать Hyper-V — поддержка процессором и материнской платой опций Intel VT и Disable Execution Bit для Intel-овских компонентов и AMD-V и No Execute для AMD-шных.
После прочтения документации и подготовки необходимого аппаратного обеспечения, можно приступать к работе.
  1. Необходимо получить последнюю версию Hyper-V и средств управления. На момент написания статьи был доступен Hyper-V RC1.
  2. В случае, если это первый сервер под управлением Windows Server 2008, и вы используете Windows XP в кач-ве рабочей станции для управления, необходимо озаботиться установкой клиента RDP 6.0 (или выше) для подключения к новому серверу. Установить средства управления Hyper-V на Windows XP нельзя. Средства управления hyper-V можно установить, если управление будет производиться с рабочей станции под управлением Windows Vista (не ниже SP1).
  3. Все гостевые системы Virtual server 2005 R2 необходимо обновить:
    — Windows Server 2003: не ниже SP2
    — Windows Server 2000: не ниже SP4
    — Windows XP: не ниже SP3
  4. Следует помнить, что после включения виртуальных машин на хост-машине с Hyper-V, в них появится новая (или новые) сетевые карты, а те, что использовались с Virtual Server 2005, будут недоступны. В связи с этим необходимо проделать такие же необходимые операции, как и в обычном сервере при смене сетевой карты. Минимально что я бы рекомендовал — удалить все назначенные в ручную IP-адреса. Максимально — удалить адреса и удалить все сетевые интерфейсы из устройств перед выключением виртуальной машины.
  5. Запомнить или записать настройки всех виртуальных машин (объем памяти, диски и пр.).
  6. Удалить из всех виртуальных машин VM Additions.
  7. Выключить все виртуальные машины. Hyper-V не поддерживает виртуальные диски Virtual Server 2005 R2 с сохраненным состоянием системы (Save).
  8. Выключить сервис Virtual Server и сделать полный бакап системы и виртуальных дисков в случае, если миграция будет происходить in-place, т.е. Hyper-V будет работать на том же сервере, на котором работал Virtual Server 2005 R2.
 
Часть 2. Установка Windows Server 2008 с ролью Hyper-V
Подробно описывать сам процесс установки не буду, опишу лишь те части его, на которые необходимо обратить внимание.
  1. Установить Windows Server 2008 x64 Standard, Enterprise или Datacenter на хост-машину в полном или Core-режимах.
  2. Для бОльшей стабильности и производительности крайне рекомендуется установить драйвера на компоненты сервера от производителя, в особенности это касается сетевых карт и различных RAID-контроллеров. От себя добавлю, что не сморя на то, что в Intel-овском наборе PROset для встроенных сетевых карт на сайте не значится поддержка Windows Server 2008, на самом деле она там есть, что написано в readme-файле этого набора.
  3. Установить обновление, соотвествующее текущей версии Hyper-V (на момент написания статьи — Windows6.0-KB950049-x64.msu)
  4. Через "Диспетчер сервера" или "Панель Управления" — "Программы и компоненты" добавить роль Hyper-V.

Часть 3. Настройка Hyper-V и виртуальных машин

  1. Необходимо мастером создать каждую из существовавших виртуальных машин с такими же параметрами, как они были раньше. В параметрах дисков необходимо выбрать файл .vhd, соотвутствующей каждой вирутальной машине. Крайне рекомендуется ен включать
  2. После этого необходимо добавить необходимое кол-во виртуальных SCSI-контроллеров, сетевых интерфейсов, процессоров и пр. Особенно внимательно надо отнестить к сетевым интерфейсам. См. Примечание в конце статьи.
  3. Запустить виртуальную машину. Надо быть готовым к тому, что:
    — в случае, если используется несколько виртуальных дисков, буквы дисков могут быть изменены, т.к. в системе могут появиться новые контроллеры.
    — виртуальный сервер запуститься отключенным от сети, в случае использования Native виртуального сетевого адаптера. См. Примечание в конце статьи.
  4. Запустить установку компонентов интеграции. Для этого в окне управления виртуальной машины выбрать "Действие" — "Вставьте установочный диск служб интеграции"
    image
  5. В Windows Server 2003 процесс установки будет проивходить в 2 этапа: в начале будет заменен HAL системы, потребуется перезагрузка. После перезагрузки будет запущен процесс установки самих компонентов интеграции. После установки вновь потребуется перезагрузка:
    замена HAL image image
    Замечание. После замены HAL и перезагрузки может появится вот окно Waiting for previous device installation to complete:
    image
    В этом случае надо завтрыть окно "Мастера нового оборудования" и установка продолжится автоматически.
  6. Необходимо назначить IP-адрес сетевому адаптеру (или прописать нужный МАС-адрес в настройках виртуальной машины) в виртуальных машинах и проверить назачение букв дисков.
  7. Проверить запуск всех сервисов каждой виртуальной машины.
Примечание. Legacy сетевые карты и обычные
В Hyper-V доступны 2 вида сетевых карт, отмечу различные особенности каждой их них:
  1. Legacy сетевая карта эмулирует сетевую карту DEC 21140, что позволяет использовать её без драйверов вплоть до Windows 95. "Обычная" виртуальная сетевая карта используется собственный драйвер, доступный только с компонентами интеграции Hyper-V. Как следствие, "обычная" карта будет работать только в тех ОС, для которых есть компоненты интеграции.
  2. Legacy сетевая карта позволяет производить установку ОС из сети. Обычная, как следствие пункта 1, нет.
  3. Legacy сетевая карта имеет крайне низкую производительность по сравнению с "обычной" сетевой картой

Дополнительная информация по теме: Работа с унаследованными (Legacy) сетевыми адаптерами в Windows XP и Server 2003 x64

Ошибка «The switch could not bind to ‘interface name’ because it is already bound to another switch» при попытке сменить сетевую карту в настройках виртуальных сетей

Поймал забавную ошибку, когда эксперементировал с виртуальными сетями в Hyper-V RC1. На хостовом сервере было 2 сетевых интерфейса, Extrenal Network была подключена ко второму.

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

После этого мне захотелось сменить в настройках Virtual Network сетевой интерфейс на первый. После переключения и нажатия "применить" выскакивает вот такая ошибка: "Setup switch failed. The switch could not bind to ‘имя сетевого интерфейса’ because it is already bound to another switch":

image

Проблема решается достаточно просто — необходимо в настройках интерфейса отключить привязку протокола "Microsoft Virtual Network Switch Protocol" и повторить настройку виртуальных сетей в Hyper-V:

image