Евгений Ферапонтов

Выключить ВМ -- это уже исключает "живую миграцию". Будет выполнена обычная миграция.
Какую ошибку получаете при выполнении миграции?
Лучший способ -- live migration, второй вариант лучше сразу забыть

Короче, проблема разрешилась крайне очевидным и неочевидным образом одновременно.
Отзеркалировал траффик с двух DHCP серверов. Заметил, что один из них не выдает настройки DNS в ответе. Проверил "проблемных клиентов" — они получают адрес как раз с него. Отметил, что останавливал службу DHCP всегда именно на нем. Проверил опции сервера — там пусто.
Выходит, при настройке failover relationship опции сервера не реплицируются.
Выходит, если бы я не был идиотом и сразу проверил правильность настройки второго DHCP, всей этой эпопеи не случилось бы. Другое дело, что я до сих пор не могу понять смысл подобного поведения: зачем иметь два active-active DHCP сервера с разными настройками?

Поставьте английскую версию. К релизу все вылижут.

Вам, скорее всего, поможет это видео: https://www.youtube.com/watch?v=RhWgifVqwjY

1. Хабр хабром, а Technet все же более авторитетным ресурсом является в вопросах Windows-систем. Нет причин заводить физический контроллер домена. В случае, если у вас полегли все ВМ (в т.ч. и КД), всегда можно зайти под локальным админом и перезапустить все, что душе угодно.
2. Хабр хабром, а Technet все же... Исходить стоит из требований к сети (полосе пропускания, используемым технологиям и т.п.). Скорее всего вам хватит двух-четырех физических гигабитных сетевых адаптера. Объедините их в teaming, поверх создайте внешний виртуальный коммутатор. Создайте виртуальный адаптер (галочка при создании коммутатора) для хост-системы, назначьте ему IP и при необходимости VLAN. Добавьте при создании ВМ необходимое количество сетевых адаптеров с соответствующими VLAN'ами.
3. Windows Backup Services все еще живее всех живых, и он умеет бэкапить Hyper-V. Вполне сносное и к тому же бесплатное решение.
P. S. Если опыта в виртуализации у вас нет от слова "совсем", зайдите на Microsoft Virtual Academy и посмотрите-почитайте пару вводных курсов. Для старта хватит, дальше по ходу дела разберетесь.

