Oracle VM

Published in OpenWorld, Virtualization by jsimmons Sunday November 18, 2007

One of the big announcements at Oracle OpenWorld last week was Oracle VM. I’m a big fan of virtualization and have worked a lot with VMWare, but honestly I’ve never paid much attention to Xen (which Oracle VM is based on).

Here’s some item’s I found interesting:

Oracle VM (based on Xen) requires the linux guest OS to be modified with paravirtualization drivers, Windows requires Hardware Assist and will likely run slower then OEL or RedHat until suitable paravirtualization drivers are delivered.

From: VMWare’s “A Performance Comparison of Hypervisors”

The full virtualization approach allows datacenters to run an unmodified guest operating system, thus maintaining the existing investments in operating systems and applications and providing a nondisruptive migration to virtualized environments. VMware uses a combination of direct execution and binary translation techniques to achieve full virtualization of an x86 system

The paravirtualization approach modifies the guest operating system to eliminate the need for binary translation. Therefore it offers potential performance advantages for certain workloads but requires using specially modified operating system kernels. The Xen open source project [and there by Oracle VM] was designed initially to support paravirtualized operating systems. While it is possible to modify open source operating systems, such as Linux and OpenBSD, it is not possible to modify “closed” source operating systems such as Microsoft Windows . It is also not practical to modify older versions of open source operating systems that are already in use. As it turns out, Microsoft Windows is the most widely deployed operating system in enterprise datacenters. For such unmodified guest operating systems, a virtualization hypervisor must either adopt the full virtualization approach or rely on hardware virtualization in the processor architecture.

The hardware virtualization support enabled by AMD-V and Intel VT technologies introduces virtualization in the x86 processor architecture itself. While first-generation hardware assist support includes CPU virtualization only, later generations are expected to include memory and I/O virtualization as well. The emergence of virtualization hardware assist reduces the need to paravirtualize guest operating systems. In fact, Xen vendors such as Virtual Iron have announced that they are supporting only full virtualization using AMD-V and Intel VT processors and are not supporting paravirtualization

It looks like paravirtualization and hardware assist are the future for the hypervisor until then check out:

Ten Reasons Why Oracle Databases Run Best on VMware (this is an interesting read but it does point out that a lot of important features relative to Oracle are not coming until the 3.5 ESX release)

When Logging Off Crashes Your OC4J Container

Published in App Server by jsimmons Thursday November 1, 2007

Dan and I were at a client whose custom OC4J Containers running in Windows 2003 SE on VMWare were crashing randomly. To make the situation more complex the default containers (Home and WebCenter) from Oracle were not crashing.

Eventually we correlated the bulk of the OC4J crashes to admins logging out of VMWare Console and Remote Desktop with /console option.

Turns out that when you create a custom OC4J container in Application Server Control Oracle does not include -Xrs as a Java option even though it is included with the standard containers they deliver with 10.1.3.x.

The -Xrs option tells the JVM to ignore most signals from the OS level otherwise the JVM will exit thereby unexpectedly terminating the OC4J container and all running threads running within it.

Based on this Metalink article this appears to be a known issue since at least 2003. Maybe in 11g Oracle will include this option by default.
Subject: Unexpected JVM Termination in Response to Logout From Windows Console
Doc ID: Note:245609.1
Last Revision Date: 11-AUG-2003

Below is a snippet of the Java application launcher detail on the -Xrs option

-Xrs
Reduces usage of operating-system signals by the Java virtual machine (JVM). This option is available beginning with J2SE 1.3.1.

In J2SE 1.3.0, the Shutdown Hooks facility was added to allow orderly shutdown of a Java application. The intent was to allow user cleanup code (such as closing database connections) to run at shutdown, even if the JVM terminates abruptly.

The JVM watches for console control events to implement shutdown hooks for abnormal JVM termination. Specifically, the JVM registers a console control handler which begins shutdown-hook processing and returns TRUE for CTRL_C_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT.

The JVM uses a similar mechanism to implement the pre-1.2 feature of dumping thread stacks for debugging purposes. Sun’s JVM uses CTRL_BREAK_EVENT to perform thread dumps.

If the JVM is run as a service (for example, the servlet engine for a web server), it can receive CTRL_LOGOFF_EVENT but should not initiate shutdown since the operating system will not actually terminate the process. To avoid possible interference such as this, the -Xrs command-line option has been added beginning with J2SE 1.3.1. When the -Xrs option is used on Sun’s JVM, the JVM does not install a console control handler, implying that it does not watch for or process CTRL_C_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, or CTRL_SHUTDOWN_EVENT.

There are two consequences of specifying -Xrs:

* Ctrl-Break thread dumps are not available.
* User code is responsible for causing shutdown hooks to run, for example by calling System.exit() when the JVM is to be terminated.

Jeremy Simmons
PIOCON Technologies Logo

36 queries. 0.381 seconds.
Powered by Wordpress
theme by cmoanz