-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vsphere-iso
: Add support for vApp properties
#44
Comments
Any ETA on this feature will help my planning. Many Thanks |
In the need of this feature. Setting vApps like this:
doesn't work for me. |
vsphere-iso
: Add support for vApp properties
Any update regarding this feature? |
Also very interested in an update for this feature |
Any updates regarding this feature? |
I'm also very interested in this feature. |
I'll be targeting this enhancement for the v1.5.0 release milestone. Please note that this work is currently done in my personal time. Ryan Johnson |
This issue was originally opened by @jpbuecken as hashicorp/packer#10319. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.
Community Note
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.
Description
In vSphere, you can enable vApp Options of a VM via Configure -> vApp Options -> Edit
After that, you can add Properties to the vApp / VM (same window)
This should be possible via the vsphere-iso builder.
Use Case(s)
With this, you can create a VM with vApp Properties.
Use Case 1: You can add a public-keys property. Configure your Suse autoyast / Redhat/Ubuntu kickstart / Ubuntu preseed to make use of the value during boot (write your own script or make use of cloud-init).
After you have done this, your new vm can be used in turn as a source for vsphere-clone builder.
Since vsphere-clone supports temporary keys for the public-keys property, there is no need to store a password or public-key file in your source image.
I see this as an absolut security win.
Use Case 2: Similar to vsphere-clone, vsphere-iso may use the public-keys property itself:
Now the same argument as above applies, there is no need to store a hardcoded password or key files inside your vm before you connect with vsphere-iso. E.g. we have the policy to recreate key files regularly. If they are created and removed "on the fly" temporary, this policy is easily fulfilled.
Potential configuration
Potential References
https://www.packer.io/docs/builders/vmware/vsphere-clone#ssh (search for public-keys and vapp on the side)
The text was updated successfully, but these errors were encountered: