Day Zero in the Configuration datamodel

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>

The url specifies a file on the ESC VM file system or file hosted on report http server.

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 datamodel,

<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.

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 datamodel, for example, 0, 1, 2, 3

Example

NICID_0_IP_ALLOCATION_TYPE: FIXED
NICID_0_NETWORK_ID: 9f8d9a97-d873-4a1c-8e95-1a123686f038
NICID_0_IP_ADDRESS: 2a00:c31:7fe2:1d:0:0:1:1000
NICID_0_MAC_ADDRESS: null
NICID_0_GATEWAY: 2a00:c31:7fe2:1d::1
NICID_0_CIDR_ADDRESS: 2a00:c31:7fe2:1d::
NICID_0_CIDR_PREFIX: 64
NICID_0_ANYCAST_ADDRESS: null
NICID_0_IPV4_OCTETS: 16.0
NICID_1_IP_ALLOCATION_TYPE: DHCP
NICID_1_NETWORK_ID: 0c468d8e-2385-4641-b1db-9080c170cb1a
NICID_1_IP_ADDRESS: 6.0.0.2
NICID_1_MAC_ADDRESS: null
NICID_1_GATEWAY: 6.0.0.1
NICID_1_CIDR_ADDRESS: 6.0.0.0
NICID_1_CIDR_PREFIX: 24
NICID_1_ANYCAST_ADDRESS: null
NICID_1_NETMASK: 255.255.255.0

By default, ESC substitutes the $ variable in the day 0 configuration file with the actual value during deployment. In ESC Release 2.3 and later, you can enable or disable the $ variable substitution for each configuration file.

Add the following field to the configuration datamodel:

where,

• VELOCITY enables variable substitution.

• NONE disables variable substitution.

If no value is set the default option is VELOCITY, and the $ variable substitution takes place. When set to NONE, the $ variable substitution does not take place.

You must follow these tips while processing the template through the velocity template engine.

• To escape dollar sign in the template insert,

  #set ( $DS = "$" )

  then replace the variable with

  passwd: ${DS}1${DS}h1VxC40U${DS}uf2qLUwGTjHgZplkP78xA

• To escape a block in the template, insert #[[ and #]]. For example,

  #[[ passwd: $1$h1VxC40U$uf2qLUwGTjHgZplkP78xA ]]#

Rules

The ESC object model defines for each vm_group a section where the end-user can specify the administrative rules to be applied based on the outcome of the KPIs selected metric collector.

<rules>
           <admin_rules>
            <rule>
             <event_name>VM_ALIVE</event_name>
             <action>TRUE esc_vm_alive_notification</action>
             <action>FALSE recover autohealing</action>                                        
           </rule>
	    :	:	:	:	:	:	:	:
	    :	:	:	:	:	:	:	:
       </admin_rules>
    </rules>

As mentioned within the KPIs section, correlation between KPIs and Rules is done based on the value of the <event_name> tag.

In the Rules section above, if the outcome of the KPIs defining event_name is VM_ALIVE, and the selected metric collector is TRUE, then the action identified by the key, TRUE esc_vm_alive_notification is selected for execution.

If the outcome of the KPIs defining event_name is VM_ALIVE, and the selected metric collector is FALSE, then the action identified by the key, FALSE recover autohealing is selected for execution.

For information on updating KPIs and Rules, see Updating the KPIs and Rules.

Metrics and Actions (Dynamic Mapping)

ESC Metrics and Actions (Dynamic Mapping) framework is the foundation of the kpis and rules sections. As described in the KPIs section the metric type uniquely identifies a metric and its metadata.

The metrics and actions is as follows:

<metrics>
          <metric>
          <name>ICMPPING</name>
          <userLabel>ICMP Ping</userLabel>
          <type>MONITOR_SUCCESS_FAILURE</type>
          <metaData>
            <type>icmp_ping</type>
            <properties>
                <property>
                    <name>ip_address</name>
                    <value></value>
                </property>
                 <property>
                    <name>enable_events_after_success</name>
                    <value>true</value>
                </property>
                <property>
                    <name>vm_gateway_ip_address</name>
                    <value></value>
                </property>
                <property>
                  <name>enable_check_interface</name>
                  <value>true</value>
                </property>
          </properties>
        </metaData>
      </metric>
	:	:	:	:	:	:	:	:
</metrics>

The above metric is identified by its unique name ICMPPING. The <type> tag identifies the metric type.

Currently ESC supports two types of metrics:

• MONITOR_SUCCESS_FAILURE

• MONITOR_THRESHOLD

The <metadata> section defines the attributes and properties that is processed by the monitoring engine.

The metric_collector type in the KPI show the following behavior:

At regular intervals of 3 seconds the behavior associated with the ICMPPING identifier is triggered. The ICMPPING metric is of type MONITOR_SUCCESS_FAILURE, that is the outcome of the monitoring action is either a success or a failure. In the sample above, an icmp_ping is performed using the <ip_address> field defined in the <metadata> section. In case of SUCCESS the rule action(s) with the TRUE prefix will be selected for execution. In case of FAILURE the rule action(s) with the FALSE prefix is selected for execution.

<actions>
          <action>
           <name>TRUE servicebooted.sh esc_vm_alive_notification</name>
           <type>ESC_POST_EVENT</type>
           <metaData>
            <type>esc_post_event</type>
            <properties>
            <property>
           <name>esc_url</name>
           <value></value>
          </property>
        <property>
       <name>vm_external_id</name>
        <value></value>
        </property>
        <property>
        <name>vm_name</name>
        <value></value>
        </property>
        <property>
      <name>event_name</name>
       <value></value>
     </property>
     <property>
   <name>esc_event</name>
   <value>SERVICE_BOOTED</value>
   </property>                
   <properties/>
   </metaData>
   </action>
  	:	:	:	:	:	:	:	:
  <actions>

The action sample above describes the behavior associated with the SUCCESS value. The ESC rule action name TRUE servicebooted.sh esc_vm_alive_notification specifies the action to be selected. Once selected the action <type> ESC_POST_EVENT identifies the action that the monitoring engine selects.

Metrics and Actions APIs

The CRUD operations for mapping the actions and the metrics are available through REST API. Refer to the API tables below for mapped metrics and actions definition.

To update an existing mapping, delete and add a new mapping through the REST API.

Note

While upgrading any earlier version of ESC to ESC 2.2 and later, to maintain the VNF monitoring rules, you must back up the dynamic_mappings.xml file and then restore the file in the upgraded ESC VM. For more information upgrading monitoring rules, see Upgrading VNF Monitoring Rules section in the Cisco Elastic Services Controller Install and Upgrade Guide. Cisco ESC Release 2.3.2 and later, the dynamic mapping API is accessible locally only on the ESC VM.

The response for the actions APIs is as follows:

<actions>
          <action>
          <name>{action name}</name>
          <type>{action type}</type>
          <metaData>
          <type>{monitoring engine action type}</type>
         <properties>
         <property>
         <name></name>
        <value></value>
       </property>
      :	:	:	:	:	:	: 
     <properties/>
     </metaData>
     </action>
	:	:	:	:	:	:	:	:
    <actions>

Where

{action name}: Unique identifier for the action. Note that in order to be compliant with the ESC object model, for success or failure actions, the name must start with either TRUE or FALSE.

{action type}: Action type in this current release can be either ESC_POST_EVENT, SCRIPT or CUSTOM_SCRIPT.

{monitoring engine action type}: The monitoring engine type are the following: icmp_ping, icmp4_ping, icmp6_ping, esc_post_event, script, custom_script, snmp_get. See Monitoring the VNFs for more details.

Core and Default Actions List

Metric APIs

The response for the Metric APIs is as follows:

<metrics>
          <metric>
          <name>{metric name}</name>
          <type>{metric type}</type>
          <metaData>
          <type>{monitoring engine action type}</type>
          <properties>
          <property>
          <name></name>
         <value></value>
         </property>
         :	:	:	:	:	:	: 
         <properties/>
         </metaData>
       </metric>
       :	:	:	:	:	:	:	:
      <metrics>

Where,

{metric name}: Unique identifier for the metric.

{metric type}: Metric type can be either MONITOR_SUCCESS_FAILURE, MONITOR_THRESHOLD or MONITOR_THRESHOLD_COMPUTE.

{monitoring engine action type}: The monitoring engine type are the following: icmp_ping, icmp4_ping, icmp6_ping, esc_post_event, script, custom_script, snmp_get. See Monitoring for more details.

Core and Default Metrics List

Triggering Pre-defined Actions

ESC introduces a new REST API to trigger the existing (pre-defined) actions defined through the Dynamic Mapping API, when required. For more information on the dynamic mapping APIs, see Metrics and Actions (Dynamic Mapping).

A sample pre-defined action is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<actions>
  <action>
    <name>SaidDoIt</name>
    <userlabel>My Friendly Action</userlabel>
    <type>SCRIPT</type>
    <metaData>
        <type>script</type>
        <properties>
            <property>
                <name>script_filename</name>
                <value>/opt/cisco/esc/esc-scripts/do_somethin.py</value>
            </property>
            <property>
                <name>arg1</name>
                <value>some_val</value>
            </property>
            <property>
                <name>notification</name>
                <value>true</value>
            </property>
        </properties>
    </metaData>
  </action>
</actions>

Note	A script file located on a remote server is also supported. You must provide the details in the <value> tag, for example, <value>http://myremoteserverIP:80/file_store/do_somethin.py</value>

The pre-defined action mentioned above is triggered using the trigger API.

Execute the following HTTP or HTTPS POST operation:

POST http://<IP_ADDRESS>:8080/ESCManager/v0/trigger/action/

POST https://<IP_ADDRESS>:8443/ESCManager/v0/trigger/action/

The following payload shows the actions triggered by the API, and the response received:

<triggerTarget>
  <action>SaidDoIt</action>
  <properties>
   <property>
     <name>arg1</name>
     <value>real_value</value>
   </property>
  </properties>
</triggerTarget>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<triggerResponse>
    <handle>c11be5b6-f0cc-47ff-97b4-a73cce3363a5</handle>
    <message>Action : 'SAIDDOIT' triggered </message>
</triggerResponse>

ESC accepts the request, and returns a response payload and status code.

An http status code of 200 indicates that the action triggered exists, and is triggered successfully. An http status codes of 400 or 404 indicate that the action to be triggered is not found.

You can determine the status using the custom script notifications sent to NB at various lifecycle stages. For more information, see Custom Script Notification.

ESC sends the MANUAL_TRIGGERED_ACTION_UPDATE callback event to NB with a status message that describes the success or failure of the action execution.

The notification is as follows:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><esc_event xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<event_type>MANUAL_TRIGGERED_ACTION_UPDATE</event_type>
<properties>
 <property>
  <name>handle</name>
  <value>c11be5b6-f0cc-47ff-97b4-a73cce3363a5</value>
 </property>
 <property>
  <name>message</name>
  <value>Action execution success</value>
 </property>
 <property>
  <name>exit_code</name>
  <value>0</value>
 </property>
 <property>
  <name>action_name</name>
  <value>SAIDDOIT</value></property>
 </properties>
</esc_event>

Note	The script_filename property cannot be overwritten by the trigger API request. See Script Actions for more details. The trigger API must not contain any additional properties that do not exist in the pre-defined action.

The new API allows to overrides some of the special properties (of the actions) listed below:

• Notification—Set this for the script notification to progress in run time. The default value is false. This value can be set to true in the action or trigger payload.

• wait_max_timeout—Wait for the script to complete the execution before terminating. The default wait timeout is 900 seconds.

Note

The trigger API supports only script type actions. Ensure that the script action located on the ESC VM is copied to the same path on both the Master and Backup HA instances. For more information, see the High Availability chapter in the Cisco Elastic Services Controller Install Guide. The script execution terminates if there is a failover, shutdown, or reboot of the ESC services.

Configuring Custom Script Metric Monitoring

Custom Script Metric Monitoring can be performed as follows:

1. Create Script

2. Add Metric

3. Add Action

4. Define Deployment

5. Update KPI data or Rules

The script to be executed has to be compliant with the rules specified for a MONITOR_THRESHOLD action. Threshold crossing evaluation will be based on the exit value from the script execution. In the sample script below, the return value is the number of IP sessions.

#!/usr/bin/env python
import pexpect
import re
import sys
ssh_newkey = 'Are you sure you want to continue connecting'
# Functions
def get_value(key):
    i = 0
    for arg in sys.argv:
        i = i + 1
        if arg == key:
            return sys.argv[i]
    return None
def get_ip_addr():
    device_ip = get_value("vm_ip_address")
    return device_ip
# Main 
CSR_IP = get_ip_addr()
 
p=pexpect.spawn('ssh admin@' + CSR_IP + ' show ip nat translations total')
i=p.expect([ssh_newkey,'assword:',pexpect.EOF])
if i==0:
    p.sendline('yes')
    i=p.expect([ssh_newkey,'assword:',pexpect.EOF])
if i==1:
    p.sendline("admin")
    p.expect(pexpect.EOF)
elif i==2:
    pass
n = p.before
result = re.findall(r'\d+', n)[0]
sys.exit(int(result))

The ESC monitoring and action engine processes the script exit value.

The script has to be installed into the following ESC VM directory: /opt/cisco/esc/esc-scripts/

The following payload describes a metric using a custom_script defined in the script

<!-- Demo Metric Counting Sessions -->
<metrics>
        <metric>
            <name>custom_script_count_sessions</name>
            <type>MONITOR_THRESHOLD</type>
            <metaData>
                <properties>
                 <property>
                   <name>script_filename</name>
                    <value>/cisco/esc-scripts/countSessions.py</value>
                   </property>
                    <property>
                     <name>for_threshold</name>
                     <value>true</value>
                    </property>
                  </properties>
                 <type>custom_script_threshold</type>
                </metaData>
              </metric>
            </metrics>
         <!-- -->

The metric payload has to be added to the list of supported ESC metrics by using the Mapping APIs.

Execute a HTTP POST operation on the following URI:

http://<my_esc_ip>:8080/ESCManager/internal/dynamic_mapping/metrics

The following payload describes custom actions that can be added to the list of supported ESC actions by using the Mapping APIs.

<actions>
        <action>
        <name>TRUE ScaleOut</name>
          <type>ESC_POST_EVENT</type>
           <metaData>
            <type>esc_post_event</type>
             <properties>
             <property>
              <name>esc_url</name>
            <value></value>
            </property>
            <property>
           <name>vm_external_id</name>
           <value></value>
          </property>
          <property>
          <name>vm_name</name>
          <value></value>
         </property>
         <property>
         <name>event_name</name>
         <value></value>
         </property>
         <property>
         <name>esc_event</name>
         <value>VM_SCALE_OUT</value>
          </property>                
         <property>
        <name>esc_config_data</name>
        <value></value>
         </property>                
        <properties/>
       </properties>
       </metaData>
        </action>
        <action>
            <name>TRUE ScaleIn</name>
            <type>ESC_POST_EVENT</type>
            <metaData>
             <type>esc_post_event</type>
                <properties>
                 <property>
                 <name>esc_url</name>
                  <value></value>
                 </property>
                <property>
             <name>vm_external_id</name>
            <value></value>
           </property>
           <property>
             <name>vm_name</name>
             <value></value>
           </property>
           <property>
           <name>event_name</name>
           <value></value>
         </property>
          <property>
          <name>esc_event</name>
         <value>VM_SCALE_IN</value>
         </property>                
        <properties/>
           </properties>
           </metaData>
        </action>
      </actions>

Execute a HTTP POST operation on the following URI:

http://<IP_ADDRESS>:8080/ESCManager/internal/dynamic_mapping/actions

ESC Service Deployment

The KPI section defines the new KPI using the monitoring metrics.

<kpi>
   <event_name>DEMO_SCRIPT_SCALE_OUT</event_name>
   <metric_value>20</metric_value>
   <metric_cond>GT</metric_cond>
   <metric_type>UINT32</metric_type>
<metric_collector>
   <type>custom_script_count_sessions</type>
   <nicid>0</nicid>
   <poll_frequency>15</poll_frequency>
   <polling_unit>seconds</polling_unit>
   <continuous_alarm>false</continuous_alarm>
</metric_collector>
</kpi>
<kpi>
   <event_name>DEMO_SCRIPT_SCALE_IN</event_name>
   <metric_value>1</metric_value>
   <metric_cond>LT</metric_cond>
   <metric_type>UINT32</metric_type>
   <metric_occurrences_true>1</metric_occurrences_true>
   <metric_occurrences_false>1</metric_occurrences_false>
<metric_collector>
   <type>custom_script_count_sessions</type>
   <nicid>0</nicid>
   <poll_frequency>15</poll_frequency>
   <polling_unit>seconds</polling_unit>
   <continuous_alarm>false</continuous_alarm>
</metric_collector>
</kpi>

In the above sample, in the first KPI section, the metric identified by custom_script_count_sessions is executed at regular interval of 15 seconds. If the value returned by the metric is greater than 20, then the event name DEMO_SCRIPT_SCALE_OUT is triggered to be processed by the rules section.

In the above sample, in the second KPI section,The metric identified by custom_script_count_sessions is executed at regular interval of 15 seconds. If the value returned by the metric is less than 1, then the event name DEMO_SCRIPT_SCALE_IN is triggered to be processed by the rules section.

The rules section defines rules using the event_name that have been used by kpis. The action tag will define an action that will be executed when the event_name is triggered. In the example below, the action identified by the TRUE ScaleOut identifier is executed when the event DEMO_SCRIPT_SCALE_OUT is triggered.

<rule>
   <event_name>DEMO_SCRIPT_SCALE_OUT</event_name>
   <action>ALWAYS log</action>
   <action>TRUE ScaleOut</action>
</rule>
<rule>
   <event_name>DEMO_SCRIPT_SCALE_IN</event_name>
   <action>ALWAYS log</action>
   <action>TRUE ScaleIn</action>
</rule>             

Custom Script Notification

ESC now supports sending notification to northbound about customized scripts run as part of the deployment at a certain lifecycle stage. You can also determine the progress of the script executed through this notification. To execute a custom script with notification, define action type attribute as SCRIPT, and property attribute name as notification, and set the value to true.

For example, in the datamodel below, the action is to run a customized script located at /opt/cisco/esc/esc-scripts/senotification.py with notification, when the deployment reaches POST_DEPLOY_ALIVE stage.

<policies>
	<policy>
		<name>PCRF_POST_DEPLOYMENT</name>
		<conditions>
			<condition>
				<name>LCS::POST_DEPLOY_ALIVE</name>
			</condition>
		</conditions>
		<actions>
			<action>
				<name>ANY_NAME</name>
				<type>SCRIPT</type>
				<properties>
					<property>
						<name>script_filename</name>
						<value>/opt/cisco/esc/esc-scripts/senotification.py</value>
					</property>
       <property>
						<name>notification</name>
						<value>true</value>
					</property>
				</properties>
			</action>
		</actions>
	</policy>
</policies>
<vm_group>
	<name>g1</name>

You can notify northbound about the script execution progress using the following outputs:

• Standard JSON output

• REST API call

Standard JSON Output

The standard JSON output follows the MONA notification convention. MONA captures entries in this to generate notification.

{"esc-notification":{"items":{"properties": [{"name":"name1","value":"value1"},{"name":"name2","value":"value2"}...]}}}

The items are listed in the table below.

Table 5 Item list

Name	Description
type	Describes the type of notification. progress_steps | progress_percentage | log | alert | error
progress Note    Progress item is required only when the type is progress-steps or progress-percentage.	For progress-steps type, {current_step}|{total_steps}
	For progress-percentage type, {percentage}
msg	Notification message.

Example JSON output is as follows:

{"esc-notification":{"items":{"properties": [{"name":"type", "value":"progress_percentage"},{"name":"progress","value":"25"},{"name":"msg","value":"Installation in progress."}]}}}

Note

If the custom script is written in Python, because standard output is buffered by default, after each notification print statement, the script is required to call sys.stdout.flush() to flush the buffer (for pre Python 3.0). Otherwise MONA cannot process the script stdout in a real-time. print '{"esc-notification":{"items":{"properties": [{"name":"type", "value":"progress_percentage"},{"name":"progress","value":"25"},{"name":"msg","value":"Installation in progress."}]}}}'sys.stdout.flush()

REST API Call

http://localhost:8090/mona/v1/actions/notification

For REST API, the script must accept a script handle as the last parameter. The script handle can be UUID, MONA action or execution job Id. For example, if the script originally accepts 3 command line parameters, to support MONA notification, the script considers an additional parameter for the handle UUID. This helps MONA to identify the notification source. For every notification, the script is responsible for constructing a POST REST call to MONA's endpoint inside the script:

The payload is as follows:

{
	"esc-notification" : {
		"items" : {
			"properties" : [{
					"name" : "type",
					"value" : "log",
					"hidden" : false
				}, {
					"name" : "msg",
					"value" : "Log info",
					"hidden" : false
				}
			]
		},
		"source" : {
			"action_handle" : "f82fe86d-6625-4b13-99f7-89d169e427ad"
		}
	}
}

