#VMware vSphere Provider Release Notes

#Overview

This page tracks release notes for the Alauda Container Platform VMware vSphere Infrastructure Provider. The version number you see on the platform (for example, v1.0.17) refers to the packaging release of the vSphere provider, which bundles the Cluster API Provider vSphere (CAPV) controller image, the vSphere Cloud Provider Interface (CPI) image, the admission webhooks, and the Helm chart used to deploy them on the Alauda Container Platform.

For the current full capability list and installation steps, see VMware vSphere Provider Installation.

#v1.0.17

#New Features

• Self-built control plane VIP — VSphereCluster.spec.controlPlaneLoadBalancer selects the control plane endpoint mode. type: internal makes the provider install Alive (keepalived and IPVS) on the control-plane nodes through a ModuleInfo, inject a bootstrap VIP on the first kubeadm init node, hand the VIP over to Alive, and keep the workload cluster's kube-proxy IPVS settings aligned with it. type: external, and an absent field, keep the existing behavior. The field is accepted once and is frozen afterwards. The Self-built VIP requires ACP v4.4 or later, and is available only to clusters created with this release or later: an upgraded cluster keeps its external LoadBalancer and cannot adopt the VIP. The endpoint is chosen when the cluster is deployed and cannot be adjusted at runtime or during an upgrade. An upgraded cluster leaves the field unset, which already means an external LoadBalancer, and setting it on a running cluster is rejected. See Upgrading the Provider. See Control Plane Endpoint Modes.
• Ephemeral data disks — VSphereMachineConfigPool.spec.configs[].ephemeralDisks[] declares per-slot disks that are deleted with the VM and recreated empty on the replacement. They take no part in reclaim and never hold a slot release. The list is a creation-time layout: an upgraded cluster keeps its existing persistent disks, the upgrade moves none of them into ephemeralDisks[], and a slot that is InUse or Released accepts additions to either list but no removal or reshaping. See Choose persistent or ephemeral.
• Per-disk and per-slot pool status — VSphereMachineConfigPool now reports status.persistentDiskStatuses[] with a phase of Creating, Attached, Available, Reclaiming, Reclaimed, or Error, plus status.ephemeralDiskStatuses[] and the slot counters status.total, status.available, and status.allocated, which also appear as printer columns.
• Pool health conditions — The pool reports Ready, MembersValid, MembersUnique, SlotAvailable, and PersistentDisksReady alongside the existing ClusterRefReady and VCenterAvailable. SlotAvailable is deliberately excluded from the Ready summary, so a fully allocated pool still reports Ready=True.
• Bootstrap and endpoint conditions — BootstrapReady on VSphereVM and VSphereMachine distinguishes a missing or unreadable bootstrap Secret from invalid content, and KubeOvnAppReleaseReady and SelfBuiltLoadBalancerReady on VSphereCluster report those subsystems without gating status.ready.

#Enhancements

• Rollout rules enforced by admission — For a KubeadmControlPlane or MachineDeployment whose infrastructure template sets machineConfigPoolRef, maxSurge must be 0, KubeadmControlPlane.spec.replicas must be 3 or more, and MachineDeployment.spec.strategy.rollingUpdate.maxUnavailable must be 1 or more. These values were already required by the fixed-IP slot model; they are now checked before the object is accepted. See Check the manifests against the admission rules.
• Pool safety validation — Hostnames and primary IP addresses must be unique across the pools bound to one Cluster; a slot that is InUse or Released can no longer have its address, disk set, or disk geometry changed; and deleting a pool that still owns InUse slots is refused up front rather than leaving the object in Terminating.
• Pod log directory on the data disk — When a slot mounts a disk at /var/lib/containerd, /var/log/pods is relocated onto that disk. Existing machines are not retrofitted; the change is picked up when nodes are replaced.
• Deterministic persistent-disk matching — Disks are matched by VMDK path, then by SCSI unit number, rather than by capacity, and ownerMachineName and ownerMachineUID persist across VM replacement so a rolling upgrade reattaches the same disks.

#Fixed Issues

