Chapter 2 Oracle VM Overview

Table of Contents

In this chapter we deliver a complete overview of the architecture of an Oracle VM deployment. Each component type is discussed to provide an adequate understanding of the platforms involved, the technologies used and the connections between components to provide the entire Oracle VM platform.

2.1 What is the Oracle VM Architecture?

Oracle VM is a platform that provides a fully equipped environment with all the latest benefits of virtualization technology. Oracle VM enables you to deploy operating systems and application software within a supported virtualization environment. Oracle VM insulates users and administrators from the underlying virtualization technology and allows daily operations to be conducted using goal-oriented GUI interfaces. The components of Oracle VM are shown in Figure 2.1, “Oracle VM Architecture”.

Figure 2.1 Oracle VM Architecture
Oracle VM architecture. Shows the Oracle VM Manager Web Interface, management server and database on one computer. Also shows Oracle VM Server, hypervisor, and host computer hardware on another computer.
Click to view larger image ovm3arch.png

  • Client Applications: Various user interfaces to Oracle VM Manager are provided, either via the graphical user interface (GUI) accessible using a web-browser; the command line interface (CLI) accessible using an SSH client; or external applications, such as Oracle Enterprise Manager, custom built applications or scripts that use the Web Services API (WS-API). All communications with Oracle VM Manager are secured using either a key or certificate based technology.

  • Oracle VM Manager: Used to manage Oracle VM Servers, virtual machines, and resources. It is comprised of a number of subcomponents, including a web browser-based user interface; and a command line interface (CLI) allowing you to manage your infrastructure directly from the command line either via external scripts or by running manual command sequences. Each of these interfaces run as separate applications and interface with the Oracle VM Manager core application using the Web Services API.

    Oracle VM Manager is usually hosted on a standalone computer but it can also be run as a virtual machine in a carefully designed environment. However, support for running Oracle VM Manager on a virtual machine is limited and caveats apply. For more information, see the Running Oracle VM Manager as a Virtual Machine section of the Oracle VM Installation and Upgrade Guide.

    The Oracle VM Manager core application is an Oracle WebLogic application that runs on Oracle Linux. The user interface uses the Application Development Framework (ADF) application, providing a common look and feel, in line with other Oracle web-based applications. While the Oracle VM Manager core application and the Oracle VM Manager Web Interface are both WebLogic applications, they are separate applications, even though they share the same process space.

    While the Oracle VM Manager Web Interface and Oracle VM Manager Command Line Interface both use the Web Services API to interface with the Oracle VM Manager core application, the Oracle VM Manager Web Interface can query the Oracle VM Manager database directly for read-only operations. This design decision allows the Oracle VM Manager Web Interface to provide a wider range of filtering options and improves performance for some operations.

    Oracle VM Manager communicates with each Oracle VM Server via the Oracle VM Agent, using XML-RPC over HTTPS on port 8899. Actions on servers that are initiated within Oracle VM Manager are triggered using this method. The Oracle VM Agent on each Oracle VM Server is equally able to send notifications, statistics and event information back to Oracle VM Manager. Actions within Oracle VM Manager triggered by Oracle VM Agent are achieved using the Web Services API exposed by Oracle VM Manager and are secured using HTTPS.

    While Oracle VM Manager is a critical component for configuration actions within the Oracle VM infrastructure, the virtualized environment can continue to function properly even if Oracle VM Manager experiences downtime. This includes the ability to maintain high availability and to perform live migration of virtual machines running on an x86 platform. Note that live migration of virtual machines running on a SPARC platform, does require that the Oracle VM Manager is running to succeed, since the only supported method of performing a live migration on this platform is either through the Oracle VM Manager Web Interface or the Oracle VM Manager Command Line Interface.

  • Oracle VM Manager Database: Used by the Oracle VM Manager core application to store and track configuration, status changes and events. Oracle VM Manager uses a MySQL Enterprise database that is bundled in the installer and which runs on the same host where Oracle VM Manager is installed. The database is configured for the exclusive use of Oracle VM Manager and must not be used by any other applications. The database is automatically backed up on a regular schedule, and facilities are provided to perform manual backups as well.

  • Oracle VM Server: A managed virtualization environment providing a lightweight, secure, server platform which runs virtual machines, also known as domains. At least one Oracle VM Server is required, but several are needed to take advantage of clustering.

    Oracle VM Server is installed on a bare metal computer, and contains the Oracle VM Agent to manage communication with Oracle VM Manager. dom0 is an abbreviation for domain zero, the management or control domain with privileged access to the hardware and device drivers. DomU is an unprivileged domain with no direct access to the hardware or device drivers. A user-domain (domU) is started and managed on an Oracle VM Server by dom0.

    On x86-based systems, Oracle VM Server is based upon an updated version of the underlying Xen hypervisor technology, and includes Oracle VM Agent. It also includes a Linux kernel with support for a broad array of devices and file systems. The Linux kernel is run as dom0 to manage one or more domU virtual machines, each of which could be Linux, Oracle Solaris, or Microsoft Windows™.

    In contrast, Oracle VM Server for SPARC takes advantage of the hypervisor that is already included within the SPARC firmware, alongside the Oracle VM Agent for SPARC. The default Oracle Solaris operating system is usually promoted to act as the primary domain, which is equivalent to dom0 on x86 systems. Once the primary domain is in place, it can be used to create and manage further domains running different versions of the Oracle Solaris operating system.

    Groups of Oracle VM Servers are usually clustered together to create server pools. This allows Oracle VM Manager to handle load balancing and failover for high-availability environments. Virtual machines run within a server pool and can be easily moved between the different servers that make up a server pool. Server pools also provide logical separation of servers and virtual machines. Server pools are required entities within the Oracle VM infrastructure, even if they consist of only one server.

    Each Oracle VM Server maintains its own Berkeley Database, used to store local configuration and runtime information. This allows the Oracle VM Server to continue to function normally, even if Oracle VM Manager becomes unavailable for a period. Where Oracle VM Servers are clustered together, a separate cluster database, stored in the server pool file system, is shared between the servers. This allows the server pool to continue to provide clustering features, such as High Availability, even if Oracle VM Manager is unavailable.

  • External Shared Storage: Provides storage for a variety of purposes and is required to enable high-availability options afforded through clustering. Storage discovery and management is achieved using the Oracle VM Manager, which then interacts with Oracle VM Servers via the storage connect framework to then interact with storage components. For morre information, see the Understanding Storage chapter of the Oracle VM Concepts Guide. Oracle VM provides support for a variety of external storage types including NFS, iSCSI and Fibre Channel.

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.

