Container blueprint XML reference

This section describes the network container blueprint XML file tags.

This section describes the network container blueprint XML file tags.

addressBlueprint Schema

<addressBlueprint>
    <addressName></addressName>
    <addressPoolName></addressPoolName>
    <condition></condition>
    <gatewayFlag></gatewayFlag>
    <poolPosition></poolPosition>
</addressBlueprint>

Description: Each addressBlueprint tag specifies how to acquire an address from either a container or pod level address pool. Address blueprints can be defined at either the container level, the node level, or the pair level. Addresses can be referenced as substitution parameters in the templates used to configure containers (for example, "$\{container.addresses\[My Address\]\}" for a container level address).

Children:

Tag

Description

addressNameSpecifies a way to uniquely identify this address within the its declared scope (for example, within the container, or within the node, or within the pair).
addressPoolNameIdentifies which container or pod level pool this address should be acquired from.
conditionDefines the condition under which the address should be acquired from its address pool, as a Boolean expression of component states. Refer to the dynamic container documentation for syntax details for these expressions. If no condition is specified, the address will be acquired as soon as the address pool involved is acquired. \\ \\ For example, if you want to declare that an address should only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS\- container.nicSegments\['NIC 1'\]".
gatewayFlagIndicates whether this address should be considered to be the gateway for its address pool (subnet) or not. Each container address pool which servers can be provisioned from must have one address from that pool declared as the gateway address.
poolPosition(Optional) Specifies a position within the address pool to acquire the address from. For instance, a poolPosition of "1" would be guaranteed to acquire the value 10.0.0.1 from a 10.0.0.0/24 pool, while a poolPosition of 254 would be guaranteed to acquire the value 10.0.0.254 from that same pool. If the tag is not specified, then the address will acquire whatever the next available value is from the pool happens to be.

Back to top

addressBlueprints Schema

<addressBlueprints>
    <!-- see addressBlueprint schema -->
</addressBlueprints>

Description: Each addressBlueprints tag consists of zero or more addressBlueprint tags.

addressPoolBlueprint Schema

<addressPoolBlueprint>
    <addressSpaceBlueprintName></addressSpaceBlueprintName>
    <condition></condition>
    <defaultPoolSize></defaultPoolSize>
    <linkId></linkId>
    <name></name>
    <natPoolName></natPoolName>
    <rangeBlueprintName></rangeBlueprintName>
</addressPoolBlueprint>

Description: Each addressPoolBlueprint tag specifies how to acquire a container level address pool from an address range specified in the pod, or from an address space specified in the container. A container level address pool is dedicated to a particular container for it to acquires addresses from.

Children:

Tag

Description

addressSpaceBlueprintNameSpecifies name of the address space in the container which this pool should be acquired from. It should not be specified if rangeBlueprintName is specified.
conditionDefines the condition under which the address pool should be acquired (from either an address space or an address range), as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the address pool is acquired as soon its address space is acquired, or as soon as the container is provisioned in the case of an address range. \\ \\ For example, if you want to declare that an address pool should only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS\- container.nicSegments\['NIC 1'\]".
defaultPoolSize

Specifies the default size of pools to be acquired from the specified address space. The value represents the number of usable IP addresses (excluding network and broadcast IP addresses) within the address pool in question. The actual size of the pool will be the nearest power of two that is greater than or equal to the value set for defaultPoolSize plus 2 (this includes the network and broadcast IP addresses). If you select a value of 50 for the tag, the actual size of the pool is the power of two greater than or equal to 52. The closest power of two that is greater than or equal to 52 is 2 ^6^ or 64. The actual pool size would be 64 IP addresses with 62 usable IP addresses. 

The default can be overridden by the BMC Cloud Lifecycle Management. It should be specified if addressSpaceBlueprintName tag is specified. See Container-oriented addressing for an example of the use of this tag.

linkIdSpecifies a unique identifier for an address pool within a pool chain. This is applicable only for Network Address Translation (NAT) pools, and is used within the context of NAT pool scaling.
namespecifies a way to uniquely identify this address pool within the container.
natPoolName(Optional) Specifies the name of an associated address pool from which NAT addresses are acquired. Used when VM/VIP addresses acquired from this address pool need to be translated. The NAT address pool should be a pool that is declared in the container blueprint or pod blueprint and could be public or private.
rangeBlueprintNameSpecifies to the name of the address range in the pod which this pool should be acquired from. It should not be specified if addressSpaceBlueprintName is specified.

Back to top

addressPoolBlueprints Schema

<addressPoolBlueprints>
    <!-- see addressPoolBlueprint schema -->
</addressPoolBlueprints>

Description: Each addressPoolBlueprints tag consists of zero or more addressPoolBlueprint tags.

Back to top

addressSpaceBlueprint Schema (xsi:type="infrastructureAddressSpaceBlueprint")

<addressSpaceBlueprint xsi:type="infrastructureAddressSpaceBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <allowOverride></allowOverride>
    <condition></condition>
    <defaultNetworkAddress></defaultNetworkAddress>
    <defaultNetworkMask></defaultNetworkMask>
    <description></description>
    <name></name>
</addressSpaceBlueprint>

Description: Each addressSpaceBlueprint tag specifies how to create an address space. The boundaries of an address space can be defined by the BMC Cloud Lifecycle Management, and its contents can be carved up into unequally sized address pools and is different than an address range, which is defined in the pod and which contains equally sized address pools. An address space blueprint with xsi:type="infrastructureAddressSpaceBlueprint" contains address pools which will be used exclusively for infrastructure addresses. The pools within it are always private (unique within just this container), never public (unique across all of IPAM).

Children:

TagDescription
allowOverrideSpecifies whether the BMC Cloud Lifecycle Management can override the boundaries of the address space and the size of the pools within it. It is only applicable to infrastructure address spaces.
condition

Defines the condition under which the address space should be acquired (assigned a boundary), as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the address space will be acquired as soon as the container is provisioned.

For example, if you want to declare that an address space should only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS\- container.nicSegments\['NIC 1'\]".

defaultNetworkAddressSpecifies the default network address boundary of the address space, which can be overridden by the BMC Cloud Lifecycle Management if allowOverride is true. It is required for an infrastructure address space.
defaultNetworkMaskSpecifies the default network mask boundary of the address space, which can be overridden by the BMC Cloud Lifecycle Management if allowOverride is true. It is required for an infrastructure address space.
descriptionSpecifies the description to be presented in the UI for the address space. It is a required value.
nameSpecifies a way to uniquely identify this address space within the container.

Back to top

addressSpaceBlueprint Schema (xsi:type="provisioningAddressSpaceBlueprint")

<addressSpaceBlueprint xsi:type="provisioningAddressSpaceBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <condition></condition>
     <defaultNetworkAddress></defaultNetworkAddress>
     <defaultNetworkMask></defaultNetworkMask>
     <defaultPublicFlag></defaultPublicFlag>
     <description></description>
     <name></name>
</addressSpaceBlueprint>

Description: Each addressSpaceBlueprint tag specifies how to create an address space. The boundaries of an address space can be defined by the BMC Cloud Lifecycle Management, and its contents can be carved up into unequally sized address pools and is different than an address range, which is defined in the pod and which contains equally sized address pools.

An address space with xsi:type="provisioningAddressSpaceBlueprint" contains address pools that must be used for provisioning addresses (VM NICs, or LB pool VIPs, or LB pool SNAT blocks) but they do not need to be used exclusively for that purpose (e.g. you can acquire some infrastructure addresses from it as well if necessary). The pools within it can be public (unique across all of IPAM), or private (unique within just this container). The BMC Cloud Lifecycle Management is always allowed to override the default values for the boundaries of the address space and the sizes of the pools within it.

Children:

TagDescription

condition

Defines the condition under which the address space should be acquired (assigned a boundary), as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the address space will be acquired as soon as the container is provisioned.

For example, if you want to declare that an address space should only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

defaultNetworkAddress

The defaultNetworkAddress tag specifies the default network address boundary of the address space, which can be overridden by the BMC Cloud Lifecycle Management.  It is required for a private provisioning address space, but should not be specified for a public provisioning address space.

defaultNetworkMask

The defaultNetworkMask tag specifies the default network mask boundary of the address space, which can be overridden by the BMC Cloud Lifecycle Management. It is required for an infrastructure address space.  It is required for a private provisioning address space, but should not be specified for a public provisioning address space.

defaultPublicFlag

Flags whether the address space is by default public (unique across all of IPAM) or private (unique just within this container), which can be overridden by the BMC Cloud Lifecycle Management.

description

The description tag specifies the description to be presented in the UI for the address space.  It is a required value.

name

The name value specifies a way to uniquely identify this address space within the container. 

Back to top

addressSpaceBlueprints Schema 

<addressSpaceBlueprints>
    <!-- see addressSpaceBlueprint schema -->
</addressSpaceBlueprints>

Description: Each addressSpaceBlueprints tag consists of zero or more addressSpaceBlueprint tags.

Back to top

addressTranslatorBlueprint Schema

<addressTranslatorBlueprint>
    <addressPoolNames>
        <addressPoolName></addressPoolName>
    </addressPoolNames>
    <insideInterfaceName></insideInterfaceName>
    <outsideInterfaceName></outsideInterfaceName>
    <dynamicFlag></dynamicFlag>
 </addressTranslatorBlueprint>

Description: The addressTranslatorBlueprint tag specifies how to create an address translator instance.  An address translator encapsulates information about a particular NAT table being managed. This includes identifying the two interfaces on the device which the translation is being performed between, and the list of address pools (typically private) being translated to.  Each of those pools contains a reference to the address pool (typically public) being translated from.  The translator also maintains the list of address pairs currently defined with the NAT table.

Children:

TagDescription

addressPoolNames

Specifies the names of one or more address pools for whom address translation will be done.  Typically these are private address pools, where each private address pool has a reference to an associated public address pool involved in the translation.

insideInterfaceName

Name of the inside interface (e.g. firewall managed interface) for which address translation will be done. Typically this is the interface on which will travel packets that use private addresses.

outsideInterfaceName

Name of the outside interface (e.g. firewall managed interface) for which address translation will be done. Typically this is the interface on which will travel packets that use public addresses.

dynamicFlag

