Packer: VirtualBox's post_manage modifyvm commands triggers session lock errors in non-headless mode

Created on 24 Jul 2016  路  5Comments  路  Source: hashicorp/packer

Trying to create a VirtualBox ovf from an ISO ;
I issue modifyVM commands in post_manage section and I get errors:

Gracefully halting virtual machine...
Executing custom VBoxManage commands...
Executing: modifyvm xxx --cableconnected1 on
Error ... The machine 'xxx' is already locked for a session (or being unlocked)

Locked session does NOT happen if:

  • run in step-by-step --debug mode
  • issue about 10 showinfo commands before modifyVM commands
  • runs headless

Also note this trace from the end of the VirtualBox log:

Changing the VM state from 'DESTROYING' to 'TERMINATED'
Console: Machine state changed to 'PoweredOff'
GUI: Request to close Runtime UI because VM is powered off already.
GUI: Passing request to close Runtime UI from machine-logic to UI session.

This is what leads me to try using the headless mode. Maybe Packer rely on the machine to be shutdown to send modifyvm commands, but it may not be the right signal. There might be other way to know when VirtualBox is ready to accept modifyvm commands? (_pure speculation_)

For reference:

buildevirtualbox upstream-bug

Most helpful comment

Another update. The VirtualBox 16063 bug is still open and has not been looked at. However, in Packer v0.11.0, the following change:

builder/virtualbox: Added post_shutdown_delay option to wait after shutting down to prevent issues removing floppy drive. [GH-3952]

now allows us to add a custom delay after VM is shutdown and thus allows the modifyvm commands to work correctly. I've tested this using VirtualBox v5.1.8 and Packer v0.11.0 and it works for me.

All you need to do is add the following to your vbox builder:

"post_shutdown_delay": "30s"

I don't think Oracle are going to look at the 16063 bug and so you may want to close this issue and mark it as solved since the above is a better workaround then running headless.

All 5 comments

It looks like something in the VirtualBox API between 5.0.x and 5.1.x has changed and broken the ability to run vboxmanage_post steps in packer.

As a workaround we've rolled back to VirtualBox 5.0.26 which works fine.

Concerning 5.1 and post manage, I think that it is fair to wait for the 5.1.3, because previous 5.1 had also problems with import that are annoying: https://forums.virtualbox.org/viewtopic.php?f=7&t=78840.

But, it would be sad to remove the vboxmanage_post entirely. If you read the original post, it looks like a timing issue due to the GUI lagging to release the session. I don't know the VirtualBox API, but I hope they provide a way to know when the VM is ready to receive manage commands.

Just an update for Packer devs. I've reproduced the issue using only VBoxManage commands and created the following VirtualBox bug: https://www.virtualbox.org/ticket/16063.

So far, I don't think its a Packer issue unless there is something wrong with the flow of commands being run. i.e. after detaching the dvd drive (or before) is one supposed to do something else before you can modify the vm?

Another update. The VirtualBox 16063 bug is still open and has not been looked at. However, in Packer v0.11.0, the following change:

builder/virtualbox: Added post_shutdown_delay option to wait after shutting down to prevent issues removing floppy drive. [GH-3952]

now allows us to add a custom delay after VM is shutdown and thus allows the modifyvm commands to work correctly. I've tested this using VirtualBox v5.1.8 and Packer v0.11.0 and it works for me.

All you need to do is add the following to your vbox builder:

"post_shutdown_delay": "30s"

I don't think Oracle are going to look at the 16063 bug and so you may want to close this issue and mark it as solved since the above is a better workaround then running headless.

I'm closing this as there is a workaround implemented in #3952 released in 0.11.0, see the comment above and this is actualy a VirtualBox bug, see 16063.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

wduncanfraser picture wduncanfraser  路  3Comments

sourav82 picture sourav82  路  3Comments

mwhooker picture mwhooker  路  3Comments

shantanugadgil picture shantanugadgil  路  3Comments

s4mur4i picture s4mur4i  路  3Comments