The initial or day 0 configuration of a VNF is based on the VM type. A VNF administrator configures the initial template for each VM type at the time of VNF deployment. The same configuration template is applied to all deployed and new VMs of that VM type. The template is processed at the time of individual VM deployment. The day 0 configuration continues to persists, so that all initial deployment, healing and scaling of VMs have the same day 0 template.

Some of the day 0 configuration tasks include bringing up the interface, managing the network, support for static or dynamic IP (DHCP, IPAM), SSH keys, and NetConf enabled configuration support on VNF.

Note	ESC does not support day 0 configuration of interfaces added during service update. In case of recovery for day 0 configuration, all the interfaces with Network Interface Card IDs will be configured.

The day 0 configuration file can be specified in different ways in the data model, but you can use only one of the options at a time.

• <file> url </file>—The url specifies a file on the ESC VM file system or file hosted on report http server. ESC downloads the file specified by the URL. This file is used as a template to replace the tokens specified in this template with the values specified in the variables section. This template is used to generate the day 0 configuration.

• <data> inline config content </data>—Specifies URL for the template. This allows the use of inline text as the template.

• <encrypted_data> inline config content</encrypted_data>—The inline configuration content will be encrypted based on the data.

• <file_locators> list of file locators </file_locators>—Similar to file, a file_locator defines file to download from a remote server with basic authentication (if required).

  Note	The <file_locators> is deprecated in ESC Release 4.0.

• <file_locator_name> deployment defined file_locator </file_locator_name>—Similar to file, the file_locator_name is used to download the file from a remote server with basic authentication (if required).

Day 0 configuration is defined in the datamodel under the config_data tag. Each user data and the configuration drive file is defined under the configuration tag. The contents are in the form of a template. ESC processes the template through the Apache Velocity Template Engine before passing to the VM.

The config_data tag is defined for each vm_group. The same configuration template is applied to all VMs in the vm_group. The template file is retrieved and stored at deployment initialization. Template processing is applied at time of VM deployment. The content of the config file can be retrieved from the file or data.

<file> url </file>
<data> inline config content </data>

A destination name is assigned to the config by <dst>. User Data is a treated as a special case with <dst>--user-data</dst>.

A sample config data model,

<config_data>
    <configuration>
        <file>file://cisco/userdata_file.txt</file>
        <dst>--user-data</dst>
        <variable>
            <name>CUSTOM_VARIABLE_FOR_USERDATA</name>
            <val>SOME_VALUE_XXX</val>
        </variable>
    </configuration>
    <configuration>
        <file>file://cisco/config.sh</file>
        <dst>config.sh</dst>
        <variable>
            <name>CUSTOM_VARIABLE_FOR_CONFIG</name>
            <val>SOME_VALUE_XXX</val>
        </variable>
    </configuration>
</config_data>

Custom variable can be specified in the variables tag within the configuration. Zero or more variables can be included in each configuration. Each variable can have multiple values. Multiple values are only useful when creating more than one VM per vm_group. Also, when performing scale in and scale out, additional VMs can be added and removed from the VM group.

Note	Note the following while providing multiple values for the variable tag.

• The variable values assigned to the initially deployed VMs are unique and from the pool. There is no order followed for assigning the values from the pool. That is, the first VM can use the second value from the pool.

• A scaled out VM should have a unique variable value and from the pool.

• A recovered VM (after undeploy or redeploy) must retain the same value it had before.

The contents of <file> are a template that is processed by the Velocity Template Engine. ESC populates a set of variables for each interface before processing the configuration template:

Where n is the interface number from the data model, for example, 0, 1, 2, 3

Note	The interface number, n starts with 0 for OpenStack, and 1 for VMware.

Example

NICID_0_NETWORK_ID=0affdc19-60fd-4a4f-a02b-f062d7a66c27
NICID_0_MAC_ADDRESS=fa:16:3e:4d:c5:f8

NICID_0_0_IP_ALLOCATION_TYPE=DHCP
NICID_0_0_IP_ADDRESS=1.1.22.133
NICID_0_0_GATEWAY=1.1.0.1
NICID_0_0_CIDR_ADDRESS=1.1.0.0
NICID_0_0_CIDR_PREFIX=16
NICID_0_0_NETMASK=255.255.0.0

NICID_0_1_IP_ALLOCATION_TYPE=DHCP
NICID_0_1_IP_ADDRESS=fd04:1::a03
NICID_0_1_GATEWAY=fd04:1::1
NICID_0_1_CIDR_ADDRESS=fd04:1::/64
NICID_0_1_CIDR_PREFIX=64

By default, ESC substitutes the $ variable in the day 0 configuration file with the actual value during deployment. You can enable or disable the $ variable substitution for each configuration file.

The day 0 configuration for vCD deployment can be passed in different ways:

• Constructing an ISO file

• OVF properties

• Pre-existing ISO file in a catalog (OOB ISO file)

Note

For initial deployment, the number of VM group(s) defined in the datamodel must be the same as the number of VM(s) in the vApp template. In a deployment, the image value of each VM group should be unique. The out of band (OOB) ISO file cannot be used along with constructing an ISO file method, as the VM can consider any one. The ovf property can be used with OOB ISO or constructing ISO together.

Day 0 configuration through constructing an ISO file:

</rules>
            <config_data>
              <!-- take content from the file path and save it as config.sh into the ISO file -->
              <configuration>
                <dst>config.sh</dst>
                <file>file:///cisco/config.sh</file>
              </configuration>
              <!-- take content from the file path, replace variables with values, and save it as data/config.sh into the ISO file -->
              <configuration>
                <dst>data/params.cfg</dst>
                <file>file:///cisco/template.cfg</file>
                <variable>
                  <name>CF_VIP_ADDR</name>
                  <val>10.0.0.9</val>
                </variable>
                <variable>
                  <name>CF_DOMAIN_NAME</name>
                  <val>cisco.com</val>
                </variable>
                <variable>
                  <name>CF_NAME_SERVER</name>
                  <val>172.16.180.7</val>
                </variable>
              </configuration>
              <!-- take the data section as the content of the file, replace variables with values, and save it as user-data.txt into the ISO file-->
              <configuration>
                <dst>user-data.txt</dst>
                <data>#cloud-config
manage_etc_hosts: true
hostname: $HOST_NAME
local-hostname: $HOST_NAME
</data>
                <variable>
                  <name>$HOST_NAME</name>
                  <val>something.cisco.com</val>
                </variable>
              </configuration>
            </config_data>

Day 0 configuration through OOB ISO file:

         </rules>
            <config_data>
              <configuration>
                <!-- ISO file stored in catalog-1 -->
                <dst>vcdCatalog:catalog-1</dst>
                <data>h2.iso</data>
              </configuration>
            </config_data>

Day 0 configuration through OVF properties:

           <config_data>
              <configuration>
                <!-- ovf properties as day0 -->
                <dst>ovfProperty:mgmt-ipv4-addr</dst>
                <data>$NICID_0_IP_ADDRESS/24</data>
              </configuration>
            </config_data>

For information on deploying VNFs on vCD, see Deploying Virtual Network Functions on VMware vCloud Director (vCD).