WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple
You are here: Home / VMware Cloud Foundation / VCF 9.1 - Deploying VCF Management Services (VCFMS) to non-Management Network during VCF Upgrade

VCF 9.1 - Deploying VCF Management Services (VCFMS) to non-Management Network during VCF Upgrade

06.03.2026 by William Lam // 7 Comments

As part of upgrading an existing VMware Cloud Foundation (VCF) deployment from either VCF 5.x or 9.0.x to VCF 9.1, one of the required steps is deploying the new VCF Management Services (VCFMS) component using a workflow provided by SDDC Manager.


The current default behavior of the VCFMS deployment workflow is to automatically deploy the VCFMS components, shown below, onto the existing VM Management network. This is typically the same network that hosts infrastructure components such as vCenter Server, NSX and other management services.


While defaulting to the management network may be convenient, most enterprise organizations do not have a large number of free IP addresses sitting idle. Even if there was available IP capacity, it is usually not contiguous blocks of IPs, which can make accommodating the CIDR-based IP allocation requirements of VCFMS more challenging than expected.

The good news is that we can use the SDDC Manager API to select an alternative vSphere-based VLAN network to deploy VCFMS!

In fact, I recently demonstrated how to use the SDDC Manager API to choose an alternative IP allocation method when deploying VCFMS, enabling organizations to make more efficient use of their available IP address space rather than requiring large contiguous blocks of addresses due to use of CIDR format.

To assist users with this advance workflow, which  has two scenarios:

  1. Single VCF Instance within VCF Fleet
  2. Multi-VCF Instance within VCF Fleet

Scenario 1

I have created PowerShell script called sddcm_deploy_vcf_management_service_to_non_management_network_on_primary_vcf_instance.ps1 which is meant for your initial VCF Instance (Primary) that you can easily use after updating the variables within the script with your desired values.

You will need to provide the exact same input as the SDDC Manager UI which includes: VCF Operations credentials, SDDC Manager credentials, VCFMS FQDNs along with list of IP addresses you wish to use (instead of CIDR) and the vSphere Portgroup to deploy VCFMS.

The script will run in validation mode by default, which will invoke the VCFMS Components Validation API and below is an example:


If you receive any failed validations, address them before updating the $ValidateOnly variable to false which will begin the VCFMS deployment as shown in screenshot below.


Once the deployment has started, you can login to VCF Operations and navigate to Build->Tasks to monitor the progress.

For those interested, here is a complete working JSON payload for deploying VCFMS onto a non-management network residing in the primary VCF Instance:

{
  "vcfOperationsSpec": {
    "nodes": [
      {
        "type": "master",
        "sslThumbprint": "6B:D3:FC:4F:AC:2A:5D:0B:87:D0:71:ED:B8:92:D8:51:E9:E3:9F:50:91:1B:23:E3:B0:FC:20:EE:0F:64:A2:E9",
        "hostname": "vcf02.vcf.lab"
      }
    ],
    "adminUserPassword": "VMware1!VMware1!",
    "loadBalancerFqdn": "",
    "useExistingDeployment": true
  },
  "vspClusterSpec": {
    "platformFqdn": "vcf-msr03.vcf.lab",
    "systemUserPassword": "VMware1!VMware1!",
    "ipv4Pool": {
      "addresses": [
        "172.30.70.170",
        "172.30.70.172",
        "172.30.70.173",
        "172.30.70.174",
        "172.30.70.175",
        "172.30.70.176",
        "172.30.70.177",
        "172.30.70.178",
        "172.30.70.179",
        "172.30.70.180",
        "172.30.70.181",
        "172.30.70.182"
      ]
    },
    "size": "small",
    "internalClusterCidrIpv4": "198.18.0.0/15",
    "instanceFqdn": "vcf-int03.vcf.lab",
    "fleetFqdn": "vcf-flt03.vcf.lab",
    "useExistingDeployment": false
  },
  "vcfManagementComponentsInfrastructureSpec": {
    "xRegionNetwork": {
      "networkName": "DVPG_FOR_FLEET_MANAGEMENT",
      "subnetMask": "255.255.255.0",
      "gateway": "172.30.70.1"
    }
  },
  "licenseServerSpec": {
    "hostname": "vcf-lic03.vcf.lab"
  },
  "vidbSpec": {
    "hostname": "vcf-idb03.vcf.lab"
  },
  "fleetLcmSpec": {},
  "sddcLcmSpec": {},
  "fleetDepotSpec": {},
  "telemetryAcceptorSpec": {},
  "saltSpec": {},
  "saltRaasSpec": {}
}

Scenario 2

I have created PowerShell script called sddcm_deploy_vcf_management_service_to_non_management_network_on_non_primary_vcf_instance.ps1 which handles additional VCF Instances (non-primary) as only subset of the VCFMS components is required to be deployed and thus requires a different API spec using the VCF_EXTEND workflow.

You will provide similiar inputs as the SDDC Manager UI which includes: VCF Operations credentials, SDDC Manager credentials, VCFMS FQDNs along with list of IP addresses you wish to use (instead of CIDR) and the vSphere Portgroup to deploy VCFMS along with then VCF Instance label, which you can find within VCF Operations inventory UI.

The script will run in validation mode by default, which will invoke the VCFMS Components Validation API and if everything passes, you can then update the $ValidateOnly variable to false to begin the VCFMS deployment on your non-primary VCF Instances.

For those interested, here is a complete working JSON payload for deploying VCFMS onto a non-management network residing in the non-primary VCF Instances:

