The Role of Oracle VM Server for SPARC In a Virtualization Strategy

by Matthias Pfützner

Overview of hardware and software virtualization basics, and the role that Oracle VM Server for SPARC plays in a virtualization strategy.

Published August 2012 (reprinted from eStep blog)

Part 8 - Oracle Enterprise Manager Ops Center as a Management Tool for Virtualization
Part 7 - The Role of Oracle Virtual Desktop Infrastructure in a Virtualization Strategy
Part 6 - Oracle VM VirtualBox - Personal Desktop Virtualization
Part 5 - Network Virtualization and Network Resource Management
Part 4 - Resource Management as an Enabling Technology for Virtualization
Part 3 - The Role of Oracle Solaris Zones and Linux Containers in a Virtualization Strategy
Part 2 - The Role of Oracle VM Server for x86 in a Virtualization Strategy
Part 1 - The Role of Oracle VM Server for SPARC in a Virtualization Strategy
Want technical articles like this one delivered to your inbox?  Subscribe to the Systems Community Newsletter—only technical content for sysadmins and developers.

In this article, we will discuss hardware, desktop, and operating system virtualization. We'll also discuss various Oracle virtualization technologies, including Oracle VM Server for SPARC.

Some Basics
Hardware Virtualization
Operating System Virtualization
Desktop Virtualization
Oracle VM Server for SPARC Functionality and Benefits
See Also
About the Author

Some Basics

But first, let's discuss what virtualization means. Wikipedia describes it this way:

"Virtualization, in computing, is the creation of a virtual (rather than actual) version of something, such as a hardware platform, operating system, a storage device or network resources."

Virtualization areas can be categorized into the following layers:

  • Hardware
  • Desktop
  • Software (including the operating system)
  • Memory
  • Storage
  • Data
  • Network

