VCAP-CMA Deploy – Objective 1.5

Disclaimer: These are my notes from studying for the 3V0-31.18 exam. If something doesn’t make sense, please feel free to reach out.

The main goal for the whole of section 1 is to understand blueprint creation and modification in depth.

Objective 1.5 – Consume NSX components of a complex blueprint


For this objective, have a think about everything you may need to put in place to consume an NSX element within a blueprint.

First lets start with a list of NSX components that can add to a blueprint:

Existing Security Groups/Tags

Fairly simplistic this one – drag the appropriate component onto the canvas, then select it. Click on the ellipsis button to select the pre-existing component (as the name suggests this should already be created within NSX).


Once the security group/tag is defined, select the VM object you want to associate with the group/tag. Go to the security tab and put a tick in the approriate box(es).


Once you’ve done this, you’ll see the security group/tag link up on the main canvas.


On-Demand Security Group

This one involves a bit more work, but it will create/delete security groups as part of the deployment/destruction of a blueprint.

First you’ll need to create a Security Policy within NSX Service Composer. This is the policy that will apply to the on-demand group, otherwise NSX doesn’t know what you want from the security group!

I kept mine simple, just clicked through the wizard without adding anything in. You can quite easily create rules here, but I chose to leave it as this is just for a lab environment.

Once the policy is created, go back to your blueprint and drag the On-Demand Security Group component on to the canvas. From here give the component a meaningful name, and click on the add button underneath security policies. Then select the policy you created earlier.


Once you’ve got the right security group on the canvas, you can link it under the security tab just like earlier.

On-Demand Routed Network

This is an on-demand network created at the provisioning stage connected to an existing Logical NSX Router. I’m making an assumption that in the exam you’ll already have the appropriate parts of NSX configured for you. After all, they’re not testing on that product. Briefly though, you’ll need:

Within vRA, we need things in place before we can consume a routed network on a blueprint:

On the network profiles page, click New, External. Once you’ve entered a name, you’re done for the routed network requirements. The remaining items are if you want to use the network profile for other things as well. If you choose to fill in the DNS page, the spawned profiles (routed & NAT) will use these values to complete the same page. However it’s not necessary, your call!


Back on the network profiles page, click New, Routed. Complete the page, entering a name, the external network profile you created earlier and fill in the network details:


The DNS page will either be filled in or you can complete it manually, depending on the settings you chose in the external network profile earlier. On network ranges, if you’ve truly allocated the whole subnet, you can select Generate Ranges. This will populate all the subnets based on the Base IP, Subnet mask & Range subnet mask from the General tab. Of course you can also complete this manually.


Now you’ve got the profiles created, you’ll need to link these profiles up in the reservation. The only change you’ll need to make is on the reservation, Network tab. Allocate the appropriate external network to the pre-existing DLR.


This is enough to make the routed network available to the users of that reservation.

Every time you deploy a blueprint that has machines allocated to this profile, it will use a different range. The already deployed DLR will be the gateway, in conjunction with dynamic routing, you’ll be able to route to these VMs.

On-Demand NAT Network

Very similar to the On-Demand Routed Network, key differences are:

So lets assume you’ve already got an external network profile in place and we’re going to create the NAT network profile. Go to the network profiles page and click New, NAT.


Key points on this main page:

As before, if it’s configured in the external profile, the DNS tab will already be populated. The network ranges tab is where you add in the ranges that will be allocated to VMs on this network. Multiple deployments can overlap as these aren’t exposed to the rest of the network.

Once the profiles are configured, the external network profile needs to be linked up on the appropriate reservation. It needs to be configured on whichever logical switch is the transit network.

Once this is complete they can be added to the canvas like any other network.

On-Demand Load Balancer

Exactly what it says on the tin, a load balancer that is deployed in NSX, on-demand. This is a configuration item on the ESG that is deployed with the deployment. If you’re not deploying one for anything else, this will deploy one for you.

The initial configuration is pretty straightforward.

Further down, create the virtual server. This is where there is more configuration options. Initially you can choose the protocol, port & description. There’s then an option to choose the default settings or to customise. If you select customise it opens up the other tabs on the option box.


There are options for:

If you hover over the information symbol for each option it will tell you what each option will give you.


Transport Zone

Key point with NSX, which I frequently forget, is to select the correct transport zone on both the blueprint & the reservation. If these aren’t present, deployment will fail!