Creating deploy templates

Administrators can configure image deployment properties and save them as a Deploy Template. A deploy template includes everything necessary to quickly and easily create a virtual machine, for example, the deployment target, colocation rule, compute template, and so on.

For the deploy target, Default Group means all the managed hosts.

For the colocation rule, by default IBM® Cloud Infrastructure Center does not have a rule. You can refer to the Server group command in OpenStack document to create an affinity or anti-affinity rule.

Follow these steps to create a deploy template:

  1. From the Images page, select the image that you want to use to create a deploy template and click Create Deploy Template.

    • The page has a list of public images (images that are shared from ibm-default project) and private images.

    • For public images, the value of the 'Visibility' option in the Images details page is set as 'public'. For private images, the 'Visibility' option is set to 'private'.

  2. On the Create Deploy Template page that you are redirected to, provide input according to the requirement, including Deploy template name, Deploy target, Compute template, Network, Activation Input and so on.

  3. Select an FCP Multipath Template or use default Auto-select. The FCP Multipath Template is seen when the target host that you selected in previous Deploy target is on z/VM hypervisor. If you select an availability zone in the Deploy target listed in previous step, only the Auto-select option is supported. Refer to How to use FCP multipath templates for more information.

  4. Click Create Deploy Template.

  5. The deploy template is now listed on the Deploy Templates tab of the Images page.

In the Deploy Template details page, check whether a public image is used for creating the deploy template. Users with self-service role can view these deploy templates. Users with project_manager role (in projects other than ibm-default) cannot view deploy templates that are created with the public images. After creation, you can edit a deploy template by selecting the template and clicking Edit.

Notes:

a. You can edit the compute template when deploying virtual machines, but note that the Disk Size has a restriction. If you boot virtual machines from a local storage, the Disk Size (GB) you specified should NOT be bigger than the size of the maximum volume in z/VM®. The volume group is configured in compute_disk_pool of /etc/icic/config.properties. Refer to Set up the configuration file for z/VM and Set up the configuration file for KVM for details.

b. For the z/VM hypervisor, if you deploy a virtual machine that boots from a local storage and the ECKD is used for the disk as configured in the compute_disk_pool of /etc/icic/config.properties, the Disk Size should NOT be bigger than 45GB. If you need more space for the root file system, it is suggested to use the Ephemeral disk as specified in the Ephemeral size field of the compute template or attach the volume to the virtual machine after the deployment to increase space.

c. If you deploy a virtual machine that boots from a local storage and you provide the Disk Size as 0, that is a special case. The deployment action uses the selected image's original size as the size of the root disk.

d. If you deploy a virtual machine that boots from volume and you provide the Disk Size as 0, that is a special case, then the GUI prompts an error message because the volume size must be larger than 0.

e. During the creation of deploy templates, you need add the networks to the template. Note, that you can only select the network level, not the subnet level, even the network can have multiple subnets. Selecting a subnet level is only supported in z/VM for an administrator to create a virtual machine directly from an image. For details, refer to Creating virtual machines.

f. When you create a deploy template from an RHEL KVM image, you are allowed to choose one or multiple security groups. If none is selected, the default security group is used. For more information about security groups, refer to Working with a security group.

g. When you create a deploy template from an RHEL KVM image that uses a DHCP network, to ensure the virtual machines that are deployed with the template successfully get an IP address, you need to add explicit rules to allow egress to the DHCP server. For more information, refer to Security Groups rules and DHCP.

h. The Activation Input is used to run a specific program when the started instance is first started. The specific program can accomplish a user is defined purpose for actions like: configuration, services management and so on.

There are two options: Enter text and Select file.

  • Upload an executable shell script file, for instance, by choosing Select file.

  • Paste the executable shell command to the text field by selecting Enter text.

The specific program should be shell scripts and the Select file or Enter text format must be like:

    #!/bin/bash
    Extra Shell command

Activation Input example:

    #!/bin/bash
    pwd >> /tmp/example.log
    echo "test scripts" >> /tmp/example.log

The file /tmp/example.log content in deployed virtual machines:

    [root@rhel-image-7 ~]# view /tmp/example.log
    /
    test scripts

i. If you create the deploy template from an RHCOS image, the Activation Input is required to pass ignition config file. Ignition is a new provisioning utility that is designed specifically for Container Linux, that allows a user to manipulate the disks during an early boot. This includes partitioning disks, formatting partitions, writing files, and configuring users. On the first boot, the ignition reads its configuration and applies to the configuration. See Ignition configuration specifications.

The Activation Input has a size limitation due to the Nova user. The data size is restricted to 65535 bytes. There is a case that the ignition file content might be too large for the activation input. You need to create a smaller ignition file that is passed to the Nova as user data and that is downloaded with the main ignition file upon execution. The main file needs to be uploaded to an HTTP(S) location where the RHCOS virtual machine is able to access it.

Here are the basic steps:

  1. Choose the storage that best fits your needs and availability. Possible choices include but not limited to Swift, Glance, Amazon S3 and Internal web server inside your organization. Assume that the file is at the following URL https://static.example.com/ignition.conf

  2. Create a file with the following contents:

    {
      "ignition": {
        "config": {
           "merge": [{
              "source": "https://static.example.com/ignition.conf"
            }]
        },
        "version": "3.1.0"
      }
    }
  3. If the Ignition file served by server that uses self-signed certificate, for the RHCOS virtual machine to retrieve the ignition file, it is necessary to add the CA certificate to the ignition.security.tls.certificateAuthorities in the ignition file. For instance:

    {
      "ignition": {
        "security": {
          "tls": {
            "certificateAuthorities": [{
              "source": "data:text/plain;charset=utf-8;base64,<base64_encoded_certificate>"
            }]
          }
        },
        "version": "3.1.0"
      }
    }
  4. By default Glance service doesn't allow anonymous access to the data. So, if you use Glance to store the original ignition config, then you also need to provide a valid auth token in the ignition.config.merge.httpHeaders field. To obtain the token, the administrator needs to run the following commands from the Openstack CLI on IBM Cloud Infrastructure Center management node:

    source /opt/ibm/icic/icicrc <administrator> <password>

    openstack token issue -c id -f value

    The command returns the token to be added to the ignition.config.merge\[0\].httpHeaders property in the new Ignition file (see beneath):

    "httpHeaders": [{
      "name": "X-Auth-Token",
      "value": "<token>"
    }]

Here is a sample ignition file:

{
  "ignition": {
    "config": {
      "merge": [{
        "httpHeaders":[{"name":"X-Auth-Token","value":"tokenstring"}],
        "source": "https://static.example.com/ignition.conf",
        "verification":{}
        }]
    },
    "security": {
      "tls": {
        "certificateAuthorities": [{
          "source": "data:text/plain;charset=utf-8;base64,<base64_encoded_certificate>"
        }]
      }
    },
    "version": "3.1.0"
  }
}