Это можно сделать с помощью командлета Set-VMNetworkAdapterVlan (https://technet.microsoft.com/en-us/library/hh8484... ). Но зачем? Зачем вам запихивать пачку виланов в один ВИРТУАЛЬНЫЙ интерфейс и затем разбирать их на стороне гостевой ОС пачкой других ВИРТУАЛЬНЫХ интерфейсов? Вам выше правильно написали: просто добавьте необходимое количество интерфейсов и настройте в них виланы. Никаких виртуальных свитчей плодить не надо.

Vgzrs 77424: без установки службы удаленных рабочих столов возможно использовать только два одновременных подключения, при чем по условию лицензии исключительно в административных целях. Если вы хотите, чтобы внутри удаленки обычные пользователи работали, гуглите на тему терминального сервера и RDS.

В Q3 2016 выйдет WS2016 с его фичей Storage Spaces Direct -- аналог VMware VSAN. Требования: не менее 4 хостов, 10Гбит сеть и редакция Datacenter.
Уже сейчас на WS2012R2 можно сделать SOFS, как писалось выше.

как избежать выхода из строя SAS JBOD'а,

JBOD'ы можно каскадировать. Два JBOD'а и mirror pool позволят избежать полного отказа одной полки. Отдавать хранилище хостам Hyper-V будете по SMB3.0, а если бюджет позволяет еще и RDMA сетевушки прикупить, тогда вообще проблем знать не будете.
Если будете строить какой-нибудь из Storage Spaces основательно и надолго, внимательно почитайте блог команды Storage Spaces на Technet'е, особенно их рекомендации касательно количества SSD на полку.
Также настоятельно рекомендую к прочтению
"руководство" по созданию SOFS: www.aidanfinn.com/?p=13176
планирование SDS на базе WS2016: www.aidanfinn.com/?p=18608
да и в целом неплохо было бы почитать весь этот блог -- этот мужик имеет MVP и пишет в основном про Hyper-V и хранилище под него.

Также никогда не стоит сбрасывать со счетов брендовые СХД от каких-нибудь HP или Dell. Стоить они будут сильно дороже за ту же производительность, но в случае проблем бить по голове будут не вас, а поддержку вендора.
P. S. Если все-таки решите смотреть в сторону Storage Spaces, рекомендую ознакомиться: www.supermicro.com/products/nfo/CiB.cfm
а также погуглить решения Cluster-in-a-Box от других вендоров. Это будет наиболее простым способом развернуть SOFS: обе ноды и дисковая полка в одном корпусе с заранее продуманными интерконнектами. Включи, настрой, используй. Расшириться в случае необходимости можно каскадированием JBOD'ов той же Supermicro, которые сейчас уже совершенно аномальной плотности существуют: до 90 3.5 дисков в 4 юнитах.

WS2016 обещает рай на земле для профи приложений в сценарии VDI.
Если есть деньги (по пакету перечисленного по осмелюсь судить, что они есть) -- VMware horizon. Из тройки лидеров решений VDI у них самое продвинутое. Если хотите сэкономить денег на лицензиях, берите MS -- по производительности, скорее всего, даже не потеряете.
Видеокарту следует выбирать на основе best practices выбранного вендора решения, рекомендаций вендора ПО и своих собственных тестов и замеров -- согласитесь, сценарии использования могут быть совершенно разными.

Отвечаю сам себе:
Для работы MS VDI в диспетчер лицензирования необходимо установить только RDS CAL. Также требуются лицензии Windows Server CAL в таком же количестве, что и RDS CAL, + лицензии на доступ к виртуальным рабочим столам (VDA в случае использования не Windows-устройств и/или без установленной Windows с включенными в редакцию таковыми правами). WS CAL и VDA достаются из конверта и устанавливаются в папочку с остальными лицензиями в сейф. Более действий не требуется.
Гостевые системы можно активировать ключом MAK в случае использования Personal Virtual Desktops, развертывание KMS необходимо лишь при использовании Pooled Virtual Desktops.

Спустя полгода сам отвечаю на собственный вопрос: создаем обычный сервер RDS (для единственного сервера можно тыкнуть "quick deploy" и получить рабочее решение, для двух и более серверов -- вынесение ролей RDS Gateway и Connection Broker на отдельные сервера, RDCB High Availability и DNS Round Robin. По этому поводу хорошо написано здесь: blog.it-kb.ru/2014/08/24/windows-server-2012-r2-re... и на technet'е)
На session host ставится базовый набор ПО (то, что используют оба отдела в моем случае), для "специфического" ПО использовать ферму (или единичный сервер) RemoteApp и разграничивать права доступа на уровне групп безопасности Active Directory.
В качестве ПО для тонких клиентов использовать Thinstation 5.X с пакетом freerdp или готовое ПО типа PoniX (www.t-sol.ru/about )

Прочитал тонны материалов по VPN, решил остановиться на IPsec + GRE. Вроде как это стандартный режим работы VPN на базе рутеров Cisco, что в дальнейшем потребует меньше усилий по перенастройке оборудования, плюс уменьшит оверхед при инкапсуляции (на один вложенный уровень меньше!).

Мы решили похожую проблему (только у нас еще + ко всему появлялась дополнительная фантомная русская раскладка) решили следующим образом:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"IgnoreRemoteKeyboardLayout"=dword:00000001

Вот это через групповые политики или вручную прописывается на каждом хосте сеансов RDP. Объяснять, что делает этот ключ, думаю, не нужно.