A vSphere Administrator observes that the Primary VM configured with Fault Tolerance is executing slowly.
After further investigation, it is determined that the Secondary VM is on an overcommitted ESXi host.
What two methods will correct the problem? (Choose two.)
A.
Use Storage vMotion to migrate the Secondary VM to another datastore.
B.
Use vMotion to migrate the Secondary VM to a different ESXi host.
C.
Configure a CPU limit on the Primary VM which will also apply to the Secondary VM.
D.
Turn off and turn on FT in order to recreate the Secondary VM on a different datastore.
Explanation:
https://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/
com.vmware.vsphere.availability.doc_40/c_ft_ts_perf.html
B & C are correct. From the explanation document URL itself: “To resolve this problem, set an explicit CPU reservation for the Primary VM at a MHz value sufficient to run its workload at the desired performance level. This reservation is applied to both the Primary and Secondary VMs ensuring that both are able to execute at a specified rate”
Eh, disregard, maybe not. Misread CPU limit as CPU reservation.
As datastore is not in focus I would say B and C are correct. The CPU limit would also cause against the overcommitment of the second esxi host of course.
the CPU/Memory Limit doesn’t reserve resources on the second host. host 2 would still be overcommitted.
I think there are 2 things VMware wants you to know about FT in this case.
1. a cpu/mem RESERVATION will apply to the primary and secondary VM
2. You cannot Storage vMotion a FT Machine.
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.avail.doc/GUID-F5264795-11DA-4242-B774-8C3450997033.html
“Storage vMotion. You cannot invoke Storage vMotion for virtual machines with Fault Tolerance turned on. To migrate the storage, you should temporarily turn off Fault Tolerance, and perform the storage vMotion action. When this is complete, you can turn Fault Tolerance back on.”
That would make D a wrong choise aswell, because you don’t have to re-create the secondary VM. Just disable FT –> storage vMotion –> enable it
setting a reservation on an allready overcommited host doesn’t sound like a solution either.
now you do need HA and shared storage. but the VMDK files do not need to be on shared storage:
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.avail.doc/GUID-83FE5A45-8260-436B-A603-B8CBD2A1A611.html
“Virtual machine files (except for the VMDK files) must be stored on shared storage. Acceptable shared storage solutions include Fibre Channel, (hardware and software) iSCSI, NFS, and NAS.”
so i would go for B and D
I contradicted myself actually.
disabling FT will remove the secondary VM. so you are simply re-creating the secondary VM.
https://www.youtube.com/watch?v=7lPf4OiMKug
https://4sysops.com/archives/vmware-vsphere-6-5-fault-tolerance-details-and-configuration/