( Optional Specifies static or dynamic NATting for the VFW. If static translation is being done, BMC Network Automation acquires the NAT addresses based on a request from BMC Cloud Lifecycle Management, and passes them on to the device for it to use. If dynamic translation is being done, the device acquires NAT addresses itself as needed.

Default: Static translation

Notes:
  • Even though the natTypeBlueprint mechanism can be declared in any nodeBlueprint, currently BMC Network Automation assumes it to be declared in a containerVfwBlueprint so as to be useful for NAT sensitivity in the path rule translation algorithm. Such sensitivity is currently only supported for static NAT in the VFW, not dynamic NAT.
  • Dynamic NAT in the VLB, where each LB pool is configured to use a different NAT block, is handled separately as a special case in the loadBalancerPoolTypeBlueprint.  Unlike dynamic NAT in the VFW, the path rule translation algorithm in BMC Network Automation is sensitive to dynamic NAT in the VLB.

Back to top

addressTranslatorBlueprints Schema

<addressTranslatorBlueprints>
    <!-- see aaddressTranslatorBlueprint schema -->
</addressTranslatorBlueprints>

Description: Eacgh addressTranslatorBlueprints tag contains one or more addressTranslatorBlueprint tags.

bbnaData Schema

<bbnaData>
    <containerBlueprint>
        <!-- see containerBlueprint schema -->
    </containerBlueprint>
    <version>
        <!-- see version schema -->
    </version>
</bbnaData

Description: The bbnaData tag is the root tag used to encapsulate an importable version stamped BMC Network Automation component, in this case a container blueprint.
 
Children:
TagDescription

containerBlueprint

See containerBlueprint schema.

version

See version schema.

Back to top

configureActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint")

<configureActionInfoBlueprint xsi:type="customActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <condition></condition>
    <description></description>
    <guid></guid>
    <name></name>
    <runtimeProps>
        <item>
            <key></key>
            <value></value>
        </item>
    </runtimeProps>
</configureActionInfoBlueprint>

Description: Each configureActionInfoBlueprint tag specifies a particular action to create to configure this node, within the overall job to configure the container.  A configureActionInfoBlueprint with xsi:type="customActionInfoBlueprint " is used to represent a custom action to be executed in the job.

Children:

TagDescription

condition

Defines the condition under which the action should be applied, as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the action is applied as soon as the container is provisioned.

For example, if you want to apply the action to only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

Note that when the condition for applying a configure action changes from true to false, an associated unconfigure action (if any) is applied. When the condition changes back from false to true, the configure action is re-applied.

description

(Optional) Describes the action, which will be presented in the container viewer.

guid

Identifies which custom action is involved (view the adapter in question in the BMC Network Automation UI to see its GUID value).

name

(Optional) Specifies a name for the action. This is used for conditional actions where both the configure action and an associated unconfigure action are both given the same name, so that BMC Network Automation knows to coordinate the application of the two actions, to guarantee that when the condition no longer applies for the configure action, the unconfigure action is applied, and vice-versa.

runtimeProps

Contains zero or more runtime properties that can be specified as arguments to pass into the actions. Each runtime property requires a key which is the name of the property, and a value. The value can include embedded substitution parameter references which are resolved before the value is passed to the action. The allowed substitution parameter types are the same as would be allowed in a template being merged to the node's device. So for instance, you could specify a value of ${container.name} in order to pass in the name of the container involved, or you could specify ${runtime.myParam} in order to pass in a value gathered in the BMC Cloud Lifecycle Management UI from the admin creating the container.

Back to top

configureActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint")

<configureActionInfoBlueprint xsi:type="externalScriptActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <condition></condition>
    <description></description>
    <guid></guid>
    <name></name>
    <runtimeProps>
        <item>
            <key></key>
            <value></value>
        </item>
    </runtimeProps>
    <capturedResultPatterns>
        <item> 
            <key></key>
            <value></value>
        </item>
    </capturedResultPatterns>
</configureActionInfoBlueprint>

Description: Each configureActionInfoBlueprint tag specifies a particular action to create to configure this node, within the overall job to configure the container. A configureActionInfoBlueprint with xsi:type="externalScriptActionInfoBlueprint " is used to represent an external script action to be executed in the job.

Children:

TagDescription

condition

Defines the condition under which the action should be applied, as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the action will be applied as soon as the container is provisioned.

For example, if you want to apply the action only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

Note that when the condition for applying a configure action changes from true to false, an associated unconfigure action (if any) are applied. When the condition changes back from false to true, the configure action is re-applied.

description

(Optional) Describes the action, which will be presented in the container viewer.

guid

Identifies which external script action is involved (view the adapter in question in the BMC Network Automation UI to see its GUID value).

name

(Optional) Specifies a name for the action. This is used for conditional actions where both the configure action and an associated unconfigure action will both be given the same name, so that BMC Network Automation knows to coordinate the application of the two actions, to guarantee that when the condition no longer applies for the configure action, the unconfigure action will be applied, and vice-versa.

runtimeProps

Contains zero or more runtime properties that can be specified as arguments to pass into the actions. Each runtime property requires a key which is the name of the property, and a value.  The value can include embedded substitution parameter references which will be resolved before the value is passed to the action.  The allowed substitution parameter types are the same as would be allowed in a template being merged to the node's device. So for instance, you could specify a value of ${container.name}, in order to pass in the name of the container involved, or you could specify ${runtime.myParam} in order to pass in a value gathered in the BMC Cloud Lifecycle Management UI from the admin creating the container.

capturedResultPatterns

Contains zero or more captured result pattern definitions. Each such definition includes a name and a value that is a regular expression within which you specify a capture pattern.
For example, you could specify a definition with the name "foo" and the value "b(.*)r". After BMC Network Automation executes the external script action, it will match the pattern against the output. If the output is "bar" for instance, the captured result would be "a". This captured result can then be referred to in other actions using the substitution parameter syntax "${container.nodes[<node-name>].action[<action-name>].results[foo]}".

Back to top

configureActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

<configureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <condition></condition>
    <requiresTunneling></requiresTunneling>
    <description></description>
    <name></name>
    <templateGroups>
        <item></item>
    </templateGroups>
</configureActionInfoBlueprint>

Description: Each configureActionInfoBlueprint tag specifies a particular action to create to configure this node, within the overall job to configure the container.  A configureActionInfoBlueprint with xsi:type="mergeActionInfoBlueprint " is used to represent a Deploy to Active action to be executed in the job.

Children:

TagDescription

condition

Defines the condition under which the action should be applied, as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the action will be applied as soon as the container is provisioned.

For example, if you want to apply the action only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

Note that when the condition for applying a configure action changes from true to false, an associated unconfigure action (if any) will be applied.  When the condition changes back from false to true, the configure action will be re-applied.

requiresTunneling

(Optional) Forces the file transfer mode be set to Tunneling protocol for a Deploy to Active action. When the value of this flag is set to true or if the value of device type.requiresTunnelingForContainerMerge is set to true, BMC Network Automation uses the Tunneling file transfer mode for the Deploy to Active action. Otherwise, BMC Network Automation uses the file transfer mode specified for the device to perform the Deploy to Active action.

description

(Optional) Describe the action, which will be presented in the container viewer.

name

(Optional) Specifies a name for the action. This is used for conditional actions where both the configure action and an associated unconfigure action will both be given the same name, so that BMC Network Automation knows to coordinate the application of the two actions, to guarantee that when the condition no longer applies for the configure action, the unconfigure action will be applied, and vice-versa.

templateGroups

Specifies one or more item tags, each of which specifies the name of an existing BMC Network Automation template to merge (the term template group is what you call templates inside the BMC Network Automation model, however the term presented in the UI is simply template).  If more than one item is specified, the selection of which to use will alternate from one container instance to the next, balancing their use.

Back to top

configureActionInfoBlueprints Schema

<configureActionInfoBlueprints>
    <!-- see <configureActionInfoBlueprint schema -->
</configureActionInfoBlueprints>

Description: Each configureActionInfoBlueprints tag consists of zero or more configureActionInfoBlueprint tags.

Back to top

containerBlueprint Schema

<containerBlueprint>
 
<!-- ========= Identity =============================================== -->
 
<description></description>
<diagramLink></diagramLink>
<legacyVersion></legacyVersion>
<name></name>
<revisionNum></revisionNum>
<tag></tag>
<type></type>
 
<!-- ========= Resources: Address Spaces ============================== -->
 
<addressSpaceBlueprints>
    <!-- see addressSpaceBlueprint schema -->
</addressSpaceBlueprints>
 
<!-- ========= Resources: Address Pools =============================== -->
 
<addressPoolBlueprints>
    <!-- see addressPoolBlueprint schema -->
</addressPoolBlueprints>
 
<!-- ========= Resources: Addresses =================================== -->
 
<addressBlueprints>
    <!-- see addressBlueprint schema -->
</addressBlueprints>
 
<!-- ========= Resources: Integers ==================================== -->
 
<integerBlueprints>
    <!-- see integerBlueprint schema -->
</integerBlueprints>
 
<!-- ========= Resources: VLANs ======================================= -->
 
<vlanBlueprints>
    <!-- see vlanBlueprint schema -->
</vlanBlueprints>
 
<!-- ========= Model: VRF IDs ========================================= -->
 
<vrfIdBlueprints>
    <!-- see vrfIdBlueprint schema -->
</vrfIdBlueprints>
 
<!-- ========= Model: External Segments =============================== -->
 
<externalNetworkSegmentBlueprints>
    <!-- see externalNetworkSegmentBlueprint schema -->
</externalNetworkSegmentBlueprints>
 
<!-- ========= Model: NIC Segments ==================================== -->
 
<nicSegmentBlueprints>
    <!-- see nicSegmentBlueprint schema -->
</nicSegmentBlueprints>
 
<!-- ========= Model: VIP Segments ==================================== -->
 
<vipSegmentBlueprints>
    <!-- see vipSegmentBlueprint schema -->
</vipSegmentBlueprints>
 
<!-- ========= Model: Zones =========================================== -->
 
<zoneBlueprints>
    <!-- see zoneBlueprint schema -->
</zoneBlueprints>
 
<!-- ========= Model: Network Paths =================================== -->
 
<networkPathBlueprints>
    <!-- see networkPathBlueprint schema -->
</networkPathBlueprints>
 
<!-- ========= Model: Nodes =========================================== -->
 
<nodeBlueprints>
    <!-- see nodeBlueprint schema -->
</nodeBlueprints>
 
<!-- ========= Model: Pairs =========================================== -->
 
<pairBlueprints>
    <!-- see pairBlueprint schema -->
</pairBlueprints>
 
</containerBlueprint>

Description: The containerBlueprint tag partially specifies how to provision a container, in an abstract way, so that the same blueprint specification can be reused across different environments.  The partial specification of the container is supplemented with additional input from the user in the BMC Cloud Lifecycle Management UI for the name of the container instance to create, the name of the pod to create it on, runtime parameters to use in the actions involved in provisioning the container (if necessary), and optional overrides for the initial state of dynamic components and the details of addressing resources.

Children:

TagDescription

addressBlueprints

Consists of zero or more addressBlueprint tags. See addressBlueprint schema.

addressPoolBlueprints

Consists of zero or more addressPoolBlueprint tags. See addressPoolBlueprint schema.

addressSpaceBlueprints

Consists of zero or more addressSpaceBlueprint tags. See addressSpaceBlueprint schema.

description

(Optional) Reminds the person viewing the container blueprint about its details.

diagramLink

(Optional) Specifies the URL linking to a diagram showing the logical topology for the container blueprint.

externalNetworkSegmentBlueprints

Consists of zero or more externalNetworkSegmentBlueprint tags. See externalNetworkSegmentBlueprint schema.

integerBlueprints

Consists of zero or more integerBlueprint tags. See integerBlueprint schema.

legacyVersion

Specifies the version of BMC Network Automation logic to use when naming port types within the hypervisor switch. Prior to 8.1.01, port profiles in switches were named using VLAN ID. However, after 8.1.01 port profiles are created using the port type name. Assigning this tag a value prior to 8.1.01 (say "8.1.00") causes BMC Network Automation to use the legacy convention of naming the port type within the switch using its VLAN ID, rather than the name defined in the model.  Assigning the tag a value of 8.2.01 or later (or leaving it unspecified), will cause BMC Network Automation to use the current logic of naming the port type within the switch using the name defined in the model.

networkPathBlueprints

Consists of zero or more networkPathBlueprint tags. See networkPathBlueprint schema.

nicSegmentBlueprints

Consists of zero or more nicegmentBlueprint tags. See nicSegmentBlueprint schema.

name

Specifies a way to uniquely identify this container blueprint among other container blueprints.

nodeBlueprints

Consists of one or more nodeBlueprint tags. See nodeBlueprint schema.

pairBlueprints

Consists of zero or more pairBlueprint tags. See pairBlueprint schema.

revisionNum

Identifies the revision number of the network container blueprint. Default value is 0. This tag is used as part of a reprovision network container operation. See Reprovisioning network containers in BMC Network Automation.

tag

(Optional) Identifies a container. It is not used by BMC Network Automation for anything. It is used by the BMC Cloud Lifecycle Management as a default tag to match against when deciding which container to use when provisioning servers.

type

(Optional) Is presented as a reminder to the user of the type of container this blueprint creates when viewing its value later in the container viewer.

vipSegmentBlueprints

Consists of zero or more vipSegmentBlueprint tags. See vipSegmentBlueprint schema.

vlanBlueprints

Consists of one or more vlanBlueprint tags. See vlanBlueprint schema.

vrfIdBlueprints

Consists of zero or more vrfIdBlueprint tags. See vrfIdBlueprint schema.

zoneBlueprints

Consists of zero or more zoneBlueprint tags. See zoneBlueprint schema.

Back to top

createGuestActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint")

<createGuestActionInfoBlueprint xsi:type="customActionInfoBlueprint"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <condition></condition>
     <description></description>
     <guid></guid>
     <runtimeProps>
         <item>
             <key></key>
             <value></value>
         </item>
     </runtimeProps>
</createGuestActionInfoBlueprint>

Description: The createGuestActionInfoBlueprint tag specifies an action to create the virtual guest on one of the host devices in a fault host pair.  The host device used will be the one which currently has the active admin context between the pair (both hosts in the pair will be inspected first to determine this).  When creating the guest, the action must also specify which host the guest should become active on (by joining the community group that is active on the desired host, which you will have learned from the inspection mentioned above). The decision of which host you want the guest to be active on will be based on which host has had the least number of guests initially activated on it. The host on which you create the guest will automatically propogate the change to the other host (you will wait for the propogation to complete before you complete your action). 

A createGuestActionInfoBlueprint tag with xsi:type="customActionInfoBlueprint" represents a custom action to be executed to create the guest.

Children:

TagDescription

condition

Defines the condition under which the action should be applied, as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the action is applied as soon as the container is provisioned.

For example, if you want to apply the action tp only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

Note that when the condition for applying a configure action changes from true to false, an associated unconfigure action (if any) is applied. When the condition changes back from false to true, the configure action is re-applied.

description

(Optional) Describes the action, which will be presented in the container viewer.

guid

Identifies which custom action is involved (view the adapter in question in the BMC Network Automation UI to see its GUID value).

runtimeProps

Contains zero or more runtime properties that can be specified as arguments to pass into the actions. Each runtime property requires a key which is the name of the property, and a value.  The value can include embedded substitution parameter references which will be resolved before the value is passed to the action.  The allowed substitution parameter types are the same as would be allowed in a template being merged to the node's device. So for instance, you could specify a value of ${container.name}, in order to pass in the name of the container involved, or you could specify ${runtime.myParam} in order to pass in a value gathered in the BMC Cloud Lifecycle Management UI from the admin creating the container.

Back to top

createGuestActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint")

<createGuestActionInfoBlueprint xsi:type="externalScriptActionInfoBlueprint"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <condition></condition>
     <description></description>
     <guid></guid>
     <runtimeProps>
         <item>
             <key></key>
             <value></value>
         </item>
     </runtimeProps>
</createGuestActionInfoBlueprint>

Description: The createGuestActionInfoBlueprint specifies an action to create the virtual guest on one of the host devices in a fault host pair.  The host device used will be the one which currently has the active admin context between the pair (both hosts in the pair will be inspected first to determine this).  When creating the guest, the action must also specify which host the guest should become active on (by joining the community group that is active on the desired host, which you will have learned from the inspection mentioned above). The decision of which host you want the guest to be active on will be based on which host has had the least number of guests initially activated on it. The host on which you create the guest will automatically propogate the change to the other host (you will wait for the propogation to complete before you complete your action). 

A createGuestActionInfoBlueprint with xsi:type="externalScriptActionInfoBlueprint" represents an external script action to be executed to create the guest.

Children:

TagDescription

condition

Defines the condition under which the action should be applied, as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the action is applied as soon as the container is provisioned.

For example, if you want to apply the action tp only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

Note that when the condition for applying a configure action changes from true to false, an associated unconfigure action (if any) is applied. When the condition changes back from false to true, the configure action is re-applied.

description

(Optional) Describes the action, which will be presented in the container viewer.

guid

Identifies which external script action is involved (view the adapter in question in the BMC Network Automation UI to see its GUID value).

runtimeProps

Contains zero or more runtime properties that can be specified as arguments to pass into the actions. Each runtime property requires a key which is the name of the property, and a value. The value can include embedded substitution parameter references which will be resolved before the value is passed to the action. The allowed substitution parameter types are the same as would be allowed in a template being merged to the node's device. So for instance, you could specify a value of ${container.name}, in order to pass in the name of the container involved, or you could specify ${runtime.myParam} in order to pass in a value gathered in the BMC Cloud Lifecycle Management UI from the admin creating the container.

Back to top

createGuestActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

<createGuestActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <requiresTunneling></requiresTunneling>
    <condition></condition>
    <description></description>
    <templateGroups>
        <item></item>
    </templateGroups>
</createGuestActionInfoBlueprint

Description: The createGuestActionInfoBlueprint specifies an action to create the virtual guest on one of the host devices in a fault host pair.  The host device used will be the one which currently has the active admin context between the pair (both hosts in the pair will be inspected first to determine this).  When creating the guest, the action must also specify which host the guest should become active on (by joining the community group that is active on the desired host, which you will have learned from the inspection mentioned above). The decision of which host you want the guest to be active on will be based on which host has had the least number of guests initially activated on it. The host on which you create the guest will automatically propogate the change to the other host (you will wait for the propogation to complete before you complete your action). 

A createGuestActionInfoBlueprint with xsi:type="mergeActionInfoBlueprint" represents a Deploy to Active action to be executed to create the guest.

Children:

TagDescription

requiresTunneling

(Optional) field used to force the file transfer mode be set to Tunneling protocol for a Deploy to Active action. When the value of this flag is set to true or if the value of device type.requiresTunnelingForContainerMerge is set to true, BMC Network Automation uses the Tunneling file transfer mode for the Deploy to Active action. Otherwise, BMC Network Automation uses the file transfer mode specified for the device to perform the Deploy to Active action.

condition

Defines the condition under which the action should be applied, as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the action is applied as soon as the container is provisioned.

For example, if you want to apply the action tp only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

Note that when the condition for applying a configure action changes from true to false, an associated unconfigure action (if any) is applied. When the condition changes back from false to true, the configure action is re-applied.

description

An optional field to describe the action, which will be presented in the container viewer.

templateGroups

Specifies one or more item tags, each of which specifies the name of an existing BMC Network Automation template to merge (the term template group is what you call templates inside the BMC Network Automation model, however the term presented in the UI is simply template). If more than one item is specified, the selection of which to use will alternate from one container instance to the next, balancing their use.

Back to top

createGuestActionInfoBlueprints Schema

<createGuestActionInfoBlueprints>
    <!-- see <createGuestActionInfoBlueprint schema --> 
</createGuestActionInfoBlueprints>

Description: Each createGuestActionInfoBlueprints tag consists of zero or more createGuestActionInfoBlueprints tags.

Back to top

createNatActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

<createNatActionInfoBlueprint xsi:type="mergeActionInfoBlueprint"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <requiresTunneling></requiresTunneling>
    <description></description>
    <templateGroups>
        <item></item>
    </templateGroups>
</createNatActionInfoBlueprint

Description: Specifies how to add a static address pair entries to a NAT table via a Deploy to Active action. The following runtime parameter references are plugged into the template involved: publicAddress, privateAddress, insideInterfaceName, outsideInterfaceName.

Children:

TagDescription

requiresTunneling

(Optional) Force the file transfer mode be set to Tunneling protocol for a Deploy to Active action. When the value of this flag is set to true or if the value of device type.requiresTunnelingForContainerMerge is set to true, BMC Network Automation uses the Tunneling file transfer mode for the Deploy to Active action. Otherwise, BMC Network Automation uses the file transfer mode specified for the device to perform the Deploy to Active action.

description 

(Optional) Describes the action, which will be presented in the container viewer.

templateGroups

Specifies one or more item tags, each of which specifies the name of an existing BMC Network Automation template to merge (the term template group is what you call templates inside the BMC Network Automation model, however the term presented in the UI is simply template).  If more than one item is specified, the selection of which to use will alternate from one container instance to the next, balancing their use.

Back to top

destroyGuestActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint")

<destroyGuestActionInfoBlueprint xsi:type="customActionInfoBlueprint"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <condition></condition>
    <description></description>
    <guid></guid>
    <runtimeProps>
        <item>
            <key></key>
            <value></value>
        </item>
    </runtimeProps>
</destroyGuestActionInfoBlueprint>

Description: The destroyGuestActionInfoBlueprint specifies an action to destroy the virtual guest on the host device which currently has the active admin context in a fault host pair (both hosts in the pair are inspected first to determine this). The host on which you destroy the guest on automatically propogates the change to the other host (propogation completes before you complete your action).

A destroyGuestActionInfoBlueprint with xsi:type="customActionInfoBlueprint" represents a custom action to be executed to destroy the guest.

Children:

TagDescription

condition

Defines the condition under which the action should be applied, as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the action is applied as soon as the container is provisioned.

For example, if you want to apply the action tp only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

Note that when the condition for applying a configure action changes from true to false, an associated unconfigure action (if any) is applied. When the condition changes back from false to true, the configure action is re-applied.

description

(Optional) Describes the action, which will be presented in the container viewer.

guid

Identifies which custom action is involved (view the adapter in question in the BMC Network Automation UI to see its GUID value).

runtimeProps

Contains zero or more runtime properties that can be specified as arguments to pass into the actions. Each runtime property requires a key which is the name of the property, and a value. The value can include embedded substitution parameter references which are resolved before the value is passed to the action. The allowed substitution parameter types are the same as would be allowed in a template being merged to the node's device. So for instance, you could specify a value of ${container.name}, in order to pass in the name of the container involved, or you could specify ${runtime.myParam} in order to pass in a value gathered in the BMC Cloud Lifecycle Management UI from the admin creating the container.

Back to top

destroyGuestActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint")

 <destroyGuestActionInfoBlueprint xsi:type="externalScriptActionInfoBlueprint"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <condition></condition>
    <description></description>
    <guid></guid>
    <runtimeProps>
        <item>
            <key></key>
            <value></value>
        </item>
    </runtimeProps>
</destroyGuestActionInfoBlueprint>

Description: The destroyGuestActionInfoBlueprint specifies an action to destroy the virtual guest on the host device which currently has the active admin context in a fault host pair (both hosts in the pair are inspected first to determine this). The host on which you destroy the guest on automatically propogates the change to the other host (propogation completes before you complete your action).

A destroyGuestActionInfoBlueprint with xsi:type="externalScriptActionInfoBlueprint" represents an external script action to be executed to destroy the guest.

Children:

TagDescription

condition

Defines the condition under which the action should be applied, as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the action is applied as soon as the container is provisioned.

For example, if you want to apply the action tp only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

Note that when the condition for applying a configure action changes from true to false, an associated unconfigure action (if any) is applied. When the condition changes back from false to true, the configure action is re-applied.

description

(Optional) Describes the action, which will be presented in the container viewer.

guid

Identifies which external script action is involved (view the adapter in question in the BMC Network Automation UI to see its GUID value).

runtimeProps

Contains zero or more runtime properties that can be specified as arguments to pass into the actions. Each runtime property requires a key which is the name of the property, and a value. The value can include embedded substitution parameter references which are resolved before the value is passed to the action. The allowed substitution parameter types are the same as would be allowed in a template being merged to the node's device. So for instance, you could specify a value of ${container.name}, in order to pass in the name of the container involved, or you could specify ${runtime.myParam} in order to pass in a value gathered in the BMC Cloud Lifecycle Management UI from the admin creating the container.

Back to top

destroyGuestActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

<destroyGuestActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <requiresTunneling></requiresTunneling>
    <condition></condition>
    <description></description>
    <templateGroups>
        <item></item>
    </templateGroups>
</destroyGuestActionInfoBlueprint>

Description: The destroyGuestActionInfoBlueprint specifies an action to destroy the virtual guest on the host device which currently has the active admin context in a fault host pair (both hosts in the pair are inspected first to determine this). The host on which you destroy the guest on automatically propogates the change to the other host (propagation completes before you you complete your action).

A destroyGuestActionInfoBlueprint with xsi:type="mergeActionInfoBlueprint" represents a Deploy to Active action to be executed to destroy the guest.

Children:

TagDescription

requiresTunneling

(Optional) Forces the file transfer mode be set to Tunneling protocol for a Deploy to Active action. When the value of this flag is set to true or if the value of device type.requiresTunnelingForContainerMerge is set to true, BMC Network Automation uses the Tunneling file transfer mode for the Deploy to Active action. Otherwise, BMC Network Automation uses the file transfer mode specified for the device to perform the Deploy to Active action.

condition

Defines the condition under which the action should be applied, as a Boolean expression of component states. Refer to the flexible container documentation for syntax details for these expressions. If no condition is specified, the action is applied as soon as the container is provisioned.

For example, if you want to apply the action tp only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

Note that when the condition for applying a configure action changes from true to false, an associated unconfigure action (if any) is applied. When the condition changes back from false to true, the configure action is re-applied.

description

(Optional) Describes the action, which will be presented in the container viewer.

templateGroups

Specifies one or more item tags, each of which specifies the name of an existing BMC Network Automation template to merge (the term template group is what you call templates inside the BMC Network Automation model, however the term presented in the UI is simply template). If more than one item is specified, the selection of which to use will alternate from one container instance to the next, balancing their use.

Back to top

destroyGuestActionInfoBlueprints Schema

<destroyGuestActionInfoBlueprints>
    <!-- see <destroyGuestActionInfoBlueprint schema --> 
</destroyGuestActionInfoBlueprints>

Description: Each destroyGuestActionInfoBlueprints tag consists of zero or more destroyGuestActionInfoBlueprints tags.

Back to top

externalNetworkSegmentBlueprint Schema

<externalNetworkSegmentBlueprint>
    <defaultEnabledFlag></defaultEnabledFlag>
    <description></description>
    <lockedFlag></lockedFlag>
    <defaultNetworkAddress></defaultNetworkAddress>
    <defaultNetworkMask></defaultNetworkMask>
    <name></name>
    <networkName></networkName>
    <tag></tag>
</externalNetworkSegmentBlueprint>

Description: Each externalNetworkSegmentBlueprint tag specifies an external network connected to a container. External networks are identified in order to be able to refer to them as potential endpoints in path rules added to the container (which are translated by BMC Network Automation into firewall ACL updates).

Children:

TagDescription

defaultEnabledFlag

Specifies whether this external network segment will be enabled by default during container provisioning. Defaults to true. This can be overridden by the BMC Cloud Lifecycle Management.

description

(Optional) Describes the segment, which will be presented in the UI.

lockedFlag

Specifies whether this network segment can be enabled or disabled by the BMC Cloud Lifecycle Management. If it is locked then the state cannot be toggled.

defaultNetworkAddress

Specifies the address of the network connected to container created from this blueprint. If the attribute is left empty this defaults to 0.0.0.0, representing a connection to the internet.

defaultNetworkMask

Specifies the network mask of the network connected to container created from this blueprint. If the attribute is left empty this defaults to 0, representing a connection to the internet.

name

Specifies a way to uniquely identify this external network segment blueprint within this container blueprint.

networkName

Specifies the name of the BMC Cloud Lifecycle Management "network" this segment belongs to.  Unlike the networkNames in NIC/VIP segments, this does not correspond to a BMC Cloud Lifecycle Management network used in provisioning, however it is displayed in the UI when referring to potential path rule endpoints.

tag

Specifies an opaque value that can be used to annotate the container in miscellaneous ways which clients might find useful.  The PCM engine in BMC Network Automation makes no use of this value. This is an optional tag.

Unlike the tags in NIC/VIP segments, this is not used directly in BMC Cloud Lifecycle Management provisioning, but is used by the BMC Cloud Lifecycle Management as a way to refer to an external network indirectly.

Back to top

externalNetworkSegmentBlueprints Schema

<externalNetworkSegmentBlueprints>
     <!-- see externalNetworkSegmentBlueprint> schema --> 
</externalNetworkSegmentBlueprints>

Description: Each externalNetworkSegmentBlueprints tag consists of zero or more externalNetworkSegmentBlueprint tags.

Back to top

guestAddressBlueprint Schema (xsi:type="addressBlueprint")

<guestAddressBlueprint xsi:type="addressBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addressName></addressName>
    <addressPoolName></addressPoolName>
    <condition></condition>
    <gatewayFlag></gatewayFlag>
    <poolPosition></poolPosition>
</guestAddressBlueprints>

Description: A guestAddressBlueprint tag specifies how to acquire an address from either a container or pod level address pool.  Such addresses are defined at the guest node level.  They can be referenced as substitution parameters in the templates used to configure containers (for example, "${container.nodes[My VFW].addresses[My Address]}").

Children:

TagDescription

addressName

The addressName value specifies a way to uniquely identify this address within the guest node.

addressPoolName

The addressPoolName value identifies which container or pod level pool this address should be acquired from.

condition

Defines the condition under which the address should be acquired from its address pool, as a Boolean expression of component states.  Refer to the flexible container documentation for syntax details for these expressions.  If no condition is specified, the address will be acquired as soon as the address pool involved is acquired.

For example, if you want to declare that an address should only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

Note there is an implied condition for a guest address blueprint of the guest node itself having to be enabled before the address will ever be acquired. This condition will be assumed if it is not explicitly specified.

gatewayFlag

The gatewayFlag value indicates whether this address should be considered to be the gateway for its subnet or not.  Each container address pool which servers can be provisioned to must have one address from that pool declared as the gateway address.

poolPosition

An optional tag the specifies a position within the address pool to acquire the address from.  For instance, a poolPosition of "1" would be guaranteed to acquire the value 10.0.0.1 from a 10.0.0.0/24 pool, while a poolPosition of 254 would be guaranteed to acquire the value 10.0.0.254 from that same pool.  If the tag is not specified, then the address will acquire whatever the next available value is from the pool happens to be.

Back to top

guestAddressBlueprint Schema (xsi:type="communityAddressBlueprint")

<guestAddressBlueprint xsi:type="addressBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addressName></addressName>
    <community1AddressPoolName></community1AddressPoolName>
    <community2AddressPoolName></community2AddressPoolName>
    <gatewayFlag></gatewayFlag>
    <poolPosition></poolPosition>
</guestAddressBlueprints>

Description: A guestAddressBlueprint tag specifies how to acquire an address from either a container or pod level address pool.  Such addresses are defined at the guest node level.  They can be referenced as substitution parameters in the templates used to configure containers (for example, "${container.nodes[My VLB].addresses[My Address]}").

A guest address blueprint with xsi:type="communityAddressBlueprint" is a management address for a virtual guest node in a community fault host pair, where a pod level VLAN is being used to manage the guest.  For such addresses, the VLAN being used to manage the guest alternates from one container instance to the next, depending on which community fault group the guest is active in.  Since the management VLAN being used alternates, so must the management address pool alternate. Here you specify the names of the two pod level address pools to alternate between when acquiring this management address.

Children:

TagDescription

addressName

The addressName value specifies a way to uniquely identify this address within the container.

community1AddressPoolName

Name of the pod level address pool to acquire this address from when the guest is active in community fault group 1.

community2AddressPoolName

Name of the pod level address pool to acquire this address from when the guest is active in community fault group 2.

gatewayFlag

The gatewayFlag value indicates whether this address should be considered to be the gateway for its subnet or not.  Each container address pool which servers can be provisioned to must have one address from that pool declared as the gateway address.

poolPosition

An optional tag the specifies a position within the address pool to acquire the address from.  For instance, a poolPosition of "1" would be guaranteed to acquire the value 10.0.0.1 from a 10.0.0.0/24 pool, while a poolPosition of 254 would be guaranteed to acquire the value 10.0.0.254 from that same pool.  If the tag is not specified, then the address will acquire whatever the next available value is from the pool happens to be.

Back to top

guestAddressBlueprints Schema

<guestAddressBlueprints>
     <!-- see <guestAddressBlueprint schema --> 
</guestAddressBlueprints>

Description: Each guestAddressBlueprints tag consists of one or more guestAddressBlueprint tags.

Back to top

guestAuthenticationBlueprint Schema

<guestAuthenticationBlueprint>
    <guestDspName></guestDspName>
    <guestLoginUserName></guestLoginUserName>
    <guestLoginPassword></guestLoginPassword>
    <guestPrivilegedUserName></guestPrivilegedUserName>
    <guestPrivilegedPassword></guestPrivilegedPassword>
</guestAuthenticationBlueprint>

Description: The guestAuthenticationBlueprint tag consists of a guest device's credential parameters. This is a optional tag.  In absence of this tag, the host device's device security profile (DSP) is used to authenticate the guest device.

Children:

TagDescription

guestDspName

If guestDspName is provided, the rest of the child tags are ignored and the specified DSP is used.  If guestDspName is not provided then a new DSP is created using information from the other child tags. Can contain ${runtime.}, ${exec.}, and ${device.*} substitution parameters.

guestLoginUserName

User name to use when logging into the guest.  Can contain ${runtime.} and ${exec.} substitution parameters. This tag should only be populated if the guestDspName child tag is not populated.

guestLoginPassword

Password to use when first logging into the guest.  Can contain ${runtime.} and ${exec.} substitution parameters. This tag should only be populated if the guestDspName child tag is not populated.

guestPrivilegedUserName

User name to use when switching to privileged mode after logging into the guest.  Can contain ${runtime.} and ${exec.} substitution parameters. This tag should only be populated if the guestDspName child tag is not populated.

guestPrivilegedPassword

Password to use when switching to privileged mode after logging into the guest.  Can contain   ${runtime.} and ${exec.} substitution parameters. This tag should only be populated if the guestDspName child tag is not populated.

Back to top

inboundAclBlueprint schema

<inboundAclBlueprint>
    <description>
    <enablePathUpdates></enablePathUpdates>
    <name></name>
    <ruleBlueprints></ruleBlueprints>
</inboundAclBlueprint>

Description: The inboundaclblueprint tag represents attributes of an inbound ACL of a firewall interface (for controlling the flow of packets coming into the interface).  If it is unspecified for a given firewall interface, a default inbound ACL is automatically created.

Children:

TagDescription

description

Optional field to describe this ACL which is presented in the user interface.

enablePathUpdates

The enablePathUpdates tag can take values of true or false.  When it is set to_true_, the ACL created from this blueprint is updated as part of path rule updates where applicable. When it is set to false, this ACL update is skipped during path rule updates. Generally, this is set to true for an inbound ACL. For the default ACL, it is false.

name

The name attribute specifies name of the ACL. The value defaults to "in".

ruleBlueprints

Specifies the collection of rules with which the ACL should be initialized.

Back to top

initGuestActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint")

<initGuestActionInfoBlueprint xsi:type="customActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <description></description>
    <guid></guid>
    <runtimeProps>
        <item>
            <key></key>
            <value></value>
        </item>
    </runtimeProps>
</initGuestActionInfoBlueprint>

Description: The initGuestActionInfoBlueprint specifies an action to initialize the newly created virtual guest on one of the host devices. The host device used will be the one which you specified the guest to become active on during the create action.  When initializing the guest, the action must assign it a management virtual IP address which BMC Network Automation will use to subsequently snapshot and administer the guest device, regardless of which host it is currently active on.  The host you initialize the guest on will automatically propogate the change to the other host (you will wait for the propogation to complete before you complete your action).  

An initGuestActionInfoBlueprint with xsi:type="customActionInfoBlueprint" represents a custom action to be executed to initialize the guest.

Children:

TagDescription

description

An optional field to describe the action, which will be presented in the container viewer.

guid

Identifies which custom action is involved (view the adapter in question in the BMC Network Automation UI to see its GUID value).

runtimeProps

Contains zero or more runtime properties that can be specified as arguments to pass into the actions.  Each runtime property requires a key which is the name of the property, and a value.  The value can include embedded substitution parameter references which will be resolved before the value is passed to the action. The allowed substitution parameter types are the same as would be allowed in a template being merged to the node's device.  So for instance you could specify a value of ${container.name}, in order to pass in the name of the container involved, or you could specify ${runtime.myParam} in order to pass in a value gathered in the BMC Cloud Lifecycle Management UI from the admin creating the container.

Back to top

initGuestActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint")

<initGuestActionInfoBlueprint xsi:type="externalScriptActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <description></description>
    <guid></guid>
    <runtimeProps>
        <item>
            <key></key>
            <value></value>
        </item>
    </runtimeProps>
</initGuestActionInfoBlueprint>

Description: The initGuestActionInfoBlueprint specifies an action to initialize the newly created virtual guest on one of the host devices.  The host device used will be the one which you specified the guest to become active on during the create action.  When initializing the guest, the action must assign it a management virtual IP address which BMC Network Automation will use to subsequently snapshot and administer the guest device, regardless of which host it is currently active on.  The host you initialize the guest on will automatically propogate the change to the other host (you will wait for the propogation to complete before you complete your action).  

An initGuestActionInfoBlueprint with xsi:type="externalScriptActionInfoBlueprint" represents an external script action to be executed to initialize the guest.

Children:

TagDescription

description

An optional field to describe the action, which will be presented in the container viewer.

guid

Identifies which custom action is involved (view the adapter in question in the BMC Network Automation UI to see its GUID value).

runtimeProps

Contains zero or more runtime properties that can be specified as arguments to pass into the actions.  Each runtime property requires a key which is the name of the property, and a value.  The value can include embedded substitution parameter references which will be resolved before the value is passed to the action. The allowed substitution parameter types are the same as would be allowed in a template being merged to the node's device.  So for instance you could specify a value of ${container.name}, in order to pass in the name of the container involved, or you could specify ${runtime.myParam} in order to pass in a value gathered in the BMC Cloud Lifecycle Management UI from the admin creating the container.

Back to top

initGuestActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

<initGuestActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <requiresTunneling></requiresTunneling>    
    <description></description>
    <name></name>
    <templateGroups>
        <item></item>
    </templateGroups>
</initGuestActionInfoBlueprint>

Description: The initGuestActionInfoBlueprint specifies an action to initialize the newly created virtual guest on one of the host devices. The host device used will be the one which you specified the guest to become active on during the create action.  When initializing the guest, the action must assign it a management virtual IP address which BMC Network Automation will use to subsequently snapshot and administer the guest device, regardless of which host it is currently active on. The host you initialize the guest on will automatically propogate the change to the other host (you will wait for the propogation to complete before you complete your action).  

An initGuestActionInfoBlueprint with xsi:type="mergeActionInfoBlueprint" represents a Deploy to Active action to be executed to initialize the guest.

Children:

TagDescription

requiresTunneling

An optional field used to force the file transfer mode be set to Tunneling protocol for a Deploy to Active action. When the value of this flag is set to true or if the value of device type.requiresTunnelingForContainerMerge is set to true, BMC Network Automation uses the Tunneling file transfer mode for the Deploy to Active action. Otherwise, BMC Network Automation uses the file transfer mode specified for the device to perform the Deploy to Active action.

description

An optional field to describe the action, which will be presented in the container viewer.

name

An optional field to give the action a name. This is used for conditional actions where both the configure action and an associated unconfigure action will both be given the same name, so that BMC Network Automation knows to coordinate the application of the two actions, to guarantee that when the condition no longer applies for the configure action, the unconfigure action will be applied, and vice-versa.

templateGroups

Specifies one or more item tags, each of which specifies the name of an existing BMC Network Automation template to merge (the term template group is what you call templates inside the BMC Network Automation model, however the term presented in the UI is simply template).  If more than one item is specified, the selection of which to use will alternate from one container instance to the next, balancing their use.

Back to top

integerBlueprint Schema

<integerBlueprint>
    <condition></condition>
    <integerName></integerName>
    <integerPoolName></integerPoolName>
</integerBlueprint>

Description: Each integerBlueprint tag specifies how to acquire a container level numeric value from an integer pool in the pod on which the container is being created. Container level integers can be referenced (by the integerName) as substitution parameters in the templates used to configure containers (for example, "${container.integers[My Numeric Value]}".

Children:

TagDescription

condition

Defines the condition under which the integer should be acquired from its pool, as a Boolean expression of component states.  Refer to the flexible container documentation for syntax details for these expressions.  If no condition is specified, the integer will be acquired when the container is provisioned.

For example, if you want to declare that an integer should only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

integerName

The integerName value specifies a way to uniquely identify this integer among the container level integers.

integerPoolName

The integerPoolName tag specifies which integer pool in the pod to acquire this numeric value from.  Note that a container may acquire more than one value from the same pool by specifying an integerBlueprint for each value, using the same integerPoolName.

Back to top

integerBlueprints Schema

<integerBlueprints>
    <!-- see <integerBlueprint> schema --> 
</integerBlueprints>

Description: Each integerBlueprints tag consists of zero or more integerBlueprint tags.

Back to top

managedInterfaceBlueprint Schema

<managedInterfaceBlueprint>
    <bridgeInterfaceNames>
        <bridgeInterfaceName></bridgeInterfaceName>
    </bridgeInterfaceNames>
    <description></description>
    <inboundAclBlueprint>
        <!-- see inboundAclBlueprint schema -->
    </inboundAclBlueprint>
    <name></name>
    <nameWithinFirewall></nameWithinFirewall>
    <outboundAclBlueprint>
        <!-- see outboundAclBlueprint schema -->
    </outboundAclBlueprint>
    <servicedSegmentNames>
        <servicedSegmentName></servicedSegmentName>
    </servicedSegmentNames>
</managedInterfaceBlueprint>

Description: Each managedInterfaceBlueprint tag represents an interface in a firewall (VFW) which BMC Network Automation is managing security for.  In the case of a firewall operating in transparent (non-routed) mode, there will typically be two interfaces to manage, one "outside" interface and one "inside" interface.  In the case of a firewall operating in routed mode, there will typically be more than two interfaces to manage.

Children:

TagDescription

bridgeInterfaceNames

The bridgeIntefaceNames tag contains zero or more bridgeInterfaceName tags.  Each bridgeInterfaceName tag names an interface in a peer firewall which this managed interface is directly connected to. The bridge interface names are used in path rule updates to help BMC Network Automation understand how different firewalls are connected to each other.

description

The description tag is optional and provides a description about this managed interface.

inboundAclBlueprint

See inboundAclBlueprint schema.

name

The name attribute is used to identify the interface uniquely within the container model.

nameWithinFirewall

The name of the interface used in the actual firewall device is identified by the nameWithinFirewall attribute. This tag can contain embedded substitution parameter references.

  • If it does contain such references, this attribute is propagated from the managedInterfaceBlueprint to the firewall interface instance when the instance is enabled, at which time any embedded substitution parameter references are resolved.
  • If it does not contain any such references, it is propagated to the instance when it is created.

The resolved value can be referenced in templates used to configure the container, via the "${container.node.managedInterfaces[MyInterface].sanitizedName}" substitution parameter. The phrase "MyInterface" corresponds to the name of the interface within the container model, and the value that the parameter resolves to is the nameWithinFirewall value after it has been modified to replace non alphanumeric characters with dashes to make the name more palatable to the device. 

outboundAclBlueprint

See outboundAclBlueprint schema.

servicedSegmentNames

The servicedSegmentNames tag can have zero or more servicedSegmentName tags.  An interface "services" a segment if it is "directly" connected to it and secures traffic for it.  Being directly connected to a segment means there is not other firewall in between the interface and the segment (though there may be other infrastructure in between).  An outside interface will typically name an external segment as its serviced segment. An inside interfaces will typically name VIP or NIC segments as the segments it serves.

Back to top

managedInterfaceBlueprints Schema

<managedInterfaceBlueprints>
    <!-- see <managedInterfaceBlueprint> schema --> 
</managedInterfaceBlueprint>

Description: Each managedInterfaceBlueprints tag consists of zero or more managedInterfaceBlueprint tags.

Back to top

natTypeBlueprint Schema

<natTypeBlueprint>
    <addressTranslatorBlueprints>
        <!-- see addressTranslatorBlueprint schema -->
    </addressTranslatorBlueprints>
    <createNatActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <!-- see createNatActionInfoBlueprint schema -->
    </createNatActionInfoBlueprint>
    <removeNatActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <!-- see removeNatActionInfoBlueprint schema -->
    </removeNatActionInfoBlueprint>
    <natRuleBlueprints>
        <!-- see natRuleBlueprint schema -->
    </natRuleBlueprints>
</natTypeBlueprint>

Description: The natTypeBlueprint specifies how BMC Network Automation should acquire and translate NAT addresses. The addresses acquired are typically the public address for a private address which has already been acquired during NIC provisioning. You can configure NAT on any container node which has the underlying device supporting NAT. However, NAT is typically configured on VFWs. If you are configuring NAT on a node other than VFW, the node must be at the edge of the container, upstream of any VFWs behind the node, in order for the translation of path rules into firewall rules to work correctly in those VFWs. Within each natTypeBlueprint, you specify actionInfoBlueprints that are Deploy to Active actions for creating a new NAT entry when a public address is acquired, and removing an old NAT entry when a public address is released. 

Children:

TagDescription

addressTranslatorBlueprints

Contains one or more addressTranslatorBlueprint. See addressTranslatorBlueprint schema

createNatActionInfoBlueprint

See createNatActionInfoBlueprint schema .

removeNatActionInfoBlueprint

See removeNatActionInfoBlueprint schema .

natRuleBlueprints

See natRuleBlueprints schema.

Back to top

natRuleBlueprint Schema

<natRuleBlueprint>
    <description></description>
    <destinationHostAddress></destinationHostAddress>
    <destinationNetworkAddress></destinationNetworkAddress>
    <destinationNetworkMask></destinationNetworkMask>
    <destinationPortHigh></destinationPortHigh>
    <destinationPortLow></destinationPortLow>
    <destinationPort></destinationPort>
    <loggingEnabled></loggingEnabled>
    <nattedHostIsSource></nattedHostIsSource>
    <permitFlag></permitFlag>
    <sourceHostAddress></sourceHostAddress>
    <sourceNetworkAddress></sourceNetworkAddress>
    <sourceNetworkMask></sourceNetworkMask>
    <transportProtocol></transportProtocol>
</natRuleBlueprint>

Description: Defined as a collection within the natRuleBlueprints tag, a natRuleBlueprint describes detailed information for creating a NAT rule. A NAT rule is essentially a firewall rule that is created as part of applying network address translation. The source or the destination of such a rule is always the public address of the host for which network address translation was applied, and as such is not specified in the blueprint.

Children:

TagDescription

description

Specifies an optional field that describes the NAT rule, which will be presented in the container viewer.

destinationHostAddress

Specifies the IP address of the host that you are blocking, specified as either the IP address or a combination of network address and network mask. If nattedHostIsSource is false, this attribute need not be specified. This tag supports substitution parameters.

destinationNetworkAddress

Specifies the IP address of the destination subnet (range of hosts) that you are blocking, specified as either the IP address or a combination of network address and network mask. If nattedHostIsSource is false, this attribute need not be specified. This tag supports substitution parameters.

destinationNetworkMask

Specifies the mask of the destination subnet (range of hosts) that you are blocking, specified as either the IP address or a combination of network address and network mask. If nattedHostIsSource is false, this attribute need not be specified. This tag supports substitution parameters.

destinationPort

Specifies the destination port being blocked.

destinationPortHigh

Specifies the higher value for destination port range being blocked.

destinationPortLow

Specifies the lower value for destination port range being blocked.

loggingEnabled

Indicates whether the firewall rule created from this blueprint will have logging enabled.

nattedHostIsSource

Indicates whether the host where network address translation is applied is the source or the destination.

permitFlag

Specifies whether the rule is permitting or denying the specified traffic.

sourceHostAddress

Specifies the address of the source involved when blocking a particular host. Either source host address or combination of source network address and source network mask should be specified. If nattedHostIsSource is true, this attribute need not be specified. This tag supports substitution parameters.

sourceNetworkAddress

Specifies the address of the source subnet involved when blocking a range of hosts. Either source host address or combination of source network address and source network mask should be specified. If nattedHostIsSource is true, this attribute need not be specified. This tag supports substitution parameters.

sourceNetworkMask

Specifies the mask of the source subnet involved when blocking a range of hosts. Either source host address or combination of source network address and source network mask should be specified. If nattedHostIsSource is true, this attribute need not be specified. This tag supports substitution parameters.

transportProtocol

Specifies the transport protocol being blocked.

Back to top

natRuleBlueprints Schema

<natRuleBlueprints>
    <!-- see <natRuleBlueprint> schema --> 
</natRuleBlueprints>

Description: Each natRuleBlueprints tag consists of zero or more natRuleBlueprint tags.

Back to top

networkPathBlueprint Schema

<networkPathBlueprint>
    <endpoint1Name></endpoint1Name>
    <endpoint2Name></endpoint2Name>
    <name></name>
    <servicedNodeNames>
        <servicedNodeName></servicedNodeName>
    </servicedNodeNames>
</networkPathBlueprint>

Description: Each networkPathBlueprint tag identifies a route between 2 endpoints in the container. An endpoint is a network segment, which can either be an external segment or an internal (NIC/VIP) segment.  VFW or VLB hops (if any), between the endpoints are listed (in order, traversing from endpoint 1 to 2). A network path is intended to identify which endpoints can potentially talk to each other within the container. The path rule update logic uses this information to figure out how to translate a high level path rule into low level ACL updates in each of the VFWs along the path.

The reason VLB hops are also identified so that you can automatically derive network paths in which a VLB (or rather its VIP segment) is an endpoint, so that the blueprint author does not have to specify them if he doesn't want to. For instance, if you specify a network path between an external segment and a NIC segment, with a VFW and VLB as hops along the way, BMC Network Automation can automatically derive a related network path between the external segment an the VIP segment which balances traffic for that NIC segment. BMC Network Automation can also automatically derive a related network path between the VIP segment and the NIC segment.

Children:

TagDescription

endpoint1Name

The endpoint1Name corresponds to network segment name (internal or external).

endpoint2Name

The endpoint2Name corresponds to network segment name (internal or external).

name

The name attribute uniquely identifies the network path blueprint within the container blueprint.

servicedNodeNames

The servicedNodeNames consists of one or more servicedNodeName tags.  Each servicedNodeName tag represents the name of a service node (VFW or VLB) which is a hop along the path between the 2 endpoints (in order from endpoint 1 to endpoint 2).

Back to top

networkPathBlueprints Schema

<networkPathBlueprints>
    <!-- see <networkPathBlueprint> schema --> 
</networkPathBlueprints>

Description: Each networkPathBlueprints tag consists of zero or more networkPathBlueprint tags.

Back to top

nicSegmentBlueprint Schema

<nicSegmentBlueprint xsi:type="containerNicNetworkSegmentBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addressPoolName></addressPoolName>
    <customerFlag></customerFlag>
    <defaultEnabledFlag></defaultEnabledFlag>
    <description></description>
    <lockedFlag></lockedFlag>
    <managementFlag></managementFlag>
    <name></name>
    <networkName></networkName>
    <tag></tag>
    <vlanName></vlanName>
</nicSegmentBlueprint>

Description: A NIC network segment specifies an internal network segment where virtual or physical server NICs can be provisioned.  It encapsulates a container level VLAN to which the NICs will be connected, and a container level address pool which will be used to acquire addresses for the NICs.

Children:

TagDescription

addressPoolName

The address pool name specifies the address pool which will be used to acquire server NIC addresses

customerFlag

The customerFlag defines whether this segment carries customer (non-management) traffic or not.

defaultEnabledFlag

The defaultEnabledFlag specifies whether this NIC segment will be enabled by default during container provisioning. This can be overridden by the BMC Cloud Lifecycle Management.

description

An optional field to describe the segment, which will be presented in the UI.

lockedFlag

The locked flag specifies whether this network segment can be enabled or disabled by the BMC Cloud Lifecycle Management.  If it is locked then the state cannot be toggled.

managementFlag

The managementFlag defines whether this segment carries management traffic or not.

name

A name for the segment, unique across the container.

networkName

The name of the BMC Cloud Lifecycle Management "network" this segment belongs to.  A BMC Cloud Lifecycle Management network almost corresponds exactly to BMC Network Automation's notion of a network segment, but not quite.  The BMC Cloud Lifecycle Management imposes the constraint that its networks must each encapsulate a different address pool.  BMC Network Automation does not impose this constraint on its network segments (e.g. you could have a VLB in one-arm mode where the VIP segment and NIC segment involved both encapsulate the same VLAN and address pool).  Another difference is that BMC Cloud Lifecycle Management networks only need to be named uniquely within a given scope (e.g. within a given zone), whereas BMC Network Automation network segments must be uniquely named across the entire container.

tag

A tag is an opaque value that can be used to annotate the container in miscellaneous ways which clients might find useful.  The PCM engine in BMC Network Automation makes no use of this value. This is an optional tag.

In the case of the BMC Cloud Lifecycle Management client, they use this to specify one or more hints to be used when they need to select a particular network segment in the container (e.g. during server provisioning).  The container blueprint defines the default hints, which are propagated to the container instance created from it.  The BMC Cloud Lifecycle Management admin is free to override them with non-default values in the version of the container instance stored in the cloud DB subsequently. 

For example, you might specify a tag with the value "Purpose[WEB],Quality[HI,LOW]" to indicate that a server being provisioned which was tagged with "Purpose[WEB]" and either "Quality[HI]" or "Quality[LOW]" could be provisioned to this segment by default.

vlanName

Specifies the vlan to which NICs will be connected when they are provisioned to this segment.

Back to top

nicSegmentBlueprints Schema

<nicSegmentBlueprints xsi:type="containerNicNetworkSegmentBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <!-- see <nicSegmentBlueprint> schema --> 
</nicSegmentBlueprints>

Description: Each nicSegmentBlueprints tag consists of zero or more nicSegmentBlueprint tags.

Back to top

nodeBlueprint Schema (default xsi:type)

<nodeBlueprint>
   <addressBlueprints>
        <!-- see addressBlueprint schema -->
    </addressBlueprints>
    <category></category>
    <configureActionInfoBlueprints>
        <!-- see configureActionInfoBlueprint schema -->
    </configureActionInfoBlueprints>
    <description></description>
    <dummyHostFlag></dummyHostFlag>
    <name></name>
    <numVrfs></numVrfs>
    <role></role>
    <unconfigureActionInfoBlueprints>
        <!-- see unconfigureActionInfoBlueprint schema -->
    </unconfigureActionInfoBlueprints>
</nodeBlueprint>

Description: Each nodeBlueprint tag specifies how to create a container node. A container node is hosted on a particular pod node, and represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the container instance.

The nodeBlueprint tag, with a default xsi:type value, specifies how to create a basic (vanilla) type of container node. A basic node represents an infrastructure device within the container, which does not require additional administration after initially configured. This includes all devices except firewall hosts, load balancer hosts, and access switches, since each of those require additional administration.

Children:

TagDescription

addressBlueprints

Consists of zero or more addressBlueprint tags.See addressBlueprint schema.

category

The category value must be one of the allowed values for  BMC Network Automation device categories, as defined in CategoryMap.xml (e.g. "1" for a router, "2" for a switch, "4" for a firewall, "7" for a load balancer, ...).  In order for a container node blueprint to be capable of creating a container node instance on a given pod node, their category values must match. For a basic node the category value is typically 2.

configureActionInfoBlueprints

Consists of zero or more configureActionInfoBlueprint tags. See configureActionInfoBlueprint schema.

description

An optional field describing the node which will be presented in the UI.

dummyHostFlag

The dummyHostFlag tag was necessary in a prior release to workaround the limitations of not supporting multiple create-guest actions in a fault host pair blueprint within a dynamic container.  Those limitations have since been lifted, but you retain this tag for backward compatibility reasons. The flag allows BMC Network Automation to ensure that the actions of a node flagged as a dummy host get executed after the create-guest action but before the init-guest action defined in the fault host pair.

name

The name value specifies a way to uniquely identify this node within the container.

numVrfs

The numVrfs tag optionally defines the number of VRFs that will be created on the device when it is configured for this container.  If an upper limit to the number of VRFs has been specified for the underlying pod node, then one will not be allowed to exceed that limit when attempting to create new containers.

role

The role value identifies the role which this node plays within the container.  In the example below I have specified a value of "Edge" to indicate that this is the node at the edge of the container. If there were two such edge nodes within the container, paired for redundancy, then each would need a unique role value (e.g. "Edge 1" and "Edge 2").  The role value specified for a container node is matched against the role values specified by pod nodes when deciding where to host each container node within a pod.  If there are multiple pod nodes with the same role value, then the choice of which one to host the container node on will be made in such a way as to automatically balance the usage of the underlying pod nodes from one container instance to the next, for scalability.

unconfigureActionInfoBlueprints

Consists of zero of more unconfigureActionInfoBlueprint tags. See unconfigureActionInfoBlueprint schema.

Back to top

nodeBlueprint Schema (xsi:type="containerFirewallHostBlueprint")

<nodeBlueprint xsi:type="containerFirewallHostBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addressBlueprints>
        <!-- see addressBlueprint schema -->
    </addressBlueprints>
    <category></category>
    <configureActionInfoBlueprints>
        <!-- see configureActionInfoBlueprint schema -->
    </configureActionInfoBlueprints>
    <description></description>
    <name></name>
    <natTypeBlueprint>
        <!-- see natTypeBlueprint schema -->
    </natTypeBlueprint>
    <numVrfs></numVrfs>
    <role></role>
    <unconfigureActionInfoBlueprints>
        <!-- see unconfigureActionInfoBlueprint schema -->
    </unconfigureActionInfoBlueprints>
    <virtualGuestBlueprint xsi:type="containerVfwBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <!-- see virtualGuestBlueprint schema -->
    </virtualGuestBlueprint>
</nodeBlueprint>

Description: Each nodeBlueprint tag specifies how to create a container node. A container node is hosted on a particular pod node, and represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the container instance.

The nodeBlueprint tag, with an xsi:type value of containerFirewallHostBlueprint, specifies how to create a firewall host type of container node. A firewall host node represents a device on which a virtual guest firewall (VFW) will be created for this container (for example, a Cisco FWSM or ASA). ACLs for the VFW are later administered from the BMC Cloud Lifecycle Management, either automatically during server provisioning, or ad hoc from the UI.

Note that when the container is created, a container node will automatically be created encapsulating the VFW device created on the host device. The VFW device will be assigned the same username and password as the host device by default, but will be given its own virtual IP address for BMC Network Automation to use to administer it subsequently.

Also note that if this host is part of a fault host pair (using active active fault tolerance), the VFW will be active on one or the other of the devices in the pair, alternating from one container instance to the next.

Back to top

nodeBlueprint Schema (xsi:type="containerHostBlueprint")

<nodeBlueprint xsi:type="containerHostBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addressBlueprints>
        <!-- see addressBlueprint schema -->
    </addressBlueprints>
    <category></category>
    <configureActionInfoBlueprints>
        <!-- see configureActionInfoBlueprint schema -->
    </configureActionInfoBlueprints>
    <description></description>
    <name></name>
    <numVrfs></numVrfs>
    <role></role>
    <unconfigureActionInfoBlueprints>
        <!-- see unconfigureActionInfoBlueprint schema -->
    </unconfigureActionInfoBlueprints>
    <virtualGuestBlueprint>
        <!-- see virtualGuestBlueprint schema -->
    </virtualGuestBlueprint>
</nodeBlueprint>

Description: Each nodeBlueprint tag specifies how to create a container node. A container node is hosted on a particular pod node, and represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the container instance.

The nodeBlueprint tag, with an xsi:type value of containerHostBlueprint, specifies how to create a host type of container node. A virtual guest (Vanilla type) node is created for the container on this host node. (for example, a Cisco CSR 1000V).

Children:

TagDescription

addressBlueprints

Consists of zero or more addressBlueprint tags. See addressBlueprint schema .

category

Specifies the category value that must be one of the allowed values for BMC Network Automation device categories, as defined in CategoryMap.xml (for example, "1" for a router, "2" for a switch, "4" for a firewall, "7" for a load balancer, ...). In order for a container node blueprint to be capable of creating a container node instance on a given pod node, their category values must match. For a firewall host node the category value is typically 4.

configureActionInfoBlueprints

Consists of zero or more configureActionInfoBlueprint tags. See configureActionInfoBlueprint schema.

description

(Optional) Describes the node which will be presented in the UI.

name

Specifies a way to uniquely identify this node within the container.

numVrfs

(Optional) Defines the number of VRFs that will be created on the device when it is configured for this container.  If an upper limit to the number of VRFs has been specified for the underlying pod node, then one will not be allowed to exceed that limit when attempting to create new containers.

role

Identifies the role which this node plays within the container. In the example below I have specified a value of "Edge" to indicate that this is the node at the edge of the container.  If there were two such edge nodes within the container, paired for redundancy, each would need a unique role value (for example, "Edge 1" and "Edge 2"). The role value specified for a container node is matched against the role values specified by pod nodes when deciding where to host each container node within a pod. If there are multiple pod nodes with the same role value, then the choice of which one to host the container node on will be made in such a way as to automatically balance the usage of the underlying pod nodes from one container instance to the next, for scalability.

unconfigureActionInfoBlueprints

Consists of zero of more unconfigureActionInfoBlueprint tags. See unconfigureActionInfoBlueprint schema.

virtualGuestBlueprint

See virtualGuestBlueprint schema.

Back to top

nodeBlueprint Schema (xsi:type="containerHypervisorSwitchBlueprint")

<nodeBlueprint xsi:type="containerHypervisorSwitchBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addressBlueprints>
        <!-- see addressBlueprint schema -->
    </addressBlueprints>
    <category></category>
    <configureActionInfoBlueprints>
        <!-- see configureActionInfoBlueprint schema -->
    </configureActionInfoBlueprints>
    <description></description>
    <name></name>
    <numVrfs></numVrfs>
    <portTypeBlueprints>
        <!-- see portTypeBlueprint schema -->
    </portTypeBlueprints>
    <role></role>
    <unconfigureActionInfoBlueprints>
        <!-- see unconfigureActionInfoBlueprint schema -->
    </unconfigureActionInfoBlueprints>
</nodeBlueprint>

Description: Each nodeBlueprint tag specifies how to create a container node. A container node is hosted on a particular pod node, and represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the container instance.

The nodeBlueprint tag, with an xsi:type value of containerHypervisorSwitchBlueprint, specifies how to create a hypervisor access switch type of container node. A hypervisor switch node represents a device within the container which controls switching for a given hypervisor server or cluster that virtual servers are being provisioned to (for example, a Cisco Nexus 1000v or a VMWare VSwitch) for this container.

Children:

TagDescription

addressBlueprints

Consists of zero or more addressBlueprint tags. See addressBlueprint schema.

category

The category value must be one of the allowed values for BMC Network Automation device categories, as defined in CategoryMap.xml (for example, "1" for a router, "2" for a switch, "4" for a firewall, "7" for a load balancer, ...).  In order for a container node blueprint to be capable of creating a container node instance on a given pod node, their category values must match. A hypervisor switch node typically has a category value of 2.

configureActionInfoBlueprints

Consists of zero or more configureActionInfoBlueprint tags. See configureActionInfoBlueprint schema.

description

An optional field describing the node which will be presented in the UI.

name

The name value specifies a way to uniquely identify this node within the container.

numVrfs

The numVrfs optionally tag defines the number of VRFs that will be created on the device when it is configured for this container. If an upper limit to the number of VRFs has been specified for the underlying pod node, then one will not be allowed to exceed that limit when attempting to create new containers.

portTypeBlueprints

Consists of one or more portTypeBlueprint tags. See portTypeBlueprint schema.

role

The role value identifies the role which this node plays within the container. In the example below I have specified a value of "Edge" to indicate that this is the node at the edge of the container.  If there were two such edge nodes within the container, paired for redundancy, then each would need a unique role value (for example, "Edge 1" and "Edge 2"). The role value specified for a container node is matched against the role values specified by pod nodes when deciding where to host each container node within a pod. If there are multiple pod nodes with the same role value, then the choice of which one to host the container node on will be made in such a way as to automatically balance the usage of the underlying pod nodes from one container instance to the next, for scalability.

unconfigureActionInfoBlueprints

Consists of zero of more unconfigureActionInfoBlueprint tags. See unconfigureActionInfoBlueprint schema.

Back to top

nodeBlueprint Schema (xsi:type="containerLoadBalancerHostBlueprint")

<nodeBlueprint xsi:type="containerLoadBalancerHostBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addressBlueprints>
        <!-- see addressBlueprint schema -->
    </addressBlueprints>
    <category></category>
    <configureActionInfoBlueprints>
        <!-- see configureActionInfoBlueprint schema -->
    </configureActionInfoBlueprints>
    <description></description>
    <name></name>
    <numVrfs></numVrfs>
    <role></role>
    <unconfigureActionInfoBlueprints>
        <!-- see unconfigureActionInfoBlueprint schema -->
    </unconfigureActionInfoBlueprints>
    <virtualGuestBlueprint xsi:type="containerVlbBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <!-- see virtualGuestBlueprint schema -->
    </virtualGuestBlueprint>
</nodeBlueprint>

Description: Each nodeBlueprint tag specifies how to create a container node. A container node is hosted on a particular pod node, and represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the container instance.

The nodeBlueprint tag, with an xsi:type value of containerLoadBalancerlHostBlueprint, specifies how to create a load balancer host type of container node. A load balancer host node represents a device on which a virtual guest load balancer (VLB) will be created for this container (for example, a Cisco ACE). LB pools can later be added to the VLB, and server entries can be added to those pools, administered from the BMC Cloud Lifecycle Management, either automatically during server provisioning, or ad hoc from the UI.

Note that when the container is created, a container node will automatically be created encapsulating the VLB device created on the host device. The VFW device will be assigned the same username and password as the host device by default, but will be given its own virtual IP address for BMC Network Automation to use to administer it subsequently.

Also note that if this host is part of a fault host pair (using active active fault tolerance), the VLB will be active on one or the other of the devices in the pair, alternating from one container instance to the next.

Children:

TagDescription

addressBlueprints

Consists of zero or more addressBlueprint tags. See addressBlueprint schema.

category

The category value must be one of the allowed values for BMC Network Automation device categories, as defined in CategoryMap.xml (for example, "1" for a router, "2" for a switch, "4" for a firewall, "7" for a load balancer, ...).  In order for a container node blueprint to be capable of creating a container node instance on a given pod node, their category values must match. A load balancer host node typically has a category value of 7.

configureActionInfoBlueprints

Consists of zero or more configureActionInfoBlueprint tags. See configureActionInfoBlueprint schema.

description

An optional field describing the node which will be presented in the UI.

name

The name value specifies a way to uniquely identify this node within the container.

numVrfs

The numVrfs tag optionally defines the number of VRFs that will be created on the device when it is configured for this container.  If an upper limit to the number of VRFs has been specified for the underlying pod node, then one will not be allowed to exceed that limit when attempting to create new containers.

role

The role value identifies the role which this node plays within the container. In the example below I have specified a value of "Edge" to indicate that this is the node at the edge of the container.  If there were two such edge nodes within the container, paired for redundancy, then each would need a unique role value (for example, "Edge 1" and "Edge 2"). The role value specified for a container node is matched against the role values specified by pod nodes when deciding where to host each container node within a pod.  If there are multiple pod nodes with the same role value, then the choice of which one to host the container node on will be made in such a way as to automatically balance the usage of the underlying pod nodes from one container instance to the next, for scalability.

unconfigureActionInfoBlueprints

Consists of zero of more unconfigureActionInfoBlueprint tags. See unconfigureActionInfoBlueprint schema.

virtualGuestBlueprint

See virtualGuestBlueprint schema with xsi:type="containerVlbBlueprint.

Back to top

nodeBlueprint Schema (xsi:type="containerPhysicalSwitchBlueprint")

<nodeBlueprint xsi:type="containerPhysicalSwitchBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addressBlueprints>
        <!-- see addressBlueprint schema -->
    </addressBlueprints>
    <category></category>
    <configureActionInfoBlueprints>
        <!-- see configureActionInfoBlueprint schema -->
    </configureActionInfoBlueprints>
    <description></description>
    <name></name>
    <numVrfs></numVrfs>
    <provisionSwitchGuid></provisionSwitchGuid>
    <role></role>
    <unconfigureActionInfoBlueprints>
        <!-- see unconfigureActionInfoBlueprint schema -->
    </unconfigureActionInfoBlueprints>
</nodeBlueprint>

Description: Each nodeBlueprint tag specifies how to create a container node. A container node is hosted on a particular pod node, and represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the container instance.

The nodeBlueprint tag, with an xsi:type value of containerPhysicalSwitchBlueprint, specifies how to create a physical access switch type of container node. A physical switch node represents a device within the container where physical server are connected.

Children:

TagDescription

addressBlueprints

Consists of zero or more addressBlueprint tags. See addressBlueprint schema.

category

The category value must be one of the allowed values for BMC Network Automation device categories, as defined in CategoryMap.xml (for example, "1" for a router, "2" for a switch, "4" for a firewall, "7" for a load balancer, ...). In order for a container node blueprint to be capable of creating a container node instance on a given pod node, their category values must match. A physical switch node typically has a category value of 2.

configureActionInfoBlueprints

Consists of zero or more configureActionInfoBlueprint tags. See configureActionInfoBlueprint schema.

description

An optional field describing the node which will be presented in the UI.

name

The name value specifies a way to uniquely identify this node within the container.

numVrfs

The numVrfs tag optionally defines the number of VRFs that will be created on the device when it is configured for this container.  If an upper limit to the number of VRFs has been specified for the underlying pod node, then one will not be allowed to exceed that limit when attempting to create new containers.

provisionSwitchGuid

The provisionSwitchGuid tag specifies the guid of the action that would be run to provision the switch port on the physical switch. This tag is required.

role

The role value identifies the role which this node plays within the container. In the example below I have specified a value of "Edge" to indicate that this is the node at the edge of the container.  If there were two such edge nodes within the container, paired for redundancy, then each would need a unique role value (for example, "Edge 1" and "Edge 2"). The role value specified for a container node is matched against the role values specified by pod nodes when deciding where to host each container node within a pod.  If there are multiple pod nodes with the same role value, then the choice of which one to host the container node on will be made in such a way as to automatically balance the usage of the underlying pod nodes from one container instance to the next, for scalability.

unconfigureActionInfoBlueprints

Consists of zero of more unconfigureActionInfoBlueprint tags. See unconfigureActionInfoBlueprint schema.

Back to top

nodeBlueprints Schema

<nodeBlueprints>
    <!-- see <nodeBlueprint schema --> 
</nodeBlueprints>

Description: Each nodeBlueprints tag consists of one or more nodeBlueprint tags.

Back to top

outboundAclBlueprint schema

<outboundAclBlueprint>
    <description></description>
    <enablePathUpdates></enablePathUpdates>
    <name></name>
    <ruleBlueprints></ruleBlueprints>
</outboundAclBlueprint>

Description: The outboundaclblueprint tag represents attributes of an outbound ACL of a firewall interface for controlling the flow of packets going out the interface. If it is unspecified for a given firewall interface, a default inbound ACL is automatically created.

Children:

TagDescription

description

An optional field describing the ACL which is presented in the user interface.

enablePathUpdates

The enablePathUpdates tag can take values of true or false. When it is true, the ACL created from this blueprint is updated as part of path rule updates where applicable. When it is false, this ACL update is skipped during path rule updates. Generally it is false for an outbound ACL. For the default ACL, it is false.

name

The name attribute specifies name of the ACL. Default value is out.

ruleBlueprints

Specifies the collection of rules with which the ACL should be initialized.

Back to top

pairBlueprint Schema (default xsi:type)

<pairBlueprint>
    <addressBlueprints>
        <!-- see addressBlueprint schema -->
    </addressBlueprints>
    <name></name>
    <nodeBlueprints>
        <nodeBlueprint></nodeBlueprint>
        <nodeBlueprint></nodeBlueprint>
    </nodeBlueprints>
</pairBlueprint>

Description: Each pairBlueprint tag specifies how to create a container pair. A container pair is hosted on a particular pod pair, and associates two redundant nodes within the container.

The pairBlueprint tag, with a default xsi:type value, specifies how to create a basic (vanilla) type of container pair. A basic pair specifies two nodes within the container which provide redundancy, but which require no special configuration logic at the pair level to achieve this. The only reason for modelling it typically is to be able to declare parameters at the pod parameters or address blueprints whose scope you want to limit to just this pair.

Children:

TagDescription

addressBlueprints

Consists of zero or more addressBlueprint tags. See addressBlueprint schema.

name

Specifies a way to uniquely identify this pair within the container.

nodeBlueprints

Consists of two nodeBlueprint tags. Each nodeBlueprint tag specifies the name of a node blueprint already defined within the container. Both node blueprints must have the same category value. The determination of which pod pair to host the container pair on is made by matching the roles of the container nodes against the nodes in the pod nodes. If there are multiple pod pairs which match, then the choice of which one to host the container pair on will be made in such a way as to automatically balance the usage of the underlying pod pairs from one container instance to the next, for scalability.

Back to top

pairBlueprint Schema (xsi:type="containerCommunityFaultHostPairBlueprint")

<pairBlueprint xsi:type="containerCommmunityFaultHostPairBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addressBlueprints>
        <!-- see addressBlueprint schema -->
    </addressBlueprints>
    <createGuestActionInfoBlueprint>
        <!-- see createGuestActionInfoBlueprint schema -->
    </createGuestActionInfoBlueprint>
    <destroyGuestActionInfoBlueprint>
        <!-- see destroyGuestActionInfoBlueprint schema -->
    </destroyGuestActionInfoBlueprint>
    <initGuestActionInfoBlueprint>
        <!-- see initGuestActionInfoBlueprint schema -->
    </initGuestActionInfoBlueprint>
    <managementVlan></managementVlan>
    <name></name>
    <nodeBlueprints>
        <nodeBlueprint></nodeBlueprint>
        <nodeBlueprint></nodeBlueprint>
    </nodeBlueprints>
    <virtualGuestBlueprint xsi:type="containerVfwBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <!-- see virtualGuestBlueprint schema -->
    </virtualGuestBlueprint>
</pairBlueprint>

Description: Each pairBlueprint tag specifies how to create a container pair. A container pair is hosted on a particular pod pair, and associates two redundant nodes within the container.

The pairBlueprint tag, with an xsi:type value of containerCommunityFaultHostPairBlueprint, specifies how to create a community fault host type of container pair. A community fault host pair represents two nodes within the container which provide redundancy using community style active-active fault tolerance. Refer to the podCommunityFaultHostPairBlueprint schema for a description of community style active-active fault tolerance.

Children:

TagDescription

addressBlueprints

Consists of zero or more addressBlueprint tags. See addressBlueprint schema.

createGuestActionInfoBlueprint

See createGuestActionInfoBlueprint schema.

destroyGuestActionInfoBlueprint

See destroyGuestActionInfoBlueprint schema.

initGuestActionInfoBlueprint

See initGuestActionInfoBlueprint schema.

managementVlan

Specifies the name of a container level management VLAN. The name specified needs to refer to an AcquiredVlan in the Container. The attribute is optional. If it is unspecified, the assumption is that a pod level management VLAN is used instead.

name

The name value specifies a way to uniquely identify this pair within the container.

nodeBlueprints

Consists of two nodeBlueprint tags. Each nodeBlueprint tag specifies the name of a node blueprint already defined within the container. Both node blueprints must have the same category value. The determination of which pod pair to host the container pair on is made by matching the roles of the container nodes against the nodes in the pod nodes. If there are multiple pod pairs which match, the choice of which one to host the container pair on is made in such a way as to automatically balance the usage of the underlying pod pairs from one container instance to the next, for scalability.

virtualGuestBlueprint

See virtualGuestBlueprint schema with xsi:type="containerVfwBlueprint".

Back to top

pairBlueprint Schema (xsi:type="containerIndividualFaultHostPairBlueprint")

<pairBlueprint xsi:type="containerIndividualFaultHostPairBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addressBlueprints>
        <!-- see addressBlueprint schema -->
    </addressBlueprints>
    <createGuestActionInfoBlueprint>
        <!-- see createGuestAcitonInfoBlueprint -->
    </createGuestActionInfoBlueprint>
    <destroyGuestActionInfoBlueprint>
        <!-- see destroyGuestActionInfoBlueprint -->
    </destroyGuestActionInfoBlueprint>
    <initGuestActionInfoBlueprint>
        <!-- see initGuestActionInfoBlueprint -->
    </initGuestActionInfoBlueprint>
    <name></name>
    <nodeBlueprints>
        <nodeBlueprint></nodeBlueprint>
        <nodeBlueprint></nodeBlueprint>
    </nodeBlueprints>
    <virtualGuestBlueprint xsi:type="containerVlbBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <!-- see virtualGuestBlueprint schema -->
    </virtualGuestBlueprint>
</pairBlueprint>

Description: Each pairBlueprint tag specifies how to create a container pair. A container pair is hosted on a particular pod pair, and associates two redundant nodes within the container.

The pairBlueprint tag, with an xsi:type value of containerIndividualFaultHostPairBlueprint, specifies how to create an individual fault host type of container pair. An individual fault host pair represents two nodes within the container which provide redundancy using individual style active-active fault tolerance. Refer to the podIndividualFaultHostPairBlueprint schema for a description of individual style active-active fault tolerance.

Children:

TagDescription

addressBlueprints

Consists of zero or more addressBlueprint tags. See addressBlueprint schema.

createGuestActionInfoBlueprint

See createGuestActionInfoBlueprint schema.

destroyGuestActionInfoBlueprint

See destroyGuestActionInfoBlueprint schema.

initGuestActionInfoBlueprint

See initGuestActionInfoBlueprint schema.

name

The name value specifies a way to uniquely identify this pair within the container.

nodeBlueprints

The nodeBlueprints tag consists of two nodeBlueprint tags. Each nodeBlueprint tag specifies the name of a node blueprint already defined within the container. Both node blueprints must have the same category value.  The determination of which pod pair to host the container pair on is made by matching the roles of the container nodes against the nodes in the pod nodes. If there are multiple pod pairs which match, the choice of which one to host the container pair on is made in such a way as to automatically balance the usage of the underlying pod pairs from one container instance to the next, for scalability.

virtualGuestBlueprint

See virtualGuestBlueprint schema with xsi:type="containerVlbBlueprint".

Back to top

pairBlueprints Schema

<pairBlueprints>
    <!-- see <pairBlueprint schema --> 
</pairBlueprints>

Description: Each pairBlueprints  tag consists of one or more pairBlueprints tags.

Back to top

poolTypeBlueprint Schema

<poolTypeBlueprint>
    <name></name>
    <description></description>
    <routeDomainIds>
        <routeDomainId></routeDomainId>
    </routeDomainIds>
    <serverVlanName></serverVlanName>
    <servicedNicSegmentsNames>
        <servicedNicSegmentName></servicedNicSegmentName>
    </servicedNicSegments>
    <snatBlockSize></snatBlockSize>
    <snatPoolName></snatPoolName>
    <vipSegmentName></vipSegmentName>
</poolTypeBlueprint>

Description: A given poolTypeBlueprint describes a particular type of load balancer pool that can be created on a VLB.  Different pool types can balance traffic for different NIC segments on the server side, or connect to different VIP segments on the client side.

Children:

TagDescription

name

Each pool type has a name which is unique within the load balancer.

descriptionAn optional field describing the pool type blueprint.

routeDomainIds

To implement multi-tenancy in the F5 load balancer, you need to assign a route domain ID for each LB pool. Each route domain needs a unique VLAN. The integer pool for route domain IDs ranges between 0 - 65534. The value in this tag specifies how to acquire a unique integer and corresponds to the name of the integer blueprint, which is defined in the container blueprint.

You can access route domain IDs in load balancer pool custom actions as runtime parameters, for example, routeDomainID1 value can be accessed as runtime.routeDomainID1 and routeDomainID2 can be accessed as runtime.routeDomainID2.

Note: You cannot import a container blueprint with a route domain ID that does not correspond to an integer blueprint.

serverVlanName

Name of the server side VLAN on which to send out request packets to the NIC segments for whom traffic is being balanced.

servicedNicSegmentNames

Specifies the names of one or more NIC segments which those request packets will be forwarded to in a load balanced manner.

snatBlockSize

An optional tag specifying the size of a block of one or more addresses to acquire from our SNAT address pool. This block will be used by the custom action to add the LB pool (if the underlying device supports it) to configure source NATing for the packets being load balanced. You will attempt to acquire the block as a contiguous set of addresses from IPAM if possible, but if it is not possible, you will acquire a set of discontiguous addresses to represent the block instead.

snatPoolName

An optional tag specifying the name of an address pool to use to acquiring SNAT blocks for use in source NAT translation of packets being load balanced.

vipSegmentName

Specifies the name of a VIP segment, whose address pool will be used to acquire a VIP address for LB  pools created from this type. Incoming client side request packets destined for the VIP address will be delivered to the LB pool via the VIP segment.

Back to top

poolTypeBlueprints Schema

<poolTypeBlueprints>
     <!-- see <poolTypeBlueprint> schema --> 
</poolTypeBlueprints>

Description: Each poolTypeBlueprints tag consists of one or more poolTypeBlueprint tags.

Back to top

portTypeBlueprint Schema

<portTypeBlueprint>
    <description></description>
    <name></name>
    <nameWithinSwitch></nameWithinSwitch>
    <nicSegmentName></nicSegmentName>
</portTypeBlueprint>

Description: Each portTypeBlueprint specifies information about a container level virtual port type (such as port profile or port group) which will be created in the hypervisor switch when this container is configured.  A container level virtual port type is used by a particular container to create virtual ports for NICs of VMs provisioned in that container.

Children:

TagDescription

description

An optional field describing the virtual port type, which will be presented in the UI.

name

Each port type also has a name, unique among container level port types in a given container switch node. This is the name of the port type in the BMC Network Automation model.

nameWithinSwitch

The name of the port type used in the actual switch device is identified by nameWithinSwitch attribute.  The attribute is required. This is the value that will be substituted into the template as the value for a ${container.nodes[My Switch].portTypes[My Port Type]} substitution parameter reference.  In this case "My Port Type" would correspond to our name in the BMC Network Automation model, and the value substituted in would be the name for the actual switch device to use.

The user may specify complicated naming patterns here, including references to any ${pod.}, ${container.}, ${runtime.}, ${eval.} and ${exec.*} parameters. Any illegal characters assigned to this value, as determined by the illegalPortTypeNameCharacters tag in for the device type in question, are automatically stripped out when the nameWithinSwitch value is used.

nicSegmentName

Specifies the name of the NIC segment whose VLAN the virtual ports created from this port type will connect NICs to.

Back to top

portTypeBlueprints Schema

<portTypeBlueprints>
   <!-- see <portTypeBlueprint> schema --> 
</portTypeBlueprints>

Description: Each portTypeBlueprints tag consists of one or more portTypeBlueprint tags.

Back to top

primaryVirtualGuestBlueprint Schema (xsi:type="containerVlbBlueprint")

<primaryVirtualGuestBlueprint xsi:type="containerVlbBlueprint">
  <configureActionInfoBlueprints>
    <!-- see configureActionInfoBlueprint schema -->
  </configureActionInfoBlueprints>
  <unconfigureActionInfoBlueprints>
    <!-- see unconfigureActionInfoBlueprint schema -->
  </unconfigureActionInfoBlueprints>
  <guestAuthenticationBlueprint>
    <!-- see guestAuthenticationBlueprint schema -->
  </guestAuthenticationBlueprint>
  <guestAddressBlueprints>
    <!-- see guestAddressBlueprint schema -->
  </guestAddressBlueprints>
  <operativeFlag></operativeFlag> 
  <guestAddressName></guestAddressName> 
  <guestDeviceName></guestDeviceName> 
  <useExistingGuestDeviceFlag></useExistingGuestDeviceFlag> 
  <guestNodeName></guestNodeName> 
  <sharesVirtualDevice></sharesVirtualDevice> 
  <defaultEnabledFlag></defaultEnabledFlag> 
  <lockedFlag></lockedFlag> 
</primaryVirtualGuestBlueprint>

Description: Enables you to configure the primary guest node when the VLB is operating in HA mode.

Back to top

removeNatActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

<removeNatActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <requiresTunneling></requiresTunneling>
    <description></description>
    <templateGroups>
        <item></item>
    </templateGroups>
</removeNatActionInfoBlueprint>

Description: Specifies how to remove a static address pair entries to a NAT table via a Deploy to Active action. The following runtime parameter references are plugged into the template involved: publicAddress, privateAddress, insideInterfaceName, outsideInterfaceName.

Children:

TagDescription

requiresTunneling

An optional field used to force the file transfer mode be set to Tunneling protocol for a Deploy to Active action. When the value of this flag is set to true or if the value of device type.requiresTunnelingForContainerMerge is set to true, BMC Network Automation uses the Tunneling file transfer mode for the Deploy to Active action. Otherwise, BMC Network Automation uses the file transfer mode specified for the device to perform the Deploy to Active action.

description

An optional field to describe the action, which will be presented in the container viewer.

templateGroups

Specifies one or more item tags, each of which specifies the name of an existing BMC Network Automation template to merge (the term template group is what you call templates inside the BMC Network Automation model, however the term presented in the UI is simply template).  If more than one item is specified, the selection of which to use will alternate from one container instance to the next, balancing their use.

Back to top

 

ruleBlueprint Schema

<ruleBlueprint>
    <defaultEnabledFlag></defaultEnabledFlag>
    <description></description>
    <destinationHostAddress></destinationHostAddress>
    <destinationNetworkAddress></destinationNetworkAddress>
    <destinationNetworkMask></destinationNetworkMask>
    <destinationPortHigh></destinationPortHigh>
    <destinationPortLow></destinationPortLow>
    <destinationPort></destinationPort>
    <hidden></hidden>
    <loggingEnabled></loggingEnabled>
    <locked></locked>
    <permitFlag></permitFlag>
    <sourceHostAddress></sourceHostAddress>
    <sourceNetworkAddress></sourceNetworkAddress>
    <sourceNetworkMask></sourceNetworkMask>
    <transportProtocol></transportProtocol>
</ruleBlueprint>

Description: Defined as a collection within the inboundAclBlueprint or outboundAclBlueprint tag. Specifies the low-level firewall rules with which the ACL would be initialized when a VFW is enabled.

Children:

TagDescription

defaultEnabledFlag

Specifies whether the rule created from this blueprint would be enabled or not. Valid values: true (default), false

description

Specifies an optional field that describes the rule, which will be presented in the container viewer.

destinationHostAddress

Specifies the IP address of the host that you are blocking, specified as either the IP address or a combination of network address and network mask.

destinationNetworkAddress

Specifies the IP address of the destination subnet (range of hosts) that you are blocking, specified as either the IP address or a combination of network address and network mask.

destinationNetworkMask

Specifies the mask of the destination subnet (range of hosts) that you are blocking, specified as either the IP address or a combination of network address and network mask.

destinationPort

Specifies the destination port being blocked.

destinationPortHigh

Specifies the higher value for destination port range being blocked.

destinationPortLow

Specifies the lower value for destination port range being blocked.

hidden

Specifies whether the firewall is hidden. When this tag is set to true, the initial rules created during container provisioning or modification by using the ruleBlueprint schema are hidden from end users and tenant administrators.

loggingEnabled

Indicates whether logging is enabled for the firewall rule created from this blueprint. Set loggingEnabled to true to enable logging.

locked

Specifies whether the firewall rule is locked. When this tag is set to true, the initial rules created during container provisioning or modification by using the ruleBlueprint schema are locked for end users and tenant administrators.

permitFlag

Specifies whether the rule is permitting or denying the specified traffic.

sourceHostAddress

Specifies the address of the source involved when blocking a particular host. Either source host address or combination of source network address and source network mask should be specified.

sourceNetworkAddress

Specifies the address of the source subnet involved when blocking a range of hosts. Either source host address or combination of source network address and source network mask should be specified.

sourceNetworkMask

Specifies the mask of the source subnet involved when blocking a range of hosts. Either source host address or combination of source network address and source network mask should be specified.

transportProtocol

Specifies the transport protocol being blocked.

Back to top

ruleBlueprints Schema

<ruleBlueprints>
    <!-- see <ruleBlueprint> schema --> 
</ruleBlueprints>

Description: Each ruleBlueprints tag consists of one or more ruleBlueprint   tags.

Back to top

secondaryVirtualGuestBlueprint Schema (xsi:type="containerVlbBlueprint")

<secondaryVirtualGuestBlueprint xsi:type="containerVlbBlueprint">
  <configureActionInfoBlueprints>
    <!-- see configureActionInfoBlueprint schema -->
  </configureActionInfoBlueprints>
  <unconfigureActionInfoBlueprints>
    <!-- see unconfigureActionInfoBlueprint schema -->
  </unconfigureActionInfoBlueprints>
  <guestAuthenticationBlueprint>
    <!-- see guestAuthenticationBlueprint schema -->
  </guestAuthenticationBlueprint>
  <guestAddressBlueprints>
    <!-- see guestAddressBlueprint schema -->
  </guestAddressBlueprints>
  <operativeFlag></operativeFlag> 
  <guestAddressName></guestAddressName> 
  <guestDeviceName></guestDeviceName> 
  <useExistingGuestDeviceFlag></useExistingGuestDeviceFlag> 
  <guestNodeName></guestNodeName> 
  <sharesVirtualDevice></sharesVirtualDevice> 
  <defaultEnabledFlag></defaultEnabledFlag> 
  <lockedFlag></lockedFlag> 
</secondaryVirtualGuestBlueprint>

Description: Enables you to configure the secondary guest node when the VLB is operating in HA mode.

Back to top

unconfigureActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint")

<unconfigureActionInfoBlueprint xsi:type="customActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <condition></condition>
    <description></description>
    <guid></guid>
    <name></name>
    <runtimeProps>
        <item>
            <key></key>
            <value></value>
        </item>
    </runtimeProps>
</unconfigureActionInfoBlueprint>

Description: Each unconfigureActionInfoBlueprint tag specifies a particular action to create to unconfigure this node, within the overall job to unconfigure the container. An unconfigureActionInfoBlueprint with xsi:type="customActionInfoBlueprint " is used to represent a custom action to be executed in the job.

Children:

TagDescription

description

An optional field to describe the action, which will be presented in the container viewer.

guid

Identifies which custom action is involved (view the adapter in question in the BMC Network Automation UI to see its GUID value).

name

An optional field to give the action a name. This is used for conditional actions where both the configure action and an associated unconfigure action will both be given the same name, so that BMC Network Automation knows to coordinate the application of the two actions, to guarantee that when the condition no longer applies for the configure action, the unconfigure action will be applied, and vice-versa.

runtimeProps

Contains zero or more runtime properties that can be specified as arguments to pass into the actions. Each runtime property requires a key, which is the name of the property, and a value. The value can include embedded substitution parameter references which will be resolved before the value is passed to the action.

Do not redeclare properties declared in the configureActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint") action. Instead, only declare those properties that are unique to the unconfigureActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint") action or the UnconfigRuntime.fragment files.

The allowed substitution parameter types are the same as would be allowed in a template being merged to the node's device. For instance, you could specify a value of ${container.name}, to pass in the name of the container involved, or you could specify ${runtime.myParam} to pass in a value gathered in the BMC Cloud Lifecycle Management UI from the admin creating the container.

Back to top

unconfigureActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint")

<unconfigureActionInfoBlueprint xsi:type="externalScriptActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <condition></condition>
    <description></description>
    <guid></guid>
    <name></name>
    <runtimeProps>
        <item>
            <key></key>
            <value></value>
        </item>
    </runtimeProps>
</unconfigureActionInfoBlueprint>

Description: Each unconfigureActionInfoBlueprint tag specifies a particular action to create to unconfigure this node, within the overall job to unconfigure the container. An unconfigureActionInfoBlueprint with xsi:type="externalScriptActionInfoBlueprint " is used to represent a custom action to be executed in the job.

Children:

TagDescription

description

An optional field to describe the action, which will be presented in the container viewer.

guid

Identifies which custom action is involved (view the adapter in question in the BMC Network Automation UI to see its GUID value).

name

An optional field to give the action a name. This is used for conditional actions where both the configure action and an associated unconfigure action will both be given the same name, so that BMC Network Automation knows to coordinate the application of the two actions, to guarantee that when the condition no longer applies for the configure action, the unconfigure action will be applied, and vice-versa.

runtimeProps

Contains zero or more runtime properties that can be specified as arguments to pass into the actions. Each runtime property requires a key which is the name of the property, and a value. The value can include embedded substitution parameter references which will be resolved before the value is passed to the action.

Do not redeclare properties declared in the configureActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint") action. Instead, only declare those properties that are unique to the configureActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint") action or the UnconfigRuntime.fragment files. The allowed substitution parameter types are the same as would be allowed in a template being merged to the node's device.

So for instance you could specify a value of ${container.name}, in order to pass in the name of the container involved, or you could specify ${runtime.myParam} in order to pass in a value gathered in the BMC Cloud Lifecycle Management UI from the admin creating the container.

Back to top

unconfigureActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

<unconfigureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <requiresTunneling></requiresTunneling>
    <description></description>
    <name></name>
    <templateGroups>
        <item></item>
    </templateGroups>
</unconfigureActionInfoBlueprint>

Description: Each unconfigureActionInfoBlueprint tag specifies a particular action to create to unconfigure this node, within the overall job to unconfigure the container. An unconfigureActionInfoBlueprint with xsi:type="mergeActionInfoBlueprint " is used to represent a Deploy to Active action to be executed in the job.

Children:

TagDescription

requiresTunneling

An optional field used to force the file transfer mode be set to Tunneling protocol for a Deploy to Active action. When the value of this flag is set to true or if the value of device type.requiresTunnelingForContainerMerge is set to true, BMC Network Automation uses the Tunneling file transfer mode for the Deploy to Active action. Otherwise, BMC Network Automation uses the file transfer mode specified for the device to perform the Deploy to Active action.

description

An optional field to describe the action, which will be presented in the container viewer.

name

An optional field to give the action a name. This is used for conditional actions where both the configure action and an associated unconfigure action will both be given the same name, so that BMC Network Automation knows to coordinate the application of the two actions, to guarantee that when the condition no longer applies for the configure action, the unconfigure action will be applied, and vice-versa.

templateGroups

Specifies one or more item tags, each of which specifies the name of an existing BMC Network Automation template to merge (the term template group is what you call templates inside the BMC Network Automation model, however the term presented in the UI is simply template).  If more than one item is specified, the selection of which to use will alternate from one container instance to the next, balancing their use.

Back to top

unconfigureActionInfoBlueprints Schema

<unconfigureActionInfoBlueprints>
     <!-- see <unconfigureActionInfoBlueprint schema -->
</unconfigureActionInfoBlueprints>

Description: Each unconfigureActionInfoBlueprints tag consists of zero or more unconfigureActionInfoBlueprint tags.

Back to top

vipSegmentBlueprint Schema

<vipSegmentBlueprint>
    <addressPoolName></addressPoolName>
    <description></description>
    <name></name>
    <networkName></networkName>
    <tag></tag>
    <vlanName></vlanName>
</vipSegmentBlueprint>

Description: A VIP network segment specifies an internal network segment that delivers traffic to a VLB. It encapsulates a container level VLAN representing a client side VLAN for the VLB, and a container level address pool which will be used to acquire addresses for the VIPs of LB pools of a particular type that have been added to the VLB.

Children:

TagDescription

addressPoolName

The address pool name is specifies the address pool which will be used to acquire VIP addresses for LB pools in the VLB.

description

An optional field describing the VIP segment, which will be presented in the UI.

name

The name is unique within the container.

networkName

The name of the BMC Cloud Lifecycle Management "network" this segment belongs to.  A BMC Cloud Lifecycle Management network almost corresponds exactly to BMC Network Automation's notion of a network segment, but not quite. The BMC Cloud Lifecycle Management imposes the constraint that its networks must each encapsulate a different address pool. BMC Network Automation does not impose this constraint on its network segments (for example, you could have a VLB in one-arm mode where the VIP segment and NIC segment involved both encapsulate the same VLAN and address pool). Another difference is that BMC Cloud Lifecycle Management networks only need to be named uniquely within a given scope (for example, within a given zone), whereas BMC Network Automation network segments must be uniquely named across the entire container.

tag

A tag is an opaque value that can be used to annotate the container in miscellaneous ways which clients might find useful. The PCM engine in BMC Network Automation makes no use of this value.  It is an optional field.

In the case of the BMC Cloud Lifecycle Management client, they use this to specify one or more hints to be used when they need to select a particular network segment in the container (for example, during server provisioning). The container blueprint defines the default hints, which are propagated to the container instance created from it.  The BMC Cloud Lifecycle Management admin is free to override them with non-default values in the version of the container instance stored in the cloud DB subsequently.

For example, you might specify a tag with the value "Purpose[WEB],Quality[HI,LOW]" to indicate that a server being provisioned which was tagged with "Purpose[WEB]" and either "Quality[HI]" or "Quality[LOW]" could be provisioned to this segment by default.

vlanName

The VLAN name is the name of the client side VLAN for the VLB which this VIP segment encapsulates.

Back to top

vipSegmentBlueprints Schema

<vipSegmentBlueprints>
    <!-- see <vipSegmentBlueprint> schema -->
</vipSegmentBlueprints>

Description: Each vipSegmentBlueprints tag consists of zero or more vipSegmentBlueprint tags.

Back to top

virtualGuestBlueprint Schema (Vanilla)

<virtualGuestBlueprint>
    <configureActionInfoBlueprints>
        <!-- see configureActionInfoBlueprint schema -->
    </configureActionInfoBlueprints>
    <guestAddressName></guestAddressName>
    <guestAddressBlueprints>
        <!-- see guestAddressBlueprint schema -->
    </guestAddressBlueprints>
    <guestAuthenticationBlueprint>
        <!-- see guestAuthenticationBlueprint schema -->
    </guestAuthenticationBlueprint>
    <guestDeviceName></guestDeviceName>
    <defaultEnabledFlag></defaultEnabledFlag>
    <guestDeviceTypeGuid></guestDeviceTypeGuid> 
    <guestNodeName></guestNodeName>
    <guestNodeRole></guestNodeRole>
    <lockedFlag></lockedFlag>  
    <operativeFlag></operativeFlag>
    <useHostAddressForGuest></useHostAddressForGuest>
    <useExistingGuestDeviceFlag></useExistingGuestDeviceFlag>
    <natTypeBlueprint>
        <!-- see above -->
    </natTypeBlueprint>
    <sharesVirtualDevice></sharesVirtualDevice>
    <unconfigureActionInfoBlueprints>
        <!-- see unconfigureActionInfoBlueprint schema -->
    </unconfigureActionInfoBlueprints>
