FT will now support VMs with up to 4 x vCPUs and 64GB RAM. SMP-FT as it’s called works differently than FT for single CPUs. There is a new fast check-pointing mechanism to keep the primary and secondary in sync. Previously a “Record-Replay” sync mechanism was used but the new fast check-pointing has allowed FT to expand beyond 1 x vCPU. Record-Replay kept a secondary VM in “virtual lockstep” with the primary. With fast check-pointing the primary and secondary VM execute the same instruction stream simultaneously making it much faster. If the FT network latency is too high for VMs to stay in sync, the primary will be slowed down to the point that the secondary can keep up. You can also now hot-configure FT.
There are still some restrictions on the number of FT VMs you can have, you can have a maximum of 4 FT protected VMs or 8 FT protected vCPUs per host, whichever limit is reached first. The maximums include primary and secondary VMs. A 10Gb dedicated Nic is a requirement for SMP-FT, but you may be able to share bandwidth using NIOC with FT given priority. You cannot use hot-add for RAM or CPU with FT in vSphere 6.0.
With SMP-FT, two complete VMs are created. The secondary VM is a completely separate VM including storage for the first time and can now be on a different datastore from the primary.
This means FT can protect a VM against a host failure but also a datastore issue/failure as well with zero downtime. As a separate secondary VM is spun up, it will use additional I/O. You still need shared storage for the tiebreaker file but the .VMX and .VMDK files don’t even have to be on shared storage, they could be local disks. In previous vSphere versions you had to create your FT VMs with Eager Zero Thick disks, now with vSphere 6.0, all disk types are supported. Para Virtualisation Devices are also now supported.
vMotion is also supported for both primary and secondary VMs. DRS initial placement will choose where the VMs get placed on power on but DRS won’t balance FT VMs but can balance other non-FT VMs around. HA is FT aware and will take over functionality on the secondary if the primary host fails. If either the primary or secondary host fails, FT will automatically start creating another secondary VM. During a host reboot, a new secondary will be created automatically and started on another host.
Storage vMotion is not available for FT with multiple vCPUs and vCloud Director, vSphere Replication, VSAN/vVols and vFlash don’t support SMP-FT.
SMP-FT has made some improvement to backup such as VADP support and snapshots which weren’t available in 5.5.
There is a performance penalty of SMP-FT to the guest depending on workload, VMware say this could be between 10%-30%, Host CPU impact is minimal
Remember, though that FT doesn’t replace other clustering technologies such as Microsoft Cluster. It doesn’t protect against OS failures but operates at a hardware level which means it isn’t limited in guest OS support.