Configuration and User Guide

Creating Virtual WebLogic Domains

The following topics describe the procedures to create virtual WebLogic domains and also provide additional configuration information:

Overview

The Physical-to-Virtual (P2V) Domain Conversion utility for WebLogic helps simplify the conversion of WLS Managed Servers in a domain to WLS-VE instances in the hypervisor environment, as follows:

The P2V utility packages up the following WLS artifacts:

The P2V utility also generates start scripts in the domain directory on the launcher machine to complete the configuration and start the newly generated WLS-VE instances. A sample WLS-VE configuration is illustrated and described in the Configuration Overview.

Before You Begin

Before attempting to configure and run WLS-VE, ensure the following:

Preparing an Existing WebLogic Domain for Virtualization

When you convert from a non-virtualized implementation of a WLS 10.0 MP1 domain to a WLS-VE domain, you may need to make some modifications to the domain’s configuration file (config.xml) and/or application code to ensure successful operation.

Out-of-Domain Dependencies

The P2V utility does not handle out-of-domain dependencies, such as referenced libraries, nor does it modify the WLS domain configuration file (config.xml) or any other files under the domain directory. Therefore, any path references in the config.xml that are valid only for the local physical machine must be modified with respect to the LVM file system path using the UNIX-style path convention, as follows:

ListenAddress

If server instances that are to be virtualized use the ListenAddress attribute (including the ListenAddress attribute in any configured NetworkAccessPoint), you must remove the address for those servers so that WLS automatically binds to the IP address of LVM.

WLST connect()

If an application uses default values for the host in the WLST connect() command, you will need to change it so that the hostname can be passed in.

Using the P2V Domain Conversion Utility

The following steps explain how to use the P2V Domain Conversion utility to convert the physical WLS instances in the domain to WLS-VE instances in the hypervisor environment. You create one such instance for each Managed Server (and optionally the Administration Server) in the domain.

Complete details for creating WebLogic domains is provided in Creating WebLogic Domains Using the Configuration Wizard.

What’s Next?

As shown in Roadmap for Configuring a WLS-VE Domain, the next step in the process is to start new virtual servers using the WLS-VE start scripts generated by the P2V utility, as described in Run the P2V-Generated Start Scripts:

Run the P2V-Generated Start Scripts

As shown in Roadmap for Configuring a WLS-VE Domain, the next step to complete the configuration process is to run the server start scripts in the /virtual directory generated by the P2V utility, as shown in Table 5-3:

where DOMAIN_NAME is the directory name of the domain that was selected for virtualization, typically BEA_HOME\user_projects\domains\DOMAIN_NAME.

Initially, the scripts must be run from a command-line to complete the P2V configuration process, as follows:

The startup scripts also call the commonVEStart.cmd startup script in the /virtual directory. Therefore, when you start a WLS-VE instance, LiquidVM boots (in active mode) and simultaneously boots the associated server.

For more information about starting and stopping WLS-VE instances after the initial startup, see Starting and Stopping WLS-VE.

What’s Next?

As shown in Roadmap for Configuring a WLS-VE Domain, the next step, if necessary, is to copy domain-related files to the local disk of the LVM instance on the ESX server using the SSH service provided by the LVM. For details, see Copying Domain Artifacts Using the LiquidVM SSH Service.

Copying Domain Artifacts Using the LiquidVM SSH Service

After you have created and started the new WLS-VE instances, you can copy any application files not stored in the domain directory (that is, referenced applications) to the instances using the SSH service provided with LiquidVM. This may be necessary because the P2V utility does not handle out-of-domain dependencies, such as referenced libraries.

For a description of all the P2V-generated start script parameters, see The P2V-Generated Start Script Properties.

To copy files to a virtual server using the LiquidVM SSH service, follow these tasks.

Task 1: Start LiquidVM in Passive Mode

When you start LiquidVM in passive mode, only the LiquidVM services, including the SSH service, are started. To start LiquidVM in passive mode, you need to set the LVM_startMode=passive option in the start script arguments and start LiquidVM as described in the following steps.

Task 2: Copy the Files to the WLS-VE Instance

Use an SSH-2 compatible file transfer client of your choice, such as scp or sftp, to login to the SSH service and transfer the necessary files. Note the following:

Task 3: Shut Down the LiquidVM Instance

You can shut down the LiquidVM instance using the VMware VI Client as follows:

For more information about using the VI Client, see Working with WLS-VE Using the VMware VI Client.

Task 4: Re-start the WLS-VE Instance

What’s Next?

As shown in Roadmap for Configuring a WLS-VE Domain, after you have successfully started your WLS-VE instance from the command-line, you can start and stop the servers, and administer the WLS-VE environment as required. See Starting and Stopping WLS-VE.

Configuring a Virtual Domain to Access an NFS Server

After using the P2V utility to convert a physical domain to a virtualized domain, you must manually configure any NFS connections. Before doing so, make sure that both your ordinary OS and your WLS-VE instance have access to the same NFS-share.

For details about generating a WebLogic 9.2 domain to an NFS share, see “Configuring and Starting WLS-VE Domains” in version 1.0 Installation and Configuration Guide.

Moving a WLS-VE Domain to a Production Environment

You use the same procedures to move a WLS-VE domain from a development environment to a production environment that you use for standard WLS domains. Ensuring your environment is secure is critical in a production environment. For important security recommendations, see Securing Your Production Environment

Additional Configuration Tasks

Since WLS-VE contains both a JVM and a virtualized WLS instance, you can configure both devices by using the same configuration flags used by their non-virtualized editions. Usually, you can do this from the WLS Administration Console. Refer to System Administration for BEA WLS 10.0 for complete information on how to:

Tuning LiquidVM

The JVM should already be well-tuned for most WLS applications but you can configure and tune the Java behavior of a machine by setting the necessary Java options in the start-up script for the domain in question. Simply enter the standard J2SE start-up options or BEA JRockit’s non-standard -X and -XX options at the JAVA_OPTIONS= statement.

Listing 5-1 shows a snippet of the Administration Server start-up script, startAdminServername.sh/cmd, with JAVA_OPTIONS= highlighted.

@ECHO OFF
SETLOCAL
.
.
.
set PRE_CLASSPATH=
set POST_CLASSPATH=
set JAVA_OPTIONS=
set JAVA_PROPERTIES=

For example, suppose you want to start the machine so that LiquidVM uses a garbage collector (that is, a memory management system) optimized for application throughput. You would do this by setting JAVA_OPTIONS as follows:

JAVA_OPTIONS=“-xgcprio:throughput”

You can string together as many valid options as you need; however, you must place them within quotation marks and separate them with a single space. For example, the following code:

JAVA_OPTIONS=“-xgcprio:throughput -xgcreport -Xss:512k”

tells the JVM to:

See the BEA JRockit Command Line Reference for a list of valid LiquidVM start-up options and instructions for using them. For LiquidVM tuning and configuration guidelines, see Profiling and Performance Tuning in the BEA JRockit Diagnostics Guide.

Deploying an Application to WLS-VE

Deploy applications on WLS-VE the same way you deploy them on non-virtualized WLS. Application deployment generally involves the following tasks:

These tasks are detailed in Deploying Applications on BEA WebLogic Server 10.0.