High Availability and Fault Tolerance. They solve the problem of keeping your virtual machines running when hardware fails, which happens more often than you think. For the VCP-DCV exam you must understand exactly how each works, when to use which, and the trade-offs in cost, performance, and complexity.
Jump to a section
A simple way to picture High Availability and Fault Tolerance
The Head Chef runs a busy restaurant kitchen during dinner service. Orders are coming in fast, every station is working, and the kitchen must keep food coming out no matter what. The Head Chef is the central manager of all cooking activity, much like a virtual machine (a VM) is the central application running your service.
If the Head Chef suddenly burns a hand and has to step away, the kitchen doesn't just stop cooking. The restaurant has an assistant sous chef standing by, already trained on the same recipes and holding the same ingredient stock. That backup sous chef immediately takes over the Head Chef's station without missing a step, so the diners never even notice a change. That instant takeover is Fault Tolerance — a complete copy of the virtual machine that takes over instantly with zero downtime when the primary VM fails, with no lost work.
Now imagine the same kitchen but with a different problem: the oven breaks. The Head Chef cannot cook the main course until the oven is repaired, but that takes thirty minutes. To solve this, the restaurant also has a policy: if any single piece of equipment fails, a spare oven in the back room automatically turns on and the kitchen switches to it. The diners wait a few extra minutes, but they still get their food. That is High Availability — restarting the virtual machine on another physical server when the original server fails, but with a short delay (downtime of a minute or two) while the system detects the failure and starts the backup. In Fault Tolerance the switch is instant and lossless; in High Availability you accept a brief hiccup to keep the service alive.
At the simplest level, a virtual machine (VM) is a computer that exists only as software, running on top of a physical server. If that physical server breaks, the VM stops working — just like a real computer when its motherboard dies. High Availability (HA) and Fault Tolerance (FT) are two different strategies that vSphere uses to stop that from happening.
High Availability is like having a rescue team standing by. When a physical server in your cluster fails, HA automatically restarts all the VMs that were running on that server on other healthy servers in the same cluster. The key point is that restarts are not instant. The system needs to detect the failure (usually within a few seconds) and then boot up the VM again on a new host. Because the VM has to go through its full boot process, you lose a minute or two of service. Any work that was in the VM's memory at the moment of failure is lost — HA does not preserve the state of your application, it just gets it running again from the last saved state (like from a disk or a snapshot).
Fault Tolerance is much more aggressive. It keeps a second copy of your VM running on another physical server at all times — this is called the secondary VM. The primary VM and the secondary VM are kept in perfect lockstep. Every single action the primary VM takes — every calculation, every memory write, every network packet sent — is instantly copied to the secondary VM. If the primary server fails, the secondary VM takes over immediately with zero downtime and zero data loss. The service keeps running as if nothing happened. Because FT duplicates everything, it requires a fast network connection between the two servers and can only protect VMs that have a single virtual CPU (vCPU). For multi-processor VMs you must use HA or other solutions.
Why does this matter for the VCP-DCV exam? The exam loves to test the distinction between availability and fault tolerance. You will see scenario questions like: "Your company runs a critical database that cannot lose a single transaction. Which feature should you enable?" The answer is Fault Tolerance. Then they might ask: "You have a web server that can tolerate a 5-minute outage. Which feature should you use?" That points to HA.
HA uses a concept called the master host and the isolation response. In a cluster running HA, one host is elected as the master. The master host monitors the heartbeat of all other hosts in the cluster. If it stops hearing heartbeats from a host, it declares that host as failed and triggers the restart process. If a host loses network connectivity but stays powered on, that is an isolation event. HA can be configured to either power off the isolated VMs (so they can restart elsewhere) or keep them running if the network comes back. The default is to power them off.
FT uses something called vLockstep technology. It logs every input and non-deterministic event (like random number generation or timing) on the primary VM and replays them on the secondary. This keeps the two VMs in exact agreement. FT also uses a dedicated VMkernel network connection for the logging traffic (FT logging). You must configure this network separately on each host that will host FT VMs.
Both HA and FT are configured on the cluster level in vSphere. For HA you enable it on the cluster and set parameters like admission control (do you reserve capacity for failover?) and the restart priority of VMs (which VMs restart first when a host fails). For FT you enable it per individual VM after HA is turned on. FT requires that the VM's virtual disk files are stored on shared storage that both hosts can access, like a SAN (Storage Area Network) or NAS (Network Attached Storage).
The cost trade-off is significant. HA costs almost nothing in performance overhead — you pay for the extra capacity in your cluster to host the restarted VMs, but there is no ongoing duplication. FT costs double the CPU and memory resources because two copies of the VM run at all times. You also need the fast network link. Therefore FT is reserved only for the most critical VMs that cannot tolerate any downtime at all.
Enable vSphere HA on the Cluster
Open vCenter Server, select your cluster, go to Configure > vSphere Availability, and turn on vSphere HA. This activates host monitoring, which will detect when a physical server in the cluster fails and automatically restart its VMs on other hosts. Without this step, no automatic restart happens.
Configure Admission Control
Admission control tells HA how much spare CPU and memory capacity to keep free across the cluster so that if a host fails, the remaining hosts have enough resources to restart all affected VMs. If you set it too low, the restart may fail because there is no capacity available. The exam tests three admission control policies: percentage of cluster resources, number of host failures to tolerate, and slot policy.
Set Restart Priority and Host Isolation Response
Define which VMs restart first (High, Medium, or Low priority) when a host fails. Critical VMs should get High priority so they come back online before web servers. Also choose what happens when a host loses network connectivity but stays powered on (isolation). The default is 'Power off VMs', but you can change it to 'Keep VMs running' if you prefer to wait for the network to return. This decision depends on your tolerance for split-brain scenarios.
Configure the FT Logging Network
For Fault Tolerance to work, you must create a dedicated VMkernel network adapter on each host that will run FT VMs. This network carries the vLockstep logging traffic between primary and secondary VMs. Use a separate physical NIC with at least 10 Gbps bandwidth and configure it on a different subnet from the management and vMotion networks. Without this step, FT will either not enable or perform poorly.
Enable Fault Tolerance on a Specific VM
Once HA is active and the FT logging network is ready, right-click the target VM and select Fault Tolerance > Turn On. vSphere checks the VM's eligibility (single vCPU, no snapshots, storage type support, etc.) and then creates a secondary VM on another host in the cluster. At this point the VM is fully protected — the secondary VM is live and synced. You can monitor both copies from the vSphere Web Client under the Fault Tolerance section.
Test and Monitor the Configuration
Put a host into maintenance mode to simulate a failure and observe that HA restarts the VMs or FT fails over seamlessly. Check the FT logging bandwidth usage using esxtop metrics like 'ftlogRx/s' and 'ftlogTx/s'. If you see high latency or packet drops, increase the network speed or move FT VMs to hosts with a faster link. Regular testing ensures the configuration works when a real failure occurs.
Let's walk through a realistic scenario at a medium-sized company called 'Acme Retail'. Acme runs a web store, a customer database, and a payment processing system on a vSphere cluster with three physical servers. The company's SLA (Service Level Agreement) says the web store can be down for up to 2 minutes per month, but the payment processing system must never go down.
Step 1: The IT administrator logs into vCenter Server. They create a new cluster called 'Production-Cluster' and add the three physical hosts. They right-click the cluster, select 'Settings', then 'vSphere Availability'. They check the box 'Turn On vSphere HA'. The cluster now has High Availability enabled.
Step 2: The admin configures admission control. This setting reserves capacity on the cluster so that if one host fails, the other two can accommodate all the restarted VMs. The admin sets it to 'Reserve 30% of cluster resources'. This means the cluster always keeps 30% of its CPU and memory free, unused, just in case a host fails. This is a direct exam topic — if you set admission control too low, VMs might not restart after a failure; if too high, you waste resources.
Step 3: The admin creates the payment processing VM with a single vCPU (because FT only works with one vCPU). The admin installs the application and makes sure the VM's virtual disk is stored on a SAN that all three hosts can see. Then, on the VM's properties, the admin turns on Fault Tolerance. The system creates a secondary copy on a different host. A heartbeat link is established.
Step 4: A week later, the physical server hosting the primary payment VM suffers a motherboard failure. The FT mechanism detects the loss of heartbeat within milliseconds. The secondary VM in another server instantly transitions to primary status. The payment service never pauses — customers see no error. The admin receives an alert from vCenter and schedules the repair of the faulty server.
Step 5: Meanwhile, the web store VM (which has 4 vCPUs and cannot use FT) is running on a different host. That host experiences a power supply failure. HA detects the host as dead after about 15 seconds because it stops sending heartbeats to the master host. The master marks all VMs from that host for restart. The web store VM is restarted on one of the remaining hosts. During this time, the site is down for about a minute and a half while the VM reboots and the application comes back online. The SLA is still met because the downtime was under 2 minutes.
What the admin practises daily: they monitor the HA heartbeat logs, test the FT logging network bandwidth, and periodically validate that the admission control settings still have enough headroom as new VMs are added. They also schedule regular tests where they manually put a host into maintenance mode to verify that HA restarts VMs correctly.
Tools used: vSphere Web Client (for configuration), esxtop (for performance monitoring of FT logging), and the HA status dashboard in vCenter that shows the health of all hosts and the number of protected VMs.
The VCP-DCV exam focuses on several specific patterns when testing High Availability and Fault Tolerance. You must know the exact configuration steps, the failure scenarios, and the traps they set.
Core exam topics:
HA architecture: the master host election process, host isolation detection, and the different isolation responses (power off VMs vs keep them running). They love to ask: if a host is isolated but still powered on, what is the default action? The answer is 'Power off the VMs'.
FT prerequisites: a VM must have no snapshots, must use a storage type that supports FT (like VMFS or NFS), must have only one vCPU, and must have the VMXNET3 network adapter. They will give you a scenario and ask which VM is eligible for FT.
FT logging network: you must configure a separate VMkernel port on each host for FT traffic, with a dedicated physical NIC and a high bandwidth link. They ask why FT performance is poor — the answer is almost always 'insufficient FT logging bandwidth'.
Admission control: three types — Cluster resource percentage, Host failover capacity (dedicate a host), and Slot policy. The exam expects you to know which type is best for which scenario. For example, if you have VMs of very different sizes, slot policy wastes space, so percentage is better.
Heartbeat datastores: HA uses heartbeat datastores to detect host failures when the network heartbeat is missing. If all datastores are lost, the host is considered isolated. Exam question: if a host loses network connectivity but still has datastore access, is it isolated? Answer: yes, it is still isolated because the network heartbeat is lost, unless you configure it otherwise.
Restart priority: the order VMs are restarted after a host failure. Highest priority VMs start first. They test the concept: if a host fails and two VMs have the same priority, which restarts first? The answer is non-deterministic — vSphere starts them in the order it processes them.
Host monitoring vs VM monitoring: HA has host-level monitoring (detects a crashed host) and VM monitoring (detects a frozen guest OS inside a VM). VM monitoring is for when the host is fine but the VM's guest OS stops responding. They enable this with a VM monitoring heartbeat and a reset period. Expect a question asking the difference.
Common traps:
They present a scenario where the FT VM has 2 vCPUs and ask why FT cannot be enabled. The trap is the vCPU limit. Many candidates forget the single-vCPU rule.
They claim that FT protects against storage failures. It does not — both primary and secondary VMs access the same datastore. A storage failure takes out both. HA and FT protect against host failures, not storage or network failures.
They give a scenario with a cluster of 2 hosts and ask to set admission control to tolerate 1 host failure. The trap: you cannot reserve 50% of resources because HA needs the remaining host to handle all VMs, which may require more than 50% if VMs are large. The correct answer is to dedicate one host for failover.
Key definitions to memorise: - 'Host failure' means the host is completely dead or unreachable (no network, no datastore heartbeats). - 'Host isolation' means the host is still running but loses network connectivity to the rest of the cluster. It can still access storage. - 'FT logging' is the continuous stream of data from primary to secondary VM. - 'vLockstep' is the technology that keeps primary and secondary VMs synchronised. - 'Secondary VM' is the live copy that takes over if the primary fails.
High Availability restarts VMs on surviving hosts after a failure, losing any data in memory and causing a short outage during the VM boot process.
Fault Tolerance keeps a live secondary copy of a VM on a different host, providing zero downtime and zero data loss, but only works for single-vCPU VMs.
FT requires a dedicated and fast FT logging network to keep the primary and secondary VMs synchronised at all times.
HA uses a master host to monitor the heartbeat of other hosts, and if a host is isolated but still powered on, HA will power off its VMs by default.
Admission control reserves resources in a cluster to ensure VMs have enough capacity to restart after a host failure.
Neither HA nor FT protects against storage failures or network infrastructure failures — they only cover host hardware failures.
You cannot enable FT on a VM that has snapshots, uses an IDE disk, or has more than one vCPU.
VM monitoring (within HA) detects when a guest operating system inside a VM freezes, and restarts the VM independently of the host's health.
These come up on the exam all the time. Here's how to tell them apart.
vSphere High Availability (HA)
Restarts VMs after a host failure from disk, causing a brief outage.
Loses all data that was in the VM's memory at the time of failure.
Works with VMs of any vCPU count.
vSphere Fault Tolerance (FT)
Keeps a live secondary VM that takes over instantly with zero downtime.
Preserves all in-memory data, no data loss on failure.
Only works with VMs that have exactly one vCPU.
Admission Control (Percentage)
Reserves a percentage of total cluster CPU and memory for failover.
Works well when VMs are of similar size or when you know the exact resource usage.
Simpler to manage and adapts as VMs are added or removed.
Admission Control (Slot Policy)
Reserves enough resources to host a fixed number of VMs based on the largest VM in the cluster.
Wastes resources if VMs are very different sizes because slots are based on the largest VM.
Best used when all VMs are identical in resource requirements.
Host Monitoring (HA)
Monitors the physical host's heartbeat (network and datastore).
Detects a complete host failure or a host that has become unreachable.
Restarts all VMs from that host on healthy hosts.
VM Monitoring (HA)
Monitors the heartbeat inside the guest operating system of a VM.
Detects when a VM's OS has frozen or become unresponsive (even if the host is fine).
Restarts only that individual VM without affecting other VMs on the same host.
FT Logging Network
Carries the vLockstep log of VM operations from primary to secondary.
Requires extremely low latency and high bandwidth (minimum 10 Gbps).
Must be on a different subnet from management and vMotion.
vMotion Network
Carries the memory state of a VM during a live migration to another host.
Tolerates higher latency and lower bandwidth (1 Gbps is often sufficient).
Can share the same physical NIC with management in many configurations.
Mistake
High Availability and Fault Tolerance do the same thing, just with different names.
Correct
HA restarts VMs after a failure with some downtime and data loss. FT keeps a live secondary copy with zero downtime and zero data loss. They solve different problems for different criticality levels.
Both terms start with 'high' and 'fault' and both involve keeping VMs running, so beginners conflate them. The exam deliberately tests the precise difference.
Mistake
Fault Tolerance protects against all types of failure, including storage and network failures.
Correct
FT only protects against host failures (the physical server crashing). Both primary and secondary VMs share the same virtual disk on the same shared storage. If the storage array fails, both copies are lost. FT also does not help if the network switch goes down.
The word 'fault' sounds all-encompassing. Beginners assume it means any fault, but vSphere FT is narrow — it only handles the failure of the host hardware.
Mistake
You can enable FT on any VM regardless of size, as long as HA is turned on.
Correct
FT has strict requirements: the VM must have exactly one vCPU (virtual CPU), no snapshots, no USB devices, and must use VMXNET3 network adapters. It also requires a separate FT logging network and shared storage.
Many beginners think FT is just a checkbox. They do not realise the licensing and hardware restrictions, especially the vCPU limit, which is a frequent exam trap.
Mistake
When a host fails and HA restarts VMs, the VMs resume exactly where they left off, without losing any data.
Correct
HA restarts VMs from the disk. Any data that was in the VM's memory (RAM) at the moment of failure is lost. This includes unsaved work in applications, temporary calculations, and network connections. HA only provides process-level restart, not state preservation.
People think 'restart' means 'resume' because of how we use the word in everyday language. In IT, a restart usually means starting from scratch, not continuing.
Mistake
Enabling FT doubles the storage cost because you need two copies of the virtual disk.
Correct
FT does not duplicate the virtual disk. Both primary and secondary VMs access the same virtual disk file on the same shared datastore. The duplication is only in memory (RAM) and CPU processing. Storage cost remains the same for the VM.
It seems logical that a secondary copy would mean double storage, but vSphere FT uses shared storage and only replicates the in-memory state. Beginners often overestimate the storage impact.
Mistake
HA always restarts all VMs exactly in the order they were configured with restart priority.
Correct
HA respects restart priority (highest first), but inside the same priority level the order is not deterministic. vSphere starts them in the order it processes the list, which can change between outages. You cannot predict the exact sequence within the same priority tier.
Administrators expect strict ordering because they configured a priority. The exam tests that you understand the behaviour is non-deterministic within the same priority level.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. vSphere Fault Tolerance only works with VMs that have exactly one virtual CPU (1 vCPU). If your VM needs more than one vCPU, you cannot use FT — you must use High Availability instead, which will restart the VM after a failure with some downtime.
High Availability restarts a VM on another host after a failure, causing a short outage (usually 1-3 minutes) and losing any data in memory. Fault Tolerance keeps a second copy of the VM running in lockstep on another host, so if the primary fails, the secondary takes over instantly with zero downtime and zero data loss.
Yes. Both the primary and secondary VMs in Fault Tolerance must access the same virtual disk files on a shared datastore (like VMFS on a SAN or NFS). The FT architecture does not replicate the disk — only the memory and CPU state. If the shared storage fails, both copies are lost.
Host isolation occurs when a physical server in a vSphere cluster loses all network connectivity to the other hosts but remains powered on and still has access to the shared storage. The default HA isolation response is to power off all VMs on the isolated host so they can be restarted on other hosts. You can change this to keep them running if you prefer.
The FT logging network is a separate VMkernel port used exclusively to copy the execution state from the primary VM to the secondary VM. It carries vLockstep data and requires a high-bandwidth, low-latency dedicated link (at least 10 Gbps). Without it, Fault Tolerance cannot maintain synchronisation, and performance will be poor.
No. You cannot take snapshots of a Fault Tolerance-protected VM. If you need a snapshot, you must first turn off FT, take the snapshot, and then re-enable FT. This is a strict limitation that the exam likes to test.
You've finished High Availability and Fault Tolerance. Continue through the VCP-DCV study guide to build a complete picture of the exam.
Done with this chapter?