DRS Moved a VM Back After a Manual vMotion: Rule, Setting or Load Balancing?

A manual vMotion completes, and later the cluster migrates the same VM again, sometimes straight back to where it was.

One documented cause is that your move broke a rule DRS is allowed to repair. vSphere lets a user-initiated vMotion break a Keep Virtual Machines Together or Separate Virtual Machines rule, and a fully automated DRS cluster then remediates the placement (Broadcom KB 393104). The vSphere 8.0 guide documents the same for preferential ("should") VM-Host rules (Using Affinity Rules without vSphere DRS).

Rule remediation is not the only cause. DRS load balancing and the VM Distribution option can also move a VM with no rule involved. So treat "a rule pulled it back" as something to establish from evidence, not as the starting assumption.

This article is inspection only. It shows how to work out which rule, group or setting the second migration is consistent with, using the vSphere 8.0 vSphere Client, and when the evidence is not enough to name a cause. It does not cover migrating VMs, changing rules, maintenance mode or turning DRS off. Each of those is a separate change with its own approval.

This guide is based on source research only. Nothing in it was run. All VM, host and cluster names are fictional.

Who decides where a VM runs

A VM's placement in a DRS cluster depends on several separate settings. Check each one.

Sources: - Create a VM-Host Affinity Rule (the four specifications) - Using VM-Host Affinity Rules - VM-VM Affinity Rule Conflicts - Set a Custom Automation Level for a Virtual Machine - Edit Cluster Settings - Soft Rule Violation Correction Disallowed

How overlapping VM-Host rules combine

From Using VM-Host Affinity Rules:

• Rules are not ranked, and the older rule wins a conflict. VM-Host rules are applied equally. When you create a rule, vCenter does not check how it works with your other rules. When two VM-Host rules conflict, the older one takes precedence, the newer one is deactivated, and DRS ignores deactivated rules. Check the enabled state of every rule, not just whether it exists. A deactivated rule is not by itself proof of a conflict: it may also have been disabled on purpose.
• Two "must run on" rules intersect. Broadcom's example is a VM in two groups, each covered by a different required rule. That VM can run only on hosts that belong to both host groups. The example concerns positive rules.
• A "must not run on" rule excludes. It forbids the hosts in its group; it does not require the VM to run inside that group. A practical reading of the hosts a VM may use: 1. Start from the hosts that all enabled must run on rules permit. 2. Remove the hosts named by enabled must not run on rules. 3. Then apply capacity and compatibility.

This combination is a reading of the documented rule definitions. Broadcom does not state it as a formula.

Since vSphere 7.0 Update 1, DRS depends on the availability of vSphere Cluster Services (vCLS) VMs (Edit Cluster Settings). If DRS has stopped acting altogether, that is a different problem from the one in this guide.

Before you start

• Read-only access to the cluster in the vSphere Client. This guide uses only views. Any later change needs its own approval.
• The vCenter and ESXi builds, recorded. The workflow below follows the vSphere 8.0 documentation. KB 393104 confirms the same symptom on vSphere 7.x, but this guide does not claim that the 8.0 screens match 7.x. On 7.x, use the matching 7.0 pages.
• The reason for each rule, from its owner: for example licensing, application clustering or a vendor support statement. Without it you cannot judge whether a rule is still correct.

Step 1: establish what started the second migration

Before looking at rules, record the facts of both migrations from the cluster's recent tasks and events in the vSphere Client. This guide does not name the exact screen, because the cited pages do not document it:

• The VM, the source host, the destination host and the time of your manual vMotion.
• The time and destination of the second migration.

• Who or what started the second migration, as the client shows it.

• If the client shows them, the DRS recommendation behind the second migration and the reason it gives.

Who applied a migration is not the same as why it was recommended. In a Manual or Partially Automated cluster, DRS presents migration recommendations "based on rule fulfillment and load balancing" for a person to approve (Using Affinity Rules with vSphere DRS). So a person-initiated migration may still be a DRS recommendation, and a system-initiated one does not by itself say which reason DRS had. Keep both in this investigation. Only a person's own manual move, with no recommendation behind it, falls outside it. This guide makes no claim about the exact wording of the initiator or reason fields in your build, so record what they show.

