Короткий ответ
Если VM-APP01 кластеризована, перенос — это Move-ClusterVirtualMachineRole, не обязательно тот же путь, что Move-VM. Сначала: роль существует, Possible Owners включает HV02, диски на C:\ClusterStorage\Volume1 (доступны цели), нет AntiAffinity/Preferred Owners, которые запрещают узел, CSV Online.
Если VM «просто Hyper-V» на локальном диске HV01, кластер её не двинет: либо сделайте clustered с общим хранилищем, либо shared-nothing Live Migration.
Симптомы и как отличить
Типичная картина:
- Failover Cluster Manager: Move не доходит, роль возвращается на
HV01; Get-ClusterGroup VM-APP01: OwnerNode не меняется;- на цели нет файлов VM;
- две VM с одним AntiAffinityClassNames не разъезжаются как вы хотели — или наоборот не съезжаются.
Отличия:
| Что видно | Куда |
|---|---|
| Роль едет, падает LM на памяти/Kerberos | Live Migration |
| CSV недоступен цели | CSV |
| Нет кворума | quorum |
| VM Off и не стартует нигде | старт |
Возможные причины
- VM не clustered (забыли Configure Role).
- Possible Owners только
HV01. - VHDX на
D:\Hyper-V\локально, не CSV/SMB. - AntiAffinityClassNames / Fault domains / Site.
- Целевой узел Drain, Pause, слишком мало RAM, нет идентичного vSwitch
CorpNet. - Зависимости роли (диск, NIC) не Online.
- Версия конфигурации / CPU — тогда это уже LM error, но выглядит как «не едет».
Диагностика
Get-ClusterGroup -Name 'VM-APP01' -ErrorAction SilentlyContinue | Format-List Name, State, OwnerNode, GroupType
Get-ClusterGroup | Where-Object GroupType -eq 'VirtualMachine' | Format-Table Name, State, OwnerNode
Get-ClusterOwnerNode -Group 'VM-APP01' | Format-Table ClusterObject, OwnerNodes
Get-ClusterResource | Where-Object OwnerGroup -eq 'VM-APP01' | Format-Table Name, ResourceType, State, OwnerNodeПути дисков:
Get-VMHardDiskDrive -VMName 'VM-APP01' | Format-Table Path
Get-ClusterSharedVolume | Format-Table Name, State, OwnerNode, FriendlyVolumeNameAntiAffinity:
Get-ClusterGroup -Name 'VM-APP01' | Select-Object Name, AntiAffinityClassNames
(Get-ClusterGroup -Name 'VM-APP01').AntiAffinityClassNamesПамять и drain:
Get-ClusterNode | Format-Table Name, State, DrainStatus, NodeWeight
Get-VMHost -ComputerName 'HV02.contoso.example' | Format-List MemoryCapacity
Get-VM -ComputerName 'HV02.contoso.example' | Measure-Object -Property MemoryAssigned -SumПопытка с подробным логом кластера после fail (сохраните, не публикуйте секреты):
Get-ClusterLog -Node HV01,HV02 -TimeSpan 15 -Destination C:\Temp\cluster-logsРешение
Сценарий A. VM не в кластере
Добавьте роль Virtual Machine в Failover Cluster Manager, диск должен быть на CSV/SMB. Не «Move-VM и надежда», если политика — HA.
Сценарий B. Possible Owners
В свойствах роли: оба HV01 и HV02. PowerShell:
Set-ClusterOwnerNode -Group 'VM-APP01' -Owners 'HV01','HV02'
Move-ClusterVirtualMachineRole -Name 'VM-APP01' -Node 'HV02'Preferred Owners — порядок, не жёсткий запрет; пустой Possible — вот запрет.
Сценарий C. Локальный путь диска
Перенесите хранилище на C:\ClusterStorage\Volume1 через Move VM Storage (окно IO). Пока Path на локальном диске, второй узел физически не откроет файл.
Сценарий D. AntiAffinity
Класс AppPair на двух VM мешает им быть на одном узле. Если вы хотите разъехаться — это правильно; если «не едет на единственный живой узел» при аварии — AntiAffinity может блокировать. В аварии снимите класс временно, задокументируйте.
(Get-ClusterGroup 'VM-APP01').AntiAffinityClassNames = @()Пустой массив — снятие. Верните после.
Сценарий E. Цель Pause/Drain/нет CorpNet
Resume-ClusterNode HV02. Создайте vSwitch с тем же именем. Освободите RAM.
Проверьте зависимости роли: Virtual Machine, Virtual Machine Configuration, иногда диск. Если Configuration Offline, compute не поедет. Get-ClusterResource | Where-Object OwnerGroup -eq 'VM-APP01'. Failed диск — сначала CSV, не Move.
Сеть кластера с ролью «Cluster and Client» vs «Cluster only» влияет на LM. Если вы запретили LM на единственной живой сети, Move будет Fail даже при зелёных Owners. Failover Cluster Manager → Networks → Live Migration settings: должна быть хотя бы одна сеть, маршрутизируемая между HV01 и HV02.
Get-VMHardDiskDrive Path обязан быть под C:\ClusterStorage\ или SMB Cluster Shared Volume / file share witness не путать с файловым SMB для VM (SOFS). Локальный C:\Users\...\VM-APP01.vhdx после «временно положили» — классика: на HV01 Running, Move невозможен физически.
Drain HV01 в тесте покажет правду: какие роли не уезжают. Не ждите пятничного патча, чтобы это обнаружить. После неудачного Move роль может остаться Partially Online — не Start-VM на втором узле, верните Online на исходном и разберите лог.
CPU compatibility и версия конфига проявятся уже как ошибка LM (21502), когда кластер разрешил перенос. Тогда идите в статью Live Migration, не крутите AntiAffinity.
Как проверить, что проблема устранена
Get-ClusterGroup -Name 'VM-APP01' | Format-List State, OwnerNode
Get-VM -Name 'VM-APP01' | Format-List ComputerName, State
Test-NetConnection -ComputerName 10.0.10.40 -Port 445OwnerNode HV02, State Online, гость отвечает. Обратный move на HV01. После Pause HV02 роль уезжает, не остаётся Failed.
Если не помогло
- Ошибка 21502: статья Live Migration (delegation/CPU).
- CSV redirected на цели: статья CSV.
- Replica — другой механизм, не HA move.
- BitLocker/CSV ключ не на цели — ключи кластера/KPS, не «ещё раз Move».
Профилактика
- Все прод-VM — clustered, диски только CSV/SMB.
- Имена vSwitch одинаковые.
- AntiAffinity только осознанно, с тестом «один узел жив».
- Регулярный drain-тест узла.
- Документ Possible Owners после добавления HV03.
FAQ
Move-VM vs Move-ClusterVirtualMachineRole?
Для clustered VM — cluster cmdlet. Move-VM может разъехаться с ролью.
Нужен ли одинаковый путь C:\ClusterStorage\Volume1?
Да, CSV монтируется в одно дерево имён. Не держите VM в Volume1 на одном узле и Volume2 «копии» файла.
Quick migration если Live нельзя?
Да, как временный обход с простоем Saved. Не как постоянная замена починки LM.
VM шаблон не кластеризуют?
Гостевые шаблоны на локальном SSD — норма. Прод-сервисы — нет.
Host grouping / site awareness в 2022+?
Смотрите Fault Domain / Site. Неправильный site может запретить перенос «в другой зал». Это feature, не баг — сверьте топологию.
Почему после добавления узла VM туда не едет?
Не добавили в Possible Owners, нет сети LM, нет switch, нет доступа к storage, или drain до конца настройки.