Heads Up - New image identifier required by VM Service in vSphere 8.0 Update 2

I have been a huge fan of the VM Service capability, which has been an integral part of vSphere with Tanzu since its inception with the release of vSphere 7.0 Update 2. The VM Service had another major update last year that enabled further customization of workloads with the Sphere 8.0 release. What makes the latest update so exciting for vSphere with Tanzu users is that in vSphere 8.0 Update 2, the VM Service now officially supports deploying Microsoft Windows VMs and can also create VMs using all the rich VM configuration options that the vSphere platform supports!

I just got to try out the new VM Service feature yesterday and deployed a Windows OVF that I had built almost a year ago, which I have waiting for this feature to finally ship! 😀

I typically save my VM Service YAML manifest files so that I can easily reuse them but after performing the kubectl apply, I noticed nothing was being deployed and when I went to retrieve more details by running:

kubectl get vm -o yaml

I noticed the following error message:

message: 'Failed to get the VM''s image: windows-desktop-10'

I was pretty confused by the error, especially since I have used this exact same YAML manifest to deploy this VM in the past and more importantly, the label IS the name of my VM Image within my VM Service Content Library or so I thought ...

By using the following command:

kubectl get vmimage

I was able to check my associated VM Service Content Library and I had noticed the Name column now show these vmi-* labels rather than the VM labels that I had seen in the past. I had also noticed there is now a new column called Image Name which actually contains the friendly VM labels.

I decided to update the imageName property from "windows-desktop-10"

apiVersion: vmoperator.vmware.com/v1alpha1
kind: VirtualMachine
metadata:
  name: win-desk-10-01
  labels:
    app: win-desk-10-01
spec:
  imageName: windows-desktop-10
  className: best-effort-medium
  powerState: poweredOn
  storageClass: vsan-default-storage-policy
  networkInterfaces:
  - networkType: vsphere-distributed
    networkName: workload-1
  vmMetadata:
    configMapName: win-desk-10-01
    transport: CloudInit
---
apiVersion: v1
kind: ConfigMap
metadata:
    name: win-desk-10-01
data:
  user-data: "#cloud-config\nwrite_files:\n- encoding: gz+b64\n  content: H4sIAA6K1GIAA/NIzcnJV0grys9VCM/MyclMzPVJzNVLzs/lAgD/QoszGgAAAA==\n  path: C:\\vm-service-message.txt\n"

to "vmi-9d7f9aa2271cf8ec1"

apiVersion: vmoperator.vmware.com/v1alpha1
kind: VirtualMachine
metadata:
  name: win-desk-10-01
  labels:
    app: win-desk-10-01
spec:
  imageName: vmi-9d7f9aa2271cf8ec1
  className: best-effort-medium
  powerState: poweredOn
  storageClass: vsan-default-storage-policy
  networkInterfaces:
  - networkType: vsphere-distributed
    networkName: workload-1
  vmMetadata:
    configMapName: win-desk-10-01
    transport: CloudInit
---
apiVersion: v1
kind: ConfigMap
metadata:
    name: win-desk-10-01
data:
  user-data: "#cloud-config\nwrite_files:\n- encoding: gz+b64\n  content: H4sIAA6K1GIAA/NIzcnJV0grys9VCM/MyclMzPVJzNVLzs/lAgD/QoszGgAAAA==\n  path: C:\\vm-service-message.txt\n"

and re-apply the deployment and I immediately saw the VM being cloned from my VM Service Content Library!

In speaking with Engineering, I found out this was indeed a change in behavior for vSphere 8.0 Update 2 because due to potential naming conflicts, this change ensures that each VM Image has a unique ID that can then be referenced in the YAML manifest. I have asked the team to include a note in both the documentation and release notes about this change in behavior since this will likely affect anyone who has used the VM Service in the past.

The team is also working to re-enable the human friendly label, assuming there are no conflicts in a future update. For now, there is an implication for those planning to upgrade to vSphere 8.0 Update 2 that you will need to use the vmi-* ID rather than human friendly label that you may have saved in your YAML files.

Lastly, one improvement that I really did like with vSphere 8.0 Update 2 is we now have an easy way of associating the VM Service Content Library for a given VM Image. In the past, when you list out the VM Service Content Library or any Content Library used by vSphere with Tanzu, you would get a UUID that you could not easily figure out which vSphere Content Library it belonged to.

You can now use:

kubectl get contentlibrary

and there is a new field called VSPHERENAME which provides the friendly label that is seen in the vSphere UI that makes it easy to figure out which vSphere Content Library is providing the VM Image!