Oracle VM
Oracle VM
com/book/export/html/844
Change Log
The information found in this publication was gathered from many different sources in the computing world. It is provided for
informational purposes only. Use common sense in applying these concepts and tips. Screen shots may vary from environment to
environment. Please verify correctness and applicability in a test environment first and then deploy to your production
environment(s).
Trademarks
Trademarked names appear throughout this publication. Rather than listing the names and entities that own the trademarks or
include a trademark symbol with each mention of the trademark name, the publisher states that he is using the name for editorial
purposes only and to the benefit of the trademark owner, with no intention of infringing upon that trademark.
Audience
This book is intended to assist solution architects, sales engineers, field engineers and consultants in planning, designing, deploying
and supporting Oracle VM for x86 in internal and external clouds. This book assumes that the reader has an architectural
understanding of cloud computing, Oracle technologies, storage and network system, and related software.
Objectives
This book is intended to articulate the design considerations and validation efforts required to design, deploy and support Oracle VM
for x86 in an internal or external cloud.
Chapters at a Glance
Chapter 1: Oracle VM Introduction
Chapter 2: Oracle VM for x86 Reference Design and Architectural Introduction
Chapter 3: Hard and Soft Partitioning Oracle Technologies with Oracle VM
Chapter 4: Oracle VM Server Sizing, Installation and Updates
Chapter 5: Oracle VM Manager Sizing, Installation, Updates and the Oracle VM Manager Command Line Interface
...Oracle VM 2.1.5 to 2.2 Upgrade
Chapter 6: Oracle VM 2.2 SAN, iSCSI and NFS Back-end Storage Configurations
Chapter 7: Oracle VM Networking from A to 802.1Q
Chapter 8: Virtualizing Oracle Database 10g/11g
Chapter 9: Virtualizing Oracle Enterprise Manager 10g
Oracle VM Centralized Logging
The Virtualization Policy Project
Show a printer friendly version of this book with its sub pages
Table of Contents
Change Log
The Evolution of Oracle VM for x86
Oracle VM for x86 Introduction
...Oracle VM for x86 Virtualization Modes
...Oracle VM for x86 Packaging and Pricing
Accelerating Application Deployments with Oracle VM for x86
...Virtual Machine Cloning
...Oracle VM Templates
…...Oracle VM Templates Packaging and Pricing
...Oracle VM Template Builder
…...Oracle VM Template Builder Packaging and Pricing
...Oracle Virtual Assembly Builder
…...Oracle Virtual Assembly Builder Packaging and Pricing
...Oracle JRockit Virtual Edition
…...Oracle JRockit Virtual Edition Packaging and Pricing
The Oracle VM Management Pack Plug-in
Oracle's x86 Virtualization Support Policy
Change Log
Oracle and non-Oracle workloads, backed by Oracle's world-class support organization. With the release of Oracle VM for x86, Oracle
had a flagship x86 server virtualization solution and a clear x86 server virtualization strategy.
Note: The first release of Oracle VM for x86 was version 2.1. An Oracle colleague explained to me that Larry Ellison avoids using 1.0
for Oracle product releases to help drive early adoption.
In August 2008, Oracle announced the release of Oracle VM templates. Oracle VM templates are self-contained preconfigured virtual
machines with key Oracle technologies, which can be downloaded from the Oracle Linux eDelivery portal and quickly deployed into
production using Oracle VM for x86. Oracle VM templates completely eliminate the operating system and application installation
process, reducing risk and dramatically shortening Oracle application deployment timelines.
In August 2009, Oracle announced the release of Oracle VM Template Builder. Oracle VM Template Builder is an application-
packaging studio that generates preconfigured, reusable Oracle VM templates with Oracle and non-Oracle applications on Oracle
Linux JeOS (just enough operating system). Oracle Linux JeOS is a customizable small-footprint x86 and x86-64 Oracle Linux
operating system.
On January 27, 2010 Oracle completed the acquisition of Sun Microsystems, which added Sun's software and hardware assets to
Oracle's product portfolio. Shorty after the Sun acquisition, Oracle rebranded numerous Sun virtualization technologies with the
Oracle VM product name and created the Oracle VM product family with the following three separate product lines: Oracle VM for
x86, Oracle VM for SPARC (formally LDOMs), and Oracle VM VirtualBox. Each product line has add-on products that extend the
functionally of the line. Then, Oracle announced Oracle Virtual Assembly Builder and JRockit Virtual Edition. Oracle Virtual Assembly
Builder and JRockit Virtual Edition extended Oracle VM templating into the Oracle Fusion Middleware product portfolio.
With the addition of Oracle VM templates, Oracle VM Template Builder, Oracle Virtual Assembly Builder, and JRockit Virtual Edition,
Oracle VM for x86 was transformed from a x86 server-virtualization solution into Oracle's next-generation application delivery
platform.
The next sections will examine Oracle VM for x86, Oracle VM templates, Oracle VM Template Builder, Oracle Virtual Assembly
Builder, JRockit Virtual Edition and the Oracle VM Management Pack.
Operating system and application installations can be very time consuming. Oracle VM for x86 offers next-generation operating
system and application packaging and deployment features that eliminate the traditional operating system and application installation
process. Oracle VM for x86 enables operating system and application configurations to be packaged in preconfigured, reusable
virtual-machine templates. Virtual machine templates can consist of a single virtual machine or a group of virtual machines, called an
assembly. Virtual machine templates can be rapidly redeployed an unlimited number of times as copies of an original virtual machine
or virtual machine assembly, or as a unique new virtual machine or virtual machine assembly.
The Oracle VM for x86 is a type 1 hypervisor that installs directly on x86-64 hardware, enabling multiple concurrently running virtual
machines to share a single piece of hardware. Each virtual machine has its own operating system, kernel, virtual CPUs, RAM, network
interfaces, storage, and applications. Oracle VM for x86 increases server utilization by breaking the traditional one-workload-per-box
approach to server provisioning while making operating systems and enterprise applications easier to deploy, manage, and support by
eliminating the operating system and application installation process.
Oracle VM for x86 consists of an x86 server component and a manager component used to manage one or more clustered servers.
The server component is based on the open source Xen.org hypervisor, and is called Oracle VM server. The Xen hypervisor is a thin
layer of code that installs directly on hardware that enables multiple guest operating systems to run concurrently on a single piece of
hardware. Xen has emerged as the industry open standard for x86 virtualization, with broad adoption from ISVs such as Oracle, IBM,
HP, Dell, and Citrix, and cloud providers such as Amazon AWS, Savvis Cloud Services, and Rackspace Cloud. Oracle makes subtle
changes to the original Xen.org code that create a unique Xen distribution, which Oracle maintains and redistributes as Oracle VM
server. Oracle VM server was designed to support the most demanding high I/O workloads like Oracle Database products and Oracle
Exalogic, which other hypervisors and Xen distributions are unable to support.
The manager component is a traditional Oracle application, named Oracle VM Manager, that installs on Oracle Linux and Red Hat
Enterprise Linux. Oracle VM Manager is used to manage one or more clustered Oracle VM servers, virtual machines, and virtual
machine resources. Oracle VM Manager is a traditional Oracle application consisting of an Oracle database, an Oracle application
server, and a J2EE application with an OS-/browser-neutral Oracle Application Development Framework (ADF) administrative portal.
All of the Oracle VM Manager components can be installed in an all-in-one configuration on an Oracle Linux virtual machine or in a
multiple node HA configuration. Oracle VM Manager is distributed from the Oracle Linux eDelivery portal as an ISO file and as a
preconfigured, production-ready Oracle VM template.
Paravirtualization mode requires the virtual machine operating system to run a Xen kernel and Xen network and I/O drivers. Xen
paravirtualized kernels ship along with the default Linux kernel with Oracle Linux and Red Hat Enterprise Linux operating systems.
Paravirtualized virtual machines are hypervisor aware and run without the additional overhead of hardware emulation.
Paravirtualization offers much less overhead with timers, interrupts, I/O traffic, and context switches, allowing superior scalability
under heavy loads when compared to hardware virtualization mode.
Unlike paravirtualization mode, which requires the virtual machine to run a Xen kernel, hardware virtualization mode supports native
unmodified operating systems. Virtual machines that run under hardware virtualization mode are called hardware virtualized
machines (HVM). Hardware virtualized machines are unaware that they have been virtualized and think they are on physical
hardware. To provide acceptable performance, hardware virtualized machines need to use paravirtualized network and I/O drivers.
From Oracle Linux and Red Hat Enterprise Linux 4.7 onwards, the stock kernels provide paravirtualized network and I/O drivers for
hardware virtualized guests. From Solaris 10 10/09 onwards, the stock kernels provide paravirtualized network and I/O drivers for
hardware virtualized machines. Windows does not have native paravirtualization support, although Windows virtual machines can run
as hardware virtualized machines using Oracle's paravirtualized network and I/O drivers. Oracle has released paravirtualized network
and I/O drivers for the Windows operating system that can be freely downloaded from the Oracle Linux eDelivery portal.
In hardware virtualization mode, the hypervisor, the Intel or AMD virtualization technologies, and dom0 with QEMU work in concert
to emulate hardware for hardware virtualized machines. Hardware virtualization mode has a higher overhead than paravirtualization
mode, due in part to the overhead of emulating hardware for hardware virtualized machines.
Table 1 shows the guest operating system support matrix for Oracle VM for x86. 2.2.x
*Oracle Linux
* * * *
6.x
Oracle Linux
* * * *
5.x
Oracle Linux
* * * *
4.x
*Red Hat
Enterprise * * * *
Linux 6.x
Red Hat
Enterprise * * * *
Linux 5.x
Red Hat
Enterprise * * * *
Linux 4.x
Red Hat
Enterprise * *
Linux 3.x
Microsoft
* *
Windows 2000
Microsoft
* *
Windows 2003
Microsoft
Windows XP * *
Pro
Microsoft
* *
Windows Vista
Microsoft
* *
Windows 7
Microsoft
Windows 2008 * *
SP1
Microsoft
Windows 2008 *
R2
Oracle Solaris
* *
10 10/09+
Oracle Solaris
* *
11 Express
* Oracle VM 2.2.x does not have native ext4 support, therefore Oracle Linux 6 and Red Hat Enterprise Linux 6 virtual machines must
use ext3 for the /boot partition to be able to boot.
Premier Support for Systems costs 12% of the net Sun system purchase price and includes comprehensive support for the system
hardware and firmware, as well as operating system support for Solaris x86, Solaris 11 Express, Oracle Linux, and Oracle VM for x86.
Along with hardware and firmware support, Premier Support for Systems includes operating system support for one or more virtual
instances Oracle Linux, Solaris 10 x86, and Solaris 11 Express x86 running on Oracle VM for x86.
Support for Oracle VM for x86 for third-party hardware is sold in two packages: Oracle VM Premier Limited support for servers with
up to two sockets and Oracle VM Premier support for servers with more than two sockets. Support for Oracle VM for x86 for
third-party hardware only includes support for Oracle VM for x86. Operating System support for Oracle Linux, Red Hat Enterprise
Linux, Solaris x86, Solaris 11 Express, and Windows virtual machines running on Oracle VM for x86 must be purchased separately.
The next section will examine how to accelerate application deployments using the Oracle VM for x86 product line and add-on
products.
system and application installations. Oracle offers five unique options for accelerating application deployments using the Oracle VM
for x86 product line:
List 1: Five options for accelerating application deployments using Oracle VM for x86.
The next sections will examine virtual machine cloning, Oracle VM Templates, Oracle VM Template Builder, Oracle Virtual Assembly
Builder, and will conclude with Oracle JRockit Virtual Edition.
Virtual machine cloning accelerates application development and testing by reducing the time required to deploy a clean operating
system environment for application testing. For example, using Oracle VM Manager, a virtual machine can be saved as a clone or
saved as a template and then the clone or the template can be rapidly redeployed an unlimited number of times as copies of the
original virtual machine or as unique new virtual machines.
Note: The minimum requirement to create and Oracle VM templates is an Oracle VM server managed by Oracle VM Manager.
Virtual machine cloning is an Oracle VM Manager image management feature. The Oracle VM Manager clone and save-as-template
features offer sparse and nonsparse virtual machine image provisioning. The term “sparse” is commonly referred to as “thin
provisioning,” in contrast to nonsparse, which is referred to as “thick provisioning”.
A thin-provisioned clone will not write the parent virtual machine's zeroed blocks to disk, whereas a thick clone will copy all of the
parent virtual machine's blocks to disk. Thin-provisioned disks grow proportionally to the number of writes to the disk by the virtual
machine, so that large portions of the unused disk do not consume space.
As of this writing, both thin and thick clone provisioning are off-line operations, meaning that the parent virtual machine must be
powered off to create a clone. The advantage of selecting thin provisioning for clones is that the storage is allocated only when
needed, which reduces the time it takes to create clones in addition to saving disk space. The disadvantage of using thin provisioning
is that the file system free-space reports may be misleading. For example, since thin-provisioned disks are allocated only when
needed, the file system free space reports may not be accurate since large portions of unused disk, that is, the zeroed blocks, have not
yet been written to disk.
Tip: Some applications do not support copying sparse files and may copy the entire uncompressed size of the file including the sparse
sections.
For more information on virtual machine cloning please refer to Chapter 5. For more information about Oracle VM Storage, please
refer to Chapter 6.
Oracle VM Templates
Operating system and Oracle application installations can be very time consuming. The Oracle VM for x86 Template program was
created to accelerate Oracle application deployments by offering self-contained, preconfigured virtual machines with key Oracle
technologies. Oracle VM templates can be downloaded from the Oracle Linux eDelivery portal and rapidly deployed an unlimited
number of times using Oracle VM for x86. The minimum requirement to run Oracle VM Template Builder and Oracle VM templates is
an x86-64 server with Oracle VM for x86, Oracle VM Manager is optional although highly recommended.
1. Copy the Oracle VM template zip file to your Oracle VM server's /OVS/running_pool directory.
2. Unzip and untar the files in the /OVS/running_pool directory.
3. Import the Oracle VM Template using Oracle VM Manager.
4. Start the Oracle VM template using Oracle VM Manager.
5. Access the Oracle VM template's console and select the initial boot-time options.
An Oracle VM template can consist of one or more virtual machines containing a preconfigured Oracle operating system and Oracle
technology products. Using Oracle VM templates eliminates the operating systems and Oracle application installation and
configuration process, which dramatically shortens application deployment timelines. There is no other vendor in the x86
virtualization market that can offer pre-packaging of production ready enterprise applications.
Applications
Middleware
Operating System
Third-party Software
An Oracle VM template license includes a free download and free trial use of the Oracle technologies with the option to purchase a
product license. Oracle VM templates do not have time limits or feature limitations. Oracle VM templates can be quickly transitioned
from evaluations into test, development. or production by purchasing the Oracle technology product license.
Oracle frequently updates Oracle VM templates and adds new Oracle VM templates to the Oracle Linux eDelivery portal. The best
way to stay up to date about Oracle VM templates is to visit ITNewsCast's Oracle VM section.
For information on how to get and deploy Oracle VM templates, please refer to Chapter 8 and Chapter 9.
Oracle Linux JeOS (just enough operating system) as a preconfigured, reusable Oracle VM template. Oracle Linux JeOS is a
prepackaged, customizable small-footprint x86 and x86-64 Oracle Linux operating system.
Deploying preconfigured Oracle VM templates eliminates the entire operating system and application installation and configuration
process. Oracle VM Template Builder dramatically shortens application deployments by packaging unique application configurations
within preconfigured Oracle VM templates that can be rapidly deployed one or more times using Oracle VM for x86. The minimum
requirement to run Oracle VM Template Builder and Oracle VM templates is an x86-64 server with Oracle VM for x86, Oracle VM
Manager is optional although highly recommended.
Note: Oracle VM Template Builder is the application Oracle uses to create Oracle VM templates.
Oracle VM Template Builder templates are designed to be configured at the initial boot time to ensure that each template has unique
operating system and application configurations. The initial boot time configuration selections can be default values and/or actions
based on the user’s input.
Note: Oracle Linux JeOS is shipped with only English language support. Additional language packages for JeOS are available from
Oracle Linux eDelivery portal.
Oracle VM templates can be built and used by anyone including Oracle, ISVs, Oracle Partners, VARs, and end users. JeOS Oracle VM
templates can be redistributed without an agreement from Oracle. Redistributing templates with applications may or may not be
allowed. It is necessary to consult with the ISV to determine if their application can be legally redistributed within an Oracle Linux
JeOS template.
Packaging software applications with Oracle VM Template Builder requires a thorough understanding of the software application's
behavior. This particularly applies to the Oracle VM JeOS template reconfiguration and cleanup scripts used in the Oracle VM JeOS
template.
Creating Oracle VM JeOS templates is a multistep process. The number of steps to create an Oracle VM template depends on the type
and complexity of the application software added to the Oracle VM JeOS template.
Oracle VM Template Builder and Oracle's JeOS are open source, free to download, free to use, and free to redistribute.
Assemblies are created and managed using the Oracle Virtual Assembly Builder Studio, which is a standalone administrative
application. Oracle Virtual Assembly Builder Studio integrates with Oracle VM for x86 using the Oracle VM Manager API. The
minimum requirements for Oracle Virtual Assembly Builder are a) Oracle Virtual Assembly Builder Studio, b) Oracle VM for x86
server pool, c) Oracle VM Manager, and d) a physical and/or virtual reference Oracle Fusion Middleware environment to introspect.
The current release of Oracle Virtual Assembly Builder is 11g Release 1 (11.1.1). Oracle Virtual Assembly Builder 11g Release 1
works exclusively with Oracle VM for x86 2.x. Oracle describes the this release as a developer-centric release, as opposed to an
enterprise release, due to the lack of enterprise security features, such as root access to files and directories and the absence of
role-based access. The next release of Oracle Virtual Assembly Builder should be an enterprise release with the enterprise security
features, broader Oracle Fusions Middleware application support, and Oracle VM 3.0 integration.
Oracle Virtual Assembly Builder is not a standalone Oracle technology product that can be purchased a la carte. The right to use
Oracle Virtual Assembly Builder is bundled with WebLogic Enterprise Edition. The only way to purchase Oracle Virtual Assembly
Builder is by purchasing WebLogic Enterprise Edition licenses.
Note: I intend to add a chapter about the next enterprise release of Oracle Virtual Assembly Builder. Please stay tuned to
ITNewsCast.com and the underground Oracle VM Manual for the new Oracle Virtual Assembly Builder chapter.
Figure 2 shows an Oracle JRockit Virtual Edition appliance, highlighting the JRockit Virtual Edition OS layer.
The Oracle JRockit Virtual Edition OS layer contains a purpose-built kernel that contains only the essential services to run Oracle
WebLogic Server 11g with JDK 6 compatible applications. Oracle WebLogic Server 11g on Oracle JRockit Virtual Edition offers up to
30% better performance for Java applications compared to WebLogic deployments using a traditional operating system, and has a
footprint up to five hundred times smaller than that of WebLogic deployments using a traditional operating system. Without a
traditional operating system, JRockit Virtual Edition eliminates the operating system installation, management, security, and storage
requirements as well as operating system license and support costs.
To illustrate just how thin the Oracle JRockit Virtual Edition OS layer is, Table 2 compares a Linux operating system to JRockit Virtual
Edition.
Administration +-500 1
Utilities
Administrative +-3000 10
Commands
Oracle JRockit Virtual Edition uses the same administrative infrastructure, tools, and WLST scripts as a traditional WebLogic
deployment. Each Oracle JRockit Virtual Edition appliance ships with an administrative server equipped with WebLogic Server
Administration Console. Oracle JRockit Virtual Edition appliances support both off-line and on-line management of applications
running in WebLogic instances.
Oracle JRockit Virtual Edition is intended to be a deployment platform. Oracle recommends that Java application development be done
on traditional WebLogic platforms. Once the application is ready to be deployed into production, it can be moved from the WebLogic
development system to an Oracle JRockit Virtual Edition appliance.
Oracle JRockit Virtual Edition is not a standalone Oracle technology product that can be purchased a la cart. The right to use Oracle
JRockit Virtual Edition is bundled with WebLogic Enterprise Edition. The only way to purchase Oracle JRockit Virtual Edition is by
purchasing WebLogic Enterprise Edition licenses.
the other of the two management options, Oracle VM Manager or the Oracle VM Management Pack Plug-in, not both.
Note: The Oracle VM Management Pack is licensed software; Oracle VM Server and Oracle VM Manager are not licensed software.
It's difficult to compare a full-featured system management solution like Oracle Enterprise Manager with a single-product
management solution like Oracle VM Manager, although for completeness Table 3 contrasts the high-level features of the Oracle
Enterprise Manager with those of the Oracle VM Management Pack Plug-in and Oracle VM Manager.
Configuration Management, *
i.e. tracking of configuration
drifts.
The Application Change Console is a separate standalone application that is licensed with the Oracle VM Management Pack Plug-in.
The Application Change Console (ACC) is able to parse configuration files to track changes and differences and send alerts and
notifications when changes are made. The Application Change Console has prebuilt parsers for Operating System configuration files.
After installing the Application Change Console, you can point the Application Change Console to the Oracle VM servers and Oracle
VM guests using hostnames. The Application Change Console will connect to a host via SSH to gather and track configurations. No
additional agents are required. All of the Application Change Console components can run on Oracle Linux on Oracle VM.
Oracle’s support policy, regarding Oracle technologies and virtualization, can be referenced via MetaLink documents 794016.1 and
249212.1. In short, MetaLink documents 794016.1 and 249212.1 explain that service requests (SRs) involving uncertified
virtualization solutions will receive best effort for known issues on physical systems. Oracle may request that the customer reproduce
the problem on native hardware if the third-party virtualization software cannot be ruled out as the root cause of the problem.
Major ISVs, for example, Microsoft and IBM, have virtualization support policies similar to Oracle’s. Microsoft and IBM may request
that customers reproduce problems on native hardware if the third-party virtualization software cannot be ruled out as the root cause
of a problem.
Microsoft: "As part of the investigation, Microsoft may require the issue to be reproduced by the customer independently from the
non-Microsoft hardware virtualization software."
IBM: “Will IBM correct all defects for IBM software products that are running in a supported virtualization environment?
A: Not necessarily. As with other operating environments, IBM does not warrant that all code defects will be corrected. IBM will issue
defect correction information, a restriction, or a bypass to IBM products if the defect is applicable to a supported virtualized
environment or to a native physical machine environment (that is, without the virtualization software).”
Watch this space
Oracle OpenWorld 2011 Call for Papers - Submit Today!
Temporary Post Used For Theme Detection (409fc5e9-d7ee-4e1a-b645-8b82f256f434 - 3bfe001a-32de-4114-a6b4-4005b770f6d7)
Debugging Oracle VM 2.2 & Oracle VM Manager 2.2 errors using the many log files
New VDI Training Course now available!
HIMSS 2011 and New Press Release
Oracle Desktop Virtualization at HIMSS 2011
Oracle VM VirtualBox 4.0.4 Released!
Two Virtualization Webinars This Week
We're Hiring! - Server and Desktop Virtualization Product Management
The chapter starts with an architectural review of Oracle VM for x86 and ends with an introduction to the Oracle VM for x86
reference design. The goal of this chapter is to articulate the architectural and design considerations for Oracle VM for x86 in order
to provide the technical foundation for using the Oracle VM for x86 reference design.
Note: This chapter replaces the original “Chapter 2: Oracle VM Architectural Review” that is still available as an Oracle VM for x86
architectural reference.
Table of Contents
Change Log
Oracle VM Server and Xen Architectural Review
...Oracle VM for x86 Server Specifications
Oracle VM Manager Architectural Review
Oracle VM Agent
Oracle VM for x86 Networking
Oracle VM for x86 Server Pools, HA and Live Migration
Oracle VM for x86 Storage
Oracle VM for x86 Intra-component Communication & Firewall Requirements
1.0 – The Oracle VM for x86 System Reference Design Introduction
...1.1 – The Oracle VM for x86 System Reference Design Implementation Overview
...1.2 – The Oracle VM for x86 System Reference Design Document Overview
2.0 – The Oracle VM for x86 System Reference Design Architectural Overview
...2.1 - The Oracle VM for x86 System Reference Design Support Infrastructure
Part 1 - The Oracle VM for x86 System Reference Design
3.0 - Cloud Infrastructure Architecture
Change Log
The Xen hypervisor works in concert with a control domain, which, in Xen terminology, is called dom0 or domain 0. Xen and dom0 are
automatically started when an Oracle VM server boots. Dom0’s role includes providing an interface to Xen, hardware detection,
device support, domU management, and presenting domUs with networking, storage, video, and I/O interfaces. Xen and dom0 enable
multiple concurrently running virtual machines to share a single piece of hardware. In Xen terminology, unprivileged domains are
called domU or domain U; the industry term for domU is virtual machine. Dom0 and domUs are all virtual machines.
Oracle makes subtle changes to the Xen.org code that create a unique Xen distribution, which is redistributed as Oracle VM server.
Oracle has developed a Xen/dom0 configuration for Oracle VM that supports the most demanding high I/O workloads that other Linux
distributions with Xen do not use. For example, each Linux distribution ships with Xen as an operating system virtualization feature.
When Xen is enabled on a Linux system, the entire Linux operating system, including all of the user space applications, is turned into
dom0. Xen-enabled Linux systems do not have an optimized Xen or dom0 configuration. In contrast to Xen/Linux, Oracle VM server is
a deliberately built virtualization platform, specifically designed for high I/O workloads such as Oracle's Database and Oracle Fusion
Middleware workloads.
Oracle VM server supports two unique virtualization modes, paravirtualization mode (PV mode) and hardware virtualization mode
(HVM mode). Oracle VM servers can support both paravirtualization mode and hardware virtualization mode simultaneously on a
single x86-64 server that has either Intel or AMD virtualization technologies. Intel and AMD virtualization is a requirement only for
hardware virtualization mode, not for paravirtualization mode. Intel and AMD virtualization technologies are enabled and managed
using the system BIOS.
Paravirtualization mode requires the virtual machine operating system to run a Xen kernel and Xen network and I/O drivers. Xen
paravirtualized guest kernels are available for the Oracle Linux and Red Hat Enterprise Linux operating systems. Paravirtualized
virtual machines are hypervisor aware and run without the additional overhead of hardware emulation. Paravirtualization requires
much less overhead for timers, interrupts, I/O traffic, and context switches, allowing superior scalability under heavy loads, when
compared to hardware virtualization mode.
Unlike paravirtualization mode, which requires the virtual machine to run a Xen kernel, hardware virtualization mode supports
unmodified operating systems. Virtual machines that run under hardware virtualization mode are called “hardware virtualized
machines” (HVM). Hardware virtualized machines are unaware that they have been virtualized and think they are on physical
hardware. To provide acceptable performance, hardware virtualized machines should use paravirtualized network and I/O drivers.
From Oracle Linux and Red Hat Enterprise Linux 4.7 onwards, the stock kernels have provided paravirtualized network and I/O
drivers for hardware virtualized guests. From Solaris 10 10/09 onwards, the stock kernels have provided paravirtualized network and
I/O drivers for hardware virtualized machines. Windows does not have native paravirtualization support, although Windows virtual
machines can run as hardware virtualized machines using Oracle's paravirtualized network and I/O drivers. Oracle has released
paravirtualized network and I/O drivers for the Windows operating system that can be freely downloaded from the Oracle Linux
eDelivery portal.
Paravirtualization and hardware virtualization modes use very different techniques to provide resources to virtual machines. For
example, hardware virtualization mode uses Intel or AMD virtualization technologies for memory management and to emulate the
boot environment for hardware virtualized machines. Hardware virtualization mode also uses QEMU in dom0 for device emulation for
hardware virtualized machines. Paravirtualization mode leverages the guest operating system's Xen kernel for the boot process using
the pygrub bootloader, Xen for memory management, and dom0 without QEMU for device support.
With paravirtualization mode, dom0 multiplexes native Linux devices for paravirtualized domUs. dom0 runs the back-end drivers, and
domU runs the paravirtualized front-end drivers in a back-end dom0, front-end domU driver model. For networking and I/O, dom0
runs a network back-end driver and a block back-end driver to support network and I/O requests for paravirtualized domUs. The
network back-end driver communicates through dom0 to the local hardware device to process all domU networking requests. The
block back-end driver communicates through dom0 to the local storage to process all domU storage requests.
Dom0 runs a dedicated quemu-dm process for each hardware virtualized machine. Hardware virtualized machines do not use the
same dom0 back-end and domU front-end drivers as paravirtualized domUs. Hardware virtualized machines use emulated drivers that
are created and managed by the quemu-dm processes in dom0. Hardware virtualization mode has a higher overhead than
paravirtualization mode, due in part to the CPU overhead of emulating hardware for hardware virtualized machines.
Figure 1 illustrates the Xen architecture explained above, highlighting the hypervisor, dom0, QEMU, two paravirtualized domUs, one
hardware virtualized domU, and the direct and virtual I/O paths.
Tip: The only way to determine which virtualization mode will provide the best performance for your environment is to benchmark
the same workload using the same operating system in paravirtualization mode and in hardware virtualization mode. If you do not
have the time or expertise to conduct the benchmarks, consider only using paravirtualization mode for your virtual machines.
To better understand the capabilities of Oracle VM server, List 1 highlights the technical specifications of Oracle VM server.
I686 class
Minimum Memory
1GB
Maximum Memory
1TB
Some Intel Pentium D, Core, Core2 and Xeon models (/proc/cpuinfo should list "vmx" among the flags)
Some AMD Athlon and Opteron models (/proc/cpuinfo should show "svm" among the flags)
Boot Options
32 virtual CPUs
Paravirtualized Mode: 31
Hardware Virtualization Mode: 8
List 1 shows that an Oracle VM server supports a total of a 1TB of RAM and a total of 128 CPU threads. An Oracle VM server with a
1TB of RAM and 128 CPU threads could allocate the majority of the 1TB of RAM and more than 128 CPU threads to virtual machines.
Oracle VM server supports CPU oversubscription, which means that an Oracle VM server with 128 CPU threads can overallocate the
total number of CPU threads to virtual machines. Oracle VM server does not support memory oversubscription, which means that an
Oracle VM server with 1TB of RAM cannot overallocate RAM. By default, each Oracle VM server reserves 512MB of memory for
dom0. The average memory overhead for each running guest on a dom0 is approximately 20MB plus 1% of the guest’s memory size.
The remaining physical memory can be allocated to guests.
Avoid oversubscribing CPU-bound workloads such as the Oracle Database. CPU oversubscription with CPU-bound workloads
negatively effects performance and availability. CPU oversubscription for non-CPU-bound workloads, such as Oracle Fusion
Middleware products, is recommended. It is common to oversubscribe CPU cores 3-to-1 with non-CPU-bound workloads. For example,
each CPU core could allocate 3 virtual CPUs for non-CPU-bound workloads without a performance penalty.
The maximum amount of RAM and CPU cores that an Oracle VM server with a 1TB or RAM and 128 CPU cores could allocate to a
single virtual machine is 32 virtual CPUs with 510GB of RAM. The minimum amount of RAM and CPU cores that an Oracle VM server
with a 1TB or RAM and 128 CPU threads could allocate to a single virtual machine is 1 virtual CPUs with as little as 256MB of RAM.
Note: A virtual machine cannot aggregate CPU and RAM resources from more than one server. That is, virtual machines consume
resources only from the host where the virtual machine was started.
Oracle VM for x86 consists of an x86 server component and a manager component used to manage one or more clustered servers.
Oracle VM server enables multiple concurrently running virtual machines to share a single piece of x86 hardware. The manager
component is a traditional Oracle application, named Oracle VM Manager. Oracle VM Manager facilitates centralized management of
one or more clustered Oracle VM servers, virtual machines, and virtual machine resources.
Oracle VM Manager is distributed from the Oracle Linux eDelivery portal as an ISO file and as a preconfigured, production-ready
Oracle VM template. Oracle VM Manager can be installed in an all-in-one configuration using the default Oracle 10g Express
Database or in a more traditional two tier architecture with an OC4J web tier and a 10 or 11g database tier. The Oracle VM Manager
template is an example of an all-in-one installation with the Oracle 10g Express Database, an OC4J application server, and the Oracle
VM Manager application all installed on the same operating system.
Table 1 lists the packaged applications in the Oracle VM Manager ISO file.
Application Capability
The total number of Oracle VM servers that Oracle VM Manager can manage is limited by the type of database repository used by
Oracle VM Manager. The default Oracle Database 10g Express Edition has a 4GB limit for on-disk storage, which is a bottleneck in
supporting Oracle VM environments with more than 50 Oracle VM servers. Using Oracle Standard Edition or Oracle Enterprise
Edition eliminates the 4GB limit for on-disk storage. For example, if your Oracle VM Manager database repository is not using Oracle
Database 10g Express Edition but an Oracle Standard or Enterprise Edition database on a reasonably sized server with a gigE
networking, Oracle VM Manager could easily scale up to 1000+ Oracle VM servers with thousands of virtual machines.
Tip: The Oracle VM Manager application runs much faster using an Oracle Standard or Enterprise Edition database.
The Oracle VM Manager application is a great candidate for virtualization on Oracle VM and Oracle VM VirtualBox. Virtualizing
Oracle VM Manager saves on hardware costs and improves application flexibility while reducing data center space. The Oracle VM
Manager template can be used to quickly deploy a production all-in-one Oracle VM Manager installation as a virtual machine, without
the need to dedicate a server for Oracle VM Manager. For a distributed Oracle VM Manager installation, the web tier and the
database tier can both be virtualized on Oracle VM using Oracle Linux virtual machines.
Note: Oracle VM Manager is not supported and should not be installed in an Oracle VM server's dom0.
Oracle VM Agent
Figure 2 illustrates the Xen architecture with the addition of the Oracle VM Manager. Oracle VM Manager is running on a virtual
machine with an all-in-one Oracle VM Manager installation, managing a server pool with one Oracle VM server hosting three virtual
machines.
Oracle VM Manager dispatches administrative commands made in the Oracle VM Manager portal to the Oracle VM agent in dom0.
The Oracle VM agent executes the Oracle VM Manager commands in dom0 using python scripts located in the /opt/ovs-agent-latest/
directory.
Oracle VM Manager facilitates centralized management of server pools and their resources using an agent-based architecture. When
an Oracle VM server is added to a server pool, one or more Oracle VM agent roles are assigned to the Oracle VM server. There are a
total of three Oracle VM agent roles; 1) the Server Pool Master, 2) the Utility Server and 3) the Virtual Machine Server. When an
Oracle VM server is added to a new server pool, it can be assigned one, two, or all three of the agent roles.
The server pool master is the principal server pool role within a server pool. The server pool master is the only agent role that
communicates with Oracle VM Manager. The server pool master dispatches commands received from Oracle VM Manager to
other servers within a server pool. There can be only one server pool master in a server pool at any instant. The server pool
"Virtual IP" feature in Oracle VM Manager 2.2 and above will detect the loss of the server pool master and automatically failover
the pool master server role to the first pool member that can lock the cluster.
Tip: To eliminate a single point of failure, always enable the Virtual IP feature. The Virtual IP feature requires a unique IP
address. If you have enabled the Virtual IP feature and do not know which server is the server pool master, ssh to the Virtual IP
to validate which host is the server pool master.
Utility Server
The utility server role is responsible for I/O-intensive operations such as virtual machine creation and removal and server pool
creation and removal, as well for as copying and moving guest files. The server pool master dispatches operations to utility
server agents. There can be one or more utility server agents in a server pool. When there are multiple utility server agents in a
pool, the server pool master will select the least loaded utility server to conduct a task.
Tip: For production Oracle VM systems, use dedicated utility servers to isolate the impact of I/O intensive operations to utility
servers. For example, colocating the utility server agent with the virtual machine server agent will affect guest performance
during utility server operations.
Servers with the virtual machine server agent role are responsible for allocating CPU, memory, and disk resources to the virtual
machines in a server pool. There can be one or more virtual machine servers in a server pool.
Oracle VM Manager dispatches commands using XML RPC to each server pool master agent, which, in turn, dispatches commands to
other pool members over a dedicated management interface using XML RPC. Oracle VM agent architecture is exceptionally
bandwidth efficient, since the intracomponent traffic is limited between a) Oracle VM Manager and each server pool master agent and
b) each server pool master agent and its server pool members. For example, an Oracle VM environment with 20 server pools, each
server pool having 20 servers, would have a total of 20 communication channels between Oracle VM Manager and each server pool
master. If Oracle employed a direct Oracle VM Manager to Oracle VM agent relationships, the same Oracle VM environment with 20
server pools, each server pool having 20 servers, would have a total of 400 communication channels.
bridge operates at layer 2 of the OSI model, effectively acting as a layer 2 (L2) switch passing packets to the egress port; it relies on
the TCP protocol for rate control and packet loss. Oracle VM's default network configuration pairs each network interface (NIC) with
a Xen bridge. An Oracle VM server with two NICs will have two Xen bridges, eth0/xenbr0 and eth1/xenbr1. The first Xen bridge,
eth0/xenbr0, is configured with an IP address on xenbr0 and is used for Oracle VM management traffic. The second Xen bridge will
not have an IP address assigned; it effectively acts as a layer 2 switch for guest traffic. The default Oracle VM server networking
configuration can be used as-is or modified to meet your business requirements, for example, to use 802.3AD NIC bonding with
802.1Q.
Figure 3 shows the default Oracle VM Xen bridge configuration: an Oracle VM server with two NICs wired into a single switch,
hosting three guests.
Tip: In an HA-enabled pool, the loss of network connectivity for the Oracle VM management interface causes an HA event. When an
HA event occurs, an Oracle VM server is fenced from the pool and reboots, then all HA-enabled guests are restarted on a live Oracle
VM pool member.
As of this writing, Oracle VM network configuration management is not included in Oracle VM Manager; it must therefore be
performed by hand in dom0. Both 802.3AD NIC bonding and 802.1Q VLANning are supported by Oracle VM for x86, although
bonding and VLANning must also be configured by hand in dom0.
Figure 4 shows an example 802.3AD NIC bonding and Xen bridges with 802.1Q VLANning.
For more information on Oracle VM networking please refer to Chapter 7: Oracle VM Networking from A to 802.1Q
Oracle VM Manager administers Oracle VM servers, virtual machines, and virtual machine resources in server pools. A server pool is
a management boundary that contains one or more clustered Oracle VM servers with virtual machines and virtual machine resources.
The next section will examine Oracle VM server pools.
templates, administrative users, and groups are isolated to their respected server pool.
An Oracle VM server with local storage is limited to a server pool with only one server, without high availability (HA) or Live
Migration functionally. To add additional Oracle VM Servers to a server pool, and to enable HA and Live Migration, at least one
shared SAN, iSCSI, or NFS storage repository is required. Shared SAN, iSCSI, or NFS storage allows virtual machines to start, run,
and migrate to any Oracle VM Server within a server pool. Without shared storage, virtual machines can only start and run on one
Oracle VM server without HA and Live Migration functionality.
Figure 5 shows an Oracle VM environment with four Oracle VM servers managed in two server pools.
Note: OCFS2 is not integrated or supported with any volume manager (LVM) solutions to manage the back-end block storage. Fibre
Channel and iSCSI OCFS2 partitions must be provisioned at static sizes, that is, partition sizes cannot change once a partition is
formatted with OCFS2.
As of this writing, there are no administrative features in Oracle VM for x86 for managing storage repositories. Oracle VM storage
repository configurations are made in dom0 and storage management is done using the native storage-array management tools.
Oracle VM Manager is responsible for pool creation, not for storage repository management. For example, storage repository
provisioning, storage repository snapshotting, storage repository replication, and storage repository monitoring, as well as storage
repository backup and restoration, are preformed using the storage-array administrative functionality.
Tip: A best practice with server pools that have more than one server is to dedicate the root repository to host only OCFS2 and HA
configurations, without virtual machine configuration files and images. A dedicated root repository without virtual machine
configuration files and images reduces the risk of cluster data corruption from virtual machine operations.
For more information on Oracle VM storage please refer to Chapter 6: Oracle VM 2.2 SAN, iSCSI and NFS Back-end Storage
Configurations
Figure 6 shows an Oracle VM server pool with three servers using a dedicated root repository hosting the cluster and HA
configurations and two extended repositories hosting virtual machine configuration files and images.
The Oracle VM for x86 HA feature detects server failures within a server pool and responds by restarting the virtual machines from a
failed server on a live server in the server pool. Oracle VM leverages a lightly modified OCFS2 cluster stack to monitor the status of
each Oracle VM server, using a network heartbeat over the management interface and a storage heartbeat on the root storage
repository. If any node in a server pool fails to update/respond to its network or storage heartbeat, the node is fenced from the pool
and promptly reboots, then all HA-enabled guests are restarted on a live server in the pool.
Figure 7 shows a server pool with three servers. One of the three servers has failed and the virtual machines from the failed server
have been restarted on the live servers.
Oracle VM HA adds negligible traffic to the Oracle VM server management network: 1 packet every 2 seconds for the HA heartbeat
traffic plus distributed lock manager (DLM) traffic when locks are taken during guest start and stops. The HA heartbeat traffic is
latency sensitive, and the allowable latency for heartbeat traffic is 60 seconds. For example, network heartbeat latency is 30 seconds,
but after 30 seconds the cluster will attempt to establish a disk heartbeat. If the cluster establishes a disk heartbeat, it will then try to
reconnect via the network. The second disk heartbeat timeout latency is set to 30 seconds, so it takes a full 60 seconds plus the
inability to see the root storage repository to trigger an HA event.
Note: In an HA-enabled pool, the loss of network connectivity for the Oracle VM management interface causes an HA event. When an
HA event occurs, an Oracle VM server is fenced from the pool and reboots, then all HA-enabled guests are restarted on a live Oracle
VM pool member.
The Oracle VM for x86 Live Migration feature moves running virtual machines between server pool members across a LAN without
loss of availability. Live Migration has two primary use cases. The first use case is to eliminate planned downtime by migrating
running guests from one server pool member to another during planned maintenance events. The second use case is to migrate
running guests from an overutilized pool member to a pool member with available resources.
There are three requirements for Live Migration. The first requirement is a shared SAN, iSCSI, or NFS storage repository to host the
virtual machine configuration files and images. The second requirement is that the source and target pool member servers CPUs be
identical. The final requirement is that the target server pool member must have sufficient memory to accommodate the memory
requirements of the virtual machine or machines that will be migrated.
Figure 8 shows a server pool with virtual machines Live Migrating between server pool members.
Oracle VM uses an iterative precopy method to migrate running guests over a TCP/SSL connection between two pool members. A Live
Migration event starts when the source server sends a migration request to the target server, which contains the guest resource
requirements. If the target accepts the migration request, the source starts the iterative precopy phase. The iterative precopy phase
starts by iteratively copying the guest’s memory pages from the source to the target server over the management network. If a
memory page changes during the precopy phase, it is marked dirty and resent. Once the majority of the pages are copied, the
stop-and-copy phase begins. The stop-and-copy phase starts by pausing the guest while the remaining dirty pages are copied to the
target, which usually takes 60 to 300 milliseconds. Once the pages are copied to the target, the guest is started on target server.
Note: Oracle VM server does not support memory oversubscription, which means that an Oracle VM server cannot accept a Live
Migration request unless the server has available RAM for the virtual machines. Oracle VM server supports CPU oversubscription,
which means that an Oracle VM server can accept a Live Migration request and overallocate the total number of CPU threads to
virtual machines, if necessary.
List 3 highlights Oracle VM communication ports and system passwords used with Oracle VM Manager.
Oracle VM Manager:
TCP 22/ssh is the default service used to access the Oracle VM Manager CLI.
Oracle VM Manager communicates with the Server Pool Master agent using TCP/8899.
The default HTTPS port for the Oracle VM Manager portal is 4443.
The default HTTP port for Oracle VM Manager portal is 8888.
The default HTTP port for the Oracle Database 10g Express Edition portal is 8080.
The default HTTP port for the Oracle Application Server 10g portal is 8888.
The default Database listening port for the Oracle Database 10g Express Edition repository is 1521.
Oracle Database 10g Express Edition accounts are SYS and SYSTEM.
Virtual machine VNC console access from the Oracle VM Manager portal uses ports 5900 through 5999.
Virtual machine VNC console access requires a VNC password without a user name. Virtual machine VNC console passwords are
assigned using Oracle VM Manager and are saved in clear text in each virtual machine's vm.cfg file.
Oracle VM Server:
The Oracle VM Agent listens on TCP 8899 and requires a password. The agent password is selected during the Oracle VM server
installation and can be configured from dom0 by typing “service ovs-agent configure”.
The xend-relocation-server service listens for Live Migration requests on TCP 8002. The xend-relocation-server is managed by
xend and configured using the /etc/xen/xend-config.sxp file. TCP 8002 must be open to all server pool members.
The cluster heartbeat is active on TCP 7777 and must be open to all server pool members.
SSH is enabled by default on TCP 22.
VNC console access to virtual machines uses TCP 5900 through 5999.
The rpcbind process (portmapper) listens on TCP/UDP 111.
Figure 9 illustrates Oracle VM for x86 intra-component communication and firewall requirements with Oracle VM Manager.
Next, we will examine the intracomponent communication and firewall requirements for an Oracle VM for x86 environment using the
Oracle Enterprise Manager Oracle VM Management Pack Plug-in.
List 4 highlights communication ports used with the Oracle Enterprise Manager Oracle VM Management Pack Plug-in.
Oracle Enterprise Manager Oracle VM Management Pack Plug-in communicates with the Server Pool Master agent using
TCP/8899.
The default HTTP port for the Enterprise Manager Grid Control portal is 4889.
The default database listening port for the Oracle Database repository is 1521.
Virtual machine VNC console access from the Oracle VM Manager portal uses ports 5900 through 5999.
Virtual machine VNC console access requires a VNC password without a user name. Virtual machine VNC console passwords are
assigned using Oracle VM Manager and are saved in clear text in each virtual machine's vm.cfg file.
Oracle VM Server:
The Oracle VM Agent listens on TCP 8899 and requires a password. The agent password is selected during the Oracle VM server
installation and can be configured from dom0 by typing “service ovs-agent configure”.
The xend-relocation-server service listens for Live Migration requests on TCP 8002. The xend-relocation-server is managed by
xend and configured using the /etc/xen/xend-config.sxp file. TCP 8002 must be open to all server pool members.
The cluster heartbeat is active on TCP 7777 and must be open to all server pool members.
SSH is enabled by default on TCP 22.
VNC console access to virtual machines uses TCP 5900 through 5999.
The rpcbind process (portmapper) listens on TCP/UDP 111.
Oracle VM Guests:
The Oracle Management Agent to Oracle Management Service communication is HTTPS on 4889.
Figure 10 illustrates Oracle VM for x86 intra-component communication and firewall requirements with the Oracle VM Management
Pack.
The Oracle VM for x86 reference design is a field-tested best-practice standard, designed with simplicity, reproducibility, usability,
scalability, supportability and security. The Oracle VM for x86 reference designs represent a complete Oracle VM for x86 standard
that can be leveraged as a vanilla solution or modified to more accurately reflect organization-specific needs. The Oracle VM for x86
reference design includes the following categories and solutions:
Cloud Infrastructure
Administration and Monitoring
Oracle VM Server Pools
Oracle VM Server Pool Storage Design
Oracle VM Server Pool Network Design
Oracle VM Templates
Virtual Machine Operating Systems
Note: A detailed explanation of each category and solution in the Oracle VM for x86 reference design is presented in the architectural
overview section.
1.1 – The Oracle VM for x86 System Reference Design Implementation Overview
The Oracle VM for x86 reference design provides a well defined starting point for each implementation. It also serves as a baseline
upon which all solution additions, revisions, and tools will be based. As such, there is an increasing value to Oracle VM for x86
reference design users in keeping implementations as close to the reference design as possible.
Prior to implementing Oracle VM for x86 based upon the Oracle VM for x86 reference design, it’s important that an infrastructure
assessment (IA) and gap analysis (GA) be performed. During the IA/GA, the architecture of the solution will match the customer’s
business needs while maintaining the integrity of the Oracle VM for x86 reference design. Implementation and support will follow the
analysis phase after careful consideration has been given to any specific design modifications that deviate from the Oracle VM for x86
reference design.
1.2 – The Oracle VM for x86 System Reference Design Document Overview
This document outlines the decision points necessary for implementing the Oracle VM for x86 reference design. For decisions that
rely on preexisting factors or specific organizational needs, the appropriate best practice will be discovered in the infrastructure
assessment (IA) and gap analysis (GA). The best practices should be analyzed carefully and decisions should be made based on
organizational needs, existing architecture, and budget resource availability.
2.0 – The Oracle VM for x86 System Reference Design Architectural Overview
The Oracle VM for x86 reference design is designed to be scalable and resilient for ease of implementation, high availability, and ease
of maintenance for internal and external clouds. The complete solution is made up of six architectural components that work together
to provide flexibility and options with respect to server consolidation, application delivery, monitoring, authentication and security
requirements, user access scenarios, and component migration/modification. The design breaks down into the following six
components:
Cloud Infrastructure. The Oracle VM for x86 reference design offers a cloud virtualization and management layer that allows
multiple Oracle Linux, Red Hat Linux, Solaris, and Windows virtual machines to run on a shared x86-64 hardware environment
allowing x86-64 bit server consolidation, and rapid application provisioning.
Administration and Monitoring: The Oracle VM for x86 reference design provides complete transparency from a cloud
infrastructure and an application perspective to any Oracle VM server, virtual machine, or application running in the cloud using
Oracle Enterprise Manager with Oracle VM Manager. Oracle Enterprise Manager allows organizations to consistently and
quantitatively measure performance across the organization for all of the hosted applications in the cloud.
Oracle VM Server Pools. The Oracle VM for x86 reference design may have one or more Oracle VM server pools to provide
isolation, defense in depth, the principle of least privilege, compartmentalization of information, and security domains, and to
accommodate different applications and their performance, authentication, and security requirements. This design builds on the
ability to test new applications alongside production applications in isolated Oracle VM server pools, without sacrificing the
integrity of the production environment.
Oracle VM Templates. The Oracle VM for x86 reference design will support an organization’s entire Oracle application
portfolio using Oracle VM templates. An Oracle VM template can consist of one or more virtual machines containing a
preconfigured operating system with an application. Using Oracle VM templates eliminates the operating system and application
installation and configuration process, allowing applications to be deployed from a library of Oracle VM templates. Oracle VM
templates used in conjunction with Oracle VM server pools accommodate different applications and their performance,
authentication, and security requirements. This design builds on the ability to test new applications alongside production
applications in isolated Oracle VM server pools, without sacrificing the integrity of the production environment.
Virtual Machine Operating Systems. The Oracle VM for x86 reference design standardizes on a small number of virtual
machine operating systems, operating system versions, and virtualization modes to streamline operations and to increase the
level of file duplication on production and archival virtual machine data. This design reduces complexity and increases
operational efficiency by limiting the number of supported operating systems.
Oracle VM Server Pool Storage Design. The Oracle VM for x86 reference design standardizes one OCFS2 or NFS 4GB root
repository that is used to host each server pool's Oracle Cluster File System v2 (OCFS2) cluster and HA configurations, and a
maximum of 10 extended repositories used exclusively to host virtual machine configuration files and images. When a server pool
needs more storage capacity, additional extended OCFS2 and/or NFS repositories are added to a server pool to increase capacity.
Oracle VM Server Pool Network Design. The Oracle VM for x86 reference design standardizes one of two Oracle VM server
pool network designs that both support defense in depth, the principle of least privilege, compartmentalization of information,
and security domains, and accommodate different applications and their performance, authentication, and security requirements.
1. A single two NIC 802.3AD bond with Xen bridges using 802.1Q-Tagged VLANs to isolate traffic between the Oracle VM
Manager management network and the virtual machine networks.
Figure 11
2. 4 NICs with two 802.3AD bonds. One two NIC bond is dedicated to Oracle VM management traffic with a fixed IP and the
second two NIC bond will use Xen bridges with 802.1Q-Tagged VLANs to isolate virtual machine networks.
Figure 12
Figure 13 shows a high-level overview of the Oracle VM for x86 reference design components.
The Oracle VM for x86 reference design isolates Oracle VM server pools into the following four security domains:
Controlled: A controlled security domain is used to restrict access between security domains. A controlled security domain could
contain groups of users with their network equipment or a demilitarized zone (DMZ).
Uncontrolled: An uncontrolled security domain refers to any network not in control of an organization, such as the Internet.
Restricted: A restricted security domain can represent an organization’s production, test and development networks. Access is
restricted to authorized personnel, and there is no direct access from the Internet.
Secured: A secured security domain is a network that is only accessible to a small group of highly trusted users, such as
administrators and auditors.
Note: The classification of security domains is very similar to data classifications. FIPS PUB 199 is the Standards for Security
Categorization of Federal Information and Information Systems. FIPS PUB 199 can be used to determine the security category of
systems and within which security domain systems should reside.
2.1 - The Oracle VM for x86 System Reference Design Support Infrastructure
Support is an integral part of the Oracle VM for x86 reference design and includes a combination of an Oracle support agreement and
on- and off-site support from the implementing party. Administrators will have several options for support, including live assistance,
phone support, and forums.
Port The default ports will Using the default ports creates
Numbers be used for all Oracle consistency and simplifies
VM server and Oracle configuration.
VM Manager
components.
vi /etc/motd
This system is
restricted to authorized
access only. All
activities on this system
are recorded and
logged. Unauthorized
access will be fully
investigated and
reported to the
appropriate law
enforcement agencies.
:wq!
Central log A central log host will Centralized logging for user
host be used to log all user logins and iptables connection
logins and iptables failures simplifies security
connection failures. management for the detection of
attacks and intrusions.
On-site and On-site and off-site On-site and off-site support from
Off-site support from the the implementing party for problem
support implementing party will resolution, system maintenance,
be used for site reviews, upgrades, and
maintenance, site security audits augments the
reviews, upgrades, and Oracle support agreement and
security audits. internal IT operations staff.
This chapter will review hard and soft partitioning Oracle technologies with Oracle VM. The goal of this chapter is to clarify how
Oracle VM can be used with hard and soft partitioning to help manage your Oracle enterprise technology license costs. The chapter
starts with a brief introduction to Oracle licensing. Next, we will review Oracle technology named user plus licensing followed with
processor licensing with hard and soft partitioning using Oracle VM. The chapter concludes with hard partitioning examples and
virtual CPU binding testing techniques.
Note: While Oracle recognizes hard and soft partitioning with Oracle VM, this does not imply that this applies when using other
vendor's virtualization technologies. Please refer to the SIG or your Oracle representative if you have questions about the licensing
impact of other vendor's virtualization approaches.
Table of Contents
Oracle Technology Licensing
Oracle Technology Licensing with Oracle VM
…Named User Plus Licensing
…Named User Plus Licensing versus Processor Licensing
…Processor Licensing
Hard and Soft Partitioning with Oracle VM
…Soft Partitioning Examples
…Hard partitioning Examples
…Oracle VM Manager Manual Placement Policy Configuration
Hard Partitioning an Oracle VM Guest
…CPU Pinning Examples
…CPU Pinning with xm
Resources
Database
Enterprise Managers
Application and System Management
Application Server
Fusion Middleware
Business Intelligence
Identity Management
Tools
Enterprise 2.0
Collaboration
Data Warehousing Products
Integration products
The only way to determine the most beneficial licensing model for your Oracle software investment is to evaluate your organization’s
Oracle software requirements, along with your hardware, operating system and virtualization configurations. Most organizations
initially engage their Oracle sales representatives as a first step, in order to help evaluate and quote license options. Customers
typically use the initial licensing evaluation and quotes as a starting point to help determine which licensing model and configuration
provides the best value.
An important Oracle technology licensing consideration is your organization’s hardware, operating system and virtualization
configurations. Oracle recognizes a wide variety of hardware, operating system and virtualization configurations that directly affect
the CPU count used to calculate Oracle technology processor licenses. For example, Oracle recognizes various hard and soft
partitioning configurations for Oracle VM, as well as the big 3 UNIX platforms, that directly affect how to count Oracle technology
CPU licenses.
From an Oracle technology licensing perspective, hard partitioning allows customers to license a subset of a server’s CPUs.
Conversely, soft partitioning counts the total number of a server’s CPUs.
Hard partitioning with Oracle VM allows a customer to license a subset of an Oracle VM server’s CPUs. Soft partitioning is used to
take advantage of Live Migration, which is not supported with hard partitioning. Along with Live Migration, soft partitioning provides
the ability to manage the number of licensed Oracle technology product CPUs within an Oracle VM pool.
Hard and soft partitioning with Oracle VM provide the ability to manage the number of licensed Oracle technology CPUs. Named user
plus licensing and unlimited license agreements are not CPU regulated, which preclude using Oracle VM as a license management
option.
The SIG states that Oracle technology standard edition products are limited to 2 or 4 sockets, i.e. installed on a server with no more
than 2 or 4 physical CPUs. Standard edition products can run on an Oracle VM as long as the Oracle VM server meets the standard
edition’s CPU requirements. Most contemporary virtualization servers are equipped with 2 or 4 sockets, which may preclude hosting
standard edition products on Oracle VM.
Understanding how and where to use hard and soft partitioning with Oracle VM can help organizations to better manage their Oracle
Enterprise technology licensing costs for development and production environments.
Processor Licensing
Processor licensing is when an Oracle customer pays per processor (CPU), to run an Oracle technology product. Larger deployments,
with 50 or more users, typically use processor based licensing. Oracle recognizes each CPU core as a separate CPU and each CPU
type with a different processor factor. The processor factor determines the CPU count. The CPU count determines the number of
CPUs required to license the Oracle technology product.
Note: Be sure to refer to the latest Oracle Processor Core Factor Table to find out the processor core factor for your hardware.
UltraSparc T1 0.25
AMD/Intel 0.50
Two and four core CPUs are now end of life. New Intel x86 servers’ ship with six or eight core CPUs. AMD plans to ship their 12 core
CPUs in the first half of 2010. Both Sun Sparc and IBM Power servers now ship with eight core CPUs. As the chip vendors add more
cores to CPUs, Oracle technology licensing costs can increase.
To better understand the impact to Oracle processor licensing with multi-core CPUs, let’s review List 2.
List 2 shows the processor factor for a single eight core Intel, AMD, Sun Sparc, and IBM Power CPU.
As illustrated in the above examples, a single eight core CPU doubled the Oracle technology license CPU count, when compared to
the single four cores CPU in List 1. Oracle customers using processor licensing will have to carefully consider the licensing impact of
a hardware refresh due to the additional CPU cores.
List 3 highlights various options to help manage the Oracle technology license CPU count, with multi-core CPUs.
One of the options is to move from processor licensing to an unlimited license agreement. Customers with an unlimited license
agreement (ULA) have no CPU restrictions with Oracle technology products.
Another option would be to use hard partitioning with processor licensing to control the number of licensed CPUs. Hard
partitioning allows a customer to license a subset of a server’s CPUs. However, Live Migration is not supported with hard
partitioning.
Customers can also use soft partitioning with processor licensing and Oracle VM to limit the number of licensed CPUs within a
server pool. Soft partitioning supports Live Migration.
Note: Standard edition products can run on an Oracle VM as long as the Oracle VM server meets the standard edition’s CPU
requirements. Please refer to the relevant licensing documentation for the Standard Edition product in question to verify if
the Standard Edition product can be hosted on your server platform with Oracle VM.
The difference between hard and soft partitioning is how Oracle recognizes the Oracle technology CPU license count, and the
supported virtualization feature set. For example, Live Migration is not supported with Oracle VM when used with hard partitioning.
Conversely, soft partitioning can be used within an Oracle VM pool to take advantage of Live Migration, along with the ability to
manage the Oracle technology CPU count.
From an Oracle technology licensing perspective, hard partitioning allows customers to license a subset of a server’s CPUs.
Conversely, soft partitioning counts the total number of a server’s CPUs. Soft partitioning with Live Migration requires each Oracle
VM server, running a guest with an Oracle technology product to be licensed. We can limit the number of soft partitioned pool
members, where a guest can run, by configuring an Oracle VM Manager manual placement policy.
1. A single Intel server with 16 CPU cores, with Linux installed running 11G has a processor factor of 8 CPUs. The Linux server can
run one 11G instance.
2. A single Intel server with 16 CPU cores, with Oracle VM installed using soft partitioning has a processor factor of 8 CPUs. The
Oracle VM server could run more than 16 single CPU guests each with 11G.
3. A single Intel server with 16 CPU cores with Oracle VM installed using hard partitioning. The Oracle VM server is capable of
running more that 16 single CPU guests, although only one of the guests is running 11G with 2 virtual CPUs. In this example,
using hard partitioning, we could license a subset of the 8 CPUs. For example, we could hard partition 1 of the 8 CPUs.
A single Oracle VM server with 2 Intel eight core CPUs (16 cores), could run 16 one CPU guests, without oversubscribing the servers’
CPUs. Oracle VM supports both CPU and memory oversubscription, which allows a single Oracle VM server to oversubscribe CPU and
memory resources to guests. For example, an oversubscribed host with 2 Intel eight core CPUs (16 cores), could provision more than
16 cores to guests.
Figure 1 shows three hosts. The first host has two eight core CPUs with Linux installed running 11G. The second host has two eight
core CPUs using soft partitioning with Oracle VM installed, hosting 8 guests running 11G. The third host has two eight core CPUs
using hard partitioning with Oracle VM installed, hosting 8 guests. Only one of the guests is running 11G.
As shown in Figure 1, the Linux server requires eight Oracle technology CPU licenses and is hosting one 11G application. Servers that
host one application are commonly referred to as application silos. The traditional one application per server deployment
methodology, shown in Figure 1, inevitably leads to over-provisioning and underutilization of hardware. Studies show that most
servers run at 5-15% of their total capacity. For example, most servers spend the majority of their life idle, consuming electricity and
taking up valuable data center space. Underutilized servers can be consolidated using Oracle VM with hard or soft partitioning to
provide better license and resource utilization when compared to application silos.
The soft partitioning example in Figure 1 shows how an Oracle VM server with eight processor licenses can host multiple isolated
guests, running 11G, for the same CPU cost as the application silo. Oracle VM with soft partitioning provides superior license and
resource utilization when compared to an application silo. Oracle VM supports CPU and memory oversubscription, which allows you
to run even more workloads per server when compared to an application silo.
The hard partitioning example in Figure 1 shows how a shared infrastructure can be used to support Oracle technology products
along with the ability to license a subset of the server’s CPUs. For example, we can license one of the eight CPUs. Hard partitioning
with Oracle VM can be used with processor licensing and enterprise edition products to manage the number of licensed CPUs for
The use case for Oracle VM and soft partitioning with production environments, is the ability to use Live Migration, along with the
ability to manage the number of licensed CPUs. For example, it is not necessary to license the sum of all Oracle VM pool member’s
CPU cores when using Live Migration with soft partitioning. We can configure an Oracle VM Manager manual placement policy to
control which pool members a guest can run on. Using a placement policy with soft partitioning allows us to license a subset of an
Oracle VM pool’s CPU cores. A manual placement policy confines a guest to run on the pool members listed in the manual placement
policy.
Figure 2 shows an Oracle VM server pool with six Oracle VM servers. Each Oracle VM server has two eight core CPUs. The Oracle
VM server pool has a total of 96 cores, and a processor factor of 48 CPUs. In Figure 2, there is a total of 8 guests in the pool running
11G, with the ability to run on all 6 Oracle VM pool members. The example shown in Figure 2 would require 48 Oracle technology
processor licenses.
Figure 3 shows the same server pool as in Figure 2, with a total of 96 cores and a processor factor of 48 CPUs. In Figure 3, there is a
total of 8 guests in the pool running 11G, with the ability to run on two Oracle VM pool members. The scenario shown in Figure 3
requires 16 Oracle technology processor licenses.
Figure 4 shows the same server pool as in Figure 2, with 96 cores, and a processor factor of 48 CPUs. In Figure 4, there is a total of
96 guests in the pool, each running 11G, with the ability to run on any of the Oracle VM pool members. The scenario shown in Figure
4 would require 48 Oracle technology processor licenses.
We can limit the number of Oracle VM pool members that a guest can run on, by configuring a manual placement policy in Oracle VM
Manager. A manual placement policy allows you to limit which Oracle VM pool members a guest is allowed to run on. Once a manual
placement policy is configured, HA events and Live Migration will be limited to the Oracle VM pool members listed in the manual
placement policy.
Tip: An auto placement policy will start a guest on the least busy pool member and does not limit a guest’s ability to HA or Live
Migrate to any pool members.
Oracle’s hard partitioning policy states that a hard partitioned guest’s virtual CPUs mapping must be hardcoded in the guest’s vm.cfg
file. To confine the hard partitioned guest to the mapped host, a manual placement policy must be configured. Oracle restricts the use
of Live Migration with hard partitioning.
Our first hard partitioning example in Figure 5 shows an Oracle VM server with two eight core Intel CPUs, with one hard partitioned
guest running 11G. The guest is pinned to two of the Oracle VM server’s cores (2 cores = 1 CPU). From an Oracle technology
licensing perspective, the server has a processor factor of 8. Using hard partitioning, the pinned guest would require only 1 CPU
license. The additional 7 CPUs could be used to license other Oracle technologies or be shared to run other workloads on the same
Oracle VM server.
Another example with the server in Figure 5 would be to hard partition two guests, each guest running 11G. Each of the two guests is
pinned to 1 of the Oracle VM server’s cores (2 cores = 1 CPU). The additional 7 CPUs could be used to license other Oracle
technologies or be shared to run other workloads on the same Oracle VM server.
Figure 6 shows an Oracle VM server with two eight core Intel CPUs, with two hard partitioned guests running 11G. Each guest is
pinned to 1 of the Oracle VM server’s cores, 2 cores = 1 CPU.
Hard partitioning an Oracle VM guest is a two step process. The first step is to create a manual placement policy for the hard
partitioned guest using Oracle VM Manager. The manual placement policy will confine the guest to the pinned Oracle VM server. The
second step is to edit the hard partitioned guest’s vm.cfg file to pin the guest’s virtual CPU to the Oracle VM server’s physical CPU
cores.
policy. A manual placement policy is a guest property that can be configured during or after guest creation.
In the next section, we will walk through the configuration of a manual placement policy. Please note that guests must be powered off
to configure a placement policy.
The first step is to access Oracle VM Manager and power off the guest. Next, click on the guest’s Virtual Machine Name as shown
in Figure 7 to access the guest’s properties.
From the General Information page, click the Policies link to access the Policies properties page, as shown in Figure 8.
From the Policies page click the Placement Policy tab, as shown in Figure 9.
From the Placement Policy page click the Manual button to access the Prefer Server page, as shown in Figure 10.
From the Preferred Server page, select the desired Oracle VM server(s) from the preferred server list. When you select an Oracle
VM server from the preferred server list, the manual placement policy will limit the guest to the selected server(s). Once you have
selected the preferred server, click the Confirm button, as shown in Figure 11.
After clicking the Confirm button, the page refreshes and displays the Placement Policy page. The new manual placement policy
will be displayed as shown Figure 12.
We have successfully configured a manual placement policy for an Oracle VM hard partitioned guest.
The next and final step to hard partition an Oracle VM guest is to pin the guest’s virtual CPUs to the Oracle VM server’s CPU cores.
Each hard partitioned guest should be pinned to the Oracle VM server that is listed in the guest’s manual placement policy.
Oracle VM’s default CPU scheduler is the credit scheduler. The credit scheduler uses a credit/debit system to fairly share CPU
resources between guests. Credits are assigned to each running guest, along with the fraction of CPU resources. The credit scheduler
continually increments/decrements credits from running guests, which is how the credit scheduler balances resources. In many ways,
the credit scheduler is like the Linux scheduler. The Linux scheduler is used as the default CPU scheduler with the KVM hypervisor.
Both schedulers can preempt processes as needed while trying to ensure proportional fair share allocations.
The default behavior of the credit scheduler is to bind each virtual CPU to a separate physical core. For example, when you create a
guest with two virtual CPUs, the credit scheduler will map the two virtual CPUs to two physical cores. So when pinning virtual CPUs,
we should follow the credit scheduler’s default behavior of mapping virtual CPUs to a server’s individual CPU cores.
Unless you have pinned a guest’s virtual CPUs, virtual CPUs will occasionally bind to different physical cores. Virtual CPUs bind to
different physical cores, due to the credit scheduler’s use of the credit/debit system, which dynamically re-balances CPU resources.
For example, if you where to periodically check an unpinned guest’s CPU mapping, you would see a different CPU mapping
throughout the day.
There are two methods to pin virtual CPUs. We can use the xm command to pin a guests’s virtual CPUs or we can hardcode the CPU
mapping in a guest’s vm.cfg file. The difference between pinning CPUs with xm and hard coding the CPU mapping in a guest’s vm.cfg
file is the persistence of the CPU mapping. CPUs that are pinned with xm are not persistent between reboots. Hard coding the CPU
mapping in a guest’s vm.cfg file is persistent between reboots. To comply with Oracle’s hard partitioning policy, we must hardcode the
CPU mapping in a guest’s vm.cfg file.
Please note that hard partitioning could cause guest performance issues. For example, if you pin a guest’s virtual CPU to a specific
subset of named CPUs without considering how the lower-level I/O interrupts are being assigned, you can end-up hurting
performance. I/O interrupts are typically mapped to a specific CPU. If that CPU is not the same as the pinned CPU, the interrupts have
to be "re-directed" to the CPU you pinned, which could cause the performance of the guest to decrease. If a hard partitioned guest is
experiencing performance issues, the CPU pinning would be an area to investigate.
Next, we will review how to hard partition an Oracle VM guest. After the hard partitioning example, we will review pinning an Oracle
VM guest using the xm command. Unfortunately, all CPU cores are not equal, so you may need to test various virtual CPU mappings
using the xm and virsh commands.
To comply with Oracle’s hard partitioning policy, we must hardcode a guest’s virtual CPU mapping, by adding the “cpus=” directive in
the guest’s vm.cfg file. By adding the “cpus=” directive in the guest’s vm.cfg file, we pin the guest’s virtual CPUs to the Oracle VM
server’s cores.
Let’s review two different “cpus=” configurations, to help explain how to pin a guest’s virtual CPUs to an Oracle VM server’s CPU
cores.
In the first vm.cfg example, we add a new line in the vm.cfg file, cpus = '0-3'.The cpus = '0-3' entry pins the guest’s virtual CPUs to
the Oracle VM server’s CPU cores 0, 1, 2, and 3.
Please note the vcpus = 4 entry, one line above the cpus = '0-3' entry. The vcpus = 4 entry defines the number of virtual CPUs. The
vcpus = directive can be edited to select the desired number of virtual CPUs.
#vi /OVS/running_pool/v52x6410g1/vm.cfg
bootloader = '/usr/bin/pygrub'
disk = ['file:/OVS/running_pool/v52x6410g1/System.img,xvda,w',
'file:/OVS/running_pool/v52x6410g1/oracle10g_x86_64_asm.img,xvdb,w',
]
memory = '2048'
name = 'v52x6410g1'
on_crash = 'restart'
on_reboot = 'restart'
uuid = 'd428ba07-31b9-5667-2085-8753a0342425'
vcpus = 4
cpus = '0-3'
vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0']
vif = ['bridge=xenbr0,mac=00:16:3E:20:18:19,type=netfront']
vif_other_config = []
The above example vm.cfg file shows a hard partitioned guest with 4 virtual CPUs. The guest’s 4 virtual CPUs are pinned to the
Oracle VM server’s CPU cores 0, 1, 2, and 3. The same guest could also be pinned using cpus = '0' in the vm.cfg file. Using cpus =
'0' would pin all 4 virtual CPUs to the same physical core, number 0, on the Oracle VM server. The same guest could also be pinned
using cpus = '0,1' in the vm.cfg file. Using cpus = '0,1’ would pin 2 virtual CPUs to core number 0 and 2 virtual CPUs to core
number 1.
We can also use regular expression inversion. For example, we could use cpus=’^0-1’, which means any core but 0 and 1.
In the second vm.cfg example, we add a new line in the vm.cfg file, cpus = '0,1'.The cpus = '0,1' entry pins the guest’s virtual CPUs
to the Oracle VM server’s CPU cores 0 and 1.
Please note the vcpus = 2 entry above the cpus = '0,1' entry. The vcpus = 2 entrydefines the number of virtual CPUs. The vcpus =
directive can be edited to select the desired number of virtual CPUs.
#vi /OVS/running_pool/v52x6410g1/vm.cfg
bootloader = '/usr/bin/pygrub'
disk = ['file:/OVS/running_pool/v52x6410g1/System.img,xvda,w',
'file:/OVS/running_pool/v52x6410g1/oracle10g_x86_64_asm.img,xvdb,w',
]
memory = '2048'
name = 'v52x6410g1'
on_crash = 'restart'
on_reboot = 'restart'
uuid = 'd428ba07-31b9-5667-2085-8753a0342425'
vcpus = 2
cpus = '0,1'
vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0']
vif = ['bridge=xenbr0,mac=00:16:3E:20:18:19,type=netfront']
vif_other_config = []
The above example vm.cfg file shows a hard partitioned guest with 2 virtual CPUs pinned to the Oracle VM server’s CPU cores 0 and
1.
We can also use regular expression inversion. For example, we could use cpus=’^0-1’, which means any core but 0 and 1.
Note: We must reboot the virtual machine to enforce any new hard partitioning configurations.
To be able to hard partition a guest, we need to know the number of CPUs and the number of cores on the pinned Oracle VM server.
There are a number of commands to list the CPU details of an Oracle VM server. From dom0 we could type “xm info” or “virsh
nodeifo” to list the CPU and core details as shown in the next example.
# virsh nodeinfo
libvir: Remote error : No such file or directory
libvir: warning : Failed to find the network: Is the daemon running ?
CPU model: i686
CPU(s): 8
CPU frequency: 2992 MHz
CPU socket(s): 2
Core(s) per socket: 4
Thread(s) per core: 1
NUMA cell(s): 1
Memory size: 16775168 kB
The “virsh nodeinfo” example shows that the Oracle VM server has two four core CPUs (sockets) with a total of eight cores. The
example Oracle VM server has an Oracle technology license processor factor of 4 CPUs.
To list the CPU cores, we can type “grep -i processor /proc/cpuinfo”, as shown in the next example.
# grep -i processor /proc/cpuinfo
processor :0
processor :1
processor :2
processor :3
processor :4
processor :5
processor :6
processor :7
The “grep -i processor /proc/cpuinfo” example lists the number of all eight CPU cores. If you would like to list all of the CPU details
type “cat /proc/cpuinfo”.
Once we have the Oracle VM server’s CPU and core details, we can pin the guest’s virtual CPUs to any of the physical cores. We will
follow the default behavior of the credit scheduler and bind each virtual CPU to a separate physical core.
Before we pin the guest, let’s review the guest’s vm.cfg file. Please note the vcpus = 2 directive, which indicates the number of
virtual CPUs for the guest.
#vi /OVS/running_pool/v52x6410g1/vm.cfg
bootloader = '/usr/bin/pygrub'
disk = ['file:/OVS/running_pool/v52x6410g1/System.img,xvda,w',
'file:/OVS/running_pool/v52x6410g1/oracle10g_x86_64_asm.img,xvdb,w',
]
memory = '2048'
name = 'v52x6410g1'
on_crash = 'restart'
on_reboot = 'restart'
uuid = 'd428ba07-31b9-5667-2085-8753a0342425'
vcpus = 2
vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0']
vif = ['bridge=xenbr0,mac=00:16:3E:20:18:19,type=netfront']
vif_other_config = []
Next, we will pin the two virtual CPUs to core 7 and 3 on the Oracle VM server. We will add the cpus =’7,3’ directive to pin the
guest’s two virtual CPUs to core 7 and 3 on the Oracle VM server.
#vi /OVS/running_pool/v52x6410g1/vm.cfg
bootloader = '/usr/bin/pygrub'
disk = ['file:/OVS/running_pool/v52x6410g1/System.img,xvda,w',
'file:/OVS/running_pool/v52x6410g1/oracle10g_x86_64_asm.img,xvdb,w',
]
memory = '2048'
name = 'v52x6410g1'
on_crash = 'restart'
on_reboot = 'restart'
uuid = 'd428ba07-31b9-5667-2085-8753a0342425'
vcpus = 2
cpus =’7,3’
vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0']
vif = ['bridge=xenbr0,mac=00:16:3E:20:18:19,type=netfront']
vif_other_config = []
We must reboot the virtual machine to enforce the new hard partitioning configuration.
Note: If a hard partitioned guest uses Live Migration, or has the CPU properties edited with the xm command, the hard coded CPU
mapping in the vm.cfg file will be lost. If the CPU mappings get removed by Live Migration, or xm, you will need to re-pin the virtual
CPUs in the guest’s vm.cfg file.
Once we reboot the guest we can validate our new hard partition configuration by accessing dom0 as root and type xm vcpu-list
[domain], as shown in the next example.
# xm vcpu-list v52x6410g1
Name ID VCPU CPU State Time(s) CPU Affinity
v52x6410g1 19 0 7 -b- 12.8 3,7
v52x6410g1 19 1 3 -b- 5.6 3,7
The “xm vcpu-list v52x6410g1” command validates that our hard partition configuration is enforced. By adding the cpus =”7,3”
directive, we pinned the guest’s two virtual CPUs, one virtual CPU is pinned to core 7 and one virtual CPU is pinned to core 3.
The above hard partition example showed how to license a subset of an Oracle VM servers’ CPUs. The example Oracle VM server has
a processor factor of four CPUs. Using hard partitioning, we licensed only one of the Oracle VM server’s four licensable CPUs.
Note: If you have hard coded the CPU mapping in a guest’s vm.cfg file and use the xm command to change the CPU properties, the
hard coded CPU mapping will be lost.
The “xm vcpu-set” command allow us to select any number of virtual CPUs up to number of virtual CPUs listed in the vcpus = n
directive in the vm.cfg file. For example, if a guest has four virtual CPUs, (vcpus = 4) we could use the “xm vcpu-set” command to
reconfigure a guest to use 1, 2 or all four of the virtual CPUs.
To view a guest’s virtual CPU statistics, from dom0 as root, type xm vcpu-list [domain], as shown in the next example. If you type “xm
vcpu-list”, it will list all of the running guest’s virtual CPU statistics.
# xm vcpu-list v52x6410g1
Name ID VCPU CPU State Time(s) CPU Affinity
v52x6410g1 18 0 2 -b- 351.4 2
v52x6410g1 18 1 6 -b- 220.7 6
We can also use the virsh command to list a guest’s virtual CPU details by typing virsh vcpuinfo [domain], as shown in the next
example.
# virsh vcpuinfo v52x6410g1
libvir: Remote error : No such file or directory
libvir: warning : Failed to find the network: Is the daemon running ?
VCPU: 0
CPU: 2
State: blocked
CPU time: 236.2s
CPU Affinity: ---y---y
VCPU: 1
CPU: 6
State: blocked
CPU time: 178.5s
CPU Affinity: ---y---y
In the above example, the guest has two virtual CPUs, 0 and 1. Virtual CPU 0 is in the "blocked" state on the physical core number 2.
Virtual CPU 1 is in the "blocked" state on the physical core number 6. Both virtual CPUs are in the blocked state, which means the
guest is waiting on I/O or has gone to sleep. There is a total of six virtual CPU states, r for running, b for blocked, p for paused, s for
shutdown, c for crashed and finally, d for dying.
The next example shows how to change the virtual CPU count from two virtual CPUs to one virtual CPU using the “xm vcpu-set”
command.
# xm vcpu-set v52x6410g1 1
# xm vcpu-list v52x6410g1
Name ID VCPU CPU State Time(s) CPU Affinity
v52x6410g1 18 0 2 -b- 359.5 2
v52x6410g1 18 1 - --p 227.0 6
As shown in the above example, typing “xm vcpu-set v52x6410g1 1” paused one of the two virtual CPUs. A paused virtual CPU is not
eligible for scheduling by the credit scheduler. The paused virtual CPU will remain paused until resumed, for example, by typing “xm
vcpu-set v52x6410g1 2”, as shown in the next example.
# xm vcpu-set v52x6410g1 2
# xm vcpu-list v52x6410g1
Name ID VCPU CPU State Time(s) CPU Affinity
v52x6410g1 19 0 2 -b- 266.4 2
v52x6410g1 19 1 6 -b- 190.5 6
Next, we will pin the guest’s virtual CPUs to the Oracle VM server’s physical cores using the “xm vcpu-pin <domain> <vcpu>
<pcpu>” command. In the next example, we will pin the guest’s virtual CPU 0 to core 1, and virtual CPU 1 to core 4.
# xm vcpu-pin v52x6410g1 0 1
# xm vcpu-pin v52x6410g1 1 4
# xm vcpu-list v52x6410g1
Name ID VCPU CPU State Time(s) CPU Affinity
v52x6410g1 19 0 1 -b- 268.4 4
v52x6410g1 19 1 4 -b- 190.5 6
As shown in the above example, typing “xm vcpu-pin v52x6410g1 0 1” followed by typing “xm vcpu-pin v52x6410g1 1 4” pinned the
guest’s virtual CPU 0 to core 1 and virtual CPU 1 to core 4.
Resources:
Table of Contents
Oracle VM Server Installation Options
Oracle VM Media Pack Download
Oracle VM Server Sizing and Resource Requirements
…High-Availability and Disaster-Recovery Requirements
…Separation of Duties
…Oracle VM Server CPU Requirements
…Oracle VM Server Memory Requirements
…Oracle VM Server Storage Requirements
…Oracle VM Server Network Requirements
Note: Oracle VM Manager is not supported and should not be installed in Oracle VM server's dom0.
The zip file from the Oracle eDelivery/Linux site contains a single Oracle VM server ISO file; this file is used for both x86 and x86-64
hardware. The Oracle VM server install routine automatically detects the hardware platform and installs the appropriate 32-bit or
64-bit Xen hypervisor. Regardless of the hardware platform, 32-bit or 64-bit, dom0 is 32-bit.
A PXE boot installation requires several additional steps; for example, a boot server and a kickstart file to automate the Oracle VM
server installation must be created. The boot server allows a bare-metal system to automatically receive an IP address via DHCP, load
a kernel via TFTP, and then boot without an installed operating system. Once the bare-metal server boots, you can install Oracle VM
server from the installation media or use a kickstart file to automate the Oracle VM server installation.
The default behavior of the Oracle VM server installer is to install Oracle VM server on the Oracle VM server's local disk. To enable
the boot from SAN option, type “boot: linux mpath [enter]” at the installation boot prompt. The installation boot prompt is visable
on the first Oracle VM Server installation screen. Typing “boot: linux mpath [enter]” tells the installer to use the device-mapper-
multipath drivers.
Oracle VM server can be installed directly from a bootable CDROM, as well as from the Oracle VM server media files that have been
staged on a) an Oracle VM server's local hard drive b) on an NFS share c) on an FTP server and/or d) on a web server. The Oracle VM
madia files are also refered to as the Oracle VM server media installation tree. To install Oracle VM server from the Oracle VM media
files, from the installation boot prompt type "boot: linux askmethod [enter]. Typing "linux askmethod [enter] from the installation
boot prompt will enable the Install Method installation screen. From the Install Method screen you can select to install Oracle VM
server from a) Local CDROM b) Hard Disk c) NFS image d) FTP or e) HTTP.
Tip: Installing Oracle VM server using a bootable CDROM with Lights out Management (LOM) solutions may generate file copy
installation errors. If you experience file copy errors, stage the Oracle VM server media files on the a) Hard Disk b) NFS image c) FTP
or d) HTTP and from the installation boot prompt type "boot: linux askmethod [enter] to enable the Install Method installation
screen.
Figure 1 shows the result from the Media Pack Search for Oracle VM.
Select the desired Oracle VM Media Pack, then press the Continue button or click the Oracle VM <version> Media Pack
hyperlink to go to the download page. On the Oracle VM <version> Media Pack download page, click the Download button to
download the Oracle VM Server <version> media pack.
The Oracle VM Server media is delivered as a zip file. The zip file name corresponds to the Part Number listed on the download
page. Once the zip file is downloaded, use your favorite zip utility to unzip the Oracle VM ISO file. Next, burn the ISO file to a
bootable CD or DVD that can be used to install Oracle VM server using a CD-ROM.
Oracle VM server runs on x86 32-bit and x86 64-bit platforms with Intel or AMD chips. The minimum resource requirement for your
Oracle VM hardware depends on the resource requirements of the guests that will run on your Oracle VM servers. For example,
Oracle recommends a dual core CPU or multiple CPUs with at least 1GB or 2GB of RAM. Oracle’s minimum resource recommendation
for Oracle VM is a great starting point for running a couple guests for an evaluation. To size your Oracle VM server hardware and
Oracle VM server pools, you will need document a) the resource requirements of all of your virtual machines b) your organization’s
high-availability and disaster-recovery requirements and c) your organization’s separation of duty requirements for the Oracle VM
users and groups.
To size your Oracle VM hardware, first calculate the CPU, memory, and storage requirements for all of your guests. Understanding the
CPU, memory, and storage requirements for all of your guests allows you to accurately determine the CPU, memory, and storage
requirements for your Oracle VM servers and Oracle VM server pools.
Consider, for example, the case of virtualizing one 11g database that requires 16 CPUs, 128GB of memory, and 1TB of storage. The
11g database guest could run on a single Oracle VM server with 4 quad core CPUs (16 cores), 132GB of memory and 1TB of local or
remote storage. The Oracle VM server in the example would run the 11g database guest without oversubscribing CPU or memory
resources. Please note that dom0 requires a minimum of 512MB of memory, therefore the Oracle VM server in the example allocated
132GB of memory for the virtual machine plus 4GB for the overhead in dom0. If the example Oracle VM server uses local storage, it
would be a single server Oracle VM pool. If the Oracle VM server uses a shared storage repository, the Oracle VM server could be a
pool member in a multiserver pool.
Tip: An Oracle VM Manager placement policy can be used to restrict the 11g guest to a specific Oracle VM server.
To virtualize two 11g databases, each database with 16 CPUs and 128GB of memory with 1TB of storage, the two 11g database
guests could both run on a single Oracle VM server with 4 six core CPUs (24 cores), 260GB of memory, and 2TB of local or remote
storage. Running two 11g database guests each with 16 CPUs and 128GB on a single server with 4 six core CPUs (24 cores) would
oversubscribe the Oracle VM server by 8 cores, which may not be an option if your database workload is CPU bound. An example of
not oversubscribing CPUs with two 11g database guests would be to run each guest on a dedicated Oracle VM server with 4 quad
core CPUs, 132 GB of memory, and 1TB of storage.
Oracle offers a wide variety of high-availability solutions for databases, applications, and operating systems that offer different levels
of availability. For example, RAC is Oracle’s database high-availability solution that offers operational continuity in the event of node
failure. Oracle DataGuard and Oracle ApplicationGuard are two other Oracle high-availability solutions that offer operational
continuity in the event of failure.
Oracle VM has two high-availability features; a) guest HA and b) Live Migration. Oracle VM HA automatically restarts guests when;
a) a guest hangs or b) when an Oracle VM pool member fails or restarts. Oracle VM HA minimizes unplanned downtime by restarting
guests. Live Migration is used to eliminate planned downtime by migrating running guests from one Oracle VM pool member to
another during a maintenance event, for example, for repairs or an upgrade. Both HA and Live Migration require a pool configuration
with a minimum of two Oracle VM servers with sufficient memory to run all the guests on one host and a shared storage repository.
An organization’s high-availability and disaster-recovery requirements will directly affect the numbers of guests, Oracle VM servers,
and Oracle VM server pools required to meet your availability SLA. For example, a corporate policy that states that a mission-critical
database requires operational continuity will require a clustering solution such as RAC. From an Oracle VM perspective, supporting a
database that requires operational continuity requires one dedicated Oracle VM server per RAC node for production environments. If
disaster recovery is a requirement for an Oracle VM environment, the number of Oracle VM servers at the disaster-recovery site
would be the minimum number of Oracle VM servers required to run all the guests in the event of an outage of the primary data
center.
Separation of Duties
Separation of duties is also a consideration that affects the number of Oracle VM servers and Oracle VM server pools in an Oracle VM
environment. For example, many organizations require separation of duties between development and production environments or
separation of duties based on geography. Oracle VM supports role-based access control that can be used to isolates Oracle VM
resources such as guests and Oracle VM pools based on user and group membership. Oracle VM role-based access control can isolate
access to guests within a pool or isolate access to an entire a pool based on user and group membership. For example, role-based
access controls could be created for a group named “Development”; these controls could restrict access to resources such as guests,
ISO files, templates, and Oracle VM pools used by the Development group.
Isolating resources within a pool, for example, isolating guests for groups a and b, would not affect the number of Oracle VM servers
within a pool. But isolating resources at the Oracle VM pool level, for example creating a production pool for the Production group
and development pool for the Development group, would require dedicated Oracle VM servers for each group, which, in turn, would
require additional Oracle VM servers and Oracle VM pools.
Understanding your organization’s separation of duties requirements will help to accurately determine the total number of Oracle VM
servers and Oracle VM pools within your Oracle VM environment.
To support Live Migration between Oracle VM pool members, each pool member should have CPUs of the same CPU family and
model. Attempts at Live Migration between two Oracle VM servers with CPUs that are not of the same CPU family and model may fail.
Although the CPUs should be of the same family and model to support Live Migration, each Oracle VM server may have a different
number of sockets and cores.
Tip: To validate the CPU family and model of an Oracle VM server’s CPUs, view /proc/cpuinfo on your Oracle VM server.
To effectively size the number of CPUs and cores for an Oracle VM server, the first step is to count the total number of guest CPUs.
For example, when a guest is allocated a virtual CPU, the virtual CPU is actually a physical CPU core allocated from an Oracle VM
server. A guest with eight virtual CPUs will be allocated eight CPU cores from an Oracle VM server.
Oracle VM server supports oversubscribing CPUs, which means that a single Oracle VM server can overallocate its CPU cores. For
example, an Oracle VM server with four 6 core CPUs (24 cores) could allocate more than 24 cores to guests. Oversubscribing CPUs
with CPU-bound workloads, such as the Oracle Database or RAC, can quickly lead to nasty performance problems. Oversubscribing
CPUs should be used with workloads that are not CPU bound to allow greater utilization of the Oracle VM server hardware. For
example, the Oracle SOA Suite is an Oracle application that is not CPU bound. Oversubscribing CPUs with Oracle SOA Suite guests
would allow greater utilization of the Oracle VM server hardware.
By default, each Oracle VM server reserves 512MB of memory for dom0. The average memory overhead for each running guest on a
dom0 is approximately 20MB plus 1% of the guest’s memory size. The remaining physical memory can be allocated to guests.
The memory requirement for a guest depends on the guest’s workload, but will not vary from the memory required for the same
workload running on bare metal. For example, if you would like to run two Oracle Database 11g guests on a single Oracle VM server
and each guest requires 64GB of memory, the Oracle VM server would have to have a minimum of 130GB of memory for the guests
plus 512MB for dom0.
Note: That 512MB of memory that is reserved for dom0 is configurable by editing the “dom0_mem=” parameter in /boot/grub
/menu.lst file.
The 512MB fixed memory overhead for dom0 is rarely an issue except with servers that only have 1–4GB of memory. There is a
noteworthy difference between the memory overhead of paravirtualized guests verses hardware-virtualized guests. The overhead for
hardware-virtualized guests is much higher than for paravirtualized guests due to the internal data structures, for example, the use of
shadow page tables and dedicated QEMU processes for each guest. The overhead for paravirtualized guests is approximately 8MB
per guest, regardless of the amount of memory assigned to the guest.
Tip: To list the total amount of memory on the system type “xm info | grep mem” in dom0.
To effectively size the amount of memory for an Oracle VM server, the first step is to calculate the total amount of memory for all of
the guests that could run the Oracle VM server. Do not forget to add the overhead for dom0 and the overhead for each guest, that is,
20MB per guest plus 1% of the each guest’s memory size. The total memory requirements for the guests plus dom0’s memory
requirements is the amount of memory required for any Oracle VM server. If HA or Live Migration is used, each Oracle VM server in
the pool would need to have enough memory to run all the guests that could run on a given server at any time.
To determine the amount of memory for an Oracle VM server pool, is is necessary to consider the additional memory overhead from
an HA event or a Live Migration. For example, in an HA-enabled pool with two servers it would be necessary to have enough memory
on each server to run all of the guests in the pool in the event of an Oracle VM server failure.
Oracle VM 2.x does not officially support memory overcommit, which means that an Oracle VM server equipped with xGB of memory
can only allocate the available memory. To be able to support an HA event or Live Migration in an Oracle VM server pool, each Oracle
VM pool member must have enough free memory to be able to accept any new guests. For example, in an HA-enabled pool with two
servers, if one server fails, the available server must have enough free memory to run the guests from the failed server. If an HA event
occurrs between two pool members and the target server does not have enough free memory for the guests, the guests will be
blocked from starting on the target Oracle VM server.
Note: Oracle VM 2.2/Xen 3.4.0 ships with the experimental Xenballoond memory overcommit feature, although Xenballoond memory
overcommit is not enabled or supported by Oracle.
In January 2009, Dan Magenheimer from Oracle announced the "Transcendent Memory" project, "tmem" for short. Tmem will
improve on VMware’s long-available but fatally flawed mechanism for "time-sharing" physical memory between virtual machines,
commonly known as "ballooning .” The results of tmem will be better memory utilization and fewer disk accesses, which, in turn, will
lead to higher performance and greater virtual-machine density per Oracle VM server. Tmem may be included in the Oracle VM 3.0
release.
Oracle VM Server Storage Requirements
Unless the Oracle VM server is booting from SAN, some form of local storage is required. A default Oracle VM 2.2 server installation
creates a “local” OCFS2 virtual machine file system that is mounted under /var/ovs/mount/UUID and linked to /OVS. Using a local
storage repository restricts pool membership to one Oracle VM server without Live Migration or HA functionality. To increase the
capacity of an Oracle VM pool past one Oracle VM server, the addition of a shared back-end storage repository is required.
To determine your storage requirements for a single- or multiple-server Oracle VM server pool, calculate the disk requirements for all
of your guests, ISO files, and templates. To account for growth, consider provisioning at least 30% to 50% more storage for your
Oracle VM storage repositories than the expected size.
Oracle VM’s installation program does not provide the ability to configure shared storage repositories. Storage administration for
storage arrays must be configured after the installation of the server.
To ensure that dom0 and your Xen bridges provide sufficient throughput and availability for guests, consider bonding multiple
network interfaces to increase throughput and availability. For example, mode4 network bonding (802.3AB), running with tagged
VLANs (802.1Q) allows better than single-wire-speed transfers from multiple hosts.
Oracle VM’s installation program does not include network interfaces bonding and VLAN configurations. Network interfaces bonding
and VLAN configurations must be done after the installation of the server.
mapper-multipath drivers.
Before a boot from SAN installation is started, ensure that the blade chassis or servers are configured to support boot from SAN.
Next, provision, zone and mask at least two LUNs. One unique LUN per server is the the boot LUN. The boot LUN is where Oracle VM
server is installed. Do not use the second LUN during the installation. After the installation, the second LUN will be formatted with
OCFS2 and configured as the shared root storage repository. The shared root storage repository is the virtual machine file system that
is shared between all of the Oracle VM server pool members. To enable the boot from SAN installation option, when the server boots
using the Oracle VM ISO, it is necessary to pass the mpath parameter. The next example shows how to pass the mpath parameter
from the Oracle VM server boot prompt.
Typing “boot: linux mpath [enter]” from the boot prompt at the first Oracle VM Server screen tells the installer to use the device-
mapper-multipath drivers. Once the installer is using the device-mapper-multipath drivers, all zoned and maked LUNs will be visable
during the installation process. Be sure to only select the boot LUN for the installation!
Before a boot from SAN installation is started, ensure that the blade chassis or servers are configured to support boot from SAN.
Next, provision, zone and mask at least two LUNs. One unique LUN per server is the the boot LUN. The boot LUN is where Oracle VM
server is installed. Do not use the second LUN during the installation. After the installation, the second LUN will be formatted with
OCFS2 and configured as the shared root storage repository. The shared root storage repository is the virtual machine file system that
is shared between all of the Oracle VM server pool members. To enable the boot from SAN installation option, when the server boots
using the Oracle VM ISO, it is necessary to pass the mpath parameter. The next example shows how to pass the mpath parameter
from the Oracle VM server boot prompt.
Typing “boot: linux mpath [enter]” from the boot prompt at the first Oracle VM Server screen tells the installer to use the device-
mapper-multipath drivers. Once the installer is using the device-mapper-multipath drivers, all zoned and maked LUNs will be visable
during the installation process. Be sure to only select the boot LUN for the installation!
Tip: Installing Oracle VM server using a bootable CDROM with Lights out Management (LOM) solutions may generate file copy
installation errors. If you experience file copy errors, stage the Oracle VM server media files on the a) Hard Disk b) NFS image c) FTP
or d) HTTP and from the installation boot prompt type "boot: linux askmethod [enter] to enable the Install Method installation
screen.
4. a) To Install Oracle VM server on the local hard drive: Press the Enter key to start the install program. If the Enter key is not
pressed for one minute, the install program will automatically start.
4. b) To install Oracle VM server to Boot from SAN: To enable the boot from SAN option, type “linux mpath [enter]” at the boot
prompt. Typing “boot: linux mpath [enter]” tells the installer to use the device-mapper-multipath drivers. The next example show
how to enable the boot from SAN option.
Typing boot: linux mpath [enter] will continue the installation process.
4. c) To Install Oracle VM server from Other Sources: From the installation boot prompt type "boot: linux askmethod [enter] to
enable the Install Method installation screen. From the Install Method installation screen, select and enter the details for the Hard
drive, NFS image, FTP or HTTP installation media.
The next example show how to enable the Install Method installation screen.
Warning screen
If you see the Warning screen, use the Tab key to select the Yes button, then press Enter to continue.
Use the Tab key to select the Remove all partitions and create a new default partition layout option. Ensure that the
appropriate drive is select in the Which drive(s) do you want to use for this installation section. Use the Tab key to select the
OK button to continue.
Warning screen
Since we selected the Remove all partitions and create a new default partition layout option, a Warning screen is displayed to
confirm that we want to remove the partition(s), including all of the data contained on any of the selected partitions. Use the Tab key
to select the YES button to continue.
Partitioning screen
On the Partitioning screen, use the Tab key to select the /OVS Mount Point, then use the Tab key to select the Delete button.
Press Enter to continue.
Partitioning screen
On the Partitioning screen, use the Tab key to select the / Mount Point, then use the Tab key to select the Edit button. Press
Enter to continue.
Partitioning screen
On the Partitioning screen, use the Tab key to select the OK button. Press Enter to continue.
Note: dom0’s management interface defaults to eth0, which is controlled in the /etc/ovs-config file. The dom0 management interface
can be changed after the installation.
If your Oracle VM server will use DHCP to assign its IP address, select the Dynamic IP configuration (DHCP) option.To select the
Dynamic IP configuration (DHCP) entry, use the Tab key to highlight the Dynamic IP configuration (DHCP) entry, then use the
Space bar to select the Dynamic IP configuration (DHCP) entry. Use the Tab key to select the OK button to continue.
If your Oracle VM server will use a static IP address, select the Manual address configuration entry.To select the Manual address
configuration entry use the Tab key to highlight the Manual address configuration entry, then use the Space bar to select the
Manual address configuration entry. Next, use the Tab key to enter the IP Address and Prefix (netmask). Use the Tab key to select
the OK button to continue.
If the machine uses DHCP to assign its hostname, select the automatically via DHCP option. Then, use the Tab key to select the OK
button to continue.
To assign a hostname for your Oracle VM server, select the manually option and enter the fully qualified domain name (FQDN) in the
text box. Then, use the Tab key to select the OK button to continue.
The Oracle VM agent password is used by Oracle VM Manager and the Oracle VM Management Pack to dispatch commands and to
retrieve pool-status data. The Oracle VM agent password can be changed after the installation using Oracle VM Manager or the
Oracle VM Management Pack and from dom0 by typing “service ovs-agent configure”.
not match, the installation program will ask you to reenter the passwords.
Complete screen
When the Complete screen appears, remove the Oracle VM Server media from the CD-ROM drive and press Enter to reboot the
Oracle VM server.
Note: Remain at the Oracle VM servers console until the server reboots in order to accept the End User License Agreement, which is
displayed after the server reboots. For example, if you ssh in to the server after the reboot, you will not be presented with the End
User License Agreement. If the End User License Agreement is not accepted after the reboot, the Oracle VM agent will not be
started.
TIP: If you ssh in to the server after the reboot, you will not be presented with the End User License Agreement. If the End User
License Agreement is not accepted after the reboot, the Oracle VM agent will not be started.
2. Ensure that all the Oracle VM servers’ clocks are synchronized using NTP.
First, open the “/etc/ntp.conf” file by typing “vi /etc/ntp.conf” and validate that at least two available NTP servers entries are listed.
The next example shows two bold NTP server entries in an ntp.conf file.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server myntp1.com
server myntp2.com
Ping each NTP server listed in the ntp.conf file from each Oracle VM server to ensure network connectivity.
Next, type "ntpstat" on each Oracle VM server to validate the NTP configuration. The next example shows the output from typing the
ntpstat command on an Oracle VM server that has its time synchronized to an NTP server with the IP address of 192.168.4.251.
# ntpstat
synchronized to NTP server (192.168.4.251)
at stratum 4
time correct to within 54 ms
polling server every 1024 s
Finally, validate that the time, date and time zone on each Oracle VM server as well as on the Oracle VM Manager host is
3. All Oracle VM servers have consistent name resolution using DNS with both forward and reverse lookups.
First, open the “/etc/resolv.conf” file by typing “vi /etc/resolv.conf” and validate that two available DNS servers are listed. The next
example shows two DNS servers listed in a resolve.conf file.
# vi /etc/resolve.conf
nameserver <MY DNS SERVER1 IP ADDRESS>
nameserver <MY DNS SERVER2 IP ADDRESS>
From each Oracle VM server ping each DNS server listed in the resolv.conf file to ensure network connectivity.
Next, validate the forward and reverse lookups for each Oracle VM pool member and the Oracle VM Manager host using the “host”
command. For example, to validate server2's forward lookup from server1 type “host server2” as shown in the next example.
# host server2
server2 has address
192.168.4.6
Next, to validate server2's reverse lookup from server1 type “host 192.168.4.6” as shown in the next example.
# host 192.168.4.6
6.4.168.192.in-addr.arpa domain
name pointer
server2
Note: Using hosts files without DNS is not advised and may produce unpredictable results.
4. The Oracle VM server’s host name in the /etc/hosts file must be associated with the Oracle VM server's public IP address. If an
Oracle VM pool member's host name is associated with 127.0.0.1, the cluster.conf file will be malformed and the Oracle VM pool will
not be operational. The next example shows the improper syntax from an Oracle VM server's hosts file entry.
The next example shows the proper syntax for an Oracle VM server’s hosts file entry.
127.0.0.1 localhost.localdomain
localhost
192.168.4.8 servername.com
servername
5. ocfs2 network connectivity between all Oracle VM server pool members must be operational before creating a multiple server pool.
Check the ocfs2 network connectivity between all Oracle VM pool members by typing "nc -zv <myoraclevmserver1> 7777". For
example, if you have two Oracle VM servers named ovs1 and ovs2, from ovs1 type "nc -zv ovs2 7777". Typing "nc -zv ovs2 7777" from
ovs1 should return "succeeded!". If you receive a "failed: Connection refused" message between any Oracle VM servers, something
(firewall, switch, router, cable, etc..) is restricting communication between the hosts.
The iptables firewall on an Oracle VM server may be blocking the ocfs2 connectivity. If iptables is disabled and allowing all
connections, the output from typing “iptables -L” will look like the next example.
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
After you have added the above bold iptables rule, restart the iptables service by typing "service iptables restart".
This section discusses a default Oracle VM installation with local storage. A default Oracle VM server installation will allocate most of
the disk space to the /OVS partition. The difference between an installation for an Oracle VM server with local storage and a pool
member is that the pool member does not need an /OVS partition with dedicated storage. A pool member installation removes the
default /OVS partition and reallocates the disk space from the /OVS partition to the / partition.
Tip: Installing Oracle VM server using a bootable CDROM with Lights out Management (LOM) solutions may generate file copy
installation errors. If you experience file copy errors, stage the Oracle VM server media files on the a) Hard Disk b) NFS image c) FTP
or d) HTTP and from the installation boot prompt type "boot: linux askmethod [enter] to enable the Install Method installation
screen.
4. a) To Install Oracle VM server on the local hard drive: Press the Enter key to start the install program. If the Enter key is not
pressed for one minute, the install program will automatically start.
4. b) To Install Oracle VM server from Other Sources: From the installation boot prompt type "boot: linux askmethod [enter] to
enable the Install Method installation screen. From the Install Method installation screen, select and enter the details for the Hard
drive, NFS image, FTP or HTTP installation media.
The next example show how to enable the Install Method installation screen.
Warning screen
If you see the Warning screen, use the Tab key to select the Yes button, then press Enter to continue.
Use the Tab key to select the Remove all partitions and create a new default partition layout option. Ensure that the
appropriate drive is select in the Which drive(s) do you want to use for this installation section. Use the Tab key to select the
OK button to continue.
Warning screen
Since we selected the Remove all partitions and create a new default partition layout option, a Warning screen is displayed to
confirm that we want to remove the partition(s), including all of the data contained on any of the selected partitions. Use the Tab key
to select the YES button to continue.
partition as the location to install the boot loader. For this example, we selected the Master Boot Record (MBR) option.Use the
Tab key to select the OK button and press Enter to continue.
Note: dom0’s management interface defaults to eth0, which is controlled in the /etc/ovs-config file. The dom0 management interface
can be changed after the installation.
If your Oracle VM server will use DHCP to assign its IP address, select the Dynamic IP configuration (DHCP) option.You can select
the Dynamic IP configuration (DHCP) entry by using the Tab key to highlight the Dynamic IP configuration (DHCP) entry then
use the Space bar to select the Dynamic IP configuration (DHCP) entry. Use the Tab key to select the OK button to continue.
If your Oracle VM server will use a static IP address, select the Manual address configuration entry.You can select the Manual
address configuration entry by using the Tab key to highlight the Manual address configuration entry, then use the Space bar to
select the Manual address configuration entry. Next, use the Tab key to enter the IP Address and Prefix (netmask). Use the Tab
key to select the OK button to continue.
If the machine uses DHCP to assign its hostname, select the automatically via DHCP option. Use the Tab key to select the OK
button to continue.
To assign a hostname for your Oracle VM server, select the manually option and enter the fully qualified domain name (FQDN) in the
text box. Use the Tab key to select the OK button to continue.
On the Time Zone Selection screen select the System clock uses UTC option to use Coordinated Universal Time (UTC), then use
the Tab key and the UP or DOWN key (↑ or ↓) to select the time zone closest to your Oracle VM server’s physical location. Use the
Tab key to select the OK button and press Enter to continue.
The Oracle VM agent password is used by Oracle VM Manager and the Oracle VM Management Pack to dispatch commands and to
retrieve pool status data. The Oracle VM agent password can be changed after the installation using Oracle VM Manager or the
Oracle VM Management Pack, or from dom0 by typing “service ovs-agent configure”.
Complete screen
When the Complete screen appears, remove the Oracle VM Server media from the CD-ROM drive and press Enter to reboot the
Oracle VM server.
TIP: Remain at the Oracle VM servers console until the server reboots to be able to accept the End User License Agreement, which is
displayed after the server reboots. For example, if you ssh in to the server after the reboot you will not be presented with the End
User License Agreement. If the End User License Agreement is not accepted after the reboot, the Oracle VM agent will not be
started.
TIP: If you ssh in to the server after the reboot you will not be presented with the End User License Agreement. If the End User
License Agreement is not accepted after the reboot the Oracle VM agent will not be started.
2. Ensure that all the Oracle VM servers’ clock is synchronized using NTP.
First, open the “/etc/ntp.conf” file by typing “vi /etc/ntp.conf” and validate that at least two available NTP servers entries are listed.
The next example shows two bold NTP server entries in an ntp.conf file.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server myntp1.com
server myntp2.com
Ping each NTP server listed in the ntp.conf file from each Oracle VM server to ensure network connectivity.
Next, type "ntpstat" on each Oracle VM server to validate the NTP configuration. The next example shows the output from typing the
ntpstat command on an Oracle VM server that has its time synchronized to an NTP server with the IP address of 192.168.4.251.
# ntpstat
synchronized to NTP server (192.168.4.251)
at stratum 4
time correct to within 54 ms
polling server every 1024 s
Finally, validate that the time, date and time zone on each Oracle VM server as well as on the Oracle VM Manager host is
synchronized by typing the "date" command.
3. The Oracle VM server must have consistent name resolution using DNS with both forward and reverse lookups.
First, open the “/etc/resolv.conf” file by typing “vi /etc/resolv.conf” and validate that two available DNS servers are listed. The next
# vi /etc/resolve.conf
nameserver <MY DNS SERVER1 IP ADDRESS>
nameserver <MY DNS SERVER2 IP ADDRESS>
From each Oracle VM server ping each DNS server listed in the resolv.conf file to ensure network connectivity.
Next, validate the forward and reverse lookups for each Oracle VM pool member and the Oracle VM Manager host using the “host”
command. For example, to validate server2's forward lookup from server1 type “host server2” as shown in the next example.
# host server2
server2 has address
192.168.4.6
Next, to validate server2's reverse lookup from server1 type “host 192.168.4.6” as shown in the next example.
# host 192.168.4.6
6.4.168.192.in-addr.arpa domain
name pointer
server2
Note: Using hosts files without DNS is not advised and may produce unpredictable results.
4. The Oracle VM server’s host name in the /etc/hosts file must be associated with the Oracle VM server's public IP address. If an
Oracle VM pool member's host name is associated with 127.0.0.1, the cluster.conf file will be malformed and the Oracle VM pool will
not be operational. The next example shows the improper syntax from an Oracle VM server's hosts file entry.
The next example shows the proper syntax for an Oracle VM server’s hosts file entry.
127.0.0.1 localhost.localdomain
localhost
192.168.4.8 servername.com
servername
This section discusses how to configure an Enterprise Linux boot server with DHCP, TFTP, and HTTP. The boot server allows a
bare-metal system to receive an IP address via DHCP, load a kernel via TFTP, and boot without an operating system. Next, the
kickstart file orchestrates an automated Oracle VM server installation. Once the installation is completed, a personalized Oracle VM
server is booted and can be added to a pool using Oracle VM Manager or the Oracle VM Management Pack.
The DHCP service will be configured with network-specific details along with the IP addresses of the Oracle VM servers you will
PXE/kickstart install. You will need to change the example network details with your specific environmental networking details.
The TFTP service will be configured with a /tftpboot directory populated with:
The HTTP server will be configured with default settings and used to host the Oracle VM media files and the kickstart files.
Installing Apache from a registered Enterprise Linux host from the Unbreakable Linux Network is accomplished by typing “up2date -i
httpd” while logged in as root or using sudo. Once Apache is installed, configure Apache to automatically start by typing “chkconfig
httpd on”. Next, start Apache by typing “service httpd start”. The next example shows how to install, configure and start Apache.
Once the “up2date -i httpd”, “chkconfig httpd on” and “service httpd start” commands have finished, test your Apache server by
pointing a web browser to the fully qualified domain name (FQDN) or the IP address of the Apache server. You will see the default
Apache test page as shown in Figure 46.
Tip: If you don’t see the default Apache test page, check if iptables is blocking http traffic on the Apache host. Consider disabling
iptables to test Apache by typing “sudo /sbin/service iptables stop”.
The “If you are the website administrator:” section of the default Apache test page explains how to disable the test page and to enable
the default web root directory at /var/www/html. To disable the Apache test page and to enable the default web root at /var/www
/html, access the Apache server and comment out all the entries in the /etc/httpd/conf.d/welcome.conf file. The next example shows
the default /etc/httpd/conf.d/welcome.conf file.
The next example shows the /etc/httpd/conf.d/welcome.conf file with all the entries commented out.
To test the new configuration restart Apache, as shown in the next example.
To view the default root directory of your Apache server located at /var/www/html refresh your browser or point a browser to the fully
qualified domain name (FQDN) or the IP address of the Apache server. You will be presented with the Apache root directory as shown
in Figure 47.
How to Make the Oracle VM Server Installation Tree Available for a PXE/Kickstart Installation
This section discusses how to make the Oracle VM server installation tree available for a PXE/kickstart installation on a boot server in
the /var/www/html/ovs2.2 directory. All of the steps below are completed on the boot server using sudo or root.
The next example shows how to create the directories, mount and copy the installation files and change the ownership of the ovs2.2
directory.
To confirm that the Oracle VM server installation tree is available for the PXE/kickstart installation via HTTP, point your browser to
the ovs2.2 directory, that is, http://<FQDN>/ovs2.2. You will see the installation files as shown in Figure 48.
1- The first step is to install the DHCP service. Using sudo or root, type “up2date -i dhcp” as shown in the next example.
2- Next, we will configure the startup parameters for the dhcpd daemon, by typing “chkconfig --list dhcpd”. Then, type “chkconfig
dhcpd on” to configure the dhcpd daemon to start at runlevels 2, 3, 4 and 5. Next, type “chkconfig --list dhcpd” to validate the dhcpd
3- Next, we will configure the DHCP server’s /etc/dhcpd.conf file. The default DHCP configuration file is located at /etc/dhcpd.conf.
An example dhcpd.conf file is located at /usr/share/doc/dhcp-3.0.5/dhcpd.conf.sample.
ddns-update-style none;
allow booting; # support PXE booting
allow bootp; # respond to bootp queries
default-lease-time 120;
max-lease-time 120;
next-server 192.168.4.11;
pool {
range dynamic-bootp 192.168.4.199 192.168.4.230;
}
#Oracle VM 2.2 Kickstart boxes
group {
filename "pxelinux.0";
host ovs2
{ hardware ethernet 00:30:48:7F:44:6E; fixed-address 192.168.4.199; }
host ovs3
{ hardware ethernet 00:30:48:7F:35:0A; fixed-address 192.168.4.198; }
}
}
The example dhcpd.conf file will configure the DHCP server to respond to DHCP requests on the 192.168.4.0 network with a netmask
of 255.255.255.0, as shown in the next example.
Replace the 192.168.4.0 network address and the 255.255.255.0 subnet mask with your network address and subnet mask.
The next section of the dhcpd.conf file configures the router, subnet mask, nis-domain, domain name, name server, and time zone.
Replace the router, subnet mask, nis-domain (if applicable), domain name (optional), name server (DNS), and time zone with your
environmental details.
The next section lists the next-server entry, which is the IP address of your boot server.
next-server 192.168.4.11;
The next section of the dhcpd.conf file shows the IP address range the DHCP server will assign to DHCP clients. For example, the
DHCP server will assign IP addresses from 192.168.4.199 to 192.168.4.230.
Replace the 192.168.4.199 192.168.4.230 address range with your DHCP IP address range.
The next section of the dhcpd.conf file lists a descriptive name, MAC address, and the fixed IP address of each Oracle VM server that
will PXE boot.
host ovs2
{ hardware ethernet 00:30:48:7F:44:6E; fixed-address 192.168.4.199; }
host ovs3
{ hardware ethernet 00:30:48:7F:35:0A; fixed-address 192.168.4.198; }
Replace the host section with a descriptive name for your Oracle VM server, for example, “host server-name”. Next, replace the MAC
address and the fixed IP address with your server’s details.
Tip: If your servers have an OS installed, type “ifconfig -a” for nix hosts or “ipconfig /all” for Windows to list each NICs MAC address.
If your servers do not have an OS, enable the PXE boot option in the system BIOS. Once PXE boot is enabled, you should be able to
see the MAC addresses during the system startup.
4- Once you have the entries in the dhcpd.conf file, restart the DHCP service by typing “service dhcpd restart”, as shown in the
next example.
Note: It’s necessary to restart the DHCP service to recognize any modifications made to the dhcpd.conf file.
The tftp service is managed by xinetd. The default xinetd configuration disables tftp. To enable the tftp service, edit /etc/xinetd.d/tftp
and change the “disable = off” line to “disable = on”.
Once the tftp service is enabled, configure the startup parameters for the xinetd daemon by typing “chkconfig xinetd on”. Typing
“chkconfig xinetd on” configures the xinetd daemon to start at runlevels 2, 3, 4, and 5. Next, type “chkconfig --list xinetd” to list
xinetd’s runlevels, as shown in the next example.
Next, restart the xinetd service by typing “service xinetd restart”, as shown in the next example.
To confirm that the tftp service is running, type “netstat -l -u | grep tftp”, as shown in the next example.
If no output is displayed after typing “netstat -l -u | grep tftp”, the tftp service is not running. The example confirms that the tftp
service is up.
Tip: Consider disabling iptables during the testing phase by typing “sudo /sbin/service iptables stop”.
C0A804C7
C0A804C6
In the next section, we will prepare the PXE boot files in the /tftpboot directory. All of the steps below are completed on the boot
server using sudo or root.
The next example show the contents of the /tftpboot directory after Steps 1 through 5.
# tree /tftpboot/
/tftpboot/
|
|-- ovm
| `-- 2.2
| `-- initrd.img
|-- pxelinux.0
|-- pxelinux.cfg
`-- vmlinuz
6. Next, we will create two unique PXE boot files. Each PXE boot file has a unique name that represents the hex number of the IP
address of the server. A PXE boot file contains the PXE boot and kickstart configurations. The PXE boot configurations are
identical for all Oracle VM servers and allow the bare-metal systems to load a kernel via TFTP and boot without an operating
system. The kickstart configuration is different for each PXE boot file. Each PXE boot file parses a unique kickstart file that
personalizes the kickstart installation.
To convert an IP address to the hex value for a PXE boot file, use the “gethostip” program by typing “gethostip -x <IP ADDRESS>”.
The next example shows how to list the hex values for 192.168.4.199 and 192.168.4.198.
# gethostip -x 192.168.4.199
C0A804C7
# gethostip -x 192.168.4.198
C0A804C6
The first PXE boot file is named C0A804C7 and is for the Oracle VM server in the dhcpd.conf file named ovs2. The next example
shows ovs2’s entry in the dhcpd.conf file.
host ovs2
{ hardware ethernet 00:30:48:7F:44:6E; fixed-address 192.168.4.199; }
The next example shows how to get the name of the PXE boot file for ovs2, that is, 192.168.4.199.
# gethostip -x 192.168.4.199
C0A804C7
The second PXE boot file named is C0A804C6 and is for the Oracle VM server in the dhcpd.conf file named ovs3. The next example
shows ovs3’s entry in the dhcpd.conf file.
host ovs3
{ hardware ethernet 00:30:48:7F:35:0A; fixed-address
192.168.4.198; }
The next example shows how to get the name of the PXE boot file for ovs3, that is 192.168.4.198.
# gethostip -x 192.168.4.198
C0A804C6
Next, create the PXE boot file for ovs2 (192.168.4.199) by typing “vi /tftpboot/pxelinux.cfg/C0A804C7”. Enter the configurations
shown below and save the file.
# vi /tftpboot/pxelinux.cfg/C0A804C7
default ovsboot
label ovsboot
kernel vmlinuz
append initrd=ovm/2.2/initrd.img ks=http://192.168.4.11/ovs2-ks.cfg ksdevice=eth0
:wq!
Typing “vi /tftpboot/pxelinux.cfg/C0A804C7” creates a PXE boot file C0A804C7 in /tftpboot/pxelinux.cfg/. The default line is required.
You can change the description from the default line, that is, replace ovsboot with any descriptive name. The label line is also
required. You can change the description from the label line, that is, replace ovsboot with any name. The kernel vmlinuz line
configures the PXE boot system to load the compressed Linux kernel “vmlinuz”. The append initrd=ovm/2.2/initrd.img
ks=http://192.168.4.11/ovs2-ks.cfg ksdevice=eth0 line configures a) the initial RAM disk “initrd.img” and b) the kickstart file
ovs2-ks.cfg on the boot server. Pressing the Esc key followed by :wq! saves the C0A804C7 file.
Note: The kickstart file can be staged using http, ftp, or nfs, as shown in the next example.
ks=http://192.168.4.11/ovs3-ks.cfg
ks=ftp:// 192.168.4.11/ovs3-ks.cfg
ks=nfs:192.168.4.11/ovs3-ks.cfg
Next, create a PXE boot file for ovs3 (192.168.4.198) by typing “vi /tftpboot/pxelinux.cfg/ C0A804C6”. Enter the configurations shown
below and save the file.
vi /tftpboot/pxelinux.cfg/C0A804C6
default ovsboot
label ovsboot
kernel vmlinuz
append initrd=ovm/2.2/initrd.img ks=http://192.168.4.11/ovs3-ks.cfg ksdevice=eth0
:wq!
Finally, make sure all files and directories in /tftpboot have the right permission set. The next example shows how to set the correct
permissions for the files and directories in /tftpboot.
The next example shows all of the directories and files in the /tftpboot directory.
# tree /tftpboot/
/tftpboot/
|
|-- ovm
| `-- 2.2
| `-- initrd.img
|-- pxelinux.0
|-- pxelinux.cfg
| `-- C0A804C7
| `-- C0A804C6
`-- vmlinuz
Each Oracle VM server installation generates a generic anaconda kickstart file in the /root directory, named anaconda-ks.cfg. The
kickstart file is used by anaconda during the installation process to define the installation parameters. The default anaconda-ks.cfg file
lists the answers to each Oracle VM server installation question and field entry required by the installation program. If any of the
required fields are missing from a kickstart file the installation halts and waits for input.
Example 1 shows a default Oracle VM anaconda kickstart file. The bold sections need to be modified to create a kickstart file for your
environment.
Example 1
install
cdrom
lang en_US.UTF-8
network --device eth0 --bootproto static --ip 192.168.4.6 --netmask 255.255.255.0 --gateway 192.168.4.254 --nameserver
192.168.4.11 --hostname ovs1.sf.itnc.com
ovsagent --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxx
ovsmgmntif eth0
rootpw --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxx
firewall --enabled --port=21:tcp --port=22:tcp --port=53:udp --port=53:tcp --port=80:tcp --port=2049:tcp --port=5900-5950:tcp
--port=8002:tcp --port=8003:tcp --port=8899:tcp --port=7777:tcp
authconfig --enableshadow --enablemd5
selinux --disabled
timezone --utc America/Los_Angeles
bootloader --location=mbr --dom0_mem=569 --driveorder=sda
# The following is the partition information you requested
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
#clearpart --all --drives=sda
#part /boot --fstype ext3 --size=100 --ondisk=sda
#part / --fstype ext3 --size=3072 --ondisk=sda
#part /OVS --fstype ocfs2 --size=1024 --grow --ondisk=sda
#part swap --size=1024 --ondisk=sda
%packages
@office
@admin-tools
@editors
@text-internet
@gnome-desktop
@dialup
@core
@base
@games
@java
@base-x
@graphics
@printing
@sound-and-video
@ovs-virtualization
@graphical-internet
tftp
bridge-utils
squashfs-tools
The default kickstart file must be modified before you can test a PXE/kickstart installation. The next list show the sections of the
default kickstart file that need to be modified for your environment.
cdrom
network --device eth0 --bootproto static --ip 192.168.4.7 --netmask 255.255.255.0 --gateway 192.168.4.254 --nameserver
192.168.4.11 --hostname ovs2.sf.itnc.com
ovsagent --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxx
rootpw --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxx
timezone --utc America/Los_Angeles
#clearpart --all --drives=sda
#part /boot --fstype ext3 --size=100 --ondisk=sda
#part / --fstype ext3 --size=3072 --ondisk=sda
#part /OVS --fstype ocfs2 --size=1024 --grow --ondisk=sda
#part swap --size=1024 --ondisk=sda
%packages
Tip: To review an exhaustive list of kickstart file options, please consult the following resources:
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/s1-kickstart2-options.html
http://fedoraproject.org/wiki/Anaconda/Kickstart
Example 2 is a commented kickstart file that was modified from the default anaconda kickstart file and will be used to install an
Oracle VM server pool member named ovs2.sf.itnc.com. The Oracle VM server ovs2.sf.itnc.com will not have a local storage
repository, that is, an /OVS directory. The bold sections need to be modified for your environment.
Note: Timezone details and entries are listed in the /usr/share/zoneinfo/ directory.
Example 2
### Installation
Install
### Keyboard layout
lang en_US.UTF-8
keyboard us
### Skips using X windows
skipx
### Installation source
url --url http://192.168.4.11/ovs2.2/
### Network configurations
network --device eth0 --bootproto static --ip 192.168.4.7 --netmask 255.255.255.0 --gateway 192.168.4.254 --nameserver
192.168.4.11 --hostname ovs2.sf.itnc.com
### Oracle VM server agent password
ovsagent --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxx
### Oracle VM agent management interface
ovsmgmntif eth0
### Root password
rootpw --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxx
### dom0 iptables configuration
firewall --enabled --port=21:tcp --port=22:tcp --port=53:udp --port=53:tcp --port=80:tcp --port=2049:tcp --port=5900-5950:tcp
--port=8002:tcp --port=8003:tcp --port=8899:tcp --port=7777:tcp
### Authentication settings
authconfig --enableshadow --enablemd5
### SELinux configuration
selinux –disabled
### Timezone settings
timezone --utc America/Los_Angeles
### Bootloader configuration
bootloader --location=mbr --dom0_mem=569 --driveorder=sda
### Automatic reboot after install
#reboot
## Partitioning
clearpart --linux
part /boot --fstype=ext3 --size=256
part / --fstype=ext3 --size=1 --grow
part swap --fstype=swap –recommended
## Packages
%packages
@core
@base
@ovs-virtualization
tftp
bridge-utils
Note: Example 2 uses a web server to host the installation source. The installation source can be hosted using http, nfs, or ftp. The
next list shows http, nfs and ftp entries in a kickstart file hosting the installation source.
Example 3 was modified from the default anaconda kickstart file and is used to install an Oracle VM server pool member named
ovs3.sf.itnc.com. ovs3.sf.itnc.com will not have an /OVS directory. The bold sections need to be modified for your environment.
Example 3
install
key --skip
lang en_US.UTF-8
keyboard us
skipx
url --url http://192.168.4.11/ovs2.2/
network --device eth0 --bootproto static --ip 192.168.4.8 --netmask 255.255.255.0 --gateway 192.168.4.254 --nameserver
192.168.4.11 --hostname ovs3.sf.itnc.com
ovsagent --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxxx
ovsmgmntif eth0
rootpw --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxxx
firewall --enabled --port=21:tcp --port=22:tcp --port=53:udp --port=53:tcp --port=80:tcp --port=2049:tcp --port=5900-5950:tcp
--port=8002:tcp --port=8003:tcp --port=8899:tcp --port=7777:tcp
authconfig --enableshadow --enablemd5
selinux --disabled
timezone --utc America/Los_Angeles
bootloader --location=mbr --dom0_mem=569 --driveorder=sda
#reboot
clearpart --linux
part /boot --fstype=ext3 --size=256
part / --fstype=ext3 --size=1 --grow
part swap --fstype=swap --recommended
%packages
@core
@base
@ovs-virtualization
tftp
bridge-utils
Example 4 was modified from the default anaconda kickstart file and is used to install a stand-alone Oracle VM server named
ovs1.sf.itnc.com. ovs1.sf.itnc.com will have a local storage repository in the /OVS directory. The bold sections need to be modified for
your environment.
Example 4
install
key --skip
lang en_US.UTF-8
keyboard us
skipx
url --url http://192.168.4.11/ovs2.2/
network --device eth0 --bootproto static --ip 192.168.4.5 --netmask 255.255.255.0 --gateway 192.168.4.254 --nameserver
192.168.4.11 --hostname ovs1.sf.itnc.com
ovsagent --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ovsmgmntif eth0
rootpw --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
firewall --enabled --port=21:tcp --port=22:tcp --port=53:udp --port=53:tcp --port=80:tcp --port=2049:tcp --port=5900-5950:tcp
Note: None of the example kickstart files will automatically reboot the server after the installation. Uncomment the reboot section of
the kickstart file to have the Oracle VM server automatically reboot after the installation. After a successful PXE/kickstart installation,
either disable the PXE boot feature from the BIOS or comment out the Oracle VM server’s entries in the dhcpd.conf file to disable
PXE boot and to preclude the system from performing additional PXE/kickstart installations.
To generate encrypted passwords for the root user account and the ovs-agent account, use the grub-md5-crypt program. From an
Enterprise Linux host , while logged in as root or using sudo, type “grub-md5-crypt”. You will be prompted for a password and then
asked to confirm the password. The password will not be visible as you type it. The grub-md5-crypt program will then print out the
MD5-encrypted password.
Note: The Oracle VM installation program requires at least six characters each for the root and Oracle VM agent passwords.
# grub-md5-crypt
Password:
Retype password:
xxxxxxxxxxxxxxxxxxxxxxxxxx
Once you have generated the encrypted passwords for the root user account and the ovs-agent account, place the encrypted
passwords in the kickstart file and stage the kickstart file on the boot server.
Kickstart files can be staged using http, ftp, or nfs. The next example shows a PXE boot file named C0A804C7 that points to a
kickstart file (ovs2-ks.cfg) staged on a web server (192.168.4.11).
# vi /tftpboot/pxelinux.cfg/C0A804C7
default ovsboot
label ovsboot
kernel vmlinuz
append initrd=ovm/2.2/initrd.img ks=http://192.168.4.11/ovs2-ks.cfg ksdevice=eth0
:wq!
Note: Kickstart files can be staged using http, ftp, or nfs, as shown in the next example.
ks=http://192.168.4.11/ovs3-ks.cfg
ks=ftp:// 192.168.4.11/ovs3-ks.cfg
ks=nfs:192.168.4.11/ovs3-ks.cfg
To stage kickstart files to a web server, copy the kickstart files to the directory specified in the PXE boot file. The above example uses
the web root directory at /var/www/html, although the example could have used any subdirectory with a descriptive name, such as
http://192.168.4.11/kickstart-files/ovs2-ks.cfg.
Figure 49 shows the staged installation tree in the ovs2.2/ directory along with the kickstart file ovs2-ks.cfg and ovs3-ks.cfg in the
web root directory, that is, the /var/www/html of the example 192.168.4.11 boot/web server.
Note: A kickstart file can be staged in any directory on a web, ftp, or nfs server.
The final step in preparing a PXE boot environment is to enable each system on which you want to perform a PXE/kickstart
installation to boot using PXE. To enable a system’s PXE boot capability, reboot the system and access the system BIOS. From the
system BIOS, locate and enable the PXE boot feature. In some cases, it may be necessary to change the boot order and place PXE
boot at the top of the list.
Tip: Many systems use the "F12" hotkey to access the boot methods selection screen, while others systems require BIOS access to
enable PXE boot. Consult your vendor’s website for details about your hardware.
If you run into problems when testing your boot server and PXE/kickstart configurations, check /var/log/messages, /var/log/httpd
/access_log and /var/log/httpd/error_logs on the boot server for errors. The /var/log/messages, /var/log/httpd/access_log and /var/log
/httpd/error_log log files on the boot server are where all the DHCP, TFTP and HTTP errors are logged. The next list shows a
PXE/kickstart check list.
Check that your boot server is ready to answer requests from the PXE clients.
Is your tftp service is running? From the boot server, type “netstat -l -u | grep tftp”, as shown in the next example to confirm that the
tftp server is running.
If no output is displayed after typing “netstat -l -u | grep tftp”, the tftp service is not running. The example confirms that the tftp
service is up.
Consider disabling iptables to test the boot server by typing “sudo /sbin/service iptables stop”.
Check the BIOS of each PXE client to ensure that PXE boot is enabled.
When the system boots, do you see the NIC looking for an IP address via DHCP? If not, PXE boot is not enabled.
Check that your PXE client is connected to the same network as the boot server.
If the PXE client is located across a router from the boot server, the PXE client may not be able to receive an IP address from the
DHCP service.
How to Register and Update an Oracle VM Server from the Oracle Unbreakable Linux Network
This section discusses how to register and update an Oracle VM server from the Oracle Unbreakable Linux Network. The section
starts with a brief introduction to the Oracle Unbreakable Linux support program and the Oracle Unbreakable Linux Network (ULN).
The section concludes with an overview of how to register and update an Oracle VM server from the Oracle Unbreakable Linux
Network using the up2date program.
Tip: Even after a fresh installation of Oracle VM, it’s advisable to patch the system before any testing to avoid troubleshooting
patched bugs.
layer, the service request will automatically transition between the application and Oracle VM support engineers.
The Oracle Unbreakable Linux Network is a cloud resource for Oracle Unbreakable Linux support customers that hosts the Oracle
VM and Enterprise Linux RPM repositories, including software patches, updates and fixes. The Oracle Unbreakable Linux Network’s
web portal is located at http://linux.oracle.com. The Oracle Unbreakable Linux Network web portal provides a dashboard and
management interface for all registered Oracle VM and Enterprise Linux systems and RPM channels. The Oracle Unbreakable Linux
Network repositories are used to patch and install RPMs for Oracle VM and Enterprise Linux systems. Oracle Unbreakable Linux
support customers have the option to patch and install RPMs for Oracle VM and Enterprise Linux systems from the Oracle
Unbreakable Linux Network using the up2date program, or from a local yum repository.
Note: Before you can access the Oracle Unbreakable Linux Network it's necessary to create an Oracle Single Signon account. Your
existing My Oracle Support (MOS) Oracle Single Signon account will not work with the Oracle Unbreakable Linux Network until the
account has been registered with the Oracle Unbreakable Linux Network. Click the Register link at the the Oracle Unbreakable Linux
Network portal to a) create a new Oracle Single Signon account or to b) associate your existing Oracle Single Signon account with the
Oracle Unbreakable Linux Network.
The Oracle Unbreakable Linux Network and My Oracle Support, formerly Metalink, are entirely separate systems, accessed by
different URLs, and use different customer service identifiers (CSIs). My Oracle Support is used to interface with Oracle’s enterprise
support organization, whereas the Oracle Unbreakable Linux Network is used to monitor registered Oracle VM and Enterprise Linux
systems and RPMs. A valid customer service identifier (CSI) for Oracle VM or Enterprise Linux is required to access the RPMs at the
Oracle Unbreakable Linux Network. The customer service identifiers for Oracle VM and Enterprise Linux are only valid for the Oracle
Unbreakable Linux Network, not for My Oracle Support.
Note: The customer service identifiers for Oracle VM and Enterprise Linux cannot be entered at the My Oracle Support portal.
Note: Oracle Unbreakable Linux Network access requires a valid Oracle VM customer service identifier.
Figure 51 shows an Oracle VM server being updated from the Oracle Unbreakable Linux Network using the up2date program.
The second option is to update Oracle VM servers using a local yum repository. A local yum repository can be hosted on any
Enterprise Linux system that has been registered with the Unbreakable Linux Network with internet access and Apache. Local yum
repositories are populated and synchronized with RPMs that are hosted at the Unbreakable Linux Network using a script and a local
cron job. The up2date program or the yum program can be used with a local yum repository.
Figure 52 shows an Oracle VM server being updated from a local yum repository.
The third option is boot an Oracle VM server with the latest Oracle VM media in the CD-ROM drive and to select the update option
from the boot prompt. Selecting the update option from the boot prompt will update the Oracle VM Server to the version of the Oracle
VM server media. Once the server has been updated, the system must be patched from the Oracle Unbreakable Linux Network or
from a local yum repository.
In the next section, we discuss the process for registering and updating an Oracle VM Server. The examples will all be performed
from dom0 as root using the up2date command.
3. enableProxy No
4. enableProxyAuth No
11. httpProxy
21. proxyPassword
22. proxyUser
To edit an up2date program item type “up2date –configure” then type the item number. Then, type C to clear the default value or type
q to quit without saving. Next, type the new value and press Enter to save the new value and to exit. If you need to enter multiple
values, separate them with semicolons (;).
Another default up2date configuration for Oracle VM is to not update the Oracle VM server’s kernel. The default configuration avoids
a “blind” kernel update, which could affect any installed programs or third-party drivers that are dependent on a specific kernel
version. If the default kernel configuration is modified to allow kernel updates, previous kernels are not removed, which allows a
system to be rebooted into the previous kernel if things go wrong.
The next example shows the default up2date --config configurations with the proxy and kernel items in bold.
# up2date --config
0. adminAddress ['root@localhost']
1. debug No
2. disallowConfChange ['noReboot', 'sslCACert', 'useNoSSLForPackages', 'noSSLSe
3. enableProxy No
4. enableProxyAuth No
5. enableRollbacks No
6. fileSkipList []
7. forceInstall No
8. gpgKeyRing /etc/sysconfig/rhn/up2date-keyring.gpg
9. headerCacheSize 40
10. headerFetchCount 10
11. httpProxy
12. isatty Yes
13. keepAfterInstall No
14. networkRetries 5
15. noBootLoader No
16. noReboot No
17. noReplaceConfig Yes
18. noSSLServerURL http://linux-update.oracle.com/XMLRPC
19. pkgSkipList ['kernel*']
20. pkgsToInstallNotUp ['kernel', 'kernel-modules', 'kernel-devel']
21. proxyPassword
22. proxyUser
23. removeSkipList ['kernel*']
24. retrieveOnly No
25. retrieveSource No
26. rhnuuid 3cfb2ee2-6a22-11dd-9022-001c23b73c3a
27. serverURL https://linux-update.oracle.com/XMLRPC
28. showAvailablePacka No
29. sslCACert /usr/share/rhn/ULN-CA-CERT
30. storageDir /var/spool/up2date
31. systemIdPath /etc/sysconfig/rhn/systemid
32. updateUp2date Yes
33. useGPG Yes
34. useNoSSLForPackage No
35. useRhn Yes
36. versionOverride
Once the GPG key has been imported, the Oracle VM Server can be registered at the Oracle Unbreakable Linux Network by typing
“up2date” to start the registration process. The registration process requires you to select a user name and password and to enter a
valid Oracle VM Support Identifier number (CSI). The user name and password that are selected during the registration process
become the user name and password to log on to the Oracle Unbreakable Linux Network. The first time you log on and authenticate
your account on the Oracle Unbreakable Linux Network, you will be prompted to convert your user name and password to an Oracle
SSO user name and password. Oracle SSO accounts can be used across Oracle’s web properties, for example on the Oracle Technical
Network (OTN). You can change your user name and password after you have authenticated your account by clicking the Profile link.
The following list shows the six steps to register an Oracle VM host with the Oracle Unbreakable Linux Network:
1. Review the Unbreakable Linux Privacy Statement
2. Register a User Account
3. Register a System Profile—Hardware
4. Register a System Profile—Packages
5. Send Profile Information to the Unbreakable Linux Network
6. Finished Registration
Figure 53 shows the Review the Unbreakable Linux Privacy Statement screen.
Note: The information gathered from the system profile step is saved in your user profile at the Oracle Unbreakable Linux Network.
Figure 57 shows the Send Profile Information to the Unbreakable Linux Network screen.
Table of Contents
Oracle VM Manager Introduction
Oracle VM Manager Resource Requirements
...Supporting Large Oracle VM Manager User Communities
Oracle VM Manager Installation Prerequisites
...libaio RPM Package
...Name Resolution
...Host Firewall & Port Test
...SMTP Server
...Oracle VM Manager Guest Console
Required Installation Passwords and Password Complexity Requirements
Oracle VM Manager Installation
Applying the 2.2.16 Oracle VM Manager Patch
Updating Oracle VM Manager using the Installation Media
...OVS Database and oc4jadmin Accounts and Passwords
...Updating Oracle VM Manager
Oracle VM Manager Database Backup and Restoration
...Oracle VM Manager Database Backup
...Oracle VM Manager Database Restore
Deploying the Oracle VM Manager Template
...Oracle VM Manager Template Prerequisites
...SMTP Server
...User Accounts, Passwords and Password Complexity Requirements
...HTTP and Oracle VM Manager XE Database listening Ports
...Oracle VM Server Cluster Configurations
Download and Deploy the Oracle VM Manager Template
...Running the Deploy_Manager_Template.sh Script
The Oracle VM Manager Command Line Interface Introduction
Downloading the Oracle VM Manager Command Line Interface from ULN
Oracle VM Manager Command Line Interface Installation & Configuration
Oracle VM Manager Command Line Interface Command Examples
...Bulk Commands and Batch Scripting
...Guest Backup
...Create a Server Pool
Programming with the Oracle VM Manager Command Line Interface
Oracle VM 2.1.5 to 2.2 Upgrade
Oracle VM Manager is supported on a physical or virtual Enterprise Linux operating system. Oracle VM Manager is a great candidate
for virtualization on Oracle VM or Oracle VM VirtualBox. Virtualizing Oracle VM saves on hardware costs and improves application
flexibility while reducing data center space.
Note: Oracle VM Manager is not supported and should not be installed in Oracle VM server's dom0.
List 1 shows the supported Enterprise Linux operating systems and virtualization platforms for Oracle VM Manager.
Oracle VM Manager is distributed in three formats; a) as an ISO file that installs on Enterprise Linux b) as a pre-packaged Oracle VM
template (with the CLI) and c) as the Oracle VM Management Pack plug-in.
Oracle VM Manager is considered the leading edge development platform for the Oracle VM Management Pack, which is an Oracle
Enterprise Manager plug-in. Oracle VM Manager 2.1.2 was ported to Oracle Enterprise Manager 10.2.0.5 and Oracle VM Manager
2.2 was ported to Oracle Enterprise Manager 11g R1. Expect at least a six month lag for Oracle to port a new Oracle VM Manager
release to the Oracle VM Management Pack.
Note: The Oracle VM Management Pack is licensed software; Oracle VM Server and Oracle VM Manager are not licensed software.
The next chart shows the matrix of supported Oracle VM Manager and Oracle VM server combinations.
OVM 2.1.0 2.1.1 2.1.2 2.1.5 2.2.0
OVS --------+------+------+-----+------
2.1.0 O | O | O | O | O
2.1.1 X | O | O | O | O
2.1.2 X | X | O | O | O
2.1.5 X | X | X | O | O
2.2.0 X | X | X | X | O
2.2.1 X | X | X | X | O
Note: Oracle VM Manager can manage many Oracle VM server pools, e.g. Oracle VM Manager 2.2 can manage one pool of Oracle
VM 2.1.x servers, another pool of Oracle VM 2.2 servers, and many more server pools; But within the same server pool, all the servers
must have the same version of Oracle VM server and the Oracle VM agent. Mixing Oracle VM 2.1.x and 2.2.x servers in the same pool
is not supported.
Oracle VM Manager resource requirements can be quickly tested with Oracle VM Manager user interface (UI) page response times.
For example, if the Oracle VM Manager user interface is painfully slow or if you experience page timeouts adding memory and CPUs
will speed up the user interface and eliminate page timeouts.
Tip: Oracle VM Manager on VMware is performance challenged and will need substantially more CPU and memory than the minimum
recommendations. Oracle VM Manager is a great fit running on a virtualized Enterprise Linux operating system on an Oracle VM
server.
Table 1 lists Oracle's recommended minimum resource requirements for Oracle VM Manager 2.x.
Description Minimum
Resources
Memory 2 GB
Swap Space 2 GB
Hard Disk 4 GB
Space
The memory and CPU requirements for Oracle VM Manager 2.x scales up as the number of Oracle VM pool members grow.
Table 2 shows the recommended CPU and memory allocation for three different Oracle VM Manager deployments.
> 10 4 GB 2 2 GHz 8 GB
> 32 8 GB 4 2 GHz 8 GB
On the OVM Manager host, edit the “/opt/oc4j/bin/oc4j” file and change this line:
OC4J_JVM_ARGS="-XX:PermSize=256m -XX:MaxPermSize=512m"
to:
OC4J_JVM_ARGS="-XX:PermSize=512m -XX:MaxPermSize=1024m -Xms2048m -Xmx2048m"
Next, restart the OC4J service on the Oracle VM Manager hosts by typing "service oc4j restart".
To validate if your Enterprise Linux system has the libaio 0.3.96 or above package, as root “type rpm -q libaio” as shown in the next
example.
# rpm -q
libaio
libaio-
0.3.106-3.2
If you get no result from typing “rpm -q libaio” you will need to install the libaio package. To install libaio from the Oracle
Unbreakable Linux network type “up2date -i libaio” as shown in the next example.
# up2date -i
libaio
Name Resolution
Before you install Oracle VM Manager ensure that the Oracle VM Manager server's host name is properly entered in the /etc/hosts
file. The host name, i.e. fully qualified domain name (FQDN) must be associated with the public IP address.
The next example shows an “improper” Enterprise Linux /etc/hosts file entry.
localhost
192.168.4.8 servername.com servername
The next example shows the proper syntax for an Enterprise Linux /etc/hosts file entry.
If your Enterprise Linux host uses iptables you will need to allow tcp traffic on ports 8888, 8899 and 4443 to allow access to the
Oracle VM Manager portal.
To allow tcp traffic on ports 8888, 8899 and 4443 on the Oracle VM Manager host, as root or with sudo type the following three
commands:
# system-config-securitylevel-tui -q
-p 8888
# system-config-securitylevel-tui -q
-p 8899
# system-config-securitylevel-tui -q
-p 4443
SMTP Server
Oracle VM Manager has several user notification features that require the use of an SMTP server. During the Oracle VM Manager
installation you will be asked to a) enter the SMTP server IP address or fully qualified domain name and b) the SMTP port and c) a
valid email address and password for the Oracle VM Manager admin account.
Entering the SMTP details during the installation is optional and can be configured after the installation by using the
“update_email.sh” script on the Oracle VM Manager host or by editing the values in Oracle VM Manager repository database table
ovs_sys_value under the OVS schema.
The next example shows how to download and install the TightVNC package on the Oracle VM Manager host as root. The TightVNC
package can be downloaded and installed in any directory, i.e. /tmp on the Enterprise Linux host.
# wget http://oss.oracle.com/oraclevm/manager/RPMS/tightvnc-
java-1.3.9-3.noarch.rpm
# rpm -ivh tightvnc-java-version.noarch.rpm
Note: If you use Firefox on Linux to access the Oracle VM Manager user interface and would like to use the TightVNC guest console
you will also need to install the Oracle VM Manager console plug in (ovm-console) on your Linux workstation. The ovm-console
package is available at http://oss.oracle.com/oraclevm/manager/RPMS/.
List 3 shows the password complexity requirements for the required passwords.
Tip: Select and write down all the passwords before you start the installation. Unfortunately you may not be able to use the same
password for all four services because the Web Service has a slightly different password policy.
During the Oracle VM Manager installation, you are required to set the following ports. Please note that the installer program will
provide defaults.
1. Download the Oracle VM Manager ISO file from the Oracle eDelivery Linux portal.
2. Log in to the Oracle VM Manager host as root.
3. Copy the Oracle VM Manager ISO file to a directory on the Oracle VM Manager host, i.e. to the /tmp directory.
4. Create a directory to mount the ISO file, i.e. mkdir -p /tmp/mount-point.
5. Mount the ISO file by typing “mount -o loop,ro OracleVM-Manager-version.iso mount-point”
6. Change into the directory where the ISO file is mounted, i.e. “cd /tmp/mount-point.
7. Type “sh runInstaller.sh” to start the Oracle VM Manager installation and then type “1” to select the “Install Oracle VM Manager”
option as shown in the next example.
# sh runInstaller.sh
Welcome to Oracle VM Manager 2.2
8. From the ”Do you want to install a new database or use an existing one? [1|2]” prompt type ”1” to select the ”Install a new Oracle
XE database on localhost” option as shown below.
Do you want to install a new database or use an existing one? [1|2]
1. Install a new Oracle XE database on localhost
2. Use an existing Oracle database in my network
1
9. Press the enter key to select the default HTTP port 8080 for Oracle Application Express.
Specify the HTTP port that will be used for Oracle Application Express [8080]:
10. Press the enter key to select the default database listener port 1521.
Specify a port that will be used for the database listener [1521]:
12. Type y and press enter to configure the Oracle Database 10g Express Edition to start on boot.
Do you want Oracle Database 10g Express Edition to be started on boot (y/n) [y]:y
13. Type a secure password for the keystore password for the Web Service.
Please enter the keystore password for the Web Service:
Confirm the password:
14. You can enable HTTPS for the Oracle VM Manager user interface by typing Y, or n if you do not want to enable HTTPS. If you
select Y a private SSL certificate will be generated and used to secure the Oracle VM Manager user interface. In the example we
typed Y to enable HTTPS.
15. Type a secure password for the default Oracle VM Manager admin account. You will use the admin user name and the admin
password to log into the Oracle VM Manager user interface.
16. Type the outgoing SMTP mail server IP address or the fully qualified domain name (optional).
Please enter the outgoing SMTP mail server (e.g. - mail.abc.com, mail.abc.com:25): mail.my.domain.net:25
Mail server checking, may need some time, please wait...
Setting the SMTP server to mail.my.domain.net...
Done
The Oracle VM Manager application was successfully installed and can be accessed by typing https://<Oracle VM Manager
Host>:4443/OVS if you selected HTTPS or http://<Oracle VM Manager Host>:8888/OVS if you did not select HTTPS in a web
browser. Enter the admin user name and the admin password to log into the Oracle VM Manager portal.
List 2 shows the supported Web browsers for the Oracle VM Manager user interface.
If you configured the SMTP server the admin account will receive the following email:
OVM Administrator
To access the Oracle VM Manager 2.2 home page go to:
https://<Oracle VM Manager Host>:4443/OVS
The Oracle Database Express Edition portal can be accessed from the Oracle VM manager server locally by entering
http://127.0.0.1:8080/apex or remotely by entering the ip address or the FQDN followed by :8080/apex, i.e. http://<Oracle VM
Manager Host>:8080/apex in a web browser. You can use the SYS, SYSTEM or the OVS user account and the associated password to
log in to the Oracle Database Express Edition portal.
Figure 3 shows the Oracle Database Express Edition portal login page.
The Application Server Control portal is also part of the Oracle VM Manager install. The oc4jadmin account can be maintained from
the Application Server Control portal. The Application Server Control portal can only be access locally from the Oracle VM Manager
host by typing http://127.0.0.1:8888/em. Use the oc4jadmin account and password to access the Application Server Control portal.
Table 3 lists the ovs-manager-2.2-16.noarch package and the channels where the ovs-manager-2.2-16.noarch package is hosted.
Table 3
ovs-manager-2.2-16.noarch Oracle Software for Enterprise Linux 4 (x86_64) Oracle Software for Enterprise Linux 4 (x86_64)
ovs-manager-2.2-16.noarch Oracle Software for Enterprise Linux 5 (x86_64) Oracle Software for Enterprise Linux 5 (x86_64)
ovs-manager-2.2-16.noarch Oracle Software for Enterprise Linux 5 (i386) Oracle Software for Enterprise Linux 5 (i386)
While applying the ovs-manager-2.2-16.noarch package you will be prompted for a total of three passwords.
The next example shows how to install the ovs-manager-2.2-16.noarch package as root or using sudo.
Updating Oracle VM Manager is accomplished by running the Oracle VM Manager installation program on the Oracle VM Manager
host and to select the upgrade installation option. The Oracle VM Manager installation program will ask for the passwords for the
existing Oracle VM Manager OVS database account and the oc4jadmin account. The Oracle VM Manager OVS database account and
the oc4jadmin account passwords are selected during the Oracle VM Manager installation process. The account passwords for the
Oracle VM Manager OVS database account and the oc4jadmin account can be managed from their respected web portals.
Note: The Oracle Database Express Edition portal and the Application Server Control portal are installed by default with the Oracle
VM Manager portal. The Oracle VM Manager Template does not enclude the Oracle Database Express Edition portal and the
Application Server Control portal.
The next Figure shows the Oracle Database Express Edition portal login page.
The Application Server Control portal is a part of the Oracle VM Manager install. The oc4jadmin account can be maintained from the
Application Server Control portal. The Application Server Control portal can only be accessed locally from the Oracle VM server
console by entering http://127.0.0.1:8888/em in a local web browser.
The next Figure shows the Application Server Control portal login page.
The update process requires you to select the upgrade option from the install prompt as well as enter the passwords for the Oracle
VM Manager OVS database account and the Oracle VM Manager oc4jadmin account.
Step 1 is to download the ISO image from http://edelivery.oracle.com/linux.
Once the ISO image is downloaded and placed on the Oracle VM Manager host or made available from a network share then it should
be mounted as root user.
The following example shows how to mount the Oracle VM Manager ISO image from the Oracle VM Manager server console as root
user.
# mount -o ro,loop OracleVM-Manager-2.1.2.iso mnt/
# cd mnt
# ls
EULA LICENSE readme.txt runInstaller.sh scripts source TRANS.TBL
Step 2 is to execute the runInstaller.sh script within the Oracle VM Manager root directory from the Oracle VM Manager server
console as root.
The following example shows how to execute the runInstaller.sh from the Oracle VM Manager server console as root user.
# sh runInstaller.sh
Step 3 is to select the Upgrade option (number 3) from the install prompt. The next example shows the installation choice prompt.
Please enter the choice: [1|2|3]
1. Install Oracle VM Manager
2. Uninstall Oracle VM Manager
3. Upgrade Oracle VM Manager
Step 4 asks if you would like to proceed or cancel the upgrade. You can enter y to proceed or n to cancel the upgrade. The following
example shows the upgrade acceptance prompt.
Are you sure you want to upgrade Oracle VM Manager from version
2.1.1 to 2.1.2 ? [y|N] y
Step 5 is to enter the OVS password. The following example shows the OVS installation password prompt.
Please enter the password for database account 'OVS':
Step 6 is to enter the oc4jadmin password. The following example shows the oc4jadmin installation password prompt.
Please enter the password for account 'oc4jadmin':
Step 7 is to enter yes or no to backup the Oracle VM Manager database. This step is optional, i.e. entering no will not abort the
upgrade. The following example shows the Oracle VM Manager database backup prompt.
Would you like to back up the Oracle VM Manager database?
Now back up the Oracle VM Manager database to /usr/lib/oracle/xe/app
/oracle/product/10.2.0/server/dump-2008-10-06-05-24-25-PM.dmp
A successful upgrade will exit with the following informational warnings.
Export terminated successfully with warnings.
Done.
The following example shows how to execute the “/opt/ovs-manager-2.2/bin/backup.sh” script from the Oracle VM Manager host as
root user.
# sh /opt/ovs-manager-2.2/bin/backup.sh
Next to backup the Oracle VM Manager database select the Backup Oracle VM Manager option (number 1) from the backup
prompt. The next example shows the backup selection prompt.
sh /opt/ovs-manager-2.2/bin/backup.sh
Welcome to Oracle VM Manager
Completed backup:
Completed backup:
Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
SQL>
PL/SQL procedure successfully completed.
SQL> Disconnected from Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses AL32UTF8 character set (possible charset conversion)
. exporting pre-schema procedural objects and actions
. exporting foreign function library names for user OVS
. exporting PUBLIC type synonyms
. exporting private type synonyms
. exporting object type definitions for user OVS
About to export OVS's objects ...
. exporting database links
. exporting sequence numbers
. exporting cluster definitions
. about to export OVS's tables via Conventional Path ...
. . exporting table OVS_AGENT 2 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_ALERT 11 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_CATEGORY 1 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_CDROM 5 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_CDROM_RESOURCE 0 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_GROUP 4 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_HD_TEMP
. . exporting table OVS_IMG_OS 0 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_IMG_TEMP
. . exporting table OVS_LOCK 19 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_MAP 35 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_NIC_TEMP
. . exporting table OVS_OS_RESOURCE 17 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_PARTNER 0 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_PREFERRED_SERVER 0 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_PRIVILEGE 4 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_PRIVILEGE_ROLE 5 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_RESOURCE 4 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_ROLE 3 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_SERVER 2 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
SQL>
SQL> Disconnected from Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Done
Please check the log file /tmp/ovs.log
#
The following details are required to restore the Oracle VM Manager databasee a) the password for database account 'OVS', which
was assigned during the Oracle VM Manager install, b) the path for dump file, i.e. /tmp/ovs.dmp and c) the path for log file, i.e.
/tmp/ovs.log.
The following example shows how to execute the “/opt/ovs-manager-2.2/bin/backup.sh” script from the Oracle VM Manager server
console as root user.
# sh /opt/ovs-manager-2.2/bin/backup.sh
Next, to backup the Oracle VM Manager database, select the Restore Oracle VM Manager option (number 2) from the backup
prompt. The next example shows the backup selection prompt.
sh /opt/ovs-manager-2.2/bin/backup.sh
Welcome to Oracle VM Manager
Completed backup:
The next example reviews an Oracle VM Manager database restore procedure. Access the Oracle VM Manager server console as root
and type "sh /opt/ovs-manager-2.1/bin/backup.sh" as shown in the following example.
# sh /opt/ovs-manager-2.1/bin/backup.sh
Welcome to Oracle VM Manager
Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
. . importing table "OVS_AGENT" 2 rows imported
. . importing table "OVS_ALERT" 11 rows imported
. . importing table "OVS_CATEGORY" 1 rows imported
. . importing table "OVS_CDROM" 5 rows imported
. . importing table "OVS_CDROM_RESOURCE" 0 rows imported
. . importing table "OVS_GROUP" 4 rows imported
. . importing table "OVS_IMG_OS" 0 rows imported
. . importing table "OVS_LOCK" 19 rows imported
SMTP Server
Oracle VM Manager has several user notification features that require the use of an SMTP server. During the Oracle VM Manager
installation you will be asked to a) enter the SMTP server IP address or fully qualified domain name and b) the SMTP port and c) a
valid email address and password for the Oracle VM Manager admin account.
Entering the SMTP details during the template configuration is optional and can be configured after the template is deployed using
the “update_email.sh” script or by editing the values in Oracle VM Manager repository database table ovs_sys_value under the OVS
schema.
Tip: The Deploy_Manager_Template.sh script can be run with options “--skipsmtpcheck” and “--skipmailcheck” to skip the SMTP
server check and email check.
The default vnc console password for the Oracle VM Manager Template is oracle.
During the Oracle VM Manager Installation you will be prompted for a total of six required passwords.
Tip: The Oracle VM agent password can be reset by typing “service ovs-agent configure” from dom0 as root.
List 6 shows the password complexity requirements for the required passwords.
Tip: Select and write down all the passwords before you start the installation. Unfortunately you may not be able to use the same
password for all four services because the Web Service has a slightly different password policy.
To clean an Oracle VM server's cluster configurations it is necessary to a) empty the /etc/ocfs/cluster.conf file b) delete and recreate
the local BerkleyDB and c) run the cleanup.py script to stop o2cb heartbeat, offline o2cb, remove o2cb configuration file, umount
ovs-agent storage repositories and to cleanup ovs-agent local database.
To clear /etc/ocfs/cluster.conf file type “cat /dev/null> /etc/ocfs2/cluster.conf” from dom0, as shown in the next example.
To stop the o2cb heartbeat, offline o2cb, remove o2cb configuration file, unmount ovs-agent storage repositories and to cleanup
ovs-agent local database, type "/opt/ovs-agent-2.3/utils/cleanup.py" and then type “y” as shown in the next example.
# /opt/ovs-agent-2.3/utils
/cleanup.py
This is a cleanup script for
ovs-agent.
It will try to do the following:
List 7 reviews the five steps to deploy the Oracle VM Manager Template.
1. Download the Oracle VM Manager template named “Oracle VM Manager 2.2.0 for x86 (32 bit) with Oracle Linux 5.4” from
“http://edelivery.oracle.com/linux”. Note: Do not unzip the V21186-01.zip file until Step 2.
2. Copy the zip file named V21186-01.zip to your Oracle VM server's /OVS/running_pool directory.
3. Unzip the V21186-01.zip file. The V21186-01.zip file contains two file, Deploy_Manager_Template.sh and
OVM_EL5U4_X86_OVM_MANAGER_PVM.tgz. Note: Do not untar the OVM_EL5U4_X86_OVM_MANAGER_PVM.tgz file.
4. From dom0 as root type “sh Deploy_Manager_Template.sh”. The Deploy_Manager_Template.sh script is used to check the
prerequisite and gather all the details to configure and create the Oracle VM Manager virtual machine.
5. After the Deploy_Manager_Template.sh script completes and the Oracle VM Manager template is deployed, you will need to wait
about 3 to 5 minutes for the Oracle VM Manager application to start. Once the Oracle VM Manager application is running log in
to the Oracle VM Manager URL that is displayed at the end of the Deploy_Manager_Template.sh script using the admin account
and the password youe selected durring the installation. You can ssh to the Oracle VM Manager Template using the IP address
assigned durring the configuration phase using the root account with the default “ovsroot” password.
Tip: The Deploy_Manager_Template.sh script can be run with options “--skipsmtpcheck” and “--skipmailcheck” to skip the SMTP
server check and email check.
Done
Checking whether Oracle VM Agent DB is clean ...
Done
Note following password setting will be used for SYS and SYSTEM.
Oracle recommends the use of different passwords for each database account.
This can be done after initial configuration.
Done
Move the parameter file to Manager.img
Done
Create Oracle VM Manager virtual machine ...
Done
The Oracle VM Manager virtual machine is booting. To finish the Oracle VM
Manager configuration, connect to the virtual machine console using any
VNC Viewer from a desktop machine via the command:
vncviewer ca-scdemo1:5900
After Oracle VM Manager has been successfully deployed, access the Oracle
VM Manager home page at:
http://10.211.0.216:8888/OVS
List 8 highlights the most common use cases for the Oracle VM Manager Command Line Interface:
Power On, Power Off, Clone, Save as Template, Import, Migrate, Pause, Unpause, Suspend, Resume and Delete virtual
machines
Manage virtual machine resources, including ISO files, virtual machine templates and virtual machine images
Manage Oracle VM Manager users, and Oracle VM Manager groups
Create and configure server pools
Manage the Oracle VM Agent
Checking the status of guests, server, and server pools:
The Oracle VM Manager Command Line Interface (ovmcli) is a stand-alone application that is written in Python that leverages the
Oracle VM Manager Web Services API to communicate with Oracle VM Manager. The Oracle VM Manager Command Line Interface
can be installed on any Oracle Enterprise Linux or RHEL host with connectivity to your Oracle VM Manager system. The Oracle VM
Manager Command Line Interface can be accessed from a local or remote console.
Figure 6 illustrates the Oracle VM Manager Command Line Interface intra-component communication and firewall requirements.
List 9 highlights the Oracle VM Manager Command Line Interface communication ports and system passwords:
Oracle VM Manager:
The Oracle VM Manager Command Line Interface has one prerequisite, namely the python-ZSI RPM. The ovmcli and python-ZSI
RPMs are hosted at ULN. The ovmcli RPM is located in the el5_i386_oracle_addons and the el5_x86_64_oracle_addons channel. The
python-ZSI RPM is located in the el5_i386_addons and el5_x86_64_addons channel.
Note: ULN is password protected. To access ULN you will need a valid Oracle Unbreakable Linux support contract and a CSI number.
Support contracts for Oracle VM can be purchased from your Oracle VM sales representative or directly from the Oracle Store. Once
you have a valid support contract, you can register at the ULN portal or you can register by running the “up2date –register” command
from one of your Oracle VM servers. Please review Oracle VM: How to update an Oracle VM Server for details about registering an
Oracle VM server with ULN.
The Oracle VM Manager Command Line Interface (ovmcli) is hosted at ULN in the el5_i386_oracle_addons and
el5_x86_64_oracle_addons channels. The Oracle VM Manager Command Line Interface prerequisite python-ZSI is hosted in the
el5_i386_addons and el5_x86_64_addons channel.
Table 5 shows the Oracle VM Manager Command Line Interface package names with the associated ULN channel names.
Package ULN Channel
el5_i386_oracle_addons and
ovmcli-1.0-1.el5.noarch.rpm
el5_x86_64_oracle_addons
el5_i386_addons and
python-ZSI-2.1-a1.el5.noarch.rpm
el5_x86_64_addons
1- Point your browser to http://linux.oracle.com as shown in Figure 7. Enter you user name and password and click the Login button
to access ULN.
2- From the ULN home page click on the Channels tab as shown in Figure 8.
3- From the Channels page click the i386_oracle_addons channel for the x86 platform or click the el5_x86_64_oracle_addons
channel for the x86-64 platform to download the appropriate ovmcli RPM.
In our example we are looking for the el5_x86_64_oracle_addons channel which is not displayed on the current page. We will need
to access the next page to locate the el5_x86_64_oracle_addons channel. Click the Next button at the bottom of the page as shown
in Figure 9 to display the next page.
4- From the Channels page click the el5_x86_64_oracle_addons channel as shown in Figure 10.
5- From the Oracle Software addons for Enterprise Linux 5 (X86-64) page, click the Packages link as shown in Figure 11.
6- From the Oracle Software addons for Enterprise Linux 5 (X86-64) > Packages page, click the ovmcli-1.0-1.el5.noarch link
as shown in Figure 12 to display the ovmcli-1.0-1.el5.noarch RPM Package Details page.
7- From the Oracle Software addons for Enterprise Linux 5 (X86-64) > Packages > ovmcli-1.0-1.el5.noarch page, click the ovmcli-
1.0-1.el5.noarch.rpm link as shown in Figure 13 to download the ovmcli-1.0-1.el5.noarch RPM.
Note: The File list link lists the details about all the files for the ovmcli-1.0-1.el5.noarch RPM. The Requires link lists the
requirements for the ovmcli-1.0-1.el5.noarch RPM. The Provides link lists what the ovmcli-1.0-1.el5.noarch RPM provides, i.e.
the ovmcli. The Obsoletes link lists what application(s) the ovmcli-1.0-1.el5.noarch RPM obsoletes. The Conflicts link lists the
conflicts for the ovmcli-1.0-1.el5.noarch RPM.
8- From the Oracle Software addons for Enterprise Linux 5 (X86-64) > Packages > ovmcli-1.0-1.el5.noarch page, click the
Channel link as shown in Figure 14 to return to the Channel page to download the python-ZSI RPM.
9- From the Channels page locate and click the el5_x86_64_addons channel link as shown in Figure 15 to access the Enterprise
Linux 5 Add ons (X86-64) > Packages page.
10- From the Oracle Enterprise Linux 5 Add ons (x86-64) > Packages page click the python-ZSI-2.1-a1.el5.noarch.rpm link as
shown in Figure 16 to display the Enterprise Linux 5 Add ons (X86-64) > Packages > python-ZSI-2.1-a1.el5.noarch.rpm page.
11- From the Enterprise Linux 5 Add ons (X86-64) > Packages > python-ZSI-2.1-a1.el5.noarch.rpm page, click the python-
ZSI-2.1-a1.el5.noarch.rpm link as shown in Figure 17 to download the python-ZSI-2.1-a1.el5.noarch.rpm RPM.
Note: The File list link lists the details about all the files for the python-ZSI-2.1-a1.el5.noarch.rpm RPM. The Requires link lists
the requirements for the python-ZSI-2.1-a1.el5.noarch.rpm RPM. The Provides link lists what the python-ZSI-2.1-
a1.el5.noarch.rpm RPM provides, i.e. python-ZSI. The Obsoletes link lists what application(s) the python-ZSI-2.1-
a1.el5.noarch.rpm RPM obsoletes. The Conflicts link lists the conflicts for the python-ZSI-2.1-a1.el5.noarch.rpm RPM.
In the Oracle VM Manager Command Line Interface Download section we visted ULN and downloaded the ovmcli and python-ZSI
RPM. In the next section we will walk through the installation and configuration of the Oracle VM Manager Command Line Interface.
The Oracle VM Manager Command Line Interface installation is a quick and simple process that requires two RPMs, a) ovmcli and b)
python-ZSI. As soon as you have downloaded both RPMs and a) placed them on the host or b) mounted a share with the RPMs you can
install the Command Line Interface RPMs by running “rpm –Uvh ovmcli-1.0-1.el5.noarch.rpm python-ZSI-2.1-a1.el5.noarch.rpm” on
the Enterprise Linux host as root.
#
Once you have installed the Oracle VM Manager Command Line Interface you can configure the Oracle VM Manager Command Line
Interface by running "ovm config" as root. The Oracle VM Manager Command Line Interface configuration will ask for the following
five pieces of information as shown in List 10.
The next section introduces how to use the Oracle VM Manager Command Line Interface starting with a single command, then a bulk
command and concluding with batch script examples.
The Oracle VM Manager Command Line Interface can be accessed from the local or remote console from the server hosting the
Oracle VM Manager Command Line Interface. Commands can be executed directly from the command line or from within the Oracle
VM Manager Command Line Interface shell.
The Oracle VM Manager Command Line Interface shell can be accessed by typing “ovm –u username –p your_password shell” as
shown in the following example:
# ovm -u username -p password shell
ovm>
You would substitute username with a valid Oracle VM Manager user name and substitute password with a valid password to
authenticate into the shell.
Once you have successfully authenticated in to the Oracle VM Manager Command Line Interface shell you will be presented with the
“ovm>” prompt. From the “ovm>” prompt you can enter the desired subcommands. From the Oracle VM Manager Command Line
Interface shell, type “ovm help”, to display an abbreviated list of the help messages, as shown below.
ovm> help
Usage: subcommand [suboptions]
Subcommands:
ovm>
Tip: Help messages for subcommands, i.e. "help <subcommand>" will display the help message for that subcommand. The "help all"
command displays a complete list of all the subcommands.
Subcommands can also be run directly from the command line outside of the Oracle VM Manager Command Line Interface shell. The
next example shows how to display the help message from the command line, not from the Oracle VM Manager Command Line
Interface shell.
# ovm -u username -p password help
Usage: ovm [options] subcommand [suboptions]
Subcommands:
Note: We will be adding new example Oracle VM Manager Command Line Interface use cases to this chapter on a regular basis. Stay
tuned!
Bulk commands can be run from the command line or via batch scripts. For example, if you wanted to suspend multiple guests with a
single command i.e. “vm suspend”, this could be accomplished by typing multiple “vm suspend” commands separated by a semi-colon.
Before we execute our fist “vm suspend” bulk command, lets check the status of our virtual machines using the “vm ls” command. The
“vm ls” command can be entered from the Oracle VM Manager Command Line Interface shell or directly from the console.
The next example shows the “vm ls” command entered at the server console which will list the status of all of the virtual machines in
your Oracle VM server farm.
# ovm -u admin -p password vm ls
Name Size(MB) Mem VCPUs Status Server_Pool
node4 13313 256 1 Running SF-HQ
node1 13313 256 1 Running SF-HQ
node3 13313 256 1 Running SF-HQ
Tip: The help message for “vm suspend” can be displayed by typing “ovm -u admin -p password help vm suspend” or from the shell by
typing “help vm suspend”.
Let’s validate that the status of the four virtual machines has changed, from “Running” to “Suspended”, by typing “ovm -u admin -p
password vm ls” from the server console, as shown in the next example.
# ovm -u admin -p password vm ls
Name Size(MB) Mem VCPUs Status Server_Pool
node4 13313 256 1 Suspended SF-HQ
node1 13313 256 1 Suspended SF-HQ
node3 13313 256 1 Suspended SF-HQ
node2 13313 256 1 Suspended SF-HQ
The above “vm ls” example validated that our “vm suspend” bulk command was successfully completed.
Next we will review how to create a vmsuspend batch script. If you would like to test the vmsuspend batch script, you will need to
resume your suspended guest. We will cover how to resume your guests in great detail in a couple of paragraphs. If you need to
resume your guests to test our next example vmsuspend batch script, please run the following bulk command from the server console.
# ovm -u admin -p password vm resume -s serverpool_name -n node1; ovm -u admin -p password vm resume -s serverpool_name -n
node2; ovm -u admin -p password vm resume -s serverpool_name -n node3; ovm -u admin -p password vm resume -s
serverpool_name -n node4
Resuming.
Resuming.
Resuming.
Resuming.
#
The same “vm suspend” bulk command could be run as a batch script. The commands in an Oracle VM Manager Command Line
Interface batch script are executed in sequence, identical to how sqlplus runs a sql script. There is no error handling with Oracle VM
Manager Command Line Interface batch scripts which means when the previous command finishes, regardless of success or failure,
the next command will run.
The first step to create an Oracle VM Manager Command Line Interface batch script is to create a file. Let’s call the example file
vmsuspend. Save the example commands shown below in the vmsuspend file.
Now that we have created the file vmsuspend, we can run the vmsuspend file as a batch script in one of two ways; this assumes that
the vmsuspend file is located in the current working directory, i.e. /home/user/vmsuspend. You can run the batch script from the
server console or from the Oracle VM Manager Command Line Interface shell.
The next example shows how to run our example vmsuspend batch script from the server console.
# ovm shell -s vmsuspend
Login: admin
Password:
Suspending.
Suspending.
Suspending.
Suspending.
#
The above example runs our batch script from the servers console using the “-s” or script option. As shown in the example, it is
necessary to authenticate into the shell to run the vmsuspend batch script. Once the script completes you are dropped back to the
server console.
Our other option to run the vmsuspend batch script is from the Oracle VM Manager Command Line Interface shell. The next example
shows how to run the vmsuspend batch script from the Oracle VM Manager Command Line Interface shell. The example assumes that
the vmsuspend file is located in the current working directory, i.e. /home/user/vmsuspend.
# ovm -u admin -p password shell
ovm> @vmsuspend
Suspending.
Suspending.
Suspending.
Suspending.
ovm>
The above example runs our batch script from the Oracle VM Manager Command Line Interface shell. Once the script completes, you
are dropped back to the Oracle VM Manager Command Line Interface shell prompt.
Let’s validate the status of the four virtual machines by typing “vm ls” from the Oracle VM Manager Command Line Interface shell as
shown on the next example.
# ovm> vm ls
Name Size(MB) Mem VCPUs Status Server_Pool
node4 13313 256 1 Suspended SF-HQ
node1 13313 256 1 Suspended SF-HQ
node3 13313 256 1 Suspended SF-HQ
node2 13313 256 1 Suspended SF-HQ
Typing “vm ls” from the Oracle VM Manager Command Line Interface shell validated that our previous vmsuspend batch script did
successfully run and suspend all four of the guests. You can also list the status of your virtual machines from the server console, as
shown in the next example.
# ovm -u admin -p password vm ls
Name Size(MB) Mem VCPUs Status Server_Pool
node4 13313 256 1 Suspended SF-HQ
node1 13313 256 1 Suspended SF-HQ
node3 13313 256 1 Suspended SF-HQ
node2 13313 256 1 Suspended SF-HQ
Now that we have reviewed running a “vm suspend” bulk command and a vmsuspend batch script along with “vm ls”, let’s examine
how to resume our guests. First we will review a “vm resume” bulk command, followed with a vmresume batch script.
Next, we will resume four “Suspended” guests named node1, node2, node3, and node4 with a single bulk command. Enter the bulk
command from the command line, not the Oracle VM Manager Command Line Interface shell, to resume all four guests as shown in
the next example.
# ovm -u admin -p password vm resume -s serverpool_name -n node1; ovm -u admin -p password vm resume -s serverpool_name -n
node2; ovm -u admin -p password vm resume -s serverpool_name -n node3; ovm -u admin -p password vm resume -s
serverpool_name -n node4
Resuming.
Resuming.
Resuming.
Resuming.
#
You can validate the status of the four virtual machines by typing “ovm -u admin -p password vm ls” from the server console or “vm ls”
from the Oracle VM Manager Command Line Interface shell.
The same “vm resume” bulk command could be run as a batch script. As discussed in the “vm suspend” section the commands in an
Oracle VM Manager Command Line Interface batch script are executed in sequence, identical to how sqlplus runs a sql script. There
is no error handling with Oracle VM Manager Command Line Interface batch scripts which means when the previous command
finishes, regardless of success or fail, the next command will run.
The first step to create our example “vm resume” Oracle VM Manager Command Line Interface batch script, is to create a file. Let’s
call the example file vmresume. Save the example commands shown below in the vmsuspend file.
Now that we have created the file vmresume, we can run the vmreseume file as a batch script in one of two ways; this assumes that
the vmreseume file is located in the current working directory, i.e. /home/user/vmresume. You can run the batch script from the server
console or from the Oracle VM Manager Command Line Interface shell.
The next example shows how to run our example vmresume batch script from the server console.
# ovm shell -s vmresume
Login: admin
Password:
Resuming.
Resuming.
Resuming.
Resuming.
#
The above example runs our batch script from the servers console using the “-s” or script option. As shown in the example it is
necessary to authenticate into the shell to run the vmsuspend batch script. Once the script completes, you are dropped back to the
server console.
Our other option to run the vmresume batch script is from the Oracle VM Manager Command Line Interface shell. The next example
shows how to run the vmresume batch script from the Oracle VM Manager Command Line Interface shell. The example assumes that
the vmresume file is located in the current working directory, i.e. /home/user/vmresume.
# ovm -u admin -p password shell
ovm> @vmresume
Resuming.
Resuming.
Resuming.
Resuming.
ovm>
The above example runs our batch script from the Oracle VM Manager Command Line Interface shell. Once the script completes, you
are dropped back to the Oracle VM Manager Command Line Interface shell prompt.
You can validate the status of the four virtual machines by typing “ovm -u admin -p password vm ls” from the console or “vm ls” from
the Oracle VM Manager Command Line Interface shell.
We have just completed our review of the “vm suspend” and “vm resume” bulk command and batch scripting. The next example
expands from our previous “vm suspend” and “vm resume” with a detailed use case called Guest Backup. The Guest Backup use case
will use a batch script that suspends four guests, pauses for 120 seconds and then resumes the guests to accommodate an Oracle VM
repository scheduled backup job.
Guest Backup
Our first example use case “Guest Backup”, builds upon what we learned in the previous section with regards to the vm suspend and
vm resume examples. The use case shows us how to create a batch script to suspend four guests, pause for 120 seconds and then
resume the guests to accommodate a scheduled snapshots/cloning of an Oracle VM extended repository.
There are numerous strategies to back up Oracle VM guests. For example, you can use the same agent based backup solution you
have always used for your physical machines or you could leverage the snapshots/cloning functionality from your storage solution.
Our goal, with the Guest Backup use case, is to provide an Oracle VM Manager Command Line Interface solution to work with the
snapshots/cloning functionality from your existing storage.
To capture a clean snapshot or backup of a running guest, the guest should be in the suspended state when the snapshot or backup
job is executed. When a guest is suspended, the status of the guest operating system is written to disk and removed from system
memory. Conversely, when a guest operating system is paused, the system state continues to reside in memory. For the Guest Backup
use case we will use the “vm suspend” and “vm resume” commands to ensure that the status of the guest operating system is written
to disk and removed from system memory for the duration of the snapshot or backup job.
Prerequisites:
List 11 shows the work flow to execute the Guest Backup use case.
1- The first step is to create an Oracle VM Manager Command Line Interface batch script on the machine hosting the Oracle VM
Manager Command Line Interface. Let’s create a file named vmbackup. Save the example commands shown below in the vmbackup
file.
2- Next we will test the example vmbackup batch script from the server console, as shown in the example.
# ovm -u admin -p password shell -s vmbackup
Suspending.
Suspending.
Suspending.
Suspending.
Sleeping for 120 seconds
Resuming.
Resuming.
Resuming.
Resuming.
#
3- The final step is to automate the vmbackup batch script to run at 3:00 AM every day with cron, as shown in the example.
# crontab –e
* 3 * * * ovm -u admin -p password shell -s vmbackup
:wq!
#
We have just completed our first use case that showed us how to create a batch script to suspend four guests, pause for 120 seconds,
and then resume the guests to accommodate a scheduled snapshot or backup job of an Oracle VM extended repository.
You can program Oracle VM Manager Command Line Interface commands to determine whether a command is successfully executed
or not. You’re also able to get the return result of commands in a programming friendly way.
The following example script will a) Create a serverpool b) Register all the discoverable ISOs c) Create a hvm guest by one of the ISOs
and d) Check the status of the guest created, if the status is "Running", then power off the guest.
from ovmcli.Ovm import Ovm
from ovmcli.errorcode import *
import time
serverpool_name = "ovstest19"
vm_name = "hvmbyiso1"
server_ip = "ovstest19.cn.oracle.com"
# Delete a serverpool
if OVM_OK == _("svrp del -s %s --force" % serverpool_name):
print "OK serverpool_del"
# Create a serverpool
cmd = 'svrp new -H %s --serverpool_name=%s -a -A oracle -U root -P oracle -L BJ ' % (server_ip, serverpool_name)
if OVM_OK == _(cmd):
print "OK serverpool_create"
iso = isos[0][1]
# Create a VM
cmd = 'vm new --method=iso -x -s %s -n %s -c 1 -i %s -o Other -y 512 -d 1024' % (serverpool_name, vm_name, iso)
if OVM_OK == _(cmd):
print "OK vm new"
while 1:
cmd = "vm status -s %s -n %s" % (serverpool_name, vm_name)
status = _(cmd)
if type(status) == type([]):
vm_status = status[0]
if vm_status != 'Running':
print "vm_status:" + vm_status
print "sleep 10s"
time.sleep(10)
else:
print vm_status
cmd = 'vm poweroff -s %s -n %s' % (serverpool_name, vm_name)
if OVM_OK == _(cmd):
print "OK poweroff"
break
In this chapter we will review the steps to upgrade all of the Oracle VM components from version 2.1.5 to version 2.2. The chapter
starts with an introduction to the upgrade process for Oracle VM Manager and Oracle VM server. Next we review the upgrade options
and upgrade prerequisites for both Oracle VM Manager and Oracle VM server. Next we will review the Unbreakable Linux Network to
support the up2date upgrade option. The chapter concludes with a review of the steps to upgrade Oracle VM Manager and Oracle VM
server from version 2.1.5 to version 2.2.
Table of Contents
Oracle VM 2.1.5 to 2.2 Upgrade Processes
Oracle VM Manager Upgrade Process
Oracle VM Server Upgrade Options
The Unbreakable Linux Network
Oracle VM Manager Database Backup
Oracle VM Manager Database Restore
Backup the OVS Repository
Download the Oracle VM Manager Media
Unzip and Mount the Oracle VM 2.2 ISO
Upgrade Oracle VM Manager
Oracle VM Server Upgrade using up2date
...Oracle VM Server Upgrade Prerequisites
...Oracle VM Server Upgrade Commands
...Reboot the Oracle VM Pool Master Server
...Reboot the None Master Oracle VM servers
...Enter the Server Pool Virtual IP using Oracle VM Manager
Manager is upgraded by using the Oracle VM Manager 2.2 ISO file which is available from the eDelivery portal. Oracle VM servers
can be upgraded using either a) the bootable Oracle VM Server 2.2 ISO image or b) with up2date and the Unbreakable Linux Network
or c) using up2date or yum with a local yum repository.
Note: Please note that a rolling upgrade of the Oracle VM servers from version 2.1 to version 2.2 is not supported. You will need to
backup and then power off all your virtual machines before you upgrade the Oracle VM servers. A rolling upgrade is not supported,
due in part, to an upgrade of the OCFS2 file system.
List 1 shows the correct order to backup and upgrade all of the Oracle VM components from version 2.1.5 to version 2.2.
The Oracle VM Manager update process will require you to select an installation option of either install, uninstall, or upgrade, as well
as entering the passwords for the existing Oracle VM Manager OVS database account and the oc4j admin account. The Oracle VM
Manager OVS database account and the oc4j admin account passwords are selected during the Oracle VM Manager installation
process. The account passwords for the Oracle VM Manager OVS database account and the oc4jadmin account can be managed from
their respected web portals.
The OVS account can be maintained from the Oracle Database Express Edition portal which is a part of the Oracle VM Manager
install. The Oracle Database Express Edition portal can be accessed from the Oracle VM manager server locally by entering
http://127.0.0.1:8080/apex or remotely by entering the ip address or the FQDN followed by :8080/apex, i.e.
http://OracleVM_Manager_fqdn:8080/apex in a web browser.
Figure 1 shows the Oracle Database Express Edition portal login page.
The Application Server Control portal is also part of the Oracle VM Manager install. The oc4j admin account can be maintained from
the Application Server Control portal. The Application Server Control portal can only be accessed locally from the Oracle VM server
console by entering http://127.0.0.1:8888/em in a local web browser.
The difference between the two Oracle VM server upgrade options is a) the ability to perform incremental updates or b) platform
upgrades. Using the up2date command with the Unbreakable Linux Network allows Oracle VM servers to receive incremental
updates, patches, security fixes as well as upgrades. Using the bootable media requires the machine to be restarted and to select the
update option from the boot prompt. Selecting the update option from the boot prompt will update the Oracle VM server to the
version of the bootable media, e.g. from 2.1.5 to 2.2.
Figure 4 shows the System to Upgrade boot prompt. From the System to Upgrade boot prompt administrators can select to
Reinstall System or Oracle VM server 2.x to upgrade the system.
When the up2date command is executed from an Oracle VM server’s dom0 console, up2date connects to the ULN repository and
downloads the requested packages in RPM format. The up2date command communicates over the internet to “linux-
update.oracle.com” on port 443. Up2date then installs the packages on the registered Oracle VM server.
Please consult up2date’s man page by executing “man up2date” from the Oracle VM server’s dom0 console as root for a
comprehensive list of command augments.
The Unbreakable Linux Network and My Oracle Support (formally Metalink) are two separate systems, accessed by different URLs
and user name and passwords. ULN is used to access Oracle VM and Linux patches, updates, and fixes, and My Oracle Support is
used to manage SRs.
This section will review the steps to upgrade Oracle VM Manager. We start with a review of the Oracle VM Manager database backup
and restore procedure followed by the 2.1.5 to 2.2 Oracle VM Manager upgrade.
The following example shows how to execute the “/opt/ovs-manager-2.1/bin/backup.sh” script from the Oracle VM Manager server
console as root user.
# sh /opt/ovs-manager-2.1/bin/backup.sh
Next to backup the Oracle VM Manager database select the Backup Oracle VM Manager option (number 1) from the backup
prompt. The next example shows the backup selection prompt.
sh /opt/ovs-manager-2.1/bin/backup.sh
Welcome to Oracle VM Manager
Completed backup:
Completed backup:
Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
SQL>
SQL> Disconnected from Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses AL32UTF8 character set (possible charset conversion)
. exporting pre-schema procedural objects and actions
. exporting foreign function library names for user OVS
. exporting PUBLIC type synonyms
. exporting private type synonyms
. exporting object type definitions for user OVS
About to export OVS's objects ...
. exporting database links
. exporting sequence numbers
. exporting cluster definitions
. about to export OVS's tables via Conventional Path ...
. . exporting table OVS_AGENT 2 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_ALERT 11 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_CATEGORY 1 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_CDROM 5 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_CDROM_RESOURCE 0 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_GROUP 4 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_HD_TEMP
. . exporting table OVS_IMG_OS 0 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_IMG_TEMP
. . exporting table OVS_LOCK 19 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_MAP 35 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_NIC_TEMP
. . exporting table OVS_OS_RESOURCE 17 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_PARTNER 0 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_PREFERRED_SERVER 0 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_PRIVILEGE 4 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_PRIVILEGE_ROLE 5 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_RESOURCE 4 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OVS_ROLE 3 rows exported
Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
SQL>
PL/SQL procedure successfully completed.
SQL> Disconnected from Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Done
Please check the log file /tmp/ovs.log
#
We just executed a successful Oracle VM Manager database backup.
The following example shows how to execute the “/opt/ovs-manager-2.1/bin/backup.sh” script from the Oracle VM Manager server
console as root user.
# sh /opt/ovs-manager-2.1/bin/backup.sh
Next, to backup the Oracle VM Manager database, select the Restore Oracle VM Manager option (number 2) from the backup
prompt. The next example shows the backup selection prompt.
sh /opt/ovs-manager-2.1/bin/backup.sh
Welcome to Oracle VM Manager
Completed backup:
The next example reviews an Oracle VM Manager database restore procedure. Access the Oracle VM Manager server console as root
and type "sh /opt/ovs-manager-2.1/bin/backup.sh" as shown in the following example.
# sh /opt/ovs-manager-2.1/bin/backup.sh
Welcome to Oracle VM Manager
Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
. . importing table "OVS_AGENT" 2 rows imported
. . importing table "OVS_ALERT" 11 rows imported
. . importing table "OVS_CATEGORY" 1 rows imported
. . importing table "OVS_CDROM" 5 rows imported
. . importing table "OVS_CDROM_RESOURCE" 0 rows imported
From the Registration page enter the following required information then click the Continue button to proceed:
Full Name (FIRST LAST)
Company Name
Email address
Select your country from the drop down list
Select the check box to agree to the Agreement Terms
Select the check box to accept the Export Restrictions
From the Media Pack Search page select Oracle VM from the Select a Product Pack drop down box, then select the desired
platform either x86 or x86-64 from the Platform drop down box. Click the Go button to proceed.
From the Media Pack Search results page select the Oracle VM 2.2 Media Pack radio button. Click the Oracle VM 2.2 Media
Pack link to proceed.
From the Oracle VM 2.2 Media Pack page click the Oracle VM Manager 2.2 Download button to download the Oracle VM
Manager 2.2 media.
We have just completed the steps to download the Oracle VM 2.2 Media Pack from the Oracle eDelivery portal.
Before you proceed with the Oracle VM Manager 2.2 upgrade you will need the OVS password and the oc4jadmin password, which
Access the Oracle VM server console as root and cd in to the directory where you mounted the ISO file. The following example shows
how to execute the runInstaller.sh from the Oracle VM Manager server console as root user.
# sh runInstaller.sh
Select the Upgrade Oracle VM Manager option (number 3) from the install prompt. The next example shows the installation
selection prompt.
Welcome to Oracle VM Manager 2.2
Backup the database before upgrade is highly recommended, to backup the database now, choose 'N' and run:
/opt/ovs-manager-2.1/bin/backup.sh
Are you sure you want to upgrade Oracle VM Manager from version 2.1.5 to 2.2 ? [y|N] y
Please enter the password for database account 'OVS':
It is essential to upgrade and boot the Oracle VM servers in the following order; first upgrade the Oracle VM virtual machine and
utlilty servers, followed by the Oracle VM pool master server. After all of the servers are servers upgraded, boot the Oracle VM pool
master server followed by the none pool master servers.
Note: You can determine the Oracle VM server roles i.e. virtual machine, utlilty and master servers by accessing Oracle VM Manager
and displaying the Servers tab as shown in Figure 11.
List 1
1- Verify that the hostname in /etc/hosts is associated with the public IP address, not 127.0.0.1.
2- Verify that all of the Oracle VM servers have the proper entries in /etc/resolv.conf or if DNS is not used, make sure the correct
setting are in /etc/hosts. Please note that all the servers in the same pool must have the consistent name resolution, either by DNS or
by file (/etc/hosts).
The upgrade procees for all of the Oracle VM 2.1.5 pool memeber servers i.e. the virtual machine servers, the utlilty servers and the
pool master pool server is idential. We will first upgrade all of the none pool master servers, followed by the pool master pool server,
using the following commands.
Note: Before we upgrade any of the Oracle VM servers, ensure that all of the virtaul machines are powered off and backed up.
The next example shows each of the three steps from a sucessful Oracle VM server upgrade.
Installing...
1:ovm22upgrade ########################################### [100%]
Please run the following command to continue the upgrade:
/usr/local/sbin/ovm22upgrade.py
[root@ovs3 ~]# /usr/local/sbin/ovm22upgrade.py
Please stop all running Virtual Machine Guests before proceeding.
Next run python script as suggested by the install process as shown in the next example.
# /usr/local/sbin/ovm22upgrade.py
Running phase 1 of upgrade... done
Installing new ovs-release package for OVM 2.2
Installing...
1:ovs-release warning: /etc/issue created as /etc/issue.rpmnew
########################################### [100%]
Running phase 2 of upgrade... done
Updating fstab and grub.conf with disk uuid information
Files /etc/fstab and /boot/grub/grub.conf updated to use UUID instead of LABEL.
Installing...
1:libgcc ########################################### [100%]
2:tzdata ########################################### [100%]
3:glibc-common ########################################### [100%]
4:glibc ########################################### [100%]
5:bash ########################################### [100%]
6:chkconfig ########################################### [100%]
7:popt ########################################### [100%]
8:audit-libs ########################################### [100%]
9:bzip2-libs ########################################### [100%]
10:libxml2 ########################################### [100%]
11:libstdc++ ########################################### [100%]
12:tcp_wrappers ########################################### [100%]
13:elfutils-libelf ########################################### [100%]
14:perl ########################################### [100%]
15:libX11 ########################################### [100%]
16:libacl ########################################### [100%]
17:binutils ########################################### [100%]
18:nspr ########################################### [100%]
19:nss ########################################### [100%]
20:procps ########################################### [100%]
21:iptables ########################################### [100%]
22:libgcrypt ########################################### [100%]
23:lm_sensors ########################################### [100%]
24:diffutils ########################################### [100%]
25:gzip ########################################### [100%]
26:make ########################################### [100%]
27:iptables-ipv6 ########################################### [100%]
28:iputils ########################################### [100%]
29:iproute ########################################### [100%]
30:dosfstools ########################################### [100%]
31:ethtool ########################################### [100%]
32:file ########################################### [100%]
33:mkisofs ########################################### [100%]
34:tftp ########################################### [100%]
35:setup ########################################### [100%]
36:filesystem ########################################### [100%]
37:enterprise-linux-ovs ########################################### [100%]
38:cracklib-dicts ########################################### [100%]
39:booty ########################################### [100%]
40:gnutls ########################################### [100%]
41:libXxf86vm ########################################### [100%]
42:libtiff ########################################### [100%]
43:pcre ########################################### [100%]
44:ed ########################################### [100%]
45:m4 ########################################### [100%]
46:patch ########################################### [100%]
47:libdaemon ########################################### [100%]
48:libdrm ########################################### [100%]
49:nash ########################################### [100%]
50:grub ########################################### [100%]
51:crash ########################################### [100%]
52:oprofile ########################################### [100%]
53:acl ########################################### [100%]
54:bzip2 ########################################### [100%]
55:anacron ########################################### [100%]
56:ypbind ########################################### [100%]
57:mdadm ########################################### [100%]
58:ovs-release warning: /etc/issue created as /etc/issue.rpmnew
########################################### [100%]
59:procmail ########################################### [100%]
60:ftp ########################################### [100%]
61:rdate ########################################### [100%]
62:rsh ########################################### [100%]
63:traceroute ########################################### [100%]
64:zip ########################################### [100%]
#
Reboot the Oracle VM Pool Master Server
Next we will reboot the Oracle VM pool master server as shown in the next example.
# reboot
Access Oracle VM Manager, click the Server Pools tab then click the Edit button to access the Edit Server Pool page. From the
Edit Server Pool page, enter the server pool virtual IP in the Server Pool Virtual IP text box then click OK as shown in Figure 12.
This chapter outlines how to configure an Oracle VM 2.2 pool with Fibre Channel and iSCSI SANs and NFS back-end storage. The
chapter also covers guest front-end storage options and configurations. The chapter starts with an overview of the Oracle VM storage
stack, followed by an introduction to Oracle VM back-end storage options, configurations and considerations. Next, we will summarize
storage administration with Oracle VM 2.2 followed by example root and extended storage repository (SR) configurations using Fibre
Channel and iSCSI SANs and NFS storage arrays. The chapter concludes with a review Oracle VM guest front-end storage options
and configurations.
Table of Contents
The Oracle VM Storage Stack
OCFS2 Cluster File System
OCFS2 User-Space Management Utilities and Commands
Oracle VM Storage Repositories
Storage Administration
The Storage Array Layer
…Swap
…Backup and Restoration
…SAN and iSCSI Multi-pathing
…Sparse Files and Unwritten Extents
The Server Layer
SAN Storage Repository Configuration
…SAN Back-end Storage Prerequisites
…SAN Oracle VM Server Prerequisites
…Adding an Extended SAN Storage Repository
iSCSI Storage Repository Configuration
…iSCSI Back-end Storage Prerequisites
…iSCSI Oracle VM Server Prerequisites
…Adding an Extended iSCSI Storage Repository
NFS Storage Repository Configuration
…NFS Back-end Storage Prerequisites
…NFS Oracle VM Server Prerequisites
…Adding an Extended NFS Storage Repository
Oracle VM Guest Front-end Storage
…File-backed block device
…Physical backed block device
Appendix A Example multipath.conf Files
Note: Oracle VM supports both local and shared back-end storage. Local storage refers to a file system that can only be accessed by a
single Oracle VM server. This chapter covers shared back-end storage supporting a clustered multi server pool environment, not local
storage.
Figure 1 shows a high-level overview of the three layers of the storage stack with a virtual machine running on an Oracle VM server,
connected to a storage array. At the bottom of the stack is the storage array. The storage array layer is where the physical disks are
managed and presented to the Oracle VM pool members as logical disks. Above the storage array is the server layer. The server layer
is where the storage configurations and the OCSF2 or NFS virtual machine file system (the cluster stack) are managed. At the top of
the stack is the virtual machine layer. The virtual machine layer is where virtual machine storage is presented to the virtual machine
by the Oracle VM server.
When designing an Oracle VM virtual environment, one of the most important considerations is the back-end storage. There are many
back-end storage options ranging from local storage, Fibre Channel and iSCSI SANs and NFS. Each back-end storage option has its
own capacity, performance and availability features. The back-end storage is where you store and run the virtual machines. Oracle VM
supports the Oracle Cluster File System v2 (OCSF2) and NFS on the back-end storage to store and run the virtual machines. The
OCFS2 cluster file system and NFS both have their own unique management, performance and availability features.
The next section will review the OCSF2 cluster file system, NFS and the cluster stack. The goal of the OCSF2 section is to provide an
overview of the architecture,configurations, dependencies and features of the virtual machine file system, at the server layer of the
storage stack. Understanding the architecture, configurations, dependencies and features at the server layer will allow you to design
a manageable back-end storage solution for Oracle VM.
Note: For the remainder of this chapter, the terms “pool” and “cluster” should be considered to be interchangeable.
Note: OCFS2 is not integrated or supported with any volume manager (LVM) to manage the back-end block storage. Fibre Channel
and iSCSI partitions must be provisioned at static sizes, i.e. partition sizes can not change once a partition is formatted with OCFS2.
Many customers try to use LVM to manage the back-end block storage for OCFS2. LVM is not cluster aware, so changes made to the
back-end block storage by LVM will not be propagated to the OCFS2 file system. The Oracle VM pool members would continue to
write to the old volume layout, and corruption will occur.
OCFS2 has two components, a kernel component and a user-space component. The kernel component consists of the file system and
the cluster stack. The user-space component consists of the utilities to manage the file system and the cluster stack.
A slightly modified version of OCSF2 (o2dlm) is bundled with Oracle VM. The OCFS2 file system and cluster stack are installed and
configured as part of an Oracle VM server installation. The o2cb service manages the cluster stack and the ocfs2 service manages the
OCSF2 file system. The o2cb cluster service is a set of modules and in-memory file systems that manage the ocfs2 file system service.
Once a server pool is created using Oracle VM Manager, two cluster configuration files are shared across the server pool that
maintain the cluster layout and cluster timeouts configurations. The /etc/ocfs2/cluster.conf file maintains the cluster layout and the
/etc/sysconfig/o2cb file maintains the cluster timeouts. Both configuration files are read by the user-space utility configfs. configfs
communicates the list of nodes in the /etc/ocfs2/cluster.conf file to the in-kernel node manager, along with the resource used for the
heartbeat to the in-kernel heartbeat thread.
The ovs-agent, which is also installed and configured by default, is responsible for propagating the /etc/ocfs2/cluster.conf file to all of
the pool members. The ovs-agent is an Oracle VM server service that is used for centralized pool management, orchestrated by Oracle
VM Manager or the Oracle VM Management Pack. Each time an ovs-agent starts and stops, it updates the pool status, which is
managed by the master pool agent. The master pool agent updates the pool membership status and then propagates an up to date
/etc/ocfs2/cluster.conf file to all of the pool’s ovs-agents.
An Oracle VM server must be online to be in an OCFS2 cluster. Once the cluster is on-line, each pool member starts a process, o2net.
The o2net process creates TCP/IP intra-cluster node communication channels on port 7777 and sends regular keepalive packages to
each node in the cluster to validate if the nodes are alive. The intra-cluster node communication uses the Oracle VM management
network. The Oracle VM management network is selected during the Oracle VM server installation. If a pool member falls of the
network and the keepalive connection becomes silent, the server will self-fence. Fencing forcefully removes dead servers from a pool
to ensure that active servers are not obstructed from accessing fenced servers cluster resources.
Along with the keepalive packages that check for node connectivity, the cluster stack also employs a disk heartbeat check. o2hb is the
process that is responsible for the disk heartbeat component of cluster stack that actively monitors the status of all pool members.
The heartbeat system uses a file on the OCSF2 file system, that each pool member periodically writes a block to, along with a time
stamp. The time stamps are read by each pool member and are used to check if a pool member is alive or dead. If a pool member’s
block stops getting updated, the server is considered dead. When a server dies, the server gets fenced. Fencing forcefully removes
dead pool member from the pool to ensure that active pool members are not obstructed from accessing fenced pool members
resources.
Another important OCSF2 component is the distributed lock manager. The distributed lock manager (o2dlm) tracks all the locks in the
cluster, including lock ownership and lock status. Cluster locking is added at the lowest level, in the xend code. The locking method is
defined in the xend-config.sxp file, (xend-domains-lock-path /opt/ovs-agent-2.3/utils/dlm.py) All access methods must take a lock, for .
.example, Oracle VM Manager, xm and the XenAPIdlm is also used for Oracle VM HA, which relies on the cluster stack to validate
pool member status for HA purposes. For example, as pool members boot, reboot and restart, pool membership status will change
across the pool.
There is also a virtual filesystem interface (dlmfs) that allows user space processes to access the in-kernel distributed lock manager.
dlmfs communicates locking and unlocking for pool wide locks on resources to the in-kernel distributed lock manager. The in-kernel
distributed lock manager keeps track of all locks and their owners and status. The o2cb init script mounts the virtual filesystem under
/dlm on each Oracle VM server.
To provide OCFS2 functionality with an NFS storage repository, Oracle VM uses a hidden OCFS2 file-backed block device that
facilitates the use of the OCFS2 distributed lock manager (DLM) with NFS. The ability to use the OCFS2 distributed lock manager
with OCFS2 and NFS allows Oracle VM to monitor both OCFS2 and NFS storage repositories with the same interface.
Now that we have reviewed the components of the OCFS2 file system and cluster stack, let’s see how OCFS2 works together with
Oracle VM.
When an Oracle VM 2.2 server boots, the o2cb and ocfs2 services are started which bring up the OCFS2 clusterstack. Once the
OCFS2 clusterstack is online, the ovs-agent informs the pool master that the node is online. Next, the pool master updates the
nodemap file with the node’s online status. Next, the ovs-agent queries the pool master and pulls down an up-to-date /etc/ocfs2
/cluster.conf configuration. Next, the ovs-agent mounts the root and any extended repositories and checks that /OVS is symlinked
correctly.
When a pool member stops, starts or dies, the pool master attempts to take an EX lock for the dead pool member’s resources. The
master agent then updates the nodemap file to monitor the aliveness of all active pool members. Whenever the pool membership
status changes, the mater agent will recreate the cluster.conf file and propagate the changes to all of the pool members.
The next section will review the OCFS2 user-space management utilities and commands.
Table 2 lists the OCFS2 file system utilities that are available in dom0.
OCFS2 Description
Utility
/etc/init.d/o2cb Onlines the cluster named ocfs2. The default name for
online ocfs2 Oracle VM OCFS2 cluster is ocfs2. The cluster name is
defined in the cluster.conf file. At least one pool
member must be active for the cluster to be online.
/etc/init.d/o2cb Offlines the cluster named ocfs2. The default name for
offline ocfs2 Oracle VM OCFS2 cluster is ocfs2. The cluster name is
defined in the cluster.conf file.
An Oracle VM storage repository can consist of “one” large repository, commonly referred to as “a root repository” or a root
repository with multiple extended sub repositories. Oracle VM 2.x does not have volume management, so adding storage to a root
repository volume will not grow the root repository. The only option to grow an Oracle VM 2.x storage repository is to add sub
repositories beneath the root repository. A best practice is to provision one or more larger repositories to avoid the management
overhead of numerous sub repositories.
Tip: In general, you should consider provisioning at least 30% to 50% more storage for your Oracle VM storage repositories than the
expected size.
Configuring an Oracle VM pool’s storage repository is a multi step process. Once the back-end storage is provisioned, the pool master
must be connected to the storage from dom0. Next, all of the Oracle VM servers that will be added to the pool should be connected to
the storage, again from dom0. Finally, all of the Oracle VM servers should be added to the pool using Oracle VM Manager or the
Oracle VM Management Pack. Once the pool has multiple servers, virtual machines can start on and migrate to any server in the pool.
To add storage to an Oracle VM storage repository, the first step is to provision the storage. Next, connect the pool master, followed
by each pool member to the storage using the /opt/ovs-agent-2.3/utils/repos.py script with the -n (new) followed by the -i (initialize,
aka mount) switches, to add and then mount the sub storage repository. Finally the new mount point in /var/ovs/mount/UUID needs to
be linked to /OVS/UUID, by typing “ln -nsf /var/ovs/mount/<UUID>/OVS”, again from dom0. The end result is a root repository with an
“extended” sub repository mounted under /var/ovs/mount/UUID, linked to /OVS/UUID. The Oracle VM agents will automatically place
resources such as virtual machines, templates, or ISO files on the root or sub repository with available space.
Oracle VM 2.2 uses the /opt/ovs-agent-2.3/utils/repos.py script to configure storage repositories and a local Berkley DB to save the
storage repository configurations. The Oracle VM agent is also responsible for mounting and linking storage repositories when an
Oracle VM server boots or restarts. For example, you will not see entries in /etc/fstab for any Oracle VM storage repositories. Oracle
VM storage repository configurations are saved in a local Berkley DB or in a shared Berkley DB in the root storage repository.
Oracle VM root and extended storage repositories all share the same directory structure. Oracle VM’s OCFS2 file system,
clusterstack, repos.py script, Oracle VM agent, Oracle VM Manager as well as the Oracle VM Management Pack are wired to use the
default storage repository directory structure.
The following example shows the Oracle VM storage repository directory structure including a brief explanation of each directory.
The next example shows the storage repository directory structure of an extended storage repository.
Storage Administration
Now that we know all about the OCFS2 file system, clusterstack and the storage repository directory structure, we will to turn our
attention to Oracle VM storage administration. As discussed in the Oracle VM Storage Stacksection, there are three distinct layers of
an Oracle VM storage solution. The first layer is the storage array, which is referred to as back-end storage. The second layer is the
server layer, which consists of the Oracle VM server storage configurations and the virtual machine file system. The third layer is the
guest front-end storage, which consists of multiple guest storage and driver options.
The following sections will review storage administration at each layer of the storage stack.
Storage array configurations and storage best practices are vendor specific and out of the scope of this document. Please consult your
storage administrators and storage vendor and application owners to help develop a storage solution to meet your business
requirements. This section will review Oracle VM specific storage array considerations.
Administrators do not always have the luxury to design the best storage solution for their environment. Ultimately management
makes the decisions and administrators make the best out of what equipment they get. Ideally, we would like to design a storage
solution that allowed us to provision tiered storage for different workloads. Each workload, for example, RAC, Fusion Middleware, and
E-Business Suite has different requirements, so depending on the workload, back-end disk configurations and guest front-end disk
configurations will affect the performance of the workloads. The only way to validate the best configuration for a workload is to
benchmark the workload using a variety of back-end and front-end configurations. Once you know which configurations provide the
best performance for a given workload then it is time to provision and configure the back-end and front-end storage accordingly.
Swap
Swap is another storage array layer component that requires careful consideration. The best practice for guests is to add RAM to a
guest to tune the database or application workload to minimize swapping altogether. If some swapping is necessary, placing the
guests swap files on the Oracle VM server’s local disk will offer better peformnace than hosting a guests swap file on a SAN. Paging
over a SAN in parallel with swap traffic from other guests can easily contribute to an I/O bottleneck. Swap traffic from other guests is
especially bad when a common set of physical LUNs is provisioned as swap space for many guests. If several guests load up and start
swapping heavily, all the guests on that storage will grind to a halt waiting for the saturated LUNs to respond.
Please note that placing a guests swap file on an Oracle VM server’s local disk will eliminate the ability to use Live Migration.
The advantage of using sparse files is that storage is allocated only when needed which reduces the time it takes to create sparse files
along with saving disk space.
The disadvantage of using sparse files is that the file system free space reports may be misleading. For example, since storage is
allocated only when needed, the file system free space reports may not be accurate since large portions of unused disk, i.e. the sparse
zero sections have not yet been written to disk.
Tip: Some application do not support copying sparse files and may copy the entire uncompressed size of the file including the sparse
sections.
Next, we walk through example root and extended storage repository (SR) configurations using Fibre Channel and iSCSI SANs and
NFS storage arrays.
Tip: An HA enabled pool will automatically add (repos.py -n and -r) and mount (repos.py -i) root and extended storage repositories for
all pool members.
OCFS2 is not integrated or supported with any volume manager (LVM) to manage the back-end block storage. Fibre Channel and
iSCSI partitions must be provisioned at static sizes, i.e. partition sizes can not change once a partition is formatted with OCFS2. The
challenge with supporting volume management with OCFS2 is that the volume manager needs to be cluster-aware and integrated
with the OCFS2 cluster stack. To date there are no supported volume management solutions for OCFS2. For example, many
customers use LVM to manage the back-end block storage for OCFS2. LVM is not cluster aware, so changes made to the back-end
block storage by LVM will not be propagated to the OCFS2 file system. The Oracle VM pool members would continue to write to the
old volume layout, and corruption will occur.
SAN connectivity is configured using fiber channel HBAs with dm-multipath in dom0 to allow the Oracle VM server to access a Logical
Unit (LU) using multiple paths. Oracle VM also supports boot from SAN. The "linux mpath" install option is used to boot an Oracle VM
server from a SAN. By using the "linux mpath" install option, the installer will see the multipath devices and allow you to create the
boot/root partitions, along with the master boot record (MBR) on the SAN. Please note that this document will not cover boot from
SAN.
To connect an Oracle VM server to a Fibre Channel storage array, each Oracle VM server’s HBAs must be zoned and masked to the
storage. Once the HBAs are zoned and masked, the next step is to configure dm-multipath to detect the LUNs which are recognized as
multipath devices. Once the multipath devices are detected, we need to format the devices on the “pool master” using the mkfs.ocfs2
utility. Next, use the repos.py script to configure the storage repository. Finally, create a pool using Oracle VM Manager or the Oracle
VM Management Pack by selecting the pool master server. Once the pool is created add all the other Oracle VM servers to the pool.
2. Select an Oracle VM server that will be used as the Oracle VM pool master. After the Oracle VM pool master and all the other
Oracle VM pool members meet the prerequisites outlined in the following steps, access Oracle VM Manager and create an HA
enabled pool using the Oracle VM pool master server.
Note: An HA enabled pool automatically mounts and links root and extended storage repositories for each Oracle VM pool member
that is added to a pool.
3. Create a multipath.conf file for the storage array. Please refer to Appendix A for examples multipath.conf files.
4. Ensure that all the Oracle VM servers’ clocks are synchronized using NTP.
First, open the “/etc/ntp.conf” file by typing “vi /etc/ntp.conf” and validate that at least two available NTP servers entries are listed.
The next example shows two bold NTP server entries in an ntp.conf file.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server myntp1.com
server myntp2.com
Ping each NTP server listed in the ntp.conf file from each Oracle VM server to ensure network connectivity.
Next, type "ntpstat" on each Oracle VM server to validate the NTP configuration. The next example shows the output from typing the
ntpstat command on an Oracle VM server that has its time synchronized to an NTP server with the IP address of 192.168.4.251.
# ntpstat
5. All Oracle VM servers have consistent name resolution using DNS with both forward and reverse lookups.
First, open the “/etc/resolv.conf” file by typing “vi /etc/resolv.conf” and validate that two available DNS servers are listed. The next
example shows two DNS servers listed in a resolve.conf file.
# vi /etc/resolve.conf
nameserver <MY DNS SERVER1 IP ADDRESS>
nameserver <MY DNS SERVER2 IP ADDRESS>
From each Oracle VM server ping each DNS server listed in the resolv.conf file to ensure network connectivity.
Next, validate the forward and reverse lookups for each Oracle VM pool member and the Oracle VM Manager host using the “host”
command. For example, to validate server2's forward lookup from server1 type “host server2” as shown in the next example.
# host server2
server2 has address
192.168.4.6
Next, to validate server2's reverse lookup from server1 type “host 192.168.4.6” as shown in the next example.
# host 192.168.4.6
6.4.168.192.in-addr.arpa domain
name pointer
server2
Note: Using hosts files without DNS is not advised and may produce unpredictable results.
6. The Oracle VM server’s host name in the /etc/hosts file must be associated with the Oracle VM server's public IP address. If an
Oracle VM pool member's host name is associated with 127.0.0.1, the cluster.conf file will be malformed and the Oracle VM pool will
not be operational. The next example shows the improper syntax from an Oracle VM server's hosts file entry.
127.0.0.1 localhost.localdomain
localhost
192.168.4.8 servername.com
servername
7. ocfs2 network connectivity between all Oracle VM server pool members must be operational before creating a multiple server pool.
Check the ocfs2 network connectivity between all Oracle VM pool members by typing "nc -zv <myoraclevmserver1> 7777". For
example, if you have two Oracle VM servers named ovs1 and ovs2, from ovs1 type "nc -zv ovs2 7777". Typing "nc -zv ovs2 7777" from
ovs1 should return "succeeded!". If you receive a "failed: Connection refused" message between any Oracle VM servers, something
(firewall, switch, router, cable, etc..) is restricting communication between the hosts.
The iptables firewall on an Oracle VM server may be blocking the ocfs2 connectivity. If iptables is disabled and allowing all
connections, the output from typing “iptables -L” will look like the next example.
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
After you have added the above bold iptables rule, restart the iptables service by typing "service iptables restart".
8. If an Oracle VM server was originally installed with a local ocfs2 storage repository, it is necessary to remove and unmount the
local ocfs2 storage repository before adding the Oracle VM server to a pool. To determine if an Oracle VM server is using a local
storage repository type "/opt/ovs-agent-2.3/utils/repos.py -l" to list all configured storage repositories. If a storage repository is listed,
type "/opt/ovs-agent-2.3/utils/repos.py -d UUID" to remove the local repository from the Oracle VM server.
Next, check if the local storage repository is still mounted under /var/ovs/mount/UUID. Type “mount |grep mount”, as shown in the
next example to list the mounts.
# umount /var/ovs/mount
/62C757BA5E174DF7B5AB01BBAE0F765D
Tip: A default Oracle VM server installation dedicates the majority of the local disk to the OVS partition and create a small root
partition. If your Oracle VM server was installed with the default OVS partition with a small root partition, consider rebuilding the
server to create a disk layout that allocates the disk space to the root partition.
Another consideration for small roots that include /var is the potential for large saves from the xendomains service. If an Oracle VM
server crashes, the xendomains service will save the state (the memory foot print of each guest) of all running guests in the /var/lib
/xen/save directory, which could fill up a small root partition. If xendomains functionality is not needed disable it. The next example
shows how to disable or edit the location of the saved xendomains files.
1. Edit /etc/sysconfig/xendomains
2. find the section:
## Type: string
## Default: /var/lib/xen/save
#
# Directory to save running domains to when the system (dom0) is
# shut down. Will also be used to restore domains from if # XENDOMAINS_RESTORE
# is set (see below). Leave empty to disable domain saving on shutdown
# (e.g. because you rather shut domains down).
# If domain saving does succeed, SHUTDOWN will not be executed.
#
XENDOMAINS_SAVE=/var/lib/xen/save
3. Clear the XENDOMAINS_SAVE path to disable saves. Or point the XENDOMAINS_SAVE path to a partition with available space.
4. Rest the xendomains services by typing “service xendomains restart” to enable a new configuration.
9. If an Oracle VM server have previously been added to an Oracle VM server pool, the Oracle VM server's cluster configurations will
need to be cleaned before added to a new Oracle VM server pool. To clean an Oracle VM server's cluster configurations it is necessary
to a) empty the /etc/ocfs/cluster.conf file b) delete and recreate the local BerkleyDB and c) run the cleanup.py script to stop o2cb
heartbeat, offline o2cb, remove o2cb configuration file, umount ovs-agent storage repositories and to cleanup ovs-agent local
database.
To clear /etc/ocfs/cluster.conf file type “cat /dev/null> /etc/ocfs2/cluster.conf” from dom0, as shown in the next example.
To stop the o2cb heartbeat, offline o2cb, remove o2cb configuration file, unmount ovs-agent storage repositories and to cleanup
ovs-agent local database, type "/opt/ovs-agent-2.3/utils/cleanup.py" and then type “y” as shown in the next example.
# /opt/ovs-agent-2.3/utils/cleanup.py
This is a cleanup script for
ovs-agent.
It will try to do the following:
Tip: If there are no host adapters listed in the /sys/class/fc_host directory, check if the HBAs are properly zoned and masked.
As shown in the next example, type “ll /sys/class/fc_host” to list the host adapters.
# ll /sys/class/fc_host
total 0
drwxr-xr-x 3 root root 0 Oct 11 08:24 host6
The output from “ll /sys/class/fc_host” shows that there are two host adapters, host6 and host7.
Once you’re able to list the host adapters in the /sys/class/fc_host directory, cat each host adapter’s “port_name” file to get the host
adapter number ID number.
#cat /sys/class/fc_host/host6/port_name
0x10000000c0ffee7e
The above example shows that 0x10000000c0ffee7e is the host adapter number ID number for host6.
Next, cat the host7/port_name file to get the host adapter number ID number.
cat /sys/class/fc_host/host7/port_name
0x10000000c0ffee7f
The above example shows that 0x10000000c0ffee7f is the host adapter number ID number for host7.
If you need to rescan the bus, echo the “/sys” filesystem as shown in the next examples.
For example.
We have successfully discovered the host adapter ID numbers from each Oracle VM server.
Step 2: Next, validate that multipath daemon is properly configured on each Oracle VM server. From dom0, type “service multipathd
status”, as shown in the following example.
If your system’s multipath daemon is stopped, use chkconfig to configure the multipath daemon, as shown in the below example.
Next, type “chkconfig --list multipathd” to view the multipath daemon configuration, as shown in the next example.
The output of “chkconfig --list multipathd” shows that the multipath daemon is not configured to run at any system run level i.e. run
level 0 through 6.
Next, type “chkconfig multipathd on” in order to automatically start the multipath daemon at run level 3, 4 and 5, as shown in the
next example.
#chkconfig multipathd on
Next, validate the multipathd startup configuration by typing “chkconfig --list multipathd” as shown in the next example.
The output of “chkconfig --list multipathd” validates that the multipath daemon is configured to run at run level 2, 3, 4, and 5.
Finally, start the multipath daemon by typing “service multipathd start”, as shown in the following example.
We have successfully configured and started the multipath daemon on each Oracle VM server.
Step 3: Next, we will configure dm-multipath on each Oracle VM server by replacing or modifying the default /etc/multipath.conf file
with a multipath.conf file crafted for your storage solution. multipath.conf file settings can be vendor specific, please check with your
storage vendor for a multipath.conf file for Oracle VM or RHEL 5U3. If you already have a working multipath.conf file please skip to
Step 4.
Each Oracle VM server has an example multipath.conf file located at /etc/multipath.conf. The example multipath.conf file should be
modified or replaced with a vendor specific multipath.conf file to support your storage array. A multipath.conf file is divided into four
sections. List 4 shows the four sections of a multipath.conf file.
1. blacklist
2. defaults
3. multipaths
4. devices
Blacklist
The blacklist section lists devices that are to be excluded from multipath control. For example, if the server boots from a local disks
i.e. sda, sdb, hda, hdb, etc…then we need to include those disks in the blacklist. The example multipath.conf file has two blacklist
entries.
As shown below, the first blacklist entry is uncommented and will blacklist all devices.
blacklist {
devnode "*"
}
If you are going to test the example multipath.conf file, comment the blacklist entry to allow devices to be managed by dm-multipath.
The next example shows the blacklist entries commented.
#blacklist {
# devnode "*"
#}
The second blacklist entry is commented and shows how to blacklist WWIDs, ram, raw, loop, fd, md, dm-, sr, scd, st, and hd devices.
The next example shows the second black list entry.
#blacklist {
# wwid 26353900f02796769
# devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
# devnode "^hd[a-z]"
#}
The first entry wwid 26353900f02796769 is an example that shows how to blacklist WWID. If you need to blacklist WWIDs, add an
entry for each WWID, for example.
wwid "3600508b40008dc480000500000670000"
wwid "3600508b40008dc480000500000640000"
wwid "3600508b40008dc480000500000610000"
The second devnode line devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" blacklists ram, raw, loop, fd, md, dm-, sr, scd, st,
and hd devices.
The third devnode entry devnode "^hd[a-z]" will blacklist hda disks.
To test the default blacklist entry, first comment out the blacklist entry that blacklist all devices. Next, remove the wwid line, then
uncomment the blacklist, devnode and the } sections, as shown below.
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
}
You will need to restart the multipath daemon to test any new settings. The next example shows how to restart the multipath daemon.
If your Oracle VM servers use a serial or SCSI controller for local disks then the interface names will be similar to sda, sdb, etc. To
exclude the local disks i.e. sda and sdb you need to add a devnode entry for the devices. The example devnode entry below will
blacklist the sda and the sdb device.
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
devnode "^sd[a-b]$"
}
Defaults
The defaults section allows you to configure default settings for dm-multipath that “may” be supported by your storage array. If you
determined that your storage array does not use the settings in the defaults section, use the devices section of the multipath.conf file.
The defaults section settings are overwritten when the devices and multipaths sections are used. The default “defaults” setting in the
example multipath.conf uses the “user_friendly_names yes” entry. The “user_friendly_names yes” entry will allow you to use an alias,
instead of WWID (World Wide Identifier) names.
Multipath devices can be identified by a WWID names or by an alias. A WWID is a unique identifier for the multipath device that does
not change. Device names such as /dev/sdx and /dev/dm-x can change on reboot, so defining multipath devices by their ID is
preferred. The multipath device names in the /dev/mapper directory references LUN IDs that do not change and are user friendly, i.e.
mpath0, mpath1, etc…
Multipaths
The multipaths section is where you map devices to a user friendly name. Each multipath entry will specify the UUID or wwid and the
alias of a LUN along with path_checker variables, which will regularly check the path. The settings in the multipaths section overwrite
the settings specified in the defaults and devices sections.
Devices
The devices section is used to define vendor specific settings. Consult your storage vendor for the entries for your storage array. If you
are using multiple SAN storage systems, several device entries are necessary.
After changing settings in a multipath.conf file, administrators must restart the dm multipath daemon by typing service multipathd
restart, as shown in the next example.
To generate detailed return messages, administrators can type “multipath -ll”. The “multipath -ll” command will list all LUNs by
WWID with their multipath device names and the individual paths used to create the multipath.
# This is a basic configuration file with some examples, for device mapper
# multipath.
# For a complete list of the default configuration values, see
# /usr/share/doc/device-mapper-multipath-0.4.7/multipath.conf.defaults
# For a list of configuration options with descriptions, see
# /usr/share/doc/device-mapper-multipath-0.4.7/multipath.conf.annotated
}
##
## Here is an example of how to configure some standard options.
##
#
#defaults {
# udev_dir /dev
# polling_interval 10
# selector "round-robin 0"
# path_grouping_policy multibus
# getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
# prio_callout /bin/true
# path_checker readsector0
# rr_min_io 100
# max_fds 8192
# rr_weight priorities
# failback immediate
# no_path_retry fail
# user_friendly_names yes
#}
##
## The wwid line in the following blacklist section is shown as an example
## of how to blacklist devices by wwid. The 2 devnode lines are the
## compiled in default blacklist. If you want to blacklist entire types
## of devices, such as all scsi devices, you should use a devnode line.
## However, if you want to blacklist specific devices, you should use
## a wwid line. Since there is no guarantee that a specific device will
## not change names on reboot (from /dev/sda to /dev/sdb for example)
## devnode lines are not recommended for blacklisting specific devices.
##
#blacklist {
# wwid 26353900f02796769
# devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
# devnode "^hd[a-z]"
#}
#multipaths {
# multipath {
# wwid 3600508b4000156d700012000000b0000
# alias yellow
# path_grouping_policy multibus
# path_checker readsector0
# path_selector "round-robin 0"
# failback manual
# rr_weight priorities
# no_path_retry 5
# }
# multipath {
# wwid 1DEC_____321816758474
# alias red
# }
#}
#devices {
# device {
# vendor "COMPAQ "
# product "HSV110 (C)COMPAQ"
# path_grouping_policy multibus
# getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
# path_checker readsector0
# path_selector "round-robin 0"
# hardware_handler "0"
# failback 15
# rr_weight priorities
# no_path_retry queue
# }
# device {
# vendor "COMPAQ "
# product "MSA1000 "
# path_grouping_policy multibus
# }
#}
Note: If you do not have a working multipath.conf file please reference Appendix A for example multipath.conf files.
Once you have a working multipath.conf file and have restarted the multipath daemon you can list the mapped devices in the
/dev/mapper directory. Next we will access dom0 as root and type “ll /dev/mapper” to view the mapped devices, as shown in the
following example.
# ll /dev/mapper
total 0
crw------- 1 root root 10, 62 Jan 23 16:44 control
brw-rw---- 1 root disk 253, 0 Jan 23 17:01 mpath0
The "mpath0" entry validates that the mapped device is available from dom0.
We can also list the mapped devices with their major and minor numbers by typing “dmsetup ls”. The minor numbers corresponds
with the dm device name. In the following example the minor number of 0 corresponds to the multipath device /dev/dm-0.
#dmsetup ls
mpath0 (253, 0)
We can also validate the mapped devices with the corresponding multipath devices by listing the /dev/mpath/ directory as shown in
the next example.
# ll /dev/mpath/
total 0
lrwxrwxrwx 1 root root 7 Jan 23 17:01 mpath0 -> ../dm-0
To list all the storage devices and the available paths type “multipath –l”, as shown in the next example.
# multipath -l
mpath0 (2000b080000002369) dm-0 Pillar,Axiom 600
[size=603G][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][enabled]
\_ 7:0:0:0 sdb 8:16 [active][undef]
\_ 7:0:1:0 sdc 8:32 [active][undef]
\_ 8:0:0:0 sdd 8:48 [active][undef]
The "multipath -l" command queries sysfs and the device mapper only, it does not invoke path checkers. The "multipath -ll" gets
information from all relevant sources, including path checkers.
In Step 3 we reviewed the syntax of a multipath.conf file and showed how to restart the multipath daemon to view the mapped
devices, and the storage devices, along with the available paths.
Step 4: Next we will create an OCFS2 storage repository on a LUN or LUNs from “one” Oracle VM server. We will format the OCSF
partition from the pool master.
In the above example, the mkfs.ocfs2 utility is used to format the device. The “-L” parameter is optional and can be used to add a
descriptive label to the OCFS2 volume. The “-Tdatafiles” parameter makes mkfs.ocfs2 choose the optimal filesystem parameters for
the device. The -N parameter selects the number of slots. The number of slots determines the number of pool members that can
concurrently mount the OCFS2 volume. The OCFS2 file system can support up to 255 nodes. For example, if your Oracle VM server
pool will have 20 pool members, select -N20. The slot number can later be increased or decreased using the tunefs.ocfs2 utility.
Next, from dom0, format an OCFS2 volume by typing “mkfs.ocfs2 -L root-sr -Tdatafiles -N16 /dev/mapper/mpath0”, as shown in the
next example.
Substitute root-sr with your desired label name and /dev/mapper/mpath0 with the proper device path for your environment.
32256 clusters)
Journal size=33554432
Initial number of node slots: 16
Creating bitmaps: done
Initializing superblock: done
Writing system files: done
Writing superblock: done
Writing backup superblock: 5 block(s)
After the OCFS2 volume has been formatted you can use the mounted.ocfs2 utility to detect and list the OCFS2 volume.
To detect and list the OCFS2 volume from the above example, type “mounted.ocfs2 –d” from dom0, as shown in the next example.
# mounted.ocfs2 -d
Device FS UUID Label
/dev/mapper/mpath0 ocfs2 35c601e9-b0da-4950-9a90-ec0193baa205 root-sr
The above mounted.ocfs2 -d example lists the device name, the file system type, the UUID and the label.
You can also use the full (-f) mode to lists the status of each OCFS2 volume.
# mounted.ocfs2 -f
Device FS Nodes
/dev/mapper/mpath0 ocfs2 Not mounted
The above mounted.ocfs2 -f example lists the device name, the file system type, and the status of the node.
Note: Sparse files and unwritten extents are activated by default when using Oracle VM 2.2’ mkfs.ocfs2 utility. If your system was
upgraded from 2.1 to 2.2, it’s necessary to enable sparse files and unwritten extents using the following procedure.
# umount <device>
# tunefs.ocfs2 --fs-features=sparse,unwritten <device>
To validate the enabled OCSF2 features, type “tunefs.ocfs2 -Q "%M %H %O\n" <device>” as shown in the next example.
We have successfully formatted the /dev/mpath0 device with OCSF2 using the mkfs.ocfs2 utility as well as reviewed mounted.ocfs2 –d,
mounted.ocfs2 -f and how to list the OCFS2 features using tunefs.ocfs2.
Step 5: Next, on the pool master configure the root repository using the repos script. After the pool master is configured, configure
all other pool members.
1. From dom0 type "/opt/ovs-agent-2.3/utils/repos.py -l" to list any configured storage repositories, as shown in the next example.
# /opt/ovs-agent-2.3/utils
/repos.py -l
#
Typing "/opt/ovs-agent-2.3/utils/repos.py -l" should result with an empty entry. If a storage repository is listed, type "/opt/ovs-agent-
2.3/utils/repos.py -d UUID" to remove the repository. Next, unmout the storage repository in /var/ovs/mount/UUID by typing “umount
/var/ovs/mount/UUID”.
2. Next, type "/opt/ovs-agent-2.3/utils/repos.py -n /dev/mpath0" to add the new device to the list of managed devices, as shown in
the next example. Substitute /dev/sdb for the correct device path for your environment.
# /opt/ovs-agent-2.3/utils/repos.py -n /dev/mapper/mpath0
[ NEW ] 002463a4-8998-4423-a797-8a1544739409 => /dev/mapper/mpath0
3. Next, type "/opt/ovs-agent-2.3/utils/repos.py -r UUID" to tag the storage repository as the root storage repository, as shown in
the next example.
# /opt/ovs-agent-2.3/utils/repos.py -r 002463a4-8998-4423-
a797-8a1544739409
[ R ] 002463a4-8998-4423-a797-8a1544739409 => /dev/mapper
/mpath0
Note: The UUID will be listed in step 2 or you can list the UUID by typing repos.py -l.
4. Next, "only" on the pool master type /opt/ovs-agent-2.3/utils/repos.py -i to mount the root storage repository, as shown in the
next example. This step only needs to be performed on the pool master.
# /opt/ovs-agent-2.3/utils/repos.py -i
*** Storage repositories initialized.
Note: When repos.py -i is run, the new storage repository will be mounted under /var/ovs/mount/UUID, although the new storage
repository will not be linked to /OVS. The Oracle VM agent is responsible for mounting and linking storage repositories for pool
members.
Next, validate that the storage repository has been mounted by typing “mounted.ocfs2 -f“, as shown in the next example.
# mounted.ocfs2 -f
Device FS Nodes
/dev//mapper/mpath0 ocfs2 ovs1.sf.itnc.com
You can also validate the ocfs2 mounts by typing mount|grep ocfs2, as shown in the next example.
# mount|grep ocfs2
ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw)
/dev/mapper/mpath0 on /var/ovs/mount
/A85D7145957842F988293FDA43F8754D type ocfs2
(rw,_netdev,heartbeat=local)
Typing df –h would also validate that the root storage repository is mounted, as shown in the next example.
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 451G 961M 426G 1% /
/dev/sda1 99M 46M 48M 49% /boot
tmpfs 285M 0 285M 0% /dev/shm
/dev/mapper/mpath0 463G 541M 463G 1% /var/ovs/mount/A33BF3D2E09B45F3931F830CB1A404AA
5. Next, create the pool in Oracle VM Manager. When creating the pool select the Oracle VM server that was used to format the
OCFS2 file system as the pool master.
6. Next, add all of the other configured Oracle VM servers to the pool.
Once a pool is configured, the Oracle VM agent will automatically place resources such as virtual machines, templates, or ISO files on
the storage repository with available space. The Oracle VM agent is also responsible for mounting and linking storage repositories.
2. Select an Oracle VM server that will be used as the Oracle VM pool master. After the Oracle VM pool master and all the other Oracle VM pool
members meet the prerequisites outlined in the following steps, access Oracle VM Manager and create an HA enabled pool using the Oracle VM pool
master server.
Note: An HA enabled pool automatically mounts and links root and extended storage repositories for each Oracle VM pool member that is added to a
pool.
3. Ensure that all the Oracle VM servers’ clocks are synchronized using NTP.
First, open the “/etc/ntp.conf” file by typing “vi /etc/ntp.conf” and validate that at least two available NTP servers entries are listed. The next example
shows two bold NTP server entries in an ntp.conf file.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server myntp1.com
server myntp2.com
Ping each NTP server listed in the ntp.conf file from each Oracle VM server to ensure network connectivity.
Next, type "ntpstat" on each Oracle VM server to validate the NTP configuration. The next example shows the output from typing the ntpstat command
on an Oracle VM server that has its time synchronized to an NTP server with the IP address of 192.168.4.251.
# ntpstat
4. All Oracle VM servers have consistent name resolution using DNS with both forward and reverse lookups.
First, open the “/etc/resolv.conf” file by typing “vi /etc/resolv.conf” and validate that two available DNS servers are listed. The next example shows two
DNS servers listed in a resolve.conf file.
# vi /etc/resolve.conf
nameserver <MY DNS SERVER1 IP ADDRESS>
nameserver <MY DNS SERVER2 IP ADDRESS>
From each Oracle VM server ping each DNS server listed in the resolv.conf file to ensure network connectivity.
Next, validate the forward and reverse lookups for each Oracle VM pool member and the Oracle VM Manager host using the “host” command. For
example, to validate server2's forward lookup from server1 type “host server2” as shown in the next example.
# host server2
server2 has address
192.168.4.6
Next, to validate server2's reverse lookup from server1 type “host 192.168.4.6” as shown in the next example.
# host 192.168.4.6
6.4.168.192.in-addr.arpa domain name
pointer
server2
Note: Using hosts files without DNS is not advised and may produce unpredictable results.
5. The Oracle VM server’s host name in the /etc/hosts file must be associated with the Oracle VM server's public IP address. If an Oracle VM pool
member's host name is associated with 127.0.0.1, the cluster.conf file will be malformed and the Oracle VM pool will not be operational. The next
example shows the improper syntax from an Oracle VM server's hosts file entry.
6. ocfs2 network connectivity between all Oracle VM server pool members must be operational before creating a multiple server pool. Check the ocfs2
network connectivity between all Oracle VM pool members by typing "nc -zv <myoraclevmserver1> 7777". For example, if you have two Oracle VM
servers named ovs1 and ovs2, from ovs1 type "nc -zv ovs2 7777". Typing "nc -zv ovs2 7777" from ovs1 should return "succeeded!". If you receive a
"failed: Connection refused" message between any Oracle VM servers, something (firewall, switch, router, cable, etc..) is restricting communication
between the hosts.
The iptables firewall on an Oracle VM server may be blocking the ocfs2 connectivity. If iptables is disabled and allowing all connections, the output from
typing “iptables -L” will look like the next example.
# iptables -L
After you have added the above bold iptables rule, restart the iptables service by typing "service iptables restart".
7. If an Oracle VM server was originally installed with a local ocfs2 storage repository, it is necessary to remove and unmount the local ocfs2 storage
repository before adding the Oracle VM server to a pool. To determine if an Oracle VM server is using a local storage repository type "/opt/ovs-agent-
2.3/utils/repos.py -l" to list all configured storage repositories. If a storage repository is listed, type "/opt/ovs-agent-2.3/utils/repos.py -d UUID" to remove
the local repository from the Oracle VM server.
Next, check if the local storage repository is still mounted under /var/ovs/mount/UUID. Type “mount |grep mount”, as shown in the next example to list
the mounts.
# umount /var/ovs/mount
/62C757BA5E174DF7B5AB01BBAE0F765D
Tip: A default Oracle VM server installation dedicates the majority of the local disk to the OVS partition and create a small root partition. If your Oracle
VM server was installed with the default OVS partition with a small root partition, consider rebuilding the server to create a disk layout that allocates the
disk space to the root partition.
Another consideration for small roots that include /var is the potential for large saves from the xendomains service. If an Oracle VM server crashes, the
xendomains service will save the state (the memory foot print of each guest) of all running guests in the /var/lib/xen/save directory, which could fill up a
small root partition. If xendomains functionality is not needed disable it. The next example shows how to disable or edit the location of the saved
xendomains files.
1. Edit /etc/sysconfig/xendomains
2. find the section:
## Type: string
## Default: /var/lib/xen/save
#
# Directory to save running domains to when the system (dom0) is
# shut down. Will also be used to restore domains from if # XENDOMAINS_RESTORE
# is set (see below). Leave empty to disable domain saving on shutdown
# (e.g. because you rather shut domains down).
# If domain saving does succeed, SHUTDOWN will not be executed.
#
XENDOMAINS_SAVE=/var/lib/xen/save
3. Clear the XENDOMAINS_SAVE path to disable saves. Or point the XENDOMAINS_SAVE path to a partition with available space.
4. Rest the xendomains services by typing “service xendomains restart” to enable a new configuration.
8. If an Oracle VM server have previously been added to an Oracle VM server pool, the Oracle VM server's cluster configurations will
need to be cleaned before added to a new Oracle VM server pool. To clean an Oracle VM server's cluster configurations it is necessary
to a) empty the /etc/ocfs/cluster.conf file b) delete and recreate the local BerkleyDB and c) run the cleanup.py script to stop o2cb
heartbeat, offline o2cb, remove o2cb configuration file, umount ovs-agent storage repositories and to cleanup ovs-agent local
database.
To clear /etc/ocfs/cluster.conf file type “cat /dev/null> /etc/ocfs2/cluster.conf” from dom0, as shown in the next example.
agent/db/*” to delete the BerkleyDB. Finally, type “service ovs-agent start” to start the Oracle VM agent, which also recreate a new
local BerkleyDB.
To stop the o2cb heartbeat, offline o2cb, remove o2cb configuration file, unmount ovs-agent storage repositories and to cleanup
ovs-agent local database, type "/opt/ovs-agent-2.3/utils/cleanup.py" and then type “y” as shown in the next example.
# /opt/ovs-agent-2.3/utils/cleanup.py
This is a cleanup script for
ovs-agent.
It will try to do the following:
If the iscsi service is not running, start the iscsi service by typing “service iscsi start” as shown in the next example.
We have successfully validated that the iscsi service is running on each Oracle VM pool member.
Step 2: Next, on each Oracle VM server discover the iSCSI LUNs using the iscsiadm utility. Once the iSCSI LUNs have been
discovered, if necessary, remove any entries that will not be used. Next, we will verify that the unused LUNs are removed.
List 1 shows the procedure to discover, remove and validate iSCSI LUNs.
1. First, from dom0 type “iscsiadm -m discovery -t sendtargets -p iSCSI-Target-IPADDRESS”, to discover the entries from your
iSCSI target. Substitute “iSCSI-Target-IPADDRESS” with the IP address or FQDN of your iSCSI target.
2. Second, remove any unused entries by typing “iscsiadm -m node -p iSCSI Qualified Name -o delete”, for example, iscsiadm -m
node -p 192.168.4.10:3260,1 -T iqn.2006-01.com.openfiler:tsn.a83c0838952c -o delete.
3. Finally, validate that only the desired LUNs are discovered by typing “iscsiadm -m node”.
As shown in the next example, the output from “iscsiadm -m discovery -t sendtargets -p 192.168.4.10” lists two entries. The first entry,
192.168.4.10:3260,1 iqn.2006-01.com.openfiler:tsn.a83c0838952c will be removed. The second entry, 192.168.4.10:3260,1
iqn.2006-01.com.openfiler:tsn.db29e77712c0 will become the root repository.
Note: Discovered LUNs will appear in /proc/partitions only after restarting the iscsi service.
In general, if your Oracle VM server lists entries that you will not use, you will need to remove all of the entries.
To remove an unused entry, for example type “iqn.2006-01.com.openfiler:tsn.a83c0838952c” type “iscsiadm -m node -p
192.168.4.10:3260,1 -T iqn.2006-01.com.openfiler:tsn.a83c0838952c -o delete
”, as shown in the next example.
The next example shows how to verify that the unused entry has been removed by typing “iscsiadm -m node".
# iscsiadm -m node
192.168.4.10:3260,1
iqn.2006-01.com.openfiler:tsn.aa231ffd6ef2
Step 3: Next, on each Oracle VM server list /proc/partitions to review each Oracle VM server’s devices. After we review the
devices listed in /proc/partitions, restart the iscsi service to mount the discovered iSCSI LUN. After the iSCSI service is restarted, the
iSCSI LUN will be listed in /proc/partitions as a new device, i.e. sdb.
Before we restart the iscsi service, review the devices listed on each Oracle VM server by typing “cat /proc/partitions”, as shown in
the next example.
# cat /proc/partitions
major
minor #blocks name
8 0 488386584 sda
8 1 104391 sda1
8 2 487227352
sda2
8 3 1052257
sda3
Next, type “service iscsi restart” to restart the iscsi service, which also mounts the discoved LUN.
After the iscsi service is restarted, any discovered iSCSI LUNs will be listed in /proc/partitions as a new device, as shown in the next
example.
# cat /proc/partitions
major
minor #blocks name
8 0 488386584 sda
8 1 104391 sda1
8 2 487227352
sda2
8 3 1052257
sda3
8 16 485490688
sdb
Note that the LUN i.e. the sdb device is listed in /proc/partitions. Now the new device can be partitioned using the mkfs.ocfs2 utility.
In Step 3 we reviewed /proc/partitions on each Oracle VM server. Next, we restarted the iscsi service which mounted the discovered
iSCSI LUN. After the iSCSI LUN was mounted, we validated that the new device was listed in /proc/partitions.
Step 4: Next, “only on the pool master” you have to format an OCFS2 volume on the new device (the iSCSI LUN), using the
mkfs.ocfs2 utility. The OCSF2 volume should be formatted “only” from one Oracle VM server, i.e. the pool master server.
Note: If you already have created a server pool, format the OCSF2 volume “only” on the server pool master server. If you have not
created a server pool in Oracle VM manager, use the Oracle VM server that you will select as the pool master to format the OCFS2
volume.
In the above example, the mkfs.ocfs2 utility is used to format the device. The “-L” parameter is optional and can be used to add a
descriptive label to the OCFS2 volume. The “-Tdatafiles” parameter makes mkfs.ocfs2 chose the optimal filesystem parameters for the
device. The -N parameter selects the number of slots. The number of slots determines the number of pool members that can
concurrently mount the OCFS2 volume. The OCFS2 file system can support up to 255 nodes. For example, if your Oracle VM server
pool will have 20 pool members, select -N20. The slot number can later be increased or decreased using the tunefs.ocfs2 utility. Next,
from dom0, format an OCFS2 volume by typing “mkfs.ocfs2 -L root-sr -Tdatafiles -N16 /dev/sdb”, as shown in the next example.
Substitute root-sr with your desired label name and /dev/sdb with the proper device path for your enviroment.
After the OCFS2 volume has been formatted you can use the mounted.ocfs2 utility to detect and list the OCFS2 volume.
To detect and list the OCFS2 volume from the above example, type “mounted.ocfs2 –d” from dom0, as shown in the next example.
# mounted.ocfs2 -d
Device FS UUID
Label
/dev/sdb ocfs2 35c601e9-b0da-4950-9a90-
ec0193baa205 root-sr
The above mounted.ocfs2 -d example lists the device name, the file system type, the UUID and the label.
You can also use the full (-f) mode to lists the status of each OCFS2 volume.
# mounted.ocfs2 -f
Device FS Nodes
/dev/sdb ocfs2 Not
mounted
The above mounted.ocfs2 -f example lists the device name, the file system type, and the status of the node.
Note: Sparse files and unwritten extents are activated by default when using Oracle VM 2.2’ mkfs.ocfs2 utility. If your system was
upgraded from 2.1 to 2.2, it’s necessary to enable sparse files and unwritten extents using the following procedure.
# umount <device>
# tunefs.ocfs2 --fs-features=sparse,unwritten <device>
To validate the enabled OCSF2 features, type “tunefs.ocfs2 -Q "%M %H %O\n" <device>” as shown in the next example.
We have successfully formatted the /dev/sdb volume with OCSF2 using the mkfs.ocfs2 utility as well as reviewed mounted.ocfs2 –d,
mounted.ocfs2 -f and how to list the OCFS2 features using tunefs.ocfs2.
Step 5: Next, on the pool master configure the root repository using the repos script. After the pool master is configured, configure
all other pool members.
1. From dom0 type "/opt/ovs-agent-2.3/utils/repos.py -l" in order to list any configured storage repositories, as shown in the next
example.
# /opt/ovs-agent-2.3/utils
/repos.py -l
#
Typing "/opt/ovs-agent-2.3/utils/repos.py -l" should result with an empty entry. If a storage repository is listed, type "/opt/ovs-agent-
2.3/utils/repos.py -d UUID" to remove the repository. Next, unmout the storage repository in /var/ovs/mount/UUID by typing “umount
/var/ovs/mount/UUID”.
2. Next, type "/opt/ovs-agent-2.3/utils/repos.py -n /dev/sdb" to add the new device to the list of managed devices, as shown in the
next example. Substitute /dev/sdb for the correct device path for your environment.
# /opt/ovs-agent-2.3/utils/repos.py -n /dev/sdb
[ NEW ] 002463a4-8998-4423-a797-8a1544739409
=> /dev/sdb
3. Next, type "/opt/ovs-agent-2.3/utils/repos.py -r UUID" to tag the storage repository as the root storage repository, as shown in
the next example.
# /opt/ovs-agent-2.3/utils/repos.py -r 002463a4-8998-4423-
a797-8a1544739409
[ R ] 002463a4-8998-4423-a797-8a1544739409 => /dev/sdb
Note: The UUID will be listed in step 2 or you can list the UUID by typing repos.py -l.
4. Next, "only" on the pool master type /opt/ovs-agent-2.3/utils/repos.py -i to mount the root storage repository, as shown in the
next example. This step only needs to be performed on the pool master.
# /opt/ovs-agent-2.3/utils/repos.py -i
*** Storage repositories initialized.
Note: When repos.py -i is run, the new storage repository will be mounted under /var/ovs/mount/UUID, although the new storage
repository will not be linked to /OVS.
Next, validate that the storage repository has been mounted by typing “mounted.ocfs2 -f“, as shown in the next example.
# mounted.ocfs2 -f
Device FS Nodes
/dev/sdb
ocfs2 ovs2.sf.itnc.com
You can also validate the ocfs2 mounts by typing mount|grep ocfs2, as shown in the next example.
# mount|grep ocfs2
ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw)
/dev/sdb on /var/ovs/mount/A85D7145957842F988293FDA43F8754D
type ocfs2 (rw,_netdev,heartbeat=local)
Typing df –h would also validate that the root storage repository is mounted, as shown in the next example.
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 451G 961M 426G 1% /
/dev/sda1 99M 46M 48M 49% /boot
tmpfs 285M 0 285M 0% /dev/shm
/dev/sdb 463G 541M 463G 1% /var/ovs/mount
/A33BF3D2E09B45F3931F830CB1A404AA
5. Next, create the pool in Oracle VM Manager. When creating the pool select the Oracle VM server that was used to format the
OCFS2 file system as the pool master.
6. Next, add all of the other configured Oracle VM servers to the pool.
Note: If you restart the iscsi service to detect the new LUN, the iscsi service will log out of the existing storage repository, discover
the new LUN and reboot the server. To avoid a reboot of your Oracle VM server use the rescan option with the iscsiadm utility, i.e.
Next, connect the pool master and format the storage using the steps outlined in Step 4. Then, connect the other pool member to the
storage using the /opt/ovs-agent-2.3/utils/repos.py script with the -n (new) followed by the -i (initialize, aka mount) switches, to add
and then mount the sub storage repository. Finally, the new mount point in /var/ovs/mount/UUID needs to be linked to /OVS/UUID, by
typing “ln -nsf /var/ovs/mount/<UUID>/ /OVS”, again from dom0. The end result is a root repository with an “extended” sub
repository mounted under /var/ovs/mount/UUID which is linked to /OVS/UUID.
Once a pool is configured, the Oracle VM agent will automatically place resources such as virtual machines, templates, or ISO files on
the storage repository with available space. The Oracle VM agent is also responsible for mounting and linking storage repositories.
1. All Oracle VM servers must be patched from the Unbreakable Linux Network (ULN) to ensure that the storage configurations will
not be hampered by unpatched bugs.
2. Select an Oracle VM server that will be used as the Oracle VM pool master. After the Oracle VM pool master and all the other
Oracle VM pool members meet the prerequisites outlined in the following steps, access Oracle VM Manager and create an HA
enabled pool using the Oracle VM pool master server.
Note: An HA enabled pool automatically mounts and links root and extended storage repositories for each Oracle VM pool member
that is added to a pool.
3. Ensure that all the Oracle VM servers’ clocks are synchronized using NTP.
First, open the “/etc/ntp.conf” file by typing “vi /etc/ntp.conf” and validate that at least two available NTP servers entries are listed.
The next example shows two bold NTP server entries in an ntp.conf file.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server myntp1.com
server myntp2.com
Ping each NTP server listed in the ntp.conf file from each Oracle VM server to ensure network connectivity.
Next, type "ntpstat" on each Oracle VM server to validate the NTP configuration. The next example shows the output from typing the
ntpstat command on an Oracle VM server that has its time synchronized to an NTP server with the IP address of 192.168.4.251.
# ntpstat
4. All Oracle VM servers have consistent name resolution using DNS with both forward and reverse lookups.
First, open the “/etc/resolv.conf” file by typing “vi /etc/resolv.conf” and validate that two available DNS servers are listed. The next
example shows two DNS servers listed in a resolve.conf file.
# vi /etc/resolve.conf
nameserver <MY DNS SERVER1 IP ADDRESS>
nameserver <MY DNS SERVER2 IP ADDRESS>
From each Oracle VM server ping each DNS server listed in the resolv.conf file to ensure network connectivity.
Next, validate the forward and reverse lookups for each Oracle VM pool member and the Oracle VM Manager host using the “host”
command. For example, to validate server2's forward lookup from server1 type “host server2” as shown in the next example.
# host server2
server2 has address
192.168.4.6
Next, to validate server2's reverse lookup from server1 type “host 192.168.4.6” as shown in the next example.
# host 192.168.4.6
6.4.168.192.in-addr.arpa domain
name pointer
server2
Note: Using hosts files without DNS is not advised and may produce unpredictable results.
5. The Oracle VM server’s host name in the /etc/hosts file must be associated with the Oracle VM server's public IP address. If an
Oracle VM pool member's host name is associated with 127.0.0.1, the cluster.conf file will be malformed and the Oracle VM pool will
not be operational. The next example shows the improper syntax from an Oracle VM server's hosts file entry.
127.0.0.1 localhost.localdomain
localhost
192.168.4.8 servername.com
servername
6. ocfs2 network connectivity between all Oracle VM server pool members must be operational before creating a multiple server pool.
Check the ocfs2 network connectivity between all Oracle VM pool members by typing "nc -zv <myoraclevmserver1> 7777". For
example, if you have two Oracle VM servers named ovs1 and ovs2, from ovs1 type "nc -zv ovs2 7777". Typing "nc -zv ovs2 7777" from
ovs1 should return "succeeded!". If you receive a "failed: Connection refused" message between any Oracle VM servers, something
(firewall, switch, router, cable, etc..) is restricting communication between the hosts.
The iptables firewall on an Oracle VM server may be blocking the ocfs2 connectivity. If iptables is disabled and allowing all
connections, the output from typing “iptables -L” will look like the next example.
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
After you have added the above bold iptables rule, restart the iptables service by typing "service iptables restart".
7. If an Oracle VM server was originally installed with a local ocfs2 storage repository, it is necessary to remove and unmount the
local ocfs2 storage repository before adding the Oracle VM server to a pool. To determine if an Oracle VM server is using a local
storage repository type "/opt/ovs-agent-2.3/utils/repos.py -l" to list all configured storage repositories. If a storage repository is listed,
type "/opt/ovs-agent-2.3/utils/repos.py -d UUID" to remove the local repository from the Oracle VM server.
Next, check if the local storage repository is still mounted under /var/ovs/mount/UUID. Type “mount |grep mount”, as shown in the
next example to list the mounts.
# umount /var/ovs/mount
/62C757BA5E174DF7B5AB01BBAE0F765D
Tip: A default Oracle VM server installation dedicates the majority of the local disk to the OVS partition and create a small root
partition. If your Oracle VM server was installed with the default OVS partition with a small root partition, consider rebuilding the
server to create a disk layout that allocates the disk space to the root partition.
Another consideration for small roots that include /var is the potential for large saves from the xendomains service. If an Oracle VM
server crashes, the xendomains service will save the state (the memory foot print of each guest) of all running guests in the /var/lib
/xen/save directory, which could fill up a small root partition. If xendomains functionality is not needed disable it. The next example
shows how to disable or edit the location of the saved xendomains files.
1. Edit /etc/sysconfig/xendomains
2. find the section:
## Type: string
## Default: /var/lib/xen/save
#
# Directory to save running domains to when the system (dom0) is
# shut down. Will also be used to restore domains from if # XENDOMAINS_RESTORE
# is set (see below). Leave empty to disable domain saving on shutdown
# (e.g. because you rather shut domains down).
# If domain saving does succeed, SHUTDOWN will not be executed.
#
XENDOMAINS_SAVE=/var/lib/xen/save
3. Clear the XENDOMAINS_SAVE path to disable saves. Or point the XENDOMAINS_SAVE path to a partition with available space.
4. Rest the xendomains services by typing “service xendomains restart” to enable a new configuration.
8. If an Oracle VM server have previously been added to an Oracle VM server pool, the Oracle VM server's cluster configurations will
need to be cleaned before added to a new Oracle VM server pool. To clean an Oracle VM server's cluster configurations it is necessary
to a) empty the /etc/ocfs/cluster.conf file b) delete and recreate the local BerkleyDB and c) run the cleanup.py script to stop o2cb
heartbeat, offline o2cb, remove o2cb configuration file, umount ovs-agent storage repositories and to cleanup ovs-agent local
database.
To clear /etc/ocfs/cluster.conf file type “cat /dev/null> /etc/ocfs2/cluster.conf” from dom0, as shown in the next example.
To stop the o2cb heartbeat, offline o2cb, remove o2cb configuration file, unmount ovs-agent storage repositories and to cleanup
ovs-agent local database, type "/opt/ovs-agent-2.3/utils/cleanup.py" and then type “y” as shown in the next example.
# /opt/ovs-agent-2.3/utils/cleanup.py
This is a cleanup script for
ovs-agent.
It will try to do the following:
Step 1: On the pool master configure the root repository using the repos script. After the pool master is configured, configure all other pool members.
1. From dom0 type "/opt/ovs-agent-2.3/utils/repos.py -l" to list any configured storage repositories, as shown in the next example.
# /opt/ovs-agent-2.3/utils
/repos.py -l
#
Typing "/opt/ovs-agent-2.3/utils/repos.py -l" should result with an empty entry. If a storage repository is listed, type "/opt/ovs-agent-
2.3/utils/repos.py -d UUID" to remove the repository. Next, unmout the storage repository in /var/ovs/mount/UUID by typing “umount
/var/ovs/mount/UUID”.
2. Next, type "/opt/ovs-agent-2.3/utils/repos.py -n nfsserver:/mnt/vol1/ovs-root/" to add the new share, as shown in the next
example. Substitute nfsserver with the FQDN or IP address of your filer and substitute :/path/to/ovs-root-share with the path to your
NFS share.
# /opt/ovs-agent-2.3/utils/repos.py -n 192.168.4.10:/mnt/vg-931
/nfs-root/nfs-sr/
[ NEW ] ef47b8a9-620f-4ed1-aac1-7ac10f4f7fcf =>
192.168.4.10:/mnt/vg-931/nfs-root/nfs-sr/
3. Next, type "/opt/ovs-agent-2.3/utils/repos.py -r UUID" to tag the storage repository as the root storage repository, as shown in
the next example.
# /opt/ovs-agent-2.3/utils/repos.py -r ef47b8a9-620f-
4ed1-aac1-7ac10f4f7fcf
[ R ] ef47b8a9-620f-4ed1-aac1-7ac10f4f7fcf =>
192.168.4.10:/mnt/vg-931/nfs-root/nfs-sr/
Note: The UUID will be listed in step 2 or you can list the UUID by typing repos.py -l.
4. Next, type /opt/ovs-agent-2.3/utils/repos.py -i to mount the root storage repository, as shown in the next example. This step only
needs to be performed on the pool master. When Oracle VM pool members are added to a pool the agent will mount and link the root
storage repository.
# /opt/ovs-agent-2.3/utils/repos.py -i
*** Storage repositories initialized.
Note: When repos.py -i is run, the new storage repository will be mounted under /var/ovs/mount/UUID, although the new storage
repository will not be linked to /OVS. Once the pool is created the Oracle VM agent will auto mount and link the storage repository.
5. Next, create the pool in Oracle VM Manager. When creating the pool select the Oracle VM server that was used to format the
OCFS2 file system as the pool master.
6. Next, add all of the other configured Oracle VM servers to the pool.
The section starts with a review of file-backed block devices and the file-backed block device driver options. The section concludes
with a review of physical backed block devices.
By default, Oracle VM Manager and the Oracle VM Management Pack configure guest storage as file-backed block device using the
fast-loopback driver in dom0. You can validate that a guest is using a file-backed block device by looking at the 'disk =' directive in a
guest’s vm.cfg file. Each guest has a vm.cfg file in the /OVS/*_pool/vmname/ directory. A 'file:' reference indicates the use of the
fast-loopback driver.
File-backed block devices can use one of two drivers a) the default fast-loopback driver or b) the blktap driver. In certain
circumstances, the blktap driver may provide better performance than the fast-loopback driver. Oracle VM Manager and the Oracle
VM Management Pack do not support editing the file-backed block device driver settings. To test the blktap driver you must edit the
'file' directive by hand in the desired guest’s vm.cfg file from ‘file’ to 'tap:aio:'.
The next example shows a vm.cfg file from an 11g Oracle VM template that is configured with two virtual disks using file-backed block
devices with the fast-loopback driver. The first of two virtual disks is defined in the 'disk =' directive contains the OS and the second
virtual disk defined in the 'disk =' directive is an ASM disk.
bootloader = '/usr/bin/pygrub'
disk = ['file:/OVS/running_pool/v52x8611g1/System.img,xvda,w',
'file:/OVS/running_pool/v52x8611g1/oracle11g_x86_asm.img,xvdb,w',
]
memory = '2048'
name = 'v52x8611g1'
on_crash = 'restart'
on_reboot = 'restart'
uuid = 'f8725f79-c6c8-26d4-a51e-1f32cf010c84'
vcpus = 2
vif = ['bridge=xenbr0,mac=00:16:3E:56:20:63,type=netfront']
vif_other_config = []
The next example shows the same vm.cfg file from the above 11g Oracle VM template that is configured using file-backed block
devices with the blktap driver. The first of two virtual disks is defined in the 'disk =' directive contains the OS and the second virtual
disk defined in the 'disk =' directive is an ASM disk.
bootloader = '/usr/bin/pygrub'
disk = ['tap:aio:/OVS/running_pool/v52x8611g1/System.img,xvda,w',
'tap:aio:/OVS/running_pool/v52x8611g1/oracle11g_x86_asm.img,xvdb,w',
]
memory = '2048'
name = 'v52x8611g1'
on_crash = 'restart'
on_reboot = 'restart'
uuid = 'f8725f79-c6c8-26d4-a51e-1f32cf010c84'
vcpus = 2
vif = ['bridge=xenbr0,mac=00:16:3E:56:20:63,type=netfront']
vif_other_config = []
You can quickly benchmark guest front-end performance by typing “hdparm -tT <device>” within the guest. Replace <device> with
the device you would like to benchmark. Type df to list the devices.
For example, if a guest is using the default file-backed block device with the fast-loopback driver, as root from the guest console type
“hdparm -tT <device>” to gather cached reads and buffered disk reads statistics, as shown in the next example.
/dev/xvda2:
Timing cached reads: 26968 MB in 1.99 seconds = 13536.94 MB/sec
Timing buffered disk reads: 148 MB in 3.03 seconds = 48.87 MB/sec
Record the data from “hdparm -tT <device>” and power off the guest. Once the guest is powered of edit the guest’s vm.cfg file and
replace the file directive with tap:aio. Power on the guest and run the same “hdparm -tT <device>” command to gather the cached
reads and the buffered disk reads statistics using the with the blktap driver.
For example, Oracle’s certified Oracle VM RAC configuration uses physical backed block devices to provide the best performance for
RAC. To use a physical backed block device, you export a physical block device e.g. a LUN from dom0 to the guest, as a virtual block
device.
As of this writing, Oracle VM Manager or the Oracle VM Management Pack cannot manage physical backed block devices. To use
physical backed block devices with Oracle VM, you need to edit the guest’s vm.cfg file manually to use a physical backed block device.
Note: Oracle VM 2.2 Manager can manage physical multipath devices as Shared Disks.
The next example shows a vm.cfg file that uses physical backed block devices. The first of two disks is defined in the 'disk =' directive,
and contains the OS, the second disk defined in the 'disk =' directive is an ASM disk.
bootloader = '/usr/bin/pygrub'
disk = ['phy:/dev/sdu,xvda,w!’, 'phy:/dev/sdv,xvda,w!’
]
memory = '2048'
name = 'v52x8611g1'
on_crash = 'restart'
on_reboot = 'restart'
uuid = 'f8725f79-c6c8-26d4-a51e-1f32cf010c84'
vcpus = 2
vif = ['bridge=xenbr0,mac=00:16:3E:56:20:63,type=netfront']
vif_other_config = []
The next example shows a vm.cfg file from a guest that uses a file backed block device for the OS and eight physical backed block
devices.
bootloader = '/usr/bin/pygrub'
disk = ['file:/var/ovs/mount/
4C42F6B3FCB841499D595C0CC36D7695/
running_pool/266_lax005112pvm07/System.img,xvda,w',
'phy:/dev/sda,/dev/xvda3,w!',
'phy:/dev/sdb,/dev/xvda4,w!',
'phy:/dev/sdc,/dev/xvda5,w!',
'phy:/dev/sdd,/dev/xvda6,w!',
'phy:/dev/sde,/dev/xvda7,w!',
'phy:/dev/sdf,/dev/xvda8,w!',
'phy:/dev/sdg,/dev/xvda9,w!',
'phy:/dev/sdh,/dev/xvda10,w!',
]
keymap = 'en-us'
memory = '4096'
name = 'oel5u5pv07'
on_crash = 'restart'
on_reboot = 'restart'
uuid = '4fa8e2f0-4514-5169-467a-7fd64fe62147'
vcpus = 2
vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0']
vif =
['bridge=xenbr0,mac=00:16:3E:69:E4:04,type=netfront',
'bridge=xenbr1,mac=00:16:3E:61:DE:5E,type=netfront',
]
vif_other_config = []
1. The first step is to create a guest using Oracle VM Manager. Please note, that after the guest is created, the default file backed
block device, i.e. the System.img file can be used or deleted and replaced with a physical backed block device.
2. Provision a disk for the guest, i.e. one or more LUNs. The Oracle VM servers must be zoned and masked to be able to access the
storage.
3. Configure the storage in each dom0. For example, if the guest will run on 4 servers within a pool, the storage must be configured
in dom0 on all four servers.
4. Once the LUN is presented in dom0, export the LUN to the guest by editing the vm.cfg file using a physical backed block device
as show in the above examples.
#vi /etc/multipath.conf
devnode_blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
}
defaults {
user_friendly_names yes
}
#vi /etc/multipath.conf
## This is the /etc/multipath.conf file recommended for
## EMC storage devices.
##
## OS : RHEL5
## Arrays : CLARiiON and SYMMETRIX
## Use user friendly names, instead of using WWIDs as names.
defaults {
user_friendly_names yes
}
## The blacklist is the enumeration of all devices that are to be
#vi /etc/multipath.conf
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
devnode "^cciss!c[0-9]d[0-9]*"
wwid
}
devices {
device {
vendor "Pillar"
product "Axiom 600"
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout "/sbin/mpath_prio_alua %n"
features "0"
hardware_handler "0"
path_grouping_policy group_by_prio
rr_weight priorities
rr_min_io 1000
path_checker tur
}
device {
vendor "Pillar"
product "Axiom 500"
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout "/sbin/mpath_prio_alua_pillar %n"
features "0"
hardware_handler "0"
path_grouping_policy group_by_prio
rr_weight priorities
rr_min_io 1000
path_checker tur
}
4. HP EVA SAN
# vi /etc/multipath.conf
defaults {
user_friendly_names yes
}
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^(hd|xvd)[a-z]*"
wwid "*"
}
blacklist_exceptions {
wwid "3600508b40008dc480000500000550000"
wwid "3600508b40008dc4800005000005b0000"
wwid "3600508b40008dc4800005000005e0000"
wwid "3600508b40008dc480000500000670000"
wwid "3600508b40008dc480000500000640000"
wwid "3600508b40008dc480000500000610000"
}
multipath {
wwid 3600508b40008dc4800005000005b0000
alias mpath1
}
multipath {
wwid 3600508b40008dc4800005000005e0000
alias mpath2
}
multipath {
wwid 3600508b40008dc480000500000610000
alias mpath3
}
multipath {
wwid 3600508b40008dc480000500000640000
}
multipath {
wwid 3600508b40008dc480000500000670000
alias mpath5
}
# vi /etc/multipath.conf
devnode_blacklist {
# wwid 26353900f02796769
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*|sda"
devnode "^hd[a-z]"
}
multipaths {
multipath {
wwid 3600507680194011ef000000000000b46
alias oraclevm-lun0
path_grouping_policy failover
path_checker readsector0
path_selector "round-robin 0"
failback 0
rr_weight priorities
# no_path_retry 5
}
multipath {
wwid 3600507680194011ef000000000000dbd
alias oraclevm-lun1
}
multipath {
wwid 3600507680194011ef000000000000dbe
alias oraclevm-lun2
}
multipath {
wwid 3600507680194011ef000000000000dc4
alias oraclevm-lun3
}
multipath {
wwid 3600507680194011ef000000000000dbf
alias oraclevm-lun4
}
multipath {
wwid 3600507680194011ef000000000000dc0
alias oraclevm-lun5
}
multipath {
wwid 3600507680194011ef000000000000eaf
alias oraclevm-lun6
}
multipath {
wwid 3600507680194011ef000000000000eb0
alias oraclevm-lun7
}
multipath {
wwid 3600507680194011ef000000000000eb1
alias oraclevm-lun8
}
multipath {
wwid 3600507680194011ef000000000000eb2
alias oraclevm-lun9
}
devices {
# IBM 2145
device {
vendor "IBM"
product "2145"
path_grouping_policy group_by_prio
prio_callout "/sbin/mpath_prio_alua /dev/%n"
}
}
defaults {
udev_dir /dev
polling_interval 10
selector "round-robin 0"
path_grouping_policy multibus
getuid_callout "/sbin/scsi_id -g -u -s
/block/%n"
prio_callout /bin/true
rr_min_io 100
rr_weight priorities
failback immediate
}
devices {
device {
vendor "3PARdata"
product "VV"
path_grouping_policy multibus
path_checker tur
no_path_retry 60
}
}
The default Oracle VM server networking configuration routes all dom0 and guest traffic through a Xen bridge. A Xen bridge operates
at layer 2 of the OSI model, effectively acting as a layer 2 (L2) switch passing packets to the egress port; it relies on the TCP protocol
for rate control and packet loss.
Table 1 shows the OSI model. Note that Xen bridges operate in layer 2.
Layer Description
7 Application
Layer
6 Presentation
Layer
5 Session Layer
4 Transport
Layer
3 Network
Layer
2 Data Link
Layer
LLC sublayer
MAC sublayer
1 Physical Layer
Oracle VM's default network configuration pairs each network interface (NIC) with a Xen bridge. The Xen bridges are created by
default by the Xen SysV startup script (/etc/init.d/xend). An Oracle VM server with two NICs will have two Xen bridges, eth0/xenbr0
and eth1/xenbr1. The first Xen bridge, eth0/xenbr0, is configured with an IP address on xenbr0 and is dedicated to Oracle VM
management and HA traffic. The second Xen bridge will not have an IP address assigned; it effectively acts as a layer-two switch for
guest traffic. Any Xen bridge, including the ent0/xenbr0 pair, can be used for guest traffic. Guest virtual NICs can be used with any
Xen bridges by editing the guest's vm.cfg file or by editing the guest's network properties using Oracle VM Manager or the Oracle VM
Management Pack.
Tip: In an HA-enabled pool, the loss of network connectivity for the Oracle VM management interface causes an HA event. When an
HA event occurs, an Oracle VM server is fenced from the pool and reboots, then all HA-enabled guests are restarted on a live Oracle
VM pool member.
It's your prerogative how to physically wire your Oracle VM server's NICs. For example, you could wire each NIC into a managed
switch using VLANs to segregate the traffic from each Xen bridge. Another option is to wire your NICs into an unmanaged switch on a
flat network, using the Xen bridges to distribute traffic across the switch.
Figure 1 shows the default Oracle VM Xen bridge configuration: an Oracle VM server with two NICs wired into a single switch,
hosting three guests.
As shown in Figure 1, the default Oracle VM server network configuration will pair eth0 with xenbr0 and use the eth0/xenbr0 pair for
Oracle VM agent, OCFS2 cluster heartbeat, and Live Migration traffic, and pair eth1 with xenbr1. If an Oracle VM server had four or
more NICs, the default configuration would pair eth0 with xenbr0, used for Oracle VM management traffic, and then create additional
Xen bridges, that is, eth1/xenbr1, eth2/xenbr2, eth3/xenbr3, and so on. Any Xen bridge can be used for guest traffic, even
eth0/xenbr0.
In Figure 1, packets that arrive at the physical NIC (eth0) are handled by dom0’s Ethernet driver and appear on xenbr0. Xen bridges
distribute packets like a layer-two switch for dom0 and guests. Xen bridges route guest packets based on the guest's MAC address.
The next example shows the output from “ifconfig” and “brctl show” from an Oracle VM server with two NICs without any guests.
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:7F:35:0A
UP BROADCAST RUNNING MULTICAST MTU:1500
Metric:1
RX packets:17459615 errors:0 dropped:0 overruns:0
frame:0
TX packets:15661870 errors:0 dropped:0 overruns:0
carrier:0
collisions:0 txqueuelen:100
RX bytes:3807333630 (3.5 GiB) TX bytes:3092948689 (2.8
GiB)
Metric:1
RX packets:93673 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:9902147 (9.4 MiB) TX bytes:0 (0.0 b)
The Oracle VM server's dom0 interfaces are managed using native Linux network scripts, for example, /etc/sysconfig/network and
/etc/sysconfig/network-scripts/ifcfg-*. After an Oracle VM Server 2.2 boots, the Xen /etc/xen/xend-config.sxp script (network-script
network-bridge) entry is referenced and creates an independent Xen bridge for each physical NIC. For example, typing "brctl addif
xenbr0 eth0" creates the eth0/xenbr0 pair and typing "brcrtl addif xenbr0 eth1" creates the eth1/xenbr1 pair.
dom0's management interface is selected during the Oracle VM server installation and can be edited after the installation in the
/etc/ovs-config file. From an HA perspective, the NIC used for Oracle VM management traffic is the only network interface that is
monitored for HA events. If HA is a requirement for both the Oracle VM hosts and guests, it’s important to design your Oracle VM
servers with a single bond used by all Xen bridges for dom0 and guests.
The next example shows Oracle VM's default /etc/sysconfig/network-scripts/ifcfg* scripts from an Oracle VM server with two NICs.
# cat /etc/sysconfig/network-scripts/ifcfg*
# Intel Corporation 80003ES2LAN Gigabit Ethernet
Controller (Copper)
DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.4.255
HWADDR=00:30:48:7F:44:6E
IPADDR=192.168.4.7
NETMASK=255.255.255.0
NETWORK=192.168.4.0
ONBOOT=yes
# Intel Corporation 80003ES2LAN Gigabit Ethernet
Controller (Copper)
DEVICE=eth1
BOOTPROTO=static
HWADDR=00:30:48:7F:44:6F
ONBOOT=yes
DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making
127.0.0.0/8 a martian,
# you can change this to something else
(255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback
Note: Oracle VM 2.2 does not use the default Xen.org pseudo devices in dom0, for example, no vif or peth devices are used.
Bonded Oracle VM server's that use the Broadcom NetXtreme II bnx2x driver on hardware with Baseboard Management Controllers
are subject to broadcast storms. The solution to eliminate the broadcast storms is to a) change the network interface driver from the
bnx2x driver to the tg3 driver or b) disable the Baseboard Management Controller's management firmware and/or c) both a and b.
Typing “dmesg|grep Broad” from dom0 will validate if an Oracle VM server is using Broadcom NetXtreme II network interfaces. The
next example shows the result from typing “dmesg|grep Broad” on an Oracle VM server using Broadcom NetXtreme II network
interfaces.
# dmesg |grep Broad
Broadcom NetXtreme II 5771x 10Gigabit Ethernet Driver bnx2x 1.52.12 ($DateTime: 2009/12/17 12:14:50 $)
eth0: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fb000000, IRQ 22, node addr d8d385d91f88
eth1: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fa000000, IRQ 23, node addr d8d385d91f8c
eth2: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem f9000000, IRQ 23, node addr d8d385d91f89
eth3: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem f8000000, IRQ 24, node addr d8d385d91f8d
eth4: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem f7000000, IRQ 24, node addr d8d385d91f8a
eth5: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem f6000000, IRQ 25, node addr d8d385d91f8e
eth6: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem f5000000, IRQ 25, node addr d8d385d91f8b
eth7: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem f4000000, IRQ 22, node addr d8d385d91f8f
Broadcom NetXtreme II CNIC Driver cnic v1.9.13b (Dec 16, 2009)
Broadcom NetXtreme II iSCSI Driver bnx2i v1.8.12f (Jan 19, 2010)
The next example shows an Oracle VM server using the bnx2x network interface driver for eth0 and eth1.
# cat /etc/modprobe.conf
alias eth0 bnx2x
alias eth1 bnx2x
alias scsi_hostadapter lpfc
alias scsi_hostadapter1 usb-storage
alias bond0 bonding options bonding mode=1 miimon=100 downdelay=200 updelay=200 max_bonds=1
To change the network interface driver from bnx2x to tg3, it is necessary to edit dom0's modprob.conf file as shown in the next
example.
# cat /etc/modprobe.conf
alias eth0 tg3
alias eth1 tg3
alias scsi_hostadapter lpfc
alias scsi_hostadapter1 usb-storage
alias bond0 bonding options bonding mode=1 miimon=100 downdelay=200 updelay=200 max_bonds=1
After changing the network interface driver in the modprobe.conf file, restart the network service by typing “service network restart”.
Typing “service network restart” will unload the bnx2x driver and load the tg3 driver.
Broadcom has a DOS utility named xdiag that can be used to disable the Baseboard Management Controller's management firmware
(MF) code. If typing "xdiag -ver" shows MF active" on a controller, it is necessary to type "xdiag -c <controller#> -mfw 0" to disable
the controler. xdiag can be downloaded as a stand alone application or as a bootable ISO.
The next example shows how to disable a Baseboard Management Controller's management firmware using a bootable ISO that
contains xdiag.
>cd nx2
>uxdiag -c 1 -mfw 0
>uxdiag -c 2 -mfw 0
Guest networking is configured in each guest's vm.cfg file in the “vif” and “vif_other_config” directives. Each guest will have a unique
vm.cfg file, located in the storage repository, for example, the /var/ovs/mount/<UUID>/running_pool/<VIRTUAL MACHINE NAME>
directory. The next example shows a vm.cfg file from the Oracle VM 11g template. The “vif” and “vif_other_config” directives are
highlighted.
bootloader = '/usr/bin/pygrub'
disk = ['file:/OVS/running_pool/v52x8611g1
/System.img,xvda,w',
'file:/OVS/running_pool/v52x8611g1
/oracle11g_x86_asm.img,xvdb,w',
]
memory = '2048'
name = 'v52x8611g1'
on_crash = 'restart'
on_reboot = 'restart'
uuid = 'f8725f79-c6c8-26d4-a51e-1f32cf010c84'
vcpus = 2
vif =
['bridge=xenbr0,mac=00:16:3E:56:20:63,type=netfront']
vif_other_config = []
In the above example, the settings in the “vif” directive show that:
The “vif_other_config” directive is empty, indicating that there is not an Oracle VM Manager network policy. A guest with the proper
“vif” and OS networking setup will appear on the network from the assigned Xen bridge in the guest's vm.cfg file.
Tip: To generate a unique MAC address for a guest, type the following text while logged in as root:
PYTHONPATH=/opt/ovs-agent-2.2 python -c "from OVSCommons import randomMAC; print randomMAC()"
The next example shows the output from “ifconfig” and “brctl show” from an Oracle VM server with two NICs hosting three guests;
each guest has a single NIC.
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:7F:45:AE
UP BROADCAST RUNNING MULTICAST MTU:1500
Metric:1
RX packets:496976 errors:0 dropped:0 overruns:0 frame:0
TX packets:424315 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:78403808 (74.7 MiB) TX bytes:72492155 (69.1
MiB)
# brctl show
bridge name bridge id STP enabled interfaces
xenbr0 8000.0030487f45ae no vif2.0
eth0
xenbr1 8000.0030487f45af no vif4.0
vif3.0
eth1
The output from “ifconfig” in the above example shows eth0, eth1, lo, vif2.0, vif3.0, vif4.0, xenbr0, and xenbr1. vif2.0, vif3.0, vif4.0 are
the guest virtual NICs. Next, the output from “brctl show” shows the bridge configurations, that is, xenbr0 is connected to vif2.0 and
eth0, and xenbr1 is connected to vif3.0, vif4.0, and eth1.
Figure 1 shows the default Oracle VM Xen bridge configuration, with an Oracle VM server with two NICs wired into a single
unmanaged switch. The Oracle VM server is hosting three guests that use xennbr1; xenbr0 is dedicated to management traffic.
In Figure 1, the Oracle VM management traffic and HA monitoring are isolated to the eth0/xenbr0 interface and the loss of network
connectivity for eth0/xenbr0 will cause an HA event. If the eth1/xenbr1 interface looses connectivity and all the guests are dropped
from the network, an HA event will not occur.
Figure 2 shows the default Oracle VM Xen bridge configuration with a two-server Oracle VM pool. Each Oracle VM server has two
NICs wired in to a single unmanaged switch. The Oracle VM server is hosting three guests that use xenbr1; xenbr0 is dedicated to
management traffic.
In Figure 2, the Oracle VM management traffic and HA monitoring are isolated to eth0/xenbr0 and the loss of network connectivity for
eth0/xenbr0 will cause an HA event. If the eth1/xenbr1 interface loses connectivity and all the guests are dropped from the network
an HA event will not occur.
Figure 3 shows an 802.3AD NIC bonding configuration with one Xen bridge on bond1.
The Oracle VM server in Figure 3 has four NICs configured with two bonds, bond0 and bond1. Each NIC from each bond is wired into
a separate switch for high availability. The Oracle VM server is hosting three guests using xenbr1; bond0 and eth0:0 are dedicated to
management traffic.
Tip: If a bond is dedicated for dom0 management traffic it is not necessary to configure a Xen bridge for dom0; a Xen bridge is only a
requirement for guests to access the network.
In Figure 3, the Oracle VM management traffic and HA monitoring are isolated to bond0 and the eth0:0 interface and the loss of
network connectivity for bond0 or the eth0:0 interface would cause an HA event. If the bond1/xenbr1 interface loses connectivity and
all the guests are dropped from the network, an HA event will not occur.
Figure 4 shows an 802.3AD NIC bonding configurations with one Xen bridge with a two-server Oracle VM pool.
Each Oracle VM server in Figure 4 has four NICs configured with two bonds, bond0 and bond1. Each NIC from each bond is wired
into a separate switch for high availability. Each Oracle VM server is hosting three guests that use xenbr1; bond0 and eth0:0 are
dedicated to management traffic.
In Figure 4 the Oracle VM management traffic and HA monitoring are isolated to bond0 and the eth0:0 interface and the loss of
network connectivity for bond0 or the eth0:0 interface would cause an HA event. If the bond1/xenbr1 interface loses connectivity and
all the guests are dropped from the network, an HA event will not occur.
The Oracle VM server in Figure 5 has four NICs configured with one bond, bond0. Each NIC from each bond is wired into a separate
switch for high availability. The Oracle VM server is hosting three guests that use vlan2, vlan3, and vlan4; vlan1 is dedicated to
management traffic.
Note: In Figure 5 vlan1, vlan2, vlan3 and vlan4 are Xen bridges. Xen bridges can have discriptive names, i.e. vlanX, xenbrX, etc...
In Figure 5, the Oracle VM management traffic and HA monitoring are isolated to the bond0:1 interface over vlan1. If dom0 loses
network connectivity due to bond0, bond0:1 or vlan1 an HA event would occur causing the Oracle VM server to fence from the pool
and reboot, all HA-enabled guests would restart on a live Oracle VM pool member.
Figure 6 shows an 802.3AD NIC bonding configurations with a two-server Oracle VM pool that uses Xen bridges with 802.1Q VLAN
and VLAN tagging.
Each Oracle VM server in Figure 5 has four NICs configured with one bond, bond0. Each NIC from each bond is wired into a separate
switch for high availability. Each Oracle VM server is hosting three guests that use vlan2, vlan3, and vlan4, respectively; vlan1 is
dedicated to management traffic. The loss of network connectivity with the bond0 interface would cause an HA event that fences the
Oracle VM server and reboots it, and restart all HA-enabled guests on a live Oracle VM pool member.
Figure 7 shows an example configuration with NIC bonding using a single Xen bridge.
The example configuration will create a bond with two NICs, one interface and one Xen bridge, used by dom0 and guests. After
configuring the bonding interface, dom0 will have the following interfaces:
Note: This example configuration provides HA for both dom0 and the guests if the Oracle VM server loses network connectivity.
Step 1: Disable the default xend network configuration. From dom0 type the following commands while logged in as root to disable
the xend network configuration:
# cd /etc/xen/scripts/
# ./network-bridges
stop
Step 2: Create a file in the /etc/xen/scripts directory named “network-bridge-ovs” that contains the following lines:
#!/bin/sh
/bin/true
For example, from dom0 while logged in as root type “vi /etc/xen/scripts/network-bridge-ovs” to create a file named network-
bridge-ovs, then enter the text in the next example:
#!/bin/sh
/bin/true
Step 3: Make the etc/xen/scripts/network-bridge-ovs file executable by typing the text in the next example.
Step 5: Edit /etc/modprobe.conf and load and configure the bonding modules. For example:
Change the <DriverName> to the correct driver for your NICs, for example, tg3, e1000, or the like.
We have done extensive testing with the various bonding modes and suggest mode 1 for all Oracle VM configurations. For example,
the existing 2.6.18 kernel has known issues with mode 4 and 6.
Note: Please review Bonding with LACP does not work if your testing mode 4. Consider testing the "xmit_hash_policy=layer2+3"
setting in the above modprobe.conf file. Adding the "xmit_hash_policy=layer2+3" setting in the modprobe.conf file may help spread
the load between the NICs in the bond and provide better throughput.
To list the NIC drivers, try one of the following commands from dom0 while logged in as root:
To configure the eth0 and eth1 interfaces, edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file as follows:
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
HWADDR=<YOUR MAC ADDRESS>
For /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
HWADDR=<YOUR MAC ADDRESS>
The HWADDR parameter is the pointer to the NIC's MAC address. The SLAVE parameter defines the network card as a slave of a
bond-device, in this case bond0. The MASTER parameter points to the actual bonding device that this network interface will be part
of.
Next, create the bonding device bond0 by creating a file named /etc/sysconfig/network-scripts/ifcfg-bond0, containing the following
lines:
DEVICE=bond0
ONBOOT=yes
BRIDGE=xenbr0
USERCTL=no
The next example shows how to create and save a file named /etc/sysconfig/network-scripts/ifcfg-bond0 with the bond device
parameters.
# vi /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
ONBOOT=yes
BRIDGE=xenbr0
USERCTL=no
:wq!
The BRIDGE parameter specifies that the bond interface does not have an IP address, but will be connected to bridge xenbr0.
Next, create the Xen bridge by creating a file named /etc/sysconfig/network-scripts/ifcfg-xenbr0 containing the following lines:
DEVICE=xenbr0
ONBOOT=yes
STP=off
USERCTL=no
IPADDR=<YOUR IP ADDRESS>
NETMASK=<YOUR NETMASK>
The next example shows how to create and save a file named ifcfg-xenbr0 that contains the Xen bridge parameters.
# vi /etc/sysconfig/network-scripts/ifcfg-xenbr0
DEVICE=xenbr0
ONBOOT=yes
STP=off
USERCTL=no
IPADDR=<YOUR IP ADDRESS>
NETMASK=<YOUR NETMASK>
:wq!
An IP address is assigned to xenbr0 using the IPADDR and NETMASK lines. The NETWORK and BROADCAST parameters are
deprecated and are automatically calculated with ipcalc.
Step 5: Restart the network and xend services from dom0 by typing “service network restart” followed by “service xend restart,” as
shown in the next example:
To validate the configurations, from dom0 type “ifconfig” to list the interfaces and the Xen bridges, as shown in the next example.
# brctl show
bridge name bridge id STP enabled interfaces
xenbr0 8000.0015172d8a91 no bond0
The output for “brctl show” lists the bridge name, bridge ID, spanning-tree protocol (STP) configuration, and the configured
interfaces.
The next example shows a vm.cfg file from a guest that is configured to use xenbr0.
bootloader = '/usr/bin/pygrub'
disk = ['file:/OVS/running_pool/v52x8611g1
/System.img,xvda,w',
'file:/OVS/running_pool/v52x8611g1
/oracle11g_x86_asm.img,xvdb,w',
]
memory = '2048'
name = 'v52x8611g1'
on_crash = 'restart'
on_reboot = 'restart'
uuid = 'f8725f79-c6c8-26d4-a51e-1f32cf010c84'
vcpus = 2
vif =
['bridge=xenbr0,mac=00:16:3E:56:20:63,type=netfront']
vif_other_config = []
Tip: All Oracle VM servers using bonded interfaces should modify two default O2CB heartbeat configurations to allow a bond fail-over
event to occur without the Oracle VM server fencing from the pool. Edit the /etc/sysconfig/o2cb file using your favorite text editor and
change "O2CB_HEARTBEAT_THRESHOLD=" to "O2CB_HEARTBEAT_THRESHOLD= 61" and "O2CB_IDLE_TIMEOUT_MS=" to
"O2CB_IDLE_TIMEOUT_MS= 60000". The next example shows the suggested modifications made to a /etc/sysconfig/o2cb file.
# vi /etc/sysconfig/o2cb
#
# This is a configuration file for automatic startup of the O2CB
# driver. It is generated by running /etc/init.d/o2cb configure.
# Please use that method to modify this file
#
# O2CB_ENABELED: 'true' means to load the driver on boot.
O2CB_ENABLED=true
# O2CB_BOOTCLUSTER: If not empty, the name of a cluster to start.
O2CB_BOOTCLUSTER=rmvsx
# O2CB_HEARTBEAT_THRESHOLD: Iterations before a node is considered dead.
O2CB_HEARTBEAT_THRESHOLD= 61
# O2CB_IDLE_TIMEOUT_MS: Time in ms before a network connection is considered dead.
O2CB_IDLE_TIMEOUT_MS= 60000
# O2CB_KEEPALIVE_DELAY_MS: Max time in ms before a keepalive packet is sent
O2CB_KEEPALIVE_DELAY_MS=
Figure 8 shows an example 802.3AD NIC bonding and Xen bridges with 802.1Q VLANning.
The example configuration will have an 802.3AD bond with two NICs with one interface using four Xen bridges. After the bonding
interface is configured, dom0 will have the following interfaces:
The example configuration offers HA for both dom0 and the guest Xen bridges if the Oracle VM server loses network connectivity.
Note: Please note that the :XX part of the interface name, that is, bond0:1, bond0:2, bond0:3, bond0:4, is referencing VLAN 1, 2, 3,
and 4, respectively.
Step 1: Disable the default xend network configuration. From dom0 type the following commands while logged in as root to disable
the xend network configuration:
# cd /etc/xen/scripts/
# ./network-bridges
stop
Step 2: Create a file in the /etc/xen/scripts directory named “network-bridge-ovs” that contains the lines:
#!/bin/sh
/bin/true
For example, from dom0 while logged in as root type “vi /etc/xen/scripts/network-bridge-ovs” to create a file named network-
bridge-ovs, then enter the text in the next example.
#vi /etc/xen/scripts/network-
bridge-ovs
#!/bin/sh
/bin/true
:wq!
Step 3: Make the etc/xen/scripts/network-bridge-ovs file executable by typing the text in the next example.
Step 5: Edit /etc/modprobe.conf and load and configure the bonding modules. For example:
Change the <DriverName> to the correct driver for your NICs, for example, tg3, e1000, or the like.
Note: Please review Bonding with LACP does not work and consider testing the "xmit_hash_policy=layer2+3" setting in the above modprobe.conf file.
Adding the "xmit_hash_policy=layer2+3" setting in the modprobe.conf file may help spread the load between the NICs in the bond and provide better
throughput.
To list the NIC drivers, use one of the following commands from dom0 while logged in as root.
To configure the eth0 and eth1 interfaces, edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file as follows:
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
HWADDR=<YOUR MAC ADDRESS>
For /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
HWADDR=<YOUR MAC ADDRESS>
The HWADDR parameter is the pointer to the NIC's MAC address. The SLAVE parameter defines the network card as a slave of a
bond-device, in this case, bond0. The MASTER parameter points to the actual bonding device that this network interface will be part
of.
Next, create the bonding device bond0 by creating a file named /etc/sysconfig/network-scripts/ifcfg-bond0 containing the following
lines:
DEVICE=bond0
ONBOOT=yes
USERCTL=no
The next example shows how to create and save a file named /etc/sysconfig/network-scripts/ifcfg-bond0 with the bond-device
parameters.
# vi /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
ONBOOT=yes
USERCTL=no
:wq!
Next, create the interfaces by making a file for each interface named /etc/sysconfig/network-scripts/ifcfg-<INTERFACE NAME>. The
following examples show four interface files.
Note: Any descriptive name can be used for the interface and Xen bridge. You can create as many interfaces and Xen bridges as
needed for your environment.
The next example is the file for the bond0:1 interface that uses vlan1.
DEVICE=bond0:1
ONBOOT=yes
BOOTPROTO=none
VLAN=yes
TYPE=Ethernet
BRIDGE=vlan1
The next example is the file for the bond0:2 interface that uses vlan2.
DEVICE=bond0:2
ONBOOT=yes
BOOTPROTO=none
VLAN=yes
TYPE=Ethernet
BRIDGE=vlan2
The next example is the file for the bond0:3 interface that uses vlan3.
DEVICE=bond0:3
ONBOOT=yes
BOOTPROTO=none
VLAN=yes
TYPE=Ethernet
BRIDGE=vlan3
The next example is the file for the bond0:4 interface that uses vlan4.
DEVICE=bond0:4
ONBOOT=yes
BOOTPROTO=none
VLAN=yes
TYPE=Ethernet
BRIDGE=vlan4
Next, create the Xen bridges by making a file for each Xen bridge, named /etc/sysconfig/network-scripts/ifcfg-<XEN BRIDGE NAME>.
The following examples show four Xen bridge files.
The next example is the file for the vlan1 that is used by bond0:1.
DEVICE=vlan1
BOOTPROTO=static
ONBOOT=yes
IPADDR=<YOUR IP ADDRESS FOR DOM0>
NETMASK=<YOUR NETMASK FOR DOM0>
An IP address is assigned to xenbr11 using the IPADDR and NETMASK sections. The NETWORK and BROADCAST parameters are
deprecated and are automatically calculated with ipcalc.
The next example is the file for the vlan2 that is used by bond0:2.
DEVICE=vlan2
BOOTPROTO=none
ONBOOT=yes
Type=Bridge
The next example is the file for the vlan3 that is used by bond0:3.
DEVICE=vlan3
BOOTPROTO=none
ONBOOT=yes
Type=Bridge
The next example is the file for the vlan4 that is used by bond0:4.
DEVICE=vlan4
BOOTPROTO=none
ONBOOT=yes
Type=Bridge
The next example shows how to create and save a file named ifcfg-vlan2 that contains the Xen bridge parameters.
# vi /etc/sysconfig/network-scripts/ifcfg-vlan2
DEVICE=vlan2
BOOTPROTO=none
ONBOOT=yes
Type=Bridge
:wq!
Step 5: Restart the network and xend services from dom0 by typing “service network restart” followed by “service xend restart” as
shown in the next example.
To validate the configurations, from dom0 type “ifconfig” to list the interfaces and the Xen bridges, as shown in the next example.
# brctl show
bridge name bridge id STP enabled interfaces
vlan1 8000.0015172d8a91 no bond0:1
vlan2 8000.0015172d8a91 no bond0:2
vlan3 8000.0015172d8a91 no bond0:3
vlan4 8000.0015172d8a91 no bond0:4
The output for “brctl show” lists the bridge name, bridge ID, spanning-tree protocol (STP) configuration and the configured
interfaces.
Tip: All Oracle VM servers using bonded interfaces should modify two default O2CB heartbeat configurations to allow a bond fail-over
event to occur without the Oracle VM server fencing from the pool. Edit the /etc/sysconfig/o2cb file using your favorite text editor and
change "O2CB_HEARTBEAT_THRESHOLD=" to "O2CB_HEARTBEAT_THRESHOLD= 61" and "O2CB_IDLE_TIMEOUT_MS=" to
"O2CB_IDLE_TIMEOUT_MS= 60000". The next example shows the suggested modifications made to a /etc/sysconfig/o2cb file.
# vi /etc/sysconfig/o2cb
#
# This is a configuration file for automatic startup of the O2CB
# driver. It is generated by running /etc/init.d/o2cb configure.
# Please use that method to modify this file
#
# O2CB_ENABELED: 'true' means to load the driver on boot.
O2CB_ENABLED=true
# O2CB_BOOTCLUSTER: If not empty, the name of a cluster to start.
O2CB_BOOTCLUSTER=rmvsx
# O2CB_HEARTBEAT_THRESHOLD: Iterations before a node is considered dead.
O2CB_HEARTBEAT_THRESHOLD= 61
# O2CB_IDLE_TIMEOUT_MS: Time in ms before a network connection is considered dead.
O2CB_IDLE_TIMEOUT_MS= 60000
# O2CB_KEEPALIVE_DELAY_MS: Max time in ms before a keepalive packet is sent
O2CB_KEEPALIVE_DELAY_MS=
Watch this space
Oracle OpenWorld 2011 Call for Papers - Submit Today!
Temporary Post Used For Theme Detection (409fc5e9-d7ee-4e1a-b645-8b82f256f434 - 3bfe001a-32de-4114-a6b4-4005b770f6d7)
Debugging Oracle VM 2.2 & Oracle VM Manager 2.2 errors using the many log files
New VDI Training Course now available!
HIMSS 2011 and New Press Release
Oracle Desktop Virtualization at HIMSS 2011
Oracle VM VirtualBox 4.0.4 Released!
Two Virtualization Webinars This Week
We're Hiring! - Server and Desktop Virtualization Product Management
Show a printer friendly version of this book with its sub pages
This chapter will review how to rapidly deploy a virtualized Oracle 10g/11g Database using Oracle VM Templates with Oracle VM Manager.
Note: As of this writing, the Oracle 10g/11g Database Oracle VM Templates will not boot on an Oracle VM server with more than 60 G or RAM. Oracle VM templates
using Oracle Linux 5.3 and below ship with a known kernel bug that will not allow the Oracle VM template to boot on an Oracle VM server with more than 60 G or
RAM. If your Oracle VM server has more than 60 G of RAM and an Oracle VM template will not boot, edit the grub.conf file on the Oracle VM server to add the
memory parameter to kernel line that loads the Xen hypervisor, i.e.
kernel /xen-64bit.gz dom0_mem=1024M mem=50G
After adding the mem=50G entry, reboot the Oracle VM server. With the addition of the mem=50G entry, the Oracle VM template will be able to boot on the Oracle
VM server. Once the Oracle VM template is running, patch the kernel to resolve the kernel bug, and then remove the the mem=50G entry on the Oracle VM server.
The use of Oracle VM Templates for the deployment of applications in Oracle VM guest virtual machines eliminates the need for a user to install and configure the
operating system or applications. The virtual machines created using Oracle VM Templates can be started either from the Oracle VM Manager or the Oracle VM
Management Pack (an Oracle Enterprise Manager plug-in).
Oracle VM Templates include a free download and free trial license with the option to purchase a product license. Oracle VM Templates do not have time limits or
feature limitations, e.g. Oracle VM Templates are full featured and do not have expiration dates. Oracle VM Templates can be quickly transitioned from evaluation
into production by purchasing Oracle technology licenses.
Oracle Applications
E-Business Suite 12.1.3
E-Business Suite 12.1.1
E-Business Suite 12.X Sparse Middle Tier
JD Edwards EnterpriseOne 9.0 Update 1 with ESUs and JD Edwards EnterpriseOne Tools 8.98 Update 3
JD Edwards EnterpriseOne 9.0 Update 1 and JD Edwards EnterpriseOneTools 8.98 Update 2
PeopleSoft ELM 9.1 Bundle #2 with PeopleTools 8.50.09
PeopleSoft FSCM 9.1 Bundle #4 (includes Maintenance Pack 2) with PeopleTools 8.50.10
PeopleSoft CRM 9.1 Bundle #2 with PeopleTools 8.50.09
PeopleSoft Portal Solutions 9.1 and PeopleTools 8.50.09
PeopleSoft HCM 9.1 and PeopleTools 8.50.02
Siebel CRM SIA 8.1.1
Siebel CRM SIA 8.0
Oracle Middleware
Oracle WebLogic Server on JRockit Virtual Edition 11g R1 (10.3.2)
Oracle WebLogic Server 10g Release 3
Oracle Business Intelligence Enterprise Edition 10.1.3.4
Oracle Application Server 10g Release 3 WebCenter
Oracle Identity Management 10g Release 2
Oracle Fusion Middleware Service Oriented Architecture (SOA) 10.1.3.4 and 10.1.3.3
Oracle Solaris 10
Note: The Oracle VM Templates are only available from the Linux Oracle eDelivery site at http://edelivery.oracle.com/linux. The
Oracle VM templates are not available from the root http://edelivery.oracle.com/ eDelivery URL.
b) Complete the Registration form, accept the license agreement and the export agreement. Next, click the Continue button to
proceed to the Search page.
Figure 2
c) From the Media Pack Search page you can select the a) Oracle VM Templates b) Enterprise Linux c) Oracle VM search
options.
Figure 3
Select the Oracle VM Templates search option from the Select a Product Pack drop down list. Next, select ether x86 32 bit or the
x86 64 option from the Platform drop down list. Click the Go button to proceed to the Oracle VM Templates Media Pack
Search page.
Figure 4
d) From the Media Pack Search page, locate and click on the desired Oracle VM Template link.
Figure 5
d) Review the Oracle VM Templates on the desired <Oracle VM Template Name> Media Pack Download pages and select and
download the zip files.
Figure 6 shows the Oracle VM Template for Oracle Database Media Pack Download page. To download the Oracle Database
Media Pack, select and download both files.
e) Next, click the Readme button and review the Readme for the Oracle VM Template template.
f) Once the Oracle VM template files have been downloaded, copy the zip files to your Oracle VM server's /OVS/running_pool directory
or the /OVS/seed_pool directory. Next, unzip and untar the files in the directory.
Note: Use the running_pool directory if you would like to deploy the Oracle VM template as a running virtual machine. Use the
seed_pool directory if you would like to deploy the Oracle VM template as a reusable template that can be re-deployed an unlimited
number of times.
Watch this space
Oracle OpenWorld 2011 Call for Papers - Submit Today!
Temporary Post Used For Theme Detection (409fc5e9-d7ee-4e1a-b645-8b82f256f434 - 3bfe001a-32de-4114-a6b4-4005b770f6d7)
Debugging Oracle VM 2.2 & Oracle VM Manager 2.2 errors using the many log files
New VDI Training Course now available!
HIMSS 2011 and New Press Release
Oracle Desktop Virtualization at HIMSS 2011
Oracle VM VirtualBox 4.0.4 Released!
Two Virtualization Webinars This Week
We're Hiring! - Server and Desktop Virtualization Product Management
a) Access the Oracle VM Manager GUI by typing the Oracle VM Manager URL in your browser. Enter your username and password
in to the Username and Password text boxes. Then, press the Login button to authenticate to access the Oracle VM Manager GUI.
Figure 1
b) From the Virtual Machines home page click the Resources tab. From the Resources tab click the Virtual Machine Image link. From the Virtual
Machine Images page click the Import Button.
Note: The example assumes that the Oracle Database 11g template has been unzipped and untarred in the /OVS/running_pool directory. If the Oracle
database 11g template was unzipped and untarred in the /OVS/seed_pool directory, click the Virtual Machine Templates tab to import the template.
Figure 2
d) From the Source page select the Select from Server Pool (Discover and register) radio button and click Next to proceed.
Note: The Select from Server Pool (Discover and register) requires that the Oracle Database 11g template has been staged, i.e. unzipped
and untarred in the /OVS/running_pool directory.
Figure 3
d) From the General Information page complete the form for the Oracle VM 11g Template's properties. Once all the data is complete click Next to
proceed.
Figure 4
f) From the Virtual Machine Images page click the Refresh button. The status will change from Importing to Pending. Next, click
the Approve button.
Figure 6
g) From the View Imported Virtual Machine page click the Approve button.
Figure 7
h) After the Virtual Machine Image is approved click the Virtual Machines tab. From the Virtual Machines page you will see the Oracle Database 11g
template in the list of Virtual Machines in the Powered Off status.
Figure 8
The Select and feature allow you to Power On, access the virtual machine's Console, Power Off, and Configure a virtual machine's properties, i.e.
resource allocations and policies.
The More Actions drop down list offers the following virtual machine administrative features: Deploy, Live Migration, Clone, Save as Template, Pause,
Unpause, Suspend, Resume, Delete and Reset.
a) From the Virtual Machine page start your virtual machine by pressing the Power On button. The virtual machine status will change from Powered
Off to Initializing to Running.
Figure 1
b) Once the status is Running click the Console button to access the virtual machine's console.
Note: If you receive any Java Warnings, click the Always trust content from the publisher check box and click Run.
c) Enter the VNC Authentication Password in the Password text box and click the OK button to access the virtual machine's console.
Figure 2
d) When a virtual machine created from Oracle Database template boots up for the first time, the boot up process gathers database configuration
information from the user and configures the database automatically, please follow the prompts in the Oracle VM Manager virtual machine VNC console
to complete the process.
1) System configuration
User will be asked if a static IP address should be configured. Answer no “y” to use DHCP.
Configuring network for Oracle Database.
Current network is using DHCP. Using static IP address is recommended.
Use DHCP? y/n [n]
Configuring static IP.
Starting network...
ORACLE_HOME= /u01/app/oracle/product/11.1.0/db_1
Enter the full pathname of the local bin directory: [/usr/local/bin]:
Copying dbhome to /usr/local/bin ...
Copying oraenv to /usr/local/bin ...
Copying coraenv to /usr/local/bin ...
Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
Finished product-specific root actions.
Starting CSS.
Starting Oracle Net Listener...Done
ASM instance started
ORACLE instance started.
Configuration Completed Successfully.
To access the Oracle Application Express go to
"http://myhost.mydomain.com:8080/apex"
d) The Oracle Database 11g Template is configured, on the network and 100% operational. The virtual machine is accessible via ssh using the IP address
select during the configuration process with the default user name root and the default root password ovsroot. The virtual machine's console can be
accessed using the console password that was selected during the configuration process using the console button in Oracle VM Manager.
Notes:
1. The system image contains a minimal install of Oracle Linux. Only basic RPM packages are installed.
1. The default root password is 'ovsroot'.
2. A database instance 'orcl' is created in the templates.
1. The database user is named “oracle” and belongs to groups 'orainstall' and 'dba'. The password is 'oracle'.
2. The oracle-validated package is installed. This package verifies and sets system parameters based on Oracle validated configuration
recommendations for Oracle Enterprise Linux.
3. The database storage is managed by Automatic Storage Management (ASM). Two ASM disks 'VOL1' and 'VOL2' are created, and the default
ASM group name is 'DATA'.
The Oracle Enterprise Manager 10g Oracle VM template allows customers to quickly deploy Oracle Enterprise Manager 10g/11g
using Oracle VM Manager.
The Oracle Enterprise Manager 10g template is comprised of a virtual machine assembly with two pre-configured virtual machines.
Both virtual machines use Oracle Enterprise Linux 4 update 5. The first virtual machine hosts the Oracle Management Service (OMS)
and an optional YUM repository. The second virtual machine hosts the Oracle Management Repository (OMR). Each virtual machine
was created with Oracle best practices, which reduce deployment risk and dramatically shortens deployment timelines. Oracle VM
templates are freely available from http://edelivery.oracle.com/linux.
The Oracle Enterprise Manager 10g Oracle VM template is downloaded as two sets of compressed files (14.81 GB total)
from http://edelivery.oracle.com/linux. The first set of four files (5.69 GB) is named “Oracle VM Enterprise Manager Grid Control
Template for Oracle VM” and the second set of five files (9.12 GB) is named “Yum Repository of Oracle Enterprise Linux 4 and 5 for
use with Enterprise Manager Grid Control Template”. The second set of files for the Yum repository is optional.
Figure 1 shows how the Oracle Enterprise Manager 10g Oracle VM template is deployed in to an Oracle VM server farm.
System Requirements
A minimum of one physical servers is required for the Oracle VM Enterprise Manager Grid Control Template.
Oracle VM Server:
Oracle VM Server requires one bare-metal server capable of running at least three virtual machines simultaneously. The
recommended minimum hardware requirements for an Oracle VM Server are:
4 CPUs
4 GB RAM
80 GB disk space without the Yum repository
100 GB disk space with the Yum repository
The Oracle Management Service and the Yum repository Virtual Machine:
2 Virtual CPUs (virtual machine)
2 GB RAM (virtual machine)
16 GB disk space in /OVS/seed_pool/ (virtual machine template storage)
72 GB disk space in /OVS/running_pool/ (virtual machine storage)
Step 1 will require a visit to http://edelivery.oracle.com/linux to register, search for and to download the Oracle VM Enterprise
Manager Grid Control Template.
1. Point a web browser to http://edelivery.oracle.com/linux as show in Figure 2 click the Continue button to proceed.
2. From the Registration page enter a Full Name, Company Name, Email Address, select a Country from the drop down box,
accept the Agreement Terms by selecting the Agreement Terms check box, accept the Export Restrictions by selecting the
Export Restrictions check box and click Continue to proceed.
3. From the Media Pack Search page, select Oracle VM Templates from the Select a Product Pack drop down menu. Then select
x86 32 bit from the Platform drop down menu and click the Go button to proceed as shown in Figure 4.
4. As shown in Figure 5, from the Media Pack Search results page select the Oracle VM Enterprise Manager Grid Control
Template for Oracle VM radio button and click the Continue button to proceed to the Oracle VM Grid Control Template 1.0
Media Pack for x86 (32 bit) download page.
5. From the Oracle VM Grid Control Template 1.0 Media Pack for x86 (32 bit) download page click the Download button next
to each part of compressed files (14.81 GB total) to start the download.
Figure 6 shows the Oracle VM Grid Control Template 1.0 Media Pack for x86 (32 bit) download page.
In Step 1 we downloaded two sets of files, the first set of files has both the OMR and OMS file set and the second file set is the Yum
repository.
List 1 shows the compressed 5.69 GB OMR/OMS file set.
V13510-01_1of4.zip
V13510-01_2of4.zip
V13510-01_3of4.zip
V13510-01_4of4.zip
V13511-01_1of5.zip
V13511-01_2of5.zip
V13511-01_3of5.zip
V13511-01_4of5.zip
V13511-01_5of5.zip
In Step 2 we will run through the procedure to unzip and concatenate both files sets in the /OVS/seed_pool directory as well as to add
the yum.img file in the OMS vm.cfg file.
Note: The procedure is identical with a local Oracle VM OVS repository or a centralized Oracle VM OVS repository.
1. Place the zip template files in the /OVS/seed_pool directory as shown in the example:
/OVS/seed_pool/V13510-01_1of4.zip
/OVS/seed_pool/V13510-01_2of4.zip
/OVS/seed_pool/V13510-01_3of4.zip
/OVS/seed_pool/V13510-01_4of4.zip
/OVS/seed_pool/V13511-01_1of5.zip
/OVS/seed_pool/V13511-01_2of5.zip
/OVS/seed_pool/V13511-01_3of5.zip
/OVS/seed_pool/V13511-01_4of5.zip
/OVS/seed_pool/V13511-01_5of5.zip
2. From the Oracle VM Server console login as root and unzip the files using the unzip command as shown in the following example.
# unzip 'V*.zip'
Archive: V13510-01_1of4.zip
inflating: GC_Container.tar.gz.1of4
Archive: V13510-01_2of4.zip
inflating: GC_Container.tar.gz.2of4
Archive: V13510-01_3of4.zip
inflating: GC_Container.tar.gz.3of4
Archive: V13510-01_4of4.zip
inflating: GC_Container.tar.gz.4of4
Archive: V13511-01_1of5.zip
inflating: yum.tar.gz.1of5
Archive: V13511-01_2of5.zip
inflating: yum.tar.gz.2of5
Archive: V13511-01_3of5.zip
inflating: yum.tar.gz.3of5
Archive: V13511-01_4of5.zip
inflating: yum.tar.gz.4of5
Archive: V13511-01_5of5.zip
inflating: yum.tar.gz.5of5
Unzipping all of the file sets will generate the following tar files:
/OVS/seed_pool/GC_Container.tar.gz.1of4
/OVS/seed_pool/GC_Container.tar.gz.2of4
/OVS/seed_pool/GC_Container.tar.gz.3of4
/OVS/seed_pool/GC_Container.tar.gz.4of4
/OVS/seed_pool/yum.tar.gz.1of5
/OVS/seed_pool/yum.tar.gz.2of5
/OVS/seed_pool/yum.tar.gz.3of5
/OVS/seed_pool/yum.tar.gz.4of5
/OVS/seed_pool/yum.tar.gz.5of5
3. Next we will concatenate the OMR/OMS file set. The next example shows how to concatenate the OMR/OMS file set.
4. Next we will concatenate the Yum repository file set. The next example shows how to concatenate the Yum repository file set.
The yum.img file contains a Yum repository populated with the full Linux distribution RPMs for:
5. The final step is to add the yum.img virtual disk to the OMS virtual machine. We will modify the /OVS/seed_pool/GC_TEMPLATE
/vm.cfg file to include the Yum repository virtual disk. The next example shows the default unmodified OMS vm.cfg file.
In Step 2 we walked through the procedure to unzip and concatenate both files sets and we added an entry for the yum.img file in the
OMS vm.cfg file. In Step 3 we will use Oracle VM Manager to create an OMR and OMS virtual machine template.
1. Login to Oracle VM Manager. Enter the desired user name and password and click the Login button to proceed as shown in
Figure 7.
2. From the Virtual Machine home page click the Resources tab to access the Virtual Machine Template page. From the Virtual
Machine Template page click the Import button to start the importation process.
3. From the Source page select the Select from Server Pool (Discover and register) radio button and click Next as shown in
Figure 9.
4. From the General Information page we need to enter the following data:
a. Select the desired server pool from the Server Pool Name drop down list.
b. Select the CG_DB_Template from the Virtual Machine Template Name drop down list.
c. Enable High Availability check box if desired, HA will need to be setup in advance to enable HA.
d. Select Oracle Enterprise Linux 4 from the Operating System drop down list.
e. Enter root in the Virtual Machine User Name text box.
f. Enter ovsroot in the Virtual Machine Password text box.
g. Enter a Description for the virtual machine (optional)
h. Click Next to proceed to the Confirmation page.
5. From the Confirm Information page click the Confirm button to proceed.
Figure 11 shows the Confirm Information page.
6. We have successfully created the CG_DB_Template virtual machine template, which is in a pending status. Templates that are in the
pending status are not available to Oracle VM Manager users until they have been approved. Next we will approve the
CG_DB_Template by selecting the CG_DB_Template and clicking the Approve button as shown in Figure 12.
7. From the Virtual Machine Templates page click the Approve button to approve the template as shown in Figure 13.
8. The CG_DB_Template has been successfully approved and its Status has changed to Active as shown in Figure 14.
1. From the Virtual Machine home page click the Resources Tab to access the Virtual Machine Template page. From the Virtual
Machine Template page click the Import button to start the importation process.
2. From the Source page select the Select from Server Pool (Discover and register) radio button and click Next as shown in
Figure 16 to proceed.
3. From the General Information page we need to enter the following data:
a. Select the desired server pool from the Server Pool Name drop down list.
b. Select the CG_Template from the Virtual Machine Template Name drop down list.
c. Select the Enable High Availability check box if desired. HA will need to be setup in advance to enable HA.
d. Select Oracle Enterprise Linux 4 from the Operating System drop down list.
e. Enter root in the Virtual Machine User Name text box.
f. Enter ovsroot in the Virtual Machine Password text box.
g. Enter a Description for the virtual machine (optional).
h. Click Next to proceed to the Confirmation page.
4. From the Confirm Information page click the Confirm button to proceed.
Figure 18 shows the Confirm Information page.
5. We have successfully created the CG_DB_Template virtual machine template, which is in the pending status. Templates that are in
the pending status are not available to Oracle VM Manager users until they have been approved. Next we will approve the
CG_DB_Template by selecting the CG_DB_Template radio button and clicking the Approve button as shown in Figure 19.
6. From the View Virtual Machine Template page click the Approve button to approve the template as shown in Figure 20.
7. The CG_Template has been successfully approved and is now in the Active State as shown in Figure 21.
In Step 3 we used Oracle VM Manager to create an OMR and OMS template. Next in Step 4 we will use Oracle VM Manager to create
the OMR and OMS virtual machines.
1. From the Virtual Machines page click one of the two Create Virtual Machine buttons to proceed.
Figure 22 shows the Virtual Machines page with two Create Virtual Machine buttons.
2. From the Creation Method page select the Create virtual machine based on virtual machine template radio button, then
click Next to proceed as shown in Figure 23.
3. From the Server Pool page select the desired Server Pool radio button and accept the default Preferred Server setting. Click
Next to proceed as shown in Figure 24.
4. From the Source page as shown in Figure 25 select the CG_DB_TEMPLATE radio button and click Next to proceed.
5. From the Virtual Machine Information page enter the following data:
a. Virtual Machine Name
b. Console Password
c. Confirm Console Password
d. Select the Enable High Availability check box if desired. HA will need to be configured in advance to enable HA.
e. Select the desired Network Interface Card and Bridge.
i. The Network Interface Card can be deleted by selecting the Delete radio button.
ii. The Add Row radio button allows us to create up to three Network Interface Cards
iii. The Bridge drop down list will allow us to select any configured bridges.
f. Click Next to proceed.
6. As shown in Figure 27, from the Confirm Information page click Confirm to proceed.
7. The web browser will automatically redirect to the Virtual Machine page. From the Virtual Machine page validate the status of
the new virtual machine, as Creating. When the creation process is completed the status will change to Powered Off.
8. From the Virtual Machines page click one of the two Create Virtual Machine buttons to proceed.
Figure 29 shows the Virtual Machines page with two Create Virtual Machine buttons.
9. From the Creation Method page select the Create virtual machine based on virtual machine template radio button, then
click Next to proceed as shown in Figure 30.
10. From the Server Pool page select the desired Server Pool radio button and accept the default Auto Preferred Server option.
Click Next to proceed as shown in Figure 31.
11. From the Source page as shown in Figure 32, select the CG_TEMPLATE radio button and click Next to proceed.
12. From the Virtual Machine Information page enter the following data:
a. Virtual Machine Name
b. Console Password
c. Confirm Console Password
d. Select the Enable High Availability check box if desired. HA will need to be configured in advance to enable HA.
e. Select the desired Network Interface Card and Bridge.
i. The Network Interface Card can be deleted by selecting the Delete radio button.
ii. The Add Row radio button allows us to create up to three Network Interface Cards
iii. The Bridge drop down list will allow us to select any configured bridges.
f. Click Next to proceed.
13. As shown in Figure 34, from the Confirm Information page click the Confirm button to proceed.
14. The web browser will automatically redirect to the Virtual Machine page. From the Virtual Machine page validate the status of
the new virtual machine, as Creating. When the creation process is completed the status will change to Powered Off.
15. When the creation process is completed the status will change to Powered Off as shown in Figure 36.
Step 5: Start the OMR and OMS Virtual Machines and Enter
Setup Values
In Step 4 we used Oracle VM Manager to create the OMR and OMS virtual machines from the templates we created in Step 3. In Step
5 we will used Oracle VM Manager to start the virtual machine that was created with the GC_DB_TEMPLATE, access the virtual
machine’s console and enter values for a number of setup options. Once we have successfully entered the setup values for the OMR
virtual machine we will start the OMS virtual machine (created from the GC_TEMPLATE template), we will access the virtual
machine’s console and will enter values for a number of setup options.
Note: Its necessary to start and configure the OMR virtual machine first followed by the OMS virtual machine.
List 3 and 4 show the default user names and password for the OMR and OMS virtual machines and the virtual machine console
password.
List 3 shows the default user name and passwords for the virtual machines.
List 4 shows the default password used to access the virtual machine console from Oracle VM Manager.
Password: oracle
Prerequisites
Before the OMR and OMS virtual machines are started ensure that your DNS server has entries for the OMR and OMS virtual
machines and that you have selected and documented the following setup options:
*The password must be at least 6 characters in length and contain at least one numeral character.
Setup Tips:
After the virtual machine is started, if you do not enter a password for the database accounts, the setup will fail and you will need
to restart the virtual machine.
After the virtual machine is started, if the setup hangs towards at the end of the setup process, allow up to 20 minutes for the
process to automatically complete. Once the setup is completed you will be presented with the logon screen.
After the virtual machine is started, if the setup is not completed, the next time the virtual machine starts the setup process will
start over from the beginning.
The following section will run through the steps to start and enter the setup data for the OMR virtual machine.
1. Login to Oracle VM Manager and select the OMR virtual machine and click the Power On button as shown in Figure 37. The
Status will change from Powered Off to Initializing.
2. Next click the Refresh button until the status changes to Running. Once the status is Running click the Console button to access
the OMR virtual machine console as shown in Figure 38.
3. Enter the default password oracle and click the OK button to proceed.
Figure 39 shows the OMR virtual machine console where the setup options are entered.
The following section will run through the steps to start and enter the setup data for the OMS virtual machine.
1. Login to Oracle VM Manager and select the OMS virtual machine and click the Power On button as shown in Figure 40. The
Status will change from Powered Off to Initializing.
2. Next click the Refresh button until the status changes to Running. Once the status is Running click the Console button to access
the OMS virtual machine console as shown in Figure 41.
Enter the default password oracle and click the OK button to proceed.
Figure 42 shows the OMS virtual machine console where the setup options are entered.
In Step 5 we used Oracle VM Manager to start both the OMR and OMS virtual machines, access the virtual machine’s console and
enter values for a number of setup options. Next in Step 6 we will install OMA using the installagent.sh script.
The following procedure will walk through the installation of the Oracle Management Agent (OMA) on the OMR virtual machine.
1. Log into the OMR virtual machine via the Oracle VM Manager console or via an SSH client as root using the default ovsroot
password.
2. Run the OMA installation script named installagent.sh which is located in the /u01/scripts directory, e.g.
#cd /u01/scripts
#./installagent.sh
3. Enter the Agent Registration password and press Enter.
4. Enter the OMR SYSMAN password and press Enter.
5. Enter the full pathname of the local bin directory: [/usr/local/bin]:
If you want to use the default directory, leave this field empty and press Enter.
6. If any of the dbhome, oraenv, coraenv files already exist, you are prompted to overwrite them. At each prompt, enter y and press
Enter to overwrite the file.
The file "dbhome" already exists in /usr/local/bin. Overwrite it? (y/n)
[n]: y
The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n)
[n]: y
The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n)
[n]: y
7. Once presented with the following banner press any key on the keyboard to complete the setup process.
======================================================================
Press any key to continue...
The next example shows a complete OMA install using the /u01/scripts/installagent.sh script.
--------------------------------------
The cloning of cloneagent10g was successful.
Please check '/u01/app/oraInventory/logs/cloneActions2008-10-21_05-44-30PM.log' for more details.
Running /u01/app/oracle/product/agent10g/root.sh...
Running Oracle10 root.sh script...
In Step 6 we installed OMA on the OMS virtual machine using the installagent.sh script. Next we will access the Enterprise Manager
Grid Control portal using the sysman account and the password that was selected during Step 5.
Once logged into the Enterprise Manager Grid Control portal please refer to http://download.oracle.com/docs/cd/B16240_01
/welcome.html for the Enterprise Manager Grid Control configuration and setup documentation.
1. Point a web browser to the FQDN of the OMS virtual machine i.e. http://FQDN:4889/em/ to access the Enterprise Manager Grid
Control portal. From the Login page enter sysman as the User Name and the password that was selected during Step 5. Then press
the Login button to proceed as shown in Figure 43.
In Step 7 we accessed the Enterprise Manager Grid Control portal using the sysman account and the password that was selected
during Step 5. Next we will change the ownership of the OMR and OMS virtual machines from the default My Workspace group to the
operations group.
Note: You will need to have created groups in Oracle VM Manager to complete this step.
By default when a virtual machine is created in Oracle VM Manager, it’s owned by the administrator that created the virtual machine.
By default when a virtual machine is created it will be placed in the My Workspace group, which makes the virtual machine visible
exclusively to the virtual machine owner. For example, both the OMR and OMS virtual machines from the above examples are only
visible in Oracle VM Manager by the administrator that created the virtual machines. To allow other Oracle VM Manager users to
view and manage the virtual machine the Deploy action is used to change the ownership from the My Workspace group to a different
group. To use the Deploy action the virtual machine must be powered off.
The next section will walk through the procedure to change the ownership of the OMR virtual machine.
1. From Oracle VM Manager ensure that the OMR virtual machine is Powered Off and then select the OMR virtual machine.
Once the OMR virtual machine is selected click the More Actions drop down menu and select the Deploy action. Then click the
Go button to start the Deploy action as shown in Figure 45.
2. From the Virtual Machine Information page enter the Virtual Machine Name in the text box, select the desired group from the
Group Name drop down list and select the desired server pool name from the Server Pool Name drop down list as shown in Figure
46. Click Next to proceed.
3. From the Confirm Information page click the Confirm button to start the deploy action as shown in Figure 47.
4. As shown in Figure 48 the status of the My Workspace virtual machine changed from Powered Off to Deploying and the
deployed virtual machine status is Creating.
When the Deploy action completes, each virtual machine’s status changes to Powered Off. The deploy action results in two identical
virtual machines with different group membership. The original virtual machine remains in the My Workspace group and the
Deployed virtual machine will be in the group selected from the Virtual Machine Information page. Repeat the process for the OMS
virtual machine to change the group membership.
Watch this space
Oracle OpenWorld 2011 Call for Papers - Submit Today!
Temporary Post Used For Theme Detection (409fc5e9-d7ee-4e1a-b645-8b82f256f434 - 3bfe001a-32de-4114-a6b4-4005b770f6d7)
Debugging Oracle VM 2.2 & Oracle VM Manager 2.2 errors using the many log files
New VDI Training Course now available!
HIMSS 2011 and New Press Release
Oracle Desktop Virtualization at HIMSS 2011
Oracle VM VirtualBox 4.0.4 Released!
Two Virtualization Webinars This Week
We're Hiring! - Server and Desktop Virtualization Product Management
By default Oracle VM 2.x logs all events locally. Logging events locally makes troubleshooting Oracle VM server pool issues a
challenge, because different log information is being echoed to different local log files. In this chapter, we will walk through a
centralized logging configuration for Oracle VM that makes troubleshooting Oracle VM much easier when compared to the default
local Oracle VM logging configuration.
As of Oracle VM 2.2, the Oracle VM agent's logging functionality is customizable by using the Python Logger class configuration file.
The Oracle VM Manager application runs on OC4J, a JSP container that has log4j style configuration capabilities. Both log4j and
python's logger do support logging to syslog.
Change Log
Table of Contents
Change Log
Upgrade the Oracle VM Server and Manager Local Syslog Daemon
Oracle VM Server Syslog Configuration
...Example /etc/ovs-agent/logger_server.ini file
How to Configure Rsyslog on Oracle VM Server
...Example /etc/rsyslog.conf file
...Example /etc/sysconfig/rsyslog file
How to Configure the Central Log Host
...Example /etc/sysconfig/rsyslog file
The Oracle VM Manager Syslog Configuration
...OC4J Logging
Note: The default Oracle VM 2.x server configuration does not have rsyslog.
The next three steps show how to install and configure rsyslog on an Oracle VM 2.x server and on an Oracle VM Manager x86 or
x86-x64 host:
1. Download and install the Oracle Linux 5.5 rsyslog rpm (3.22 at time of writing) using wget and the rpm programs.
Oracle VM Server: The Oracle VM server will always use the i386 RPM regardless of the hardware platform, i.e. both x86 or x86-x64
servers both use a x86 dom0 and will use the i386 RPM package.
Oracle VM Manager: Depending on the hardware/OS platform for your Oracle VM Manager host, use the i386 RPM package for x86
or the x86_64 package x64.
The next two examples show how to download and install the rsyslog rpm package for the i386 and x86-64 platforms using wget and
the rpm programs.
I386
# wget http://public-yum.oracle.com/repo/EnterpriseLinux/EL5/5/base/i386/rsyslog-3.22.1-3.el5.i386.rpm
# rpm -Uvh rsyslog-3.22.1-3.el5.i386.rpm
x86-64
# wget http://public-yum.oracle.com/repo/EnterpriseLinux/EL5/5/base/x86_64/rsyslog-3.22.1-3.el5.x86_64.rpm
# rpm -Uvh rsyslog-3.22.1-3.el5.x86_64.rpm
2. In the next example, we use the syslog configuration file for rsyslog. We also disable syslog and enable rsyslog:
# cp /etc/syslog.conf /etc/rsyslog.conf
# chkconfig syslog off
# chkconfig rsyslog on
# service syslog stop
# service rsyslog start
3. Next, check /var/log/messages to validate that rsyslog has started. For example, type “tail /var/log/messages”
The next list shows the changes that will be made to the ovs-agent Python logger:
1. Maintain the various handlers that Oracle uses, for consistency with Oracle support.
2. Propagate all handers to the parent (root) handler; all information logged by the ovs-agent will be available at this handler.
3. Set the log level to NOTSET, which is everything (more than DEBUG).
4. Forward logs to local syslog over udp/514 (default syslog port).
5. Set all loggers to "propagate=1", so they forward up logs to their parent handlers.
6. By default performance and macip logging doesn't propagate up. We need "propagate=1" for centralization.
7. Write to unix socket /dev/log, which must be created by rsyslog!
Note: We don't use the localhost 514/udp destination because this will create a message from a hostname of localhost or 127.0.0.1,
which is of no use for centralized logging. By writing to the socket, the syslog daemon appends its hostname, which is necessary for
centralized logging.
# cat /etc/ovs-agent/logger_server.ini
[loggers]
keys=root,performance,operation,query
[logger_root]
handlers=root
level=NOTSET
[logger_operation]
qualname=ovs.operation
handlers=operation
level=DEBUG
propagate=1
[logger_performance]
qualname=ovs.performance
handlers=performance
level=DEBUG
# default propagate is 0
propagate=1
[logger_query]
qualname=ovs.query
handlers=query
level=DEBUG
propagate=1
[logger_macip]
qualname=ovs.macip
handlers=macip
level=DEBUG
# default propagate is 0
propagate=1
;----------------------------------------------------------------------
[handlers]
keys=root,performance,operation,query,macip
[handler_root]
class=handlers.RotatingFileHandler
;append to log file, and file size is 1M with 3 archive files
args=("%(log.dir)s/ovs_root.log", "a", 1024*1024, 3)
formatter=ovs
level=DEBUG
# Syslog handler
# - log to local syslog daemon, which can forward to central loghost
# - using unix socket, which must match the socket created by the syslog daemon
# - could use UDP to localhost, which loses the originating host information
# (get messages tagged with an IP that makes no sense centrally, like 127.0.0.1
# for the localhost config)
# - SysLogHandler unix socket: args=('/dev/log', handlers.SysLogHandler.LOG_LOCAL3)
# - SysLogHandler to 514/udp: (('localhost', handlers.SYSLOG_UDP_PORT),
handlers.SysLogHandler.LOG_LOCAL3)
# - if the level is set on the syslog handler, all messages sent through that handler
# inherit this level. Preferable to set level on a per-logger basis
# - if level inherited by the loggers, then a simple formatter can be used that best
matches
# the expectation of syslog parsers. see formatters section for details. eg:
# format=%(name)s: %(message)s
#
# address: /dev/log unix socket
# facility: LOG_LOCAL3
# level: do not set at the handler level
# ref: http://docs.python.org/library/logging.html#sysloghandler
#
class=handlers.SysLogHandler
#args=(('localhost', handlers.SYSLOG_UDP_PORT), handlers.SysLogHandler.LOG_LOCAL3)
args=('/dev/log', handlers.SysLogHandler.LOG_LOCAL3)
formatter=syslog
[handler_operation]
class=handlers.RotatingFileHandler
;append to log file, and file size is 1M with 3 archive files
args=("%(log.dir)s/ovs_operation.log", "a", 1024*1024, 3)
formatter=ovs
level=DEBUG
[handler_performance]
class=handlers.RotatingFileHandler
;append to log file, and file size is 1M with 3 archive files
args=("%(log.dir)s/ovs_performance.log", "a", 1024*1024, 3)
formatter=ovs
level=DEBUG
[handler_query]
class=handlers.RotatingFileHandler
;append to log file, and file size is 1M with 3 archive files
args=("%(log.dir)s/ovs_query.log", "a", 1024*1024, 3)
formatter=ovs
level=DEBUG
[handler_macip]
class=handlers.RotatingFileHandler
;append to log file, and file size is 1M with 2 archive files
args=("%(log.dir)s/ovs_macip.log", "a", 1024*1024, 2)
formatter=ovs
level=DEBUG
;----------------------------------------------------------------------
[formatters]
keys=ovs,syslog
[formatter_ovs]
class=logging.Formatter
format=%(asctime)s %(levelname)s=> %(message)s
datefmt="%Y-%m-%d %H:%M:%S"
The following /etc/rsyslog.conf file example contains rsyslog specific configuration elements. The "@@" remote forwarding
terminology means "use TCP", whereas "@" means "use UDP".
# cat /etc/rsyslog.conf
# ----------------------------- Queues (required for forwarding)
-----------------------------
$WorkDirectory /var/spool/rsyslog
$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName srvrfwd # set file name, also enables disk mode
$ActionResumeRetryCount -1 # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
# RFC5424 format
# also known as RSYSLOG_SyslogProtocol23Format, and
draft-internet-ietf-syslog-protocol-23 (now RFC5424)
# the "1" in "<%PRI%>1 " denotes syslog protocol version 1, as per the RFC
# eg: <21>1 2011-01-01T16:09:05+00:00 <MAIL PROXY HOST NAME GOES HERE> perdition 14185 - -
$template RFC5424FMT,"<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID%
%STRUCTURED-DATA% %msg%\n"
# MAIL: Log locally & forward a copy to syslog1-syd.internal for further analysis
mail.*
-/var/log/mail/mail.log;RFC5424FMT
mail.*
@@syslog1-<FQDN OF CENTRAL LOG HOST>:601
# Oracle VM: Log locally & forward a copy to syslog1-syd.internal for further analysis
local3.*
-/var/log/ovs-agent/all.log;RFC5424FMT
local3.*
# cat /etc/sysconfig/rsyslog
# Options to syslogd
# -m 0 disables 'MARK' messages.
# -rPortNumber Enables logging from remote machines. The listener will listen to the specified port.
# -x disables DNS lookups on messages received with -r
# See syslogd(8) for more details
SYSLOGD_OPTIONS="-c3 "
# Options to klogd
# -2 prints all kernel oops messages twice; once for klogd to decode, and
# once for processing with 'ksymoops'
# -x disables all klogd processing of oops messages entirely
# See klogd(8) for more details
KLOGD_OPTIONS="-x"
Next, enable the changes by reloading rsyslog by typing, “service rsyslog reload”. After rsyslog has been reloaded, there should be an
empty file named all.log in the /var/log/ovs-agent/ directory.
Next, reload the Oracle VM agent by typing “service ovs-agent stop --disable-nowayout; service ovs-agent start” as shown in the next
example.
After the Oracle VM agent has been reloaded, messages will appear in the local /var/log/ovs-agent/all.log file, as shown in the next
example.
Note: If you see "localhost.localdomain" or "127.0.0.1" instead of the hostname in the all.log file, use the unix socket instead of udp in
configuring syslog for the Oracle VM agent.
Note: For the /etc/rsyslog.conf file, please see the Centralized Log Host full rsyslog.conf section.
# cat /etc/sysconfig/rsyslog
# Options to syslogd
# -m 0 disables 'MARK' messages.
# -rPortNumber Enables logging from remote machines. The listener will listen to the specified port.
# -x disables DNS lookups on messages received with -r
# See syslogd(8) for more details
#SYSLOGD_OPTIONS="-c3 -x -m 0 -r514 -t601,4096" # syslog compat
SYSLOGD_OPTIONS="-c3 " # rsyslog
# Options to klogd
# -2 prints all kernel oops messages twice; once for klogd to decode, and
# once for processing with 'ksymoops'
# -x disables all klogd processing of oops messages entirely
# See klogd(8) for more details
KLOGD_OPTIONS="-x"
Next, reload the rsyslog service by typing, “service rsyslog reload”. After the rsyslog service has been reloaded, the central log host
will receive messages to /var/log/ovs-agent/all.log.
Notes: The rsyslog configuration must allow inbound 601/tcp. Check the central log host firewall to ensure that inbound 601/tcp is
enabled. The central log host's /var/log/ovs-agent directory must exist. If SElinux is in use, it must have the "user_u:object_r:var_log_t"
context
OC4J Logging
The Oracle VM Manager application is a J2EE Web application, running in an OC4J container. Assuming OC4J is installed to /opt/oc4j,
then the default logging is configured via the
“/opt/oc4j/j2ee/home/config/j2ee-logging.xml” file.
By default the deployment descriptors both point to the j2ee-logging.xml configuration file. So we only need to edit the
j2ee-logging.xml configuration file.
Note: The configuration will result in the lose of the event severity.
Note: The full imfile module documentation can be found here: http://www.rsyslog.com/doc/imfile.html
# cat /etc/rsyslog.conf
# module: input file
# - emits each line of the given file to syslog, for apps that don't do syslog
# - keeps track of position, file rotation
$ModLoad imfile
$InputFileName /var/log/ovm-manager/oc4j.log
$InputFileTag OVM:
$InputFileStateFile state-oc4j
$InputFileSeverity debug
$InputFileFacility local2
$InputRunFileMonitor
# Oracle VM Manager: Log locally & forward a copy to syslog1-syd.internal for further analysis
# - Oracle VM Manager to local2, not logging to file here as the input is a file
local2.* @@<CENTRAL LOG HOST>:601
Next, restart the rsyslog service on the central log host and on Oracle VM Manager. After the rsyslog service is restarted, log host
should see inbound messages:
# cat /etc/rsyslog.conf
# ----------------------------- Queues (required for forwarding) -----------------------------
$WorkDirectory /var/spool/rsyslog
$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName srvrfwd # set file name, also enables disk mode
$ActionResumeRetryCount -1 # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
# ----------------------------- Modules & Functions -----------------------------
# module: kernel logs, klogd replacement
$ModLoad imklog
# RFC5424 format
# also known as RSYSLOG_SyslogProtocol23Format, and draft-internet-ietf-syslog-protocol-23 (now
RFC5424)
# the "1" in "<%PRI%>1 " denotes syslog protocol version 1, as per the RFC
# eg: <21>1 2011-01-01T16:09:05+00:00 <MAIL PROXY HOST NAME> perdition 14185 - -
$template RFC5424FMT,"<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID%
%STRUCTURED-DATA% %msg%\n"
# MAIL: Log locally & forward a copy to sysdev1-syd3 for further analysis
# - RFC5424 parseable output
mail.* -/var/log/mail/mail.log;RFC5424FMT
mail.* @@<SMTP HOST>:601
# cat /etc/logrotate.d/ovs-agent
/var/log/ovs-agent/all.log {
create 0644 root root
missing ok
# compression parameters
compress
compresscmd /usr/bin/bzip2
compressext .bz2
compressoptions -9
The information found in this publication was gathered from many different sources in the computing world. It is provided for
informational purposes only. Use common sense in applying these concepts and tips. Screen shots may vary from environment to
environment. Please verify correctness and applicability in a test environment first and then deploy to your production
environment(s).
Introduction
I would like to introduce the Virtualization Security Policy Project Second Edition. The Virtualization Security Policy Project Second
Edition consists of an Enterprise Architecture Introduction, a Hardware and Software Sunset Policy, a Server Virtualization Policy, and
a Server Virtualization Standards.
The Enterprise Architecture Introduction provides the framework for the Virtualization Security Policy Project and runs through a
brief introduction of Enterprise Architecture to
illustrate how your virtualization technologies fit within your Enterprise Architecture.
The Hardware and Software Sunset Policy define an organization’s hardware and software sunset policy.
The Server Virtualization Policy and Server Virtualization Standards define an organization’s server virtualization requirements and
minimum standards.
You can use the policies and standards as is or modify them to meet your specific business requirements.
I welcome your comments about the Virtualization Security Policy Project. Please let me know if you would like to see additional
policies added to the Virtualization Security Policy Project to help support your virtual infrastructure.
The purpose of Enterprise Architecture is to establish an Enterprise wide blueprint used to achieve business objectives while
maximizing the business value of information technology. An Enterprise Architecture is a “blueprint” that describes an organization’s
strategic direction, security and regulatory requirements, information technology portfolio and their inter-dependencies, baseline and
target architectures, and the processes to implement technologies. In business terms, Enterprise Architecture is accomplished by
efficiently achieving an organization’s mission with minimal investment in information technology; and in technical terms, by
optimizing business operations, effective information technology planning, information technology budgeting, information technology
acquisition, human resource utilization, and the implementation of security controls.
After the goals and stakeholders of an Enterprise Architecture project have been identified, a framework is selected to help
implement and support the Enterprise Architecture through its entire life cycle. There are a number of frameworks, such as Cobit,
ISO/IEC 17799, ITIL, and many others that represents a variety of methodologies and toolsets to fulfill the requirements of any size or
type of organization. Frameworks provide methodologies, standards, guidelines, and formats that can be used as is or adapted to
meet specific requirements. Because organizations have different missions and business objectives, no single framework will be right
for each situation. Organizations typically select a framework or a mixture of frameworks to meet their requirements.
Enterprise Architecture has well defined principles and processes, along withan approach that generates a comprehensive layered
policy infrastructure used to communicate management’s goals, principles, instructions, procedures, and response to laws and
regulatory mandates. A policy infrastructure consists of tier 1, tier 2 and tier 3 policies that encompass people, systems, data, and
information. A policy infrastructure consists of policies, standards, procedures, baselines, and guidelines.
Tier 1 policies are at the top layer of the policy infrastructure and address broad organizational issues, vision and direction. Most
organizations will develop and support up to a dozen tier 1 policies. An example tier 1 policy is an Employee Practices Policy or a
Conflict of Interest Policy. Global in scope, Tier 1 policies are high level documents that define vision and direction.
Tier 2 policies are topic specific, and tier 3 policies are application or system specific. Standards are tier 2 policies that describe
system design concepts, implementation steps, and detailed configurations. Procedures are tier 2 & 3 policies that provide step by
step compulsory measures, communicating best practices in using information systems and organizational data/information. Baselines
are tier 3 policies that are application or system specific and describe step by step instructions to implement technologies.
Guidelines are tier 3 documents, offering application, system, or procedural specific best practices. Guidelines are
recommendations unlike policies, standards, procedures, and baselines, which are compulsory.
Figure 1 represents Enterprise Architecture’s layered policy infrastructure, starting with tier 1 policies which address broad
organizational issues, vision, and direction. The next layer, General Organizational Policy, consists of tier 1 policies in which
management makes security statements, explains roles and responsibilities, and defines which assets are considered valuable. The
following layer, Practical Implementation Policies, contains tier 2 and 3 policies which are topic, application, and system specific and
are used to enforce upper layer policies. The lower layer consists of tier 2 and 3 policies which are topic and technology specific and
are used to enforce higher layer policies.
A policy infrastructure contains confidential information relating to running a business and the publication, distribution and storage of
that information should be strictly monitored. Many organizations leverage the human resource department and secured
intranet solutions to distribute and control access to policies.
An Enterprise Architecture groups together infrastructure components within topic specific domains. An example of Enterprise
Architecture domains are infrastructure, applications, network, and security. After an organization has defined its Enterprise
Architecture domains, all infrastructure components are grouped within their corresponding domain and reviewed individually and as
a single cohesive unit. Layered policies are developed for each domain and each individual technology within a domain.
Table 1 shows the Enterprise Architecture domain structure that will be used throughout this publication. The example encompasses
five domains split between two high level groups; infrastructure and applications. The five domains are platform, network, software,
data / information, and security.
Enterprise Architecture Scope
Infrastructure Applications
Platform Software
Network Data/Information
Security
An organization’s mission and business objectives drive its Enterprise Architecture domain structure. As we have all learned, there is
no ‘one size fits all’ with information technology, and Enterprise Architecture is no exception. Enterprise Architecture is flexible and
can be molded to suit any organization’s mission and business objectives.
Platform
Network
Software
Data/Information
Security
Access Domain
Integration Domain
Privacy Domain
Scope
The scope of this policy encompasses server, desktop and network hardware platforms, operating systems and application software.
Policy
Products that have reached the end of their life cycle and are no longer supported by a vendor will be given a sunset date. The sunset
date is when the product is scheduled to be removed from production. The sunset date will be set far enough in advance to give
<Company Name> at least a budget cycle to fund and plan for the replacement. When a particular version of hardware or software is
scheduled to be sunsetted, <Company Name> will provide the affected users with advance notice via email.
A Sunset list will be used to track all hardware and software sunset dates. In order to keep the sunset list up to date, <Company
Name> will update the sunset list quarterly with hardware and software for review. Department managers with staff that use
products on the sunset list will be notified quarterly via email regarding the sunset review process and sunset dates.
If you are currently using application software that has been designated sunset and would like to extent support, you will need to
acquire a version that meets the current minimum standards as defined in <Company Name> Software Standards. If you are
currently using hardware that has been designated sunset, any technical issues with the unit will trigger a replacement process with
a unit that meets the current minimum standards as defined in <Company Name> Hardware Standards.
Review Cycle
This policy is subject to annual review.
Compliance
All information technology investments shall conform to existing policies in order to ensure the integrity and interoperability of
computing platforms. Any employee found to have violated this policy may be subject to disciplinary action, up to and including
termination of employment.
Related Policies
Platform Infrastructure Standard
Xen.org @ OSCON
Xen.org GSoC 2011 Update
KVM Forum 2011 scheduled for August 15-16
Libvirt 0.9.0 Released
Virt-Manager 0.8.7 Released: New UI Features
Proxmox VE 1.8 Released: Supports qemu-kvm 0.14
Xen 4.1 releases
Xen hack-a-tron day 1
Xen.org accepted for GSoC 2011
Xen.org spring clean
Purpose
The purpose of this policy is to establish server virtualization requirements that define the acquisition, use, and management of server
virtualization technologies. This policy provides controls that ensure that Enterprise issues are considered along with business
objectives when making server virtualization related decisions.
Platform Architecture policies, standards and guidelines will be used to acquire, design, implement and manage all server
virtualization technologies.
Scope
The scope of this policy encompasses all new and existing workloads.
Responsibilities
The CEO and CIO ensure that policies are followed in order to establish contracts, review procurement requests and to develop and
manage services.
Policy
<Company Name>’ legacy IT practice was to dedicate one physical server to a single workload. The result of <Company Name>’
legacy IT practice was excessive server underutilization, an ever-expanding data center footprint and excessive data center power
consumption.
Server virtualization software allows the consolidation of new and existing workloads onto high capacity x86 servers. Consolidating
workloads onto high capacity x86 servers allows <Company Name> to reduce the x86 server inventory, which in turn decreases the
data center footprint and data center power consumption.
<Company Name> will migrate all new and existing workloads from physical servers to virtual machines. All workloads that cannot
be migrated to a virtual machine will be subject to <Company Name>’ Hardware and Software Sunset Policy.
Review Cycle
This policy is subject to annual review.
Compliance
All information technology investments shall conform to existing policies in order to ensure the integrity and interoperability of
computing platforms.
Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
Related Policies
Platform Infrastructure Standard
Server Virtualization Standard
Server Virtualization Guidelines
Hardware and Software Sunset Policy
Xen.org @ OSCON
Xen.org GSoC 2011 Update
KVM Forum 2011 scheduled for August 15-16
Platform Architecture policies, standards and guidelines will be used to acquire, design, implement and manage all server
virtualization software.
Scope
The scope of this policy encompasses all server virtualization software.
Responsibilities
The CEO and CIO ensure that policies are followed in order to establish contracts, review procurement requests and to develop and
manage services.
Standards:
Table 1 shows the Technology Classifications used to define <Company Name>’ technology life cycle.
Current
Table 2 lists the current server virtualization technologies.
Contain
Table 3 lists the contain technologies that are being phased out over the next 3 to 5 years.
Retire
Table 4 lists the retire technologies which are being phased out. Referance the Hardware and Software Sunset Policy for the software
retirment plan.
Reaearch
Table 5 lists the research technologies. Research technologies could become current standards. The use of research technologies is
restricted to test environments.
Review Cycle
This policy is subject to annual review.
Compliance
All information technology investments shall conform to existing policies in order to ensure the integrity and interoperability of
computing platforms.
Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
Related Policies
Platform Infrastructure Standard
Server Virtualization Policy
Server Virtualization Guidelines
Hardware and Software Sunset Policy
Xen.org @ OSCON
Xen.org GSoC 2011 Update
KVM Forum 2011 scheduled for August 15-16
Libvirt 0.9.0 Released
Virt-Manager 0.8.7 Released: New UI Features
Proxmox VE 1.8 Released: Supports qemu-kvm 0.14
Xen 4.1 releases
Xen hack-a-tron day 1
Xen.org accepted for GSoC 2011
Xen.org spring clean