2.2 What is Oracle VM Server?

Oracle VM Server can be installed on either x86 or SPARC hardware platforms. Since these platforms are fundamentally dissimilar, the hypervisor used on each platform is different. Oracle VM helps to abstract the hypervisor further by providing a user interface that facilitates the same logical actions across different server types. Much of this abstraction is provided by the Oracle VM Agent that is installed on each Oracle VM Server in the environment.

In this section, the way in which components run on these different hardware platforms and their roles are described in more detail. For more information on the different hardware platforms that are supported and the requirements to run an Oracle VM Server, refer to the Oracle VM Installation and Upgrade Guide.

More detailed coverage of Oracle VM Server is provided in Chapter 6, Understanding Server Pools and Oracle VM Servers.

2.2.1 What Hypervisors are used in Oracle VM?

The hypervisor present on each Oracle VM Server is an extremely small-footprint virtual machine manager and scheduler. It is designed so that it is the only fully privileged entity in the system. It controls only the most basic resources of the system, including CPU and memory usage, privilege checks, and hardware interrupts. Oracle VM Server for SPARC

On SPARC systems, the SPARC hypervisor is built into the SPARC firmware and is generally referred to as the Logical Domains Manager. If Oracle VM Server for SPARC has not been installed, the default operating system runs on top of the hypervisor transparently. When Oracle VM Server for SPARC is installed, the default operating system becomes the primary domain and tools are provided for the primary domain to manage how resources and hardware are allocated via the hypervisor to other domains.

As with the Xen hypervisor, each virtual machine is securely executed on a single computer and runs its own guest Oracle Solaris operating system. The SPARC hypervisor provides a broader range of virtualization features than the Xen hypervisor, due to the nature and design of SPARC hardware. Xen™

Oracle VM makes use of Xen technology, when running on x86 servers, taking advantage of the Xen hypervisor. The Xen hypervisor is a small, lightweight bare metal hypervisor for x86-compatible computers. The Xen hypervisor securely executes multiple virtual machines on one host computer. Each virtual machine runs in its own domain and has its own guest operating system with almost native performance. A primary management domain, called dom0, also runs as a guest on top of the hypervisor. See Section 2.2.2, “What are Domains?” for more information on domains. The Xen hypervisor was originally created by researchers at Cambridge University, and derived from work done on the Linux kernel.

Figure 2.2 Oracle VM Server Hypervisor and Guest Domains

2.2.2 What are Domains?

The terms "domain", "guest" and "virtual machine" are often used interchangeably, but they have subtle differences. A domain is a configurable set of resources, including memory, virtual CPUs, network devices and disk devices, in which virtual machines run. A domain or virtual machine is granted virtual resources and can be started, stopped and restarted independently of other domains or the host server itself. A guest is a virtualized operating system running within a domain. Multiple guests can run on the same Oracle VM Server, each within its own domain. Management Domain (dom0)

Most of the responsibility of hardware detection in an Oracle VM Server environment is passed to the management domain, referred to as domain zero (or dom0). On x86-based servers, the dom0 kernel is actually a small-footprint Linux kernel with support for a broad array of devices and file systems. In Oracle VM Server, the dom0 is tasked with providing a view of the system hardware available to the hypervisor. It also allows you to interact directly with the hypervisor to control access to resources as well as performing various tasks such as creating, destroying and controlling guest operating systems, and presenting those guests with a set of common virtual hardware. Other domains never interact with dom0 directly. Their requirements are handled by the hypervisor itself. Dom0 only provides a means to administer the hypervisor.

On SPARC-based servers, the management domain, usually referred to as the primary service domain or control domain, is created when the Logical Domains Manager is installed. If installed on an existing server that is not already configured for logical domains, the current Operating System automatically gets promoted to primary domain status. The primary domain runs an Oracle Solaris kernel and is responsible for the creation and management of all other domains. It is also responsible for providing access to virtualized hardware resources.

On systems running Oracle VM Server for SPARC, aside from the concepts of a "management domain" and of "guest domains", similar to "user domains", there are a variety of other domain-types that can run alongside the management domain. For instance, it is possible to set up multiple "service domains" that can act as network switches and virtual disk servers. Not all of these domain types are configurable using the Oracle VM Manager. Most importantly, it is possible to add a secondary service domain to your servers that can take over disk and network I/O in the case where the primary domain must be restarted. This allows running guest virtual machines to continue to access these resources even while the primary domain is unavailable. This topic is discussed in more detail within Configuring a Secondary Service Domain in the Oracle VM Administrator's Guide.

Supported Operations in the Management Domain (dom0)

Oracle VM Manager allows you to manage and configure your virtualization infrastructure, including the dom0. Manually modifying the dom0 can result in configuration issues for either Oracle VM Manager or Oracle VM Server, which can degrade performance or cause a loss of service.


Oracle does not support any changes that are made to the dom0 outside of Oracle VM Manager. Likewise, Oracle does not support running any third party applications within the dom0.

While it is possible to run hypervisor-specific commands directly on an Oracle VM Server from the shell, for example on x86 platforms you can run the Xen xm command and on SPARC you can run the ldm command, you should avoid these operations where it is possible to perform an operation using Oracle VM Manager. Using hypervisor tools directly can interfere with the Oracle VM Agent and may also result in Oracle VM Manager falling out of sync with the actual state of the environment. As a result, running hypervisor commands directly on an Oracle VM Server is generally unsupported. Exceptions to this rule may be applied when troubleshooting or when you have instruction to run a command directly by an Oracle support representative or within official documentation for Oracle VM.

