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,D
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1013428
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-availability-guide.pdf p.45
3
0
B D
1
0
B,D
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.troubleshooting.doc/GUID-C714CA33-13B9-41CE-A4BE-BFCA5C0C134E.html
2
0
C,D!
See https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.troubleshooting.doc/GUID-C714CA33-13B9-41CE-A4BE-BFCA5C0C134E.html
– 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, ensu….
0
3
CPU Reservation differs from CPU limits.
1
0
B, D: https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.troubleshooting.doc/GUID-C714CA33-13B9-41CE-A4BE-BFCA5C0C134E.html
0
0
B and C
The question is about an over committed host which typically means CPU/Mem/Network. Even if you assume it means storage contention as well, if you change the datastore and remain on the same over committed host, the that wouldn’t fix the issue.
1
0
… Although… C specifies limit instead of reservation… could be a typo’d question?
1
0
Besides, part of that new 125Q VMware 2V0-622PSE dumps are available here:
https://drive.google.com/open?id=0B-ob6L_QjGLpaXhnQWQ4S2Ffc1k
Best Regards!
1
0
A Secondary VM running on a host that is overcommitted (for example, with its CPU resources) might not get the same amount of resources as the Primary VM. When this occurs, the Primary VM must slow down to allow the Secondary VM to keep up, effectively reducing its execution speed to the slower speed of the Secondary VM.
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.
1
0
In my opinion, all the answers are correct, but I choose B and C.
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.troubleshooting.doc/GUID-C714CA33-13B9-41CE-A4BE-BFCA5C0C134E.html
Why not D:
“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.”
You not “recreate” the Secondary VM on a different datastore… you recreate the VM and CHANGE the location of the datastore.
So, why not A than?!
“If the Secondary VM is on an overcommitted host, you can move the VM to another location without resource contention problems.”
The question: […] After further investigation, it is determined that the Secondary VM is on an overcommitted ESXi host.
Answer B: Use vMotion to migrate the Secondary VM to a different ESXi host.
We’re talking about the host… not a specifically storage problem.
0
0
B & D :
That is clear with the previously link given :
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.troubleshooting.doc/GUID-C714CA33-13B9-41CE-A4BE-BFCA5C0C134E.html
A : SvMotion is not supported with FT –> Wrong (https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-availability-guide.pdf)
B : vMotion, obviously right like resource problem without FT (and OK with FT from the troubleshooting link VMware)
C : This answer talk about LIMIT, and the troubleshooting VMware talk about RESERVATION. That is NOT the same thing, Reservation reserve resources on both VMs (primary and secondary), so that can correct the problem. But No relation with the Limit –> Wrong
D : This is clear for VMware : “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.”
3
0