Donnerstag Dez 03, 2015

Getting Started with OVM Templates for SPARC - Part 2: Creating a Template

The primary purpose of a template is to deliver an application "ready to run" in an environment that contains everything the application needs, but not more than necessary.  The template will be deployed multiple times and you will want to configure each deployed instance to give it a personality and perhaps connect it with other components running elsewhere.  For this to work, you will need to understand the configuration aspects of the application well.  You might need a script that does some or all of the configuration of the application once the template has been deployed and the domain boots for the first time.  Any configuration not done by such a script will need to be done manually by the user of the template after the domain has booted.  It is usually desirable to create templates in such a way that no further manual configuration is required.  I'll not cover how to create such first-boot scripts here.

(Note: This article is the blog version of the second part of MOS DocID 2063739.1 reproduced here for convenient access.) 

Here are the steps usually required to build a template:

  1. Create a new domain and install Solaris and the ovmt utilities.
  2. Define what properties will be needed to configure the application.
  3. Install and configure the application as much as possible.
  4. Write and test a first-boot script or SMF service that will read the values for these properties using the ovmt utilities and configures the application.
  5. Unconfigure Solaris in your domain and remove any temporary files, then and shut it down.
  6. Create the template. 
  7. Test your template.  Go back to any of the previous steps to fix issues you find.

Before we look at each of these steps using an example, here is a little background about how properties work in this context.

Properties for Your Template

Most applications require some sort of configuration before they are ready.  Typical configuration items might be TCP ports on which to listen for requests, admin passwords for a web user interface or the IP address of a central administration server for that application.  These are usually set during manual installation of the application.  Since the whole idea of an application template is that once you deploy it, the application is ready to run, there needs to be a way to pass these configuration items to the application during template deployment.  This is where properties come in.  Any configuration item that must be passed to the application at deployment time is defined as a property of the template.  This happens in a properties definition file that is bundled with the actual OS image to build the template.  Note that this file only contains the definition of these properties, not their values!  Properties are populated with values at deployment time.

You have already seen an example of how to pass such values to a template during deployment in the first part of this mini-series, when Solaris properties were passed to the template.

Properties are defined in a small XML file, as they themselves have various properties.  They have a name, which can be fully qualified or simple.  They have a data type, like number, text, selection lists etc.  These are covered in detail in the Template Authoring Guide.  For the simple example in this article, we will use text properties only.

During deployment, you pass values for these properties to the target domain using the ovmtconfig utility.  It will use one of two methods to pass these values to the domain.  The more complex method is backmounting the target domain's disk images to the control domain and then running a script which will put configuration items right into the filesystem of the target domain.  This is how a Solaris AI profile is constructed and passed to the domain for first-boot configuration of Solaris itself.  The other method currently uses VM variables to pass properties and their values to the domain.  These can then be read at first boot using the ovmtprop utility.  This is why the ovmt utilities should be installed in the template.  In the example below, you will see how this is done.

Creating a Source Domain

The first step in developing a template is to create a source domain.  This is where you will install your application, configure it as much as possible and test the first-boot script which will do the rest of the configuration based on the template property values passed during deployment.  Here are a few hints and recommendations for this step:

  • Use a standalone SPARC sun4v system to build your template.  Do not attempt to build a template on SuperCluster - this is not supported.
  • Create a simple domain:
    • Use only one network adapter if possible.  This makes it easier to deploy the template in many different environments.
    • Use only one disk image for the OS.  Keep it small.  Unnecessarily large disk images will make it more difficult to transport and deploy the template.
    • If required, you can use one or more additional disk images for the application.  Separating it from the OS is often a good idea.
    • Define CPU and memory resources only as needed.  They can always be increased after deployment if necessary.
    • Install only those OS packages required by your application.  You might want to start with "solaris-minimal-server" and then add any packages required.
  • You must use flat files for all disk images.  A later version of the utilities will also support other disk backends.
  • All your disk image files must have a filename ending in ".img".  While this is not a restriction for general use, it is currently a requirement if you intend to deploy your template on SuperCluster.
    • Use a sensible name for the disk images, as they are used in the volume descriptions within the template.
  • To speed up testing (create and deploy cycles) it is helpful to install pigz, a parallel implementation of gzip.  If present, it will be used to speed up compression and decompression of the disk images.
  • As you will most likely be using ovmtprop to read properties for your application, don't forget to install the ovmtutilities into the domain.
  • Apply all required configurations to make the application ready to run.  If this includes adding users, file systems, system configurations etc. to the domain, then do that.  All of these will be preserved during template creation.
  • Note that system properties like IP addresses, root passwords, timezone information etc. will not be preserved.

