# Configuration and User Guide

# Configuration Overview and Roadmap

The following sections provide an overview of a sample WebLogic Server Virtual-Edition (WLS-VE) configuration, describe the main components in the configuration, and summarize the main tasks required to successfully install and configure WLS-VE:

- Configuration Overview
- Roadmap for Configuring a WLS-VE Domain
- Comparing Startup, Configuration, and Logging Options to Non-virtualized WLS

## Configuration Overview

To successfully configure and use WLS-VE, it is important to understand the overall architecture and components of a WLS-VE configuration. Figure 1-1 provides a sample configuration consisting of two WLS-VE instances in a virtual environment.

Figure 1-1 Sample WLS-VE Configuration on WLS 10. 0 MP1

Table 1-1describes the components of the sample WLS-VE configuration.

Table 1-1 WLS-VE 10 Configuration Components
Component | Description
--- | ---
Launcher Machine | The Windows or Linux machine where the WebLogic domain resides and where you unpackage the WLS-VE distribution archive. It is also the machine on which you run the LiquidVM Configuration Wizard, the P2V Domain Conversion utility, and initiate the creation of WLS-VE instances on the VMware ESX machine. The WLS-VE distribution archive includes LiquidVM 1.2, which provide the tools needed to create, control, and start LiquidVM instances. The archive also includes an ISO image for WebLogic products. For example, the WLS ISO image contains the WLS classes and LiquidVM executables used to run WLS-VE and the applications on the hypervisor host (VMware ESX server). This ISO image must be copied to the hypervisor host from the launcher machine. LiquidVM 1.2 also provides an SSH service which provides a secure mechanism to transfer files, including WebLogic domains, to and from the LiquidVM instance on the hypervisor host.
VMware VirtualCenter | The primary controller for configuring and managing the virtual environment. Users can connect to the VirtualCenter server using the Virtual Infrastructure Client (VI Client). The VI Client is only supported on Windows platforms, therefore there must be at least one Windows machine in your configuration. The BEA tools on the launcher machine interface with the ESX environment through the VirtualCenter server.
VMware ESX Server | The hypervisor machine with VMware installed that is available for the creation of virtual machines. The LiquidVM launcher accesses the ESX server through the VirtualCenter server.
Virtual Infrastructure | The full infrastructure virtualization suite that provides the hardware and software resources required to support a virtualized environment.
WLS-VE instances | Virtual WLS instances running on the ESX server. The WLS-VE 10 LiquidVM includes a virtual local disk, which can be mapped to the SAN, for each WLS-VE instance. You can transfer files to and from the local disk using the SSH service.
SAN Disk | Recommended physical storage device for the ISO image and the local disks on the WLS-VE instances.

## Roadmap for Configuring a WLS-VE Domain

The following section summarizes the overall process for installing and configuring WLS-VE, depending on whether you are either:

- Installing a WebLogic product from scratch and configuring a domain, and then using WLS-VE to virtualize the domain.
- Using WLS-VE to virtualize an existing WebLogic domain.

The procedures for downloading and unpacking the WLS-VE distribution archive are documented in Accessing and Using the WLS-VE Distribution Archive. Subsequent sections of this document provide details for configuring and using WLS-VE.

### Converting a Physical Domain to a Virtual Domain

Table 1-2 describes that main steps required to convert an existing WLS 10.0 MP1 domain to a corresponding virtual domain on the VMware ESX machine.

Table 1-2 Roadmap for Configuring and Using WLS-VE
Step | Description
--- | ---
Create a new physical domain or make a copy of an existing domain. | If necessary, configure a new domain—The Physical-to-Virtual (P2V) Domain Conversion utility only converts physical WebLogic domains and Managed Servers into virtual instances. Complete details for creating WebLogic domains is provided in Creating WebLogic Domains Using the Configuration Wizard. Make a copy of the existing domain—For existing WebLogic 10.0 domains, make a copy of the entire domain, and use the back-up copy of the domains’ configuration file (`config.xml`) for the necessary editing and transferring of domain artifacts to the virtual environment.
Make sure the physical domain is ready for virtualization. | The P2V utility does not handle out-of-domain dependencies, such as referenced libraries, nor does it modify the domain configuration file (`config.xml`) or any other files under the domain directory. Therefore, any path references that are valid only for the local physical machine must be modified with respect to the LVM file system path. Also, if server instances in the domain use the `ListenAddress` attribute, the address must be removed for that server to be virtualized. See Preparing an Existing WebLogic Domain for Virtualization.
Generate an SSH key-pair | If public key authentication is to be used for SSH connections to LVM instances, then generate an SSH key-pair on the launcher machine using a tool such as `ssh-keygen`.
Note: | Only RSA format is supported, so the public key string must begin with `ssh-rsa`.
Download and unzip the WLS-VE distribution archive. | Details about downloading and unpacking the distribution archive are provided in Accessing and Using the WLS-VE Distribution Archive.
Copy the ISO image to the ESX server. | Details about the copying the ISO image are provided in Copying the WLS-VE ISO Image.
Configure the LiquidVM connection parameters. | On the launcher machine where the WebLogic domain resides, run the LiquidVM Configuration Wizard to configure the connection between the LiquidVM tools running on the launcher machine and the hypervisor environment (Virtual Center and ESX server). For details, see Configuring LiquidVM Connection Parameters
Convert the WebLogic domain to a virtualized domain. | On the launcher machine, run the P2V Domain Conversion utility to convert the physical WLS 10.0 MP1-based domain (or selected servers in the domain) to a virtual domain in the hypervisor environment. The P2V utility makes sure that the domain, patches, and connection information is available for the new WLS-VE instances. For details, see Using the P2V Domain Conversion Utility.
Note: | In many cases, additional steps are required to complete the transformation of physical WebLogic domains into virtual domains.
Use the P2V-generated start scripts to complete the configuration and start the WLS-VE instances. | The P2V utility generates WLS-VE start scripts in the domain directory on the launcher machine. You must run these start scripts to complete the configuration process and start the new WLS-VE instances, as described in Run the P2V-Generated Start Scripts.
If necessary, copy additional files to the WLS-VE instances. | If additional files need to be copied to a WLS-VE instance, such as application files than are stored outside the domain, use the LiquidVM SSH service to securely copy them to the hypervisor environment. See Copying Domain Artifacts Using the LiquidVM SSH Service.
Administer the WLS-VE environment. | To administer the WLS-VE environment, see the following topics: Working with WLS-VE Using the VMware VI Client Configuring Logging Moving a WLS-VE Domain to a Production Environment Securing Your Production Environment Tuning the WLS-VE LiquidVM Kernel Diagnostics and Troubleshooting

## Comparing Startup, Configuration, and Logging Options to Non-virtualized WLS

If you have experience using non-virtualized WLS 10.0 MP1, you might want to use some of the configuration techniques common to that product. If so, you need to be aware that some of techniques with which you are familiar will not work with WLS-VE. For example:

- Some customers prefer to use a script to configure their environment before running WLS. You can do this only on a standard operating system before starting the WLS-VE instance. You cannot run scripts on the WLS-VE instance itself.
- In a physical WebLogic domain, the encrypted administrator user name and password, which are stored in the domain directory in the `boot.properties` file, can be passed on the command-line when booting the Administration Server. WLS-VE does not provide an interactive prompt, however, so you cannot specify credentials when the virtual server is starting. Therefore, if you want to use these credentials for the virtual domain, the `boot.properties` file must be available when using the P2V utility to virtualize the domain. See Using the P2V Domain Conversion Utility.
- You can track the progress of WLS-VE by viewing the log files. The following types of log files are generated:

- Server logs
- LiquidVM console logs

By default, both the server and LiquidVM console log files are created on the local disk of the WLS-VE instance. VMware logs are also created and stored on the ESX server.

To view the log files on the WLS-VE instance’s local disk, the instance must be running in passive mode with SSH enabled. Then you can copy them to your local machine using SSH, use a remote syslog collector, or put the logs on an NFS share. For more information, see Configuring Logging.

- If the Administration Server will use a fixed IP address, you need to specify it when you convert the physical domain using the P2V utility. If you do not specify an IP address, DHCP assigns one from the available network addresses. The static IP or the IP obtained using DHCP for the Administration Server will be used as the host address in the `admin_url` parameter set in the Managed Server start scripts that are generated by the P2V utility.

Note: | If DHCP is selected in the P2V utility for the Administration Server, then no IP address will be set in the generated start scripts and LVM will query the DHCP server to obtain an IP address. If the IP address’s time-to-live has expired, then LVM can get a new IP address. Therefore, BEA does not recommend using DHCP for the Administration Server because in such a situation the `admin_url` parameter in the Managed Server’s start script will be invalid. If DHCP is used, your network administrators must guarantee that the Administration Server gets a fixed IP from the DHCP server.