OSImages from Content Library Not Appearing on Supervisor

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

• When running kubectl get osimages on a vSphere Supervisor,  TKR OSImages are missing from the list that are sourced from a subscribed Content Library. .
• The image is clearly visible and marked as "Ready" in the vCenter Content Library.
• The image was previously modified (e.g., converted to a VM to increase disk size) before being added back to the Content Library.
• Running kubectl get clustervirtualmachineimage shows the image name, but fields such as IMAGE VERSION, OS NAME, and OS VERSION are empty.

Environment

Product: VMware vSphere Kubernetes Service (VKS) / Tanzu Kubernetes Grid (TKG)

Version: vSphere 8.x / 9.x

Cause

The issue is caused by the loss of vApp properties (vAppConfig) within the OVF descriptor.

VKS requires specific metadata embedded in the OVF to identify it as a valid Kubernetes OSImage. When an image is converted into a VM or VM template (e.g., to manually resize the virtual disk) and then exported back to a Content Library, the vApp properties are stripped. Without these properties, the Supervisor's registry controller cannot recognize the item as a valid node template

Resolution

To resolve this, you must re-import a valid image and use supported methods for disk expansion.

1. Verify Image Integrity

Check the files associated with the Content Library item in the vSphere Client.

• If you see a .nvram file (e.g., image_name.nvram), this confirms the image was exported from a VM and is missing the required vApp metadata.
• The OVF file size will often be significantly smaller than the original manufacturer OVF because the metadata has been removed.

2. Re-import the Original OVF

1. Delete the modified/problematic item from the Content Library.
2. Download the original, unmodified OVF/OVA.
3. Import the OVF directly into the Content Library without performing any "Convert to VM" or "Export" workflows.

3. Use Supported Disk Expansion Methods

If your workloads require additional disk space (e.g., for security agents or logging), do not modify the base OS image disk. Instead, use one of the following:

• External Volume Mounts: Configure your Tanzu Kubernetes Cluster manifest to mount persistent volumes to specific node paths.
  • Persistent Volume Expansion for VKS Clusters
• Tanzu Image Builder: If a custom image is required, use the official Tanzu Image Builder (BYOI) process and use the disk_size extension variable to define the required size during the initial build. This ensures vApp properties are preserved.