Chapter 2: Oracle VM for x86 Reference Design and Architectural Introduction
Engage the Author Roddy Rodstein Today for your Oracle Project!
Copyright © 2009 - 2012 Roddy Rodstein. All rights reserved.
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
|
Revision
|
Change Description
|
Updated By
|
Date
|
|
1
|
New chapter
|
Roddy Rodstein
|
04/03/11
|
| 1 | 3.4 – Oracle VM for x86 Network Security Architecture - Added "SSH login banners" | Roddy Rodstein | 04/11/11 |
| 1 | 3.5 - Oracle VM for x86 Administration and Monitoring - Added "Rootkit prevention and monitoring" | Roddy Rodstein | 04/11/11 |
Oracle VM Server and Xen Architectural Review
Oracle VM for x86 consists of an x86 server component and a manager component that is used to manage one or more clustered servers. The server component is a type 1 hypervisor based on the Xen.org open source hypervisor, which is called the Oracle VM server. Xen is considered a type 1 hypervisor because Xen installs directly on hardware, whereas a type 2 hypervisor, such as Oracle VM VirtualBox, is a software applications installed on top of a desktop operating system. The Xen hypervisor is responsible for monitoring virtual machine operating systems and for scheduling virtual machine operating system requests to the physical server's CPU and memory. Xen is not responsible for and has no knowledge of networking, external storage, video, or common I/O functions.
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.
Oracle VM for x86 Server Specifications
Supported Platforms
-
x86 or x86_64 processors with PAE (Physical Address Extension) support
Minimum Processor Class
-
I686 class
Minimum Memory
-
1GB
Maximum Memory
-
1TB
CPUs Supporting Paravirtualization Mode
-
Intel Pentium-PRO or newer
-
AMD Athlon/Duron or newer
-
At least a Pentium IV or Athlon CPU recommended
CPUs Supporting Hardware Virtualization Mode
-
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)
Maximum Number of CPUs or Threads
-
128 CPUs or 128 threads
Boot Options
-
Local disk, SAN, iSCSI, NFS, flash
Oracle VM for x86 Virtual Machine Specifications
Maximum Number of Virtual CPUs per Virtual Machine
-
32 virtual CPUs
Maximum Amount of Memory per Virtual Machine
-
x86 (32-bit): 63GB
-
x86_64 (64-bit): 510GB
Maximum Number of Virtual Disks per Virtual Machine
-
Paravirtualized Mode: 20 hda, 26 sda, 5 xvd
-
Hardware Virtualization Mode: 4 hda, 7 sda, 5 xvd
-
*Each Oracle VM Server can support a maximum of 128 virtual disks
Maximum Number of Virtual NICs per Virtual Machine
-
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.
The next section provides an architectural review of Oracle VM Manager.
Oracle VM Manager Architectural Review
Oracle VM Manager is the default “no cost management component” for Oracle VM for x86. Oracle VM Manager is a traditional Oracle application that installs on Oracle Linux and Red Hat Enterprise Linux. It is used to manage one or more clustered Oracle VM servers, virtual machines, and virtual machine resources. Oracle VM Manager consists of an Oracle database, an Oracle application server, and a J2EE application with an OS and browser neutral Oracle Application Development Framework (ADF) administrative portal. Oracle VM Manager also has a command line interface that allows Oracle VM Manager administrative tasks to be performed from the command line or to be executed as scripts.
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
|
|
Oracle Database 10g Express Edition
|
The Oracle Database 10g Express Edition is packaged in the Oracle VM ISO.
|
|
Oracle VM Manager package
|
The Oracle VM Manager package contains the Oracle VM Manager web application. The Oracle VM Manager web application runs on Oracle Application Server 10g Release 3 (10.1.3) and is deployed into an OC4J container.
|
|
Oracle Containers for J2EE (OC4J) Standalone 10.1.3 packaged with Application Development Framework (ADF) 10.1.3.3
|
Oracle Containers for J2EE (OC4J) is the J2EE runtime environment for the Oracle Application Server. Oracle Application Development Framework (ADF) is a Java EE framework.
|
|
XML-RPC 3.0
|
The XML-RPC 3.0 package is installed during an Oracle VM Manager installation. XML-RPC is used for Oracle VM Manager to Oracle VM agent communication.
|
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.
List 2 explains each of the three Oracle VM agent roles.
-
Server Pool Master
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.
-
Virtual Machine Server
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.
Oracle VM for x86 Networking
The default Oracle VM server networking configuration routes all dom0 and virtual machine 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. 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.
Oracle VM for x86 Server Pools, HA, and Live Migration
Oracle VM Manager uses the concept of a server pool to group together and manage one or more clustered Oracle VM servers. An Oracle VM server pool defines the management boundaries and the feature set of Oracle VM servers, virtual machines, and virtual machine resources. Once a server pool is created, resources such as servers, virtual machines, operating system installation ISO files, Oracle VM templates, administrative users, and groups can be configured and managed within the context of the server pool. For example, an Oracle VM environment with multiple server pools could be managed from one single Oracle VM Manager instance, although each server pool's resources, such as servers, virtual machines, operating system installation ISO files, Oracle VM 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.
Oracle VM for x86 Storage
Oracle VM uses two different types of storage repositories for server pools. The first type of storage repository, called a root repository, is used to host a server pool's Oracle Cluster File System v2 (OCFS2) cluster configurations, HA configurations for HA enabled pools and, optionally, virtual machine configuration files and images. There can only be one OCFS2 or NFS root repository per server pool. The other type of storage repository, called an extended repository, is used exclusively for server pools with more than one server, to host virtual machine configuration files and images. There can be one or more extended OCFS2 and/or NFS repositories in a server pool with more than one server. When a server pool needs more storage capacity, additional extended OCFS2 and/or NFS repositories are added to a server pool to increase capacity.
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.
Oracle VM for x86 Intracomponent Communication & Firewall Requirements
This section will examine Oracle VM for x86's intracomponent communication and firewall requirements. The goal of this section is to illustrate the communication ports and system passwords required to help plan, build, and support an Oracle VM for x86 environment.
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.
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.
1.0 – The Oracle VM for x86 System Reference Design Introduction
This section presents the Oracle VM for x86 reference design. The Oracle VM for x86 reference designs encompass the software, hardware, storage, and network components required to deploy a scalable, secure, and supportable Oracle VM for x86 solution in an internal or external cloud.
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.
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.
-
-
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
-
-
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.
Part 1 - The Oracle VM for x86 System Reference Design
3.0 Cloud Infrastructure Architecture
This section provides a decision matrix for the Oracle VM for x86 reference design. Implementers of the Oracle VM for x86 reference design can use the decision matrix as quick reference guide to identify settings and configuration decisions to be implemented in the environment. Decisions highlighted in yellow may rely on preexisting environment factors or differ depending on organizational needs. These decisions should be carefully analyzed during a gap analysis phase.
|
Decision Point
|
Decision
|
Justification
|
|
Server Vendor
|
Servers will be procured from a reliable hardware vendor.
|
NA
|
|
Processors
|
Two socket multiple-core processors for standard workloads and four socket multiple-core processors for large CPU-bound workloads.
|
The Maximum Number of CPUs or threads an Oracle VM server can support is 128. Oracle VM server maps a virtual CPU to a hardware thread on a CPU core in a CPU socket. A CPU core or a hyperthread is considered a physical CPU by the Xen hypervisor.
For example, a server with an Intel Xeon processor 5600-series CPU with hyperthreading can have up to six cores and twelve threads per socket. A two socket server with an Intel Xeon processor 5600-series CPU could allocate twenty four virtual CPUs without oversubscribing the physical CPUs. CPU-bound workloads should not be on servers that have oversubscribed CPUs.
Two socket multiple-core processors are ideal for standard non-CPU-bound workloads. For example, workloads with up to 8 virtual CPUs.
Four socket multiple-core processors are ideal for large CPU-bound workloads. For example, workloads with 16 up to 32 virtual CPUs.
|
|
RAM
|
Servers will be ordered with the maximum amount of physical memory.
|
Oracle VM server does not support memory oversubscription, which means that an Oracle VM server cannot accept a Live Migration or HA request unless the server has available RAM for the virtual machines. Having available RAM on each server provides flexibility in terms of adding new virtual machines to the server pool, and to allow Live Migration and HA within a server pool.
|
|
Internal storage
|
Unless the Oracle VM server is booting from SAN, redundant internal hard drives or a 2GB flash drive is required. Virtual machine images will be stored on shared SAN, iSCSI, or NFS repositories.
|
An Oracle VM server installation “without” local virtual machine storage requires 1GB of storage and 1GB of swap space. Oracle VM server can be installed on a 2GB flash drive or on local redundant hard drives.
|
|
NICs
|
A minimum of two and up to four NICs per server.
|
For network-interface height availability 802.3AD bonds will be used for each pair of network interfaces up to a maximum of four network interface cards with two bonds.
|
|
Build Process
|
PXE boot
|
Oracle VM server will be installed using an automated PXE boot configuration to ensure that each server has a consistent installation configuration.
|
3.2 - Oracle VM for x86 Server Pool Configurations
|
Decision Point
|
Decision
|
Justification
|
|
Oracle VM for x86 server pool design and management
|
Use multiple Oracle VM server pools managed from Oracle VM Manager.
|
Single point of administration for multiple Oracle VM server pools accommodating organization-specific needs, i.e., defense in depth, the principle of least privilege, compartmentalization of information, 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.
If more than one location exists, Oracle VM server pools may be dispersed to different locations.
|
|
Version of Oracle VM server and Oracle VM Manager
|
The latest version of Oracle VM server and Oracle VM Manager will be used.
|
The latest version of Oracle VM server and Oracle VM Manager will be used to ensure that system has the latest platform and security updates and patches.
|
|
Oracle VM agent role configurations
|
Server Pool Master
Each Oracle VM server pool will enable the Virtual IP feature.
Utility Server
Each Oracle VM server pool will have at least one dedicated utility server with only the Utility Server role enabled.
Virtual Machine Server
Virtual Machine Servers will have only the Virtual Machine Server role enabled.
|
Server Pool Master
To eliminate a single point of failure, each Oracle VM server pool will enable the Virtual IP feature.
Utility Server
Each Oracle VM server pool will have at least one dedicated utility server to isolate the impact of I/O intensive operations on the Utility Servers. Utility Servers will only have Utility Server role enabled.
Virtual Machine Server
Virtual Machine Servers will only have the Virtual Machine Server role enabled to dedicate system resources to running virtual machines, eliminating the effect of Utility Server operations.
|
|
Oracle VM Server Pool Storage Configurations
|
Each Oracle VM server pool will have 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 up to a maximum of 10 extended repositories used exclusively to host virtual machine configuration files and images.
|
Each Oracle VM server pool uses one OCFS2 or NFS 4GB root repository that is used to host each server pool's OCFS2 cluster and HA configurations to isolate and protect the cluster and HA configurations from virtual machine configuration operations. Up to 10 extended repositories can be used exclusively to host virtual machine configuration files and images. The Oracle VM agent can reliably support up to 10 extended repositories.
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, i.e., partition sizes cannot change once a partition is formatted with OCFS2. When a server pool needs more storage capacity, up to ten extended OCFS2 and/or NFS repositories can be added to a server pool to increase capacity.
|
|
Oracle VM Server Pool Network Configurations.
|
Each Oracle VM pool member will use one of the two following network configurations:
1) A single two NIC 802.3AD bond with Xen bridges using 802.1Q-Tagged VLANs to isolate traffic between the Oracle VM management network and the virtual machine networks.
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.
|
For network interface link aggregation and height availability 802.3AD bonds will be used for each pair of network interfaces up to a maximum of four network interface cards with two bonds.
802.1Q-Tagged VLANs are used to configure isolated virtual networks using "smart" or managed Ethernet switches, rather than relying on cables wired into physical switches and routers. For example, with VLANs a LAN can be segmented into isolated security domains that offer defense in depth, the principle of least privilege, and compartmentalization of information, and can accommodate different applications and their performance, authentication, and security requirements, without being restricted by physical connections.
|
|
Patch Management
|
Oracle VM servers will be configured to use local custom yum repositories.
All patches will be regression tested in the lab environment before they are deployed on production systems.
High-priority patches, security fixes, and application upgrades updates will be applied as needed in accordance with <Company Name>’s Change Management Policy.
Noncritical fixes will be applied on a Quarterly basis in accordance with <Company Name>’s Change Management Policy.
All production systems will undergo security audits in accordance with <Company Name>’s Change Management Policy to validate configuration and patch compliance.
|
A key component of patch management is acquiring and vetting patches for production systems. Patches must be researched to identify which patches, security fixes, and application updates are applicable to your environment. Newly released patches, security updates, and application updates will be tested before being deployed in to production using time stamped local custom repositories.
Local yum repositories will be maintained for patch testing and production using a point-in-time static channel for each supported operating system to ensure all like operating systems are patched in a consistent manner across the organization.
Pre- and post-production audits will be conducted in accordance with <Company Name>’s Change Management Policy to validate configuration and patch compliance.
|
3.3 - Oracle VM for x86 Network Topology
|
Decision Point
|
Decision
|
Justification
|
|
NIC Configuration
|
Each Oracle VM server will use 802.3AD bonds for each pair of network interfaces up to a maximum of four network interface cards with two bonds.
|
For network interface link aggregation and height availability 802.3AD bonds will be used for each pair of network interfaces up to a maximum of four network interface cards with two bonds.
|
|
Switch Port Configuration
|
802.1Q-Tagged VLANs
|
802.1Q-Tagged VLANs are used to configure isolated virtual networks using "smart" or managed Ethernet switches, rather than relying on cables wired into physical switches and routers. For example, with 802.1Q-Tagged VLANs a LAN can be segmented into isolated security domains that offer defense in depth, the principle of least privilege, and compartmentalization of information, and can accommodate different applications and their performance, authentication, and security requirements, without being restricted by physical connections.
|
|
IP Addresses
|
Static
|
Using static reserved IP addresses eliminates issues associated with duplicated or reassigned IP addresses.
|
|
Location of Oracle VM server pool management network
|
Each production Oracle VM server pool have an isolated management network subnet.
|
Each Oracle VM server pool will restrict Oracle VM management traffic to an isolated network subnet to protect the server pool from broadcast storms that could saturate the management network and cause pool members to loose network connectivity and fence from the pool.
|
|
Location of Oracle VM Manager
|
Oracle VM Manager will be located on a isolated network segment.
|
Oracle VM Manager will be the single point of administration for all Oracle VM server pools and should be located on a secure isolated network segment to protect access to the Oracle VM Manager portal and to better control and monitor communication to the server pool masters.
|
|
Virtual Machine Console Access
|
Inbound TCP 5900 through 5999 traffic will be allowed to each Oracle VM server pool network subnet.
|
To facilitate virtual machine console access, inbound TCP 5900 through 5999 traffic must be allowed to each Oracle VM server pool network subnet from the system administrators network subnet.
|
|
Port Numbers
|
The default ports will be used for all Oracle VM server and Oracle VM Manager components.
|
Using the default ports creates consistency and simplifies configuration.
|
|
NFS Storage Repositories
|
If NFS shared storage repositories are used, the storage network will be restricted to the Oracle VM Management network subnet.
|
NFS shared storage repositories will be restricted to the Oracle VM Management network subnet to isolate and secure NFS storage traffic.
|
3.4 – Oracle VM for x86 Network Security Architecture
|
Decision Point
|
Decision
|
Justification
|
|
Oracle VM Server and Oracle VM Manager iptables configurations
|
The iptables service will be enabled on each Oracle VM server using the default
policy and ruleset in /etc/sysconfig/iptables.
|
Host firewalls, for example iptables, are a fundamental part of information security that protect hosts from attacks and intrusions.
|
|
Root ssh access
|
Root ssh access will be disabled on all Oracle VM servers and sudo will be configured for root access.
To disable root ssh access, edit the default /etc/ssh/sshd_config file and uncomment the
the “#PermitRootLogin yes” line and change the yes to no; that is, “PermitRootLogin no”. Next, restart the sshd service by typing “service sshd restart” to enable the change.
To enable sudo access for a users, from dom0 type “viedit” and add the account names under the following lines:
## Allow root to run any commands anywhere
root ALL=(ALL) ALL
newuser ALL=(ALL) ALL
The above example provides root access to all commands for the newuser account. More restrictive access to commands can be configured for each user. Consult the sudoers man page for details.
|
By default, Oracle VM servers permit ssh access using the root super user account. One of the most important security measure that can be taken on an Oracle VM server is to prevent unauthorized access to the root user account by disabling root ssh access.
Systems administrators will access the Oracle VM servers with user privileges and use sudo for root access. All sudo user access will be tracked and logged in the /var/log/secure file.
|
| SSH login banners |
Pre and post SSH login banners will be configured on each Oracle VM server.
Pre-login banner:
Edit the /etc/ssh/sshd_config and add the following directive:
Banner /etc/banner.net
Next, create the /etc/banner.net file and add your login banner, i.e.
vi /etc/banner.net
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!
Once the file has been created and the banner text is added and saved, restart the sshd by typing:
# service sshd restart
Post login banner:
Edit /etc/motd and add your login banner text, i.e.
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!
Once the file has been edited and saved, restart the sshd by typing:
# service sshd restart
|
To be able to successfully prosecute individuals who improperly use a computer, the computer must have a warning banner displayed at all access points.
SSH login banners presents a definitive warning or disclaimer to all users that wish to access your systems using SSH. SSH login banners should clarify which types of activities are illegal as well as advise legitimate users of their obligations relating to the acceptable use of the system.
|
|
Iptables failed connection logging
|
Iptables failed connection logging will be enabled on each Oracle VM server.
The following two lines will be added prior to the last REJECT line in the /etc/sysconfig/iptables file:
-A RH-Firewall-1-INPUT -m limit --limit 15/minute -j LOG
--log-prefix "FW Drop:"
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-hostprohibited
|
Failed connect logging is a fundamental part of information security that allows detection of attacks and intrusions.
|
|
Central log host
|
A central log host will be used to log all user logins and iptables connection failures.
|
Centralized logging for user logins and iptables connection failures simplifies security management for the detection of attacks and intrusions.
|
|
Oracle VM Manager in a DMZ
|
Oracle VM Manager will not be placed in a DMZ.
|
The Oracle VM Manager application was not designed to be an Internet facing application. If remote access is a requirement for Oracle VM Manager VPN access will be used.
|
|
Oracle VM Servers in a DMZ
|
Oracle VM server hosting Internet facing virtual machines will be placed in a DMZ without connectivity to the Internet or internal network segments, except TCP/8899 from Oracle VM Manager.
|
Oracle VM servers in a DMZ are restricted from inbound and outbound Internet connectivity to minimize the risk of attack from the Internet.
Oracle VM servers in a DMZ are restricted from access to internal network segments except TCP/8899 from Oracle VM Manager.
If virtual machine console access is required, inbound TCP/5900 through 5999 will be configured to each Oracle VM server in the DMZ for virtual machine console access.
|
3.5 - Oracle VM for x86 Administration and Monitoring
|
Decision Point
|
Decision
|
Justification
|
|
Oracle VM for x86 server pool administration and monitoring
|
Oracle VM for x86 server pool administration will be done using Oracle VM Manager with the Oracle VM Manager Command Line Interface.
Oracle VM for x86 server pools will be monitored using an SNMP based solution.
|
Oracle VM Manager with the Oracle VM Manager Command Line Interface has the broadest administration feature set available for Oracle VM for x86. For example, the Oracle Enterprise Manager Oracle VM Management Pack Plug-in does not a have comparable Command Line Interface to automate administrative functions.
Oracle VM Manager does not include monitoring. An SNMP based solution for monitoring Oracle VM servers is the best option since there are no additional software requirements.
|
|
Centralized logging for Oracle VM server agent logs and the Oracle VM Manager oc4j.log.
|
A central log host will be configured to capture the Oracle VM server agent logs and the Oracle VM Manager OC4J logs.
|
When things go wrong with an Oracle VM server pool, being able to quickly determine the “root cause” of an issue can eliminate or reduce down time. The most effective way to identify problems with an Oracle VM server pool is to analyze the Oracle VM Manager OC4J log and Oracle VM server' agent log files.
|
|
Rootkit prevention and monitoring
|
Each Oracle VM server will have the chkrootkit RPM installed.
|
Wikipedia describes a rootkit as” A rootkit is software that enables continued privileged access to a computer while actively hiding its presence from administrators by subverting standard operating system functionality or other applications.”
Monitoring systems for rootkits is fundamental part of information security that allows the detection of rootkits to prevent attacks and intrusions.
|
3.6 - Oracle VM for x86 Virtual Machine Operating Systems
|
Decision Point
|
Decision
|
Justification
|
|
Virtual Machine Operating Systems
|
A small number of virtual machine operating systems will be used.
|
Standardizing on a small number of virtual machine operating systems streamlines operations and increases 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.
|
|
Virtual Machine Operating System Versioning
|
In accordance with <Company Name>’s Application Software Policy and Application Software Standards, applications will determine the operating system type and version.
|
Each application has an operating system support matrix that lists the supported operating systems, patch levels, and software prerequisites.
In accordance with <Company Name>’s Application Software Policy and Application Software Standards, applications will determine the operating system type and version.
|
|
Virtual Machine Operating System Deployments
|
All new virtual machine operating systems will be deployed using a virtual machine template in accordance with <Company Name>’s Server Policy, and Server Security Policy.
|
A virtual machine template is a self-contained, preconfigured virtual machine with an operating system and optionally an application installed in accordance with <Company Name>’s Server Policy, Server Security Policy, and Operating System Installation Guidelines.
Each time a new virtual machine is deployed using a virtual machine template, <Company Name>’s standards are applied to each new virtual machine.
|
|
Patch Management
|
Linux virtual machines will be configured to use local custom yum repositories.
All patches will be regression tested in the lab environment before they are deployed on production systems.
High-priority patches, security fixes, and application upgrades updates will be applied as needed in accordance with <Company Name>’s Change Management Policy.
Noncritical fixes will be applied on a Quarterly basis in accordance with <Company Name>’s Change Management Policy.
All production systems will undergo security audits in accordance with <Company Name>’s Change Management Policy to validate configuration and patch compliance.
|
A key component of patch management is acquiring and vetting patches for production systems. Patches must be researched to identify which patches, security fixes, and application updates are applicable to your environment. Newly released patches, security updates, and application updates will be tested before being deployed in to production using time stamped local custom repositories.
Local yum repositories will be maintained for patch testing and production using a point-in-time static channel for each supported operating system to ensure all like operating systems are patched in a consistent manner across the organization.
Pre- and post-production audits will be conducted in accordance with <Company Name>’s Change Management Policy to validate configuration and patch compliance.
|
3.7 - Oracle VM for x86 Application Integration
|
Decision Point
|
Decision
|
Justification
|
|
Application Support
|
Applications must be supported by the independent software vendor (ISV) on the latest version of Oracle VM for x86 to be included in the Oracle VM for x86 environment.
|
Applications that are incompatible with and unsupported by Oracle VM for x86 cannot be supported by <Company Name> on Oracle VM for x86. Only applications with ISV support for the latest version of Oracle VM for x86 can be deployed and supported by <Company Name>, the ISV, and Oracle on Oracle VM for x86.
|
|
Application Requirements and Dependencies
|
Applications will be analyzed for requirements and dependencies and tested in accordance with <Company Name>'s Software Installation Standards.
|
Applications will be analyzed for requirements and dependencies and tested to ensure compliance with ISV specifications.
|
|
Application Installation, Packaging, and Distribution
|
Applications should be installed and packaged using Oracle VM Template Builder or Oracle Enterprise Manager.
Applications that are installed and packaged using Oracle VM Template Builder will be deployed as Oracle VM templates.
Applications that are installed using Oracle Enterprise Manager will be installed on Oracle VM templates.
|
Application installations that are packaged in Oracle VM templates or deployed using Oracle Enterprise Manager have a consistent installation configuration.
|
|
Application sunsetting
|
Applications will be sunsetted in accordance with <Company Name>'s Hardware and Software Sunset Policy
|
Applications 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.
Sunsetting applications that have reached the end of their life cycle results in better customer service and reduced costs.
|
|
Patch Management
|
All patches will be regression tested in the lab environment before they are deployed on production systems in accordance with <Company Name>’s Change Management Policy.
Noncritical fixes will be applied on a Quarterly basis in accordance with <Company Name>’s Change Management Policy.
All production systems will undergo security audits in accordance with <Company Name>’s Change Management Policy to validate configuration and patch compliance.
|
A key component of patch management is acquiring and vetting patches for production systems. Patches must be researched to identify which patches, security fixes, and application updates are applicable to your environment. Newly released patches, security updates, and application updates will be tested before being deployed in to production using time stamped local custom repositories.
Pre- and post-production audits will be conducted in accordance with <Company Name>’s Change Management Policy to validate configuration and patch compliance.
|
3.8 - Oracle VM for x86 Support Services
|
Decision Point
|
Decision
|
Justification
|
|
Oracle Support Agreement
|
Oracle Support Agreement for Oracle VM and Oracle Linux will be active and up to date.
|
Support is an integral part of every successful IT project. An Oracle support agreement is necessary to be able to receive RPM patches and updates for Oracle VM and Oracle Linux and to create and manage service requests.
|
|
On-site and Off-site support
|
On-site and off-site support from the implementing party will be used for maintenance, site reviews, upgrades, and security audits.
|
On-site and off-site support from the implementing party for problem resolution, system maintenance, site reviews, upgrades, and security audits augments the Oracle support agreement and internal IT operations staff.
|
