Which two steps could be taken to correct the problem?

An administrator is applying patches to a batch of ESX1 5.x hosts in an under-allocated HA/DRS cluster. An attempt is made to place the host into maintenance mode, but the progress has stalled at 2%. DRS are configured as shown in the exhibit. Of the four choices below, two would effectively resolve this issue.

Which two steps could be taken to correct the problem? Choose two

A.
manually migrates any running virtual machines to another host

B.
set the cluster to fully automated

C.
disable HA monitoring to allow maintenance mode to proceed

D.
set the cluster migration threshold to aggressive

Explanation:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007156

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1036167

– If an ESX host is a part of VMware High Availability (HA) or DR’S cluster, check the Admission Control settings. You may have to disable this option if there are not enough resources to ensure fail over capacity.
– If you want vCenter Server to migrate your running virtual machines automatically to other hosts when placing your host in maintenance mode, DR’S must be enabled in your cluster in the Fully Automated mode.

19 Comments on “Which two steps could be taken to correct the problem?

  1. Gary says:

    The answer is A and B.

    KB 1007156 is detailing a workaround of turning off HA because there was a bug that when you disabled admission control it didnt disable and is assuming that DRS is set to fully automatic already. We are clearly shown the DRS is not set to fully automatic.

    “Of the four choices below, two would effectively resolve this issue.” I read this as saying which of the choices INDEPENDENT of the other choices will resolve the issue.

    A – by itself will resolve the issue
    B – by itself will resolve the issue
    C – relies on you also following choice B as well. Turning off HA or making any adjustment to HA alone will not make migrations start working. There is also the fact that the question alludes to the potential that admission control policy is not the issue because it states the cluster is under allocated. Admission control is the only thing within HA that would prevent a migration.
    D – changing the threshold will not change if migrations occur when entering maintenance mode.

  2. J says:

    C – Wrong. Question does not mention whether or not HA VM monitoring is enabled. There is also no need to disable it, as this does not solve the problem.
    D – Wrong. Changing the cluster migration threshold would have no effect if the automation level was still set to ‘Manual’

    Therefore, the correct answers have to be A and B.

  3. Matt says:

    Yes, A & B are correct.

    D. set the cluster migration threshold to aggressive (is wrong due to the fact that when a host is put into maintenance mode, the migration threshold is irrelevant).

  4. AS says:

    Team, I respectfully disagree.
    In my opinion the right answer is B and D.

    Two reasons drive me to look on this way:

    1st. The migration threshold has an important participation on when VMs will be moved by DRS to another host (including when putting host into maintenance mode), migration threshold set to Conservative means that the aggressivity level is set to 1, and will triggers a vMotion if the VM has a level five priority rating.

    2nd. The question is clear when says that the resolution is in the scenario presented (“DRS are configured as shown in the exhibit. Of the four choices below (Manual / Partial Automated / Full Automated / Migration Threshold), two would effectively resolve this issue”). Based on this, two steps must be done to complete the exercise (“Which two steps could be taken to correct the problem?”).

    In the Cluster settings the only two steps that could be done in order to solve this issue is the steps described in the answers B and D.

  5. Joe says:

    The answer may in fact be A and C. Here is why, the question states that the HA/DRS cluster is under-allocated, if it is under allocated, why would putting the automation level to “Fully…” resolve the issue? (keep in mind admission control is enabled by default) if there are no other hosts that can support the running VM’s because admission control won’t let them violate any constraints.
    A – move the VM’s manually means admission control has nothing to worry about
    B – just what I said above, other hosts may be under-allocated
    C – disable HA, means admission control, etc. is disabled
    D – Threshold set to aggressive would do what the conservative setting is anyway (maintenance mode is covered as a priority 1 event)

    Also, the question doesn’t state anything about VM running requirements, meaning we can do manual moves, etc. without concern for downtime.

  6. G says:

    Wow you guys are over complicating a simple question. This isnt a VCDX its the VCP and the answer is obvious. This happens all the time. The host is put into MM and VMs are still on the host so it stays at 2%. I see this happen with VMs that are stored on local disks(ignore that comment for this question). Keep tgis simple the setting shows thar you would have to manually move the VM ir enable DRS.

    Threshold doesnt matter becausr its not enabled to begin with.

    HA monititing wont matter because the VM is running. mM wont run if a VM is running

  7. Ed B says:

    I use to think it was B & C but determined it was A & B. D is definitely wrong. C is incorrect because HA Monitor only looks for failed virtual machines and initiates a HA reboot to another host. The host it reboots on is determined by DRS.

  8. Daniel says:

    Its A and B as the screenshpt only shows the DRS settings and dosnt discuss anything about the HA seetings. Apply the KISS princeple.

  9. TW says:

    Is the following the reason for the answer of B and C?

    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1036167

    ESX host in a VMware High Availability cluster fails to enter maintenance mode and stops at 2%
    Symptoms

    An ESX host fails to enter maintenance mode in a VMware High Availability (HA) or DRS cluster
    Hosts fail to migrate when attempting to enter maintenance mode
    The progress indicator remains at 2% indefinitely
    Trying to remediate a host and getting a time out error when trying to enter the maintenance mode

    Purpose
    This article provides an explanation for the behavior and includes a workaround.

    Note: The workaround provided may take a significant amount of time to complete.
    Resolution
    This is normal behavior for a VMware HA/DRS cluster that is using strict admission control.

    Disabling strict admission control (allowing virtual machines to power on even if they violate constraints) should allow a host to enter maintenance mode in this situation. A bug was discovered that would not allow a host to enter maintenance mode even if stict admission control was disabled.

    This was resolved in VirtualCenter 2.5 Update 3 and disabling strict admission control should now allow hosts to enter maintenance mode correctly.

    To workaround the issue, temporarily disable VMware HA in the cluster settings. You will then be able to put the ESX Server host into Maintence mode and do the work required. You can then re-enable HA on your cluster.

    For detailed steps, see VMware High Availability: Concepts, Implementation, and Best Practices.

    Note: DRS needs to be enabled on your cluster in Fully Automated mode if you want VirtualCenter to migrate your running virtual machines automatically to other hosts when placing your host in Maintenance Mode.

  10. G.D says:

    I tried on two hosts and confirmed that either A or B will allow host go to MM.

    C: disable HA monitoring to allow maintenance mode to proceed still not able to shutdown the vm running on the host.

    D.set the cluster migration threshold to aggressive should grey out since the DRS is on manual mode


Leave a Reply

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