We've just released Oracle VM Server for SPARC 2.2! This release contains some major new features, along with numerous other improvements and (of course) bug fixes. I'll only briefly highlight the key new features here; visit Oracle's Virtualization Blog for more information on this release, including where to download the software, getting access the documentation, and providing pointers to blogs describing other features in the release. In this post, I'm going to focus on the improvements we've made in configuring your VMs using whole-core allocation.
First, the major new features:
- Cross-CPU live migration - Now migrate between T-series systems of different CPU types & frequencies
- Single-root I/O virtualization (SR-IOV) on Oracle's SPARC T3 and SPARC T4 platforms
- Improved virtual networking performance through explicit configuration of extended mapin space
In addition, 2.2 includes two features first introduced via updates to 2.1: dynamic threading on the SPARC T4 processor, and support for the SPARC SuperCluster platform.
Whole core allocation improvements
In Oracle VM Server for SPARC 2.0, we introduced the concept of whole-core allocation, allowing users to optionally allocate CPU resources at the core, rather than strand, granularity. This feature was designed primarily to allow customers to be in compliance with Oracle's "Hard Partitions" CPU licensing requirements. As such, it included the following restrictions:
- Existence and enforcement of a cap on the number of cores that could be allocated to a domain. This cap was set implicitly the first time whole-core allocation was requested for a domain.
- Severe restrictions on when & how whole-core allocation mode can be entered & exited, and when the cap can be modified. In most cases, the domain needed to be stopped and unbound before effecting these changes.
Since introducing this capability, we've heard from several customers who want to use whole-core allocation, but for the purposes of improved performance and manageability, not for complying with the hard-partitioning licensing requirement. They found the existing CLI semantics untenable for their needs. Particular concerns raised included:
- Inability to configure whole-core without a cap
- Difficulty in changing the value of the cap
- The requirement to stop & unbind the domain to enable/disable whole-core allocations
In response to these issues, we've enhanced the CLI options for managing whole-core allocations in this release. These new options allow you to enable whole-core allocation granularity without the onerous restrictions necessitated by the hard-partitioning CPU licensing requirements. Here's what we did:
- Provided new, separate CLI options for enabling whole-core allocation and for adding/setting/removing a cap
- Removed the restrictions on when you can switch in and out of whole-core mode, as long as no cap is set
Customers can continue to use the original whole-core CLI we introduced in 2.0 to comply with the hard partitioning requirements (we've not changed the semantics of those operations at all). However, we do recommend everyone migrate to these new CLI options, as they're clearer, more flexible, and suitable whether you're looking for whole-core allocation to meet the hard-partitioning requirement or solely for the other benefits of allocating cpu resources at the whole-core granularity. The key determining factor is whether or not you configure a cap on the number of cores in the domain; if you do, you're in compliance with the hard-partitioning licensing requirements, and incur the restrictions outlined above. If you configure whole-core allocation without a cap, we assume you're not interested in compliance with those terms, and are not bound by its restrictions.
Here is a brief synopsis of the new CLI options. For full details consult the Oracle VM Server for SPARC 2.2 Reference Manual (or the ldm(1M) man page if you have 2.2 installed).
To configure whole-core allocation with no cap:
ldm add-core num ldom
ldm set-core num ldom
ldm remove-core [-f] num ldom
To configure a cap for a domain separately from allocating cores to the domain:
ldm add-domain ... [max-cores=[num|unlimited]] ldom
ldm set-domain ... [max-cores=[num|unlimited]] ldom