Defining the Properties

What properties you need in your template depends on your application.  So of course you should understand how to install and configure the application before you start building the template.  Here is an example for a very very simple application:  An Apache webserver that shows a plain text page displaying the properties passed to the domain.  In this example, there are three properties defined in the properties file: property1, property2 and property3.  Here is the full XML file defining these properties:

<ovf:ProductSection ovf:class="com.oracle.supercluster.client">
        <ovf:Product>Oracle SuperCluster</ovf:Product>
        <ovf:Category>OVM Templates</ovf:Category>
        <ovf:Version>1</ovf:Version>
        <ovf:Property ovf:key="property1" ovf:type="string" 
                      ovf:userConfigurable="true" ovf:value="Value1">
                <ovf:Description>Specifies property 1</ovf:Description>
        </ovf:Property>
        <ovf:Property ovf:key="property2" ovf:type="string"
                      ovf:userConfigurable="true" ovf:value="Value2">
                <ovf:Description>Specifies property 2</ovf:Description>
        </ovf:Property>
        <ovf:Property ovf:key="property3" ovf:type="string"
                      ovf:userConfigurable="true" ovf:value="Value3">
                <ovf:Description>Specifies property 3</ovf:Description>
        </ovf:Property>
</ovf:ProductSection> 

This file will be bundled with the template when you create the template.  Note that although there are values defined in this file, these values are not passed to the target domain during deployment!  A detailed description of all the options for template properties will be available in the Template Authoring Guide, which is currently being written.

Installing and Configuring the Application

Again, this step very much depends on the application you intend for your template.  In this simple example, there is very little to do.  Note that this step also shows a very simple first-boot script which does the configuration of the application:

root@source:~# pkg install ovmtutils

root@source:~# pkg install apache22

root@source:~# svcadm enable apache22

root@source:~# more /etc/rc3.d/S99template-demo 

#!/bin/sh

# simplest of all first-boot scripts
# just for demo purposes

OUTFILE=/var/apache2/2.2/htdocs/index.html
OVMTPROP=/opt/ovmtutils/bin/ovmtprop
BASEKEY=com.oracle.supercluster.client.property

if [ ! -f $OUTFILE ]
then
   cat >>$OUTFILE << EOF
<html><body>
<h1>OVM Template Demo</h1>
EOF
   for i in 1 2 3
   do
      $OVMTPROP -q get-prop -k $BASEKEY$i >> $OUTFILE
      echo "</br>" >> $OUTFILE
   done
cat >>$OUTFILE << EOF
</body></html>
EOF
fi

After you have completed the installation and are happy with how the first-boot scripts work, the final step is to unconfigure Solaris.  You do this using the command "sysconfig unconfigure --destructive --include-site-profile". This removes system identity like hostname, IP addresses, time zones and also root passwords from the system.  It is necessary so that after deployment, a new system identity can be passed to the target domain.  You might also want to remove other files like ssh keys, temp files in /var/tmp etc. which were created during configuration and testing but should not be left in the template.

Creating the Template

After all the preparations are complete, creating the actual template is a very simple step.  You only need to call ovmtcreate, which will collect all the pieces and assemble the OVF container for you.

root@mars:~# ovmtcreate -d source -o /templates/apache-template.ova \
             -s "OVM S11.2 SPARC Apache 2.2 Demo" \
             -P /development/apache-template.properties.xml