2.2.1.1 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.

2.2.1.2 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
Oracle VM Server runs a hypervisor that communicates directly with the system hardware. Virtual machines run as domains on top of the hypervisor. Guest operating systems are installed within each domain. A primary domain called dom0 is created as a management domain, and is used to manage and provision the hypervisor.
Click to view larger image ovm_arch_hypervisor.png

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.

2.2.2.1 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.

Important

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.

2.2.2.2 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.

Note

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.

2.2.4.1 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.

2.3 What is Oracle VM Manager?

Management for the Oracle VM environment is provided by Oracle VM Manager, a transaction-based framework that also includes an integrated database, a web-based management user interface and a command line interface. Because Oracle VM can continue to function normally even during periods of downtime for the Oracle VM Manager, high-availability and redundancy are not generally required for Oracle VM Manager.

Oracle VM Manager is a multi-user application with multiple interfaces. It is best practice for multiple users to not make configuration changes concurrently. However, it is possible for two users to simultaneously configure an object in the environment. When this occurs, Oracle VM Manager takes the first change that enters the queue, locks the object, and then applies the new configuration. The second configuration change on the object fails because it is based on stale information. Oracle VM Manager then returns an error message to the user who submitted the second configuration change. The user must refresh the object and resubmit the change, if necessary.

The architecture of Oracle VM Manager is composed of various inter-related components. The fundamental components are the Oracle VM Manager application itself and the Oracle VM Manager database.

2.3.1 Oracle VM Manager Core Application and API

The Oracle VM Manager core application is a Java-based Oracle WebLogic application that is usually installed on a dedicated system.

The Oracle VM Manager core application lets you configure, monitor and manage the Oracle VM environment through direct communication with the Oracle VM Agent on each Oracle VM Server in the environment. The Oracle VM Manager core application also stores all configuration information and event data within the Oracle VM Manager database.

