Dr. Pranay Jha

Adopting VCF Automation does not mean rebuilding the hundreds of VMs you already run. The machines that predate the platform can be brought under its governance as they are, without redeploying them. The mechanism is the onboarding plan, and in 9.1 there is a second, no-downtime path for the All Apps world. The catch is that a brownfield VM does not always end up with the same capabilities as one born in the catalog, and knowing where that line falls is the difference between a clean adoption and a surprise three months later.

Two ways to bring brownfield under management

There are two distinct mechanisms, and they belong to the two organization types. In a VM Apps organization, the onboarding plan is the long-standing path inherited from Aria Automation: it takes machines that vCenter already knows about and that VCF Automation has data-collected, and turns them into managed deployments. In an All Apps organization, 9.1 adds a non-disruptive import that brings vSphere VMs into a Supervisor namespace under VM Service control with no downtime and no change of network identity. Same goal, bring the unmanaged under control, but different machinery and different constraints.

Onboarding plans, step by step

An onboarding plan exists to identify machines that have been data-collected from a cloud account but are not yet managed by a project, and to bring them under management. The flow is four steps and it is forgiving, because nothing is destructive: you are wrapping existing machines, not recreating them.

Discovered machines surface under Resources, Virtual Machines, marked with an Origin of Discovered. You create a plan, add machines to it manually, and decide how they group: one deployment per machine, or many machines into a single deployment that mirrors an application. You then assign the target project and owner, and run the plan. The output is a set of managed deployments and an accompanying cloud template that describes them.

Scale and what comes across

This is built for bulk. A single onboarding plan handles up to 3,500 unmanaged machines per hour, and you can run multiple plans to onboard up to 17,000 machines concurrently per hour. Onboarding preserves more than the VM: custom properties, attached disks, vSphere networks, and deployment ownership all come across. That fidelity is what makes onboarding a real adoption tool rather than a registration trick.

The Update action you do not get

Here is the limitation that catches teams. After onboarding, you can run most day-2 actions on the deployment, but not the Update action. You can power, resize, change lease, change owner and delete, but you cannot push a changed cloud template back through Update the way you can on a deployment that was born from the catalog. The reason is that the template was reverse-generated to match what already existed, not authored as the desired state. If a workload genuinely needs full template-driven lifecycle, onboarding is the first step, not the last.

# Cloud template an onboarding plan generates (shape, not authored by hand)
formatVersion: 1
inputs: {}
resources:
  app-server-01:
    type: Cloud.vSphere.Machine
    properties:
      name: app-server-01
      networks:
        - network: '${resource.app-net.id}'
  app-net:
    type: Cloud.vSphere.Network
    properties:
      networkType: existing

Expected result: the deployment appears on the Deployments page with this template attached and the machine still running untouched. Note the existing network type, the generated template references resources that are already there. The failure mode to watch is a machine that never shows up as Discovered, which almost always means the cloud account is not data-collecting that region, not that onboarding is broken.

The 9.1 non-disruptive VM Service import

For All Apps organizations, 9.1 introduces a different answer. You can bring existing vSphere workloads into a Supervisor namespace and under VCF Automation control without downtime and without a network identity change. In the past, moving a VM into a namespace often meant a re-IP and therefore an outage. Now the import keeps the machine and its address in place, and you can move VMs in batches using the ImportOperationBatch operation. The tested constraint to remember: imported VMs are managed by VCF Automation only if the namespace they land in was created by VCF Automation itself, not one carved directly in vCenter.

This matters beyond a single import. A non-disruptive path from a plain vSphere VM into the Supervisor model is the groundwork for moving workloads from VM Apps to All Apps without rebuilding them, which has been the hardest part of that transition. If your direction of travel is toward the All Apps architecture, this is the import to learn.

Where I'd Start

Onboard early and onboard in application-shaped groups. The fastest way to make VCF Automation real for an existing estate is to bring the running workloads under it, because governance, leases and day-2 only matter once they apply to the machines people actually use. Use onboarding plans for the bulk of a VM Apps estate, accept the missing Update action as the price of not rebuilding, and tag the few workloads that genuinely need template lifecycle for a later, deliberate rebuild. When would I import to VM Service instead? When the workload is already on the road to All Apps and cannot take downtime, take the non-disruptive path and keep the network identity intact. The thing not to do is leave hundreds of VMs unmanaged beside a shiny new catalog, because an automation platform that governs only the new stuff governs almost nothing. Which of your existing applications would you onboard first, and is it one that will ever need Update?

References

• Onboard selected machines as a single deployment in VCF Automation (Broadcom TechDocs)
• Import Multiple VMs into VM Service Using ImportOperationBatch (Broadcom TechDocs)
• What is new in VCF Automation (Broadcom TechDocs)
• VCF 9.1 improvements: VCF Automation and VKS (Cloud Blogger)

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