Broadcom is about to release a brand-new instructor-led course: What's New in VMware Cloud Foundation [v9.1]. I've had the chance to review the course materials, and this is not your typical two-day delta class — it's a full five-day, deeply technical program covering everything that changed between VCF 9.0 and 9.1, backed by no fewer than 36 hands-on and simulation labs. The course will be available shortly, and I'll be scheduling delivery dates soon. Here's what you can expect.

Course at a Glance

The curriculum is built around eleven modules that follow the full VCF stack: installer and deployment, operations and licensing, compute, storage, networking, fleet and lifecycle management, upgrade pathways, automation, vSphere Kubernetes Service (VKS), and VCF Operations. Roughly a third of classroom time is spent in the lab environment, working directly against a live VCF 9.1 fleet. The course targets system administrators, solution engineers, consultants, architects, and support personnel with working knowledge of VCF, vSphere, NSX, and vSAN. It also fits neatly into the path towards the upcoming VCP-VCF 9.1 Administrator certification.

Day 1 — Installer, Operations Console, Compute, and Storage

The week opens with the VCF Installer enhancements: the updated component architecture, deployment and import workflows for existing environments, custom and dual-stack (IPv4/IPv6) network configurations, and the new handling of management services and credentials. Lab 1 walks through a complete VCF deployment with the VCF Installer.

Next up is the redesigned VCF Operations console, including a side-by-side comparison of VCF 9.0 versus 9.1 licensing and the options for connected and air-gapped deployments. The compute module then digs into the vCenter, ESX, and vSphere resource enhancements — think memory tiering, CPU optimizations, virtual machine improvements, certificate management improvements, and the latest API additions.

Day 1 closes with storage, and there's a lot to cover:

• vSAN ESA Auto-RAID — automatic RAID-level selection and reconfiguration, validated in a dedicated lab where you add hosts and watch component placement change.
• vSAN data services, file service updates, and stretched cluster enhancements.
• vSAN disaggregated storage — deploying vSAN compute clusters that consume remote vSAN capacity, including converting one to a stretched compute cluster.

Day 2 — Data Protection and a Full Day of NSX Networking

Day 2 starts with vSAN protection and recovery: tag-based protection groups, and a lab where you deliberately delete a VM and recover it. Then the course shifts to what is arguably the most technical part of the week: the VCF networking module.

This module covers the new VPC consumption model directly from vCenter, platform and management enhancements, and a deep treatment of both Distributed and Centralized Transit Gateways. The labs are where it gets serious:

• Deploying a VNA cluster through vCenter.
• Configuring and validating VLAN extension to VPC subnets, including distributed VLAN extension connections in NSX projects and VLAN port groups on the VDS.
• Deploying a VCF Route Controller cluster and verifying its status.
• Configuring EVPN VXLAN support for the Distributed Transit Gateway — MP-BGP on the route controller, distributed VXLAN connections, and end-to-end validation via both UI and CLI.
• Advanced Centralized Transit Gateway connectivity: additional external connections per tenant project, provider SNAT, and advertising private Transit Gateway IP blocks.

Day 3 — Networking Wrap-Up, Fleet Management, and Upgrade Pathways

After a lab on dynamic BGP peering (static-to-dynamic and dynamic-to-static neighbor configurations) and a lesson on VPC service enhancements, the focus moves to fleet and lifecycle management. Highlights include creating workload domains without a vSphere cluster, the VCF management services architecture and its high-availability mechanisms, out-of-band validation enhancements, identity and access improvements, and cluster-level configuration drift detection. A fleet management lab covers password policies, bulk certificate signing requests, VCF roles, and the identity broker.

The upgrade pathways module is one I expect a lot of interest in: it maps out every supported route to 9.1 — upgrading existing VCF environments, moving from plain vSphere into VCF, and converting VVF deployments to full VCF.

Days 3–4 — VCF Automation

The automation module spans two days and reflects how much this layer has grown. Topics include scalability enhancements, organization management, multi-supervisor region quotas, networking and blueprint enhancements, the container service, and the Cloud Director migration path. The lab list speaks for itself:

• Creating region quotas backed by multiple Supervisors and validating multi-supervisor namespace behavior.
• Project content libraries with image promotion between projects.
• Infrastructure policies built on vSphere tags and compute policies.
• Third-party integrations: Infoblox for IPAM and Avi Load Balancer for organization networks.
• Namespace self-service via CLI, deploying namespaces from blueprints, and — new in 9.1 — capturing an existing namespace as a reusable blueprint.
• Deploying and scaling containers with the Container Service, verified down to the pod level in vCenter.

Days 4–5 — vSphere Kubernetes Service (VKS)

The VKS module covers the enhanced Supervisor architecture with multi-cluster zones, DTGW support for the Supervisor, and VM Service enhancements. The multi-network capabilities get particular attention: selecting your CNI (for example Calico) through the bootstrapAddons ClusterClass variable, building multi-NIC cluster nodes with parent/child subnets and VLAN extension bindings, and creating multi-NIC pods using IPPool and NetworkAttachmentDefinition custom resources with Antrea feature gates.

Node customization is also new: labs cover enabling AppArmor profiles and custom TuneD profiles on VKS cluster nodes, and there's a lesson on building your own RHEL-9 VKr images with the VCF CLI using Image Baker, plus supported upgrade paths and guardrails.

Day 5 — VCF Operations

