Znacznie większa skala środowisk serwerów wirtualnych byłaby nie do opanowania bez wspomagających nas mechanizmów. Usterka maszyny fizycznej, hostującej kilkanaście systemów gościa będzie znacznie bardziej widoczna i trudniejsza do opanowania. VMWare zaproponował dwa rozwiązania uzupełniające i wspierające się wzajemnie, które z założenia miały całkowicie wyeliminować ryzyko awarii. W praktyce systemy HA i DRS pomagają, jednak należy zapoznać się z ich ograniczeniami i traktować raczej jako mechanizmy wspomagające, a nie zastępujące. Systemy ESX nie posiadają wiedzy nt. danych i połączeń logicznych między VM'ami. Tym samym bez dodatkowej konfiguracji możemy zastać sytuację, w której system z początku zaprojektowany i skonfigurowany z zachowaniem reguł High Avaliability, zostanie umieszczony w całości na jednym hypervisorze z klastra. VMWare HA dostępny do wersji ESX 3.5 U4, nie zareaguje w przypadku wystąpienia problemu dostępności LUN'a vmfs i dopóki sami ręcznie nie zatrzymamy  procesów VM'ów i nie przeniesiemy maszyn systemy będą niedostępne.

Dlatego warto ręcznie porozdzielać redundantne elementy systemów pomiędzy różnymi klastrami, macierzami lub LUN'ami, a  jeżeli jest to niemożliwe, niezbędnym minimum jest konfiguracja odpowiednich reguł rozdzielności  maszyn, którymi zarządza DRS.

Podobną sytuację zastaniemy w przypadku wystąpienia problemów sieci ethernetowej. Domyślnie każdy ESX monitoruje jedynie interfejs konsoli serwisowej (Service Console), która w 90% konfiguracji nie ma związku z linkami biorącymi udział w wymianie produkcyjnych danych. Jeżeli nie dysponujemy redundantnymi linkami i switchami, awaria sieci LAN może pozbawić nas np. komunikacji pomiędzy serwerami webowymi i bazami danych.

Mechanizm VMWare HA możemy dostroić w opcjach zaawansowanych parametrami das.failuredetectiontime, das.isolationaddress, das.usedefaultisolationaddress oraz das.poweroffonisolation – które ustawione poprawnie, na pewno zapewnią nam spokojniejszy sen.