Fault Tolerance archives - Virtualization Pro

Virtualization Pro:

Fault Tolerance

Sep 24 2009   9:34PM GMT

Master’s guide to VMware Fault Tolerance



Posted by: Eric Siebert
VMware, Fault Tolerance, High Availability

I’ve written about the vSphere’s new Fault Tolerance (FT) feature several times and wanted to put the information together in one blog, as well as include some new information. We’ve broken this guide into several sections as it’s a bit lengthy, so you can skim the witty titles and decide if a section for you, or if you’d rather keep on truckin’ to the next section. But first, if you’d like to check out my previous posts on FT, they are available here:

I. And VMware said, ‘Let there be Fault Tolerance’

Fault Tolerance was introduced as a new feature in vSphere that provided something that was missing in VMware Infrastructure 3 (VI3), the ability to have continuous availability for a virtual machine in case of a host failure. High Availability (HA) was a feature introduced in VI3 to protect against host failures, but it caused the VM to go down for a short period of time while it was restarted on another host. FT takes that to the next level and guarantees the VM stays operational during a host failure by keeping a secondary copy of it running on another host server. If a host fails, the secondary VM becomes the primary VM and a new secondary is created on another functional host. Continued »

Jun 25 2009   3:35PM GMT

More details on VMware’s Fault Tolerance feature



Posted by: Eric Siebert
Eric Siebert, VMware, vSphere, Fault Tolerance

This week’s VMTN Community Roundtable podcast was about Fault Tolerance (FT). Henry Robinson and Karen Ritter of VMware joined to provide information about the development and future of FT.

Here’s a summary of some interesting details from the podcast, but if you haven’t listened to it yet, I recommend that you check out the recording as it provides a lot of valuable technical information.

  • VMware spent a lot of time working with Intel/AMD to refine their physical processors so VMware could implement its vLockstep technology, which replicates non-deterministic transactions between the processors by reproducing the CPU instructions on the other processor. All data is synchronized so there is no loss of data or transactions between the two systems. In the event of a hardware failure you may have an IP packet retransmitted, but there is no interruption in service or data loss. Continued »


May 27 2009   4:06PM GMT

New SiteSurvey utility from VMware checks for Fault Tolerance compatibility



Posted by: Eric Siebert
Eric Siebert, VMware, vSphere, Fault Tolerance

While looking at the newly published VMware KnowledgeBase article on processor support for the new Fault Tolerance (FT) feature last week, I noticed a link to a new utility called SiteSurvey. While it wasn’t active at the time, this week SiteSurvey is available for download.

This utility specifically tests to see if the hosts in your clusters are compatible with the new Fault Tolerance feature. It is available as either a Windows or Linux download and once you install and run it, you will be prompted to connect to a vCenter Server.

Continued »


May 20 2009   5:13PM GMT

VMware Fault Tolerance: What it is and how it works



Posted by: Eric Siebert
Eric Siebert, Fault Tolerance, vSphere, VMware

Fault Tolerance (FT) is a new feature in vSphere that takes VMware’s High Availability technology to the next level by providing continuous protection for a virtual machine (VM) in case of a host failure. It is based on the Record and Replay technology that was introduced with VMware Workstation that lets you record a VM’s activity and later play it back.

The feature works by creating a secondary VM on another ESX host that shares the same virtual disk file as the primary VM and then transferring the CPU and virtual device inputs from the primary VM (record) to the secondary VM (replay) via a FT logging NIC so it is in sync with the primary and ready to take over in case of a failure. While both the primary and secondary VMs receive the same inputs, only the primary VM produces output such as disk writes and network transmits. The secondary VM’s output is suppressed by the hypervisor and is not on the network until it becomes a primary VM, so essentially both VMs function as a single VM.

Continued »