Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I first setup a 2-node Hyper-V 2012 cluster, the failover was pretty much instant. I had a Sql Server 2012 (on Win2012) VM with 8GB RAM allocated to it. I could bounce the node it was living on, and it would jump to the other node without dropping my Sql connection.

Then I added a second VM to the cluster (clone of the first VM), also with 8GB. Now the failover takes a couple of seconds and my Sql connection resets. Is it a factor of the amount of RAM that has to be moved? Is it affected by the network? Is it the speed of the quorum disk?

In my case, both nodes are hooked to the same DAS and the VM files live on CSVs. I would expect that the disks are not a factor since nothing needs to be moved. It should all be RAM, right? So as RAM increases, failover performance decreases?

share|improve this question
up vote 4 down vote accepted

In retrospect, I guess I should've known. The answer is in two parts, because, in my mind, there's planned failover and "real"/unplanned failover---and planned failover doesn't count.

Planned failover

Planned failover is actually just the Clustering system draining the node, then rebooting it for you. So when you directly reboot the node via RDP or "Stop Cluster Service" in the Clustering app's GUI, the first thing that happens is the VMs get Live Migrated off. Because you're really just Live Migrating the VMs, the time it takes is dependent on what needs to be transfered, and the network connection. If you have a 1Gb NIC, it's going to take a while (~118MB/sec). The more RAM your VMs have, the better served you will be by faster NICs.

Real failover

Unplanned/"Real" failover is when you unplug the machine. In that case, the cluster system automatically starts the VM up on another node. The behavior to the outside world is the same as if you'd rebooted the VM. To the VM, it's the same as if you'd "turned it off" then started it again. So a "real" failover is always going to be about how long it takes your VMs to boot.


This is a let-down to me, conceptually, because I feel like all the clustering talk on the 'Net suggests that a ("hard") node failure is hidden by the clustering system---it's supposed to be like the services never went down. It's likely propagated by the fact that all the web pages I remember reading tested their cluster failover in software (planned failover). So all they're really doing is proving that Live Migration works as advertised (no downtime from the perspective of the client).

My main mistake was misunderstanding failover itself. In addition to the concept of having a hot/warm/cold backup server, where automatic failover occurs on a hot server, there is also hot/warm/cold failover. As mentioned here, hot failover is instant, warm failover is measured in seconds, and cold failover is measured in minutes. I was naive to assume that all automatic failure is "hot". I guess I was expecting some sort of magic with the RAM where the cluster would update a copy of the VM's RAM on another node---something like transaction log shipping with Sql Server. But that would require a communication channel between machines that is at least as fast as RAM to guarantee it would work.

share|improve this answer
AH, reality and common sense should have told you that. Seriously. Transparent failover means mirroring every change in memory - that is a LOT more than 118MB/s, memory bandwidth of a server is 25 to more than 50 GB / second. Want magic and fairy tales - do not go to IT ;) – TomTom May 24 '14 at 13:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.