Packer: Packer 1.6.2 vsphere-iso "not a valid iso path"

Created on 29 Aug 2020  ·  11Comments  ·  Source: hashicorp/packer

Overview of the Issue

Starting with Packer 1.6.2 I am unable to build vSphere VMs because of new validation in builder/vsphere/driver/datastore.go. The validation requires that the datastore name be entirely comprised of "word" characters, but vSphere allows other characters. Does the regular expression need to care what characters are used inside the brackets?

Reproduction Steps

Have a datastore named something like "iso-storage" and then try to use it from "iso_paths" in your Packer json.

Packer version

Packer v1.6.2

Simplified Packer Buildfile

{
    "builders": [
        {
            "type": "vsphere-iso",

            // omitted standard details…

            "iso_paths": [
                "[ISO-StorageLun9] Linux/rhel-8.0-x86_64-dvd.iso"
            ]
        }
    ]
}

Operating system and Environment details

Packer is being run from Windows 10, and is connecting to vSphere 6.7.0.

Log Fragments and crash.log files

==> vsphere-iso: Mounting ISO images...
==> vsphere-iso: error mounting an image '[ISO-StorageLun9] Linux/rhel-8.0-x86_64-dvd.iso': [ISO-StorageLun9] Linux/rhel-8.0-x86_64-dvd.iso is not a valid iso path
==> vsphere-iso: Step "StepAddCDRom" failed
bug buildevsphere regression track-internal

Most helpful comment

That build works for me.

All 11 comments

Just ran into this issue aswell, pretty sure this is caused by this function: https://github.com/hashicorp/packer/pull/9801/files#diff-0d83d92f5308e8218641e962d4bc0ec0R191

Hey there, thanks for reporting! This is definitely a regression and I'll fix it as soon as possible.

I implemented the solution for this and here are the binaries: https://app.circleci.com/pipelines/github/hashicorp/packer/6945/workflows/2ebe6433-53dd-40e8-b8fe-0b7cf84e2cf2/jobs/78129/artifacts
You can use these until the next release, or our pre-release binaries once they are published.

It would be great If you could try it out and let me know if works as expected 👍

That build works for me.

Nice! Thanks again for reporting and testing the binaries.

Hi , binaries are working fine for me as well. However, I am facing another issue about the target folder where the VM will be created. I am using the existing folder "Templates" in VMware Datacenter e.g
"folder" : " /MyDC/vm/Linux/Templates " in the Packer template configuration , however, when I try to create the vm/template , I am getting error
"Build 'vsphere-iso' errored after 1 second 415 milliseconds: error creating vm: ServerFaultCode: The name 'Templates' already exists."
If I use any other non-existing folder name e.g. Templates_TF , it complaints that folder "Templates_TF" not found.
If I remove the folder line from the configuration , it successfully creates the VM/template , however, in the root folder.

Seems like Packer will always want to create VM in the root folder . Is this normal ? Am I missing something for target VM folder?

Thanks

@muhabib1 I have some questions: Are you running your build with the -force flag? This will override any existing template and without Packer will return an already exists error.
If the error persists, did it worked before with 1.6.1, and do you mind opening a new issue with these details?

@sylviamoss Thanks for the response. I am not using -force flag. I have the same issue with other versions so its not specific to 1.6.1 . The template only able to be created under any folder under the root e.g. /MyDC/vm/Templates_TF but not under other folders e.g. /MyDC/vm/Linux/Templates_TF.
I will open a new case with details.
Thank you

Great. Could try running with the -force flag and let me know if changes the result?

Thanks. I moved the other images from that Linux folder to another folder and then removed and recreated Linux folder and then tried to create the image first without -force option and this time it worked. I then tried creating image in other existing folders and this time it worked. So I guess something might be wrong with that specific Linux folder. Things are now working without --force option. Thanks for your help.

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.

Was this page helpful?
0 / 5 - 0 ratings