Добавили в кластер Hyper-V старый сервер, а ВМ на него не мигрирует: какой режим совместимости процессора выбрать в Windows Server 2025

«Поставили галочку „Перенос на физический компьютер с другим процессором“, а живая миграция всё равно валится» — это самый частый звонок после того, как в кластер Hyper-V доложили сервер прошлого поколения. Галочку принимают за универсальную гарантию, а она включает совсем не тот набор инструкций, который нужен в конкретном сценарии. Ниже — как в Windows Server 2025 устроены два режима совместимости процессора, чем `CommonClusterFeatureSet` отличается от `MinimumFeatureSet`, какие команды это переключают, где я на этом обжёгся и что делать в первую очередь.

Симптом: галочка стоит, миграция падает

Классика жанра. Один свежий хост на Windows Server 2025 год тянет все виртуалки, всё летает, но отказоустойчивости нет. Чтобы её получить, из кладовки достают сервер прошлого поколения — снятый с работы после прошлой замены, на пару поколений процессоров старше, но с нормальной памятью и дисками, выбрасывать жалко. Из двух узлов собирают кластер, валидация проходит, оба узла показывают Up. Пробуют утащить на старый узел первую же ВМ живой миграцией — и получают отказ на этапе предварительной проверки, до того как хоть один мегабайт памяти успел уехать.

Текст ошибки при этом честный и вполне читаемый, просто его никто не дочитывает до конца:

Virtual machine migration operation for 'RDS-03' failed at migration source 'HV-01'.
The virtual machine 'RDS-03' is not compatible with physical computer 'HV-02'.
The virtual machine is using processor-specific features not supported on
physical computer 'HV-02'. To allow for migration of this virtual machine to
physical computers with different processors, modify the virtual machine
settings to limit the processor features used by the virtual machine.

«Modify the virtual machine settings to limit the processor features» — вот здесь и начинается путаница. Администратор идёт в Hyper-V Manager, в свойствах ВМ раскрывает «Процессор → Совместимость», ставит галочку «Перенести на физический компьютер с другим процессором», перезапускает машину — и в половине случаев миграция начинает работать, а в половине падает ровно так же. Потому что галочка в Hyper-V Manager — это не «включить совместимость вообще». Это конкретный режим с конкретным набором инструкций, и он может быть не тем, который вам нужен.

• Проверка совместимости процессора выполняется ДО начала передачи памяти — миграция отваливается мгновенно, а не «на 90 %»;
• если вы ВМ просто выключите и запустите на новом узле, всё стартует без всяких галочек: гостевая ОС заново перечитает возможности процессора при загрузке;
• режим совместимости меняется только на выключенной ВМ — на работающей команда вернёт ошибку;
• между Intel и AMD не помогает ни один режим: живая миграция и восстановление из saved state между разными производителями невозможны в принципе.

Два режима: минимальный набор и общий кластерный

В Windows Server 2025 режимов совместимости процессора стало два, и это ключевая вещь, которую надо развести в голове раз и навсегда.

Стандартный режим (MinimumFeatureSet) — старый, знакомый ещё со времён Windows Server 2008 R2. Он показывает виртуальной машине фиксированный, заранее заданный набор возможностей процессора, никак не связанный ни с вашим железом, ни с составом кластера. Microsoft описывает его прямо: скрываются наборы инструкций, появившиеся примерно за последние десять лет. Это тот самый режим, который включает галочка в Hyper-V Manager. Его сила — предсказуемость: ВМ с таким набором уедет вживую практически на любой хост того же производителя CPU, хоть в соседний кластер, хоть на одиночный сервер. Его цена — вы отдаёте всё, что процессор научился делать за десятилетие.

Динамический режим (CommonClusterFeatureSet) появился именно в Windows Server 2025 (и в Azure Local начиная с версии 21H2). Он не берёт фиксированный список, а вычисляет пересечение возможностей всех узлов кластера и отдаёт ВМ максимум того, что есть у всех одновременно. Пересчёт происходит автоматически и реплицируется по кластеру — отдельной команды «включить вычисление» нет, оно работает само, когда ВМ живёт в кластере. Требование одно, но жёсткое: конфигурационная версия ВМ 10.0 или новее. Если у машины версия старше — она молча откатится на стандартный минимальный набор, и вы этого никак не заметите, пока не сравните вывод Coreinfo.

Практическая разница огромна. Возьмите кластер из узлов на Ice Lake и одного узла на Broadwell. Динамический режим оставит виртуалкам AVX2 (он есть у обоих) и заберёт только AVX-512 (его нет у Broadwell). Минимальный режим, по моим сверкам через Coreinfo, срезает и AVX2 тоже: ему всё равно, какое у вас железо, он живёт по своему фиксированному списку, а AVX2 как раз попадает в «последние десять лет». Для 1С, SQL, архиваторов и всего, что упирается в векторные операции, это заметная разница.

• `MinimumFeatureSet` — фиксированный набор, максимальная мобильность, максимальная потеря возможностей;
• `CommonClusterFeatureSet` — пересечение узлов кластера, мобильность в пределах кластера, потери минимальные;
• требования динамического режима: хост Windows Server 2025 / Azure Local 21H2+, конфигверсия ВМ 10.0+, ВМ выключена на момент переключения;
• Hyper-V Manager динамический режим не настраивает вообще — только PowerShell или Windows Admin Center;
• оба режима бессильны при смене производителя процессора (Intel ⇄ AMD).

Как выбираю режим я

У меня простое дерево решений на три ветки, и оно закрывает почти все реальные ситуации у клиентов на 20–50 рабочих мест.

Ветка первая: ВМ живёт в одном кластере и никуда за его пределы вживую не ездит. Это 90 % случаев. Ставлю CommonClusterFeatureSet. Получаю максимум производительности при полной свободе перемещения между узлами — можно спокойно ставить узлы в обслуживание, ронять их на патчи, драйнить роли. Именно ради этого динамический режим и делали.

Ветка вторая: ВМ надо уметь вживую утаскивать наружу — в другой кластер, на отдельный хост, на резервную площадку. Тут CommonClusterFeatureSet не поможет: «общий набор» считается по узлам вашего кластера и о чужом железе ничего не знает. Microsoft прямо указывает: для переноса из кластера с новыми процессорами в кластер со старыми надо ставить MinimumFeatureSet. Я ставлю его точечно, только тем машинам, которые реально путешествуют, а не всем подряд.

Ветка третья: живая миграция не нужна вовсе — одиночный хост, или окно обслуживания всегда есть. Выключаю совместимость совсем (-CompatibilityForMigrationEnabled $false) и отдаю ВМ полный набор возможностей физического процессора. Это, кстати, и рекомендация самой Microsoft: включать совместимость на время миграции, а потом гасить. На практике так почти никто не делает, потому что «а вдруг» — но если у вас узел один, включённая совместимость просто бесплатно отбирает у вас производительность.

• внутри кластера, живая миграция нужна → `CommonClusterFeatureSet`;
• миграция за пределы кластера, на более старые CPU → `MinimumFeatureSet`;
• живая миграция не нужна → совместимость выключить, ВМ получает полный набор хоста;
• разные производители CPU → никакой режим не поможет, планируйте холодный перенос.

Разбор из практики: проектное бюро «Отвес», 27 рабочих мест

Проектное бюро «Отвес», 27 рабочих мест: архитекторы и конструкторы в САПР, сметчики, бухгалтерия на 1С. Вся серверная часть два года жила на одном Dell PowerEdge R650 — Xeon Gold 6338 (Ice Lake-SP), 256 ГБ памяти, Windows Server 2025 Datacenter, общее хранилище по iSCSI. На нём 12 виртуальных машин: два хоста сеансов RDS, сервер 1С с MS SQL, файловый сервер с архивом проектов, сервер сетевых лицензий САПР, система хранения проектной документации, два контроллера домена, сервер резервного копирования и пара служебных машин.

Единственный хост — единственная точка отказа, и после одной неприятной ночи с зависшим контроллером RAID бюро решило сделать кластер. Покупать второй R650 не хотелось: в серверной стоял снятый с работы HPE ProLiant DL380 Gen9 — два Xeon E5-2680 v4 (Broadwell), 256 ГБ памяти, исправный. Его поставили вторым узлом, собрали кластер из двух узлов со свидетелем на файловом ресурсе, валидация прошла. И тут же поймали ровно то, с чего начинается статья: ни одна ВМ с R650 на Gen9 живьём не поехала, а значит, поставить R650 на обслуживание без остановки проектировщиков было нельзя.

Первое, что я проверил, — конфигурационные версии. Хост бюро изначально ставили на Windows Server 2019 и потом обновляли на месте, так что большая часть машин так и осталась на версии 9.0. То есть динамический режим для них был недоступен физически, независимо от того, что написано в настройках:

# что вообще поддерживает хост и какая версия по умолчанию
Get-VMHostSupportedVersion

# срез по всем ВМ кластера
Get-ClusterGroup | Where-Object GroupType -eq 'VirtualMachine' |
    ForEach-Object { Get-VM -ComputerName $_.OwnerNode -Name $_.Name } |
    Sort-Object Version | Format-Table Name, Version, State

# текущий режим совместимости
Get-VM RDS-03 | Get-VMProcessor |
    Format-List VMName, CompatibilityForMigrationEnabled, CompatibilityForMigrationMode

Картина оказалась такой: 8 ВМ на версии 9.0, 4 — на 10.0, ни одной на 11.0 или 12.0. У трёх машин галочка совместимости стояла (кто-то ставил её руками много лет назад), у остальных нет. Пока хост был один, это никого не беспокоило: мигрировать было некуда, и совместимость просто не требовалась.

Дальше — арифметика инструкций. Прогнал Coreinfo на обоих узлах и внутри пары ВМ. На R650 в выводе присутствовали AVX-512 (AVX-512-F, AVX-512-DQ, AVX-512-BW, AVX-512-VL), на Gen9 их, разумеется, не было, зато AVX2 был у обоих. Именно AVX-512 и был тем «processor-specific feature», из-за которого падала миграция: виртуалки, поднятые на Ice Lake без режима совместимости, получили его от хоста и утащили в гостевую ОС.

# на каждом узле и внутри ВМ
.\Coreinfo.exe -f -accepteula | Select-String 'AVX|SSE4|BMI|SHA'

План работ вышел на один вечер пятницы после ухода проектировщиков. Останов всех 12 ВМ по очереди, Update-VMVersion для 8 машин на версии 9.0 (перед этим — слить старые чекпойнты и убрать сохранённые состояния, чтобы не таскать за собой хвосты старого формата), затем массовое включение динамического режима. Двум машинам — лицензионному серверу и системе хранения документации, которые бюро периодически вживую переносит на отдельный резервный хост, — прописали MinimumFeatureSet персонально.

# выполняется на узле-владельце, ВМ уже выключены
$vms = Get-VM | Where-Object State -eq 'Off'

# 1) поднимаем конфигверсию (необратимо, чекпойнты слить заранее)
$vms | Where-Object { [version]$_.Version -lt [version]'10.0' } | Update-VMVersion -Force

# 2) все ВМ кластера — динамический режим
$vms | Set-VMProcessor -CompatibilityForMigrationEnabled $true `
                      -CompatibilityForMigrationMode CommonClusterFeatureSet

# 3) две «путешественницы» — фиксированный минимум
'LIC-01','PDM-01' | ForEach-Object {
    Set-VMProcessor -VMName $_ -CompatibilityForMigrationEnabled $true `
                    -CompatibilityForMigrationMode MinimumFeatureSet
}

Что получилось по факту. После рестарта Coreinfo внутри виртуалок показал ожидаемое: AVX2 на месте, AVX-512 пропал — динамический режим срезал ровно то, чего не было у Gen9. Живая миграция на второй узел заработала для всех 10 машин с CommonClusterFeatureSet. Самая тяжёлая регулярная задача бюро — ночная архивация проектного архива со сжатием плюс обслуживание базы 1С — занимала 38 минут до работ и 40 минут после, то есть потеря AVX-512 стоила около 5 % на этой конкретной нагрузке. Для сравнения, на тестовой копии той же ВМ с MinimumFeatureSet то же окно выросло до 47 минут. Вот вам цена «поставим минимум на всякий случай»: не проценты, а почти четверть времени.

