vmware-tanzu
✨ Ensure NICs are connected / start connected
What does this PR do, and why is it needed?
This patch adds support for VM Op ensuring NICs are always connected and start connected for VMs that are not paused either by an Admin or DevOps user.
Which issue(s) is/are addressed by this PR? (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes NA
Are there any special notes for your reviewer:
@bryanv, please note that I ensured all the actual meat and potatoes logic is in the new resize location.
Please add a release note if necessary:
Ensure NICs are connected for VMs not paused by admin or DevOps users.
This will change the behavior of when using GOSC in that the VM will boot with the NICs already connected, instead of that not happening until customization is complete. IDK if that's a necessarily a breaking change though.
This will change the behavior of when using GOSC in that the VM will boot with the NICs already connected, instead of that not happening until customization is complete. IDK if that's a necessarily a breaking change though.
cc @PengpengSun
This will change the behavior of when using GOSC in that the VM will boot with the NICs already connected, instead of that not happening until customization is complete. IDK if that's a necessarily a breaking change though.
cc @PengpengSun
Agree with Byran, please do not re-connect NICs before customization finishes in guest. When customizing network, connected NICs will create conflicts. If GOSC happens, GOSC will handle NICs re-connection.
This will change the behavior of when using GOSC in that the VM will boot with the NICs already connected, instead of that not happening until customization is complete. IDK if that's a necessarily a breaking change though.
cc @PengpengSun
Agree with Byran, please do not re-connect NICs before customization finishes in guest. When customizing network, connected NICs will create conflicts. If GOSC happens, GOSC will handle NICs re-connection.
Hmmm. This is problematic. Ideally VM Operator should try to ensure the NICs are in the connected state. We should figure out how to do this even if GOSC is running or has run. Likely I'll do it by first checking the current status of a possible customization.
This will change the behavior of when using GOSC in that the VM will boot with the NICs already connected, instead of that not happening until customization is complete. IDK if that's a necessarily a breaking change though.
cc @PengpengSun
Agree with Byran, please do not re-connect NICs before customization finishes in guest. When customizing network, connected NICs will create conflicts. If GOSC happens, GOSC will handle NICs re-connection.
Hmmm. This is problematic. Ideally VM Operator should try to ensure the NICs are in the connected state. We should figure out how to do this even if GOSC is running or has run. Likely I'll do it by first checking the current status of a possible customization.
GOSC won't re-connect NICs only if something wrong happened, at this point, even re-connect NICs by VM Operator, the status of the VM is unpredictable(network might/might not work). And the connection status of the template/base vm needs to be considered too, if it's disconnected originally, GOSC will not re-connect NICs either.
If VM Operator wants to check customization status, this vAPI can be used. IMHO, no need re-connect NICs when customization fails, but VM Operator could have a different story.