News, tips, partners, and perspectives for Oracle’s virtualization offerings

Oracle VM Server for SPARC Best Practices White Paper

Jeff Savit
Product Management Senior Manager
I'm very pleased to announce a new white paper has been published: Oracle VM Server for SPARC Best Practices.

This paper shows how to configure to meet demanding performance and availability requirements. Topics include:

  • Oracle VM Server for SPARC definitions, concepts and deployment options.
  • Software, hardware, and firmware requirements.
  • Best Practices for optimal performance.
  • Best Practices for resiliency and availability.

The paper includes specific recommendations, describes the reasons behind them, and illustrates them with examples taken from actual systems.

Join the discussion

Comments ( 6 )
  • guest Monday, October 20, 2014


    I find it interesting that for environments running multiple service domains you do not include some recommendations for guest console service.

    Let me explain; only the control domain can (as for other LDom configuration actions) change the console definition for a guest domain. It is possible to configure the (second) service domain to run a VCC service and therefore serve the console sessions for all the guests from that service domain. This, I would suggest, increase the availability of the guest consoles because if the primary domain is down the guest console is accessible (as normal in this config) from the service domain. If the service domain is down then the guest console can be reconfigured into the primary domain [unfortunately this requires a reboot of the guest].

    If this reasoning makes sense would it be possible at some future point to include this as a recommendation in an updated document ?



  • guest Monday, October 20, 2014

    Hi Ian,

    Nice to hear from you, and that's a good recommendation for the next revision of the document. I'm collecting suggestions already ;)

    regards, Jeff

  • Bob Netherton Friday, October 24, 2014

    Thanks for putting this reference document together, Jeff. The content is great, thorough with just the right amount of examples. Well done.

  • Jeff Friday, October 24, 2014

    Thanks for the kind words, Bob! I plan to keep this document "live" by updating it as information comes in, and as the technology advances - as "best practices" evolve too. -- Jeff

  • Sugimura Tuesday, November 18, 2014

    Thank you for your kind document. I translated it into Japanese and shared to my team.

    We have been having a trouble about disk I/O in these months. When we copy or move a large file in a primary domain or in a guest domain, it impacts this primary domain to slow down. We use a T5-2 server and Solaris 11.2, and we apply the CPU as 8 cores and the memory as 64 GB to the primary domain.

    We assume that the primary domain uses its swap gradually and it has been chattering with swapping in/out unintentionally.

    If you have suggestions, could you please give us any advises?

    Thank you and regards,


  • Jeff Wednesday, November 19, 2014

    Hello Sugimura,

    Thank you for your comment, and for taking the effort to translate the white paper.

    Regarding the performance issue you are seeing: you have a large primary domain in both CPUs and memory, but swapping is very bad for performance, especially for a control domain. If any service domain is short on memory, the virtual I/O rate it can provide will be reduced. Is it the case that 'vmstat 1' or 'vmstat -p 1' shows the free pages getting smaller, and that there is scanning (sr value not zero) or swapping? That would confirm a memory issue.

    Since it's a large memory size, I suspect that something is consuming large amounts of memory. You didn't say what the vdisk backends are, but perhaps you are using local ZFS - which could consume a lot of storage for ZFS caching. If that's the situation you probably should set a maximum size on the ZFS ARC cache. It's also possible that you have non-ZFS file systems, such as NFS mounted virtual disks in files, and that memory is being consumed by file cache. The command echo '::memstat' | /usr/bin/mdb -k would show how storage is distributed. You might also have some application in the control domain that is consuming memory (normally, applications are not run in the control domain to avoid situations like that).

    I hope this is helpful, Jeff

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.