Step 2: read the cluster's own explanation

Open the cluster's DRS Faults view. Broadcom documents that any enabled affinity rule DRS cannot satisfy appears there with a matching fault, and that rule violations also produce a log event (Using Affinity Rules with vSphere DRS). These fault names are worth recognising:

If the second migration has already happened, there may be no fault, because the rule is satisfied again. The view is most useful while the VM is still out of place, or when a manual or partially automated cluster has a recommendation waiting.

Step 3: record every rule and group that applies to the VM

All of this is in the vSphere 8.0 Client, on the cluster's Configure tab, in the Configuration section. These are the same pages Broadcom's procedures use to create rules and groups:

• Create a VM-VM Affinity Rule
• Create a VM-Host Affinity Rule
• Create a Virtual Machine Group
• Create a VM-Host Group

View these pages only. Do not open the Add or Edit dialogs.

1. VM/Host Groups. Find every VM Group that contains the VM, and record each group's full member list. Record every Host Group with its member hosts.
2. VM/Host Rules, VM-VM types. Record every Keep Virtual Machines Together or Separate Virtual Machines rule that lists the VM, with its full member list and its enabled state.
3. VM/Host Rules, Virtual Machines to Hosts type. Record every rule whose VM group is one from item 1, with its specification (must run on, should run on, must not run on, should not run on), its host group and its enabled state.
4. Per-VM automation. Record any per-VM automation level for the VM (VM Overrides), and separately whether the cluster's Enable individual virtual machine automation levels check box is selected. Read it in the view only; do not open Edit.
5. vSphere DRS settings. Record the cluster automation level, the migration threshold and whether VM Distribution is on.

If two clusters, VMs or groups have similar names, confirm you have the right object before recording anything, for example by its host and folder. Stop if you cannot tell them apart.

Keep this record. It is the evidence for Step 4, and any later change request needs it. A VM-Host rule reaches the VM only through a VM group, so a rule list without the group membership cannot show which rules apply.

Step 4: match the evidence to a cause

Each row gives a documented explanation the record is consistent with. Unless a recorded DRS recommendation, reason or event names the cause, the row is a candidate, not a proven cause. Record "consistent with …, cause unconfirmed", and keep load balancing, VM Distribution and host events open as alternatives.

KB 447700 describes VMs under preferential rules as effectively pinned, in day-to-day operation, to the host group their rule points to. For a should not run on rule, that means the hosts outside the named group.

Worked example (hypothetical)

Cluster CL-PROD-A runs fully automated DRS. At 10:02 an administrator manually moves db01 from esx01 to esx03 before firmware work on esx01. At 10:09 db01 is migrated to esx01, and the events show the system started that migration. No DRS recommendation reason is recorded for it. The application team reports two brief network blips.

The Step 3 record:

• VM/Host Rules: app-db-together, Keep Virtual Machines Together, enabled, members app01 and db01.
• Current hosts: app01 is on esx01.
• VM/Host Groups: db01 is in no VM group, so no VM-Host rule applies to it.
• VM Overrides: none for db01.
• DRS settings: Fully Automated, default threshold.

Conclusion: the 10:02 move separated app01 and db01, which broke an enabled Keep Together rule. The 10:09 migration restored co-location, which is consistent with KB 393104's rule correction. Because no DRS reason is recorded, the ticket says "consistent with rule correction; cause not proven", and load balancing is not excluded. The blips line up with the two migrations. KB 393104 notes that RARP traffic follows a vMotion when the switch's Notify Switches setting is on. That is expected behaviour, and it does not cause the second migration.

What to hand on: the firmware work on esx01 needs a plan that keeps app01 and db01 together. That plan belongs to the separately approved maintenance procedure for the host, not to this diagnosis (see Patch ESXi clusters with Lifecycle Manager). Whether the VMs can be placed elsewhere depends on destination capacity, compatibility, devices and storage, other rules and protection settings, none of which this guide assesses.