• VM status handling — VSphereMachine clears Ready while the backing VSphereVM, its providerID, or its network information is unavailable, and out-of-band power changes made in vCenter are now observed instead of being hidden.
• Slot-owner lookup errors — Errors while resolving the owner of a slot propagate instead of being swallowed, and slot validation covers network.additional entries and normalized guest mount paths.
• Security updates — Dependencies were updated to address reported CVEs.

#Breaking Changes

• A VM powered off in vCenter stays powered off. After a VM's first successful power-on, VSphereVM latches InitialPowerOnCompleted and the controller no longer forces it back on. PoweredOn=False propagates into VSphereVM.Ready and VSphereMachine.Ready. A replacement VM created by a rollout has an unset latch, so its first boot is unaffected.

#Deprecations

• VSphereMachineConfigPool.status.configStatuses[].reclaimStatus and spec.configs[].persistentDisks[].volumePath and .diskUUID are frozen in this release and scheduled for removal. Read status.persistentDiskStatuses[] instead. Existing pools need no manual edit: the controller folds the old records into status.persistentDiskStatuses[] on its first reconcile after the upgrade, carries an in-flight reclaim across, and clears reclaimStatus. See Upgrading the Provider. A phase: Reclaimed entry is a tombstone and must not be deleted by hand.

#Notes

