Home > Default > Guest VM failover cluster on Hyper-V 2012 Cluster does not work across hosts

Guest VM failover cluster on Hyper-V 2012 Cluster does not work across hosts

November 30Hits:0
Advertisement
Hi all,
We are evaluating Hyper-V on Windows Server 2012, and I have bumped in to this problem:
I have a Exchange 2010SP2 DAG installed on 2 vms in our Hyper-V cluster (a DAG forms a failover cluster, but does not use any shared storage). As long as my vms are on the same host, all is good. However, if I live migrate or shutdown-->move-->start one
of the guest nodes on another pysical host, it loses connectivity with the cluster. "regular" network is fine across hosts, and I can ping/browse one guest node from the other. I have tried looking for guidance for Exchange on Hyper-V clusters but have not
been able to find anything.
According to the Exchange documentation this configuration is supported, so I guess I'm asking for any tips and pointers on where to troubleshoot this.
regards,
Trond

Answers

Hi All,
so some updates...
We have a ticket logged with Microsoft, more of a check box exercise to reassure the business we're doing the needful.  Anyway, they had us....
Apply hotfix http://support.microsoft.com/kb/2789968?wa=wsignin1.0  to both guest DAG nodes, which seems pretty random, but they wanted to update the TCP/IP stack...
There was no change in error, move guest to another Hyper-V node, and the failover cluster, well, fails with the following event ids I the node that fails...
1564 -File share witness resource 'xxxx)' failed to arbitrate for the file share 'xxx'. Please ensure that file share '\xxx' exists and is accessible by the cluster..
1069 - Cluster resource 'File Share Witness (xxxxx)' in clustered service or application 'Cluster Group' failed
1573 - Node xxxx  failed to form a cluster. This was because the witness was not accessible. Please ensure that the witness resource is online and available
The other node stays up, and the Exchange DB's mounted on that node stay up, the ones mounted on the way that fails failover to the remaining node...
So we then
Removed 3 x Nic's in one of the 4 x NIC teams, so, leaving a single NIC in the team (no change)
Removed one NIC from the LACP group on each Hyper-V host
Created new Virtual Switch using this simple trunk port NIC on each Hyper-V host
Moved the DAG nodes to this vSwitch
Failover cluster works as expected, guest VM's running on separate Hyper-V hosts, when on this vswitch with single NIC
So Microsoft were keen to close the call, as there scope was, I kid you not, to "consider this issue
resolved once we are able to find the cause of the above mentioned issue", which we have now done, as in, teaming is the cause... argh.
But after talking, they are now escalating internally.
The other thing we are doing, is building Server 2010 Guests, and installing Exchange 2010 SP3, to get a Exchange 2010 DAG running on Server 2010 and see if this has the same issue, as people indicate that this is perhaps not got the same problem.
Cheers
Ben
Name                   : Virtual Machine Network 1
Members                : {Ethernet, Ethernet 9, Ethernet 7, Ethernet 12}
TeamNics               : Virtual Machine Network 1
TeamingMode            : Lacp
LoadBalancingAlgorithm : HyperVPort
Status                 : Up
Name                   : Parent Partition
Members                : {Ethernet 8, Ethernet 6}
TeamNics               : Parent Partition
TeamingMode            : SwitchIndependent
LoadBalancingAlgorithm : TransportPorts
Status                 : Up
Name                   : Heartbeat
Members                : {Ethernet 3, Ethernet 11}
TeamNics               : Heartbeat
TeamingMode            : SwitchIndependent
LoadBalancingAlgorithm : TransportPorts
Status                 : Up
Name                   : Virtual Machine Network 2
Members                : {Ethernet 5, Ethernet 10, Ethernet 4}
TeamNics               : Virtual Machine Network 2
TeamingMode            : Lacp
LoadBalancingAlgorithm : HyperVPort
Status                 : Up
A Cloud Mechanic.

Read other 47 answers

Tags:

Related Articles

Copyright (C) 2019 wisumpire.com, All Rights Reserved. webmaster#wisumpire.com 14 q. 0.739 s.