The final module ties it all together on the operations side. VCF Health and Findings give you proactive issue detection across the private cloud. The new Real-Time Metrics component — deployed in its own lab — feeds custom dashboards with PromQL viewer, Object List, and Top-N widgets. Log Management gets a dedicated architecture lesson and a hands-on lab covering log collection, event creation, and query-based analysis. The course wraps up with automated VKS cluster monitoring, capacity optimization (rightsizing exclusions and storage-aware workload optimization), memory tiering recommendations, cost and price management, and VCF security and compliance.

Prerequisites and Certification

You'll want working experience with VCF, vSphere, NSX, and vSAN before attending — this class moves fast and assumes you know the 9.0 platform. The course aligns with the VCP-VCF 9.1 Administrator certification, which is expected to be released alongside the updated curriculum.

With VCF 9.1, Broadcom introduced Zero Touch Provisioning (ZTP), a capability that takes a bare-metal server at a remote edge site from power-on to a fully registered host in a vSphere cluster, without an engineer on site. No manual configuration, no PXE infrastructure, no USB sticks. Just a network cable and a power button. While testing this in my lab, I ran into a problem that I suspect others will hit as well: my ESX installation consistently stalled at "Reading installation script" whenever the management network lived on a tagged VLAN. Here is what happened, why it happens, and the one-line fix that solved it.

How ZTP network boot works

Starting with VCF 9.1, the management of UEFI HTTPS Boot moves from Auto Deploy to Zero Touch Provisioning. Instead of the classic PXE chain with TFTP and iPXE, ZTP uses a UEFI HTTPS boot URL served straight from vCenter. Three components make this work. The Boot Routing Service (BRS) exposes a single vCenter-level boot URL (https://<vcenter>/vmw/brs/vbmx64.efi) that applies to every physical machine in your environment. The new first-stage bootloader, vSphere Boot Manager (vBM), replaces iPXE and submits hardware identifiers such as UUID, MAC address, and SMBIOS data to BRS. BRS evaluates those identifiers against the Auto Deploy rule engine and redirects the host to a cluster-specific boot URL served by the Network Boot Service (NBS), which hosts the ESX boot images on the vCenter filesystem under /vmw/nbs/clusters/<cluster-id>/.

You can watch this two-stage pipeline on the console of the booting host. After the BRS redirect, the host pulls its boot configuration from the NBS cluster URL:

Loading https://10.1.1.11/vmw/nbs/clusters/domain-c1358/529f948b-99e8-626c-91f5-54819ccaa5b9/image-0/boot.cfg

So far, so good. The installer boots, the modules load, and the automated installation kicks off. In my setup the host is connected to a trunk port, the management network is tagged VLAN 100, and IP addresses on that network are handed out by a DHCP server.

The problem

The installation ran fine right up to the point where ESX was installed and the installer needed to fetch and process the installation script. There it hung, indefinitely, on:

Reading installation script

The reason turned out to be simple once I understood what the installer was doing. When the ESX installer brings up its management interface, it creates vmk0 without a VLAN ID. That is perfectly fine when the management network is untagged or carried as the native VLAN on the switch port. But on a trunk port with a tagged management VLAN, an untagged vmk0 is talking into the void: its DHCP requests never reach the DHCP server on VLAN 100, the host never gets an IP address, and the installer can never retrieve the installation script it needs to continue. Hence the eternal "Reading installation script".

The fix: add vlanid to boot.cfg

The ESX installer supports a boot option called vlanid, which tells it to tag the installer network interface (and consequently vmk0) with a specific VLAN ID. The trick is getting that option into the ZTP boot flow, and the boot screen itself points you to the right place: the boot.cfg file that NBS serves to the host.

The cluster-specific Network Boot Folders live on the vCenter Server Appliance filesystem, matching the URL you see on the console. Take the path from the boot screen, in my case:

/vmw/nbs/clusters/domain-c1358/529f948b-99e8-626c-91f5-54819ccaa5b9/image-0/boot.cfg

SSH into the vCenter appliance, locate that boot.cfg, and open it. Inside you will find the kernelopt line that carries the boot options for the installer. All you need to do is append the vlanid option directly after weasel (the ESX installer):

kernelopt=runweasel vlanid=100

Save the file and boot the edge host again. This time the installer tags its network interface with VLAN 100, vmk0 comes up on the correct management VLAN, the DHCP server on the management network hands out an IP address, and the installation script is fetched and executed without any drama. The host completed the rest of the ZTP workflow and registered itself in the vSphere cluster exactly as advertised: zero on-site interaction.

Wrapping up

Zero Touch Provisioning in VCF 9.1 is an impressive piece of automation: a single UEFI HTTPS boot URL, no PXE or TFTP infrastructure, and hardware-aware routing to the right cluster image via BRS and NBS. But the current workflow assumes an untagged management network during the installation phase. If your edge sites use a tagged management VLAN with DHCP, as many production networks do, the installer will stall at "Reading installation script" because vmk0 comes up without a VLAN ID and never obtains an address.

The workaround is a single boot option: edit the boot.cfg that NBS serves for your cluster image and add vlanid=<your management VLAN> to the kernelopt line, right after weasel. It would be great to see this exposed as a first-class setting in the ZTP configuration in a future release, so the installer inherits the management VLAN from the cluster network profile automatically. Until then, this one-liner gets your tagged edge sites provisioned hands-free.