Recently, industry trade journals have announced Oracle's the ability to migrate Virtual Machines (VMs) safely and securely from one execution environment to another on SPARC T-based servers. Actually, the OracleVM Server for SPARC Data Sheet claims what might be considered rather run-of-the-mill for state-of-the-art server virtualization. Even assuming basic virtualization capabilities, the architecture of the Sun-cum-Oracle SPARC T processors do not lend themselves well to “tacking on” virtiualization and expecting low-overhead performance. If stuck with either unportable Solaris source code or SPARC binary images and one simply needs the code to run, albiet degraded, using OracleVM to host an old Solaris 8 VM on an SPARC T server could be a temporary solution. However, as for OracleVM and an SPARC T being a powerful virtualized consolidation platform, one needs to think twice. Here is why:
When considering server consolidation it soon becomes clear that without good planning, including adding multiple paths to network connections and storage spindles, having more than sufficient RAM (roughly, closing one's eyes and at least summing up what each stovepipe server used) and choosing an appropriate target execution architecture, problems soon arise. Modern conventional processors such as IBM POWER and Intel x86 were designed for wide instruction execution capability using compilers that extract maximum Instruction Level Parallelism. Effective execution of wide ILP code requires a processor design including advanced branch prediction, large out of order execution windows, large and extremely fast caches, enhanced with the ability to execute more than one execution thread per core -- simultaneously. A single 8-core IBM POWER7 processor, for example, can execute 32 threads all in the same clock tick. The latter is in contrast with Oracle's SPARC T processors that at any time execute only one thread per clock per core regardless of the number of tread contexts that are pending.
Modern, multi-threaded operating systems such as, AIX, Solaris, Linux, even Windows keep track of each thread context status, switch between threads on the order of milliseconds, enable prioritized thread preemption, task management and its switching, and paging in/out of virtualized memory. It is not a coincidence that processors that have cleaver branch prediction, large and sophisticated caching, fast clocks, large memory spaces, not only have the highest performance (such as seen on www.spec.org, etc) but are successful platforms for server consolidation.
If we reduce the execution clocks in these successful processors by a half, reduce the cache sizes by four or eight times, eliminate the L3 cache completely, reduce instruction execution width to one, remove any branch prediction, can we expect spectacular server consolidation performance with these nearly chocked processors? Not a chance! This characterizes the SPARC T processor. To be fair, there are applications that lends themselves to a processor that switches available thin thread contexts on L1 cache misses, but those are generally associated with applications such as specific web farms and functions such the UNIX dd command.
In virtualized environments, system RAM is extra virtual – operating system (via HW MMU) address translation and the hypervisor must satisfy and keep track of multiple VM address translation. Threads should not switch on an L1 cache miss, but rather when the VMs demand it. Even on the latest SPARC T3 processor, with 8KB instruction, 6KB data L1 cache sizes, and 16 cores sharing a 6MB L2 cache, cache thrashing and thread stalling must be tremendous in a virtualized environment.
In stark contrast, IBM PowerVM, is not only based on one of the highest performance processor architectures (IBM POWER7: 32KB L1, 256KB L2 and 8 cores sharing a 32 MB L3), but has the ability to virtualize each core into 10 logical processor increments – including the four simultaneously executing threads, create processor pools, cap or uncap logical domains, migrate domains without a single reported hypervisor security fault. Go to http://web.nvd.nist.gov/view/vuln/search and enter powervm, oraclevm, and vmware separately to see the current results.
An amusing example of how much Oracle cares about customer experiences with OracleVM for SPARC is how a simple question on its OracleVM blog (http://wikis.sun.com/display/SolarisLogicalDomains/LDoms+Community+Cookbook) has remained unanswered since 2008, but rather is filled with spam.