Refer to the Exhibit.
Users are having difficulty accessing a web server since a new web application was configured in a virtual machine running on sc-titanrum03.vmeduw.com.
The vSphere Client reports the error shown in the Exhibit. DRS is set to fully automated mode, but the problem has not resolved.
Which action can resolve the issue?
A.
Hot-add a CPU to the the web server virtual machine.
B.
Add an ESXi host to the cluster
C.
vMotion one or more running virtual machines on the ESXi host running the web server virtual machine to the other ESxi host in the cluster.
D.
Power off one or more virtual machine on the ESXi host running on the Web server virtual machine and migrate them to the other ESXi host in the cluster.
Explanation:
1. DRS isn’t moving
2. Host has CPU issue.I first thought C would be the best option. However, if DRS isn’t moving anything then it doesn’t see that there would be enough of a performance gain. If you add another CPU it would help the VM. I wanted to note my observations:
1. 1 VM is experiencing the issue so there really isn’t CPU contention on the host
2. DRS doesn’t see any gains so how would moving help anything? So maybe adding that additional CPU would allow for a better DRS recommendation/move. meaning it would balance the cluster out.
3. An alarm doesn’t = bad just that it may be under load.
But is is the the Host with the CPU issue in the picture?
0
0
C is correct answer. Picture shows host server on high cpu utilization.
0
0
Going back reading again, D is the CORRECt answer.
A – adding CPU to VM does not solve Host CPU issue.
B – Yeah but DRS still doesn’t work due to high CPU on problem host
C – vMotion doesn’t work due to high CPU on problem host
D – power down vm on problem host and migrate to another host – CORRECT.
0
0
I conquer with you David. Additional support against answer A is that you cannot ‘hot’ add a vCPU to a VM. You must power down the VM, increase CPU count, then power on VM… DRS will not migrate VMs properly from one host to another if there are not enough CPU and Memory resources available on the host that needs to be offloaded…
The reasoning given in the explanation displays poor reasoning…
0
0
answer should be B:
it is a issue with the Host.
A: Adding vCPU to the VM will place more burden on the host.
B: adding a Host to the cluster will alleviate the burden on the host with high CPU usage.
C: DRS is enabled and fully automated so why need to manually vMotion the VM? DRS is not moving the VM because all hosts in cluster is overutilized. adding a new host will fix this
.
D:Powering down the VM to move to host in DRS cluster may allto move it but once powered on the DRS cluster will be over utilized.
0
0
why is this question being revisited? The original posted answer should be B.
it is a issue with the Host.
A: Adding vCPU to the VM will place more burden on the host.
B: adding a Host to the cluster will alleviate the burden on the host with high CPU usage.
C: DRS is enabled and fully automated so why need to manually vMotion the VM? DRS is not moving the VM because all hosts in cluster is overutilized. adding a new host will fix this
.
D:Powering down the VM to move to host in DRS cluster may allto move it but once powered on the DRS cluster will be over utilized.
0
0
Hey
IMHO, the answer should be D.
A – Hot adding a vCPU will only increase CPU utilisation on the host that the VM is on (the one already alerting for high CPU usage)
B – Adding a host to the cluster won’t achieve anything on it’s own as DRS is already not migrating guests to the lesser used host. If the reason DRS wasnt migrating guests was because it couldn’t guarantee CPU/Memory on the second host, i’d expect to see any alert in the screenshot for the second host as well
C – DRS would have done this itself if it could have
D – Maybe there are resources in use on the VMs that prevent DRS migration.. Physical Mode RDMs for example. They would require us to shut them down before migrating.
my two cents anyway.. 🙂
0
0
B could also be correct in my opinion.
At the moment the second host might not be over utilized so an alert is not generated, but moving the web server to this host might be ‘the straw that broke the camels back’ and hence DRS isn’t doing it.
A VM with a Physical Mode RDM CAN be vMotioned, so that is not valid…
If a host CD is connected then, that could explain why DRS isn’t moving this web server but that info is not given…
Based on the info given B should be the most correct answer…
0
0
B is the correct answer for this problem.
0
0
B is the correct answer has the host is having high cpu and drs is enabled, if drs was not enabled then the answer could be c
0
0
@tom ku completely explain why B is correct and fully agreed
0
0
A. Hot-add does nothing, it is the HOST CPU usage. Look at the alarm message
B. Is correct. You have Fully Automated DRS and it didn’t solve the problem.
C. Why? Fully Automated DRS is activated. It will balance VMs back at optimal solution.
D – why power off if DRS can VMotion? And do you imagine that all administrators will do the same on production environment just because they don’t have enough resources? Heh…
0
0
the question is very clear that the DRS cluster is fully automated, so if there is any available resourses the DRS Cluster should Automatically do the load balance and fix the issue, sothe problem here is no more Resourses available so B should be the correct answer
0
0
How is B the answer? you are unable to move the VMs using any migration tools (vMotion/DRS) currently because the CPU utilization on the current host running these VMs is too high. Adding another host will not alleviate the problem, we already have another host to migrate a VM using DRS if we could. (assuming fully automated DRS is not set to fully conservative)
0
0
A.
Hot-add a CPU to the the web server virtual machine.
-Does not make any sense the host CPU resources are already over utilized.
B.
Add an ESXi host to the cluster
-Only makes sense if you’re boss doesn’t mind spending $50k every time you have a problem. This assumes that DRS isn’t migrating because the second host would be over-utilized.
C.
vMotion one or more running virtual machines on the ESXi host running the web server virtual machine to the other ESxi host in the cluster.
-May work if the DRS migration threshold is set to ‘Conservative’, bit otherwise probably not. Of course in the real world you would know or could find out the migration threshold setting. They should have stated it in the question.
D.
Power off one or more virtual machine on the ESXi host running on the Web server virtual machine and migrate them to the other ESXi host in the cluster.
-May work if EVC is not enabled. Differing host CPU types could be the reason DRS isn’t migrating any VMs.
So based on the above it could be B, C or D, depending on a lot of possibilities that are not mentioned in the question.
I’d say:
1. Check the migration threshold setting. If it’s set to conservative, try a vMotion.
2. If that fails, check your EVC settings and host CPU types. The cluster may not be vMotion compatible, shut down some VMS and move them manually.
3. If both hosts are at the limit of CPU resource utilization, add another host. I’m sure your boss will be thrilled with that solution.
0
0
I think I just figured it out:
There are 2 web servers and 2 app servers in the picture, from their names I’d guess that they are load balanced – so VM-Host affinity rules are preventing DRS from migrating any VMs.
Therefore the only solution would be to add another host.
It’s a whopping assumption, but it makes more sense than any of the other assumptions that any other answer requires.
0
0