How does dynamic CPU reallocation work?
In the world of high-availability infrastructure—specifically within Oracle VM Server for SPARC and Exadata—Dynamic CPU Reallocation is the ability to move processing power between virtual machines (Logical Domains) or workloads in real-time without a reboot.
It turns your hardware into a "fluid" resource that can flow to wherever the demand is highest.
Dynamic reallocation is managed by the Hypervisor (the firmware layer in SPARC or the KVM/OVM layer in x86). Because the OS kernel is "virtualization-aware," it can handle the sudden appearance or disappearance of processors.
When you trigger a reallocation, the Hypervisor performs a "handshake" with the Guest OS:
Addition: The Hypervisor assigns new physical hardware threads to the VM. The OS "sees" a new CPU online and immediately starts scheduling processes on it.
Removal: The Hypervisor asks the OS to stop scheduling tasks on specific threads. Once the OS clears the "run queue" for those threads, the Hypervisor unbinds the hardware.
Oracle VM Server for SPARC uses a feature called DRM. This allows the system to act automatically based on a set of defined policies.
Utilization Thresholds: You can set a policy that says: "If LDom_A reaches 90% CPU utilization for more than 5 minutes, take 2 cores from LDom_B and give them to LDom_A."
Priority Levels: You can designate a "Production" domain as high priority. If it needs more power, the system will automatically strip resources from "Development" or "Test" domains to satisfy the demand.
The way the reallocation happens depends on how the domain was built:
The system moves individual hardware threads. This is highly granular but can lead to "cache fragmentation" if a single domain's threads are scattered across many different physical cores.
The system moves the entire physical core (all threads). This is preferred for databases because it maintains cache affinity. When a core moves, the L1 and L2 cache contents move with the context of that core, ensuring the performance doesn't "dip" during the transition.
Handling Cyclic Workloads: Many businesses have "Daily Peaks" (e.g., 9:00 AM logins) or "Monthly Peaks" (Payroll processing). You can shift 80% of the server's power to the Payroll LDom for one day, then shift it back to the web servers the next day.
Hardware Maintenance: If you need to perform maintenance on a specific part of a processor, you can dynamically migrate workloads to other cores without taking the applications offline.
Cost Efficiency: It prevents "Server Sprawl." Instead of buying two medium-sized servers for two different apps, you buy one large server and let the apps "trade" CPU power as needed.
| Step | Action | Impact |
| Monitor | The Control Domain tracks CPU % across all LDoms. | None. |
| Trigger | A threshold is hit (e.g., 85% load). | Policy evaluation. |
| Execute | ldm set-vcpu command is issued (manual or auto). | Threads are reassigned in firmware. |
| Integration | Solaris/Linux Kernel detects new CPU resources. | Instant performance boost. |
Dynamic CPU Reallocation eliminates the need for "over-provisioning." You no longer have to build every VM for its maximum possible peak; you build for the average and let the Dynamic Resource Manager handle the spikes.