Общее окно работ — 1 час 50 минут, из них около часа ушло на слияние чекпойнтов файлового сервера, которые годами копились после неудачных экспериментов с резервным копированием. Сама смена версии и режима на 12 машинах заняла минут пятнадцать. Бюро получило второй узел, на который можно разложить всю нагрузку (12 ВМ суммарно укладываются в 180 ГБ памяти), и возможность ставить любой узел на обслуживание в рабочий день, не выгоняя проектировщиков из сеансов.

• до работ: 12 ВМ, 8 из них на конфигверсии 9.0, живая миграция R650 → Gen9 невозможна ни для одной машины;
• после работ: все ВМ на 10.0, 10 машин в `CommonClusterFeatureSet`, 2 в `MinimumFeatureSet`, живая миграция в обе стороны работает;
• потеря набора инструкций: только AVX-512, AVX2 и AES-NI в гостевых ОС сохранились;
• цена в производительности: +5 % к ночному окну в динамическом режиме против +24 % в минимальном;
• простой: один вечер пятницы, 1 ч 50 мин, из них около часа — слияние старых чекпойнтов.

Порядок работ: что делать по шагам

Если вы сейчас стоите перед той же задачей — вот последовательность, которой я придерживаюсь. Она не быстрая, но зато не приходится потом ничего переделывать.

Сначала инвентаризация, до всяких изменений. Снимите конфигверсии всех ВМ, текущие режимы совместимости и наборы инструкций на каждом типе узлов через Coreinfo. Это пять минут работы, которые определят весь дальнейший план: если у вас все машины уже на 10.0+, ночная работа сведётся к одной команде; если половина на 8.0 — готовьте окно и снимайте чекпойнты.

Дальше — функциональный уровень кластера. Если кластер собирали из узлов, часть которых обновлялась с предыдущей версии Windows Server, проверьте, что уровень поднят: Microsoft прямо требует сначала обновить все узлы и функциональный уровень кластера и только потом конфигурационные версии ВМ. Проверяется одной строкой и поднимается тоже одной — но это тоже необратимый шаг, откатить узел на старую ОС после него не получится.

И только потом — переключение режимов и обязательная проверка результата. Проверять надо не «вроде мигрирует», а предварительной оценкой через Compare-VM: она вернёт список несовместимостей без реального переноса, что удобно, когда пробовать вживую страшно.

• снять инвентарь: `Get-VM * | ft Name, Version, State` и `Get-VMProcessor` по всем машинам;
• снять карту инструкций: `Coreinfo.exe -f` на каждом типе узлов, сохранить вывод в файл для сравнения «до/после»;
• поднять функциональный уровень: `Get-Cluster | fl ClusterFunctionalLevel`, затем `Update-ClusterFunctionalLevel`;
• снять чекпойнты и обновить конфигверсию на выключенных ВМ: `Update-VMVersion`;
• выставить режим: `CommonClusterFeatureSet` для внутрикластерных, `MinimumFeatureSet` для «путешественниц»;
• проверить сухим прогоном: `Compare-VM -Name 'RDS-03' -DestinationHost 'HV-02'` и посмотреть `.Incompatibilities`;
• прогнать живую миграцию каждой роли на новый узел: `Move-ClusterVirtualMachineRole -Name 'RDS-03' -Node HV-02 -MigrationType Live`;
• заново снять `Coreinfo.exe -f` внутри ВМ и сравнить с сохранённым выводом — это единственный способ увидеть, что реально получила гостевая ОС.

Где это ломается чаще всего

Грабли повторяются от клиента к клиенту, поэтому перечислю их списком — сэкономите себе вечер.

Отдельно про самую неочевидную из них — про пересчёт общего набора. Когда вы вводите в кластер узел со старым процессором, общий набор пересчитывается, но работающие виртуальные машины продолжают жить со старым, более широким набором, который они получили при последнем запуске. И на новый узел они по-прежнему не поедут. В документации это сформулировано так: новый вычисленный набор ВМ получает после перезапуска. То есть ввод «неродного» узла в кластер — это всегда окно на холодный перезапуск всех машин, а не «добавили и поехали». Планируйте это заранее, иначе получите ситуацию «узел в кластере есть, а разложить на него нечего».