The Oracle VM Manager core application provides an API that allows other components to interface with it. As of Oracle VM Release 3.3.1, this API is implemented as a Web Services API that provides a REST interface to the Oracle VM Manager. The Oracle VM Manager Web Interface and Oracle VM Manager Command Line Interface both use this API to interact directly with the Oracle VM Manager core application.

The Web Services API exposed by the Oracle VM Manager core application makes it possible to programmatically set up and manage an Oracle VM environment. For more information, see Oracle VM Web Services API Developer's Guide.

2.3.2 Oracle VM Database Repository

The Oracle VM Manager database stores configuration information and event data. The actual database management server is a MySQL Enterprise database that is bundled with the Oracle VM Manager installer.

The MySQL database is set up using bundled database software included and licensed for use with Oracle VM Manager. The database management server is installed on the same system as the Oracle VM Manager core application and is intended only for use by this application. Particular configuration parameters specific to the requirements of Oracle VM Manager are applied to this installation.

Details on the installation of the database are covered in the Oracle VM Installation and Upgrade Guide, while database backups are explained in more detail in Oracle VM Administrator's Guide.

2.3.3 Oracle VM Manager Web-Based User Interface

The Oracle VM Manager Web Interface is a web-based application built on top of Oracle WebLogic and Application Development Framework (ADF). The Oracle VM Manager Web Interface is installed on the same system and shares the same Oracle WebLogic Server domain as the Oracle VM Manager core application, but is a separate application. By default, the graphical user interface is accessed over HTTPS on the TCP port 7002.

The Oracle VM Manager Web Interface, its configuration and usage are described in detail in the Oracle VM Manager User's Guide.

2.3.4 Oracle VM Manager Command Line Interface

The Oracle VM Manager Command Line Interface is a Java-based daemon that runs on the system where Oracle VM Manager is installed. Access to the CLI is provided via an SSH connection available on a customizable TCP port, set to TCP 10000 by default. Any SSH client can be used to access the CLI, which provides its own shell and supports SSH key-based authentication.

The Oracle VM Manager Command Line Interface enables administrators to manage the entire Oracle VM environment from the shell, and facilitates programmatic setup and control of an environment through the use of simple shell or Expect scripts. Every action that is available via the Oracle VM Manager Web Interface is also available via the CLI.

As an independent component of the Oracle VM Manager suite of applications, the Oracle VM Manager Command Line Interface can be disabled if it is not required within an environment.

Full usage of the Oracle VM Manager Command Line Interface, including syntax and examples, is covered in the Oracle VM Manager Command Line Interface User's Guide.

2.3.5 Oracle VM Utilities

The Oracle VM Utilities are a collection of command line scripts that allow you to perform basic management tasks in an Oracle VM environment. Some of the management tasks you can perform with the Oracle VM Utilities include the following:

As of Oracle VM Release 3.4, most of the Oracle VM Utilities are either obsolete with native features in Oracle VM or deprecated by the Oracle VM Manager Command Line Interface. You can find out more about the Oracle VM Utilities, including how to download and install, in the Oracle VM Administrator's Guide. See Using the Oracle VM Utilities.

2.4 What is an Oracle VM Guest?

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 user-domain (domU) is granted virtual resources and can be started, stopped and restarted independently of other domains and of the host server itself. As a result, a configuration change applied to the virtual resources of a domU does not affect any other domains; and a failure of the domU does not impact any other domains. A guest is a virtualized operating system running within a domain.

Oracle VM is designed for the purpose of running multiple guests in a virtualized environment, while providing the tools to easily manage, configure and maintain the virtual machines that guests run on. These virtual machines run on Oracle VM servers that are grouped together into server pools. This makes it possible to easily migrate the virtual machine where a guest is running to another similar server without interrupting service. In a clustered server pool where a guest is configured to support High Availability, the guest can automatically be restarted on an alternate server when the server where a guest is running is under particular load or where a server becomes unavailable at any point.

Oracle VM guests consume resources that are allocated to the domain by the hypervisor running on the Oracle VM Server. Additional facilities to allow communication between a guest and the Oracle VM infrastructure can be installed on the guest operating system, including the Oracle VM Guest Additions. Note that you can install the Oracle VM Guest Additions on Oracle Linux guests only. Find out more about the Oracle VM Guest Additions in Installing and Using the Oracle VM Guest Additions in the Oracle VM Administrator's Guide.

Oracle VM guests and the virtual machines where they run are discussed in more detail in Chapter 7, Understanding Virtual Machines.

