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 // 2 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": {
    "localRegionNetwork": {
      "networkName": "DVPG_FOR_FLEET_MANAGEMENT",
      "subnetMask": "255.255.255.0",
      "gateway": "172.30.70.1"
    },
    "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": {
    "localRegionNetwork": {
      "networkName": "DVPG_FOR_FLEET_MANAGEMENT",
      "subnetMask": "255.255.255.0",
      "gateway": "172.30.70.1"
    },
    "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

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
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VCF 9.1 - Enabling High Availability for a Small VCF Management Services (VCFMS) Deployment 06/22/2026
  • Clarifying Minimum Required ESX Hosts for VCF Deployments 06/18/2026
  • VCF 9.1 - Auditing VCF Management Services (VCFMS) IP Pool Usage  06/17/2026
  • VCF 9.1 - Auditing vCenter Server Connections using the Connection Utilization API 06/15/2026
  • Quick Tip: Resolving OVFTool "Failed to Send File" Errors on macOS 06/13/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...