Физический в виртуальный сервер RD на одном сервере

Мне нужно физически виртуализировать наш сервер удаленных рабочих столов (Server 2008 R2), установить роль HyperV на физическом сервере, а затем, в конечном итоге, преобразованную виртуальную машину RD снова запустить на физическом сервере.

Я читал многочисленные темы на подобные темы, где некоторые люди предлагают, чтобы по крайней мере одна из них была новой установкой, чтобы избежать каких-либо проблем, связанных с дублированием SID/GUID и т. Д., И другие, предлагающие, что это будет хорошо, если один из них SYSPREP 'D (в документации Microsoft SYSPREP также говорится, что RD поддерживается). Тем не менее, я хочу исчерпать все возможности перед полной переустановкой / перестройкой физического или виртуального компьютера, поскольку есть пара других приложений, которые я хочу продолжать использовать на обоих и избежать переустановки / конфигурации. Я также хотел бы запустить виртуальную машину P2V на другом хосте HyperV, прежде чем изменять какую-либо / или минимальную конфигурацию текущей физической конфигурации, чтобы убедиться, что с виртуальной машиной все в порядке и все службы будут работать.

Что касается текущего Физического сервера, то он является шлюзом и на нем установлен менеджер лицензирования RD с настроенными на нем лицензиями наряду с удаленными приложениями.

Я намерен SYSPREP ВМ перед настройкой сетевого адаптера. Если я хочу избежать каких-либо изменений в текущем физическом, я предполагаю, что мне придется изменить имя сервера и IP-адрес виртуальной машины, а затем добавить / изменить любые внутренние правила DNS и брандмауэра, чтобы временно указать новый IP-адрес.

Однако вопросы таковы:

  1. Будет ли работать все в пределах виртуальной машины, включая лицензирование после преобразования и SYSPREP, или какая конфигурация потребуется? т.е. нужно ли будет заново настраивать лицензии?
  2. Требуется ли какая-либо дополнительная настройка для сервера удаленных рабочих столов, если имя сервера изменилось?

Ниже приводится разбивка того, что я надеялся, будет успешным:

  1. P2V Физический сервер, использующий внутреннюю систему sys disk2vhd.
    1. Переместите VHD на другой хост HyperV в нашей среде.
    2. Настройте новую виртуальную машину на хосте HyperV и подключите виртуальную машину, не настраивайте сетевой адаптер.
    3. Загрузите VM и SYSPREP
    4. Настроить сетевой адаптер, назначить IP, переименовать сервер
    5. Настройка Запись для внутреннего DNS и указание текущего входящего правила брандмауэра RD на новый IP-адрес виртуальной машины.
    6. После подтверждения работоспособности установите роль HyperV на физический сервер.
    7. Переместите ВМ обратно на физический сервер.

Есть ли что-то, что я упустил из виду или потенциальные подводные камни?

Заранее спасибо

Источник

1 ответ

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

Не зная больше о "паре других приложений", которые "вы хотите продолжать работать на обоих и избегать переустановки / конфигурации", трудно сказать, собирается ли sysprep их "сломать". Некоторые приложения поддерживают или корректно восстанавливаются из sysprep, в то время как другие требуют некоторого массажа; последнее особенно актуально для приложений GUID-y. Но мы не можем знать, потому что мы не знаем, что это за продукты. Было бы разумно открыть в Microsoft дело для получения инструкций по этому процессу в целом и обратиться к поставщику (-ам) по поводу рассматриваемого приложения.

Я бы, вероятно, выбрал путь, подобный следующему:

  1. Разработайте документ для проверки и регрессионного тестирования, если у вас его еще нет.
  2. Запланируйте время простоя в организации
  3. Сфотографируйте физическую машину (призрак, acronis, macrium, clonezilla, gparted, если нужно - что угодно)
  4. P2V "Физическая машина A" (PM-A) как "Виртуальная машина A" (VM-A)
  5. Раскрутите виртуальную машину в другом месте и подключите VHD/X для VM-A, созданный выше
  6. Сконфигурируйте вновь созданную виртуальную машину для VM-A (например, создайте коммутатор, поместите его в соответствующую VLAN и т. Д.)
  7. Выключите PM-A или отключите сетевой адаптер от PM-A.
  8. Включить ВМ-А
  9. Протестируйте и перенастройте VM-A и другие сервисы в организации соответствующим образом

Если VM-A функционирует должным образом, а службы продолжают функционировать так же, как и раньше для вашей организации, оставьте полнофункциональный сервер VM-A работающим как есть: не меняйте имя или IP-адрес или что-либо еще, так как это " Известная хорошая "конфигурация.

После того, как вы закончили выполнение проверочных и регрессионных тестов для VM-A, переключите свое внимание на PM-A, где вы можете: - очистить планшет, перестроив его, ИЛИ - выполнить sysprep, а затем соответственно перенастроить

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

  1. Восстановите PM-A с резервной копии, снятой ранее.
  2. Выключить ВМ-А
  3. Включите PM-A
  4. Возвращается на круги своя
Источник
Другие вопросы по тегам