Forum Discussion
Windows Server 2025 Failover Cluster Live Migration Issue
Hi Everyone,
I am facing an issue in a Hyper-V Failover Cluster environment where Live Migration intermittently fails due to a service logon-related problem. The environment was previously working normally, but now whenever we attempt to Live Migrate a VM between cluster nodes, the migration fails unless we manually run “gpupdate /force” on the Hyper-V host first.
After running gpupdate /force, the migration works temporarily, but the issue returns again during the next migration attempt. This makes it appear that some policy or permission is not being applied consistently on the cluster nodes.
During troubleshooting, I attempted to add “NT VIRTUAL MACHINE\Virtual Machines” to the “Log on as a service” policy under Local Security Policy > Local Policies > User Rights Assignment. However, the account does not appear or resolve in the Object Picker when trying to add it manually.
At this stage, I am trying to understand whether this is related to a domain GPO overwriting local policy settings, a Failover Cluster permission issue, or something specific to Hyper-V virtual machine accounts.
Has anyone encountered a similar issue where Live Migration only works after running gpupdate /force? Also, is there a correct method to add “NT VIRTUAL MACHINE\Virtual Machines” to the “Log on as a service” policy, or should this permission already exist by default on Hyper-V hosts?
Any guidance or recommendations would be greatly appreciated.
1 Reply
Hi, I’d start with the cluster validation report and the event logs on both the source and destination node at the exact migration time. Live Migration problems usually come down to network selection, authentication, constrained delegation, CPU compatibility, VM configuration version, or storage/CSV access. Also confirm both hosts are at the same patch level and have matching processor compatibility settings if the CPUs are not identical. If this is a new Windows Server 2025 cluster, I’d test with a small clean VM first. If that works, the issue is probably VM-specific; if it fails too, focus on cluster networking and authentication.
