Overview
This post documents how to design, build, and maintain an offline depot for VMware Cloud Foundation (VCF), with emphasis on current supported tooling (VCF Download Tool) for VCF 9.x and legacy commands still required by customers running VCF 5.x.
Official vendor documentation remains the authoritative source. This article exists to clarify tooling transitions, highlight behavioral differences across platforms, and document operational realities encountered in the field.
Where multiple approaches exist, the intent is to explain when and why a given method is required—not to replace vendor guidance.
RTFM
This section aggregates notable official vendor documentation referenced throughout this post. These documents remain the source of truth for supported workflows, commands, and lifecycle guidance.
VCF Download Tool (Current and Supported)
The VCF Download Tool is a command-line interface (CLI) utility that is designed to simplify the management of binaries and metadata for VMware Cloud Foundation platforms.
The VCF Download Tool provides a suite of commands for downloading, uploading, listing, and cleaning up binaries, enabling efficient management of software components for VMware Cloud Foundation releases. The tool also supports the installation, uninstallation, and execution of the Update Manager Download Service (UMDS). With its comprehensive features, the VCF Download Tool helps streamline the process of preparing, managing, and maintaining VCF-related artifacts in your environment.
Bundle Transfer Utility (Legacy)
VCF 5.x Lifecycle and Compatibility Notes
The VCF Download Tool contains both utilities.
Navigate to the
vcf-download-tool-<version.build>/bin/and confirm that you have execute permission on all folders. Note that the directory includes both the Bundle Transfer Utility (lcm-bundle-transfer-util) and the VCF Download Tool (vcf-download-tool).
Archived Posts
There are other posts on this website that still contain useful information. I decided to archive them in favor of maintaining this one single post.
Official Tooling Landscape
VMware Cloud Foundation offline depot workflows have evolved over time as tooling has been consolidated and renamed. Today, customers may encounter both current and legacy tools depending on their VCF version and operational constraints.
Understanding which tool applies—and why—is necessary before implementing or maintaining an offline depot.
VCF Download Tool
This tool represents the forward-looking model and should be preferred where supported.
- Current, supported mechanism for acquiring VCF artifacts
- Supersedes earlier standalone utilities
- Used for both online and offline depot workflows
- Actively maintained alongside newer VCF releases
Bundle Transfer Utility (Legacy)
While deprecated, this utility remains operational and relevant for customers maintaining existing VCF 5.x deployments.
- Legacy utility originally designed for offline bundle acquisition
- No longer actively supported
- Still required in specific scenarios involving VCF 5.x environments
Tooling Overlap and Transitional Behavior
The remainder of this post calls out where legacy commands remain valid and where newer tooling should be used instead.
- Some commands and behaviors remain consistent across tools
- Customers may encounter documentation or scripts that reference legacy syntax
- Tool naming alone is not a reliable indicator of applicability
Offline Depot Architecture (Conceptual)
An offline depot is a locally accessible repository that stores VMware Cloud Foundation artifacts required for deployment, upgrades, and lifecycle operations in environments without direct internet access.
Rather than retrieving content on demand, VCF components are configured to reference this repository as a trusted source for required bundles and metadata.
Core Components
The exact layout and metadata format are determined by the tooling used to populate the depot.
An offline depot typically consists of:
- Bundle artifacts (software binaries)
- Metadata describing available versions and dependencies
- Directory structures expected by VCF tooling
- Access controls appropriate for the hosting environment
Access and Trust Model
The depot itself is passive; all validation is performed by VCF tooling and SDDC Manager.
- Depot is hosted on a system reachable by SDDC Manager
- Access may be provided via local filesystem, HTTP, or HTTPS
- Certificates and trust chains must align with platform and security requirements
Why Offline Depots Still Matter
Even in partially connected environments, offline depots provide predictability and operational control.
- Air-gapped or restricted
- Subject to strict egress controls
- Required to stage content prior to maintenance windows
What This Article Does Not Cover
These topics are covered in official vendor documentation and are referenced in the RTFM section.
To keep scope clear:
- Initial VCF deployment workflows
- SDDC Manager installation
- Detailed network or PKI design
Common Prerequisites (Applies to All Platforms)
Regardless of platform or tooling, several prerequisites must be satisfied to successfully build and maintain an offline depot for VMware Cloud Foundation.
Authentication and Entitlement
Authentication failures often surface as partial or empty depots rather than explicit errors.
- Valid Broadcom/VMware entitlement is required
- Authentication method depends on tooling and environment
- Token or credential validity directly impacts metadata retrieval
Storage Capacity and Layout
Plan capacity with growth in mind; depots are rarely static.
- Sufficient disk capacity must be provisioned in advance
- Bundle content can be large and version-dependent
- Filesystem performance impacts download and validation time
Network and Connectivity Assumptions
These connectivity paths do not need to coexist on the same system.
- Outbound connectivity is required from the system populating the depot
- Inbound access is required from SDDC Manager to the completed depot
- Proxy configuration may be necessary in restricted environments
Time, Certificates, and Trust
Certificate and time drift issues commonly manifest as download or validation errors.
- Accurate system time is required
- Certificate validation is enforced where HTTPS is used
- Trust stores must align with platform defaults
Version Awareness
Always validate tooling expectations against the target VCF version.
- Tool behavior varies by VCF version
- Legacy commands may still be required for VCF 5.x
- Mixing assumptions across versions leads to subtle failures
Platform-Specific Implementation Notes
The following sections document platform-specific considerations when hosting or populating an offline depot. Only deltas from the common prerequisites are called out.
Photon OS
Photon OS is commonly used due to proximity with VMware appliances and predictable defaults.
- Minimal base installs may require additional packages
- Directory paths and permissions align with appliance conventions
- Tooling is typically executed as root or via elevated privileges
RHEL-Compatible Distributions
SELinux-related issues often surface as silent access failures rather than explicit errors.
- Additional packages may be required depending on minimal installs
- SELinux can impact file access and network behavior if not accounted for
- Service management and permissions follow standard systemd patterns
Windows
Windows remains viable for depot population, but is less commonly used for long-term hosting.
- Tooling is executed from a user context rather than a service model
- Path handling and filesystem layout differ from Linux-based platforms
- Automation and scheduling require additional consideration
For more information on this topic, refer to this post by Scott Bell: Building an VCF Offline Depot in Windows using IIS.
VCF Download Tool – Primary Workflow
The VCF Download Tool is the current, supported mechanism for acquiring VMware Cloud Foundation artifacts and populating an offline depot.
Where supported, this tool should be used in preference to legacy utilities.
General Workflow Model
Specific commands and flags are documented in official vendor guidance and are not duplicated here.
At a high level, the workflow consists of:
- Authenticating with valid entitlements
- Defining a local depot location
- Retrieving metadata describing available bundles
- Downloading selected artifacts into the depot
- Making the completed depot available to SDDC Manager
Metadata-Driven Behavior
Successful depot population depends as much on metadata integrity as on artifact completeness.
- Bundle availability is determined by retrieved metadata
- Metadata must remain consistent with downloaded artifacts
- Partial or stale metadata commonly results in validation failures
Supported Usage Patterns
Operators should treat the depot as a managed asset, not a one-time artifact.
The VCF Download Tool supports:
- Initial depot population
- Incremental updates as new bundles are released
- Reuse of an existing depot across maintenance cycles
Behavioral Differences from Legacy Tooling
These differences are discussed explicitly in the legacy section that follows.
Compared to earlier utilities:
- Tooling is more tightly coupled to VCF releases
- Authentication mechanisms have evolved
- Some legacy command patterns are no longer required or supported
Legacy Commands for VCF 5.x (Still Valid)
Customers operating VMware Cloud Foundation 5.x environments may still require legacy command patterns originally introduced with the Bundle Transfer Utility.
While the utility itself is deprecated, certain commands and workflows remain valid and functional when interacting with VCF 5.x lifecycle components.
Why Legacy Commands Still Matter
As a result, newer tools may still rely on legacy-compatible command paths to service VCF 5.x environments.
- VCF 5.x lifecycle components expect specific metadata formats
- Some newer tooling behaviors were introduced after VCF 5.x release
- Field environments often cannot be upgraded in lockstep with tooling
Supported-but-Bounded Usage
Using legacy commands outside these boundaries introduces risk without benefit.
Legacy commands should be used only when:
- Target environment is confirmed to be VCF 5.x
- Vendor documentation explicitly references legacy behavior
- Newer workflows are known to be incompatible
Coexistence with Newer Tooling
Version-awareness is more important than tool naming.
- Legacy commands may execute within newer tools
- Command availability does not imply long-term support
- Operators must validate behavior against the target VCF version
What Is Not Recommended
Legacy does not mean broken — but it does mean constrained.
- Introducing legacy workflows into new VCF deployments
- Assuming parity between legacy and current metadata models
- Treating deprecated utilities as interchangeable with supported tools
Coexistence Scenarios
Many environments operate in a transitional state, where newer tooling is used to support older VMware Cloud Foundation deployments. Understanding how these scenarios behave helps avoid false assumptions and operational dead ends.
New Tooling Supporting Older VCF Versions
Tooling compatibility is governed by the target VCF version, not the execution platform.
- Newer tools may still interact with VCF 5.x environments
- Legacy-compatible command paths may be required
- Success depends on metadata and version alignment, not tool name
Mixed Documentation in the Field
Operators should validate documentation context before execution.
- Vendor documentation may reference deprecated utilities
- Customer runbooks often lag behind tooling changes
- Scripts and automation may embed legacy assumptions
Incremental Transition States
These states are normal and should be managed intentionally, not avoided.
Common transitional patterns include:
- Using the VCF Download Tool with legacy command syntax
- Maintaining an existing offline depot created with older tooling
- Gradually migrating depot workflows during upgrade cycles
Failure Patterns in Coexistence Scenarios
Most failures are deterministic once version expectations are understood.
Coexistence issues commonly arise from:
- Metadata version mismatches
- Partial depot reuse across VCF versions
- Assuming forward compatibility where none exists
Operational Tips and Pitfalls
Even when following supported workflows, offline depot operations can fail in ways that are non-obvious. The following items reflect common issues observed in operational environments.
Partial Downloads and Silent Failures
Always validate depot completeness before consuming it.
- Downloads may appear successful while artifacts are incomplete
- Metadata retrieval can succeed even when artifact downloads fail
- Subsequent validation failures often point back to earlier interruptions
Disk Exhaustion and Filesystem Constraints
Treat storage planning as an ongoing activity, not a one-time task.
- Depot growth is cumulative over time
- Filesystem limits may be reached unexpectedly
- Cleanup without understanding metadata dependencies can corrupt the depot
Authentication and Token Expiration
Authentication issues frequently masquerade as tooling bugs.
- Authentication failures are not always explicit
- Expired or invalid tokens may result in empty metadata
- Re-authentication is often required between long-running operations
Metadata Drift and Reuse Risks
Metadata integrity is foundational to depot usability.
- Reusing depots across versions introduces risk
- Stale metadata may reference unavailable artifacts
- Manual metadata manipulation is strongly discouraged
Environmental Assumptions
Environmental changes should be assumed unless proven otherwise.
- Proxy, firewall, or DNS changes can break previously working workflows
- Time drift impacts certificate validation
- Platform updates may alter default trust stores
Verification and Validation
After populating an offline depot, verification should be performed before the depot is introduced into an active VMware Cloud Foundation workflow.
Validation confirms both content completeness and compatibility with the target VCF environment.
Depot Integrity Checks
Structural validation is the first line of defense against subtle failures.
- Confirm expected directory structure exists
- Verify bundle files are present and readable
- Ensure metadata files are complete and accessible
Metadata and Version Alignment
Version mismatch issues often surface late unless checked early.
- Metadata must align with the target VCF version
- Bundle versions should match intended lifecycle operations
- Mixing metadata across VCF versions is not supported
Connectivity and Access Validation
Successful access from the host system does not guarantee SDDC Manager access.
- Confirm SDDC Manager can reach the depot
- Validate protocol and certificate trust where applicable
- Verify permissions from the consuming system’s perspective
Dry-Run and Pre-Check Behavior
Validation failures are cheaper before change windows begin.
- Where supported, use validation or pre-check operations
- Avoid introducing unvalidated depots during maintenance windows
- Treat failed validation as a signal to revisit prerequisites
Closing Notes
Offline depot workflows for VMware Cloud Foundation continue to evolve as tooling and platform expectations change.
This article intentionally focuses on concepts, boundaries, and operational behavior rather than duplicating vendor procedures. Official documentation remains the authoritative source for supported commands and syntax.
Customers operating VCF 5.x environments should remain mindful of legacy requirements, while planning for eventual alignment with current tooling models.
Treat offline depots as managed infrastructure components, not one-time artifacts. Doing so reduces operational risk and simplifies future transitions.
Leave a Reply