Chapter 7 Understanding Virtual Machines

Table of Contents

The purpose of Oracle VM is to provide an infrastructure that virtual machines are able to run on, and which is easy to manage, configure and maintain. In this chapter we explore the different types of virtual machines that are supported; how virtual machines work within an Oracle VM environment; how virtual machines can be created, moved and migrated; and how to provision resources for a virtual machine.

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 is granted virtual resources and can be started, stopped and restarted independently of other domains and of the host server itself. A guest is a virtualized operating system running within a domain. A guest operating system may be paravirtualized, hardware virtualized, or hardware virtualized with paravirtualized drivers. A description of these different virtualization modes is provided in Section 7.1, “What are Virtualization Modes or Domain Types?”.

Multiple guests can run on the same Oracle VM Server. A virtual machine is a guest operating system and its associated application software. For the sake of simplicity, we use the term virtual machine to encompass domain, guest and virtual machine. They are synonymous with each other and may be used interchangeably.

An operating system installed in a virtual machine is known as a guest operating system. Oracle VM supports a variety of guest operating systems including Linux, Oracle Solaris and Microsoft Windows™. For a list of the supported guest operating systems, see the Oracle VM Release Notes. Guest operating system installation is described in Section 7.2, “How is a Guest OS Installed on a Virtual Machine?”.

You can use Oracle VM Manager to create virtual machines using:

  • ISO files in a repository (hardware virtualized only).

  • Mounted ISO files on an NFS, HTTP or FTP server (paravirtualized only).

  • Virtual machine templates (by cloning a template).

  • Existing virtual machine (by cloning the virtual machine).

  • Virtual appliances.

Virtual machines require most of these installation resources to be in a storage repository, managed by Oracle VM Manager, with the exception of mounted ISO files for paravirtualized guests. See Section 7.3, “Where are Virtual Machine Resources Stored?” for information on how these resources are stored within a repository.

When you create a virtual machine that requires network connectivity, or a paravirtualized machine which requires network connectivity to perform the operating system install, you generate some virtual network interfaces that can be bridged to a network defined on the Oracle VM Server. More information on provisioning networking for your virtual machines is provided in Section 7.4, “What Networking is Available for Virtual Machines?”.

In cases where you require multiple virtual machines that are identical in make up, you might consider cloning a virtual machine or template. This process is described in more detail in Section 7.6, “How does Cloning Work?”. Equally, you may need to move a virtual machine from one server or server pool to another, this process is known as migration and is discussed in Section 7.7, “How Can a Virtual Machine be Moved or Migrated?”

Oracle VM provides a messaging facility that allows messages to be sent backwards and forwards between Oracle VM Manager and a guest operating system. This makes it possible to automate configuration actions when a virtual machine boots, to obtain information about the internal status of a virtual machine, and to trigger events within a virtual machine based on changes within the Oracle VM environment. This messaging facility is described in some detail in Section 7.10, “Sending Messages to Virtual Machines”.

In some cases, usually due to software licensing requirements, you may require that virtual machines are hard partitioned using CPU pinning. This feature allows you to pin a virtual machine to a specific physical CPU to prevent it from running on alternate systems. This is an advanced feature and is described in Section 7.16, “Setting Hard Partitioning for Virtual Machine CPUs”.

7.1 What are Virtualization Modes or Domain Types?

Virtual machines may run in one of two main modes, paravirtualized (PVM) or hardware virtualized machine (HVM). In paravirtualized mode, the kernel of the guest operating system is recompiled to be made aware of the virtual environment. This allows the paravirtualized guest to run at near native speed, since most memory, disk and network accesses are optimized for maximum performance.

If support for hardware virtualization is available (either Intel® VT or AMD-V™), the guest operating system may run completely unmodified. This hardware virtualized machine is carefully monitored and trapped by Oracle VM Server when any instruction is executed which would violate the isolation with other guests or dom0. In the current implementation, there may be performance penalty for certain types of guest and access types, but hardware virtualization also allows many Microsoft Windows operating systems and legacy operating systems to run unmodified.

The third virtualization mode is a hardware virtualized machine with paravirtualized drivers (PVHVM). This mode is identical to a hardware virtualized machine, but with additional paravirtualized drivers installed in the guest's operating system to improve virtual machine performance.

When you create a virtual machine, you must choose the virtual machine virtualization mode, or domain type, as in the following table:

Table 7.1 Domain Types

Domain Type

Description

Hardware virtualized machine (HVM)

Hardware virtualization, or fully virtualized. An HVM guest, must be installed similar to bare metal, using an install ISO file or network installation server.

To create HVM guests, you may need to activate the hardware virtualization in the BIOS of the server on which you install the Oracle VM Server.

Hardware virtualized, with paravirtualized drivers (PVHVM)

Identical to HVM, but with additional paravirtualized drivers for improved performance of the virtual machine. See Converting to Paravirtualized Guests or Installing Paravirtualized Drivers for more information about using paravirtualized drivers. This Domain Type is used to run Microsoft Windows guest operating systems with an acceptable performance level and can also be used to run Oracle Linux and Oracle Solaris guest operating systems.

Paravirtualized (PVM)

When you create a PVM guest, you must supply a location for the mounted ISO file from which to create the virtual machine. Before you create the virtual machine using the paravirtualized method, mount the ISO file on an NFS share, or HTTP or FTP server. You supply the location of the mounted ISO file during the creation process.

For information on creating a mounted ISO file, see Section 7.2, “How is a Guest OS Installed on a Virtual Machine?”.

Due to kernel restrictions in both Oracle Linux 7 and RedHat Enterprise Linux 7, it is not possible to run these operating systems as PVM guests. Attempts to do so, generate an exception from within Oracle VM Manager to prevent this.

Oracle VM Server for SPARC (OVM/SPARC)

