Which action can resolve the issue?

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-titanium03.vmeduc.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?

Hot-add a CPU to the Web server virtual machine

Add an ESXi host to the cluster

vMotion Migrate one or more running virtual machines on the ESXi host running the Web server virtual machine to the other ESXi host in the cluster

Power off one or more virtual machines on the ESXi host running the Web server virtual machine and migrate them to the other ESXi host in the cluster

13 Comments on “Which action can resolve the issue?

  1. dimaped says:

    Best Answer should be B (Add an ESXi host to the cluster). D does not seem to be appropriated and should be covered off by DRS. Anyone else agree?

    1. falsufyani says:

      D is the right answer…
      the host is already member of the cluster as appear in the exhibit. so power off some VMs will free some memory on the host. vmotion these VMs will not add overhead on this host.

      1. Ahmed Maged says:

        D cannot be the answer. DRS would work to satisfy any “significant” improvement to the load balancing. It did not work. which means that the other host will not accommodate new VMs from the problematic host. the only logical solution is B

  2. Jon says:

    Yes. C & D would accomplish the same thing and should both be covered by DRS. If DRS is not recommending any machines be migrated and it is in fully automated mode, it means that it it would not see a performance gain by migrating a VM, i.e. it would just make the other host CPU constrained as well. Adding another vCPU to the VM would not alleviate CPU on the host, the only option left is B.

  3. dzemboc77 says:

    I think the correct answer would be D based on the esxi host are already clustered with DRS, They should balance out and since they are having issues still most likey the other host is low on resources as well so migrating a vm to that host wont fix the cpu issue, it would just change with host is having the cpu issue. Adding a Host would solve the issue but I think they are looking for if you had to fix that issue right now to improve performance and not a few days down the road.

  4. Jon says:

    If you agree that DRS is not moving the machines because it would add contention on the other host, why would you manually power them off and migrate them? If that logic is correct, then C would be a correct answer as well because both end results accomplish the same thing, you are just using vMotion in one case and powering off/powering up in the other.

  5. Mario says:

    D. is the correct answer. vMotion requires system resources to work. If this host is severely CPU constrained vMotion cannot work. DRS will not make a recommendation if it knows that it does not have resources at its disposal. Adding hosts will not fix the problem. The only solution is to relieve some of the pressure off of this host’s CPU so that DRS/vMotion can function.

  6. Josti says:

    The question is “Which action can resolve the issue?”
    Anwser B would apply to this.
    The question should be something like “Which action can resolve the issue quickest?”

  7. Rich says:

    I think the trick is to look at the names of the VMs running on these hosts. They appear to be load balanced pairs. Most likely there are VM-VM anti-infinity rules that are preventing DRS migrations. If that’s true then B would be the answer.

Leave a Reply

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