You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
Hey there, thanks for reaching out.
When I implemented the feature, vsphere didn't allow us to use the same name because in the meantime of creating the VM template, which will be imported to the Content Library, the origin VM is cloned into a new VM and therefore there was a conflict with the names. This is done by their API when using the provided method for cloning VM into VM templates in the Content Library. I'm almost sure using the same name is not possible, but I'll definitely give it a look and try to figure any possible workaround for this.
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
ghost
locked as resolved and limited conversation to collaborators
May 16, 2021
This issue was closed.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
modulecontent 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 thename
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:
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 bevm-template
and not OVF.Potential configuration
Potential References
The text was updated successfully, but these errors were encountered: