BOSH CLI Reports "requires CPI v2.0 or greater, you are using 1" When Applying Changes for Platform Services During VCF Automation Foundation Vending

Products

• VMware Tanzu Platform Core
• VMware Tanzu Platform - Hub

Issue/Introduction

While vending a Tanzu Platform foundation through VCF Automation, the Apply Changes step for Platform Services fails. The underlying bosh create-env invocation completes release validation, compiles packages, and installs the CPI job successfully, then aborts immediately afterward with:

Installing job 'vcf_cpi'... Finished (00:00:00)
Finished installing CPI (00:00:37)
Cleaning up rendered CPI jobs... Finished (00:00:00)
The `bosh` cli requires CPI v2.0 or greater, you are using 1
Exit code 1

The failure occurs on the tenant's Tanzu Operations Manager VM, under /var/tempest/workspaces/default/, which is the internal workspace Operations Manager uses to drive bosh create-env against its own BOSH Director during Apply Changes.

Environment

- VCF Automation / Tanzu Hub 
- VMware Cloud Foundation (VCF) 9.x
- Tanzu Operations Manager (BOSH Director tile, bosh-vcf-cpi release)

Cause

The error indicates the CLI received (or defaulted to) API version 1 from that info call but investigation shows this is not caused by an incompatible or downgraded bosh-vcf-cpi release. Instead, it occurs when the freshly-installed vcf_cpi binary's first invocation fails, times out, or does not return cleanly,typically due to transient CPU, memory, or disk I/O contention on the Operations Manager VM (or its underlying host/datastore) at the exact moment info is called, which lands right after a compile-heavy portion of the install. When this happens, the BOSH CLI surfaces the generic "you are using 1" message rather than the actual timeout/resource error, which makes the error misleading relative to its root cause.

Resolution

Create support ticket with Broadcom and collect and upload the following to help isolate whether the cause is resource contention versus something else:

1. Operations Manager VM: free -m, df -h /var/tempest /var/vcap, and kernel/OOM logs (journalctl -k or dmesg -T) for the failure window.
2. vCenter performance charts (CPU, memory, disk latency) for the Operations Manager VM's host and datastore, for the failure window.
3. The raw info CPI-call request/response from the Operations Manager task log, immediately following the Cleaning up rendered CPI jobs line. This shows whether vcf_cpi returned a genuine api_version: 1 response or errored/timed out.
4. Whether other foundation vending operations were running concurrently against the same vCenter cluster at the time of failure.
5.  Re-run the same create-env command captured in the failing task log with debug logging enabled, so the full JSON-RPC exchange with vcf_cpi is captured in a single file: E.g 
   
   

   BOSH_LOG_LEVEL=debug BOSH_LOG_PATH=/tmp/bosh-debug.log /usr/local/bin/bosh --no-color --non-interactive --tty create-env /var/tempest/workspaces/default/deployments/bosh.yml -l /var/tempest/workspaces/default/deployments/vars.yml --package-dir /var/vcap/packages

   
   
   Only run this manually when Apply Changes is not concurrently in progress from Operations Manager itself, to avoid two processes mutating director state at the same time. Because the failure is timing-dependent, a single manual run may not reproduce it.