As you create or edit your vRealize Automation cloud templates, use the most appropriate network resources for your objectives. Learn about the NSX and cloud-agnostic network options that are available in the cloud template.
Select one of the available network resource types based on machine and related conditions in your vRealize Automation cloud template.
Cloud agnostic network resource
Cloud.Network resource type. The default resource displays as:
Cloud_Network_1:
type: Cloud.Network
properties:
networkType: existing
Use a cloud agnostic network when you want to specify networking characteristics for a target machine type that is not, or might not, be connected to an NSX network.
- Cloud agnostic machine
- vSphere
- Google Cloud Platform (GCP)
- Amazon Web Services (AWS)
- Microsoft Azure
- VMware Cloud on AWS (VMC)
networkType) settings:
- public
- private
- outbound
- existing
vSphere network resource
Cloud.vSphere.Network resource type. The default resource displays as:
Cloud_vSphere_Network_1:
type: Cloud.vSphere.Network
properties:
networkType: existing
Use a vSphere network when you want to specify networking characteristics for a vSphere machine type (Cloud.vSphere.Machine).
The vSphere network resource is only available for a Cloud.vSphere.Machine machine type.
networkType) settings:
- public
- private
- existing
For examples, see Using network settings in network profiles and cloud templates in vRealize Automation.
NSX network resource
Cloud.NSX.Network resource type. The default resource displays as:
Cloud_NSX_Network_1:
type: Cloud.NSX.Network
properties:
networkType: existing
Use an NSX network when you want to attach a network resource to one or more machines that have been associated to an NSX cloud account. The NSX network resource allows you to specify NSX networking characteristics for a vSphere machine resource that is associated to an NSX cloud account.
Cloud.NSX.Network resource is available for these network type (
networkType) settings:
- public
- private
- outbound
- existing
- routed - Routed networks are only available for NSX-V and NSX-T.
If you want multiple outbound or routed networks to share the same NSX-T Tier-1 router or NSX-V Edge Service Gateway (ESG), connect a single NSX gateway resource (Cloud.NSX.Gateway) to the connected networks in the template prior to initial deployment. If you add the gateway after deployment as a day 2 or iterative development operation, each network creates its own router.
You can use the NSX NAT resource in the template to support NAT and DNAT port forwarding rules.
Machine tags are defined in the cloud template and apply to the machine resource if it is deployed on vCenter. Machine tags are also applied to the NSX-T network if the machine resource is connected to an NSX-T network, including an NSX-T global network. NSX-T global networks are networks that are defined by the NSX-T global manager and apply to one or more NSX-T local managers. Note that machine tagging is different than machine NIC (network interface) tagging.
Cloud agnostic network resource with Azure, AWS, or GCP deployment intent
Public cloud provider VMs can require specific cloud template property combinations that are not necessarily required in NSX or vSphere-based machine deployments. For examples of cloud template code that support some of these scenarios, see Networks, security resources, and load balancers in vRealize Automation.
NSX gateway resource
You can reuse or share a single NSX-T Tier-1 router or NSX-V Edge Service Gateway (ESG) within a single deployment by using a gateway resource (Cloud.NSX.Gateway) in the cloud template. The gateway resource represents the Tier-1 or ESG and can be connected to multiple networks in the deployment. The gateway resource can be used with outbound or routed networks only.
The Cloud.NSX.Gateway resource allows you to share the NSX-T Tier-1 router or NSX-V Edge Service Gateway (ESG) among connected outbound or routed networks in a deployment.
The gateway is often attached to a single outbound or routed network. However, if the gateway is attached to multiple networks, the networks must be of the same type, for example all outbound or all routed. The gateway can be connected to multiple machines or load balancers that are connected to the same outbound or routed networks. The gateway must be connected to a load balancer on the shared on-demand network so that it can reuse the NSX-T Tier-1 router or NSX-V Edge Service Gateway (ESG) created by the gateway.
To allow multiple outbound or routed networks to share the same T1 router or Edge, connect a single Cloud.NSX.Gateway gateway resource to all the networks initially. All the intended networks and the single gateway must be connected together before you deploy the cloud template, otherwise each network creates its own router.
For an NSX network that contains an associated compute gateway resource, the gateway settings are applied to all associated networks in the deployment. A single NSX-T Tier-1 logical router is created for each deployment and shared by all on-demand networks and load balancers in the deployment. A single NSX-V Edge is created for each deployment and shared by all the on-demand networks and load balancers in the deployment.
You can attach the gateway resource to a network as an iterative deployment update. However, doing so does not create a Tier-1 or Edge router - the initial network deployment creates the router.
For NSX-T networks that do not use an associated gateway resource, multiple on-demand networks in the cloud template continue to create multiple Tier-1 logical routers in the deployment.
If the gateway contains NAT rules, you can reconfigure or delete the NAT or DNAT rules for the Tier 1 router or Edge router. If the gateway is initially deployed with no NAT rules, it has no available day 2 actions.
NSX NAT resource
The Cloud.NSX.NAT resource allows DNAT rules and port forwarding to be attached to all the connected outbound networks by way of the gateway resource. You can attach a NAT resource to a gateway resource for which the DNAT rules need to be configured.
The Cloud.NSX.Gateway resource was originally available for DNAT rules. However, use of the Cloud.NSX.Gateway as a means of defining DNAT rules and port forwarding has been deprecated. It does remain available for backward compatibility. Use the Cloud.NSX.NAT cloud template resource for DNAT rules and port forwarding. A warning appears in the cloud template if you attempt to use the Cloud.NSX.Gateway resource type with NAT rule specifications.
The Cloud.NSX.NAT resource supports DNAT rules and port forwarding when connected to an outbound NSX-V or NSX-T network.
The NAT rules setting in the resource is natRules:. You can attach the NAT resource to the gateway resource to configure the natRules: entries on the gateway. DNAT rules that are specified in the resource use the associated machines or load balancers as their target.
You can reconfigure a machine NIC or compute gateway in an existing deployment to modify its natRules: settings by adding, reordering, editing or deleting DNAT port forwarding rules. You cannot use DNAT rules with clustered machines. You can specify DNAT rules for individual machines within the cluster as part of a day 2 operation.
VLAN segments and private NSX-T networks
You can specify VLAN segments for private NSX on-demand network when the network segments are used with a Policy API-type of NSX-T cloud account. For information on supported configurations and network profile requirements, see Network resources in vRealize Automation.
External IPAM integration properties for Infoblox
For information about cloud template properties that are available for use with your Infoblox external IPAM integrations, see Using Infoblox-specific properties and extensible attributes for IPAM integrations in vRealize Automation cloud templates.
Caveats for using a static IP assignment in a cloud template
You can use a static IP assignment in a vRealize Automation cloud template only when using vRealize Automation IPAM, meaning IPAM that is either the vRealize Automation-supplied internal IPAM or IPAM derived from an external provider plug-in that has been created by using the vRealize Automation IPAM SDK - for example one of the Infobox plug-ins that are available for download from the VMware Marketplace. Using a static IP assignment (assignment:static) is not supported within a cloud template when using a Network Configure event topic (which is used by either a Cloud Assembly extensibility (ABX) action or a vRealize Orchestrator workflow). Unsupported static IP assignments cause deployment failure.
For an example of a static IP assignment in a cloud template, see Networks, security resources, and load balancers in vRealize Automation.
Address value in General section of deployed cloud template
When examining a deployed cloud template, the Address value in the General section of the template is the primary IP address of the machine. The primary address is often the public or otherwise accessible machine address. For vSphere deployments, the primary IP address is calculated by vRealize Automation. All IP addresses for all NICS, including their public, private, IPv6, static, and dynamic properties, are considered and ranked to determine the primary IP address. For non-vSphere deployments, the primary IP address of the machine is calculated by each cloud vendor’s ranking system.
Available day 2 operations
For a list of common day 2 operations that are available for cloud template and deployment resources, see What actions can I run on Cloud Assembly deployments.
For an example of how to move from one network to another, see How to move a deployed machine to another network.
Learn more
For related information and examples that illustrate sample network resources and settings, see Networks, security resources, and load balancers in vRealize Automation.
For information about defining network resources, see Network resources in vRealize Automation.
For information about defining network profiles, see Learn more about network profiles in vRealize Automation.
