Do poprawnej pracy klastra failover potrzebujemy wspólnej przestrzeni dyskowej, którą konfigurujemy włączając opcję Cluster Shared Volumes (CSV). Jest to funkcjonalność dodana w ramach usług klastrowania serwerów, dzięki której można mieć zasób dyskowy dostępny w tym samym czasie na wszystkich węzłach, ale tylko jeden z nich jest właścicielem woluminu.

Efektem włączenia CSV jest widoczny na dysku systemowym każdego węzła folder c:\ClusterStorage\VolumeX (gdzie X jest kolejna cyfrą począwszy od 1 w zależności ile woluminów przypiszemy do usługi CSV).

Aby zapobiec konfliktom, jeden z węzłów pełni specjalną rolę, nazywaną Koordynatorem. Podstawą działania CSV jest mechanizm filtra CSV (CSV File System Filter). Bazując na aktualnej dostępności i wydajności połączeń SAN/LAN wybiera on najbardziej efektywną drogę dostępu do woluminu (bezpośrednio - direct I/O lub poprzez sieć - redirect I/O). Oznacza to iż jeśli jeden z węzłów straci połączenie z zasobami dyskowymi, ale połączenie LAN z Koordynatorem działa, to nadal ów wolumin będzie dostępny.

W najprostszym wariancie konfiguracyjnym dla dwóch węzłów wystarczą dwa woluminy utworzone na macierzy, ale należy je wystawić dla serwerów dopiero po utworzeniu z nich klastra. Jeden jest wtedy przeznaczony na pliki maszyn wirtualnych, a drugi służy jako "świadek" do obsługi funkcji failover. Świadek to wolumin, który jest widziany przez wszystkie węzły, a jego rolą jest przechowywanie bazy konfiguracji klastra.

Podczas konfiguracji funkcji failover, przy wskazaniu dysku świadka system sam zaproponuje odpowiednią konfigurację niezawodnościową ze względu na liczbę węzłów. Przy parzystej liczbie (załóżmy prostą konfigurację 2 węzłów) będzie to "Node and Disk Majority", co oznacza to, że zarówno węzły jak i dysk "świadek" będą dysponować kopią konfiguracji klastra.

Każdy host, który jest członkiem klastra powinien mieć analogicznie skonfigurowane wirtualne sieci. W przeciwnym razie może wystąpić problem z komunikacją sieciową w przypadku, gdy skorzystamy z migracji maszyny wirtualnej. Tak samo będzie w przypadku, gdy maszyna zmieni węzeł w przypadku uruchomienia się procesu failover. Zakładając, że mamy przynajmniej dwa interfejsy sieciowe na węzeł do obsługi klastra, oprócz określenia na nich adresacji IP, musimy wskazać, interfejs przeznaczony do komunikacji wewnętrznej oraz podłączony do wirtualnego switcha przeznaczony dla maszyn wirtualnych, Oczywiście można użyć do tego pojedynczego interfejsu, jednak dobra praktyka mówi, żeby rozdzielić te funkcje.

Gdy wszystkie niezbędne opcje zostaną ustawione, warto wykonać walidację konfiguracji klastra. Wynik pokaże, czy został on poprawnie skonfigurowany, a w przeciwnym razie zostaniemy poinformowani, który obszar konfiguracyjny należy skorygować i jakie są możliwe przyczyny nieprawidłowego działania.

Aby wykorzystać pełną funkcjonalność klastra niezawodnościowego, oprócz samego utworzenia maszyny wirtualnej należy skonfigurować ją jako serwis o wysokiej dostępności. W tym celu trzeba użyć kreatora serwisu i aplikacji w menadżerze klastra i wskazać wcześniej utworzoną maszynę wirtualną dla której chcemy zapewnić obsługę failover. Aby uzyskać wysoką dostępność, pliki konfiguracyjne oraz dyski wirtualnej maszyny muszą znaleźć się na przestrzeni dyskowej skonfigurowanej jako CSV.

Zachowanie wirtualnego systemu podczas awarii można ustawić we właściwościach. Określić należy hierarchię preferowanych węzłów, czas po którym ma zadziałać procedura failover, automatyczny start systemu oraz możliwość powrotu do preferowanego hosta..

Po skonfigurowaniu klastra oraz utworzeniu wirtualnej maszyny można przeprowadzić testy niezawodnościowe. Korzystając z opcji menedżera możemy zasymulować awarię wyłączając usługę klastrowania na jednym z węzłów (Stop Cluster Service) sprawdzając przy tym zachowanie maszyn wirtualnych w zakresie automatycznej migracji. Niestety, Hyper-V Server 2008 R2 nie umożliwia monitorowania interfejsów sieciowych, więc gdy punktem awarii będzie interfejs sieciowy bądź kabel obsługujący dana maszynę wirtualną, to utraci ona połączenie, ale mechanizm failover nie zadziała. Jest to o tyle kłopotliwe, że aktualna wersja Hyper-V Server nie wspiera również teamingu kart sieciowych na poziomie systemu, więc nie jesteśmy w stanie zapewnić redundancji połączeń sieciowych.