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:
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.
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.
For example, perform the following steps:
Remove any application-specific configurations to be re-created later.
Use default values for configuration files.
Ensure that you reset any Oracle Solaris OS configuration information such as system name, network configuration, and passwords. This configuration information is later supplied by property values and configuration scripts.
Export any zpools other than the root file system so that they can be recognized by new domains.
After you take these steps, you can shut down the domain and run the ovmtcreate utility to create a template from the domain.
Specifying the name of the template. Use 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 deploymment. 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.
The required services include the following:
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:
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.
These actions do not typically include 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.
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.
![]() | 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. To work around this issue, manually remove the domain variable after you have deployed the guest domain and the application is fully configured. A domain variable is prefixed with the OVMTVAR_ID string, where ID is four digits. This example shows a domain variable declaration for the system netmask: OVMTVAR_1006=ovmt.prop.key.com.oracle.solaris.network.netmask.0=24. From the control domain, use the ldm list-variable | grep OVMTVAR_ command to list the domain variables. Then, remove any variables with sensitive information by using the ldm remove-variable OVMTVAR_ID command. |
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.
At this point, the domain should be fully configured and operational.