Dr. Pranay Jha

Write a template that asks for a small Ubuntu box, and it should deploy in London or Frankfurt without a single change. Mappings and profiles are what make that true. They are the translation layer between the names your templates speak and the real flavors, images, networks, and storage each region actually has. Skip this layer and your templates hard-code one region’s specifics, which means a second region needs a second template, and now you maintain two of everything.

The four building blocks

Four pieces sit between a template and the metal. A flavor mapping resolves a size name to real CPU and memory. An image mapping resolves an OS name to a real template or image. A network profile describes which networks a deployment can use and how on-demand networks are built. A storage profile decides how disks are placed using storage classes and policies. Templates reference the names; these four resolve the names to reality, per region and cloud account.

The naming contract is the whole trick

Here is the insight that makes this layer worth the effort. Because a template references a name and the mapping resolves it per region, the same name can point at different real resources in different regions, and the template never knows. Define small as 2 vCPU and 8Gi in region-a and the equivalent in region-b, define ubuntu as the local Ubuntu template in each, and a single template deploys in both. The names are a contract between template authors and infrastructure admins: authors promise to only ask for names that exist, admins promise every region honours the same names.

# Same names, different reality per region (flavor + image mappings)
region-a:
  flavor:  small  -> 2 vCPU, 8Gi
  image:   ubuntu -> ubuntu-2204-template-a
region-b:
  flavor:  small  -> 2 vCPU, 8Gi
  image:   ubuntu -> ubuntu-2204-template-b

# The template just references the names, so it is region-agnostic:
resources:
  app_vm:
    type: Cloud.vSphere.Machine
    properties:
      flavor: small        # resolved by the region's flavor mapping
      image:  ubuntu       # resolved by the region's image mapping

Network and storage profiles

A network profile is more than a list of networks. It is a collection of network characteristics for a named cloud account and region: the existing networks a deployment can attach to and their settings, plus policies that define on-demand networks and other behaviour. This is where VCF Automation’s ability to build NSX networking in the background gets configured, so a template can ask for an on-demand network and the profile decides how that network is actually created. Get the profile right and developers request networking without ever touching NSX; get it wrong and either nothing connects or everything lands on one flat segment.

Storage profiles do the same job for disks. Backed by storage classes and policies, including the vSAN default policy, a storage profile decides how a deployment’s storage is placed and what guarantees it carries. A name like gold can map to a high-performance vSAN policy in one region and the nearest equivalent in another, keeping the same portability promise as flavors and images. The mistake teams make is leaving storage to the default and discovering later that everything landed on one policy with no way to differentiate tiers.

How on-demand networking actually works

The headline capability of a network profile is on-demand networking, and it is worth understanding because it is where a lot of the platform’s value lives. A template can declare it needs a network without naming an existing one, and the profile’s on-demand policy tells VCF Automation how to build it: which transport zone, which edge, what kind of segment, and how it connects outward. The platform then creates the NSX segment and the wiring in the background at deploy time, and tears it all down when the deployment is destroyed. For a developer this is the difference between filing a network ticket and waiting, and getting a working, isolated network as part of the same request that built their machines.

The design decision inside a network profile is which network types you expose. Existing networks attach a deployment to a segment you already run, which suits shared services everyone uses. On-demand networks create fresh, isolated segments per deployment, which suits self-contained application stacks that should not share a broadcast domain with anyone else. Outbound and routed options control how those networks reach the rest of the world. Expose only the types your tenants should actually use, because every network type you offer is a shape of network someone can now request without asking you, and an over-generous profile is how unexpected segments start appearing in NSX.

One binding detail ties this back to portability. A profile is defined for a specific cloud account and region, so it is not shared globally; each region needs its own profile, just as it needs its own mappings. That is why a template that deploys cleanly is really a template plus a complete set of mappings and profiles in the target region. It also means a change to one region’s network design is a change to that region’s profile alone, not a global edit, which is safer but easy to forget when you assume a fix in one place covers everywhere. Document the profiles next to the mappings, because together they are the full contract every template silently depends on.

The Bottom Line

Mappings and profiles are unglamorous and they are where template portability is won or lost. My recommendation: agree a small, fixed vocabulary of names, three flavors, a short list of images, a couple of storage tiers, and make every region honour exactly those names. Treat the names as a contract: authors only ask for names that exist everywhere, admins guarantee every region defines them. Build network profiles that expose what developers actually need, including on-demand networks, so they never have to reach into NSX. Do this and your template library is written once and runs anywhere you have a region. Skip it and you will maintain a separate template for every place you deploy, which is the exact toil this platform exists to remove.

Next we finally write the thing all of this supports: VMware Cloud Templates, the blueprints that reference these names. For where deployments actually land, revisit Part 10 on cloud zones. How many flavor and image names do you standardise on? Tell me in the comments.

References

• Network Profiles in VCF Automation (Broadcom TechDocs)
• Image Mappings in VCF Automation (Broadcom TechDocs)
• VCF Automation: From Zero to a Running VM (vWorld)

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts