search

hashicorp / packer-plugin-vsphere

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

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

Closed haunab-ornl closed 1 month ago

haunab-ornl commented 2 months ago

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.

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 commented 2 months ago

Assigned to @tenthirtyam.

lbajolet-hashicorp commented 1 month ago

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?

haunab-ornl commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

haunab-ornl commented 1 month ago

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 commented 1 month ago

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.