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.
Facing issue in forming failover cluster
Hello all, i am facing issue in forming failover cluster getting below error Beginning to configure the cluster hyperv-clr12. Initializing Cluster hyperv-clr12. Validating cluster state on node revmaxsr7.revmax.co.in. Find a suitable domain controller for node revmaxsr7.revmax.co.in. Searching the domain for computer object 'hyperv-clr12'. Bind to domain controller \\revmaxsr8.revmax.co.in. Check whether the computer object hyperv-clr12 for node revmaxsr7.revmax.co.in exists in the domain. Domain controller \\revmaxsr8.revmax.co.in. Computer object for node revmaxsr7.revmax.co.in does not exist in the domain. Creating a new computer account (object) for 'hyperv-clr12' in the domain. Check whether the computer object revmaxsr7 for node revmaxsr7.revmax.co.in exists in the domain. Domain controller \\revmaxsr8.revmax.co.in. Creating computer object in organizational unit CN=Computers,DC=revmax,DC=co,DC=in where node revmaxsr7.revmax.co.in exists. Create computer object hyperv-clr12 on domain controller \\revmaxsr8.revmax.co.in in organizational unit CN=Computers,DC=revmax,DC=co,DC=in. Check whether the computer object hyperv-clr12 for node revmaxsr7.revmax.co.in exists in the domain. Domain controller \\revmaxsr8.revmax.co.in. Configuring computer object 'hyperv-clr12 in organizational unit CN=Computers,DC=revmax,DC=co,DC=in' as cluster name object. Get GUID of computer object with FQDN: CN=HYPERV-CLR12,CN=Computers,DC=revmax,DC=co,DC=in Validating installation of the Network FT Driver on node revmaxsr7.revmax.co.in. Validating installation of the Cluster Disk Driver on node revmaxsr7.revmax.co.in. Configuring Cluster Service on node revmaxsr7.revmax.co.in. Validating installation of the Network FT Driver on node REVMAXSR4.revmax.co.in. Validating installation of the Cluster Disk Driver on node REVMAXSR4.revmax.co.in. Configuring Cluster Service on node REVMAXSR4.revmax.co.in. Waiting for notification that Cluster service on node revmaxsr7.revmax.co.in has started. Forming cluster 'hyperv-clr12'. Unable to successfully cleanup. An error occurred while creating the cluster and the nodes will be cleaned up. Please wait... An error occurred while creating the cluster and the nodes will be cleaned up. Please wait... There was an error cleaning up the cluster nodes. Use Clear-ClusterNode to manually clean up the nodes. There was an error cleaning up the cluster nodes. Use Clear-ClusterNode to manually clean up the nodes. An error occurred while creating the cluster. An error occurred creating cluster 'hyperv-clr12'. This operation returned because the timeout period expired To troubleshoot cluster creation problems, run the Validate a Configuration wizard on the servers you want to cluster.Storage Replica on Failover Cluster as a means of storage replication on iSCSI
Hello, I have implemented a Failover Cluster / File Server (node1 and node2) on Server 2019 Datacenter. Shared storage is fulfilled by iSCSI (iSCSI1). Everything works well. Now, I have another iSCSI target on another physical storage system (iSCSI2) identical to iSCSI1. I want to enable SR so to replicate iSCSI1 with iSCSI2 so this happens through the Failover Cluster manager and it is the supported configuration for Stretched Clusters. My use case though is differnet. I only want to use the 2 nodes I have and I wish to use the Storage Replica as a means to make my two storage highly available. So if iSCSI1 goes down, FC will failover to isCSI2 storage. Is this a valid/supported scenario? Thank you
node server down failover cluster fail to move VM to other node
Dear Support, We have 4 nodes server forming the failover cluster. When I unplug two power cord of one of node, the VM on that node will become unmonitor state, and it failed to move those VMs to other host. and the node will become isolated. svr1: 2 VMs (mgtsvr1 (CPU x 8 and 24G Ram) , adsvr1 (CPU x 8 and 16G RAM)) svr2: 2 VMs (recsvr1 (CPU X14 and 16G Ram), failsvr2 (CPU X14 and 16G Ram)) svr3: 2 VMs (recsvr2 (CPU X14 and 16G Ram), failsvr1 (CPU X14 and 16G Ram)) svr4: 1 VMs (fmgtsvr1 (CPU x 8 and 24G Ram)) svr1 -4 server spec as follows; ram: 64G CPU: Xeon Gold 6134 3.20GHz x2 ROM: 600GB Please advisewindows 2016 failover 2 node cluster shared disk data issue
Description of the problem: Failover cluster in windows 2016 under simplivity has issue with the shared disk, for example anything written on "shared disk cluster" owned under node01 cannot be reflected on node02 while takenover by the node02. Engineer Response: " Looked into it thoroughly and tested all option to resolve the issue, looks to me now that HP cluster configuration itself have shared disk problem. HP need to see this issue, create any test file in cluster shared disk and write some files from node1 and then for test purpose node1 need to be switchover to node2 and see if the file written by node1 is visible through node2. "