Since virtualization on SPARC platforms is significantly different to that achieved within x86 environments, Oracle VM distinguishes a separate virtualization mode specifically to indicate that the SPARC hypervisor is to be used. When creating a virtual machine that is to run in a server pool consisting of Oracle VM Servers for SPARC, this mode is used during configuration.


Note

If you want to create a PVHVM or PVM, make sure all disks the virtual machine is configured to use are paravirtual devices. An explanation and description of the steps to properly configure paravirtual disks is discussed in Paravirtualized Guest Disk Devices are Not Recognized in the Oracle VM Administrator's Guide.

Converting to Paravirtualized Guests or Installing Paravirtualized Drivers

For optimized performance, you can install paravirtualized drivers on hardware virtualized machines. Paravirtual drivers are optimized and improve the performance of the operating system in a virtual machine. These drivers enable high performance throughput of I/O operations in operating systems on top of the Oracle VM Server hosts.

Creating hardware virtualized machine machines may require that you install paravirtual drivers for your hardware on the guest operating system.

The Oracle Solaris 10 and Oracle Solaris 11 operating system runs as a hardware virtual machine (HVM), which requires HVM support (Intel® VT or AMD-V™) on the underlying hardware platform. By default, Oracle Solaris 10 or Oracle Solaris 11 operating system already has the required paravirtualized drivers installed as part of the operating system.

You can continue using HVM guest, but leverage the paravirtualized I/O drivers. For more information, see the Oracle Support document 757719.1 titled Comparison of Guest Virtualization Modes; HVM, PVM and PVHVM. Configuration, Mode Validation and Conversion to PVHVM on the My Oracle Support web site at:

https://support.oracle.com/epmos/faces/DocumentDisplay?id=757719.1.

Oracle recommends running with HVM or PVHVM guest types for optimum performance on current generation servers. Information on converting from PVM to HVM or PVHVM can be found in the Oracle Support document 757719.1.

To install the paravirtual drivers for Microsoft Windows operating systems (Oracle VM Paravirtual Drivers for Microsoft Windows), see Oracle VM Paravirtual Drivers for Microsoft Windows.

7.2 How is a Guest OS Installed on a Virtual Machine?

Virtual machines require some form of installation media, whether it be a template, virtual appliance, ISO file, or mounted ISO file. Different domain types may require slightly different installation source files. Table 7.2, “Virtual machine installation sources” lists the installation sources available for HVM and PVM guests.

Table 7.2 Virtual machine installation sources

Installation Source

HVM

PVM

Template (clone)

Yes

Yes

ISO file in repository

Yes

No

Mounted ISO file on NFS, HTTP or FTP server

No

Yes

Virtual appliance

Yes

Yes


When you create an HVM guest from an ISO file, you must supply an ISO file which has been preloaded into a storage repository that is presented to the Oracle VM Server on which the virtual machine is to be deployed. The ISO is configured as a virtual CDROM device within the virtual machine's BIOS. At boot, the virtual machine is able to boot from the virtual CDROM like a regular physical system. See Section 7.3, “Where are Virtual Machine Resources Stored?” for information on how these files are stored in a repository.

Unlike a hardware virtualized machine, a paravirtualized machine does not have a BIOS and the kernel must be loaded directly. Therefore, the virtual machine requires direct access to a kernel that can be loaded at boot. Oracle VM Manager cannot be used to manage this process, since it is not possible to predict how networking has been configured for every deployment. The virtual machine network is frequently separated from the management network using VLANs or multiple networks, so that an Oracle VM Server is unable to present a loopback mounted ISO directly to the virtual machine. This means that to install a PVM guest from an ISO file, you must first mount the ISO on an NFS, HTTP or FTP server that is accessible to the virtual machine on the virtual machine network. During the creation of the guest, you provide a network boot path that provides a URI to the mounted installation media. Examples showing how to set up your environment to cater for PVM installation media are provided in Provisioning ISO Files for PVM Guest Installations in the Oracle VM Administrator's Guide

More commonly, virtual machines are deployed using either templates or virtual appliances. Templates are essentially clones of a single existing virtual machine. As such, they can be reused and distributed to quickly deploy a preinstalled and preconfigured virtual machine. Virtual appliances are similar to templates, although they can contain multiple virtual machines and are provided in the more universal Open Virtualization Format.

See Section 4.8, “How are Virtual Machine Templates Managed?” for information on working with virtual machine templates. See Section 4.7, “How are Virtual Appliances Managed?” for information on working with virtual appliances. See Section 4.9, “How are ISO Files (CD/DVD Images) Managed?” for information on working with ISO files.

7.3 Where are Virtual Machine Resources Stored?

A storage repository is used to store virtual machine resources, so that these resources can be made available to Oracle VM Servers in a server pool, without having to copy the resources to each Oracle VM Server. The types of underlying storage that can be used for a repository are discussed in more detail in Section 3.9, “Where are Virtual Machine Resources Located?”. A more detailed description of storage repositories and how to manage their contents is described in Chapter 4, Understanding Repositories.

7.4 What Networking is Available for Virtual Machines?

A VNIC is a virtualized Network Interface Card, used by a Virtual Machine as its network interface. A VNIC is assigned a MAC address. Each MAC address corresponds with a single virtual NIC, which is used by a virtual machine. You can create a VNIC when you create or edit a virtual machine. There is no real limit to the number of VNICs available to any single virtual machine. Each VNIC must belong to a virtual machine and cannot exist independently of it. This requirement was implemented in version 3.3.1 of Oracle VM. Previous versions allowed you to create VNICs independently of virtual machines and then to assign them as required. This approach was frequently confusing and more difficult to manage.

VNICs are automatically related to a network bridge that is created on the hosting Oracle VM Server. It is possible to configure the network in such a way that virtual machines are able to only interact with each other on the same Oracle VM Server, with all of the virtual machines running across the server pool, or with all of the virtual machines and a public network such as the Internet.