</virtualGuestBlueprint>

Description: Represents the attributes of a vanilla guest node to be created by BMC Network Automation. The element should be specified within a parent nodeBlueprint (xsi:type="containerHostBlueprint").

Children:

TagDescription

configureActionInfoBlueprints

Contains zero or more configureActionInfoBlueprint tags. See configureActionInfoBlueprint schema.

guestAddressName

The guestAddressName specifies the name of the entry in the guestAddressBlueprints schema to use as the IP addres of the virtual guest, which BMC Network Automation will use to connect to it when administering the guest device.

Note: If the guest device is being managed via a pod level VLAN, then the guestAddressBlueprint referenced here must be of type  xsi:type="communityAddressBlueprint". In this case, the pod level VLAN used will alternate from one container instance to the next, and so the pod level address pool from which to acquire the guest address will need to vary from one container instance to the next as well.

guestAddressBlueprints

Contains one or more guestAddressBlueprint tags. See guestAddressBlueprint schema.

guestAuthenticationBlueprint

See guestAuthenticationBlueprint schema.

guestDeviceName

Specifies the name of the BMC Network Automation device to create or reuse to represent the guest context. The tag supports references to ${pod.}, ${container.}, ${runtime.}, ${eval.}, and ${exec.*} substitution parameters.

Note: If the container name contains special characters such as period (.) or underscore (_), in the guest device name, these characters are replaced by a hyphen (-).

defaultEnabledFlag

Specifies whether the virtual guest node created from this blueprint would be enabled.

guestDeviceTypeGuid

(Optional) Specifies the GUID that is used to identify the device type of a guest node.

guestNodeName

Specifies the name of the virtual guest node in container which will be created.  Must be unique among container node names. Note that for pre-8.2 blueprints, these names will have been prefixed with the name of the zone (separated with a ".") that originally encapsulated the node, when upgraded to 8.2 and later versions.

guestNodeRole

(Optional) Specifies the role value to assign to the guest node created from this blueprint. If you do not specify this tag, the guestNodeName value is assigned to the role value.

This attribute is only required for legacy 8.1 blueprints, which are upgraded, where the guestNodeName is prefixed with the name of the zone, which originally encapsulated the node during the upgrade. In such cases, the role value must not have this prefix so that templates from the original blueprint can continue to work because ${container.nodes[<role-name>].*} parameters in those templates assume an unprefixed role name.

lockedFlagSpecifies whether the virtual firewall created from this blueprint is locked or not.  Being locked means that it cannot be toggled (enabled/disabled) from the BMC Cloud Lifecycle Management.
operativeFlag

Specifies whether content update actions are performed through the virtual guest node.

Set this flag to false for the primaryVirtualGuestNode and secondaryVirtualGuestNode.

Default: true

useHostAddressForGuest

Specifies whether a guest is created using the IP address of the host device.

If this flag is set to false, a new IP address is acquired for the device.

useExistingGuestDeviceFlag

Indicates whether to create a new guest device or reuse an existing one when the node is enabled.

natTypeBlueprint

See natTypeBlueprint schema. This is an optional tag.

sharesVirtualDevice

Used in pre-8.2 containers where guests in different zones are sharing the same underlying host.

unconfigureActionInfoBlueprints

Contains zero or more unconfigureActionInfoBlueprint tags. See unconfigureActionInfoBlueprint schema.

Back to top

virtualGuestBlueprint Schema (xsi:type="containerVfwBlueprint")

<virtualGuestBlueprint xsi:type="containerVfwBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <configureActionInfoBlueprints>
        <!-- see configureActionInfoBlueprint schema -->
    </configureActionInfoBlueprints>
    <guestAddressName></guestAddressName>
    <guestAddressBlueprints>
        <!-- see guestAddressBlueprint schema -->
    </guestAddressBlueprints>
    <guestAuthenticationBlueprint>
        <!-- see guestAuthenticationBlueprint schema -->
    </guestAuthenticationBlueprint>
    <guestDeviceName></guestDeviceName>
    <defaultEnabledFlag></defaultEnabledFlag>
    <guestDeviceTypeGuid></guestDeviceTypeGuid> 
    <vfwSubClassName></vfwSubClassName> 
    <guestNodeName></guestNodeName>
    <guestNodeRole></guestNodeRole>
    <independentFlag></independentFlag>
    <lockedFlag></lockedFlag>  
    <operativeFlag></operativeFlag>
    <useHostAddressForGuest></useHostAddressForGuest>
    <useExistingGuestDeviceFlag></useExistingGuestDeviceFlag>
    <managedInterfaceBlueprints>
        <!-- see managedInterfaceBlueprint schema -->
    </managedInterfaceBlueprints>
    <natTypeBlueprint>
        <!-- see above -->
    </natTypeBlueprint>
    <ruleUpdateGuid></ruleUpdateGuid>
    <sharesVirtualDevice></sharesVirtualDevice>
    <accessLayerFlag></accessLayerFlag> 
    <unconfigureActionInfoBlueprints>
        <!-- see unconfigureActionInfoBlueprint schema -->
    </unconfigureActionInfoBlueprints>
