`vsphere-clone` with `none` communicator does not start the vm, and proceeds to export after configuration

[haunab-ornl]

When filing a bug please include the following headings, if possible.

Overview of the Issue

If the vsphere-clone build is configured with the "none" communicator, the VM is created, configured, and then immediately torn down and exported as per other config.

Reproduction Steps

Create a vsphere-clone builder with communicator now, shutdown_delay and disable_shutdown configered.

Packer Version

Please provide the Packer version.

1.9.4

Plugin Version and Builders

Please provide the plugin version.

1.2.7

Please select the builder.

• [] vsphere-iso
• [x] vsphere-clone

VMware vSphere Version

Please provide the VMware vSphere version.

7.0.3

Guest Operating System

Rocky 9 x86_64

Simplified Packer Buildfile

Can't provide :-(

Operating System and Environment Details

OSX

Log Fragments and crash.log Files

N/A

See that the build step is wrapped in an if here: https://github.com/hashicorp/packer-plugin-vsphere/blob/main/builder/vsphere/clone/builder.go#L82

[tenthirtyam]

Assigned to @tenthirtyam.

[lbajolet-hashicorp]

I'll add my 2 cents here, why do we do this check exactly? Is there a valid use case to building an image on VSphere without a communicator at all, as we won't be able to provision anything to it (unless I'm missing something). Should this be rejected en bloc by the builder?

[ghost]

In our case, we are using cloud-init for most provisioning on the system where this issue was encountered. Right now, our provisioner is just running cloud-init status -w, then cloud-init clean. We'd prefer to remove the provisioner to simplify the build process.

[lbajolet-hashicorp]

Forgive me if I misunderstand, but right now you are using a communicator like ssh right?

If you use none, Packer will not be able to communicate at all with the VM, so you will effectively end-up spinning a VM from an existing image, and immediately re-pack it as the output. I can see why the builder assumed it would be as good to not have to wait for the VM to be spawned as you won't do anything with it, might as well skip that step and move on to exporting the image immediately.

I'm confused as to what is the expectation here, could you provide an example of what you're trying to achieve?

[tenthirtyam]

Hello! 👋

This issue has not received any update from the OP in the last 14 days.

Please feel free to comment and/or reopen to continue the discussion on the use case.

Ryan Johnson Distinguished Engineer, VMware by Broadcom

[ghost]

To clarify, in our case, other tooling (such as cloud init) powers down the VM at the completion of build. In the current situation, we have an SSH communicator that does nothing more than cloud-init status -w. If we configured cloud init as we would, if none was functional, the SSH communicator would just have an infinite sleep, and it's disconnection would signal the completion of the build.

[lbajolet-hashicorp]

Hi @haunab-ornl,

If you specify none as your communicator, the ssh communicator is not setup, you will not be able to provide any commands to the VM, so what happens right now is essentially what you would get, except that the VM would need to power-up/power-down and do a bunch of extra steps to manage disks/peripherals/etc., so as far as I can tell, this would just make your build longer, and wouldn't impact the output.

[ghost]

In our case, we use cloud-init to customize an image, and as part of that up/down, packages are installed, and other operations are performed. The up-down cycle is necessary to ensure that these changes take place, otherwise the newly-created image differs only in metadata, this is different from the behavior of vmware-iso, and threw us for a quite a loop.