Since MAC addresses need to be unique on a network, Oracle VM Manager dynamically creates MAC addresses to be allocated to each VNIC from a predefined range. Oracle VM Manager attempts to ensure that no two VNICs are able to have the same MAC address. It is possible to modify the MAC address range that Oracle VM Manager uses to allocate for VNICs. This is described in more detail in Virtual NICs in the Oracle VM Manager User's Guide.

Note that it is not possible to change the number of VNICs available to a virtual machine while the virtual machine is in a suspended state. Attempting to add or remove a VNIC for a virtual machine that is suspended results in an exception and Oracle VM Manager returns an error.

Network configuration on a virtual machine can be achieved using the tools available in the guest operating system. If you require DHCP configuration, you equally require a DHCP server to be configured on a network that is attached to the virtual machine network. For this reason, along with the benefit of added security, it is often useful to implement full network separation particularly for the function of the virtual machine network. This can be achieved using VLANs, or separate physical network ports or bonds.

Different network configurations and network separation are discussed in more detail in Chapter 5, Understanding Networks.

7.5 How are Virtual Machines Created?

Before you create a new virtual machine, make sure that the following resources are available:

For information on how to create a virtual machine using a template, and creating a virtual machine from an ISO file, or from physical or virtual disks see Create Virtual Machine in the Oracle VM Manager User's Guide.

To access the virtual machine, select the Servers and VMs tab, select the server pool on which the virtual machine was created in the navigation tree, and select Virtual Machines in the Perspective drop-down list in the management pane. Select the virtual machine in the table to perform operations on it. Expand the virtual machine in the table to see more detailed configuration information.

7.6 How does Cloning Work?

Cloning a virtual machine or template enables you to create multiple virtual machines or templates based on the original. There are two methods of cloning; a simple clone, and an advanced clone.

A simple clone of a virtual machine has the same configuration as the original virtual machine. In some cases, simple clones of virtual machines do not always have the exact same configuration as the original virtual machines. For example, if a virtual machine uses a virtual CD-ROM device, creating a simple clone of that virtual machine does not also clone the virtual CD-ROM device if an ISO file is attached.

An advanced clone of a virtual machine has a different configuration as the original virtual machine and requires you to use a clone customizer. For example, you can use a clone customizer to have the clone deploy to a different server pool or repository, with changed memory, virtual CPU number, network settings, and so on.

Figure Figure 7.1, “Cloning a virtual machine or template” shows the process of creating a clone of a virtual machine or template.

Figure 7.1 Cloning a virtual machine or template
This figure shows the process of creating a clone of a virtual machine or template.

To modify the clone parameters, such as virtual disks, network, memory, and so on, you should create a clone customizer, and use that clone customizer to perform cloning. You can create a clone customizer to set up the clone parameters, such as networking, and the virtual disk, and ISO resources. A clone customizer is also used when moving a virtual machine or template. See Manage Clone Customizers in the Oracle VM Manager User's Guide to see an example of how you are able to create a clone customizer to use during cloning.

A cold clone is a clone created from a stopped virtual machine. A cold clone performs a clone of the virtual machine, with safe and consistent virtual disk status. This is useful for creating a virtual machine or template from the original virtual machine.

A hot clone is created from a running virtual machine. A hot clone is only available on OCFS2-based file systems, so you must use either iSCSI- or fibre channel-based storage for the source and target repositories. Additionally, Oracle VM Manager allows you to create hot clones for virtual machines only if the clone type for the virtual disk is a thin clone.

Note

A hot clone creates a clone with inconsistent disk status, and should only be used as a snapshot or back up of a virtual machine, perhaps on a virtual machine that requires 100% uptime and cannot be shut down. If you want to use the hot-cloned virtual machine, you should first repair any virtual disks, using a disk repair utility such as fsck. Do not use hot cloning for virtual machines running an Oracle Database. Instead, you should use an Oracle Database backup strategy, such as the rman utility.

A thin clone only copies the required virtual machine files and ignores empty disk space, so the cloning process is able to complete much more quickly. This process makes use of the reflinking capability within the OCFS2 file system, allowing for a rapid cloning method. As a result, thin cloning can only be used when cloning from and to the same OCFS2-based repository, and when the storage used for the storage repository is non-generic (for example, a Sun 7000 or NetApp Storage Connect plug in). Thin cloning is the fastest and most efficient cloning method.

Note

Thin provisioning of physical disks on generic storage is not supported.

A clone can also be performed using two other file copy methods: sparse copy, and non-sparse copy. These two cloning methods can be used when cloning from and to different repositories, and when the storage used for the storage repository uses a generic Storage Connect plug in. These cloning methods are slower than thin cloning, but more versatile.

Sparse copy only takes up the amount of disk space actually used, not the full specified disk space. This process only copies used blocks and ignores unused blocks on the disk. This makes it quicker than a non-sparse copy and is efficient in its initial use of disk space, however the process is not as fast as thin cloning. Since sparse copy does not allocate all required disk space immediately, it is important to plan for the possibility that disk sizes may ultimately exceed the repository size where the the virtual machine is running and cause I/O errors on all of the running virtual machines in the same repositories. Therefore, when using sparse copy, you should ensure that the repository size is adequate to handle the potential disk space requirements of all of the virtual machines hosted on it.

Note

Sparse copy is only available in SPARC environments if the control domain is running Oracle Solaris 11.2 or greater.

Non-sparse copy performs a block-level copy of a disk, so that even unused blocks are cloned. This means that the virtual machine disk is fully allocated at the time that the virtual machine is cloned, whether the disk blocks are used or not. The advantage of this type of clone is that you can always be certain of the amount of disk space required for a virtual machine and cannot exceed the disk space available in a repository by hosting it there.

7.7 How Can a Virtual Machine be Moved or Migrated?

Moving and migrating virtual machines within Oracle VM are distinct operations, as follows:

Moving

Changes the repositories where the virtual machine configuration and virtual disks reside.

You can move a virtual machine only if it is stopped.

Migrating

Changes where the virtual machine runs in terms of the Oracle VM Servers and server pools available.

You can migrate a virtual machine if it is running or if it is stopped. If the virtual machine is running, the migration is known as a live migration. If a virtual machine is hosted on a local repository on local storage, it may only be migrated while it is running. Live migration is only supported where the target Oracle VM Server is at the same release number or later. For virtual machines running on an x86 platform, a rule exception is generated if you attempt to live migrate a virtual machine to an Oracle VM Server with a major earlier release number than the Oracle VM Server where the virtual machine is running.

Exporting

Exports a virtual machine to Oracle Cloud Infrastructure using the Oracle VM Exporter Appliance.

You can only export a stopped virtual machine that is in a server pool or is unassigned.

Moving Virtual Machines

In many ways, a move is similar to a cloning process, because the source virtual machine is used as a template to create the destination virtual machine. Once the creation of the destination virtual machine is complete, the source virtual machine is deleted.

For this reason, moving a virtual machine involves using a clone customizer. During the move process, you can use a clone customizer to:

  • Change the location of the virtual machine disks and virtual machine configuration file to a different storage repository.

The network information is not changed when moving a virtual machine, so you cannot move VNICs between networks. Any network changes you make in a clone customizer are ignored when moving a virtual machine. This allows you to preserve the virtual machine in its original state, while moving the configuration file and storage to a different repository.

It is also important to understand that when moving a virtual machine that has shared virtual disks or an attached virtual CD-ROM device, the data for these objects is actually copied across repositories rather than moved. This is because if an object is shareable, it is not possible to determine whether that object may be needed by another virtual machine that is not being moved. Therefore, if your virtual machine has any attached ISOs or shared virtual disks and you complete a move operation, you may wish to manually remove these objects from the source repository if you know that they are no longer in use.

Moving Virtual Machines Between Local Repositories.  Oracle VM Manager does not allow you to move a virtual machine directly from one local repository to another local repository if that virtual machine uses virtual disks. Note that it is possible to effectively move a virtual machine from one local repository to another while it is running by performing a live migration as described in Migrating Virtual Machines. However, if the virtual machine is stopped, you must move that virtual machine and the virtual disks from the local repository of the source Oracle VM Server to a shared repository. You can then move the virtual machine and the virtual disks from the shared repository to the local repository of the destination Oracle VM Server.

For example, your environment includes a server pool with two Oracle VM Servers, server A and server B. Both servers use repositories that are hosted on disks that are local to each server. Server A cannot access the repository that is local to server B. Conversely, server B cannot access the repository that is local to server A.

On server A you have a virtual machine that uses a virtual disk, or a file in storage that is presented to the virtual machine as a disk. To move the virtual machine from the repository for server A to the repository for server B, you must use an intermediate shared repository that both server A and server B can access.

Related Information. 

Migrating Virtual Machines

Live migrations can occur only between Oracle VM Servers within the same server pool. If the virtual disks for a virtual machine reside on shared storage, then each Oracle VM Server within the server pool has access to the virtual disks. As a result, live migrations of virtual machines in this scenario are straightforward because the virtual disks do not need to change to a different repository.

However, to perform live migrations between Oracle VM Servers that use local storage, you must also migrate the virtual disks from the source server's local repository to the destination server's local repository. Because the local storage is specific to each Oracle VM Server, it is not possible to migrate a virtual machine from one Oracle VM Server to another without migrating the virtual disks.

The following restrictions apply to live migrations that include migrating the virtual machine's storage:

  • The Oracle VM Server where the virtual machine is running must be hosted on an x86 platform. The Oracle VM Agent uses features built into the OCFS2 file system for the live migration process. Because live migration relies on the OCFS2 file system, this capability is not available on SPARC-based systems.

  • The target repository must already exist, must be local to the target Oracle VM Server and must have available disk space to complete the migration.

  • The source repository from where the virtual machine is to be migrated from must have adequate disk space for the operation to complete successfully. This usually equates to at least double the size of the disk space required by the virtual machine. For example, if a virtual machine and its virtual disks use 50 GB disk space, then the source repository file system must have at least 100 GB disk space available.

Oracle VM Manager Rules for Live Migration

In Oracle VM Release 3.4.2, the following rule was added to prevent failure of live migration and subsequent issues with the virtual machine environment:

Oracle VM Manager does not allow you to perform a live migration of a virtual machine to or from an instance of Oracle VM Server with a Xen version earlier than xen-4.3.0-55.el6.22.18. This rule applies to any guest OS.

Tip

Run the following command on Oracle VM Server to find the Xen version: 

# rpm -qa | grep "xen"

In addition to rules that prevent live migration in specific cases, Oracle VM Manager includes several safeguards to prevent live migration where the operation might result in resources becoming unavailable to any virtual machine in the server pool. For instance, if the virtual machine is using a locally hosted ISO, live migration fails. Equally, in the case where a locally hosted virtual disk is shared between two or more virtual machines on the same Oracle VM Server, live migration of any of these virtual machines also fails since the locally hosted virtual disk cannot be migrated without affecting the other virtual machines. In the event that live migration fails, the target repository is automatically cleaned.

During the migration of a virtual machine from one Oracle VM Server to another, Oracle VM Manager also tests the target Oracle VM Server to ensure that any LUNs used by the virtual machine are actually available. This includes a check that the path exists and a check to ensure that the path is actually up.

In the event that the target Oracle VM Server selected for a live migration with storage becomes unavailable during the migration, a rollback process is attempted to revert the environment to its state prior to the migration. If the target Oracle VM Server remains offline during the entire rollback process, some manual steps may be required to properly revert the environment, although the environment should function normally even while these steps have not been performed. This rollback process is described in more detail in the section titled Recovering From A Failed Local Virtual Machine Migrationin the Oracle VM Administrator's Guide.

Additional Considerations for Migrating Virtual Machines

