Similar to VCF Management Services (VCFMS), VCF Automation (VCFA) can also be deployed to a non-management network using an API workflow. A typically deployment workflow is to first upgrade to VCF 9.1, deploy VCFMS and then deploy VCFA as a Day-N operation using the new VCF Operations Fleet Lifecycle Management (Fleet LCM) capability, located within VCF Operations under Build->Lifecycle->VCF Management.

When using the Fleet LCM UI to deploy VCFA, you will see that the required IP address input uses a CIDR format. This is not ideal for VCFA, which requires exactly 5 IP addresses for the VCF services runtime; the smallest CIDR that meets this requirement is a /29, which ends up consuming 8 IP addresses.

The good news is that we can use the Fleet LCM API to select an alternative vSphere-based network (VLAN or NSX Overlay) and we also get added benefit to use an alternative IP allocation method, which would allow us to specify the exact number of IP Addresses that is required!
Note: This solution is only applicable for brand new deployments of VCFA, for existing Aria Automation 8.x or VCF Automation 9.0.x/9.1.x deployments, the upgrade workflow will use the existing network that VCFA is deployed on and will availabled IP Addresses from that network.
This combined deployment approach means you do not have to leverage another API if your end goal is to have both VCFMS and VCFA reside on the same non-management network. However, if you need to deploy VCFA onto its own isolated non-management network, then the solution in Scenario 1 should be used.
Scenario 1
This solution will be using the Fleet LCM Component Validation and Component Create API. To assist users with this API workflow, I have created PowerShell script called fleet_lcm_deploy_vcf_automation_to_non_management_network.ps1 that you can easily use after updating the variables within the script with your desired values.
You will need to provide similar input as the Fleet LCM UI which includes: VCFA FQDNS along with list of IP addresses you wish to use (instead of CIDR), VCFA credentials and the VCFMS and VCF Fleet FQDN for API accessing the LCM Fleet API. You will also need to provide the name of the VCF Instance name which can be found by logging into VCF Operations and navigating to Operate->Inventory and copy the label.
Note: Make sure your Fleet Depot Service is connected to an Online/Offline Depot and that it has successfully synced VCF metadata and VCF binaries for VCFA which includes the VCD Migration Engine component before starting your deployment or will fail due to missing binaries.
For specifying the vSphere Portgroup/NSX Overlay, you will need to define the Gateway CIDR (e.g. 172.30.70.1/24) and MoRef ID. The easiest way to fetch this value is to use PowerCLI Get-VirtualPortGroup cmdlet and make a note of the value under the key column. In my example, I am deploying to a Distributed Virtual Portgroup called DVPG_FOR_FLEET_MANAGEMENT and the MoRef ID is dvportgroup-58
![]()
By default, the script will only run the validation API and not actually perform the deployment as shown in screenshot below.
![]()
Once you pass the validation, you can update the variable $ValidateOnly to false to start the deployment, which will also run through the validation.

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

For those interested, here is a complete working JSON payload for deploying VCFA onto a non-management network:
{
"componentSpecs": [
{
"componentType": "VCFA",
"deploymentType": "VspComponentSpec",
"sddcLcmId": "f8bdbc5c-be7f-4034-bc1c-a882d4ff65a6",
"fqdn": "auto03.vcf.lab",
"version": "9.1.0.0",
"configSpec": {
"adminSystemPassword": "VMware1!VMware1!",
"size": "small"
},
"vspClusterSpec": {
"deploymentType": "VspClusterSpec",
"sddcLcmId": "f8bdbc5c-be7f-4034-bc1c-a882d4ff65a6",
"platformFqdn": "vcf-asr03.vcf.lab",
"systemUserPassword": "VMware1!VMware1!",
"size": "small",
"ipv4Pool": {
"addresses": [
"172.30.70.65",
"172.30.70.66",
"172.30.70.67",
"172.30.70.68",
"172.30.70.69"
]
},
"networkMoId": "dvportgroup-58",
"gatewayCidrIpv4": "172.30.70.1/24"
}
}
]
}
Scenario 2
This solution builds on my earlier work of deploying VCFMS to non-management network using the SDDC Manager API and we are simply appending the VCFA specification to include that in the deployment specification.
To assist users with this advance workflow, I have created PowerShell script called sddcm_deploy_vcf_management_service_to_non_management_network.ps1 that you can easily use after updating the variables within the script with your desired values.
You will need to provide the following:
- SDDC Manager FQDN, credentials along with the vSphere Portgroup/NSX Overlay label and netmask/gateway information
- VCFMS requirements including 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/NSX Overlay to deploy VCFMS.
- VCFA requirements including the VCFA FQDNs along with list of IP addresses you wish to use (instead of CIDR) and the credentials
Note: Make sure your SDDC Manager is connected to an Online/Offline Depot and that it has successfully synced latest VCF 9.1 metadata and the VCF binaries for VCFMS and VCFA which includes the VCD Migration Engine component before starting your deployment or will fail due to missing binaries.
By default, the script will only run the validation API and not actually perform the deployment as shown in screenshot below.

Once you pass the validation, you can update the variable $ValidateOnly to false to start the deployment, which will also run through the validation.

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 both VCFMS and VCFA onto a non-management network:
{
"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": {},
"vcfAutomationSpec": {
"hostname": "auto03.vcf.lab",
"platformFqdn": "vcf-asr03.vcf.lab",
"adminUserPassword": "VMware1!VMware1!",
"ipPool": [
"172.30.70.65",
"172.30.70.66",
"172.30.70.67",
"172.30.70.68",
"172.30.70.69"
],
"internalClusterCidr": "198.18.0.0/15",
"nodePrefix": "vcf-m01-node-01",
"size": "small"
}
}
Thanks for the comment!