Share via


Cluster Name and IP Address resource will not come online

Question

Tuesday, September 7, 2010 7:53 PM

Last week we had a major failure with our failover cluster and I had to rebuild it from jump street.  Everything is back online and working again, except for the Cluster IP Address and the Cluster Name resource.  This resource fails on all 6 nodes with the following errors:

Cluster resource 'Cluster IP Address' in clustered service or application 'Cluster Group' failed.

and

Cluster resource 'Cluster Name' in clustered service or application 'Cluster Group' failed

When I try to start the resource I get the following error:

Error Code: 0x80071736 - The resource failed to come online due to the failure of one or more provider resources

and

Error Code: 0x80071397 - The operation failed because either the specified cluster node is no the owner of the resource, or the node is not a possible owner of the resource.

I am new to failover clustering and do not have much back ground with Windows at all other than what I have forced myself to learn in this environment.  I created this cluster and every part of it seems to work except for this resource.  Any help is appreciated.

All replies (6)

Tuesday, September 7, 2010 8:57 PM ✅Answered | 2 votes

the failover cluster service will manage that on all hosts, Just change the IP from the failover cluster console


Thursday, September 9, 2010 12:07 AM ✅Answered

Yes..All your VMs have to be in the same subnet


Tuesday, September 7, 2010 8:31 PM | 1 vote

I think this error due to permission problem, try to change cluster IP and name ( remove the DNS record before that)


Tuesday, September 7, 2010 8:37 PM

Does the IP address need to be bound to a specific server or to all servers or none?


Wednesday, September 8, 2010 3:18 PM

Sorry to keep asking what may be obvious questions, but do all the nodes in the cluster need to be on the same subnet?  I changed the IP and it is still not working.


Thursday, August 30, 2012 3:12 PM

For me, it turns out that the subnet in TCP/IP was wrong, or different between the two nodes.  Also, the cluster account needed permission to the computer node AD object.