This will collect all the disk images attached to the source domain as well as the property definition file and package them in OVF format.   This file can now be transferred to any target system and deployed there.  With the "-s" flag, a descriptive name is given to the template.  This name can be used to identify the template.  For example, it will be displayed in the library of templates available in SuperCluster.

To complete the example workflow, deployment and configuration with the three custom properties for the sample Apache configuration is shown next.

Deploying Your Template on a Standalone Server with Custom Properties

To prepare for deployment, you will need a small file containing values for the three custom properties defined above: 

root@mars:~# cat custom.values
com.oracle.supercluster.client.property1=Value1
com.oracle.supercluster.client.property2=Value2
com.oracle.supercluster.client.property3=Value3

Of course, Solaris itself will also need some configuration.  You have already seen this in Part 1.  This example will simply reuse that configuration.

To deploy and configure the target domain, you now only need two simple commands:

root@mars:~# ovmtdeploy -d target -o /domains \
    -s /templates/apache-template.ova
root@mars:~# ovmtconfig -d target  \
    -c /opt/ovmtutils/share/scripts/ovmt_s11_scprofile.sh \
    -P solaris_11.props.values,custom.values

After starting the domain, you should be able to point your browser to port 80 and see the simple html page created by the first-boot script.

Additional Notes

  • You can check the properties passed to a domain from the control domain.  They are passed as normal VM variables, so the command "ldm ls-variable <domain>" will display them.  Note that this also means that any sensitive information passed to a domain in this way will be visible to anyone on the control domain with privileges to execute the ldm command.  The same information is also available to any user logged into the target domain, as any user has read access to the ovmtprop utility.  So while this is a nice way to check if the right variables have been passed to the target domain during testing, you should not use template properties to pass clear text passwords or other sensitive information to the domain.  Use encrypted password strings instead, if possible.  If the application requires clear text sensitive information, you should at least remove these variables after the target domain is in production.  Use the command "ldm rm-variable" to do so.  Triggering a change of passwords after first login is also a good idea.
  • In general, OVM Templates support Solaris Zones.  This means you can create a template domain that contains one or more Zones as part of the template.  However, you will need to care for the configuration (IP addresses, hostnames, etc) of each zone as part of the first-boot configuration, as this is not covered by the Solaris configuration utilities.  Also note that templates containing Zones are currently not supported on SuperCluster.

For additional and background reading, please refer to the links I provided at the end of the first article in this mini-series.

Getting Started with OVM Templates for SPARC - Part 1: Deploying a Template

OVM Templates have been around for a while now.  Documentation and various templates are readily available on OTN.  However, most of the documentation is centered around OVM Manager and most of the templates are built for Linux on x86 hardware.  But SPARC and Solaris are catching up.  A template for Weblogic 12.1.3 is already available.

With the release of Solaris 11.3, commandline tools to create, deploy and configure OVM Templates for SPARC are now available.  The tools are also available as a separate download on MOS as patch ID 21210110.  In this small series of blog entries, I will discuss how to deploy OVM Templates on SPARC and how to create your own.

(Note: This article is the blog version of the first part of MOS DocID 2063739.1 reproduced here for convenient access.)

Let's start with the easiest part: Deploying an existing template on a SPARC system.

Of course, the first step here is to get a template.  Today, there isn't very much choice - you can get a template for Solaris 10 and one for Solaris 11.  But more are being developed.  Go to Edelivery.oracle.com  to get them.  Here's a little screenshot to guide you in the right direction.  My notes are in red...

There is also a template for Weblogic 12.1.3 available here.

Once you've downloaded the template, you'll find a file called "sol-11_2-ovm-sparc.ova" or similar.  This is the template in Open Virtualization Format.   Since OVA and OVF are based on tar, you can actually extract and explore that file if you are curious.

The second step in deploying this template is to download and install the OVM Template Toolkit in the control domain of your server.  Either update to Solaris 11.3 or download the toolkit as a separate patch.  Then install it - you will find the tools in /opt/ovmtutils.  The patch will also contain a README file and manpages for the utilities.  I recommend looking at them for additional details and commandline switches not covered here.

