# Overview

# WebLogic Server Virtual Edition Overview

WLS-VE is a Java application server that is optimized for running in virtualized computing environments. The following sections describe the features of WLS-VE:

- Using WLS-VE to Leverage Your Virtualized Environment
- Comparison of WLS with WLS-VE
- Environment Requirements
- Recommended Topology
- Licensing WLS-VE
- Downloading an Evaluation Copy
- Related Documentation

## Using WLS-VE to Leverage Your Virtualized Environment

WLS-VE combines WebLogic Server (WLS) with LiquidVM, a Java Virtual Machine (JVM) that works with hypervisor software and provides only the set of operating system (OS) features that WLS needs to offer its full range of services. Because hypervisor software recognizes LiquidVM as a guest OS, WLS-VE offers life-cycle control and monitoring features that are unavailable with other application servers.

In addition, WLS-VE removes layers of the software stack (see Figure 1-1), which reduces the number of software installations to license, patch, and monitor. This also makes it possible to avoid some of the performance degradation that is common in virtualized data centers.

Figure 1-1 WLS-VE Removes Layers of the Software Stack

### LiquidVM OS Features

While application servers can consume large amounts of computing resources, even full-featured Java Platform, Enterprise Edition (Java EE) application servers such as WLS use only a subset of the services that a standard OS provides.

For example, while a standard OS typically provides a user interface (either a graphical user interface or a command-line interface), Java EE application servers do not need such services. Instead, application servers rely on the OS mostly for networking and file-system services, and they rely on the JVM for most other services, such as translating Java code into hardware-specific instructions, managing memory, and scheduling threads.

In a virtualized software stack, the responsibilities of the JVM and OS are unchanged, but an additional layer of software—the hypervisor—resides between the OS and the hardware. The hypervisor coordinates low-level calls from multiple OSes that are running on a single physical machine. To fill its coordinating role, the hypervisor provides hardware-specific device drivers and other hardware-specific services.

LiquidVM provides the JVM services and operating-system services that WLS needs to offer its full set of services, and it relies on hypervisor software to provide hardware-specific device drivers and other hardware-specific services (see Figure 1-2).

Figure 1-2 LiquidVM OS Features

### Benefits of WLS-VE

WLS-VE offers the following advantages over running WLS in a Windows or UNIX guest OS within a virtualized environment:

- Less disk space

Because LiquidVM contains only a fraction of the services and programs of a standard OS, WLS-VE requires significantly less disk space than a stack of WLS, JVM, and a standard OS.

- Less memory

Because LiquidVM provides basic operating-system services, WLS-VE instances consume only as much memory as required for basic operations. A virtual machine that runs WLS-VE does not need to reserve memory for the hundreds of programs that are in a standard OS but are unused by WLS.

- Greater efficiency

Because WLS-VE uses less disk space and less memory, you can operate more virtual servers on the same physical server without noticeably affecting the performance of any of the individual servers.

- Improved disk I/O performance

The availability of a virtual local disk for each virtual machine removes the dependence on NFS and provides faster and more secure file transfers.

- Faster hibernate and resume cycles

Hypervisor software can take a snapshot of a virtual machine's state, write the state to disk, and then use the state data to restart the machine exactly as it was at the time of the snapshot.

Because LiquidVM instructs the hypervisor to store only the JVM data that is needed to restore WLS-VE's state, the snapshot of a machine that runs WLS-VE is significantly smaller than snapshots of machines with other JVMs. This smaller snapshot requires less time to write and read from disk.

- Improved security with smaller footprint, OOTB secure configuration, and SSH service

WLS-VE has fewer opportunities for security incursions than with standard OSes. This is because Liquid VM requires only low-level services and few configuration parameters, including a default secure configuration. WLS-VE also includes an SSH service for securely transferring files, including WebLogic domains, to and from the LiquidVM instance on the hypervisor host.

#### Manage Your Applications as Software Appliances

In a virtualized environment, a software appliance is a pre-configured software stack that the hypervisor can start, stop, hibernate, and resume. Some software vendors package software appliances as a single file. WLS-VE includes utilities that enable you to manage a WLS-VE application stack as a software appliance, even though your application and WLS-VE are packaged as a collection of files (see Figure 1-3).

To configure your WLS-VE-hosted application to run as a software appliance, you create a WLS domain and deploy your applications onto the WebLogic managed servers in the domain. Then you use WLS-VE utilities to configure a VM that will run one of the managed servers in your domain. You create one such pre-configured virtual machine for each managed server in the domain.