</virtualGuestBlueprint>

Description: Represents the attributes of VFW guest node to be created by BMC Network Automation. The element should be specified within a parent pairBlueprint ( xsi:type="containerCommunityFaultHostPairBlueprint ") if the host involved is part of an active-active fault tolerant pair, otherwise it should be specified within a parent nodeBlueprint ( xsi:type="containerFirewallHostBlueprint ").

Children:

TagDescription

configureActionInfoBlueprints

Contains zero or more configureActionInfoBlueprint tags. See configureActionInfoBlueprint schema.

guestAddressName

The guestAddressName specifies the name of the entry in the guestAddressBlueprints to use as the VFW's virtual management IP address, which BMC Network Automation will use to connect to it when administering the VFW.

Note that if the VFW is being managed via a pod level VLAN, then the guestAddressBlueprint referenced here must be of type  xsi:type="communityAddressBlueprint", since in that case the pod level VLAN used will alternate from one container instance to the next, and so the pod level address pool from which to acquire the guest address will need to vary from one container instance to the next as well.

guestAddressBlueprints

Contains one or more guestAddressBlueprint tags. See guestAddressBlueprint schema.

guestAuthenticationBlueprint

See guestAuthenticationBlueprint schema.

guestDeviceName

Specifies the name of the BMC Network Automation device to create or reuse to represent the guest context. The tag supports references to ${pod.}, ${container.}, ${runtime.}, ${eval.}, and ${exec.*} substitution parameters.

Note: If the container name contains special characters such as period (.) or underscore (_), in the guest device name, these characters are replaced by a hyphen (-).

defaultEnabledFlag

Specifies whether the virtual firewall created from this blueprint would be enabled.

You can specify a value for this flag only when independentFlag is true.

vfwSubClassName

Specifies the fully qualified name of the virtual firewall (VFW) class to use instead of the default class specified in the DeviceTypeMap.xml file.

For example:

  • For ASA 1000V, this tag is required because com.bmc.bcan.engine.network.pcm.ContainerVfwAsaFwsmPix, the default VFW class name for Device Type Cisco ASA/PIX/FWSM, is overridden in the container blueprint by com.bmc.bcan.engine.network.pcm.ContainerVfwAsa1000v.
  • For CSR 1000V, the value of this tag must be com.bmc.bcan.engine.network.pcm.ContainerVfwIos.

guestDeviceTypeGuid

(Optional) Specifies the GUID that is used to identify the device type of a guest node. This tag is used to identify the VFW class name of the guest node when there is ambiguity in differentiating it from the host node device type.

For example:

  • When the host node device type is VNMC, which could have either a Virtual Security Gateway (VSG) or an ASA 1000V guest device hosted on it, this tag would contain the device type GUID of Nexus for a VSG, and the device type GUID of Cisco ASA/PIX/FWSM for an ASA 1000V node.
  • For CSR 1000V guest node, there is no associated host node, and therefore you need to explicitly specify the guestDeviceTypeGuid as the device type of the Cisco IOS Switch/Router.

guestNodeName

Specifies the name of the VFW node in container which will be created.  Must be unique among container node names. Note that for pre-8.2 blueprints, these names will have been prefixed with the name of the zone (separated with a ".") that originally encapsulated the node, when upgraded to 8.2+.

guestNodeRole

(Optional) Specifies the role value to assign to the guest node created from this blueprint. If you do not specify this tag, the guestNodeName value is assigned to the role value.

This attribute is only required for legacy 8.1 blueprints, which are upgraded, where the guestNodeName is prefixed with the name of the zone, which originally encapsulated the node during the upgrade. In such cases, the role value must not have this prefix so that templates from the original blueprint can continue to work because ${container.nodes[<role-name>].*} parameters in those templates assume an unprefixed role name.

independentFlag

Specifies whether the VFW is independent or not. An independent VFW can be toggled directly.

lockedFlagSpecifies whether the virtual firewall created from this blueprint is locked or not.  Being locked means that it cannot be toggled (enabled/disabled) from the BMC Cloud Lifecycle Management.
operativeFlag

Specifies whether content update actions such as a firewall rule or a load balancer pool are performed through the virtual guest node

Set this flag to false for the primaryVirtualGuestNode and secondaryVirtualGuestNode.

Default: true

useHostAddressForGuest

Specifies whether a guest is created using the IP address of the host device.

If this flag is set to false, a new IP address is acquired for the device.

useExistingGuestDeviceFlag

Indicates whether to create a new guest device or reuse an existing one when the node is enabled.

managedInterfaceBlueprints

Contains one or more managedInterfaceBlueprint tags. See managedInterfaceBlueprint schema.

natTypeBlueprint

See natTypeBlueprint schema. This is an optional tag.

ruleUpdateGuid

Used purely for updating rules in checkpoint devices.  It should be NULL if the underlying firewall device is a non-checkpoint device. The GUID should correspond to an existing external script action adapter in BMC Network Automation.

sharesVirtualDevice

Used in pre-8.2 containers where guests in different zones are sharing the same underlying host.

accessLayerFlag  Specifies whether the firewall is deployed on the hypervisor layer and is transparent. Access layer firewalls are interface-independent with no physical interface defined.

unconfigureActionInfoBlueprints

Contains zero or more unconfigureActionInfoBlueprint tags. See unconfigureActionInfoBlueprint schema.

Back to top

virtualGuestBlueprint Schema (xsi:type="containerVlbBlueprint")

<virtualGuestBlueprint xsi:type="containerVlbBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <addEntryGuid></addEntryGuid>
    <addPoolGuid></addPoolGuid>
    <configureActionInfoBlueprints>
        <!-- see configureActionInfoBlueprint schema -->
    </configureActionInfoBlueprints>
    <defaultEnabledFlag></defaultEnabledFlag>
    <disableEntryGuid></disableEntryGuid>
    <enableEntryGuid></enableEntryGuid>
    <guestAddressName></guestAddressName>
    <guestAddressBlueprints>
        <!-- see guestAddressBlueprint schema -->
    </guestAddressBlueprints>
    <guestAuthenticationBlueprint>
        <!-- see guestAuthenticationBlueprint schema -->
    </guestAuthenticationBlueprint>
    <guestClientVlanName></guestClientVlanName>
    <guestDeviceName></guestDeviceName>
    <guestNodeName></guestNodeName>
    <guestNodeRole></guestNodeRole>
    <lockedFlag></lockedFlag>
    <operativeFlag></operativeFlag> 
    <poolTypeBlueprints>
        <!-- see poolTypeBlueprint schema -->
    </poolTypeBlueprints>
    <removeEntryGuid></removeEntryGuid>
    <removePoolGuid></removePoolGuid>
    <sharesVirtualDevice></sharesVirtualDevice>
    <unconfigureActionInfoBlueprints>
        <!-- see unconfigureActionInfoBlueprint schema -->
    </unconfigureActionInfoBlueprints>
    <useExistingGuestDeviceFlag></useExistingGuestDeviceFlag>
</virtualGuestBlueprint>

 

Description: Represents the attributes of VLB guest node to be created by BMC Network Automation. The element should be specified within a parent pairBlueprint ( xsi:type="containerIndividualFaultHostPairBlueprint ") if the host involved is part of an active-active fault tolerant pair, otherwise it should be specified within a parent nodeBlueprint ( xsi:type="containerLoadBalancerHostBlueprint ").

Children:

TagDescription

addEntryGuid

(Optional) Can be used to specify the GUID of a non-default custom action to use when adding a server entry to a load balancer pool within the VLB (view the adapter in question in the BMC Network Automation UI to see its GUID value). If not specified, the default custom action is used.

addPoolGuid

(Optional) Can be used to specify the GUID of a non-default custom action to use when adding a new load balancer pool to the VLB (view the adapter in question in the BMC Network Automation UI to see its GUID value). If not specified, the default custom action is used.

configureActionInfoBlueprints

Contains zero or more configureActionInfoBlueprint tags. See configureActionInfoBlueprint schema.

defaultEnabledFlag

Specifies whether the virtual load balancer created from this blueprint would be enabled or not.

When a VLB is enabled, the load balancer pool types within it which are serving enabled NIC segments are enabled. When a VLB is disabled, the load balancer pool types within it are disabled.  When a load balancer pool type is enabled, the vip segment associated with it is enabled as a side effect. When a load balancer pool type is disabled, the vip segment associated with it is only disabled if there are no other enabled load balancer pool type associated with it.

disableEntryGuid

(Optional) Specifies the GUID of a non-default custom action to use when disabling a server entry in a load balancer pool within the VLB (view the adapter in question in the BMC Network Automation UI to see its GUID value).

enableEntryGuid

(Optional) Specifies the GUID of a non-default custom action to use when enabling a server entry in a load balancer pool within the VLB (view the adapter in question in the BMC Network Automation UI to see its GUID value).

guestAddressName

The guestAddressName tag specifies the name of the entry in the guestAddressBlueprints to use as the VFW's virtual management IP address, which BMC Network Automation will use to connect to it when administering the VFW.

guestAddressBlueprints

Contains one or more guestAddressBlueprint tags. See guestAddressBlueprint schema.

guestAuthenticationBlueprint

See guestAuthenticationBlueprint schema.

guestClientVlanName

The guestClientVlanName tag specifies the client side (northbound) VLAN name to which the guest device will be connected.

guestDeviceName

The guestDeviceName tag specifies the name of the BMC Network Automation device to create or reuse to represent the guest context. The tag supports references to ${pod.}, ${container.}, ${runtime.}, ${eval.}, and ${exec.} substitution parameters.

Note: If the container name contains special characters such as period (.) or underscore (_), in the guest device name, these characters are replaced by a hyphen (-).

guestNodeName

The guestNodeName specifies name of the VFW node in container which will be created.  Must be unique among container node names. Note that for pre-8.2 blueprints, these names will have been prefixed with the name of the zone (separated with a ".") that originally encapsulated the node, when upgraded to 8.2+.

guestNodeRole

(Optional) Specifies the role value to assign to the guest node created from this blueprint. If you do not specify this tag, the guestNodeName value is assigned to the role value.

This attribute is only required for legacy 8.1 blueprints, which are upgraded, where the guestNodeName is prefixed with the name of the zone, which originally encapsulated the node during the upgrade. In such cases, the role value must not have this prefix so that templates from the original blueprint can continue to work because ${container.nodes[<role-name>].*} parameters in those templates assume an unprefixed role name.

lockedFlag

The lockedFlag specifies whether the virtual load balancer created from this blueprint is locked or not.  Being locked means that it cannot be toggled (enabled/disabled) from the BMC Cloud Lifecycle Management.

operativeFlag

Specifies whether content update actions such as a firewall rule or a load balancer pool are performed through the virtual guest node

Set this flag to false for the primaryVirtualGuestNode and secondaryVirtualGuestNode.

Default: true

poolTypeBlueprints

Contains one or more poolTypeBlueprint tags. See poolTypeBlueprint schema.

removeEntryGuid

The removeEntryGuid tag optionally specifies the GUID of a non-default custom action to use when removing a server entry from a load balancer pool within the VLB (view the adapter in question in the BMC Network Automation UI to see its GUID value). If not specified then the default custom action will be used.

removePoolGuid

The removePoolGuid tag optionally specifies the GUID of a non-default custom action to use when removing a load balancer pool from the VLB (view the adapter in question in the BMC Network Automation UI to see its GUID value). If not specified then the default custom action will be used.

sharesVirtualDevice

This tag is only used in pre-8.2 containers where guests in different zones are sharing the same underlying host.

unconfigureActionInfoBlueprint

Contains zero or more unconfigureActionInfoBlueprint tags. See unconfigureActionInfoBlueprint schema.

useExistingGuestDeviceFlagIndicates whether to create a new guest device or reuse an existing one when the node is enabled.

Back to top

vlanBlueprint Schema

<vlanBlueprint>
    <condition></condition>
    <vlanName></vlanName>
    <vlanPoolName></vlanPoolName>
</vlanBlueprint>

Description: Each vlanBlueprint tag specifies how to acquire a container level VLAN from a VLAN pool in the pod on which the container is being created. Container level VLANs can be referenced as substitution parameters in the templates used to configure containers (for example, "${container.vlans[My Container Level VLAN]}".

Children:

TagDescription

condition

Defines the condition under which the VLAN should be acquired from its pool, as a Boolean expression of component states.  Refer to the dynamic container documentation for syntax details for these expressions.  If no condition is specified, the address will be acquired as soon as the address pool involved is acquired.

For example, if you want to declare that a VLAN should only be acquired when the container level NIC segment named "NIC 1" is enabled, you could specify the condition to be "-EXISTS- container.nicSegments['NIC 1']".

vlanName

The name value specifies a way to uniquely identify this VLAN among all container level VLANs.

vlanPoolName

The vlanPoolName tag specifies which VLAN pool in the pod to acquire this vlan from.

  Back to top

vlanBlueprints Schema

<vlanBlueprints>
     <!-- see <vlanBlueprint> schema -->
</vlanBlueprints>

Description: Each vlanBlueprints tag consists of zero or more vlanBlueprint tags.

Back to top

vrfIdBlueprint Schema

<vrfIdBlueprint>
    <id></id>
    <name></name>
</vrfIdBlueprint>

Description: The vrfIdBlueprints tag consists of zero or more vrfIdBlueprint tags. Each vrfIdBlueprint tag specifies how to acquire a container level vrf id. Container level vrf ids can be referenced as substitution parameters in the templates used to configure containers (for example, "${container.vrfIds[VRF_TO_MPLS]}").

Children:

TagDescription

id

Specifies the value that can be used to configure a VRF in one of the devices in this container.  The value can have pod, container, and runtime substitution parameter references within it.

name

Specifies a unique name to identify this VRF ID.

Back to top

vrfIdBlueprints Schema

<vrfIdBlueprints>
    <!-- see <vrfldBlueprint> schema -->
</vrfIdBlueprint>

Description: Each vrfIdBlueprints tag consists of zero or more vrfIdBlueprint tags.

Back to top

version Schema

<version>
    <maint></maint>
    <major></major>
    <minor></minor>
</version>

Description: The version tag specifies the BMC Network Automation version which this ContainerBlueprint was created for.

Children:

TagDescription

maint

Maintenance number portion of the BMC Network Automation build version.

major

Major number portion of the BMC Network Automation build version.

minor

Minor number portion of the BMC Network Automation build version.

Back to top

zoneBlueprint Schema

<zoneBlueprint>
    <description></description>
    <name></name>
    <nicSegmentBlueprints>
        <!-- see nicSegmentBlueprint schema -->
    </nicSegmentBlueprints>
    <type></type>
    <vipSegmentBlueprints>
        <!-- see vipSegmentBlueprint schema -->
    </vipSegmentBlueprints>
</zoneBlueprint>

Description: Each zoneBlueprint tag specifies how to create a zone.  A zone provides a convenient way to group together internal (NIC/VIP) segments whose traffic is limited to one particular region within the container, typically so that they can all be protected using a common security policy at the VFW interface which serves them.

Children:

TagDescription

description

The description tag is optional, and will be presented as a reminder to the user of the details of the zone when viewing it later in the container viewer.

name

The name value specifies a way to uniquely identify this zone within the container.

nicSegmentBlueprints

Contains zero or more nicSegmentBlueprint tags. See nicSegmentBlueprint schema.

type

The type tag is optional, and will be presented as a reminder to the user of the type of zone this blueprint creates when viewing its value later in the container viewer.

vipSegmentBlueprints

Contains zero or more vipSegmentBlueprint tags. See vipSegmentBlueprint schema.

zoneBlueprints Schema

<zoneBlueprints>
     <!-- see <zoneBlueprint> schema -->
</zoneBlueprints>

Description: Each zoneBlueprints tag consists of zero or more zoneBlueprint tags.

Back to top

Runtime parameters

Runtime parameters support default values in container blueprints. For instance, if you have a particular tag or template in a container blueprint with a reference runtime parameter, you can specify the default value as ${runtime.foo:bar}. The cloud administrator provisioning or modifying a container from the blueprint can optionally specify a value for the "foo" runtime parameter. If you do not specify a value, BMC Network Automation uses "bar" as the default value.

If you specify multiple comma-separated values, for example, ${runtime.foo:bar1,bar2}, in the BMC Cloud Lifecycle Management GUI, you can select a value from the list. However, if you do not specify a value, BMC Network Automation ignores the trailing “,bar2”, and interprets it as ${runtime.foo:bar1}, implying that it considers "bar1" as the default value.

Back to top

 

Was this page helpful? Yes No Submitting... Thank you

Comments