root@mars:/tmp/ovmt# unzip /tmp/p21210110_11010_SOLARIS64.zip 
Archive:  /tmp/p21210110_11010_SOLARIS64.zip
  inflating: README.txt              
   creating: man1m/
  inflating: man1m/ovmtconfig.1m     
  inflating: man1m/ovmtprop.1m       
  inflating: man1m/ovmtlibrary.1m    
  inflating: man1m/ovmtcreate.1m     
  inflating: man1m/ovmtdeploy.1m     
  inflating: ovmt-utils1.1.0.1.p5p   

root@mars:/tmp/ovmt# pkg install -vg ./ovmt-utils1.1.0.1.p5p ovmtutils

[....]

root@mars:~# ls /opt/ovmtutils/bin
agent        dist         ovmtconfig   ovmtdeploy   ovmtprop
bin          lib          ovmtcreate   ovmtlibrary

Now, before we deploy the template, let's have a short look at what the utilities find in this specific template:

root@mars:~# ovmtdeploy -l ./sol-11_2-ovm-sparc.ova 
 
Oracle Virtual Machine for SPARC Deployment Utility
ovmtdeploy Version 1.1.0.1.4
Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights reserved.

STAGE 1 - EXAMINING SYSTEM AND ENVIRONMENT
------------------------------------------
Checking user privilege
Performing platform & prerequisite checks
Checking for required services
Named resourced available

STAGE 2 - ANALYZING ARCHIVE & RESOURCE REQUIREMENTS
---------------------------------------------------
Checking .ova format and contents
Validating archive configuration
Listing archive configuration

Assembly
------------------------
Assembly name: sol-11_2-ovm-sparc.ovf
Gloabl settings: 
References: zdisk-ovm-template-s11_2 -> zdisk-ovm-template-s11_2.gz
Disks: zdisk-ovm-template-s11_2 -> zdisk-ovm-template-s11_2
Networks: primary-vsw0

Virtual machine 1
------------------------
Name: sol-11_2-ovm-sparc
Description: Oracle VM for SPARC Template with 8 vCPUs, 4G memory, 1 disk image(s)
vcpu Quantity: 8
Memory Quantity: 4G
Disk image 1: ovf:/disk/zdisk-ovm-template-s11_2 -> zdisk-ovm-template-s11_2
Network adapter 1: Ethernet_adapter_0 -> primary-vsw0
Oracle VM for SPARC Template
        root-password
        network.hostname
        network.bootproto.0
        network.ipaddr.0
        network.netmask.0
        network.gateway.0
        network.dns-servers.0
        network.dns-search-domains.0

We can see that the target domain will have:

  • 8 vCPUs and 4GB of RAM
  • One Ethernet adapter connected to "primary-vsw0"
  • One disk image

It also supports several properties that can be configured after deployment and before the domain is first started.  These are all Solaris properties that one would usually provide during initial system configuration - either manually on the system console or using an AI profile.  We will see later in this article how to populate these properties.