Note	The action_handle value is the handle UUID MONA passes into the script.

Policy Data model

The policy data model consists of conditions and actions. The condition is a Lifecycle Stage (LCS) in a deployment. The action is predefined or custom script.

• Predefined action—The action is predefined and executed when the condition is met.

  In the datamodel below, when condition2 is met, Action2 is performed. The action <type> is predefined.

• Custom Script—The action is a custom script, and executed when the condition is met.

  In the datamodel below, when condition1 is met, Action1-1 and Action 1-2 are executed. The action <type> is script.

  <policies>
      <policy>
          <name>Name1</name>
          <conditions>
              <condition>
                  <name>Condition1</name>
              </condition>
          </conditions>
          <actions>
              <action>
                  <name>Action1-1</name>
                  <type>SCRIPT</type>
              </action>
              <action>
                  <name>Action1-2</name>
                  <type>SCRIPT</type>
              </action>
          </actions>
      </policy>
      <policy>
          <name>Name2</name>
          <conditions>
              <condition>
                  <name>Condition2</name>
              </condition>
          </conditions>
          <actions>
              <action>
                  <name>Action2</name>
                  <type>PRE-DEFINED</type>
              </action>
          </actions>
      </policy>
  </policies>

For more information on Predefined actions, and scripts, see Recovery and Redeployment Policies.

The table below shows the LCS in a deployment, and its description. The recovery and redeployment policies, and VNF software upgrade policies use the policy-driven data model. For details on configuring the recovery and redeployment policies using the policy framework, see Recovery and Redeployment Policies. For details on upgrading the VNF software upgrade policies, see Upgrading the VNF Software Using the Policy Data Model.

Supported Lifecycle Stages (LCS)

Configuring PCI or PCIe Device Passthrough on VMware vCenter

ESC supports VMware vCenter PCI or PCIe device passthrough (VMDirectPath I/O). This enables VM access to physical PCI functions on platforms with an I/O memory management unit.

Before You Begin

For the PCI / PCIe devices of a host VM to enable passthrough, the vSphere administrator must mark these devices in the vCenter.

Note	You must reboot the host after PCI settings. Put the host to maintenance mode, power off or migrate all VMs to other hosts.

<tenants>
		<tenant>
			<name>admin</name>
			<deployments>
				<deployment>
					<name>abc-test</name>

			 	<vm_group>
						<name>test-g1</name>
						<image>uLinux</image>
						<bootup_time>300</bootup_time>
						<recovery_wait_time>10</recovery_wait_time>
						<interfaces>
							<interface>
								<nicid>1</nicid>
								<network>MgtNetwork</network>
								<ip_address>10.79.0.102</ip_address>
							</interface>
							<interface>
								<nicid>2</nicid>
								<network>VM Network</network>
								<type>passthru</type>
								<ip_address>172.16.0.0</ip_address>
							</interface>
							<interface>
								<nicid>3</nicid>
								<network>VM Network</network>
								<type>passthru</type>
								<ip_address>10.84.46.117</ip_address>
							</interface>
						</interfaces>

After successful deployment, the passthru value is set in the interface section of the notification as well as in the operational data.

Auto Selecting PCI or PCIe PassThrough Device

ESC needs one or more PCI or PCIe passthrough devices to be attached to each deployment without a particular PCI ID. ESC first selects a host. ESC selects the next available PCI or PCIe passthrough enabled device and attaches it during the deployment. If there is no PCI or PCIe passthrough enabled device available, ESC fails the deployment. The vSphere administrator has to ensure all computing-host within the target computing-cluster have enough number of PCI or PCIe passthrough enabled devices.

Note

PCI or PCIe passthrough is not considered by ESC placement algorithm. For example, ESC does not select a host because it has available resources to complete the PCI or PCIe passthrough requests. ESC selects the PCI or PCIe passthrough device randomly. ESC does not consider the type or specification of the device. It selects the next available PCI or PCIe device from the list. Recovery fails if the VNF is recovered to a computing-host that ESC has selected based on the ESC placement algorithm, and if that computing-host does not have any PCI or PCIe passthrough enabled devices available. DRS must be turned off for the passthrough to work.