2.5 Authentication and Encryption in Oracle VM

Since there are a number of inter-related components that make up the Oracle VM environment, and each of these components must be able to communicate with each other, it is important to understand how each component authenticates itself to another, and how communications are secured. To explain this, we need to first identify the different interactions and communications channels that each component uses. These are presented in the list below:

  • Internal component communications within Oracle VM Manager (for example, MySQL, WebLogic, the Oracle VM Manager application, and so on).

  • Oracle VM Manager communications with Oracle VM Servers via Oracle VM Agent.

  • Web-browser communications with Oracle VM Manager using the web-based user interface.

  • Client application communications with Oracle VM Manager via the Web Services API (command line interface, custom scripts and applications, utilities, and so on).

In this section, we discuss the authentication and encryption of these interactions in some detail. Further information is available in the Oracle VM Security Guide.

As of Oracle VM Release 3.4.1, SSLv3 is disabled within Oracle VM Manager for security reasons. From Oracle VM Release 3.4.1 to Release 3.4.4, connections using the SSL TLS version 1 (TLSv1) protocol are accepted.

As of Oracle VM Release 3.4.5, the SSL TLSv1 protocol is disabled by default within Oracle VM Manager for security reasons. Wherever reference is made to SSL connections within this documentation, it should be understood that only connections using the TLSv1.2 protocol are accepted. However, downgrading to TLSv1 is still possible, to allow management of Oracle VM Server 3.2.10 and 3.2.11.

Internal component interactions

Oracle VM Manager is comprised of a number of different software components running on a single system. These include a MySQL database, an Oracle WebLogic Server that also includes the Application Development Framework (ADF) and the Oracle VM Manager application itself. Since each of these processes runs on the same system, there is no requirement to encrypt communications between them. However, authentication of each component is critical, to ensure that each process performing an interaction is legitimate.

During installation of Oracle VM Manager, a single password is set for all components. This password is used to authenticate communications between each process. The password used by Oracle WebLogic Server and the Oracle VM Manager application to access the MySQL database is stored in a secure keystore.

The same password is used for the administrative user to access the Oracle VM Manager application, via the web-based user interface, the command-line user interface or the web-services API. There are options within the product to change the password for the administrative user or to create additional user and password combinations to access the application. These are discussed in the Oracle VM Administrator's Guide. Note that authentication for Oracle VM Manager is handled by the underlying Oracle WebLogic Server framework and follows conventions applied by this software component. Therefore, an account may be locked for 30 minutes after 5 subsequent invalid login attempts.

Changing the password of the administrative user does not change the password used to authenticate to the Oracle WebLogic Server or MySQL database, and the original password is always used by the Oracle VM Manager application in its interactions with these. Therefore, it is important that this password is always kept safe and that this password properly complies with your security requirements.

Oracle VM Manager and Oracle VM Server Interactions

All communications between Oracle VM Manager and any Oracle VM Server are achieved via the Oracle VM Agent running on the Oracle VM Server. To help keep traffic segregated as far as possible, to improve security and to limit the impact of particular network transactions on each other, Oracle VM introduces the concept of dedicated network channels. By default, a single network channel known as the Management Network is created to facilitate all kinds of traffic between Oracle VM Manager and Oracle VM Servers, and between Oracle VM Servers themselves. Traffic can be further segregated according to different functions, to improve security and performance. See Section 5.6, “How are Network Functions Separated in Oracle VM?” for more information. Since these communications take place over a network, they are secured using an SSL certificate. Furthermore, the Oracle VM Manager instance must authenticate itself to the Oracle VM Server as the Oracle VM Manager instance that has ownership of that server.

For this reason, the Oracle VM Manager application creates and manages its own keystores containing various certificates and keys that are used for authentication and encryption purposes. Significantly, Oracle VM Manager generates its own Certificate Authority (CA) certificate and key that it uses to sign and validate certificates used within the infrastructure.

When Oracle VM Manager first takes ownership of an Oracle VM Server, it connects to the server via an SSL certificate that the server accepts to encrypt communications. During the ownership process, the user must provide the password that is set for the Oracle VM Agent. If the Oracle VM Server is already under the ownership of another Oracle VM Manager instance, the request to take ownership fails. Otherwise, the password is used to authenticate the Oracle VM Manager to the server. During this process, Oracle VM Manager uses its CA certificate to sign an SSL certificate and key that it provides to the server to authenticate future communications from the Oracle VM Manager instance.

From this point onwards, all authentication between Oracle VM Manager and the Oracle VM Server is achieved using SSL certificates. If a situation arises where the server is unable to validate or authenticate the certificate used by Oracle VM Manager, Oracle VM Manager must take ownership of the server again so that a new certificate and key pair can be exchanged.

The password for the Oracle VM Agent on a server can be reset when releasing ownership, using the web-based user interface, or can be reset for any server under the current ownership of Oracle VM Manager using the command line interface or Web Services API.

All certificate management for this process occurs internally within the application and does not require any user intervention at all.

Oracle VM Manager Web Interface

When a user connects to the Oracle VM Manager web-based user interface, this is achieved using an HTTPS connection secured with an SSL certificate. The user is still expected to authenticate using a plain text username and password on the Oracle VM Manager user interface login page. The SSL certificate is used to encrypt communications between the user's web-browser application and the Oracle VM Manager web application.

The SSL certificate that is used for this is automatically generated during the installation of Oracle VM Manager. The user may receive a certificate validation warning within the web-browser if the internal Oracle VM Manager CA certificate is not installed as a trusted certificate within the browser.

Oracle VM Manager provides tools to either obtain the CA certificate so that this can be installed within the web-browser, or to substitute the default SSL certificate with an alternate certificate that is signed by a trusted third-party CA. If you opt to do this, the SSL certificate hostname must match the fully qualified domain name of Oracle VM Manager and must be the same as the hostname that is used by your users to access the Oracle VM Manager web-based user interface.

More information on configuring this SSL certificate, or on obtaining the internal CA certificate, is provided in the Oracle VM Administrator's Guide.

Oracle VM Manager Web Services API interactions

All client applications, including the Oracle VM Manager Command Line Interface, are also capable of connecting to Oracle VM Manager across a network. Since all applications interact with Oracle VM Manager via a web-services API over HTTPS, these connections can be secured using the same SSL certificate as used for the Oracle VM Manager web-based user interface discussed above.

The command-line interface provides access to Oracle VM Manager via an SSH connection that can either be made using an administrator username and password, or which can be secured using standard SSH keys. The command-line interface application, then authenticates with the Oracle VM Manager application using its own SSL certificate and key, issued and signed by the Oracle VM Manager CA certificate.

If you are developing your own application or script to interface with the Oracle VM Manager Web Services API, it is possible to achieve authentication either using the API login mechanisms that accept a username and password combination, or you can use SSL-based authentication. To do this, you generate your own certificate and key pair. You then sign the certificate and register it with the Oracle VM Manager CA, using one of the provided mechanisms. From this point on, your application can use SSL key-based authentication to obtain secure and authorized access to the API. Further information on this is provided in the Oracle VM Web Services API Developer's Guide.

2.6 What Else does Oracle VM Require?

Two fundamental parts of the Oracle VM infrastructure, storage and networking, are not provided as part of the product itself, but are required in order for the product to function properly. Since the type of storage that a deployment may use can vary dependent on the deployment's requirements, Oracle VM provides support for a range of different storage types and includes mechanisms to enable different support types within the environment. Equally, network design and configuration can vary depending on requirements, hardware and cabling. Oracle VM caters to a range of complex network configurations and provides tools to configure systems within the environment to connect to each other according to a specific network design.

2.6.1 Storage

Oracle VM can use any of the following types of storage:

  • Local disks.

  • Shared Network Attached Storage - NFS.

  • Shared iSCSI SANs: abstracted LUNs or raw disks accessible over existing network infrastructure.

  • Shared Fibre Channel SANs connected to one or more host bus adapters (HBAs).

Note

OCFS2 (Oracle Cluster File System) is used in the storage configurations that are not based on NFS.

To configure access to different storage types across Oracle VM Servers within a deployment, Oracle VM makes use of Oracle Storage Connect plug-ins. Storage Connect plug-ins are packaged and distributed as RPM packages and deployed on the Oracle VM Servers. They are divided in two major categories: storage array plug-ins for any block based storage, and file system plug-ins for any network file system based storage. Generic plugins are provided by Oracle for each of these storage types, however storage vendors may provide specialized plugins that expose further features to Oracle VM via the Oracle Storage Connect framework.