Migrating Multiple Virtual Machines.  You can migrate one or more virtual machines at a time. When migrating multiple virtual machines, the migrations are performed serially and not concurrently, so one migration is performed, then the next, until all the migrations are completed. Cross-server pool migration is allowed, though the virtual machines must first be stopped. A virtual machine must also be in a stopped state before migrating it off of any server (an Unassigned Virtual Machine). When you migrate a virtual machine to another server pool, the virtual machine is not deployed to a particular Oracle VM Server until you start the virtual machine, then the placement strategies for the virtual machine depends on the Oracle VM Server roles, and destination server pool policies such as Distributed Resource Scheduler (DRS) and Distributed Power Management (DPM). See Section 6.2, “What are Server Roles?” for information on Oracle VM Server roles, and Section 6.12, “What are Server Pool Policies?” for information on server pool policies.

Inbound Migration Locks.  If you have set the inbound migration lock feature to disallow new virtual machines on an Oracle VM Server, then any automatic migration policies you set are restricted from migrating virtual machines, or creating new ones on that server. See Section 7.12, “How Can I Protect Virtual Machines?” for more information on using the inbound migration lock feature.

CPU Compatibility.  The CPU family and model number of the source and destination computers must be compatible in order to perform live migration. This means, for instance, that you cannot migrate a virtual machine from an x86-based server pool to a SPARC-based server pool, or vice versa. Equally, you cannot perform a live-migration within the same x86-server pool, if the servers have different CPU families or model numbers. For more information on CPU compatibility, please see Section 6.14, “What are Server Processor Compatibility Groups?”.

Exporting Virtual Machines

You can export a virtual machine from Oracle VM Manager to Oracle Cloud Infrastructure using the Oracle VM Exporter Appliance, a downloadable software adjunct to Oracle VM. With each Oracle VM Exporter Appliance you install, you can export up to four virtual machines concurrently. Any additional virtual machine exports are queued until one of the four active exports finishes.

Note

Even though you can export four virtual machines concurrently and queue others, you might have restrictions from Oracle Cloud Infrastructure based on your account.

When you use the Oracle VM Exporter Appliance, keep in mind:

  • virtual machines can be exported more than once.

  • the export process is tracked like all Oracle VM Manager jobs, but can be resumed if you abort it or if it stops because of an error.

  • you need an active Oracle VM account and an active tenancy and active user account in Oracle Cloud Infrastructure.

For more information about the Oracle VM Exporter Appliance, see:

7.8 What are VM States?

Oracle VM Manager tracks the different running states for each virtual machine at regular intervals. At any point, it is possible to check the running state for any virtual machine within the Oracle VM Manager Web Interface or the Oracle VM Manager Command Line Interface. There are six different running states that apply to virtual machines within Oracle VM Manager. The following list describes each running state and the scenarios that apply to each of these:

Virtual Machine States

  • STARTING:

    • A virtual machine is set to the STARTING state after either a vmStart operation or a vmRestart operation (when the restart action is set to restart).

  • RUNNING:

    • A virtual machine is set to the RUNNING state when the Oracle VM Agent on the Oracle VM Server, where the virtual machine is hosted, sends Oracle VM Manager a notification that the virtual machine has started. The Oracle VM Agent only detects whether the domain itself is running, but does not report on whether the guest operating system is running or not.

    • If a virtual machine is found to be running on an Oracle VM Server during the discovery process, its state is set to RUNNING.

  • STOPPING:

    • When an attempt is made to stop, restart or suspend a virtual machine, its state is immediately set to STOPPING.

  • STOPPED:

    • A virtual machine's state is set to STOPPED when Oracle VM Manager is notified by an Oracle VM Server that the virtual machine was shutdown. This can be due to a stop or kill action initiated via Oracle VM Manager or by a shutdown initiated on the virtual machine itself.

    • This state can also occur if, during discovery, a virtual machine that was previously in some other state, is detected as not running.

    • If the start operation for a virtual machine fails, the state of the virtual machine is changed from STARTING to STOPPED.

    • If the Oracle VM Server, where a virtual machine is running, cannot be reached and is transitioned to a STOPPED state, all virtual machines active on the same Oracle VM Server are also set to STOPPED and marked with OFFLINE events. It may take up to one minute for these virtual machines to transition to this state in the case that an Oracle VM Server becomes unavailable. Any attempt to perform an operation on a virtual machine during this transitional period is likely to fail as Oracle VM Manager is unable to communicate with the Oracle VM Server hosting the virtual machine to perform the operation.

  • SUSPENDED:

    • A virtual machine's state is set to SUSPENDED if a suspend operation completes successfully.

    • This state can also occur if, during discovery, a virtual machine is detected to be suspended. This is considered to be the case if the virtual machine is stopped and contains a suspend file.

  • TEMPLATE:

    • This state represents a type of virtual machine that can never be started. A virtual machine in this state is unable to transition to any other run state.

Actions that can be performed on virtual machines depend on these states. Therefore the following rules apply with regard to the relationship between virtual machine states and the actions that can be performed on a virtual machine:

Relationship between Virtual Machine States and Actions

  • START: Can only be performed when the virtual machine is in the STOPPED state.

  • RESTART: Can only be performed when the virtual machine is in the RUNNING state.

  • STOP: Can only be performed when the virtual machine is in the RUNNING state.

  • KILL: Runs regardless of the current state of the virtual machine and forces it into a STOPPED state. This action does its best to destroy the domain on the hosting Oracle VM Server. If HA is enabled it also clears the HA flag so that the virtual machine does not restart.

  • SUSPEND: Can only be performed when the virtual machine is in the RUNNING state.

  • RESUME: Can only be performed when the virtual machine is in the SUSPENDED state.

  • MIGRATE: Can only be performed when the virtual machine is in the RUNNING state.

7.9 Editing Virtual Machine Parameters

It is possible to edit the parameters that are used to start any virtual machine within Oracle VM using Oracle VM Manager. Typical changes may include updating the key map, mouse device type, memory or CPU allocation or to enable huge page support. It is important to understand that these parameters are runtime parameters used by the hypervisor to initialize a virtual machine. This means that making changes to these parameters do not have an immediate effect on a running virtual machine. For changes to take effect, the virtual machine must be stopped and then started again, so that the hypervisor is forced to reload the virtual machine configuration. A simple restart does not have the same effect, since the hypervisor does not reload the virtual machine configuration for this event.

7.10 Sending Messages to Virtual Machines

Sending a message to a virtual machine may be useful during certain situations, like developing or starting a virtual machine template. Messages are passed to the virtual machine operating system, and can be of any key/value pair that the operating system or template understands. For example, to set up a virtual machine template to use DHCP, you may want to send the following key/pairs to a virtual machine: 

com.oracle.linux.network.device.0       eth0
com.oracle.linux.network.onboot.0       yes
com.oracle.linux.network.bootproto.0    dhcp
com.oracle.linux.root-password          password
Note

The com.oracle.linux.root-password is always required as a parameter and should be sent as the final parameter for any message.

Any messages that are not understood are discarded and ignored by the operating system. You can hide the message for sensitive information such as passwords, so a series of asterisks are displayed in the user interface instead of the sensitive information.

You can optionally keep a log of the message. This feature is especially useful to template or application developers that want to send messages to virtual machines. Message logs are stored by Oracle VM Manager and are not available through any log file or database query. To gain access to these messages, you must use the Oracle VM Web Services API. Messages are limited to 1024 bytes when message logging is selected, or 8192 bytes when logging is not selected. They key is limited to 256 bytes.

Each message sent to a virtual machine is contained within its own job. If you send multiple messages to multiple virtual machines, each one has its own job, so 10 messages to 100 virtual machines produces 1,000 jobs.

To send a virtual machine a message you must have first installed the Oracle VM Guest Additions in the virtual machine. For information on installing the Oracle VM Guest Additions, see Installing and Using the Oracle VM Guest Additions in the Oracle VM Administrator's Guide. For information on sending messages to a virtual machine, see Send VM Messages in the Oracle VM Manager User's Guide.

7.11 Accessing the Virtual Machine Console

You can connect to a virtual machine using its console. The console is the remote control system of Oracle VM, and enables you to work and interact directly with your virtual machines.

There are two types of virtual machine consoles in Oracle VM Manager: a VNC console used to connect to virtual machines in x86-based server pools, but which is not supported for SPARC-based server pools; and a serial console used to connect to the terminal console of a virtual machines and most commonly used for SPARC-based server pools.

Note

You can use the serial console to connect to a Linux guest virtual machine in an x86-based server pool, if the guest supports a serial console, but the console is in read-only mode, and you cannot interact with the virtual machine using the serial console. Furthermore, additional configuration is required within the guest virtual machine to enable this facility. Therefore, use of the serial console should be limited to virtual machines that run within a SPARC-based server pool, and the VNC console should be used to access virtual machines running in an x86-based server pool instead.

The console functionality is contained within a specific RPM that is available on the Oracle VM Manager Installation ISO.

There are versions of this package for various Oracle Linux operating systems. The package for Oracle Linux 6, for example, is ovmcore-console-x.y-z.el6.noarch.rpm.

It is not necessary to install these packages on the Oracle VM Manager host as the installation is handled automatically by the Oracle VM Manager installer. If these packages are already installed from a previous installation of Oracle VM Manager, they may be upgraded automatically during the installation or upgrade process. If Oracle VM Manager is uninstalled, these packages are removed as part of the uninstallation.

There is no requirement to install or run any additional software on the client system accessing the virtual machine console.

7.11.1 VNC Console for x86

The VNC console is developed on top of the noVNC VNC client and runs on the Oracle VM Manager host. The noVNC client is a web-based VNC client that is rendered using HTML5 WebSockets and Canvas. You can find out more about this software at http://kanaka.github.io/noVNC/ .

Note that to use these console services, your web browser must fully support the HTML5 Canvas and WebSockets elements. The list of supported web browsers presented in Web Browser Requirements in the Oracle VM Manager User's Guide covers all browsers that also provide the necessary support to make use of the virtual machine consoles included in Oracle VM Manager.

No additional software needs to be installed on the Oracle VM Servers or virtual machines to use the VNC console.

Oracle VM Manager uses a secure tunnel to protect the virtual machine console (remote connection utility) data across the network. Oracle VM Manager does not communicate directly with the VNC client, but rather connects via an SSH-encrypted tunnel on port 69xx (where xx is based on the guest to which it is connecting).

Any firewall between the Oracle VM Manager and the Oracle VM Servers needs ports 10000 and above open; one port for each virtual machine on an Oracle VM Server. For example, if you have 100 virtual machines on an Oracle VM Server, you should open ports 10000-10099 (100 ports) on any firewall between the Oracle VM Server and Oracle VM Manager.

See Launch Console for more information on using and configuring the VNC client.

7.11.2 Oracle VM Server Serial Console for x86 and SPARC

You cannot use the standard VNC console to connect to virtual machines on a SPARC-based server pool. Instead, use the serial console. The serial console can also be used to connect to virtual machines running on x86-based server pools although the console, in this case, is read-only and non-interactive.

The serial console makes use of the jsTerm terminal emulator, which is a web-based terminal emulator that can be used to facilitate telnet-type connections using HTML5 WebSockets and Canvas.

Note that to use these console services, your web browser must fully support the HTML5 Canvas and WebSockets elements. The list of supported web browsers presented in Web Browser Requirements in the Oracle VM Manager User's Guide covers all browsers that also provide the necessary support to make use of the virtual machine consoles included in Oracle VM Manager.

No additional software needs to be installed on the Oracle VM Servers or virtual machines to use the serial console.

