Russian Windows Virtualization Discussion

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

За последние пару месяцев мне несколько раз задавали вопрос, почему при копировании виртуальной машины сбрасываются настройки сетевых интерфейсов. Если честно, изначально я не придавал ему большого значения, но когда он прозвучал из нескольких независимых источников — я решил разобраться. В 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, возникают проблемы.