In general, you should not perform any operations that modify the dom0 configuration. However, you can perform specific operations such as the following:

If you are in doubt whether an operation on the dom0 is supported, contact Oracle Support. Domains (domU)

Guest operating systems each have their own management domain called a "user domain", abbreviated to "domU". These domains are unprivileged domains with no direct access to the hardware or device drivers. Each domU is started alongside dom0 running on Oracle VM Server.


Under Oracle VM Server for SPARC these domains are usually referred to as "guest domains".

2.2.3 What is Oracle VM Agent?

The Oracle VM Agent is a daemon that runs within dom0 on each Oracle VM Server instance. Its primary role is to facilitate communication between Oracle VM Server and Oracle VM Manager. The daemon listens for connections from Oracle VM Manager on the TCP port 8899, and implements a messaging facility that allows Oracle VM Manager to connect to each Oracle VM Server instance and exchange information required for the efficient running of the entire Oracle VM infrastructure.

Oracle VM Agent is responsible for carrying out all of the configuration changes required on an Oracle VM Server instance, in accordance with the messages that are sent to it by Oracle VM Manager. This means that when a networking change is implemented in Oracle VM Manager, it is the Oracle VM Agent that reconfigures the server to cater for the change. Equally, if new storage is discovered and presented to a server in Oracle VM Manager, it is the Oracle VM Agent that handles the actual mount process required on the server.

Oracle VM Agent is also responsible for starting and stopping virtual machines as required by Oracle VM Manager. For this reason, the actual implementation of Oracle VM Agent differs significantly between different hardware platforms, even though actions within Oracle VM Manager are consistent across platforms.

For security reasons, the Oracle VM Agent must authenticate any system attempting to connect to it on port 8899. When an Oracle VM Server is not configured for any particular Oracle VM Manager it is in an unowned state. In this state, an Oracle VM Manager must take ownership of the server before it is able to communicate with the Oracle VM Agent. During the process where the Oracle VM Manager instance takes ownership of a server, the Oracle VM Manager authenticates using a password configured for the Oracle VM Agent. This password is exchanged over a connection that is secured using an SSL certificate. Once the Oracle VM Agent has authenticated Oracle VM Manager, an SSL key-certificate pair is set up to authenticate and encrypt all future communications between that Oracle VM Manager instance and the Oracle VM Agent. At this point, no other Oracle VM Manager instance or application can take control of the Oracle VM Server via the Oracle VM Agent. If you wish to allow another Oracle VM Manager instance to take ownership of the server, the original Oracle VM Manager instance must release ownership first.

There are also times when Oracle VM Agent must initiate a connection to Oracle VM Manager to signal an event or to provide statistical information. This is achieved using the Web Services API exposed by Oracle VM Manager via HTTPS on TCP port 7002.

Oracle VM Agent also maintains its own log files on the Oracle VM Server that can be used for debugging issues on a particular server instance or for auditing purposes.

Oracle VM Agent is discussed in more detail in Chapter 6, Understanding Server Pools and Oracle VM Servers.

2.2.4 What are Server Pools?

A server pool is a required entity in Oracle VM, even if it contains a single Oracle VM Server. In practice, several Oracle VM Servers form a server pool, and an Oracle VM environment may contain one or several server pools. Server pools are typically clustered, although an unclustered server pool is also possible.

Server pools have shared access to storage repositories and exchange and store vital cluster information in the server pool file system. Since server pools have shared access to storage repositories, live migration of virtual machines is possible for load balancing or for scheduled maintenance, so that a virtual machine can be moved from one Oracle VM Server to another without an interruption of service.

Within a clustered server pool, virtual machines have high availability or HA. The clustering technology used within Oracle VM can take care of monitoring the status of all of the Oracle VM Servers belonging to the server pool. If a pool member disappears for whatever reason, its virtual machines can be recovered and brought back up on another Oracle VM Server because all necessary resources are available on shared storage.

A detailed explanation of the purpose of a server pool and the technology used within one is provided in Chapter 6, Understanding Server Pools and Oracle VM Servers. What is a Master Server and a Virtual IP Address?

As of Oracle VM Release 3.4, the master server role and virtual IP address (VIP) are deprecated. However, because Oracle VM Manager can interact with previous releases of Oracle VM Server, the master server role and virtual IP address configuration are maintained for backwards compatibility but have no effect from Release 3.4 and later.

In versions of Oracle VM earlier than 3.4, Oracle VM Manager performed some operations for the entire server pool by communicating with a designated Oracle VM Server known as the master server. This server was configured with a virtual network interface and allocated an IP address within the management network known as the server pool virtual IP address. If the master server failed or went into maintenance mode, another Oracle VM Server in the server pool could assume this role and would automatically be configured with the virtual IP address.

This architecture has evolved in subsequent releases of Oracle VM, so that the master server has decreased in significance and Oracle VM Manager communicates directly with the Oracle VM Agent on every Oracle VM Server within the server pool.

The deprecation of the concept of a virtual IP address and master server for a server pool implies that various limitations have been imposed on server pool capabilities and some configuration options. The virtual IP address and master server is partially supported in Oracle VM Manager Release 3.4, specifically in the case where an instance of Oracle VM Server Release 3.3.x is added to an empty server pool or where a server pool already contains one or more instances of Oracle VM Server Release 3.3.x. However, the virtual IP address and master server do not apply to server pools that contain instances of Oracle VM Server Release 3.4 and later.