{
  "vcfInstanceName": "William VCF 9 Instance 2",
  "workflowType": "VCF_EXTEND",
  "vcfOperationsSpec": {
    "nodes": [
      {
        "sslThumbprint": "D4:BC:0C:A0:C3:66:6D:B1:D4:7C:B3:5C:02:EB:A8:1D:AC:34:FE:48:AC:66:FA:03:ED:8F:96:A4:52:18:44:A5",
        "hostname": "vcf02.vcf.lab",
        "type": "master"
      }
    ],
    "adminUserPassword": "VMware1!VMware1!",
    "loadBalancerFqdn": "",
    "useExistingDeployment": true
  },
  "vspClusterSpec": {
    "platformFqdn": "vcf-msr03.vcf.lab",
    "systemUserPassword": "VMware1!VMware1!",
    "ipv4Pool": {
      "addresses": [
        "172.30.70.170",
        "172.30.70.172",
        "172.30.70.173",
        "172.30.70.174",
        "172.30.70.175",
        "172.30.70.176",
        "172.30.70.177",
        "172.30.70.178",
        "172.30.70.179",
        "172.30.70.180",
        "172.30.70.181",
        "172.30.70.182"
      ]
    },
    "size": "small",
    "internalClusterCidrIpv4": "198.18.0.0/15",
    "instanceFqdn": "vcf-int03.vcf.lab",
    "useExistingDeployment": false
  },
  "vcfManagementComponentsInfrastructureSpec": {
    "xRegionNetwork": {
      "networkName": "DVPG_FOR_FLEET_MANAGEMENT",
      "subnetMask": "255.255.255.0",
      "gateway": "172.30.70.1"
    }
  }
}

Categories // VMware Cloud Foundation Tags // VCF 9.1, VCFMS

Comments

  1. *protectedNav says

    06/03/2026 at 11:08 pm

    Fantastic article as always. I made the mistake of deploying to the management network and now I have run out of IP Addresses for VCF Automation. Is there a way I can redeploy VCFMS onto an Overlay Network?

    Reply
    • William Lam says

      06/04/2026 at 5:49 am

      Thanks! VCFMS actually supports several networking models including Overlay https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-library/fleet-level-components-networking-detailed-design.html

      The challenge as mentioned in the article is during upgrade, you may or may not have sufficient IPs in your management network and you can deploy to both DVPG (VLAN back) or Overlay using the APIs. There is not a native re-deployment workflow afaik, there is KB around removing failed deployment ... but in your situation, you still can proceed as VCF Automation can be deployed separately using Fleet LCM API, which is what needs to be used once VCFMS has been deployed and there you can deploy to non-management network using API to both DVPG or Overlay.

      I was going to be working on the API example for VCFA shortly with a couple of options with an example, stay tuned

      Reply
  2. *protectedJoshua says

    06/28/2026 at 5:49 pm

    Hi William,

    These scripts went a long way to alleviating upgrade headaches deploying management services on a new VLAN. Quick observation though, your password fields use double-quotes; not all passwords evaluate correctly in PowerShell that way. I got tripped up on this briefly and the error referenced an unresolvable FQDN for VCF Ops when the problem really was PowerShell evaluating special characters in my password instead of treating it as a string literal.

    Reply
  3. *protectedFahim Istiaq says

    07/26/2026 at 12:35 am

    Hi William, Do VCFMS support Overlay ? If yes, can you please provide me some reference ?

    Reply
    • William Lam says

      07/26/2026 at 5:59 am

      No, must be VLAN backed

      Reply
  4. *protectedMichael Teofrio says

    07/27/2026 at 7:07 am

    William,

    Running vCF 9.0 in an air-gapped instance. My vSphere infrastructure runs in 191.0/24 (infra.local) and my current Day-N services (ops, logs, automation, networks) runs in a separate domain (services.local) 246.0/24 which is an NSX backed segment. When moving to 9.1 and the introduction to VCFMS, according to the design document, we are supposed to deploy VCFMS runtime to vLAN backed but the Day-N services can deployed to Overlay Segment. See Below:

    https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-library/fleet-level-components-networking-detailed-design/fleet-level-components-on-stretched-nsx-overlay-segment-model.html

    My question through all this is I am trying to keep the same network design and introducing a VLAN backed segment for the runtime x.x.197.0/24 and keep the services on (246.0/24) Using your script seems feasible but with your localRegion and xRegion, you have the same layer 3 config. Would it be possible to separate these? If not, how is the design in the above model possible unless the VLAN is bridged between the segment and have the same Layer 3 subnet configuration? Any input would be helpful! Thank you!

    Reply
    • William Lam says

      07/28/2026 at 2:30 pm

      Michael,

      It looks like early on during our testing, localRegionNetwork was required but just confirmed with Engr that is no longer the case and only xRegion is needed. I've updated my scripts to reflect that, so hopefully you should be good now

      Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Quick Tip: Reducing High CPU Utilization on NSX due to slow Entropy from AMD Zen4/5 CPUs 07/31/2026
  • VCF 9.1 - Quick Tip: Easily Generate VCF SSO API Tokens using VCF Component UI 07/27/2026
  • VCF 9.1 - Deploying the VCF License Server Directly to an ESX Host 07/24/2026
  • VCF 9.1 - vSphere Back-in-Time Support for Upgrade, Converge and Import 07/21/2026
  • VCF Infrastructure Services (VIS) Appliance for VCF 9.1 Lab/PoC 07/20/2026
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.

To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2026

Loading Comments...