Hyper-V и синхронизация времени

В очередной раз убедился, что надо внимательно читать документацию..

У нас основные котроллеры домена виртуальные,  находялся на хост-сервере под управление Windows 2008. С месяц назад люди начали жаловаться, что на компьютерах в домене время отличается от московсого на 1 минуту. Тогда этому особого значения не придали: сеть доменная, контроллеры домена обновляются из интернета, логи проверяются. Но когда недавно разница с сервисами точного времени (н-р http://www.direct-time.ru/) стала уже более 4 минут, стало совсем не до шуток.

Я долго и нудно проверял все настройки Службы Времени на контроллере домена, проверял доступность NTP-серверов — всё было вроде как нормально.

При попытка установить время руами, оно сбрасывается обратно на 4 минуты вперед. И только после долгово рассматривания логов меня превлек тот факт, что события синхронизации (источник — W32Time, ID — 35) идут парами. И только тогда меня осенило зайти и посмотреть, что именно происходит в этих событиях.

Первое событие — это моя вызванная руками синхронизация:

Описание:
Служба времени выполняет синхронизацию системного времени с источником времени ntp.mobatime.ru (ntp.m|0x0|**********************).

А вот второе, гораздо более интересное:

Описание:
Служба времени выполняет синхронизацию системного времени с источником времени VM IC Time Synchronization Provider.

Собственно тут всё стало понятно. Контроллео домена добросовестно синхронизуруется с интеренетом, а службы интеграции Hyper-V синхронизируются с хост-серверами, которые в свою очередь еще не успели синхронизироваться с котроллером домена. Получается замкнутый круг.

Смысл басни таков — читайте внимательно документацию. И в доменных сетях, особено если виртуальной машиной является контроллер домена, отключайте синхронизацию времени в Hyper-V.

Best Practice — виртуальные сети в Hyper-V

 
Как я уже писал ранее, в Hyper-V имеются особенности работы при использовании в многоинтерфейсных конфигурациях.
Напомню в кратце. Есть 2 физических сетевых интерфейса, хотелось бы максимально использовать производительность обоих.
После долгих проб и ошибок, испробовав разные методы, я пришел к выводу, что  в случае, когда хост-сервер и все гостевые ОС находятся в одной подсети, оптимальна и работоспособна только одна конфигурация:
1. Настраиваем сетевые параметры, актуальные для вашей сети, на первом интерфейсе.
2. Настраиваем в Hyper-V виртуальную сеть на втором интерфейсе. Hyper-v отключает на нем все протоколы, кроме Microsoft Virtual Network Switch Protocol.
3. Отключаем вновь появившейся виртуальный интерфейс (его имя соответствует имени виртуальной сети в Hyper-V)
 
В этом случае обмен хост-сервера с гостевыми виртуальными ОС будет происходить через физический свитч.
 
В других случаях у меня были проблемы с доступностью гостевых систем с хост-сервера.
Н-р в случае, когда одна из виртуальных машин была контроллером домена, на хост-сервере netdiag "повисал" на этапе "Gathering the list of Domain Controllers for domain ‘MYDOMAIN’"
dcdiag выдавал ошибки
Testing server: MYDOMAIN\MYDC
      Starting test: Replications
         [Replications Check,MYDC] DsReplicaGetInfo(NEIGHBORS,DC=MYDOMAIN,DC=ru) failed with error 1728,
         Ошибка протокола удаленного вызова процедур (RPC)..
и
Starting test: ObjectsReplicated
   Failed to read object metadata on MYDC, error Неверный дескриптор.
   Failed to read object metadata on MYDC, error Неверный дескриптор.
 
После применения конфигурации, указанной выше все ошибки пропали. Да и доступ по сети к хост-серверу и виртуальным ОС стал происходить заметно быстрее.