Figure 1-3 WLS-VE Applications as Software Appliances

#### Application Versioning and Patching Model for WLS-VE Appliances

Because WLS-VE, domains, and applications are packaged as separate files, you can deploy a new version of your application without stopping your appliances and without interrupting your application's clients. (See Deploying Applications to WebLogic Server in Deploying Applications to WebLogic Server.)

In addition, as with WLS, you can use the BEA rolling upgrade process to install BEA patches for your WLS-VE appliances without shutting down the entire domain or cluster (see WebLogic Server Rolling Upgrade in Upgrading WebLogic Application Environments).

#### Which Application Types Benefit from WLS-VE?

Applications that never or only occasionally experience performance barriers due to lack of CPU, memory, or networking resources are good candidates for running in a virtual environment and are therefore good candidates for WLS-VE. For these applications, deploying and serving from WLS-VE is indistinguishable from WLS.

Applications that frequently experience performance barriers due to lack of CPU, memory, or networking resources usually require dedicated hardware resources and are not good candidates for running in a virtual environment or on WLS-VE. See Determining Appropriate Applications for WLS-VE in the WLS-VE Installation Guide.

#### WLS-VE in Production or Testing Environments

WLS-VE delivers the same high-availability, security, and deployment features of WLS that are required for production environments, and its support for virtual environments enables you to maximize the use of the computing resources in your data center.

In a testing (QA) environment, WLS-VE simplifies the process of configuring machines or entire collections of machines for running tests. Using a single script, QA engineers can instantiate an entire WLS domain running on machines with pre-configured amounts of memory, CPU, and network resources. When the tests have completed, another script can reconfigure the same physical machines for additional tests that use different amounts of computing resources.

### Limitations of WLS-VE

Note the following limitations when using WLS-VE:

- WLS-VE is a platform for production and testing environments, not for development environments.

The WLS-VE installation package does not include WebLogic Workshop or the WLS samples.

- WLS-VE is the only process that can run in a VM that runs LiquidVM as a guest OS. For example:

- You cannot run Microsoft Windows in the VM that hosts WLS-VE, so your applications cannot use DCOM/ActiveX to access Microsoft Office applications.
- You cannot use BEA Node Manager.
- You cannot use startup scripts or classes that attempt to start additional processes on the same machine but outside the JVM (such as a database, a Perl script, or monitoring software). For example, you cannot start a Perl script by invoking `System.exec` from your WLS.
- You cannot use Type 2 JDBC drivers. Instead, use Type 4 drivers.

- BEA Node Manager cannot be used with WLS-VE; therefore:

- You cannot start, suspend, or resume managed servers from the administration console. But you can still stop servers from the administration console.
- You cannot perform server migration from WLS-VE.
- You cannot perform service migration in WLS-VE.

Tip: | VMware's Virtual Infrastructure provides similar Node Manager functionality to suspend or resume virtual servers and perform virtual machine migration.

- WLS-VE and applications that run in WLS-VE cannot execute non-Java (native) code.

## Comparison of WLS with WLS-VE

Table 1-1 compares how managed servers are distributed on hardware with WLS and WLS-VE.

Table 1-1 Distribution of Managed Servers
WLS in Non-Virtualized Environment | WLS in Virtualized Environment | WLS-VE
--- | --- | ---
On a single machine, you can run multiple managed servers and you can run multiple additional processes. | On a single machine, the hypervisor layer enables you to run multiple VMs. Each VM runs a full guest OS, which can host multiple managed servers and additional processes. | On a single machine, the hypervisor layer enables you to run multiple VMs. Each VM runs only WLS-VE, which includes its own guest OS, a WLS instance, and one or more Java applications.

Table 1-2 compares the location of file storage for WLS and WLS-VE.

Table 1-2 Location of File Storage
WLS in Non-Virtualized Environment | WLS in Virtualized Environment | WLS-VE
--- | --- | ---
All artifacts related to WLS (BEA classes, domain configuration documents and runtime caches, application classes, descriptors, file stores, and log files) can reside on local disk or network-attached storage (NAS). | All artifacts related to WLS can reside on the virtual machine's virtual disk, which can be implemented as a local disk, SAN, or NAS. | WLS-VE classes are packaged in a file that conforms to the ISO standard for CD-ROM images (ISO 9660). This ISO image file can reside on the local disk of the hypervisor's host machine, SAN, or NAS.

Table 1-3 compares life-cycle control options for WLS and WLS-VE.

Table 1-3 Life Cycle Control
WLS in Non-Virtualized Environment | WLS in Virtualized Environment | WLS-VE
--- | --- | ---
To start WLS instances, you can do any of the following: Log on to the host machine and run a startup script. Configure the OS to run WLS as a Windows service or daemon. Use Node Manager. You can also configure Node Manager to restart a server when the server's health has failed. | To start WLS instances, you can do any of the following: Log on to the VM's guest OS and run a startup script. Configure the guest OS to run WLS as a Windows service or daemon. Use Node Manager. You can also configure Node Manager to restart a server when the server's health has failed. | To start a WLS-VE appliance, you can use either of the following: A WLS-VE startup script. The hypervisor's management console. You cannot use Node Manager or the WLS Administration Console to start or manage WLS-VE appliances.
To stop servers, you can: Use the WLS Administration Console. Use Node Manager. | To stop servers, you can: Use the WLS Administration Console. Use Node Manager. Note that the VM and its guest OS continue to consume resources until you use the hypervisor to stop the VM. | To stop a WLS-VE appliance, you can: Use the WLS Administration Console.
| The hypervisor software makes it possible to suspend (hibernate) and resume an entire VM. | The hypervisor software makes it possible to suspend (hibernate) and resume an entire VM. LiquidVM facilitates this process by instructing the hypervisor to store only the JVM data that is needed to restore WLS-VE's state.

## Environment Requirements

Before planning any WLS-VE 9.2 v1.1. implementation, you must verify that your environment has a supported configuration of hardware, operating system, application server, and database. See the BEA Products Supported Configurations documentation.

For instructions on installing WLS-VE, see the WLS-VE Installation Guide.

## Recommended Topology

While the combinations of hardware and software in data center environments can vary widely to support different business needs, BEA recommends the following general principles for the network topology of your production environments:

- Install WLS-VE on the local disk of the launcher machine, either Windows or Linux, to create the virtual machines on the VMWare ESX machine.

- The WLS-VE installation includes WebLogic Server 9.2 and LiquidVM 1.1, which provide the tools needed to create, control, and start WLS-VE and LiquidVM instances.
- The installation also includes an ISO image containing the WebLogic Server classes and LiquidVM executables used to run WLS-VE and the applications on the hypervisor host (VMware ESX server).

- Copy the WLS-VE ISO image to the physical local disk of each hypervisor's host machine.
- Create a WLS cluster of managed servers.
- Use the bundled SSH service to securely transfer files, including WebLogic domains, to and from the LiquidVM instance on the hypervisor host.
- To maximize use of computing power on available machinery, run multiple managed servers on a single machine.
- To ensure high availability, run at least one managed server on a separate physical machine.
- The Administration Server can run on any machine.
Figure 1-4 Recommended Topology

Configuring web servers and load balancers for WLS-VE is no different from WLS—when you configure a virtual machine, you assign it an IP address. Then you configure the web server and load balancer to listen for the IP addresses that you have assigned to the VMs in your cluster.

Configuration procedures are documented in WLS-VE Configuration and User Guide, which provides details for using, administering, and troubleshooting WLS-VE.

## Licensing WLS-VE

BEA licenses the number of WLS-VE instances that you can run concurrently in your organization. Unlike WLS licensing, WLS-VE licensing neither restricts the IP address nor limits the number of CPUs of the host machine. For example, if you purchase a license for a single instance of WLS-VE, you can run a WLS Administration Server and deploy your applications onto the Administration Server. You can run this WLS-VE instance on a machine with any IP address and with any number of CPUs. You can shut down this instance and restart it on another machine with a different IP address and a different number of CPUs. If you purchase a license for 10 instances, you can run a WLS Administration Server and up to nine managed servers concurrently.

When you install WLS-VE, the installation includes an non-expiring evaluation license that grants the ability to run up to five instances of WLS-VE concurrently.

## Downloading an Evaluation Copy

You can download WLS-VE from the BEA Downloads web site.

If you prefer to install from a DVD, contact a BEA sales representative.

## Related Documentation

For more information on installing, configuring, and administering WLS-VE, refer to the following documentation:

- For instructions on installing WLS-VE, see the WLS-VE Installation Guide.
- Configuration procedures are documented in the WLS-VE Configuration and User Guide, which provides details for using, administering, and troubleshooting WLS-VE.