Memory DR in Oracle VM Server for SPARC 2.0
By Eric S-Oracle on Oct 27, 2010
- Requests to remove sizable amounts of memory can take a considerable amount of time
- It is not guaranteed to successfully remove all the memory requested (a smaller amount can end up being removed)
- Removing memory that was in use at boot time results in the "leaking" of the memory that was used to hold the mappings for the removed memory, making that (much smaller but not insignificant amount of) memory unavailable until the domain is rebooted
While these restrictions implicitly connote a set of reasonable recommendations (e.g. avoid using memory DR to remove a significant portion of a domain's memory), there is a particular use-case that's especially problematic: shrinking the factory-default control domain in advance of creating guest domains. We strongly recommend against relying on memory DR for this purpose. Although it is tempting to try because it would eliminate the need to reboot the control domain to complete the process, the risks outweigh the benefits.
This issue and a procedure to avoid it are described in the Initial Configuration of the Control Domain section of the Oracle VM Server for SPARC 2.0 Administration Guide. I recommend folks read it in its entirety. In brief, it involves the use of a new CLI operation introduced in 2.0 to explicitly place the control domain into a delayed reconfiguration mode:
# ldm start-reconf primaryNote that if you don't explicitly execute this command before you attempt to resize the memory of the factory-default control domain (and you're running 2.0 with Solaris 10 Update 9 or later), memory DR will be invoked by default, potentially leading to the issues listed above. Caveat Emptor!