Which change will eliminate the symptom in the performance chart shown in the exhibit?

Refer to the Exhibit.

Which change will eliminate the symptom in the performance chart shown in the exhibit?

Set CPU shares to High

Set CPU affinity for the virtual machine

Migrate the VM to a host that is less utilized

Add a CPU to the virtual machine

17 Comments on “Which change will eliminate the symptom in the performance chart shown in the exhibit?

  1. Rick says:

    Why would you add another CPU when it has trouble scheduling just 1 CPU? If 2 CPUs are configured then the VM has to wait until both CPUs are ready which in this case would take even longer. The answer is C. There could be more hosts available. The exhibit shows them logged directly to the host not vCenter.

  2. Rick2 says:

    I agree with the first Rick – but based on the screenshot you almost have to assume there is only one host. But option D will only make the problem worse. This is an awful question, any answer could be wrong. it is definitely not a or b.

  3. Rafael says:

    Giving it more shares would only give it more priority. But the CPU is already strugling on the host itself – that won’t help. C for me.

  4. rjoseph says:

    I’m confused.

    The chart shows that % ready is going high. Which means that the CPU is waiting a while to run a process.

    Wouldn’t setting the “CPU share” to High (answer A) give this VM a higher priority and decrease the wait time?

    1. Hans says:

      I agree rjoseph, we dont know if the CPU of the host is struggling or the VM has too few shares that is causing the CPU Ready problems. It’s got to be A.

  5. rjoseph says:

    Adding a CPU sounds really dumb, unless I’m understanding the issue incorrectly. You can add10 more CPU and the system would still have a high Ready number if it can’t schedule these CPU to run a process.


  6. PC says:

    Again this is a case of having to read the VCP questions very very carefully…

    Setting a CPU affinity will not help so its not that. Adding a CPU means the VM will need to wait even longer for the number of CPUs it requires to become available so that would just make it worse.

    That leaves shares and moving it to a less utilised host.

    Shares would help. They would effectively push the VM nearer the front of the queue so the wait would be shorter. Read the question again… note the word “eliminate”. Shares will probably help but not eliminate the problem.

    Now that leaves moving the VM to another host. However in this case there is no indication that there is no contention on the other host either, only that it is less utilised. So there is no guarantee that you would eliminate the symptom by doing this either.

  7. RM says:

    There’s no evidence that another host even exists. This client is pointed directly at a host, not vCenter.

    If this VM is having trouble scheduling one core, adding a second will just make it worse.

  8. Rich says:

    Though I doubt the validity of this question, A makes the most sense…except that it doesn’t guarantee that it will fix the problem.

    B & D are definitely incorrect.

    C is based on the whopping assumption that there are other hosts. I’m sure that there are a lot of single host vSphere implementations out there, so this assumption is unreasonable.

    Even though A is the best answer, I’d bet that VMWare is looking for C.

  9. Mike says:

    BAsed on the tricky question this will be… D: PLEASE I SAY THAT BASED ON THE ONE HOST. No way to move the affected VM. Also I saw this in the exam.

  10. Bart says:

    Five Ways to Fix CPU Ready Issues
    How do you fix your CPU Ready issues when you find them? Here are 5 ways to get CPU Ready resolved quickly (listed in order or importance):
    1. Proper sizing of virtual machines and hosts – Ensure that virtual machines aren’t significantly oversub-scribing the pCPU of your ESXi hosts with too many vCPUs. Additionally, if hosts are truly reaching their limits in terms of pCPU usage then consider adding additional pCPUs to the hosts or adding additional hosts to your cluster.
    2. Don’t use CPU limits – Limits cause CPU Ready issues and should only be used for short-term testing or troubleshooting.
    3. Don’t use CPU affinity rules – CPU affinity rules can cause CPU Ready issues and, like limits, should only be used for short term testing or troubleshooting.
    4. Use best practices with Fault Tolerance (FT) – Ensure that your FT implementation has its own FT net-work to communicate changes and isn’t congested so as not to prevent CPU Ready issues.
    5. Understand what DRS does and doesn’t do – DRS doesn’t help with CPU Ready and so ensure that DRS doesn’t actually cause CPU Ready issues.

Leave a Reply

Your email address will not be published. Required fields are marked *