Skip Navigation Links | |
Exit Print View | |
Oracle VM Server for SPARC 2.2 Administration Guide Oracle VM Server for SPARC |
Part I Oracle VM Server for SPARC 2.2 Software
1. Overview of the Oracle VM Server for SPARC Software
2. Installing and Enabling Software
3. Oracle VM Server for SPARC Security
4. Setting Up Services and the Control Domain
How to Apply the Whole-Core Constraint
Interactions Between the Whole-Core Constraint and Other Domain Features
Tuning the SPARC CPU to Optimize Workload Performance on SPARC T4 Systems
CPU Threading Modes and Workloads
Selecting the CPU Threading Mode
Configuring the System With Hard Partitions
Checking the Configuration of a Domain
How to Determine Whether a Domain Is Configured With CPU Whole Cores
How to List the CPU Cores That Are Assigned to a Domain
Configuring a Domain With CPU Whole Cores
How to Create a New Domain With CPU Whole Cores
How to Configure an Existing Domain With CPU Whole Cores
How to Configure the Primary Domain With CPU Whole Cores
Interaction With Other Oracle VM Server for SPARC Features
CPU Dynamic Resource Management
Domain Migration Incompatibility
Assigning Physical Resources to Domains
Managing Physical Resources on the Control Domain
Restrictions for Managing Physical Resources on Domains
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 Power-Managed CPU Threads and Virtual CPUs
How to List Power-Managed CPU Threads
How to List Power-Managed CPUs
Using Dynamic Resource Management
How to Show Syntax Usage for ldm Subcommands
Utilization Statistic Definition
How to Show Software Versions (-V)
How to Generate a Long List (-l)
How to Generate an Extended List (-e)
How to Generate a Parseable, Machine-Readable List (-p)
How to Generate a Subset of a Long List (-o format)
How to List Constraints for One Domain
How to List Constraints in XML Format
How to List Constraints in a Machine-Readable Format
11. Managing Domain Configurations
12. Performing Other Administration Tasks
Part II Optional Oracle VM Server for SPARC Software
13. Oracle VM Server for SPARC Physical-to-Virtual Conversion Tool
14. Oracle VM Server for SPARC Configuration Assistant (Oracle Solaris 10)
15. Using the Oracle VM Server for SPARC Management Information Base Software
16. Logical Domains Manager Discovery
17. Using the XML Interface With the Logical Domains Manager
The CPU allocation mechanism uses the following constraints for CPU resources:
Whole-core constraint. This constraint specifies that CPU cores are allocated to a domain rather than to virtual CPUs. As long as the domain does not have the max-cores constraint enabled, the whole-core constraint is dynamic, which means that it can be added or removed by using the ldm set-core or ldm set-vcpu command, respectively. The domain can be inactive, bound, or active. However, there must be enough cores available to satisfy the request to apply the constraint. As a worst-case example, if a domain that shares cores with another domain requests the whole-core constraint, cores from the free list would need to be available to satisfy the request. As a best-case example, all the virtual CPUs in the core are already on core boundaries, so the constraint is applied without changes to CPU resources.
Maximum number of cores (max-cores) constraint. This constraint specifies the maximum number of cores that can be assigned to a bound or active domain.
Note - The max-cores property cannot be altered unless the domain is stopped and unbound, or the control domain is placed in a delayed reconfiguration. So, to increase the maximum number of cores from the value specified at the time the whole-core constraint was enabled, you must first stop and unbind the domain.
It is best to ensure that the control domain has the whole-core constraint enabled prior to setting the max-cores constraint.
# ldm set-core 1 primary
# ldm ls -o re primary
Notice that max-cores is set to unlimited. As is the case with any domain, the control domain cannot be used in conjunction with hard partitioning until the max-cores constraint is enabled.
# ldm start-reconf primary
# ldm set-domain max-cores=number-of-CPU-cores primary
Note - The cryptographic units that are associated with those cores are unaffected by core additions. So, the system does not automatically add the associated cryptographic units to the domain. However, a cryptographic unit is automatically removed only when the last virtual CPU of the core is being removed. This action prevents a cryptographic unit from being “orphaned.”
You can only disable the max-cores constraint on an inactive domain, not on a domain that is bound or active. Before you disable the max-cores constraint on the control domain, you must first initiate a delayed reconfiguration.
# ldm ls -o re primary
# reboot
Upon reboot, you can use the control domain with hard partitioning.
Example 10-1 Applying the Whole-Core Constraint
This example shows how to apply the whole-core constraint on the primary domain. The first command applies the constraint, while the second command verifies that it is enabled:
# ldm set-core 1 primary # ldm ls -o re primary NAME primary CONSTRAINT cpu=whole-core max-cores=unlimited threading=max-throughput
The following commands constrain max-cores to three cores by initiating a delayed reconfiguration, setting the max-cores property, and verifying that the constraint is enabled:
# 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 will also take effect. # ldm set-domain max-cores=3 primary ------------------------------------------------------------------------------ Notice: The primary domain is in the process of a delayed reconfiguration. Any changes made to the primary domain will only take effect after it reboots. ------------------------------------------------------------------------------ # ldm ls -o re primary NAME primary FLAGS normal,delayed(modify),control,vio-service CONSTRAINT cpu=whole-core max-cores=3 threading=max-throughput
Upon reboot, you can use the control domain with hard partitioning.
The following example removes the max-cores constraint, but leaves the whole-core constraint on the ldg1 domain:
# ldm set-domain max-cores=unlimited ldg1
To remove both the max-cores constraint and the whole-core constraint from the ldg1 domain, assign virtual CPUs instead of cores as follows:
# ldm set-vcpu 8 ldg1
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-core, ldm set-core, or ldm remove-core 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. After such a migration, hard partitioning is not enforced on the target system. Also, the whole-core configuration and the maximum number of CPU cores are not preserved on the target system.
If you migrate a domain that is configured with whole cores, you must reconfigure the target domain to use hard partitioning after the migration completes. Also, you must ensure that your license agreement permits you to use the domain on both the source and target systems.
The whole-core constraint is fully compatible with the power management (PM) performance and elastic policies. When the elastic policy is in effect, 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.