1. Overview of the Oracle VM Server for SPARC Software
2. Installing and Enabling Software
4. Setting Up Services and the Control Domain
Enabling the Whole-Core Constraint
Disabling the Whole-Core Constraint
Allocating CPUs to the Control Domain
Interactions Between the Whole-Core Constraint and Other Domain Features
Using Memory Dynamic Reconfiguration
Tracking the Progress of a Memory DR Request
Memory Reconfiguration of the Control Domain
Decrease the Control Domain's Memory
Dynamic and Delayed Reconfiguration
Memory Alignment for Active Domains
Memory Alignment for Bound Domains
Memory Alignment for Inactive Domains
Listing CPU Power-Managed Strands
List CPU Power-Managed Strands
Using Dynamic Resource Management
Show Syntax Usage for ldm Subcommands
Utilization Statistic Definition
Generate an Extended List (-e)
Generate a Parseable, Machine-Readable List (-p)
Generate a Subset of a Long List (-o format)
List Constraints for One Domain
List Constraints in XML Format
List Constraints in a Machine-Readable Format
12. Performing Other Administration Tasks
A. Oracle VM Server for SPARC Physical-to-Virtual Conversion Tool
B. Oracle VM Server for SPARC Configuration Assistant
C. Logical Domains Manager Discovery
D. Using the XML Interface With the Logical Domains Manager
The CPU allocation mechanism uses the following constraints and hint for CPU resources:
Whole-core constraint. This constraint specifies that virtual CPUs are allocated to a domain based on a specified number of CPU cores. The system must be able to allocate the specified number of cores and must also assign all the virtual CPUs of those allocated cores to the domain. If the system cannot allocate the specified number of cores, the domain fails to bind.
Maximum number of cores constraint. This constraint specifies the maximum number of cores that can be assigned to a bound or active domain. This constraint is automatically enabled when the whole-core constraint is set on a domain. In that case, the maximum number of cores is automatically set to the number of cores configured when the domain is inactive. Currently, this constraint cannot be enabled independently of the whole-core constraint, and the maximum number of cores cannot be set manually.
Core affinity hint. This hint requests that virtual CPUs allocated to a domain come from the same CPU cores or from the fewest number of CPU cores. The system makes its best effort to honor this request. The domain fails to bind only if insufficient free virtual CPUs are available on the system.
The core affinity hint is enabled by default and cannot be disabled.
Note - The whole-core constraint and the core affinity hint only address the location of a virtual CPU on cores. They do not address the location of a core on chips or of a chip on sockets.
The whole-core constraint is automatically enabled when you specify the number of cores to assign to a domain. By default, you specify the virtual CPUs to assign to a domain. You can only enable the whole-core constraint on an inactive domain, not on a domain that is bound or active. Before you enable the whole-core constraint on the control domain, you must first initiate a delayed reconfiguration.
Use the ldm add-vcpu -c number, ldm set-vcpu -c number, or ldm remove-vcpu -c number command to assign or remove CPU cores to and from a domain. number specifies the number of CPU cores and enables the whole-core constraint. For more information, see the ldm(1M) man page.
You can use the ldm add-vcpu -c number or ldm remove-vcpu -c number command on a domain that was previously configured with virtual CPUs. In that case, the existing number of virtual CPUs is automatically converted to the corresponding number of cores. This conversion is possible only if the existing number of virtual CPUs is a multiple of the number of virtual CPUs per core. If not, the conversion cannot be performed, and the command fails.
Note - If you use these commands to enable the whole-core constraint on an inactive domain or on the control domain in delayed reconfiguration mode, the maximum number of cores is also set. The maximum number of cores is not affected when you use these commands on a bound or active domain.
For example, a core is comprised of eight virtual CPUs. If a domain has seven virtual CPUs assigned, an ldm add-vcpu -c or ldm remove-vcpu -c command could not meet the whole-core constraint. Instead, you could use the set-vcpu -c command to specify the number of cores and to enable the whole-core constraint.
The following example enables the whole-core constraint on the inactive ldg1 domain. The ldm list command verifies that the whole-core constraint is enabled.
primary# ldm add-vcpu -c 1 ldg1 primary# ldm list -o resmgmt ldg1 NAME ldg1 CONSTRAINT whole-core max-cores=1
Note - When the whole-core constraint is enabled on a domain, the cryptographic units that are associated with those cores are unaffected by core additions. So, the system does not automatically add or remove the associated cryptographic units to or from the domain. Also, you cannot remove cores if the corresponding cryptographic units are assigned to the domain.
When a domain is assigned virtual CPUs instead of cores, the whole-core constraint is disabled. You can only disable the whole-core constraint on an inactive domain, not on a domain that is bound or active. Before you disable the whole-core constraint on the control domain, you must first initiate a delayed reconfiguration.
Use the ldm add-vcpu number, ldm set-vcpu number, or ldm remove-vcpu number command to assign or remove virtual CPUs to and from a domain. number specifies the number of virtual CPUs and disables the whole-core constraint. For more information, see the ldm(1M) man page.
You can use the ldm add-vcpu number or ldm rm-vcpu number command on a domain that was previously configured with CPU cores. In that case, the existing number of CPU cores is automatically converted to the corresponding number of virtual CPUs.
Note - When you disable the whole-core constraint, the maximum core constraint is also automatically disabled.
The following example disables the whole-core constraint on the inactive ldg1 domain:
primary# ldm set-vcpu 1 ldg1
To enable the whole-core constraint on the control domain, the control domain must be in delayed reconfiguration mode. Enabling the whole-core constraint on the control domain only succeeds if sufficient CPU cores are available to meet the requested constraint. That is, unused cores, cores that are already used by the control domain, or cores that are partially used by the control domain must be available. Otherwise, the CPU allocation on the control domain remains unchanged.
Note - When the control domain is in delayed reconfiguration mode, the whole-core constraint and the setting of the number of cores also specifies the maximum number of cores.
The following example enables the whole-core constraint on the control domain (primary). First, initiate a delayed reconfiguration on the control domain. Next, assign one whole core to the control domain, and then reboot the domain to make the changes take effect.
primary# ldm start-reconf primary Initiating a delayed reconfiguration operation on the primary domain. All configuration changes for other domains are disabled until the primary domain reboots, at which time the new configuration for the primary domain also takes effect. primary# ldm add-vcpu -c 1 primary primary# reboot
This section describes the interactions between the whole-core constraint and the following features:
The whole-core constraint is fully compatible with CPU dynamic reconfiguration (DR). When a domain is defined with the whole-core constraint, you can use the ldm add-vcpu -c, ldm set-vcpu -c, or remove-vcpu -c command to change the number of cores on an active domain.
However, if a bound or active domain is not in delayed reconfiguration mode, its number of cores cannot exceed the maximum number of cores. This maximum is set with the maximum core constraint, which is automatically enabled when the whole-core constraint is enabled. Any CPU DR operation that does not satisfy the maximum core constraint fails.
The whole-core constraint is not compatible with dynamic resource management (DRM). When a DRM policy is enabled on a domain that uses the whole-core constraint, the policy is automatically disabled. The whole-core constraint remains enabled.
Even though a DRM policy cannot be enabled when the whole-core constraint is in effect, you can still define a DRM policy for the domain. Note that when a policy is automatically disabled, it still remains active. The policy is automatically re-enabled if the domain is restarted without the whole-core constraint.
The following are the expected interactions between the whole-core constraint and DRM:
If the whole-core constraint is set on a domain, a warning message is issued when you attempt to enable a DRM policy on that domain.
If a DRM policy is in effect on an inactive domain, you are permitted to enable the whole-core constraint on the domain. When the domain becomes active and the policy is enabled, the system automatically disables the DRM policy for the domain.
If a DRM policy is enabled on an active or bound domain, you are not permitted to enable the whole-core constraint.
CPU whole-core configuration is incompatible with domain migration. However, you can still migrate a domain that is configured with CPU whole cores. To restore the whole-core constraint after such a migration, stop the domain and reconfigure it for whole-core allocation.
The whole-core constraint is fully compatible with the power management (PM) performance and elastic modes. When elastic mode is enabled, the PM subsystem can add or remove CPU cores to or from domains that are configured with the whole-core constraint. In that case, the whole-core constraint continues to be honored, and domains that use that constraint remain configured only with whole cores.