⚠️ webhook: prevent changes to an already set VSphereVM.spec.biosUUID

[chrischdi]

What this PR does / why we need it:

This PR improves the validation for VSphereVM objects by adjusting the webhook to:

• only allow changes to VSphereVM.spec.biosUUID if it is not already set
• prevent updates which try to change the biosUUID.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):

Identified during discussions around #2102

[zhanggbj]

@chrischdi
Code change looks good to me, only got a question here, is there any possibility that user may need to update the biosUUID, for instance, after the VM is moved to another host maybe due to disaster recovery, and the VM will get a new biosUUID as described https://docs.vmware.com/en/VMware-Workstation-Pro/17/com.vmware.ws.using.doc/GUID-533B2C4F-7BD5-41EB-8392-2B9FE687AE50.html#GUID-533B2C4F-7BD5-41EB-8392-2B9FE687AE50

[sbueringer]

@chrischdi Code change looks good to me, only got a question here, is there any possibility that user may need to update the biosUUID, for instance, after the VM is moved to another host maybe due to disaster recovery, and the VM will get a new biosUUID as described docs.vmware.com/en/VMware-Workstation-Pro/17/com.vmware.ws.using.doc/GUID-533B2C4F-7BD5-41EB-8392-2B9FE687AE50.html#GUID-533B2C4F-7BD5-41EB-8392-2B9FE687AE50

Good point. We were thinking that nobody should mess with this field when discussing it.

@randomvariable @srm09 @yastij ?

[chrischdi]

@chrischdi Code change looks good to me, only got a question here, is there any possibility that user may need to update the biosUUID, for instance, after the VM is moved to another host maybe due to disaster recovery, and the VM will get a new biosUUID as described docs.vmware.com/en/VMware-Workstation-Pro/17/com.vmware.ws.using.doc/GUID-533B2C4F-7BD5-41EB-8392-2B9FE687AE50.html#GUID-533B2C4F-7BD5-41EB-8392-2B9FE687AE50

Good point. We were thinking that nobody should mess with this field when discussing it.

@randomvariable @srm09 @yastij ?

The linked doc is for vmware workstation, which is not the target platform. Also it states

When you power on a virtual machine that was moved or copied to a new location, you are prompted to specify whether you moved or copied the virtual machine. If you indicate that you copied the virtual machine, the virtual machine receives a new UUID.

So this only applies if explicitly "copied" got selected.

However in the vCenter / esx case: Moving to another host does not change the UUID (otherwise e.g. vMotion would be broken). So from my perspective the uuid should not get changed, also not in disaster recovery (except if you have to recreate the vmx file, because the biosUUID is stored there).

/hold

To wait for other opinions on this.

[sbueringer]

Thx for the additional context. Sounds fine to me

Probably good enough to for now play it safe and then potentially change the webhook if new use cases emerge (assuming we are not already aware of some)

[sbueringer]

/lgtm
/approve

Let's keep the hold a bit for the discussion

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: e0635c9509dd1de883fb145d891692b498db4241

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbueringer

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [sbueringer]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[randomvariable]

For all intent purposes, a new UUID constitutes a new machine identity, and we should treat that as a new machine. I'm therefore OK with this change.

[randomvariable]

/unhold