При корректном удалении снимков виртуальной машины при её выключении снимки жёстких дисков должны объединяться автоматически. К сожалению, не всегда это получается и в силу разных причин папка со снимками может распухать и привести ко всяким неприятным последствиям. Инструмента по автоматическому объединению таких «бесхозных» снимков нет. Приходится делать объединение вручную. Для этого необходимо знать где находятся снимки жёстких дисков (находятся обычно в папке виртуальной машины в подпапке Snapshots) и где находится исходный vhd-файл, к которому эти снимки мы будем прикреплять. Так же необходимо понять в каком порядке объединять снимки. Сначала объединяем самый свежий снимок (дата изменения снимка при включённой виртуалке совпадает с текущей, например 20/05/2010) со снимком более старшим (дата изменения снимка меньше предыдущей, но больше остальных, например 15/05/2010). Получившийся в итоге снимок объединяем со следующим по старшинству. Процедуру повторяем до тех пор пока не остается один снимок, который объединяется с исходным vhd-файлом. Процедура получается следующая:

1. Выключаем виртуалку, чьи диски-снимки надо объединить.
2. Меняем расширения всех снимков с .avhd на .vhd.
3. На всякий случай делаем копии всех преобразуемых файлов (бывших .avhd и исходных .vhd).
4. Записываем порядок в котором быдем объединять диски (20/05/2010.vhd => 15/05/2010.vhd =>… => Virtual Disk.vhd), чтобы в процессе не сбиться.
5. В оснастке Hyper-V запускаем Edit Disk, выбираем самый новый снимок (20/05/2010.vhd). В окне выбора действия будет доступно только одно действие – Reconnect. Далее надо будет указать родительский снимок (предыдущий относительно того, который последний – 15/05/2010.vhd). При этом, для облегчения выбора, будет подсказка какой диск является родительским к исходному. Выбираем его. Нажимаем Finish.
6. Запускаем Edit Disk повторно, выбираем самый свежий снимок. В окне выбора действия должно появится 2 пункта – Compact и Merge. Нас интересует второй. Выбираем его. В окне Summary можно будет посмотреть какой снимок с каким объединяется. Убеждаемся что это нужные нам снимки и запускаем процесс. При больших размерах снимков процесс может длиться достаточно долго.
7. По завершении процесса в папке со снимками останется только самый новый снимок (20/05/2010.vhd). Родительский снимок (15/05/2010.vhd) будет удалён. Если в папке остались ещё более старые снимки, то переходим к пункту 5 и повторяем процесс объединения.
8. Запускаем снова Edit Disk, в окне  выбора действия будет 2 пункта – Compact и Merge. Выбираем второй. По завершении процесса в папке снимков снимков исходного диска не останется – все они будут объединены с исходным vhd-диском.
9. Теперь, если мы зайдём в свойства виртуальной машины, то при попытке посмотреть на свойства нашего разбитого на снимки диска будет ошибка – виртуалка не сможет найти последний снимок. Смело можно удалять диск из свойств виртуалки и подключать его заново.

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

