Решение проблемы регистрации виртуальных машин в DNS


Обычно мы всегда знаем, кто именно виноват. Но существуют ситуации, в которых нет правых и виноватых: невозможно однозначно указать, кто именно должен был реализовать и что именно. Вот пример такой ситуации.

При генерации пула виртуальных машин VMware View  (linked clones pool) создаются учетные записи компьютеров в указанном контейнере AD. Виртуальные машины запускаются, получают ip адреса по протоколу DHCP, регистрируют себя на DNS серверах. Как правило регистрация в DNS серверах настроена как secure, т.е. только компьютер-создатель записи имеет право ее изменять и удалять. Этот механизм защищает DNS сервер от атак подмены адресов. Когда мы запускаем повторную генерацию пула виртуальных машин (recompose) происходит следующее: существующие виртуальные машины удаляются как объекты и файлы на виртуальной платформе, а также удаляются их учетные записи из AD, после чего происходит создание новых виртуальных машин, включение их в домен и запуск. Теперь появилась новая виртуальная машина со старым именем, и это имя она пытается зарегистрировать в DNS, но такое имя там уже есть, и создано оно от имени другой учетной записи! – SID новой виртаульной машины другой. В результате получаем проблему: после регенерации пула виртаульные машины не могут себя зарегистрировать в DNS, пока мы не очистим его вручную, или пока не пройдет самоочистка DNS от старых записей (если она настроена).

Так как ничего путного в документации по VMware View  мне не попалось, пришлось обратиться в уважаемому Интернету. И удивительное дело – ничего по этой проблеме серьезного не обнаружилось: всего несколько сообщений типа «я отключил DNS secure updates и – о чудо! –  все заработало». Но отключение безопасных обновлений DNS это не только глупость, но и смертельный приговор всей AD.

Проблема для меня была негорящей и поэтому оставалась открытой пару месяцев. Но вот на днях пришлось взяться за нее серьезно, но взяться серьезно не получилось: поиск в Интернете сразу вывел на комментарий в блоге, где предлагалось работающее решение (после его тестирования могу сказать, что действительно работает). Хотя сама статья блога совершенно неправильная, ссылку приведу ради путного комментария http://paulslager.com/?p=1232

Суть решения:

1.       Создать скрипт с командами:

start ipconfig.exe /release

 timeout /t 5

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

Теперь после инициации recompose VMware View  выключает виртуальные машины, выполняя в гостевых операцилнных системах Shutdown, при этом срабатывает скрипт и освобождает ip адрес (в том числе удаляется запись в DNS).

Побочный эффект: ip адрес сбрасывается при любой перезагрузке виртуальной машины.

Еще один вариант, который мне пришел в голову:  настроить на DNS серверах максимально короткое время самоочистки (scavenging). Оно будет равно 2-3 часа. Если сгенерировать пул ночью, то к утру виртуальные машины в любом случае пропишутся в DNS. Вариант отметается как издевательство на DNS и AD: даже в небольшой сети будет лавина обновлений и очисток DNS плюс лавина репликаций между домен-контроллерами для обновлений зон.

Заключение

Как видите ситуация достаточно специфическая, и невозможно однозначно сказать кто «виноват». Microsoft вроде как не при чем: откуда операционной системе знать, что ее убивают? С другой стороны VMware View не знает, с каким именем операционная система регистрируется в DNS и регистрируется ли вообще. Возлагать на VMware сохранение SID-ов – это лишиться всячекой поддержки от Microsoft на веки вечные: есть лишь один поддерживаемый механизм клонирования операционных систем Windows sysprep.

Единственный вариант, который я вижу, это автоматизация от VMware: научить VMware View агента, установленного в операционной системе, запускать ipconfig.exe /release в ответ на инициацию процедуры recompose.

Если кто-то из специалистов по VMware знает более правильное решение, то буду рад увидеть его в комментариях к этой статье.

Реклама

комментария 2

  1. Наверное всё таки не logoff а shutdown сценарий. Иначе адрес будет освобождаться и при каждом логоффе, и перелогиниться может оказаться проблемой :)
    ЗЫ: Ты уверен что ipconfig /release в шатдаун скрипте поддерживается? Я нет :) ОС вообще-то может и сама выполнять какие нибудь действия с сетью при завершении работы.

    • Да shutdown :-) Спасибо, Василий, что увидел опечатку.

      Как автор рецепта написал (в комментарии по ссылке), ipconfig /release работает, но только если поставить после него паузу

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: