Cloud Assembly provides the ability to create Provider and on-demand networks, plus use existing software defined networks, through our integrations with VMware NSX.  NSX isn’t the only option available for Infrastructure as Code needs.  Cloud Assembly also allows you to leverage the network resources provided by public cloud providers.  Over the next four posts, I’ll go through how to configure the networking options for Cloud Assembly and NSX, explain blueprint options, and which network constructs are created during the deployment process.  For this post, I’ll walk through the initial setup and configuration of the vSphere and NSX Cloud Accounts.  Also I will cover how to work with discovered compute and network objects.

This blog article assumes you have access to Cloud Assembly, a Cloud Proxy is deployed ( or video ) on premises, you’ve covered all your pre-req bases and are ready to configure and deploy compute and network resources.  If you’re not there yet, no problem, you can learn more and create a Cloud Services account here, then check out the getting started documentation and come back when you’re ready.

Adding Cloud Accounts


We’ll start by logging in and accessing Cloud Assembly then configuring Cloud Accounts.  The first thing to do is create a Cloud Account for an on premises vCenter environment.  To begin, choose Infrastructure – Cloud Accounts – Add Cloud Account.



Select vCenter first.  Add the IP/FQDN for the vCenter, choose a cloud proxy, enter the vCenter credentials and name, then click Add.  On-demand and provider networks are supported on both NSX-v and NSX-T.  For this post, I chose NSX-T.  Click Add Cloud Account again, choose NSX-T in the Account Types UI, enter the NSX-T management server, cloud proxy (you can use the same proxy for multiple Cloud Accounts), then add the credentials, and name.  Once you are done adding the Cloud Accounts, click Add.



Shown below, I added vc-south and nsx-south.  NSX (nsx-south) is now a capability available to the vc-south environment.  When deployment decisions are made involving networking, where the capabilities match the blueprint, the association between vc-south and nsx-south will be taken into account.



Viewing Discovered Resources


The vSphere and NSX accounts are configured.  After a few minutes Cloud Assembly will display what’s been discovered.  Selecting Compute shows a list of discovered (wait for it…) Compute resources.  Below I can see that Cloud Assembly has discovered my cluster and resource pools from vc-south.

You may have noticed the option to specify tags throughout Cloud Assembly.  Tags are used by Cloud Assembly for placement determination and governance.  We’ll be using tags (in the second and third posts of this series) to tell Cloud Assembly which network profile to use, more on that later.  You can read up on tags and how they’re used within our tags documentation.

Tags are also used to constrain provisioning to compute resources.  I will use the Cluster as a placement destination and have added the constraint tag env:vcs-cluster for later use.  You can add a constraint tag by clicking the Compute Name and creating a tag in the window which opens.  Now that I have confirmed my Compute resources, I need to check what has been discovered for Network constructs.




Add the Network CIDR


Next select Networks and find the switch which allows external access.  Typically this is the switch with an uplink to the T-0 Gateway with an external route.  I will be using Management – Switch for external access in this example.  The first thing we need to do is add the CIDR by clicking the switch name.



Clicking a switch name opens a new window where you can add configurations or view details for that switch.  The first thing I did was add the routed network CIDR, and default gateway.  Adding the CIDR and gateway allows it to be used later in the Network Profile for IP allocation.  You can add other details such as domain, DNS servers and search domains.  Public IP assignment is available for entities using this switch by checking the Support public IP box.  Also I can choose to make this the default switch for this zone.  Choosing default for zone means the switch will be used, unless other constraints are present, when a blueprint calls for the switch’s associated Cloud Zone.  If you’re not sure what Cloud Zones are, you can read more in the Cloud Assembly documentation.  In this case I also added a tag to constraint, net:ext, which allows me to deploy networks that only use this switch.  Click Save once the updates are complete.



Once those areas have been configured, we can focus on setting up Network Profiles.  In the second post, I will walk through how to setup network profiles that will be used when Cloud Assembly makes placement decisions.  Over the next three posts I will cover how to configure and use network profiles, the different network types, and finally load balancers.

Get started with Cloud Assembly today!


Network Automation with Cloud Assembly and NSX part 2 – Network Automation with Cloud Assembly and NSX part 3Network Automation with Cloud Assembly and NSX part 4