# Data Object - ClusterRuleInfo(vim.cluster.RuleInfo)

Property of
  ClusterConfigInfo, ClusterConfigInfoEx, ClusterRuleSpec, PlacementSpec, RuleViolation, StorageDrsPodConfigInfo, VmPodConfigForPlacement
Returned by
  FindRulesForVm
Extended by
  ClusterAffinityRuleSpec, ClusterAntiAffinityRuleSpec, ClusterDependencyRuleInfo, ClusterVmHostRuleInfo, VirtualDiskAntiAffinityRuleSpec, VirtualDiskRuleSpec
Extends
  DynamicData
See also
  ManagedEntityStatus
Since
  2.0

## Data Object Description

The ClusterRuleInfo data object is the base type for affinity and anti-affinity rules. The affinity and anti-affinity rules are DRS (Distributed Resource Scheduling) rules that affect the placement of virtual machines in a cluster. Hosts and virtual machines referenced in a DRS rule must be in the same cluster.

Note: DRS rules are different than an individual host's CPU affinity rules (VirtualMachineAffinityInfo).

The Server uses DRS rule objects to describe the current rule configuration (ClusterConfigInfoEx.rule). Your client application uses rule objects to configure the affinity and anti-affinity rules (ClusterConfigSpecEx.rulesSpec).

You can create the following types of rules:

- An affinity rule defines a set of virtual machines that should run on the same host. The ClusterAffinityRuleSpec object describes a rule that identifies virtual machines, but does not identify any specific host.
- An anti-affinity rule defines a set of virtual machines that should run on different hosts. The ClusterAntiAffinityRuleSpec object describes a rule that identifies virtual machines, but does not identify any specific host.
- A VM-Host rule defines affinity and anti-affinity relationships between virtual machines and hosts. The ClusterVmHostRuleInfo object describes a rule that identifies a virtual machine group (ClusterVmGroup) and affinity and anti-affinity host groups (ClusterHostGroup).

Rule configuration is a dynamic process. When you create or modify a DRS rule, the Server applies the rule to the cluster. If the existing cluster configuration violates the rule, the Server attempts to correct the situation. If that is not possible, the Server generates a fault and produces a log event. DRS rules do not have precedence; all rules are applied equally. DRS does not validate one rule against another. If you create conflicting rules, the older rule takes precedence and DRS disables the newer rule.

Improperly used, DRS rules can fragment the cluster and inhibit the proper functioning of DRS, HA, and DPM services. vSphere services never take any actions that would result in the violation of mandatory DRS rules. An operation that violates a mandatory rule would produce the following consequences.

- DRS does not evacuate virtual machines to place a host in maintenance mode.
- DRS does not place virtual machines for power-on or load balance virtual machines.
- HA does not perform failovers.
- DPM does not optimize power management by placing hosts into standby mode.

To avoid these situations, exercise caution when creating more than one mandatory rule, or consider using only optional rules. Make sure that the number of hosts with which a virtual machine is related by affinity rule is large enough that losing a host does not prevent the virtual machine from running.

For manual and partially automated DRS clusters, the Server produces migration recommendations to satisfy the DRS rules. You are not required to act on the recommendations, but the Server maintains the recommendations until the rules are satisfied.

Properties

Name | Type | Description
--- | --- | ---
enabled* | xsd:boolean | Flag to indicate whether or not the rule is enabled. Set this property when you configure the rule. The default value is false (disabled). If there is a rule conflict, the Server can override the setting to disable a rule.
inCompliance* | xsd:boolean | Flag to indicate whether or not the placement of Virtual Machines is currently in compliance with this rule. The Server does not currently use this property. Since vSphere API 4.1
key* | xsd:int | Unique ID for rules. When adding a new rule, do not specify this property. The Server will assign the key.
mandatory* | xsd:boolean | Flag to indicate whether compliance with this rule is mandatory or optional. The default value is false (optional). A mandatory rule will prevent a virtual machine from being powered on or migrated to a host that does not satisfy the rule. An optional rule specifies a preference. DRS takes an optional rule into consideration when it places a virtual machine in the cluster. DRS will act on an optional rule as long as it does not impact the ability of the host to satisfy current CPU or memory requirements for virtual machines on the system. (As long as the operation does not cause any host to be more than 100% utilized.) Since vSphere API 4.1
name* | xsd:string | Name of the rule.
ruleUuid* | xsd:string | UUID for the rule. When adding a new rule, do not specify this property. The Server will assign the key. Since vSphere API 6.0
status* | ManagedEntityStatus | Flag to indicate whether or not the rule is currently satisfied.
userCreated* | xsd:boolean | Flag to indicate whether the rule is created by the user or the system. Since vSphere API 4.1
Properties inherited from DynamicData
None

*Need not be set
Show WSDL type definition
<complexType xmlns="http://www.w3.org/2001/XMLSchema" xmlns:sms="urn:sms" name="ClusterRuleInfo"> <complexContent> <extension base="sms:DynamicData"> <sequence> <element name="key" type="xsd:int" minOccurs="0"/> <element name="status" type="sms:ManagedEntityStatus" minOccurs="0"/> <element name="enabled" type="xsd:boolean" minOccurs="0"/> <element name="name" type="xsd:string" minOccurs="0"/> <element name="mandatory" type="xsd:boolean" minOccurs="0"/> <element name="userCreated" type="xsd:boolean" minOccurs="0"/> <element name="inCompliance" type="xsd:boolean" minOccurs="0"/> <element name="ruleUuid" type="xsd:string" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType>