Oracle VM Server for SPARC Template Lifecycle

Language:

This section describes each stage of the template creation process, the actions that are taken, and how to use the Oracle VM Server for SPARC template utilities to assist in the process:

Note - The creation and development of templates with applications and first-boot scripts is an iterative process. Take care to synchronize all aspects of the configuration by using a source code management system to manage the scripts and properties.

The following describes the stages of the template-creation process, the actions that are taken, and how to use the Oracle VM Server for SPARC template utilities to assist in the process:

Authoring a template. While pre-built, generic templates are available, you can create a custom template from an existing domain. This domain must have all of the operating system components, application software, and other utilities that you want fully installed.

Typically, the environment is configured as fully as possible, with only a small number of actions required to finalize the environment. Any domain settings such as memory, virtual CPU, virtual networking, and disks should reflect the deployment that you want.

At this stage, you create one or more “first-boot” scripts. Include these scripts in the environment that performs the final configuration based on the properties that you supply. Be sure to record and describe these properties in a README file for each template.

Note - If any first-boot scripts access domain variables, ensure that the ovmtprop utility is installed in the guest domain.
Creating a template. Before you create a template, ensure that the source domain environment is not configured so that it can be configured later by prescribed actions that are often part of the first-boot scripts.
- Remove any application-specific configurations to be re-created later.
- Use default values for configuration files.
- Export any zpools other than the root file system so that they can be recognized by new domains.
- Revert the operating system to an unconfigured state so that it is ready to accept configuration properties on its first boot after deployment from a template. Run the following command to remove any site-level customizations, unconfigure, and halt the operating system:
```
# sysconfig unconfigure -g system -s --include-site-profile --destructive
```
After you take these steps, run the ovmtcreate command to create a template from the domain.

Note - If you run this command and no properties are supplied at deployment time, the system runs the Oracle Solaris Interactive Installer on the next boot.
Specifying the name of the template. Use a consistent convention to identify the template, such as the following format:
```
technology.OS.application.architecture.build.ova
```
For example, the following template name is for a domain that runs build 2 of the Oracle Solaris 11.2 OS on a SPARC platform and that runs version 12.1.2 of the WebLogic server: OVM_S11.2_WLS12.1.2_SPARC_B2.ova
Distributing the template. The template is a single file with a .ova extension. The file contains the compressed disk images and the metadata that are required for deployment. The template also contains a manifest file of payload file checksums, which might be combined with an overall archive checksum to validate that the content has not been changed since distribution.

You can distribute the template by using web-based services or maintain a central repository rather than duplicating templates.
Deploying the template. Because the template captures only those aspects of a system that are seen by the source domain, you must understand which services must be present to support the deployment of the template.
- One or more virtual switches to appropriate interfaces to which virtual networks from the template might be attached
- Virtual disk services
- Console services
- Sufficient virtual CPU and memory to accommodate the template requirements
While the ovmtdeploy utility can override many of these settings, the minimum values that are supplied with a template represent the baseline requirements.

You can use the ovmtdeploy utility to automatically extract, decompress, and copy the virtual disks to deployment directories, and to build the various virtual devices that the template describes.

At this point, you could start the domain but you might need to perform some manual configuration steps by using the domain console before the domain is fully functional.
Automatically configuring the domain. The configuration of a domain that is created by a template consists of several types of actions. For example, you might specify property name-value pairs to provide first-boot scripts with the information to configure. You might also back-mount virtual disks to the control domain to perform actions on the domain file systems such as copying configuration files.

The ovmtconfig utility automates these domain-configuration activities and enables you to specify the actions to take and the properties to use to configure a domain by specifying one or more command scripts and property files.

To configure the Oracle Solaris OS, the ovmtconfig utility back-mounts the domain's root file system and creates an sc_profile.xml file from the supplied configuration scripts and properties. This profile enables the Oracle Solaris OS to configure itself on first boot.

First configuration. Following the successful configuration of the Oracle Solaris OS and first boot, you must configure any installed applications. During the configuration phase, the ovmtconfig utility passes configuration information to the deployed domain by using one of the following methods:

Domain variables – In addition to a local properties file, you can set domain variables by running the ovmtconfig utility in the control domain that can then be used by the ovmtprop utility in the guest domain. This method enables first-boot scripts to access the properties directly and provides configuration information directly to the guest domain after the configuration completes.

For example, you might automate a change of a configuration aspect that does not have network access by using a supervisor script that runs ovmtprop in the guest and by running ovmtconfig -v from the control domain.

Direct action – The ovmtconfig utility back-mounts the guest domain file systems to the control domain and takes direct action on the files and file systems. Actions might include the creation of configuration files or the copying of system binaries. These actions are described in the scripts that you supply to the ovmtconfig utility. You can find scripts that perform command actions in the /opt/ovmtutils/share/scripts directory.

Note - These actions do not typically include first-boot processes that are designed to run in the guest domain because such actions might affect the control domain.

Use the ovmtconfig -c command to specify the commands to run.

Caution - Do not use unencrypted properties to pass sensitive information to the domain such as passwords. Properties other than those that are used to configure the Oracle Solaris OS are passed to the domain as ldm variables in clear text. These property values are visible to a user on the control domain who is authorized to execute ldm commands and to a user who is logged in to the deployed domain.

At this point, the domain should be fully configured and operational.