Russian Windows Virtualization Discussion

Запрет смены пароля ОС для предотвращения устаревания снимков и неиспользуемых ВМ

Периодически я сталкиваюсь с ситуацией, когда пароль компьютера в локальном хранилище теряет синхронизацию с доменом. Это происходит как при восстановлении старого снимка (snapshot) виртуальной машины, так и просто при запуске тестовой машины, которая не включалась несколько месяцев. Результатом обычно бывает недоступность домена, что исправляется выводом ВМ из домена и повторным присоединением. Технически данная проблема вообще не связана с виртуализацией. Если вы выключаете любой доменный компьютер более, чем на 60 дней, то при включении он может быть не принят контроллером в виду проблем с так называемы «безопасным каналом» (secure channel). Если же вы используете снимки в виртуальных машинах, то в течении 30 дней с момента создания снимка компьютер должен сменить свой пароль в домене, После чего, применив снимок, вы уже не сможете зайти в домен. Сегодня мы рассмотрим эту проблему и способы ее решения.

Утилита Microsoft для проверки поддержки Hyper-V на вашей системе

Еще перед выходом первой версии Hyper-V мы обсуждали способы проверки совместимости вашей системы с виртуализацией Microsoft. С тех пор прошло более года, у Microsoft на подходе новое поколение операционных систем, новая версия Hyper-V, а также своя утилита для проверки совместимости. В комплект Windows Logo Kit теперь входит утилита Virtualization Detect Tool (VpDetect.exe), которая по идентификатору процессора (CPUID) и значениям MSR определяет совместимость вашего процессора с технологиями виртуализации Microsoft.

Работа с Порталом самообслуживания SCVMM (Self-Service Portal) с компьютера под управлением Windows7 / Server 2008 R2

Я уже описывал процесс установки Портала самообслуживания SCVMM 2008 (Self-Service Portal). Однако, с тех пор в мире произошли определённые изменения. В частности, появились операционные системы Windows 7 и Server 2008 R2, с которых, возможно, вам потребуется работать с Порталом. Увы, сразу это не получится. Вместо этого вы станете получать ошибку типа «Virtual Machine Manager failed to connect to the virtual machine because the guest operating system's computer name Х could not be resolved by the Domain Name System», где Х — это имя вашей виртуальной машины.

Вышло кумулятивное обновление для SCVMM 2008

На днях, вместе с апрельскими обновлениями безопасности, стало доступно кумулятивное обновление 961983 для System Center Virtual Machine Manager 2008. Это исправление решает целый ряд проблем.

Обновление пакета управления VMM 2008 для OpsMgr 2007

Я надеюсь, что вы уже успели попробовать настройку интеграции между System Center Operations Manager 2007 и System Center Virtual Machine Manager 2008 — хотя бы в тестовой среде. И, возможно, вы столкнулись при этом с некоторыми досадными проблемами. Более того — возможно, вы уже в курсе того, что для исправления этих проблем должно было выйти обновление пакетов управления. И оно действительно появилось уже пару недель назад. Если вы этого ещё не сделали — то настоятельно советую обратить внимание и загрузить System Center Virtual Machine Manager 2008 Management Pack for System Center Operations Manager 2007 версии 2.0.3451.0 с сайта Microsoft Download Center. Итак, будем считать, что у вас уже развёрнута конфигурация с установленными SC OpsMgr 2007 и SC VMM 2008, а также настроена интеграция между ними. В этом случае у вас используется пакет управления первоначальной версии 2.0.3444.0, которая поставлялась вместе с дистрибутивом VMM 2008. Теперь имеет смысл обновить пакет управления — но эта процедура может выглядеть не вполне тривиальной для администраторов, не имющих достаточного опыта работы с OpsMgr. Поэтому сейчас я вкратце расскажу о том, с какой проблемой столкнулся у одного из своих заказчиков в ходе проведения обновления.

Новый инструмент — Virtual Machine Manager Configuration Analyzer (VMMCA) 2008

Virtual Machine Manager Configuration Analyzer (VMMCA) 2008 — это новый диагностический инструмент. Он предназначен для оценки и поиска потенциальных неполадок в работе серверов, которые предназначены для установки различных ролей System Center Virtual Machine Manager (SC VMM) 2008 или уже выполняют эти роли.

Удаление VMAdditions из Hyper-V