Before we actually go and deploy this, we should check the prerequisites on the platform:

  • Your control domain should be running Solaris 11.3 (or at least 11.2 if you're using the patch mentioned above).
  • The virtual console service must be configured and running.  If not, set it up now.
    (See here for an example.)
  • A virtual disk service must be available.  If non is there, create one now.

But first, let's deploy the template without bothering about any details:

root@mars:~# ovmtdeploy -d solarisguest -o /localstore/domains \
             /incoming/sol-11_2-ovm-sparc.ova

In this very simple example, the domain we're creating and installing will be called "solarisguest".  It's disk images will be stored in /localstore/domains and it will be installed from the template found in /incoming/sol-11_2-ovm-sparc.ova.

There are a few things to note here:

  • ovmtdeploy will create the domain with resources as they are defined in the template.
  • It will, if necessary, create vswitches to connect network ports.  Make sure to check the result.
  • By default, ovmtdeploy will use flat files for disk images.
  • All of these settings can be overridden with commandline switches.  They allow very sophisticated domain configurations and are not covered here.
  • The domain is started right after the deployment.  Since we didn't populate the available properties, Solaris will boot in an unconfigured state and request configuartion on the system console.

So let's do this again, this time providing values for these properties.  This will allow us to boot the domain in a configured state without ever logging in.  What we need for this is a small text file which contains values for these properties:

root@mars:~# more solaris_11.props.values 

# Default hostname
com.oracle.solaris.system.computer-name=solarisguest

# Root user account settings
com.oracle.solaris.root-password='password hash goes here'

# Administrator account settings 
com.oracle.solaris.user.name.0=admin
com.oracle.solaris.user.real-name.0="Administrator"
com.oracle.solaris.user.password.0='password hash goes here'

# Network settings for first network instance
# Domain network interface
com.oracle.solaris.system.ifname=net0

# IP Address
# if not set, use DHCP
com.oracle.solaris.network.ipaddr.0=192.168.1.2
com.oracle.solaris.network.netmask.0=24
com.oracle.solaris.network.gateway.0=192.168.1.1

# DNS settings
# (comma separated list of DNS servers)
com.oracle.solaris.network.dns-servers.0=192.168.1.1
# (comma separated list of domains)
com.oracle.solaris.network.dns-search-domains.0=example.com

# System default locale settings
com.oracle.solaris.system.time-zone=US/Pacific
It should be obvious how to populate this file with your own values.  With this file, deployment and configuration is a simple, two step operation:

root@mars:~# ovmtdeploy -d solarisguest -o /localstore/domains \
             -s /incoming/sol-11_2-ovm-sparc.ova 

This deploys the guest, but doesn't start it.  That's what the "-s" commandline switch is for.

root@mars:~# ovmtconfig -d solarisguest \
    -c /opt/ovmtutils/share/scripts/ovmt_s11_scprofile.sh \
    -P solaris_11.props.values

The script "ovmt_s11_scprofile.sh" is part of the ovmtutils distribution.  ovmtconfig will mount the deployed disk image and call this script.  It will create a configuration profile using the property values given in "solaris_1.props.values".  This profile will be picked up by solaris at first boot to configure the domain.

With this, you have a solaris guest domain up and running.  If you don't like it, un-deploy it using "ovmtdeploy -U solarisguest".  It cleans up nicely.  You could now use this domain as a starting point for developing your own template.  But this will be covered in the next part.

For the curious, here are some additional links and references:

Donnerstag Mai 24, 2012

OVM Server for SPARC 2.2 released!

The long awaited new version 2.2 of Oracle VM Server for SPARC has been released!  Without repeating all the things mentioned elsewhere, here the main points:

There's a good summary at the Oracle Virtualization Blog. And of course, there's the official documentation:

Happy virtualizing!

Donnerstag Jun 09, 2011

OVM Server for SPARC 2.1 is here!

The newest version of OVM Server for SPARC aka LDoms is released!  Here's the press release...


What, already a new version again?  Well, the most missed feature in the previous versions was finally completed, and we didn't want to keep everyone waiting ;-)  The new version 2.1 turns "Warm Migration" into "Live Migration".  All the other improvements can be found in "What's New".  Once I have further details about Live Migration, I'll post them here.  You can find the download on MOS and the documentation on OTN.

Mittwoch Jan 26, 2011

Logical Domains - sure secure

LDoms Oracle VM Server for SPARC are being used wide and far.  And I've been asked several times, how secure they actually were.  One customer especially wanted to be very very sure. So we asked for independent expertise on the subject matter.  The results were quite pleasing, but not exactly night time literature. So I decided to add some generic deployment recommendations to the core results and came up with a whitepaper. Publishing was delayed a bit due to the change of ownership which resulted in a significant change in process.  The good thing about that is that now it's also up to date with the latest release of the software. I am now happy and proud to present::


Secure Deployment of Oracle VM for SPARC


A big Thanks You to Steffen Gundel of Cirosec, who laid the foundation for this paper with his study.


I do hope that it will be usefull to some of you!


Enjoy!

About

Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« May 2016
SunMonTueWedThuFriSat
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
     
Today