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 and C
check the same link above
Secondary VM on Overcommitted Host Degrades Performance of Primary VM
If a Primary VM appears to be executing slowly, even though its host is lightly loaded and retains idle CPU time, check the host where the Secondary VM is running to see if it is heavily loaded. A Secondary VM running on a host that is overcommitted for CPU resources might not get the same amount of CPU resources as the Primary VM. When this occurs, the Primary VM frequently must slow down to allow the Secondary VM to keep up, effectively reducing its execution speed to the slower speed of the Secondary VM.
Further evidence of this problem could be if the vLockstep Interval on the Primary VM’s Fault Tolerance panel is yellow or red. This means that the Secondary VM is running several seconds behind the Primary VM. In such cases, Fault Tolerance slows down the Primary VM. If the vLockstep Interval remains yellow or red for an extended period of time, this is a strong indication that the Secondary VM is not getting enough CPU resources to keep up with the Primary VM.
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. For guidance setting this reservation, view the performance graphs of the virtual machine (prior to Fault Tolerance being enabled) to see how much CPU resources it used under normal conditions.
12
5
If the Secondary VM is on an overcommitted host, you can move the VM to another location without resource contention problems:
– For FT networking contention, use vMotion technology to move the Secondary VM to a host with fewer FT VMs contending on the FT network. Verify that the quality of the storage access to the VM is not asymmetric.
– For storage contention problems, turn FT off and on again. When you recreate the Secondary VM, change its datastore to a location with less resource contention and better performance potential.
– To resolve a CPU resources problem, set an explicit CPU reservation for the Primary VM at an 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 VMs can execute at a specified rate.
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.troubleshooting.doc/GUID-C714CA33-13B9-41CE-A4BE-BFCA5C0C134E.html
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.
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.avail.doc/GUID-F5264795-11DA-4242-B774-8C3450997033.html
1
1
B and D is correct.
CPU reservation is not same as CPU Limit. So C is not correct.
6
0
B and C
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.troubleshooting.doc/GUID-C714CA33-13B9-41CE-A4BE-BFCA5C0C134E.html
D is also true but it is more adequate for resolving storage problems.
3
7
Answer c speaks of a CPU limit, where the documentation speaks of a explicit CPU reservation.
In my opinion that is something different.
Therefor B and D
12
0
I think so B and D.
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.troubleshooting.doc/GUID-C714CA33-13B9-41CE-A4BE-BFCA5C0C134E.html
7
0
Correct Answer seems to be B and D
If the Secondary VM is on an overcommitted host, you can move the VM to another location without resource contention problems. Or more specifically, do the following:
For FT networking contention, use vMotion technology to move the Secondary VM to a host with fewer FT VMs contending on the FT network. Verify that the quality of the storage access to the VM is not asymmetric.
For storage contention problems, turn FT off and on again. When you recreate the Secondary VM, change its datastore to a location with less resource contention and better performance potential.
To resolve a CPU resources problem, set an explicit CPU reservation for the Primary VM at an 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 VMs can execute at a specified rate. For guidance in setting this reservation, view the performance graphs of the virtual machine (before Fault Tolerance was enabled) to see how many CPU resources it used under normal conditions.
5
0
It does not make any sense to limit the CPU’s idem same to made Storage vMotion.
B&D are correct
5
0