The main benefits of the plug-in approach are:

  • Flexibility: Use and integrate with your existing storage infrastructure, choose between file-based and block-based solutions, and use local storage for testing purposes or virtual machines of minor importance. Use generic or vendor-specific plug-ins depending on your available hardware or any new hardware you select.

  • Scalability: Add more storage providers of your preferred type and present them to your server pools as your need for storage increases. Reduce the amount of storage again if the higher storage requirements are temporary. Provision your storage with redundancy and multipathing according to your requirements and preferences.

  • Extensibility: If you upgrade your storage, consider the added functionality of vendor-specific plug-ins. If you select hardware for which Oracle Storage Connect plug-ins are available, ask the manufacturer for the RPM and install the plug-in on the Oracle VM Servers with access to this storage hardware.

Oracle VM always requires a location to store environment resources that are essential to the creation and management of virtual machines. These resources include virtual appliances and VM templates, ISO files (virtual DVD images), VM configuration files and VM virtual disks. The location of such a group of resources is called a storage repository. You present a storage repository to the Oracle VM Servers that need access to those resources; typically all servers in a server pool.

Storage repositories can be configured on an NFS file system or on a physical disk (LUN) of a storage array. However, for storage repositories on physical disk, the servers with access to it must be members of a clustered server pool. In general, the use of shared storage is recommended for the purpose of hosting a storage repository, however Oracle VM is capable of performing live migration of a virtual machine running from a repository hosted on local storage, by taking advantage of features within OCFS2. For unclustered server pools only file server storage is available. For details about the use of storage repositories, see Section 3.9, “Where are Virtual Machine Resources Located?”.

Clustering adds another storage element to the environment: the server pool file system. During server pool creation, the server pool file system specified for the new server pool is accessed and formatted as an OCFS2 file system, whether the file system is accessed by the Oracle VM Servers as an NFS share, a FC LUN or iSCSI LUN. This formatting creates several management areas on the file system including a region for the global disk heartbeat. The server pool file system plays a key role in clustering and therefore in the high-availability configuration of the Oracle VM environment. Note that where a clustered server pool is created, shared storage is required to host the server pool file system. For details about server pool clustering, see Section 6.9, “How do Server Pool Clusters Work?”.

The storage element that is most tangible and visible to all users of Oracle VM is the virtual machine disk. A VM disk is either a disk image file in a storage repository or a raw physical disk. If a physical disk (LUN) is used, it is attached directly to the VM in the same way it would be to a physical machine. For details about virtual machine operation, see Chapter 7, Understanding Virtual Machines. Again, the availability of VM disks in a storage location with shared access from all Oracle VM Servers in the server pool is preferred for VM high-availability.

Storage is described in more detail in Chapter 3, Understanding Storage.

2.6.2 Networking

The networking infrastructure in the Oracle VM environment comprises connections between:

  • Oracle VM Servers within the environment.

  • Oracle VM Manager and all Oracle VM Servers in the environment.

  • Oracle VM Server and the storage subsystems that it uses.

  • Virtual machines running in a server pool.

  • Virtual machines and external private or public networks.

These networking connections can leverage features supported by Oracle VM, such as networked file systems, clustering, redundancy and load balancing, bridging, and support for Virtual LANs (VLANs).

In Oracle VM Manager, network configuration is the mapping of available network interfaces on the Oracle VM Servers to a set of logical Ethernet networks. The physical network is the collection of physical connections in Oracle VM Manager and all Oracle VM Servers, and the switches and routers that allow information to reach its destination. A logical network in Oracle VM is built on top of these physical connections. Before you define the logical networks in Oracle VM Manager, you have to review the physical network configuration that you intend to use, such as VLAN and subnet usage. You also take into account the number of network interfaces available to your Oracle VM Servers. The minimum recommended number of ports required on a single Oracle VM Server is two, although one would suffice for test or demonstration purposes. If you have more than two ports on your Oracle VM Servers, you can design more redundancy or traffic isolation in your environment.

Oracle VM identifies different network functions: server management, live migration, cluster heartbeat, virtual machine, and storage. All network functions can either be on dedicated or shared physical networks (except for a server local network used for virtual machines only). For example, a physical network can be dedicated to Virtual Machine or Storage only, or can be dedicated for all network functions. For details about network functions, see Section 5.6, “How are Network Functions Separated in Oracle VM?”.

