Of the types of networks available through NSX, private networks are the easiest to get going because they don’t require any NSX edge routers to be in place. Think about it, the NSX edge appliance is used to allow communication with the physical network which we won’t need for a private network.

A quick refresher here, a private network is a network that is not connected to the rest of the environment. Machines that are on the private network can communicate with each other, but nothing else in the environment. Its simple, think of some machines connected to a switch and the switch isn’t connected to any routers. The machines connected to the switch can talk to each other, but thats it.

Use Case: A private network could be used to test an application in isolated environment so as to not affect a production environment. The machines in the private network could have the same IP Addresses as the production network but its ok because they can’t talk to each other. Using a private network with vRA would allow teams to deploy multi-tier applications over an over without affecting the production environment.

Build It

If you haven’t already gone through the process of setting up NSX and connecting it to vRealize Automation, you should do this first. Assuming you’ve already done this then lets begin.

Login to vRA and add a new Multi-Machine Blueprint. Fill out the Blueprint information tab and then skip over to the Network tab where the magic starts.

Select the Transport Zone from the dropdown list. Then select the New Network Profile dropdown list and then select Private. Give the new profile a name, subnet mask, gateway, and if you’re using DHCP or not.

Next select the IP Ranges tab. Create a new network range and a set of starting and ending IP Addresses. These will be assigned to the virtual machines when they’re provisioned in this new network.

Now we go to back to the Build Information tab. Select the Add Blueprints option to select a blueprint that you’ve already created. You can do this several times to add many virtual machines to your multi-machine blueprint.

Once you’ve added the blueprints to this new multi-machine blueprint, select the edit hyperlink under the network column. Here you’ll select the network profile we just created in the previous step. Remember to do this for each of the blueprints. In my case, I’ve added each of the blueprints to the same network profile but you could add many network profiles if you wished.

Once this is done you can finish up your blueprint setup with any additional configurations you might want to add such as post deployment scripts, Lease settings, Build Profiles or actions. Save the blueprint and publish it. Assign the blueprint to a service and grant entitlements. All of this is outside the scope of this article but is a standard process for deploying blueprints in vRealize Automation 6.

Request Item

What are you waiting for? Go request your new catalog item. For this test I’m using the “Tiered Private” item we just created.

Wait for the VMs to provision and then go check your vCenter to see what happened! The first thing you might notice that that in your NSX UI there is a new NSX edge that has been created automatically.

If we look at the interfaces of this edge we’ll notice that a single interface is added (internal) and that the IP Address is the default gateway that you used in your network profile in vRA. Pretty neat huh?

Now that you’ve seen some of the coolness, you probably aren’t surprised that a new logical switch has been created. This logical switch is connected to the internal interface of the new NSX edge.

In my vRA workloads cluster, I’ve got my new NSX edge and a pair of virtual machines that are part of my private network test. Notice that the IP Addresses are aligned with the network profile we created. 

If we console into our first vm (Hollow-02) we notice the IP Address and subnet mask. If we ping the other virtual machine (hollow-03) we get replies from the server. On the other hand if we try to ping anything else such as a public DNS Server (4.2.2.1) the destination is not reachable.

Summary

vRealize Automation gives us some cool ways to deploy virtual machines but combining it with a solution like NSX give us even more power to deploy mutli-tier apps. Micro-segmentation is too difficult to manage on a one by one basis, but with an automation solution in place these operations become feasible. Private networks give us the ability to test solutions over and over without affecting existing workloads and have their place in a new devops world.