This article will not cover software virtualization beyond the OS level, but here are some examples of software virtualization:

  • Application servers are a means of virtualizing an application by spreading the task of running an application (or a business transaction or many such parallel transactions) across multiple instances of the application that possibly are spread across multiple physical servers.
  • Even some of the original internet software protocols allowed for software virtualization, for example, by defining MX records (a list of servers for internet mail exchange—not to be confused with Microsoft's e-mail program named Microsoft Exchange) in the DNS (Domain Name System, the directory of all servers on the internet), since secondary servers can be useful if the primary servers are not reachable.
  • Also, an Oracle Real Application Clusters (Oracle RAC) implementation can be seen as software virtualization, because it allows for the distribution of a task across multiple Oracle RAC instances, multiple servers, or both.

So, there is a broad range of software virtualization technologies.

Before we dive into hardware virtualization, we need to cover the following virtualization concepts:

  • Full virtualization. Wikipedia has a complete article on that, but for our purposes, it should be sufficient to define it as a technology that abstracts the underlying layers 100 percent, so the layer and its interfaces can be 100 percent similar. So "stuff" being programmed (for example, an operating system or an application), has no need to know anything about the different implementations of the underlying layers. This enables easy migration from one fully virtualized environment into another fully virtualized environment.
  • Paravirtualization. Again, we have something from Wikipedia, but suffice it to say that paravirtualization differs from full virtualization in that it might expose some of the underlying elements directly. Different paravirtualization implementations might differ in ways that make portability harder, because the upper layers need to understand these differences. However, directly exposing some of the underlying elements can be used to better serve specific needs. Therefore, paravirtualization adds to the upper layers of a stack specifics about the technology being virtualized. Typically, this increases the efficiency of the virtualization because it often eliminates latency, which might be increased with full virtualization. On the other hand, knowledge about and use of the underlaying virtualization technology makes it harder to later change to another virtualization technology.

Now let's define the term hypervisor. Again, Wikipedia has a full article on that, but suffice it to say that a hypervisor is the layer that abstracts the underlying elements so that the stuff above the hypervisor doesn't know what's underneath and sees only the interfaces exposed by the hypervisor. You could also call the hypervisor a virtual machine manager, and, yes, this also is possible on different levels of the stack.

There are several different types of hypervisors:

  • Thick hypervisor versus thin hypervisor. Every hypervisor needs to be configured and managed. If a hypervisor contains configuration tools that are accessible via interfaces for configuring itself, we call it a thick hypervisor. In contrast, if a hypervisor must be configured and managed by an external entity, we call it a thin hypervisor.
  • Type 1 hypervisor versus Type 2 hypervisor. A Type 1 hypervisor runs directly on top of some hardware, whereas a Type 2 hypervisor requires an already running operating system and runs inside that operating system.

Hardware Virtualization

Again, Wikipedia has an article.

Oracle offers SPARC- and x86-based systems, and the following virtualization technologies can be used on these systems:

  • On Oracle's SPARC Enterprise M-Series servers: Dynamic System Domains
  • On Oracle's SPARC T-Series servers: Oracle VM Server for SPARC (aka Logical Domains)
  • On Oracle's x86-based systems: Oracle VM Server for x86 and Oracle VM VirtualBox

Oracle VM Server for SPARC and Oracle VM Server for x86 are Type 1 hypervisors. Oracle VM VirtualBox is a Type 2 hypervisor.

Operating System Virtualization

If we move up the stack to look at what's available from the operating system, once again, Wikipedia has a relevant article.

Operating system virtualization provides applications with a secure and isolated runtime environment that acts like an exclusive OS instance but shares some operation system resources, such as devices and the kernel. Resource management is needed if operating system virtualization is used.

Before we dive deeper, here are the different operating systems that can run on the different types of Oracle hardware:

  • On Oracle's SPARC Enterprise M-Series servers: Oracle Solaris
  • On Oracle's SPARC T-Series servers: Oracle Solaris
  • On Oracle's x86-based systems: Oracle Solaris, Linux, or Microsoft Windows

For Oracle Solaris 11, the virtualization technology is called Oracle Solaris Zones (in Oracle Solaris 10, it was called Oracle Solaris Containers).

Desktop Virtualization

Another major area of virtualization centers around the desktop.

First, let's define what a desktop is. Wikipedia has two relevant articles on that: one on desktop virtualization and one on desktop environments. Let's stick to this definition: A desktop is what a person sees on his computer monitor and interacts with using a keyboard and mouse.

Desktop virtualization describes technologies that separate the "provider of the desktop" from the system that controls the monitor, keyboard, and mouse.

Oracle VM Server for SPARC Functionality and Benefits

Oracle VM Server for SPARC is a thin Type 1 hypervisor that performs hardware virtualization on SPARC T-Series servers and uses paravirtualization. As a result, Oracle VM for SPARC provides a technology for running multiple logical domains on one system. Each domain runs its own operating system and is independent from the other logical domains.

To put this into perspective, Figure 1 summarizes what we've discussed so far.

Figure 1

Figure 1. Oracle Virtualization Technologies and Products

In Figure 1, we can see that there is a similar product called Oracle VM Server for x86. Some of the general remarks made here for Oracle VM Server for SPARC also apply to Oracle VM Server for x86.

In looking back at the definition of a thin Type 1 hypervisor, it's clear that there needs to be some explanation about how a logical domain can be managed and set up. We know we need an external entity to manage the hypervisor, because that is one of the characteristics of "thin." The other characteristic of Oracle VM Server for SPARC is "Type 1," which implies that the hypervisor runs directly on the hardware. Let's first look at the hypervisor.


You might have already come across a SPARC T-Series system, because those started years ago with the Sun Fire T1000 server and they continue today with Oracle's SPARC T4-4 server. All share the same hypervisor, but you might never have dealt with, saw, or experienced it. That's due to the fact that in SPARC T-Series systems, the hypervisor is part of the system itself; it is "hidden" in the OBP (Open Boot PROM), which can roughly be compared to the BIOS on x86-based systems. So, in contrast to most hypervisors on x86-based systems, here, we do not need to install additional software. Nevertheless, it's a good idea to check the OBP version, because there can be changes and updates that add new features.

If you are using a SPARC T-Series system and you never subdivided it into logical domains, you're running in a big logical domain that simply uses all the available hardware. That can be used as proof for the maturity and stability of the hypervisor in the SPARC T-Series systems.


I mentioned that an external entity needs to manage a thin hypervisor, because management is not part of the hypervisor itself. For SPARC T-Series systems, management is done by a guest on top of the hypervisor, so the systems can be used without a large, external management framework (however, they can be managed by a large external framework, if desired).

Every OS running on a SPARC T-Series system runs on top of a hypervisor, because the hypervisor is part of the OBP; therefore, every OS is a guest on top of the hypervisor in a SPARC T-Series system. So, in order to create the management system, we only need to start the relevant control daemons in the already running OS, assign specific virtual CPUs to be used for this "control domain," configure the virtual network and storage devices, and reboot. Once that's done, the non-used, no-longer-used, and freed hardware can be used to create additional logical domains. The whole process is described in detail in the Oracle VM for SPARC documentation.


Oracle VM Server for SPARC performs the subdividing or partitioning of a system on logical boundaries, such as a thread in a core in a CPU, and it divides the I/O resources through I/O services or by assigning I/O devices. Therefore, it is possible to have more logical domains than physical devices, which leads to sharing of devices between logical domains. This sharing can happen with the network interfaces, the boot disks, or the storage HBAs. To manage these items, you can create specific I/O domains. You can also create the domains in a redundant, highly available setup. Another thing to keep in mind is that when a single physical device is shared among separate domains, the domains can influence the throughput of the underlying single physical device. Therefore, techniques such as using the network virtualization features in Oracle Solaris 11 can help define the quality of service attributes for a specific domains.

Types of Domains

There are different types of domains, and having a general understanding of these different types is important for getting an idea of how Oracle VM Server for SPARC works.

  • Control domain: This domain runs the Logical Domain Manager and allows you to create and manage other logical domains and allocate virtual resources to other domains. There is always only one control domain per server, and it is named primary.
  • Service domain: This domain provides virtual device services—such as a virtual network switch, a virtual console concentrator, or a virtual disk server— to other domains. By creating more than one service domain, you can create I/O redundancy. At least one service domain is required; in many basic setups, the control domain is also the service domain.
  • I/O domain: This is a domain that has direct ownership of and direct access to physical I/O devices, such as a network card. This domain can be part of the control domain.
  • Guest domain: This domain is managed by the control domain and uses services from the I/O domain, the service domains, or both.

Figure 2 provides a general picture of Oracle VM Server for SPARC.

Figure 2

Figure 2. Oracle VM Server for SPARC Architecture

Things to Consider

From descriptions above we can see that building and architecting virtualized environments might become complex and, therefore, careful planning guarantees the best long-term usage of a created architecture.

Still, there's another big point to keep in mind. With Moore's Law and the fact that software needs don't grow as quickly as hardware gets faster, there are many opportunities to consolidate older environments onto fewer—but more powerful—new systems. Oracle's SPARC T4 processor-based systems provide the right solution for these consolidation tasks.

The benefits of Oracle VM Server for SPARC include the following:

  • No additional software is needed.
  • No additional licenses are needed.
  • The hypervisor adds no overhead.
  • Oracle VM Server for SPARC is fully supported by Oracle Solaris.
  • Physical-to-virtual migration/conversion tools are available.
  • Fine-grained subdivision of multi-CPU and multicore systems (up to 128 logical domains per physical system) is possible.
  • Cold, warm, and hot (live) migration is possible.
  • Oracle VM Server for SPARC is accepted as a licensing-limit/boundary by Oracle.
  • Oracle VM Server for SPARC provides support for and is supported by Oracle Solaris Cluster.


Oracle VM Server for SPARC is a proven, mature, stable virtualization technology on Oracle's SPARC T-Series systems. With the advent of Oracle's SPARC T4 processor-based systems, even the "performance" of the CPU can compete with the performance of x86-based virtualization environments. Oracle VM Server for SPARC is fully integrated and, therefore, it is easy to deploy, manage, and use.

See Also

Oracle VM Server for SPARC Website

About the Author

Matthias Pfützner worked at Sun Microsystems and Oracle from 1998 until 2012, and he now works for AppSense. During his 14 years in the Professional Services and Presales groups at Sun and Oracle, he supported technologies such as clustering, provisioning, systems management, virtualization, and cloud computing for customers such as Deutsche Bank, Deutsche Telekom, Vodafone, and Daimler Chrysler. As one of approximately a hundred worldwide Principal Field Technologists at Sun and Oracle, he helped define and shape these technologies, influenced IT businesses around the world, and gave many presentations at conferences and customer meetings.

Matthias would like to thank Uwe Strahlendorf and Detlef Drewanz for the invaluable feedback they provided for this article.

Revision 1.0, 08/14/2012

See sysadmin-related content for all Oracle technologies by following OTN Systems on Facebook and Twitter.