Os detalhes dependem de qual solução de virtualização exata você usa, mas a ideia é que você tenha um farm virtual, onde há vários hosts físicos com várias máquinas virtuais cada. Você então usa alguns da eficiência que você ganhou, não precisando de um host físico para cada VM, de modo que você tenha sobrecarga suficiente para cobrir, no caso de uma máquina física ficar inativa.
Além disso, você pode localizar os VHDs de cada VM em uma SAN comum (redundante). Os hipervisores em cada host físico podem ser configurados para falar uns com os outros e compartilhar memória de diferentes VMs. Existe alguma latência, e grande parte da memória será suportada pelo disco, mas se um dos hosts físicos ficar inativo, você nem está aguardando as VMs desse host para inicializar o backup. Em vez disso, essas VMs serão distribuídas automaticamente entre os hosts restantes. O objetivo final é que essas máquinas atinjam quase de onde pararam, com pouco ou nenhum tempo de inatividade. De certa forma, todas as suas VMs já estão sendo executadas em pelo menos dois hosts físicos. Na prática, os hipervisores agora só podem fazer esse tipo de migração uma máquina por vez, quando sabem que está chegando antes que o host falhe ... mas não se enganem: a migração instantânea na falha de hardware é a meta final para todos os principais hipervisores.
É por isso que você vê um servidor virtualizado em um único host físico em um farm. Você pode não ganhar nenhuma eficiência de hardware (você pode até mesmo perder algum desempenho), mas você compensa em termos de consistência de gerenciamento e alta disponibilidade integrada.