Сделал миграцию (p2v) контроллера домена (Windows 2003 R2 x64 Ent) с помощью SCVMM 2008 R2 на сервер Hyper-V на базе Windows 2008, потом импортировал эту виртуалку на сервер Hyper-V на базе Windows 2008 R2. После этого (и может и сразу после миграции – к сожалению не отследил виртуалка выпадает в BSOD. Ошибку пишет:

STOP: 0x0000007B (0xFFFFFADFEA40F3C0,0xFFFFFFFFC0000034,0×0,0×0).

Делаю загрузку последней успешной конфигурации – грузится, но отсутствуют все устройства, которые устанавливаются Integrational Services. Через Add/Remove Program удаляю сервисы интеграции. Перегружается успешно. Ставлю их опять – находятся все устройства, но при перезагрузке опять появляется BSOD. Как лечить? Переустановить не получится (DC).

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

1. Загружаем виртуалку в режиме LastKnownGoodConfiguration.
2. Открываем реестр и смотрим следующий ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Wdf01000
3. Он должен иметь значение WdfLoadGroup. В моем случае (и у автора статьи из ссылки) там было base. Меняем на WdfLoadGroup.
4. Удаляем Integration Components.
5. Перегружаем виртуалку в обычном режиме.
6. Устанавливаем Integration Components заново.

По словам автора статьи, проблема была в том, что для загрузки драйвера хранилища требовалось подгрузить Windows Driver Framework (WDF), который не подгружался. Соответственно, не загружался драйвер хранилища, поэтому операционная система при запуске и вываливалась в BSOD с ошибкой о недоступности загрузочного устройства. Причиной же этого было некорректное значение соответствующего ключа реестра.

Наконец-таки дошли руки до интеграции SCVMM и OpsMgr. По идее, процесс выглядит достаточно просто – на сервере с OpsMgr ставится интеграционная компонента с диска SCVMM, на сервере с SCVMM ставится консоль OpsMgr. Затем в консоли SCVMM указывается корневой сервер OpsMgr. Всё выглядит просто в случае установки обоих продуктов на один сервер. Если же сервера разные, кроме этого базы хранятся на третьем сервере, то начинаются разные весёлые приключения.

Сам процесс интеграции в простейшем случае (всё на одном сервере) можно посмотреть здесь.

У меня же процесс интеграции застрял на этапе указания корневого сервера OpsMgr. Попытка возвращала ошибку «VMM service does not have necessary privileges to access the Operations Manager SDK service on <servername>. Add VMM service account as an administrator to the Operations Manager Server and try the operation again». Ниже небольшое описание того, как я ошибку победил.

1. Добавляем в группу локальных администраторов на корневом сервере OpsMgr сервисную учётную запись VMM.

2. Нужно дать права на чтение и на запись SPN для сервисной учётной записи OpsMgr SDK. Делается это через ADSIEdit следующим образом:

• В разделе Default naming context ищем сервисную учётную запись OpsMgr SDK.
• В её свойствах на закладке Security переходим в расширенные настройки (кнопка Advanced).
• Добавляем учётку SELF, на закладке Properties указываем область применения – This object only. Ставим галки Allow напротив Read servicePrincipleName и Write servicePrincipleName.
• После этого надо перезапустить сервис System Center Data Access на корневом сервере OpsMgr.

3. Создаём доменную глобальную группу VMMAdmins, добавляем в неё сервисную учётную запись VMM и учётную запись сервера VMM (объект компьютер).

4. Добавляем эту группу в Operations Manager Administrators через консоль OpsMgr (Administration => Security => User Roles => Operation Manager Administrators). Опять перезапускаем System Center Data Access (net stop OMSDK && net start OMSDK).

5. Перезапускаем сервер SCVMM, после этого через консоль VMM добавляем сервер OpsMgr (или через PoSh – Set-VMMServer -VMMServer <SCVMM Server> -OpsMgrServer <OpsMgr RMS Server>).

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

Буквально на днях при обновлении с RC на RTM VMM 2008R2 столкнулся со следующей проблемой. Один из хостов периодически отваливался от VMM. На самом хосте сервис Hyper-V Virtual Machine Management выгружался после двух минут работы. В события при этом шла ошибка:

Faulting application vmms.exe, version 6.0.6001.18221, time stamp 0x499f6aeb, faulting module ntdll.dll, version 6.0.6001.18000, time stamp 0x4791adec, exception code 0xc0000005, fault offset 0x000000000001e758, process id 0x6ec, application start time 0x01ca403665f3fc4e.

Гугл сразу вывел на обсуждение проблемы. Как оказалось, такое поведение системы связано с наличием на хосте виртуалки с подключенным SCSI-адаптером, к которому не подключены жёсткие диски. После удаления адаптера проблема исчезла.

На днях стала доступна для скачивания триальная версия SCVMM 2008 R2 RTM. Достаточно оперативно обновилась информация о том как обновиться с RC до RTM версии. Процесс выглядит следующим образом:

1. Делаем бэкап базы VMM 2008 R2 RC. На всякий случай. Если что-то пойдёт не так, можно будет откатиться.

2. Удаляем сервер VMM 2008 R2 RC с галочкой «retain db» и остальные установленные компоненты.

3. Обновляем оставшуюся после удаления базу с помощью утилиты UpgradeVMMR2RC.exe (доступна через Microsoft Connect). Для этого из командной строки, запущенной с расширенными привилегиями (Run as Administrator) на компьютере с установленными .NET Framework 2.0 и Microsoft SQL Server tools выполняется команда:

UpgradeVMMR2RC.exe –server <computername[\instancename]> -database <database>

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

4. Устанавливаем сервер VMM 2008 R2 RTM, при установке указываем использовать обновлённую базу. Затем консоль управления и, если необходимо, портал самообслуживания.

5. В консоли управления на странице хостов в поле действий обновляем страницу (Refresh), то же самое делаем на странице библиотек.

6. Обновляем агентов VMM на всех хостах. В связи с тем, что процесс обновления агентов влияет на производительность, рекомендуется запускаеть его одновременно не более чем на 25 хостах.

На этом обновление завершается. При обновлении переносится следующая информация: информация портала самообслуживания и пользовательские поля виртуальных машин и хостов. При обновлении не переносится: список задач (job table)  и пароли для профилей операционных систем и компьютеров.

Рабочая версия Hyper-V уже несколько месяцев назад вышла, более того – уже успел выйти специфический продукт Microsoft Hyper-V Server 2008. Самое время начинать активно использовать новую технологию виртуализации в рабочей среде. В связи с этим возникает 3, на мой взгляд, стандартных задачи по миграции в виртуальную среду Hyper-V:
1. Миграция с продуктов MS (VirtualPC/Virtual Server 2005).
2. Миграция с продуктов VMWare.
3. Миграция физических компьютеров в виртуальную среду.
К сожалению, найти документации по подобной миграции найти сходу не удалось.

Continue Reading »

Попросили поставить пару виртуальных машин в VMWare Server. Стоит он на Windows Server 2003 Ent sp2. Версия 1.0.7. работаю через Remote Desktop. Подцепил стандартные образы, изменил настройки памяти и процессоров, подправил размеры дисков. Работает. Выключаю. Пытаюсь поставить в свойствах виртуалок, чтобы они запускались от учётки локальной системы. Запускаю. Пустой экран. Закладка виртуалки говорит что работает. Через некоторое время виртуалка начинает пинговаться и потом появляется доступ через Remote Desktop. В VMWare Serve Console по прежнему пустой экран виртуалки.

С сегодняшнего дня стал доступен релиз Hyper-V – достаточно удачного (по сравнению с VirtualServer) решения по виртуализации от Microsoft.
Скачать можно отсюда:
KB950050 — Description of the update for the release version of the Hyper-V technology for Windows Server 2008
Update for Windows Server 2008 x64 Edition (KB950050)
Update for Windows Server 2008 (KB950050)
KB952627 — Description of the Windows Vista Service Pack 1 Management Tools update for the release version of Hyper-V
Update for Windows Vista for x64-based Systems (KB952627)
Update for Windows Vista (KB952627)

У меня Hyper-V RC0 на Win2k8 Server Core крутится уже месяца 2. Пока проблем особых не обнаружил. В ближайшее время обновлюсь и посмотрю что там нового появилось по сравнению с RC0.