Мы уже разговаривали о совместимости виртуальных машин между различными платформами виртуализации Microsoft. Очевидно, что большинство задач переноса ВМ касаются перехода на Hyper-V. Обычно вы без проблем можете создать новую виртуальную машину в Hyper-V и подключить к ней виртуальный диск с ОС, установленной под Virtual Server 2005. При этом часто пропускается такой важный момент, как предварительное удаление Virtual Machine Additions. В результате вы не сможете установить Integration Services, так как установлены VM Additions (проверка осуществляется по наличию службы 1-vmsrvc). Казалось бы, перед вами тривиальная задача, — достаточно удалить VM Additions, и можно будет установить службы интеграции. Но тут-то и появляется проблема. В виртуальной машине, запущенной под Hyper-V, вы сможете удалить VM Additions только начиная от версии 13.813, которая поставлялась с Virtual Server 2005 R2 SP1. Предыдущие версии VM Additions отказываются удаляться будучи запущенными в «не родной» системе виртуализации. Если ваша виртуальная машина создавалась в более ранеей версии Virtual Server или Virtual PC, и вы не обновляли VM Additions в ней, то подключив такой виртуальный диск к виртуальной машине Hyper-V, вы просто не сможете удалить VM Additions штатным образом. Придется устанавливать Virtual Server 2005 или Virtual PC, загружать ВМ в этой платформе, удалять VMAdditions, а только затем возвращать виртуальный диск в Hyper-V и устанавливать службы интеграции. Но есть и обходной путь, который устраняет необходимость этого шага.

Ошибка при попытке запуска виртуальной машины в Hyper-V: «The application encountered an error while attempting to change the state of Virtual Machine»

На описание этой ошибки я уже несколько раз натыкался на форумах, посвящённых обсуждению Hyper-V. Да и сам сталкивался с ней пару раз, когда только начинал осваивать этот новый продукт. Попытка запустить виртуальную машину завершается неудачей. Вместо этого выводится сообщение с текстом: «The application encountered an error while attempting to change the state” of ».

Posted by Artem | 27 Comments

Filed under: Hyper-V, Management, Errors, Storage, Troubleshooting, Basics

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

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

Hyper-V Constrained Delegation of Authority — или как подключить образы компакт-диска с другого сервера или разместить виртуальные диски на сетевом ресурсе

Я думаю, что многие из вас уже пробовали подключить к виртуальному компакт-диску ВМ образ в формате ISO, который лежит на неком файловом сервере. Или может вы пробовали подключить к виртуальный диск в формате VHD, находящийся на удаленном сервере, а не локальном диске? Ведь благодаря SMB 2.0 производительность сети в Windows Server 2008 значительно увеличилась — и особенно это заметно при доступе к крупным файлам. Так или иначе, вне зависимости от того, используете вы Hyper-V, Virtual Server 2005 или даже какое-то стороннее решение виртуализации (при условии, что оно запускается не как приложение пользователя, а как служба ОС), задачу подключения дисков к ВМ по сети вы сразу выполнить не сможете. Причина конечно же известна — службы работают в контексте учетной записи «Local System», которая не всегда имеет права доступа к сетевым ресурсам. В Базе знаний Microsoft есть несколько статьей, посвященных этой проблеме. Сегодня мы детально разберемся в нем, чтобы более вопросов не возникало. Я буду описывать подход для Windows Server 2008 и Hyper-V — но имейте в виду, что для Windows XP/2003/Vista и Virtual Server 2005 все делается аналогично. Причем оговорюсь сразу — я описываю только поддерживаемый Microsoft способ с использованием Constrained Delegation, а не манипуляции с выдачей прав на различные объекты учетным записям компьютеров.

Обновление службы NLB для Hyper-V

На прошлой неделе я писал об обновлении службы Failover Clustering для Hyper-V, сегодня расскажу об обновлении службы Network Load Balancing. Сразу отмечу, обновление не такое значительное, как для службы Failover Clustering, и требует установки лишь в тех сценариях, когда изначальная версия работает некорректно. Несколько месяцев назад я рассказывал о полной поддержке всех сценариев работы NLB в виртуальных машинах на Hyper-V и их комбинациях. Однако в некоторых случаях при создании кластера NLB на виртуальной машине или добавлении ее в существующий кластер NLB, возникают проблемы.

Окончательный выпуск Hyper-V — возможная проблема при удалённом подключении

При работе с Hyper-V, как и с большинством других серверных технологий, рекомендованной является схема удалённого управления. То есть сама роль виртуализации выполняется на сервере, а управление ей осуществляется с рабочей станции администратора. В случае Hyper-V инструменты удалённого управления были выпущены для Windows Vista Service Pack 1 и Windows Server 2008 x86. У тех, кто уже успел установить окончательную версию Hyper-V, иногда возникет следующая проблема. Попытка подключения к серверу с помощю консоли Hyper-V Manager завершается ошибкой, которая гласит: «Access denied. Unable to establish communication between» (Доступ запрещён. Невозможно установить соединение между… — дальше указываются имена удалённого сервера и рабочей станции администратора).