Opened 10 years ago
Last modified 10 years ago
#12954 closed defect
Virtual Box VMs randomly enter "stopping" state — at Version 1
Reported by: | JohnBe | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox 4.3.10 |
Keywords: | Cc: | ||
Guest type: | other | Host type: | other |
Description (last modified by )
Since upgrading to OSX Mavericks, I've had issues with VirtualBox boxes randomly entering the "stopping" state.
$ vagrant status Current machine states: chef stopping (virtualbox) $ vagrant halt chef $ vagrant up chef Bringing machine 'chef' up with 'virtualbox' provider... ==> chef: Clearing any previously set forwarded ports... There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below. Command: ["modifyvm", "c7dcf83b-67bc-475e-b5d6-f94a4a94d148", "--natpf1", "delete", "ssh"] Stderr: VBoxManage: error: Code NS_ERROR_FAILURE (0x80004005) - Operation failed (extended info not available) VBoxManage: error: Context: "LockMachine(a->session, LockType_Write)" at line 462 of file VBoxManageModifyVM.cpp $ VBoxManage debugvm chef log --debug VBoxManage: error: Code NS_ERROR_FAILURE (0x80004005) - Operation failed (extended info not available) VBoxManage: error: Context: "LockMachine(pArgs->session, LockType_Shared)" at line 641 of file VBoxManageDebugVM.cpp $ vagrant --version Vagrant 1.5.3 $ VBoxManage --version 4.3.10r93012
Any boxes I bring up randomly enter this state multiple times a day, with the only way to revive them being to destroy them.
I've tried clearing out both the VirtualBox VMs and the vagrant.d directories and reinstalling both vagrant and VirtualBox without any change.
Note:
See TracTickets
for help on using tickets.
I would expect to see at least one VBox.log file of such affected VM. See section 12.1.2 of the user manual.