Refer to the Exhibit.
Which change will eliminate the symptom in the performance chart shown in the exhibit?
A.
Set CPU shares to High
B.
Set CPU affinity for the virtual machine
C.
Migrate the VM to a host that is less utilized
D.
Add a CPU to the virtual machine
Can’t be C, there only one host. I think D.
I agree, I’d go with D.
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.
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.
I Can be A . which would avoid waittime which is due to contention.
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.
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?
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.
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.
IMHO
Check out a similar question:
http://www.aiotestking.com/vmware/2012/03/which-of-the-following-changes-would-eliminate-the-symptom-in-the-performance-chart-shown-in-the-exhibit-2/
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.
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.
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.
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.
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.
So I’d go for C.
Hello it’s me, I am also visiting this website on a regular basis, this website is in fact nice and the people are really sharing nice thoughts.|