Hi Rickard, Sorry for reviving zombie thread but after a lot of effort I'm right back to this same issue. I started by looking at the Azure ARM documetnation and specifically the sysprep block in this example. https://github.com/hashicorp/packer/blob/master/examples/azure/windows.json
In the example sysprep is done last by a standard powershell provisioner with the /shutdown option. So sysprep starts off and does it's thing eventually shutting down the instance itself. Based on discussion and research the Azure ARM builder then sends a shutdown command to the instance. How that is handled is the key difference between this case and attempting to do the same thing on OpenStack builder. Also of note is that sysprep ends the winrm connection before it's completed work. When I do the same approach with OpenStack builder a couple of outcomes happen. 1. Matching the example just start sysprep as the last provisioner results in the provisioner ending before sysprep is done. Packer then powers off the VM before sysprep is completed. 2. Matching the example but adding a local shell provisioner that just adds 15 minute wait then shutting down. The OpenStack builder fails because the instance is shutdown when it attempts to shut it down with an invalid state error. This specific behaviour I'm crafting a bug report for currently. 3. Running sysprep with a /quit option instead of shutdown then allowing the builder to power off the system after 15min pause. This is currently what I'm doing but it's still causing the VM to be shutdown in an invalid state. Windows needs to do some kind of process at shutdown and the method openstack/packer builder does this is to abrupt. In my view the use case of sysprep for windows images merits adding the shutdown_command capability as an option for "cloud" style packer builders. The normal cloud style shutdown can run after the timeout or if the shutdown_command detects the instance is down. It seems likely the documented technique for azure-arm works because of how that builder and platform deal with windows instance power off is optimized for windows. I'm open to other suggestions but having packer handle the sysprep shutdown use case directly seems best for the long term. Cheers, Blake On Friday, March 24, 2017 at 11:58:04 AM UTC-7, Rickard von Essen wrote: > > None of the cloud based builders have a shutdown_command, there is a > difference on how they are operated. > > Azure ARM > <https://www.google.com/url?q=https%3A%2F%2Fwww.packer.io%2Fdocs%2Fbuilders%2Fazure-arm.html&sa=D&sntz=1&usg=AFQjCNHUFvtwPjGjJeLcI6AILKvPb2pq_Q> > have > a example under Deprovision - Windows on how to run sysprep on Azure, but I > assume the same thing works for OpenStack. > > // Rickard > > On 24 March 2017 at 19:52, Blake Garner <bl...@netjibbing.com > <javascript:>> wrote: > >> It seems like any of the builders could send a shutdown command to the >> OS. Why does the OpenStack one do this instead of working the same as >> vmware-iso or qemu? >> >> Windows OpenStack images need to run sysprep at shutdown. For that to >> work we need to run a script that kills the winrm connection and wait for >> the OS to power itself off. I don't see a clear way to do this with packer >> currently... >> >> >> >> On Fri, Mar 24, 2017 at 9:26 AM, Lorena Lobato <loren...@gmail.com >> <javascript:>> wrote: >> >>> Same case but with Linux images. When I reboot the machine in the >>> provisioner stops without any error and skipping the post commands. >>> >>> Is there anyway to avoid this? Need to reboot the machine during >>> provisioning time to make effective some puppet changes. >>> >>> >>> El viernes, 24 de marzo de 2017, 7:39:54 (UTC+1), Rickard von Essen >>> escribió: >>>> >>>> Shutdown is initiated by an api towards openstack. >>>> >>>> On Mar 23, 2017 23:46, "Blake Garner" <bl...@netjibbing.com> wrote: >>>> >>>>> I'm starting to work with the OpenStack builder and noticed that no >>>>> shutdown_command or shutdown_timeout exist. Am I missing something here? >>>>> Using the shutdown commands is how I trigger windows images to shutdown >>>>> and >>>>> run sysprep. Doing sysprep at shutdown is key for getting cloudbase-init >>>>> to >>>>> work as desired. >>>>> >>>>> Has anybody worked this out yet or do I need to make some feature >>>>> requests? >>>>> >>>>> Thanks, >>>>> Blake >>>>> >>>>> -- >>>>> This mailing list is governed under the HashiCorp Community Guidelines >>>>> - https://www.hashicorp.com/community-guidelines.html. Behavior in >>>>> violation of those guidelines may result in your removal from this >>>>> mailing >>>>> list. >>>>> >>>>> GitHub Issues: https://github.com/mitchellh/packer/issues >>>>> IRC: #packer-tool on Freenode >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Packer" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to packer-tool...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/packer-tool/3586fb47-584d-4434-a613-c3e64ebd45a4%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/packer-tool/3586fb47-584d-4434-a613-c3e64ebd45a4%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> This mailing list is governed under the HashiCorp Community Guidelines - >>> https://www.hashicorp.com/community-guidelines.html. Behavior in >>> violation of those guidelines may result in your removal from this mailing >>> list. >>> >>> GitHub Issues: https://github.com/mitchellh/packer/issues >>> IRC: #packer-tool on Freenode >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Packer" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/packer-tool/YNwRJD6R60I/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> packer-tool...@googlegroups.com <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/packer-tool/6755b43a-d111-47d3-88bd-51651b537bb0%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/packer-tool/6755b43a-d111-47d3-88bd-51651b537bb0%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> This mailing list is governed under the HashiCorp Community Guidelines - >> https://www.hashicorp.com/community-guidelines.html. Behavior in >> violation of those guidelines may result in your removal from this mailing >> list. >> >> GitHub Issues: https://github.com/mitchellh/packer/issues >> IRC: #packer-tool on Freenode >> --- >> You received this message because you are subscribed to the Google Groups >> "Packer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to packer-tool...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/packer-tool/CAGA5xXVUEMd06ch2JDuTChx6M5CiNGCdCs5rcY2EQ%2Bp5qZ1_Aw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/packer-tool/CAGA5xXVUEMd06ch2JDuTChx6M5CiNGCdCs5rcY2EQ%2Bp5qZ1_Aw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list. GitHub Issues: https://github.com/mitchellh/packer/issues IRC: #packer-tool on Freenode --- You received this message because you are subscribed to the Google Groups "Packer" group. To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/df3f8c87-9def-42f3-93d0-12081bc5a5c3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