И ещё одна вещь, о которой стоит знать заранее: увидеть вычисленный кластером общий набор возможностей штатными средствами нельзя. Ни PowerShell, ни GUI его не показывают — есть только косвенный метод через Coreinfo внутри ВМ. На форуме Microsoft Tech Community лежит подробная жалоба администратора крупной среды (400 блейдов, восемь типов процессоров) ровно на это: невозможно ни посмотреть общий уровень, ни зафиксировать его вручную по самому старому узлу, и наборы у ВМ меняются от перезапуска к перезапуску. Ответа от Microsoft под постом на момент написания нет. Так что в больших разнородных парках динамический режим пока приходится принимать как «чёрный ящик» — и это честный минус решения.

• **Старая конфигверсия.** ВМ переехала с Windows Server 2019, версия 8.0 или 9.0 — динамический режим недоступен, ВМ молча работает в стандартном минимальном наборе;
• **Забыли выключить ВМ.** Режим меняется только на остановленной машине, на работающей `Set-VMProcessor` вернёт ошибку — не пытайтесь «на живую»;
• **Правки через GUI поверх PowerShell.** Hyper-V Manager режим не показывает и не выбирает; после любой правки настроек процессора через GUI перепроверяйте `CompatibilityForMigrationMode` командой, а не глазами;
• **Не перезапустили ВМ после ввода узла.** Новый общий набор применяется только при следующем старте машины;
• **Смешали Intel и AMD.** Никакой режим совместимости этого не лечит — только холодный перенос;
• **Документация по cmdlet отстаёт.** В справочнике `Set-VMProcessor` для windowsserver2025-ps (проверял 14.09.2026) параметр `CompatibilityForMigrationMode` в блоке синтаксиса не описан, хотя в статье-инструкции он документирован и на хостах 2025 работает. Проверить наличие на своём хосте: `(Get-Command Set-VMProcessor).Parameters.Keys -contains 'CompatibilityForMigrationMode'`;
• **Ждут от совместимости чуда с производительностью.** Microsoft честно пишет, что оценить потери в общем виде невозможно: всё зависит от нагрузки. Шифрование, сжатие и интенсивная плавающая точка страдают сильнее всего, обычный офисный терминал — почти нет.

Приоритеты: на что забить, а что сделать обязательно

Обязательное — ровно два пункта. Первый: привести конфигурационные версии всех ВМ к 10.0 и выше, если хосты уже на Windows Server 2025. Без этого динамический режим для вас не существует, а вы будете думать, что он включён. Второй: перед вводом в кластер узла другого поколения снять карту инструкций через Coreinfo и заранее понимать, что именно потеряют виртуалки. Это делается за полчаса и снимает 90 % сюрпризов.

На что можно забить. Не гонитесь за версией 12.0, если вам не нужно разделение GPU — 10.0 достаточно для нашей задачи, а каждый шаг апгрейда необратим. Не переводите на MinimumFeatureSet весь кластер: это тот случай, когда «перестраховаться» стоит реальных процентов производительности на каждой ВМ и каждый день. Не пытайтесь измерить потери синтетическими тестами — меряйте своей нагрузкой, ночным обслуживанием SQL, выгрузкой из 1С, тем, что у вас действительно долгое.

И спокойно о рисках. Режим совместимости — не костыль и не что-то экзотическое: это штатный механизм, который живёт в Hyper-V со времён Windows Server 2008 R2 и в Windows Server 2025 просто стал умнее. Разнородный кластер с включённым динамическим режимом — совершенно нормальная эксплуатационная конфигурация, Microsoft отдельно оговаривает, что машины с совместимостью и без неё могут работать в одном кластере одновременно. Единственное, чего действительно нельзя, — мешать Intel и AMD. Всё остальное решается одной командой и одним окном на перезапуск.

• обязательно: конфигверсия всех ВМ 10.0+ на хостах Windows Server 2025 — иначе динамического режима нет;
• обязательно: карта инструкций Coreinfo на каждом типе узлов до ввода «неродного» сервера;
• обязательно: окно на холодный перезапуск всех ВМ после ввода узла и смены режима;
• можно не делать: апгрейд до 12.0 без планов на разделение GPU;
• не делать: `MinimumFeatureSet` для всего кластера «на всякий случай»;
• не делать: смешивать в одном кластере узлы на Intel и AMD.

Частые вопросы