Any firewall between the Oracle VM Manager and the Oracle VM Servers needs ports 7900 and above open; one port for each virtual machine on an Oracle VM Server. For example, if you have 100 virtual machines on an Oracle VM Server, you should open ports 7900-7999 (100 ports) on any firewall between the Oracle VM Server and Oracle VM Manager.

See Launch Serial Console for more information on using the serial console to connect to virtual machines in SPARC-based server pools.

7.12 How Can I Protect Virtual Machines?

You can protect the resources on an Oracle VM Server by restricting whether new virtual machines can be created on it or migrated to it. By doing this, you can make sure the resources of an Oracle VM Server are available to the virtual machine(s) running on the server. You can set this up for an Oracle VM Server by using the inbound migration lock feature.

This feature overrides server pool policies and anti-affinity groups, and any of these other features or policies that can result in the migration of a virtual machine onto the Oracle VM Server. However, if you have HA configured for a server, this feature does not protect a server from inbound migrations when failover occurs.

This feature allows you to set whether to allow additional virtual machines to run on the Oracle VM Server, but does not prevent virtual machines running on the Oracle VM Server from being migrated to another Oracle VM Server.

For more information on using the inbound migration lock feature, see Edit Server in the Oracle VM Manager User's Guide.

7.13 How are Virtual CPUs Allocated to Virtual Machines?

When you create or edit a virtual machine, you have the option to specify two different values for the number of processors (also known as virtual CPUs) that are allocated to a virtual machine. These represent:

  • the maximum number of virtual CPUs that can be made available to a running virtual machine (maxvcpu)

  • the actual number of virtual CPUs that a virtual machine should be using at runtime (vcpu)

The number of virtual CPUs that the virtual machine actually has available at any one time is dynamically allocated by the hypervisor as required, by changing the number of processors (vcpu) for the running virtual machine within Oracle VM Manager. This value can never exceed the maximum number of processors (maxvcpu) that you have also specified within Oracle VM Manager.

If you want to change the maximum number of virtual CPUs (maxvcpu) that a virtual machine can have, the virtual machine must be rebooted after this value is changed. The maximum number of virtual CPUs (maxvcpu) cannot exceed the values described in the Oracle VM Release Notes.

Guest virtual machine boot behavior, in relation to virtual CPU allocation, differs depending on the mode of virtualization that the guest is configured for. Modes of virtualization are discussed further in Section 7.1, “What are Virtualization Modes or Domain Types?”. For instance, for a paravirtualized virtual machine (PVM), the guest virtual machine boots with as many virtual CPUs as are specified for the maximum number of processors (max_vcpu) in Oracle VM Manager and then works its way down to the configured number of processors (vcpu) that should be available to the virtual machine at runtime. If the difference between these two values is large, then it may take some time before the guest virtual machine is actually running with the specified number of virtual CPUs (vcpu). On the other hand, a hardware-virtualized virtual machine (HVM) boots with exactly the number of virtual CPUs (vcpu) that are specified in the configuration.

Once the virtual machine is running with the specified number of virtual CPUs, you can increase or decrease this value within Oracle VM Manager as required, and the number of processor cores available to the running guest operating system is automatically adjusted.

Oracle VM permits over-subscription of the host server's physical CPUs. This means the total number of virtual CPUs, allocated to all virtual machines combined, can exceed the number of physical CPUs. CPU over-subscription can be used to increase VM density and server resource utilization, which reduces the total cost of computing. It has no negative impact on VM performance as long as there is sufficient CPU capacity, especially for workloads that are not compute-intensive: CPU resources not consumed by an idle VM can be used by other VMs. It is the administrator's task to monitor CPU allocation and prioritization so that VMs have sufficient processing power to meet their service objectives.

Note

For details about virtual machine configuration, administration and health monitoring, refer to the following sections in the Oracle VM Manager User's Guide:

For further information on performance optimization goals and techniques for Oracle VM Server for x86, see Optimizing Oracle VM Server for x86 Performance, on Oracle Technology Network at: http://www.oracle.com/technetwork/server-storage/vm/ovm-performance-2995164.pdf.

7.14 Limitations for Hot-Changing Virtual Components Within A Virtual Machine

The possibility to change the number of virtual components, while the virtual machine is running, is limited by the kernel and operating system of the virtual machine itself. Guest kernel support for these features falls outside of the control of Oracle VM Manager, but the following guidelines are based on internal test data:

Oracle Linux

For guests that are running Oracle Linux, the ability to hot-add and hot-remove virtual CPUs is fully dependent on the kernel version that is installed on the guest. The minimum kernel version that has been shown to fully support the ability to hot-add and hot remove virtual CPUs is UEK2 QU5 v2.6.39-400.211.1. All supported versions of Oracle Linux are capable of hot-adding and hot-removing virtual disks. Support for hot-adding and hot-removing RAM on a guest running Oracle Linux is available with PVM (Oracle VM 3.4.1 and higher) and PVHVM (Oracle VM 3.4.2 and higher). It is also possible to hot-add virtual network interface cards.

Oracle Solaris for SPARC

All versions of Oracle Solaris running on a SPARC platform are capable of supporting the ability to hot-add and hot-remove virtual CPUs as required. Other components such as RAM and hard disks are also hot-swappable. It is also possible to hot-add virtual network interface cards.

It is important to note that when adding or removing memory for a running virtual machine on Oracle VM Server for SPARC, the request to add or remove memory may only be partially fulfilled. This is standard behaviour. For more information, see the Using Memory Dynamic Reconfiguration section in the Oracle VM Server for SPARC Administration Guide.

Note

Access the Oracle VM Server for SPARC documentation at http://www.oracle.com/technetwork/documentation/vm-sparc-194287.html. To determine the version of the Oracle VM Server for SPARC documentation to reference, run the pkg list ldomsmanager command.

In such a case, Oracle VM Manager does not report any error after the memory add or remove operation, and indicates that the entire operation has succeeded. However the virtual machine may actually be allocated an amount of memory different from the amount indicated by Oracle VM Manager. The correct amount of memory is restored when the virtual machine is stopped and then restarted.

