Container blueprint XML reference

This section describes the network container blueprint XML file tags.

addressBlueprint Schema

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
addressName	Specifies 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).
addressPoolName	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 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'\]".
gatewayFlag	Indicates 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

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

addressPoolBlueprint Schema

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
addressSpaceBlueprintName	Specifies name of the address space in the container which this pool should be acquired from. It should not be specified if rangeBlueprintName is specified.
condition	Defines 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.
linkId	Specifies 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.
name	specifies 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.
rangeBlueprintName	Specifies 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.

Tag	Description
allowOverride	Specifies 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'\]".
defaultNetworkAddress	Specifies 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.
defaultNetworkMask	Specifies 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.
description	Specifies the description to be presented in the UI for the address space. It is a required value.
name	Specifies a way to uniquely identify this address space within the container.

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

Tag	Description
containerBlueprint	See containerBlueprint schema.
version	See version schema.

Tag	Description
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.
linkId	Specifies a unique identifier for chained action info blueprints, which can be chained by using the same name. For configure action info blueprints, you can initialize linkId with 0. Note that only unconfigure, destroy guest, and remove nat action info blueprints can be chained. If you try to chain configure, create guest and create nat action info blueprints, BMC Network Automation generates an error during import.

Tag	Description
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.
linkId	Specifies a unique identifier for chained action info blueprints, which can be chained by using the same name. For configure action info blueprints, you can initialize linkId with 0. Note that only unconfigure, destroy guest, and remove nat action info blueprints can be chained. If you try to chain configure, create guest and create nat action info blueprints, BMC Network Automation generates an error during import.
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.

Tag	Description
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. The name can include only alphanumeric characters. It cannot include symbols or special characters such as a single quote (') or dollar sign ($).
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.
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.

Tag	Description
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.
linkId	Specifies a unique identifier for chained action info blueprints, which can be chained by using the same name. For configure action info blueprints, you can initialize linkId with 0. Note that only unconfigure, destroy guest, and remove nat action info blueprints can be chained. If you try to chain configure, create guest and create nat action info blueprints, BMC Network Automation generates an error during import.

Tag	Description
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.
linkId	Specifies a unique identifier for chained action info blueprints, which can be chained by using the same name. For configure action info blueprints, you can initialize linkId with 0. Note that only unconfigure, destroy guest, and remove nat action info blueprints can be chained. If you try to chain configure, create guest and create nat action info blueprints, BMC Network Automation generates an error during import.

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

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

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

Tag	Description
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. You can choose to encrypt this password by setting the encryptedFlag element to true. If you do not set its value or set its value to false, password that you provide in the value element is passed as clear text. If you set the value to true and provide an encrypted password in the value element, password is passed as an encrypted value. For instructions on encrypting the password, see Running-the-Maintenance-and-Cleanup-tools. Note: If you have exported any container blueprint in versions earlier than 8.7.00 and importing it in version 8.700, add the encryptFlag and value elements to guestLoginPassword before importing.
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. You can choose to encrypt this password by setting the encryptedFlag element to true. If you do not set its value or set its value to false, password that you provide in the value element is passed as clear text. If you set the value to true and provide an encrypted password in the value element, password is passed as an encrypted value. For instructions on encrypting the password, see Running-the-Maintenance-and-Cleanup-tools. Note: If you have exported any container blueprint in versions earlier than 8.7.00 and importing it in version 8.700, add the encryptFlag and value elements to guestPrivilegedPassword before importing.

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

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

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

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

Tag	Description
addressTranslatorBlueprints	Contains one or more addressTranslatorBlueprint. See addressTranslatorBlueprint schema.
createNatActionInfoBlueprint	See createNatActionInfoBlueprint schema.
removeNatActionInfoBlueprint	See removeNatActionInfoBlueprint schema.
natRuleBlueprints	See natRuleBlueprints schema.

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

Tag	Description
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).

Tag	Description
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. This field is optional if the VLAN is being managed by an external entity, and not by the BMC Network Automation pod. For example, in case of a new Software Defined Networking (SDN) container, you can omit this field.

Container blueprint XML reference

addressBlueprint Schema

addressBlueprints Schema

addressPoolBlueprint Schema

addressPoolBlueprints Schema

addressSpaceBlueprint Schema (xsi:type="infrastructureAddressSpaceBlueprint")

addressSpaceBlueprint Schema (xsi:type="provisioningAddressSpaceBlueprint")

addressSpaceBlueprints Schema

addressTranslatorBlueprint Schema

addressTranslatorBlueprints Schema

bbnaData Schema

configureActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint")

configureActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint")

configureActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

configureActionInfoBlueprints Schema

containerBlueprint Schema

createGuestActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint")

createGuestActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint")

createGuestActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

createGuestActionInfoBlueprints Schema

createNatActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

destroyGuestActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint")

destroyGuestActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint")

destroyGuestActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

destroyGuestActionInfoBlueprints Schema

externalNetworkSegmentBlueprint Schema

externalNetworkSegmentBlueprints Schema

guestAddressBlueprint Schema (xsi:type="addressBlueprint")

guestAddressBlueprint Schema (xsi:type="communityAddressBlueprint")

guestAddressBlueprints Schema

guestAuthenticationBlueprint Schema

inboundAclBlueprint schema

initGuestActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint")

initGuestActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint")

initGuestActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

integerBlueprint Schema

integerBlueprints Schema

managedInterfaceBlueprint Schema

managedInterfaceBlueprints Schema

natTypeBlueprint Schema

natRuleBlueprint Schema

natRuleBlueprints Schema

networkPathBlueprint Schema

networkPathBlueprints Schema

nicSegmentBlueprint Schema

nicSegmentBlueprints Schema

nodeBlueprint Schema (default xsi:type)

nodeBlueprint Schema (xsi:type="containerFirewallHostBlueprint")

nodeBlueprint Schema (xsi:type="containerHostBlueprint")

nodeBlueprint Schema (xsi:type="containerHypervisorSwitchBlueprint")

nodeBlueprint Schema (xsi:type="containerLoadBalancerHostBlueprint")

nodeBlueprint Schema (xsi:type="containerPhysicalSwitchBlueprint")

nodeBlueprints Schema

outboundAclBlueprint schema

pairBlueprint Schema (default xsi:type)

pairBlueprint Schema (xsi:type="containerCommunityFaultHostPairBlueprint")

pairBlueprint Schema (xsi:type="containerIndividualFaultHostPairBlueprint")

pairBlueprints Schema

poolTypeBlueprint Schema

poolTypeBlueprints Schema

portTypeBlueprint Schema

portTypeBlueprints Schema

primaryVirtualGuestBlueprint Schema (xsi:type="containerVlbBlueprint")

removeNatActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

ruleBlueprint Schema

ruleBlueprints Schema

secondaryVirtualGuestBlueprint Schema (xsi:type="containerVlbBlueprint")

unconfigureActionInfoBlueprint Schema (xsi:type="customActionInfoBlueprint")

unconfigureActionInfoBlueprint Schema (xsi:type="externalScriptActionInfoBlueprint")

unconfigureActionInfoBlueprint Schema (xsi:type="mergeActionInfoBlueprint")

unconfigureActionInfoBlueprints Schema

vipSegmentBlueprint Schema

vipSegmentBlueprints Schema

virtualGuestBlueprint Schema (Vanilla)

virtualGuestBlueprint Schema (xsi:type="containerVfwBlueprint")

virtualGuestBlueprint Schema (xsi:type="containerVlbBlueprint")

vlanBlueprint Schema

vlanBlueprints Schema

vrfIdBlueprint Schema

vrfIdBlueprints Schema

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

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

Tag	Description
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".

Tag	Description
name	Each pool type has a name which is unique within the load balancer.
description	An 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.

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

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

Tag	Description
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. This field is optional if the VLAN is being managed by an external entity, and not by the BMC Network Automation pod. For example, in case of a new Software Defined Networking (SDN) container, you can omit this field.

Tag	Description
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.
lockedFlag	Specifies 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.

Tag	Description
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.
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.
useExistingGuestDeviceFlag	Indicates whether to create a new guest device or reuse an existing one when the node is enabled.

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