A contrasting case: the same symptom, but the record shows db01 in VM group sql-vms. An enabled rule, sql-licensed-hosts, says sql-vms should run on host group sql-hosts (esx01, esx02), and esx03 is not in that group. The move broke a positive preference. If licensing really requires those hosts, a "should" rule may be weaker than the requirement. Changing a rule's strength is a design decision for the licence owner, and it carries the risks described below.

Troubleshooting

For migration compatibility errors, see vMotion fails with a compatibility error. For VMs that HA did not restart, see vSphere HA did not restart VMs.

Acceptance checks

These checks close the diagnosis, not any later change.

1. Step 1: both migrations are recorded with their times, hosts and initiator, plus the DRS recommendation and reason where the client shows them.
2. Step 3: the record lists every applicable VM-VM rule with its members, every VM group that contains the VM, and every VM-Host rule that reaches it with its host-group members, all with their enabled state.
3. Step 4: the ticket names the documented explanation the record is consistent with, says whether a recorded DRS reason proves it or the cause stays unconfirmed, or states that no rule applies. It cites the record. A deactivated rule is recorded as a conflict only with conflict evidence.
4. At a later observation, the VM's current placement complies with every enabled required rule that applies to it, and each enabled preferential rule is either satisfied or its violation is explained. Broadcom documents that preferential rules "can be violated to allow the proper functioning of DRS, vSphere HA, and vSphere DPM", and a violation DRS cannot correct appears in the Faults view. Compliant placement on a different host from the original also passes. Record the time you checked.
5. Any proposed migration, rule change or maintenance is handed on as a separate change, with the Step 3 record attached.

Optionally, Broadcom documents an event-based alarm with the trigger VM is violating VM-Host Affinity Rule. Adding an alarm is a configuration change, so it goes through your normal approval process.

Risk notes for any later change

• Reversing a rule change is a configuration change of its own. Do not revert or restore vCenter just to undo one rule. A separately reviewed reversal needs the full recorded definition: rule type, specification, VM group and host group with their members, and enabled state. It also needs a check of current membership and conflicts before the definition is re-applied. Restoring a rule does not restore the earlier VM placement; placement then follows DRS under the restored rules.
• Required rules have costs. Broadcom warns that required ("must") VM-Host rules can fragment the cluster. If a required rule would be violated:
• DRS does not evacuate VMs for maintenance mode.
• DRS does not place VMs for power-on, and does not load-balance them.
• HA does not fail them over.
• DPM does not put hosts into standby.

Keep enough hosts in each required host group that losing one still leaves somewhere for the VM to run. - HA can break preferences. The vSphere 8.0 guide states that, with soft VM-Host rules, vSphere HA operations succeed even if the rule is violated. Whether a particular VM is restarted after a failure still depends on HA's own capacity and admission conditions, which this guide does not assess. - Disabling DRS for one VM pins it. It also stops DRS moving the VM for any reason. Treat it as a deliberate exception with an owner and an end date. - VM-VM rules and HA. Broadcom says VM-VM rules are not supported when the HA admission control policy designates multiple failover hosts ("Specify Failover Hosts"). - Leave the migration threshold alone. Changing the cluster-wide threshold or automation level to stop one VM moving affects every VM in the cluster.

These are source-documented behaviours. Expert review, and a lab check against your own cluster design, are still needed before any change in production.

Learning notes

• A second migration after a manual vMotion can be rule remediation, load balancing or VM Distribution. The initiator, the timeline and the enabled rules narrow it down; only a recorded DRS reason proves it. Who applied a migration is not why it was recommended.
• "Must" rules stop a move that would break them. "Should" rules and VM-VM rules let the move happen and are corrected afterwards.
• Should run on prefers hosts inside the named group; should not run on prefers hosts outside it.
• A Keep Together rule requires the members to run on the same host, not on a particular host.
• A new VM-Host rule is not checked against existing rules when it is created, and a conflicting newer rule is deactivated. The reverse does not hold: a deactivated rule may have been disabled on purpose.

References

Related articles

• vMotion fails with a compatibility error: EVC and VMkernel checks
• vSphere HA did not restart VMs: admission control and isolation
• Build a vSphere private cloud cluster
• Patch ESXi clusters with Lifecycle Manager