There are 2 choices,
1) If you have multiple Compute pools or Network Container(NC) then use Tag
2) or Create another Tenant & associate NC with that Tenant
In my case I have selected 1st option but that didn't worked so I have removed all the Tag & chose 2nd option. Now I don't have any Tag and any policy in Service Governor, but still its showing error related Tag. My question is, if we don't have any Tag & Policy defined then how come Tag error is throwing?
Alright, here's a lesson on what worked for me on using Tags. This has always been a confusing topic. Below is a representation of option #1 as its the only option I have tried (have not tried what you suggested in #2).
I've scrubbed some of the sensitive information on the screenshots and changed names for Location/Container/etc to protect the innocent, but hopefully the context carries through.
First, its the defined location. For this example, we have two locations, each represent a different data center with separate Virtual Centers and ESX Clusters. For this example, we are going to use "LocationA".
Second, we have our created POD from our BBNA blueprint. This is the default VCenter Pod definition (a topic for another thread). For this example, we refer to this pod as "PodA".
Then, we have our network containers. In this example, we have an alternate site (blanketed out) and Primary, which is what we'll use in this example.
Now comes the Compute Pools - we are going to focus on the one labeled "vCD" as the representation of the VirtualCluster in the Primary site.
Now comes the tagging. First you need to create the tags and their appropriate values. You can do this from editing a resource such as Network Container or Resource Pool, and clicking on the Add Tag icon and then select "Manage Tags" on the bottom corner.
Here, we add two tags and assign appropriate values. One tag is for the Site (determins which Location you will be provisioning to. The second tag is for determining which Compute Pool to provision to. I always thought you could get away with a single tag for both Site (synonimous with Network Container in our case) and Compute Pool, but for our use cases we may have more than one Conpute Pool in each Site. Your use cases may vary.
Second, you need to ensure correct tag value assignment in the Network Container. Otherwise, the service governor will not know where to provision to. So in the screenshot below, we edit the Network Container for the "Primary" site.
Note that we specified two tags:
Site = LocationA
ComputePool = vCD
The Pod automatically gets associated with PodA as its part of the onboarding of Network Container (again, topic for another thread).
The next important item is to edit the ComputePool and assign the appropriate tag value. Below, you will see we assigned tag:
Compute Pool = vCD.
You will see how this is used later on.
Now lets configure the Service Governor on which tags it should consider for allocating resources to provisioniong requests. Below you will see the Service Governor takes into account the "Site" tag value in the Service Blueprints when deciding on which Network Container to provision into.
Below you will see that the Service Governor will take into account the Compute Pool tag value in the Service Blueprint when deciding on which Compute Pool to provision into.
Below you will see that we are not making any distinctions on which Virtual Disk Repository Pools to provision into (that's because we only have one onboarded with the Primary POD).
Now lets look at the blueprint tag assignment. This is critical to ensure the Service Governor can make the right decisions. The values assigned to the Blueprints are the ones taken into account for provisioning by the Service Governor.
We have tags assigned in other places of the Service Blueprint, but none are necessary except in this location for determining the Container and Compute pool to provision into.
Hopefully the above shines some light in the Tag usage from a minimum requirements perspective.