• New management-cluster permissions — The provider chart grants read access to clustermodules, moduleconfigs, and moduleplugins, write access to moduleinfoes, read access to clusters in clusterregistry.k8s.io and platform.tkestack.io, and patch and update on kubeadmcontrolplanes. See Verify the installation.
• vCenter Custom Fields privilege — Required whenever a VSphereCluster or its CAPI Cluster carries a vsphere.cluster.x-k8s.io/* annotation. A missing privilege fails VM reconciliation rather than skipping the metadata write.

#v1.0.16 (2026-08-05)

#Enhancements

• ACP 4.4 system component repositories — The provider selects the Kube-OVN chart from the target Kube-OVN version, the CoreDNS image repository from the ACP version suffix in the CoreDNS tag, and the kube-proxy image repository from the Kubernetes version. Kube-OVN v4.4 and later uses acp/chart-kube-ovn, CoreDNS tags for ACP v4.4 and later use acp, and Kubernetes v1.35 and later uses acp/k8s for kube-proxy. Earlier targets keep their legacy repository paths.

#Fixed Issues

• Reliable component reconciliation during upgrades — The provider reacts to KubeadmControlPlane version and rollout changes, waits for the control-plane rollout before changing workload-cluster kube-proxy and CoreDNS resources, and passes the workload cluster's existing Registry pull credentials to managed system components. This keeps Kube-OVN, CoreDNS, and kube-proxy aligned with the selected ACP and Kubernetes versions.

#Notes

• External control plane LoadBalancer — This release does not deploy a Self-built VIP. Provision an external LoadBalancer by following Plan the Control Plane Endpoint.

For the provider-version-specific Kube-OVN upgrade sequence, see Upgrading Clusters on VMware vSphere.

#v1.0.15 (2026-07-09)

#Fixed Issues

• Reliable primary node address and identity — The vSphere cloud provider now honors the configured node IP when choosing a node address and resolves the provider ID from the VM's registered system UUID. This avoids incorrect node identity or address selection, especially for VMs with multiple NICs.

• More reliable Kube-OVN bootstrap — The provider waits for a valid control-plane node set before reconciling Kube-OVN, avoiding CNI reconciliation while the initial control plane is incomplete.

#v1.0.14 (2026-06-08)

#Notes

v1.0.14 is a re-tag of v1.0.13 at the same source revision. It contains no additional changes; see v1.0.13.

#v1.0.13 (2026-06-08)

#Fixed Issues

• Safer pool-managed persistent disk replacement — A machine-configuration pool slot is not reused while persistent disks from the previous VM are still attached. This prevents a replacement VM from racing the disk-detach operation.

• Standby Global Cluster reconciliation — vSphere provider resources can reconcile correctly on a standby Global Cluster, supporting the documented disaster recovery procedure.

#v1.0.12 (2026-05-25)

#Fixed Issues

• vSphere CPI can start during Kube-OVN bootstrap — The vSphere cloud provider is scheduled on control-plane nodes and tolerates their taints, allowing it to start before the cluster network is ready.

• Kube-OVN waits for the initial control plane — The provider defers Kube-OVN reconciliation until the number of ready control-plane nodes matches the intended control-plane replica count.

#v1.0.11 (2026-05-21)

#Fixed Issues

• Reduced unnecessary OVN reconciliation triggers — Upstream CAPV image bumped to a build that prevents OVN reconciliation from being repeatedly retriggered when no actual state change is required. Improves controller stability and reduces background load.

#v1.0.10 (2026-05-18)

#Enhancements

• Upstream CAPV image refresh — Provider chart now references a newer Alauda build of the upstream Cluster API Provider vSphere controller. No behavior change in this overlay release beyond the upstream image bump.

#v1.0.9 (2026-05-18)

#New Features

• OCI source and revision labels on container images — Built provider images include standard OCI source and revision labels for build traceability.

#Fixed Issues

• OVN integration and persistent disk handling — Upstream CAPV image bumped to a build that resolves OVN networking integration issues and persistent disk handling regressions reported on prior releases.

#v1.0.8 (2026-05-12)

#Fixed Issues

• capv-manager-role ClusterRole — Corrected the capv-manager-role ClusterRole definition that was missing required permissions for normal controller operation.

#v1.0.7 (2026-04-28)

#Fixed Issues

• Chart template regressions — Restored the v1beta1 contract label on CRDs and corrected an escaped Go template literal in the chart, fixing chart template regressions that prevented successful provider installation in certain configurations.

#v1.0.6 (2026-04-28)

#Enhancements

• CRD update — Provider CRDs refreshed to align with the latest schema.

#v1.0.5 (2026-04-16)

#Breaking Changes

• CRD rename: VSphereResourcePool → VSphereMachineConfigPool — The CRD that declares per-node-pool slot reservations and persistent configuration has been renamed from VSphereResourcePool to VSphereMachineConfigPool. Existing manifests must be updated to use the new resource type.

#v1.0.4 (2026-04-11)

#Enhancements

• VSphereResourcePool CRD update — Schema adjustments to the VSphereResourcePool CRD (subsequently renamed in v1.0.5; see above).

• Documentation — Provider README refreshed with project structure, components, CRDs, and configuration sections.

#v1.0.3 (2026-04-07)

#Fixed Issues

• CVE patches — Resolved multiple disclosed CVE issues in vendored dependencies.

#v1.0.2 (2026-04-07)

#Notes

v1.0.2 is a re-tag of v1.0.1 (same underlying commit). No additional changes beyond v1.0.1; see v1.0.1 for the release content.

#v1.0.1 (2026-04-07)

#New Features

• Secret-based encryption for CAPV deployment — The provider deployment can now consume an external Secret for encryption configuration, removing the previous requirement to bake encryption material into the deployment manifest directly.

#Enhancements

• VSphereResourcePool CRD update — Schema refresh on the VSphereResourcePool CRD. Note this CRD was later renamed to VSphereMachineConfigPool in v1.0.5.

• Updated CAPV deployment manifest — Provider deployment manifest aligned with the new CRD schema.

#v1.0.0 (2026-04-03)

#Overview

v1.0.0 is the initial release of the Alauda Container Platform VMware vSphere Infrastructure Provider, an Alauda-packaged distribution of the upstream Cluster API Provider vSphere (CAPV) for the Alauda Container Platform.

#Initial Capability Set

• Helm-chart packaging of CAPV controller and vSphere CPI — Bundles the upstream CAPV controller image and the vSphere Cloud Provider Interface (CPI) image, plus the Alauda Container Platform ModulePlugin definition required for platform-managed installation.

• CRD set — Ships the standard CAPV CRDs (VSphereCluster, VSphereClusterIdentity, VSphereMachine, VSphereMachineTemplate, VSphereVM, VSphereDeploymentZone, VSphereFailureDomain) plus the Alauda extension VSphereResourcePool (renamed to VSphereMachineConfigPool in v1.0.5).

• Platform-aligned installation flow — Installs through the Alauda Container Platform's standard provider installation flow, exposing chart values for upstream CAPV controller and CPI image overrides.