Segregation Rules
Device isolation and placement rules for compliance, security, and multi-tenancy requirements.
Segregation rules are accessed from the device list page. Navigate to Virtual Datacenter > All Devices and click the Segregation rules button.
Overview
Segregation rules let you control the physical placement of virtual machines on the underlying hypervisor hosts. You can pin a set of VMs to the same physical server (Connect) or ask that they be spread across different physical servers (Separate). Rules are organized by cloud or hypervisor and enforced automatically during VM placement. They do not control network connectivity between VMs — that is governed by firewalls and, in Kubernetes, by NetworkPolicies.
Managing Segregation Rules
Creating a Rule
Open segregation rules
Navigate to Virtual Datacenter > All Devices and click the Segregation rules button in the device list header.
Select the cloud
If you have multiple clouds or hypervisors, select the appropriate one from the tabs at the top.
Create a new rule
Click Create Rule. Provide a name, description, select the rule type (Connect or Separate), and choose the devices to include.
Viewing and Filtering Rules
The rules list can be filtered by type using the tabs: All rules, Connect, or Separate. Use the search field to find rules by name, description, or device name.
Editing and Deleting Rules
Click a rule to edit its name, description, or device assignments. Rules with a "Provisioning" status cannot be edited until provisioning completes. To remove a rule, click the delete button and confirm in the dialog.
Use Cases
Connect
Ensures that two or more virtual machines run on the same physical server. Useful when workloads should be as close together as possible — for example, a web server and its database — to minimize network latency between them.
Separate
Selecting Separate creates a vCenter anti-affinity rule that tells the hypervisor scheduler to keep the selected VMs on different physical hosts. This is best-effort placement, not an absolute guarantee — under resource pressure, or during an automatic restart after a host failure, the scheduler may still place them on the same host. Used well, it reduces the single point of failure that exists when a clustered service — a database cluster, Kubernetes control plane, or message broker cluster — would otherwise be co-located on one host. Also addresses the high-availability and business-continuity requirements of frameworks such as FINMA Circular 2023/1 (critical functions), ISO 27001 Annex A.17, nDSG Art. 8 / GDPR Art. 32, and NIS2 Article 21.
Anti-affinity protects you from a class of failures that, on the Xelon cloud, is already mostly handled at the platform level:
- Storage: no impact. Persistent storage is clustered across multiple nodes, so a single hardware node failure does not lose data or take volumes offline.
- Compute: VMs that were running on the failed node are automatically restarted on a healthy node. The VM experiences a brief outage during failover but comes back without manual intervention.
Anti-affinity (Separate) adds a further layer on top of this: under normal operation, the members of a single cluster are kept apart so they do not share a host in the first place. Without it, two replicas of the same database cluster might end up co-located, and a single host failure would briefly take both down at once. With it, in the common case only one replica is affected by any given host failure, and the cluster continues to serve traffic with no perceptible outage. Because placement is best-effort, the platform cannot promise replicas will never share a host — for example, an automatic restart after a host failure may temporarily co-locate them.