search

hashicorp / packer-plugin-vsphere

Packer plugin for VMware vSphere Builder
https://www.packer.io/docs/builders/vsphere
Mozilla Public License 2.0
94 stars 91 forks source link

Ability to use the same name as vm name for vm-templates in vSphere Content Library #11

Open ghost opened 3 years ago

ghost commented 3 years ago

This issue was originally opened by @jdotsmith as hashicorp/packer#9967. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

Please search the existing issues for relevant feature requests, and use the reaction feature (https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to add upvotes to pre-existing requests.

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

Currently the vsphere-iso module content library configuration allows for vmware templates to be uploaded to the content library when the OVF flag is set to false. However, it doesn't allow for the same name as the VM name and appends a timestamp unless the name flag is specified. The OVF flag allows for the same name and overwrites the existing content library file.

I would like the ability to have the vm name be the same as the vm template name that gets uploaded to content library.

Here's the error message: 


1 error(s) occurred:

* the content library destination name must be different from the VM name

Use Case(s)

I have an automated packer process (ADO Build) that runs every month so Ill be getting a bunch of vm_name + timestamps vm-templates and would love to overwrite them.

Im using the vmware_content_deploy_template with ansible and that only allows the content-library type to be vm-template and not OVF.

Potential configuration

Potential References

Arderos commented 7 months ago

+1 For this. Probably the easiest way to do it would be to delete the previous CL item and then upload a new one

das-ich commented 7 months ago

+1 For this,

ykezlya commented 7 months ago

+1

tenthirtyam commented 7 months ago

Community Note

patschi commented 3 months ago

Stumbled about the same too. While I think deleting prior uploading the new copy might work (and be the easier approach), possibly an alternative might be by 1) create template, 2) upload template under temporary name like "Ubuntu2204-new", 3) delete original template "Ubuntu2204" and then rename "Ubuntu2204-new" to "Ubuntu2204".

So any scripts using the VM template based on its name have a smaller timeframe where it is possible to fail.

tenthirtyam commented 3 months ago

@patschi It's a valid concern - one of the values of using OVF templates with automation like Aria Automation is not needing to remap after generating a new image. One potential concern with this approach would be that the on-disk path would not have a matching name due to a renaming which could lead to confusion on the file system.

What about instead including a check for the target name (and folder path) in the Prepare() to stop the build early unless an overwrite option is true?

patschi commented 3 months ago

@tenthirtyam I'd expect ESXi to handle cases when the same name is used for a VM - like, when you create a VM with a name already present on the datastore, it will add "_1" suffix automatically.

IMHO, I don't think any automation should be based on the datastore file path anyway and not consider it reliable. Taking vSAN as an example - every new VM/template will have a new namespace folder with unique UUID.

I think checking for the existence of the VM name before starting build process might safe time and resources and is a good idea, but is not really addressing this PR.