After reviewing your physical network environment and deciding on the logical distribution and grouping of these physical objects, you create the logical constructs in Oracle VM Manager to implement your network design. These logical constructs include network bonds, VLAN Interfaces, networks and bridges. If your network design includes interface bonding, or aggregations of two ports, you create these network bonds first. These bonds are often used in conjunction with VLANs, when traffic from several VLANs is allowed to use the same bond. If your network environment comprises VLANs, your next step is to create VLAN Interfaces, determining which port or bond on each Oracle VM Server will accept traffic from which VLANs.

After careful evaluation of the available network building blocks and required network functions, you create the necessary logical networks by choosing one of these types:

  • Network with bonds and ports.

  • Network with VLANs only.

  • Hybrid network connecting bonds and ports, as well as VLAN interfaces.

  • Logical network on a single server (local server network).

For more detailed information about networking within Oracle VM, see Chapter 5, Understanding Networks.

2.7 What are Virtual Machines?

The entire Oracle VM environment is designed for the purpose of running and deploying virtual machines. They are, therefore, a significant component within the Oracle VM architecture. Virtual machines offer different levels of support for virtualization at the level of the operating system, often affecting performance and the availability of particular functionalities afforded by system drivers. The different types of virtualization support are referred to as virtualization modes.

Virtual machine images and configuration data are usually stored within storage repositories on shared storage that is connected to all of the Oracle VM Servers in a server pool. If the server pool has been configured to take advantage of load balancing, the virtual machine can be started on any Oracle VM Server in the pool, because all of the files required to run it are available to all of the servers. Equally, in the case of failover, if a server in a clustered server pool should become unavailable, the virtual machine can be automatically restarted on another Oracle VM Server in the pool.

Virtual machines can be created from different types of resources: from a virtual appliance that contains one or more preconfigured virtual machines, or from a template. Alternatively, you can also create virtual machines from scratch using an ISO file (image) of an installation DVD. Booting a virtual machine using PXE, or network boot for a paravirtualized guest, is also possible.

The creation of a virtual machine from template is based on cloning: the template is imported as an archive, unpacked and stored as a virtual machine configuration file with images of its disks, which are cloned to create a new instance in the form of a virtual machine. In the same way, an existing virtual machine can be cloned to create a new virtual machine, or cloned to create a new template. Cloning is discussed in further detail in Section 7.6, “How does Cloning Work?”.

Virtual appliances are similar to templates in that you can use them to quickly create virtual machines. The primary difference between virtual appliances and templates is that virtual appliances are packages created as a single .ova (Open Virtualization Format Archive) file or a set of .ovf (Open Virutalization Format) and .img (disk image) files. Virtual appliances can contain one or more virtual machines and include the virtual disks and the inter-connectivity between the virtual machines.

Note

In previous releases of Oracle VM, virtual appliances were referred to as assemblies.

In the Oracle VM Manager Web Interface, templates and virtual appliances are located on a different tab to virtual machines. However, all configuration files and disk images are stored in the same location, including the configuration files and disk images that Oracle VM Manager creates for new virtual machines or templates.

Creating a virtual machine from a virtual DVD (image file, ISO) is different depending on the virtualization mode. For hardware virtualized guests the standard installer provided in the image is used, so no allowance for PV drivers is given. When creating a hardware virtualized guest, you can assign an ISO file located on a storage repository so that the new virtual machine immediately boots from the virtual DVD. Conversely, a PVM guest cannot simply boot from DVD since there is no virtual DVD device loaded at this stage, and uses an ISO file mounted remotely, accessing it via NFS, HTTP or FTP. The distinction here is that a hardware virtualized machine has an emulated BIOS, while a PVM guest does not.

Virtual machine resources are stored in storage repositories. The contents and structure of storage repositories is described in detail in Chapter 4, Understanding Repositories.

When a virtual machine is running, it can be accessed through a console, which allows it to be used as a regular operating system. For more information on the console, see Section 7.11, “Accessing the Virtual Machine Console”.

The next few sections provide an overview of many of the concepts specific to virtual machines. A more detailed look at virtual machines is covered later in Chapter 7, Understanding Virtual Machines.

2.7.1 What are Virtualization Modes?

A virtual machine can be defined as a virtualized operating system with its associated software and applications. It runs in one of three virtualization modes, also named domain types:

  • Hardware virtualized (HVM): An unmodified guest operating system executes in complete isolation. Instructions are trapped and emulated at the hardware level (Intel® VT-x/VT-i and AMD-V™). This means that a guest can run without specific modifications to allow for virtualization.

  • Paravirtualized (PVM): A software interface similar but not identical to the underlying hardware is presented to the guest operating system. Paravirtualization provides hooks for guest instructions so that hardware related tasks such as access to network resources, blocks and underlying files can be handled by the management domain instead of the virtual machine, often significantly improving performance, particularly for 32-bit environments. Paravirtualization requires that the guest kernel has support for and loads the PVM drivers to be made aware of the virtual environment.

  • Hardware virtualized with paravirtualized drivers (PVHVM): Similar to HVM but with additional paravirtualized drivers that are capable of handling I/O related processes directly within the management domain to increase VM performance. This provides the advantages of paravirtualization to an otherwise hardware virtualized guest. This domain type is typically used to run Microsoft Windows™ guests with a limited performance penalty.

2.7.2 What are the Oracle VM Guest Additions?

While not necessary to have a fully functional Oracle VM deployment, Oracle VM Guest Additions can be installed into you virtual machines to allow you to communicate directly with a virtual machine from Oracle VM Manager. The Oracle VM Guest Additions package installs a daemon that runs within the virtual machine and which listens for messages from Oracle VM Manager. By installing this package, Oracle VM Manager is able to provide information about the actual virtual machine's configuration, such as its configured IP address. Furthermore, it is possible to configure virtual machines as they are started by sending configuration information from Oracle VM Manager directly to the virtual machine, triggering configuration scripts that are able to use the data. This facility enables you to control behavior within a virtual machine as different events outside of the virtual machine trigger these scripts.

The Oracle VM Guest Additions, and the way in which configuration scripts can be used in conjunction with Oracle VM's messaging subsystem, are discussed in detail in the Oracle VM Administrator's Guide.

2.8 What Features Does Oracle VM Provide?

This section gives an overview of the Oracle VM Manager features used to manage Oracle VM Servers, virtual machines, storage repositories, networks, and resources. Oracle VM Manager provides the following main capabilities:

  • Manages the physical Oracle VM Servers and can, for example, reboot or rediscover the physical hardware.

  • Creates and configures server pools.

  • Creates and manages Oracle VM Server logical networks, for example, NIC port bonding, and configuring VLAN networks.

  • Manages storage devices such as local disks, SAN storage and Network File Servers.

  • Creates and manages storage repositories.

  • Manages resources, including ISO files, virtual machine templates, virtual machine images, and virtual appliances.

  • Manages the virtual machines. This includes creating virtual machines from either installation media or from templates, starting, logging in, shutting down, and deleting virtual machines.

  • Imports, clones and migrates virtual machines.

  • Performs load balancing of virtual machines in server pools.

  • Manages jobs in the Oracle VM environment.

  • Manages policies such as High Availability, Distributed Resource Scheduling, and Distributed Power Management.

A Web Services API is available for programmatic access to Oracle VM Manager, and all of the objects Oracle VM Manager has ownership of. See the Oracle VM Web Services API Developer's Guide for an introduction to the API.

A command line interface is also available to access Oracle VM Manager, see the Oracle VM Manager Command Line Interface User's Guide for more information.

2.9 What Support is Available for Oracle VM?

Oracle has a unique position in the virtualization market as an enterprise application, operating system and hardware vendor that delivers technologies across the stack. Owning the entire stack has various advantages:

  • Integration and centralized management of all components.

  • The ability to pre-package and distribute Oracle technologies via Oracle VM templates and virtual appliances.

  • Integrated enterprise support across the entire technology stack, from application to hardware.

Oracle VM Support is an add-on component of Oracle's enterprise support package that offers an end-to-end single vendor support solution from the application to the disk. A single support call covers the entire Oracle stack which expedites problem resolution. Using Oracle Support allows an Oracle Support Service Request (SR) to transition between Support teams with issues that require cross stack collaboration. For example, if you open a service request for an application issue, and the root cause is at the virtualization layer, then the service request moves between the application and virtualization Support teams. For more information on Oracle Support, see:

http://www.oracle.com/us/support/index.html

Copyright © 2014, 2021 Oracle and/or its affiliates. Legal Notices