Mixed Automation Across a PCI Scope With No Spare Hosts

Keep Global Automatic and express the exception as a policy on a dynamic group.

1. Build the group from the tag or attribute you already applied (PCI=true), not a static list. New VMs must inherit the control without an administrator remembering.
2. Attach a policy to that group setting automation to Manual for VM resize actions, and for any other configuration action the auditors want gated. Manual means the action is still generated and queued for approval; Disabled would suppress the recommendation entirely and blind you to what the estate needs.
3. Precedence runs from the entity up: an entity-level setting overrides a group policy, which overrides the global default. Because you are not setting anything per entity, the other ~2,120 VMs keep Automatic. Where an entity belongs to overlapping groups, the more specific scope wins - keep the PCI group the narrowest scope and do not also tag those VMs into a broad production policy that sets Automatic.
4. Verify per entity: open several PCI and several non-PCI VMs and read the effective policy, not just the group definition.
5. Publish the approval queue. A scheduled export of pending PCI actions to the change manager turns the control into something an auditor can see operating, rather than a setting that exists on paper.

Two hard constraints exist and placement logic cannot invent hosts, so sequence the work.

1. Express the rule as a placement policy: a PCI VM group, a non-PCI VM group, and a constraint that PCI VMs must not be placed on hosts running non-PCI VMs. Use the mandatory relationship if it is a compliance requirement. Using the advisory relationship invites the platform to violate it, and you will then be reporting a breach rather than preventing one.
2. The clean way to satisfy it without buying hardware is dedication: create a host group and pin the PCI VMs to it. Size that host group for peak demand plus one host for N+1, because a host-failure violation inside the PCI scope is itself a compliance finding.
3. Expect the platform to stop generating moves that would break the constraint and to report violations instead. That is correct. The 60 host-failure and 40 cannot-place conditions are the product telling you the capacity does not exist under the constraint.
4. Tell the business exactly that, with the numbers, and escalate as a capacity decision. Do not downgrade the policy to advisory or exclude the hosts to make the dashboard green - that converts a visible capacity gap into an invisible compliance breach.
5. Finally, keep the PCI host group out of the consolidation that Automatic performs, or a later placement action can quietly undo the isolation.

Batch tier. Create a scheduling (workload placement) policy on the batch group defining a window from 22:00 to 02:00 during which moves are not executed. Two things to anticipate: the window uses the platform's configured time zone rather than the data centre's unless you verify it, and the window blocks execution, not analysis - recommendations keep appearing and queue for the window's close, which looks like a backlog in Pending Actions and will generate tickets unless you explain it first.

In-memory databases. 'Never merged onto a busier host' is two controls, not one:

• Anti-affinity between the database VMs themselves, so no two land on the same host.
• A placement policy between the database group and the high-utilization group with an avoid relationship, so a consolidation that co-locates a database with a busy workload is not generated.

Use mandatory relationships only where a breach is unacceptable. Each one shrinks the feasible placement space, and with 48 hosts already partitioned for PCI, piling on mandatory constraints can convert healthy merges into cannot-place violations. Validate the result by confirming the database VMs still receive resize actions but no move actions, and revisit the policies whenever host capacity changes.