Avoid forcibly shutting the VM down when there is no shutdown command
Closed this issue · 6 comments
Description
Ability to disable the feature that forcibly halts the virtual machine.
Use Case(s)
I have an automatic installer on an ISO image. I just need Packer to boot the VM, type a command, and then wait for the VM to stop by itself.
While it works perfectly with qemu (no forced shutdown), this plugin forces the shutdown.
A workaround I have found is to define shutdown_command = "placeholder" in the source definition (*), but well, it's a bit ugly...
(*): with a fake shutdown command defined but no communicator, it allows (*StepShutdown).Run, to avoid entering in the else block and not forcibly halt the virtual machine.
I suggest that this is not implemented based on prior precedent for a similar issue on packer-plugin-vsphere. This would deviate from the intended use of Packer and this plugin; however, there is an existing workaround.
Ryan Johnson
Senior Staff Solutions Architect | Product Engineering @ VMware, Inc.
The issue you are linking here is not similar. That issue is about leaving the VM running forever, and manually stopping it afterwards, which is not what I need.
The disable_shutdown option, which is present for packer-plugin-vsphere, would be perfectly fine for my need. A 5-minute timeout (configurable with shutdown_timeout) is more than enough for my installer.
But that option does not exist on packer-plugin-vmware.
In that case such an option may be an option to consider.
Code completed and in local testing prior to pull request.
Closing per #217 (comment).
I have a build process that ends with a script that sets a static IP and shuts it down afterwards. This is to configure the machine ready to be imported in another location. As the static IP is not valid on my current network, it means Packer is unable to reconnect to run a shutdown command (including a fake one), throwing an error.
The only option left is to not specify a shutdown_command and letting Packer forcefully shutdown the machine, which is not ideal. Is this a valid use case for implementing disable_shutdown?