While using VMware vSphere, you may encounter a situation where you cannot edit the memory resource settings (shares, reservations, and limits) for a particular VM on the resources tab. The memory resource settings section will be completely grayed out. In addition, a label will clearly state “Memory resources-cannot edit” as shown below:

In this particular instance, the underlying cause for this condition is VMware Fault Tolerance (FT) has been enabled on the FT “primary” VM. The fact that the memory resource settings cannot be modified is by design and is used as a means to help guarantee the FT “secondary” VM stays in vLockstep with the primary. What has actually happened is that when FT was enabled on the VM, a memory reservation was set equal to the amount of memory configured for the VM. This eliminates VMkernel swap file for the VM managed by the host in all cases, not just for FT enabled VMs.

What other subtle changes can you expect when you enable VMware Fault Tolerance (FT) on a VM?

DRS will be disabled for the FT enabled primary VM, although it may be VMotioned manually in cases where maintenance needs to be performed on the ESX(i) host. FT secondaries may also be migrated by right clicking on the FT primary VM and choosing the Fault Tolerance menu item to “Migrate Secondary”:

Thin provisioned disks will be converted to a Thick type:

A FT “secondary” VM will be created on another host in the cluster which will consume CPU and memory on the secondary host. It will share VM storage with the FT “primary”. VM networking is disabled on the FT “secondary” to eliminate the obvious problem of a duplicate machine on the network, however, other considerable host based network traffic will be consumed for two purposes:

1. Initial creation of the FT “secondary” – dedicated VMotion network is used
2. Continuous FT logging traffic – dedicated FT logging network is used

If hardware MMU feature exists in the host CPUs (AMD RVI/Intel EPT), the feature is disabled in the VM. This will force a power off of the VM before FT can be enabled.

Storage vMotion will be disabled for the FT enabled VM.

The hypervisor may slow down execution of the FT “primary” VM if the FT “secondary” is not able to keep pace with the FT “primary” using vLockstep technology.

Snapshotting functionality will be disabled. Furthermore and maybe more importantly, backups requiring snapshot technology won’t work.

Virtual hardware that is not compatible with FT will be disabled (ie. USB, Sound, etc.)

vSMP (multiple CPUs) in the VM is not supported. FT can’t be enabled.

Physical RDMs in the VM are not supported. FT can’t be enabled.

For more information on VMware Fault Tolerance, see VMware vSphere™ 4 Fault Tolerance: Architecture and Performance, VMware vSphere Availability Guide, and Xtravirt’s Disaster Recovery and VMware vSphere 4.0 Fault Tolerance whitepaper,

• Previous Entry: Thank you Gabe and Brenda
• Next Entry: Lab Manager 4 and vDS