Oracle Solaris for x86

Guests running Oracle Solaris on an x86 platform do not have the same capabilities and the ability to hot-add and hot-remove virtual CPUs and RAM are not supported. However, as of Solaris 11, you are capable of hot-swapping hard disks. It is also possible to hot-add virtual network interface cards. Virtual machines running Oracle Solaris on an x86 platform are incapable of hot-removing a virtual CD-ROM device, due to the driver type used on this platform.

Microsoft Windows

Guests running Microsoft Windows are not capable of supporting the option to hot-add virtual CPUs or memory. Hot-swappable virtual disks and the ability to hot-add virtual network interfaces are supported, as long as the Oracle VM Paravirtual Drivers for Microsoft Windows are installed.

7.15 How is the HugePages Feature Enabled for Virtual Machines?

Paging is a process whereby the CPU, for a system, allocates contiguous blocks of memory for use by a running process. These pages are tracked by the operating system, so that processes access the correct blocks of assigned memory. Typically, these blocks are sized at 4 KB. This means that when a process uses 1 GB of memory, 262144 page (1 GB/4 KB) entries are created and are referenced continually by the process.

Most current CPU architectures support bigger pages to reduce the number of page lookups required by the CPU or Operating System. On Linux systems, these are called HugePages, while on Windows systems they are called Large Pages. These terminologies are equivalent.

By default, HugePages are available for hardware virtualized virtual machines (HVM and PVHVM) when the new virtual machine is created.

For paravirtualized virtual machines (PVM), the Xen hypervisor must start the virtual machine with a specific parameter set to enable HugePages support. Oracle VM Manager provides an option to enable HugePages support for a paravirtualized virtual machine when you create or edit a virtual machine. However, the HugePages feature is deprecated for PVM guests as of Oracle VM Release 3.4.1. You should not enable HugePages when creating or editing PVM virtual machines in the Oracle VM Manager Web Interface or Oracle VM Manager Command Line Interface. This feature will be removed in a future release of Oracle VM.

You should not attempt to enable HugePages support for an HVM or PVHVM within Oracle VM Manager, as this functionality is not handled by the Xen hypervisor, but rather by the virtual machine itself.

If you have HugePages enabled for any PVM guests, Oracle recommends that you change the domain type for virtual machines from Paravirtualized (PVM) to Hardware virtualized, with paravirtualized drivers (PVHVM). If you cannot change the domain type for a virtual machine, you should disable the HugePages setting and then restart the virtual machine.

For HugePages to be supported in the virtual machine, depending on the operating system of the virtual machine, HugePages may need to be enabled inside the virtual machine. For example, in Linux, this is done by specifying the Linux boot command line flag balloon_hugepages inside the virtual machine.

For virtual machines running on SPARC architecture, HugePages are referred to as Large Pages and are always enabled by default. The Oracle VM Manager setting to enable or disable HugePages support has no effect on virtual machines running on Oracle VM Server for SPARC.

High Availability (HA) takes precedence over HugePages rules. For example, you have a server pool with two servers running in it. You enable HugePages on the virtual machines running on server A. You do not enable HugePages on the virtual machines running on server B. You also enable HA for all virtual machines on both servers. If either server A or server B stops running, then the virtual machines are migrated to the server that is still running. This migration occurs despite the rule that prevents virtual machines with different HugePage settings running on the same server.

See Create Virtual Machine in the Oracle VM Manager User's Guide for more information on this option.

7.16 Setting Hard Partitioning for Virtual Machine CPUs

Oracle VM offers an advanced feature for hard partitioning, also known as CPU pinning. Hard partitioning means binding a virtual machine CPU to a physical CPU (on x86) , and preventing it from running on other physical cores than the ones specified. This is done for Oracle CPU licensing purposes, since Oracle VM is licensed on a per-CPU basis.

CPU pinning cannot be configured using Oracle VM Manager; it can only be set up using the Oracle VM Utilities. For more information, see Oracle VM Virtual Machine Control (ovm_vmcontrol) in the Oracle VM Administrator's Guide.

Hard partitioning is described in its own technical paper available on the Oracle Technology Network. This technical paper describes setting up hard partitioning using the Oracle VM Utilities. The hard partitioning technical paper is titled Hard Partitioning With Oracle VM Server for x86 and located at:

http://www.oracle.com/technetwork/server-storage/vm/ovm-hardpart-168217.pdf

Warning

Live-migration of CPU pinned virtual machines to another Oracle VM Server is not permitted under the terms of the license. Consequently, DRS and DPM policies should not be enabled for server pools containing CPU pinned guests.

Note

If your Oracle VM Servers support NUMA (non-uniform memory access), make sure that the systems are running correctly in NUMA mode. In a clustered setup, a CPU can access its local memory faster than non-local and shared memory. To make full use of the performance advantages of NUMA, be sure to pin the virtual VCPUs to the same physical CPU on an Oracle VM Server. For more information about NUMA, consult your server hardware documentation.

For information about special Oracle hard partitioning licensing policies, see the Oracle Technology Network and open the PDF document on the subject of Partitioning located at:

http://www.oracle.com/us/corporate/pricing/specialty-topics/index.html

7.17 How are Virtual Machines Backed Up?

Virtual machine backup is not handled directly by Oracle VM. However, there are a number of approaches to virtual machine backup that can take advantage of facilities already provided within Oracle VM. Most commonly virtual machine backup is achieved by performing cloning of a virtual machine. For the best possible result, this should be performed as a cold clone (i.e. where the virtual machine is stopped) as this ensures better data integrity. Cloning is discussed in more detail in Section 7.6, “How does Cloning Work?”.

It is equally possible to stop a virtual machine and then create a backup of the virtual machine files stored in the repository that is used for the server pool.

A more comprehensive discussion of virtual machine backup strategies is provided in Backing up Virtual Machines in the Oracle VM Administrator's Guide.

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