Suspending removes the box

[jkosecki]

Hi, I'm running the latest version of VirtualBox (4.3.14) and Vagrant (1.6.3) on my Win8.1 x64 laptop and I'm having a strange problem that I couldn't find anywhere to be mentioned. After creating the box with vagrant up, vagrant status displays box status as running so everything is fine. However, when I run the vagrant suspned command, instead of having saved box, my vagrant status shows not created and so after vagrant up my box has to start all over from the beginning. Any ideas why does it behave so?

[mitchellh]

Can you please attach a debug log for this? We've never seen this behavior and that will help. Append --debug to your commands to get a debug log. It would help to see the comple up, status, suspend, status sequence of debug logs.

[keunwoo]

I am finding similar symptoms, although I find that it is not suspending but running vagrant status that removes the box from vagrant's index. I have a sneaking suspicion that the reporter's problem is like mine. Here is the exact sequence of commands I used:

1. In an empty directory, vagrant init hashicorp/precise32
2. vagrant up
3. vagrant suspend. At this point, the .vagrant/machines/default/virtualbox dir is populated.
4. vagrant status. Suddenly .vagrant/machines/default/virtualbox is empty, and the VM is described as "not created" by vagrant status.

When I start the VirtualBox manager GUI after step 4, the VM is listed, and is in the "aborted" state.

I am testing this on a Windows 8.1 box, running as a non-Administrator user. Vagrant 1.6.3, VirtualBox 4.3.14 r95030.

Here is a gist with a console log, as well as VAGRANT_LOG=debug stderr captures for the vagrant up, vagrant suspend, and vagrant status commands:
https://gist.github.com/keunwoo/3226d004a6493ef03e74

[keunwoo]

After a little more debugging, I have discovered the following:

• After vagrant suspend, VBoxManage showvminfo shows State: aborted
• Running VBoxManage in this state, immediately after suspend, often crashes. Windows brings up the "This program crashed" dialog.
• Running VBoxManage again seems to work, although State: is still aborted.

These symptoms resemble those found in Issue #4254 by @scottgrasley ("VBoxManage showvminfo call returns 2147483651").

Exact steps I use to produce the error (in an empty directory, vagrant 1.6.3 and virtualbox 4.3.14):

1. vagrant init hashicorp/precise32
2. vagrant up
3. vagrant suspend
4. This step crashes: /c/Program\ Files/Oracle/VirtualBox/VBoxManage.exe showvminfo cat .vagrant/machines/default/virtualbox/id``
5. This step works: /c/Program\ Files/Oracle/VirtualBox/VBoxManage.exe showvminfo cat .vagrant/machines/default/virtualbox/id``
6. vagrant status shows "aborted"

So it appears that running VBoxManage showvminfo until it succeeds before running any vagrant commands clears some weird bit of broken state in VirtualBox. This is a partial workaround for the issue of VMs disappearing, although it still doesn't make suspend/resume work properly.

I'm going to try downgrading to VirtualBox 4.3.12 and reproducing there.

[keunwoo]

After downgrading to Virtualbox 4.3.12, I can't get VBoxManage to crash after suspend any more, and I also can't reproduce the issue above with that version. The output of VBoxManage showvminfo after suspend also shows "State: saved" after suspend, rather than "State: aborted".

Here's a gist of env VAGRANT_LOG=debug vagrant suspend with 4.3.12:
https://gist.github.com/keunwoo/29f23d2b780883b94413
I can't find any meaningful differences from the suspend log under 4.3.14.

So my current best guess is that under Virtualbox 4.3.14, something goes wrong during suspend, leaving Virtualbox in a corrupt state that triggers a crashing defect in VBoxManage showvminfo. Running VBoxManage showvminfo somehow clears Virtualbox's metadata in a way that prevents it from crashing, but does not enable the VM to resume rather than booting.

This is pretty frustrating, but as a short-term workaround, vagrant users who encounter this issue may be able to solve it by downgrading to 4.3.12.

If vagrant forks VBoxManage showvminfo internally, it may also want to retry the call a few times before deciding the VM doesn't exist and blowing away the contents of ~/.vagrant/machines. This would at least reduce the likelihood of vagrant losing track of VMs and declaring them "not created", although it would not fix suspend.

[mitchellh]

Yeah after more looks I think this was a weird VirtualBox issue. :( Sorry this happened, wish I could help more.

[keunwoo]

OK, thanks for looking at it at least.

BTW is there any chance you could put up a matrix somewhere of VirtualBox version/platform pairs that are "supported", or at least "tested and believed to work", perhaps with a listing of known quirks? This would make onboarding simpler for people on various platforms. It could even be a wiki page, so users could help maintain it instead of you by yourself.

[antonmos]

@mitchellh, is there a bug open in the Virtual Box project for this?
Also, +1 on @keunwoo's request

[lewiswalsh]

Further to my similar issue #4254 - All is now working as expected with Vagrant 1.6.5 and Virtualbox 4.3.14r95030 on Windows 8.1

[taichunmin]

I have the same problem!

1. vagrant up a vm
2. vagrant suspend
3. vagrant status
   On step 3, I find the step will clear all the .vagrant data.
   I found the vagrant log have the command that have been executed.
   So I execute step by step.
   I find the error is because after virtualbox suspend. Then execute VBoxManage.exe showvminfo uuid will crash! When vagrant receive a crash code (on Windows can use %errorlevel%), vagrant will treat the vm disappear, then clear all the data.
   My log file below:

 INFO global: Vagrant version: 1.6.5
 INFO global: Ruby version: 2.0.0
 INFO global: RubyGems version: 2.0.14
 INFO global: VAGRANT_EXECUTABLE="C:\\HashiCorp\\Vagrant\\embedded\\gems\\gems\\vagrant-1.6.5\\bin\\vagrant"
 INFO global: VAGRANT_INSTALLER_EMBEDDED_DIR="C:\\HashiCorp\\Vagrant\\embedded"
 INFO global: VAGRANT_INSTALLER_ENV="1"
 INFO global: VAGRANT_INSTALLER_VERSION="2"
 INFO global: VAGRANT_INTERNAL_BUNDLERIZED="1"
 INFO global: VAGRANT_LOG="debug"
 INFO global: Plugins:
 INFO global:   - bundler = 1.6.6
 INFO global:   - mime-types = 1.25.1
 INFO global:   - rdoc = 4.0.0
 INFO global:   - rest-client = 1.6.8
 INFO global:   - vagrant-login = 1.0.1
 INFO global:   - vagrant-share = 1.1.1
... deleted ...
 INFO subprocess: Starting process: ["D:\\Program Files\\Oracle\\VirtualBox\\VBoxManage.exe", "showvminfo", "39460999-0689-4b7a-a529-4343175a87b3"]
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 2147483651
DEBUG virtualbox: VM not found! Clearing saved machine ID and reloading.
DEBUG virtualbox: Instantiating the driver for machine ID: "39460999-0689-4b7a-a529-4343175a87b3"

[stufa00]

I am having the exactly same problem with vagrant (win) 1.6.4 & virtualbox 4.3.14r95030, can't suspend. Haven't found a solution yet.

[lewiswalsh]

@stufa00 Try upgrading Vagrant to 1.6.5, it solved it for me.

[stufa00]

No help, can't suspend with 1.6.5. I think the "vagrant suspend" command works but there is something strange with "vagrant up" and "vagrant status" because they delete everything from the .vagrant dir after successful suspend.

[stufa00]

"vagrant halt" and then "vagrant up" works, have to stick to that for now..

[jhaoda]

Windows 7x64

Virtualbox 4.3.14, Vagrant 1.6.4 — same problem.

Virtualbox 4.3.16, Vagrant 1.6.5 — no problem. vagrant resume and vagrant up works correctly after vagrant suspend.

[ghost]

I am using:

• Windows 7 Ultimate (x64)
• Vagrant 1.6.5
• VirtualBox 4.3.16 (r95972)

The problem still exists. The command vagrant suspend destroys VM. After running it vagrant status is showing:

Current machine states:

default                 not created (virtualbox)

Any solutions?

[gonewest818]

Incidentally, I have the same issue running Vbox 4.3.16 and Vagrant 1.6.5 on Win 7 Professional SP1 x86_64. "vagrant suspend" is causing the VM to be destroyed, leaving an "aborted" VM in the VirtualBox Manager ui.

I experimented a bit with VBoxManage by hand, and was able to reproduce the issue this way:

• vagrant up
• vagrant status (shows the vm is running)
• VBoxManage list vms (shows the name and uuid of the running vm)

So far everything looks good. So now I am assuming a "vagrant suspend" is the same as the following command:

• VBoxManage controlvm savestate

And at this point I can go to %HOME%\Virtualbox VMs<name_of_vm>\Logs\VBox.log and find the following:

00:01:27.978619 Changing the VM state from 'RUNNING' to 'SUSPENDING'.
00:01:28.084084 PDMR3Suspend: 105 431 766 ns run time
00:01:28.084135 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'.
00:01:28.100015 Changing the VM state from 'SUSPENDED' to 'SAVING'.
00:01:29.807748 SSM: Footer at 0xad0cca1 (181456033), 30 directory entries.
00:01:29.808004 SSM: Successfully saved the VM state to 'C:\Users\ (... path redacted)
00:01:29.808013 Changing the VM state from 'SAVING' to 'SUSPENDED'.
00:01:29.808051 Console::powerDown(): A request to power off the VM has been iss
00:01:29.808075 Changing the VM state from 'SUSPENDED' to 'POWERING_OFF'.

which looks fine, but then the log continues

00:01:29.808182 PDMR3PowerOff: 2 642 ns run time
00:01:29.808188 Changing the VM state from 'POWERING_OFF' to 'OFF'.
00:01:29.808907 Changing the VM state from 'OFF' to 'DESTROYING'.
00:01:29.813951 Changing the VM state from 'DESTROYING' to 'TERMINATED'.

And yes, at this point if I check the status

• vagrant status (shows the vm as "not created")

Seems wrong that the "vboxmanage controlvm savestate" should destroy the VM after powering off, and this seems to be the bug we need to report to Virtualbox.

[stufa00]

In my case, vagrant suspend is actually not destroying the created virtual machine itself. Somehow, it just inserts a wrong uuid to id file under .vagrant/machines/default/virtualox. The virtual machine is still there when you issue "vboxmanage list vms". After this if you issue "vagrant status" then it destroys all the contents of the corrupted .vagrant dir.

[jkosecki]

Having still the same problem after upgrading both VirtualBox and Vagrant to newest versions

[gonewest818]

I've moved the discussion of my symptoms to the Virtualbox forums

https://forums.virtualbox.org/viewtopic.php?f=6&t=63703

[mattsnowboard]

Has anyone gotten an answer from VirtualBox? I've found only the response that "Vagrant is not supported". Unfortunately, I don't know what exactly Vagrant is doing and what is going wrong, if I knew, I could just ask on the VirtualBox forums describing the problem without mentioning vagrant.

https://forums.virtualbox.org/viewtopic.php?f=6&t=63556&start=120#p299780

So far, I'm just using the 4.3.12 version but I don't want to be stuck on that version forever...

[ghost]

I am also curious if there is a solution, I don't want to be using version 4.3.12 forever.

[ssundheim]

I have this problem, too. Suspended vagrant boxes become aborted on resume.
Wind 8.1, Vbox 4.3.15, Vagrant 1.6.5

[hansolav]

I also experienced this problem with VirtualBox 4.3.16 and Vagrant 1.6.5 on Windows 8.1. Downgraded VirtualBox to 4.3.12 and now suspend and up is working.
Edit:
Now it's working some times

[avonian]

chalk me up to the list of users with this same issue

[szigya]

Same issue with Vagrant 1.6.5 and VirtualBox 4.3.18, BUT! "vagrant halt" and "vagrant up" is working. Windows 7 x64, SSD, VMWare installed before VirtualBox. I uninstalled it now, but with suspend it fails.

[renanvaz]

Same issue with Vagrant 1.6.5 and VirtualBox 4.3.18 on Windows 8.1.
For me works only with Vagrant 1.6.5 and VirtualBox 4.3.10 on Windows 8.1.

[majkinetor]

The same problem

Vagrant 1.6.5
Virtual Box 4.3.18 r96516
Windows 7 x 64

halt & up work OK
suspend destroys machine

PS C:\Downloads\svn\vagrant> vagrant status
Current machine states:
node-1                    running (virtualbox)
The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.
PS C:\Downloads\svn\vagrant> vagrant suspend
==> node-1: Saving VM state and suspending execution...
==> node-1: Removing hosts on suspend disabled
PS C:\Downloads\svn\vagrant> vagrant status
Current machine states:
node-1                    not created (virtualbox)
The environment has not yet been created. Run `vagrant up` to
create the environment. If a machine is not created, only the
default provider will be shown. So if a provider is not listed,
then the machine is not created for that environment.

[comxd]

Same issue for me with Vagrant 1.6.5 and VirtualBox 4.3.18 on Windows 8.1. (Cygwin current version)

[JVimes]

@gonewest818, did you come to a resolution on the VirtualBox thread? It dead-ended and jumped to another thread, and that thread seemed to say "fixed in 4.3.18", but this Vagrant issue still happens in 4.3.18. So maybe they're talking about something else. Is there a bug in the VirtualBox bug tracker?

[borntorun]

I don't understand why the owner of the project and almost everyone keep saying this is a VirtualBox problem! I reported a very similar issue #4740 that was closed without much interest/information given. I think this problems suspending/halting vagrant powered vms are Vagrant issues at least with newer versions of VirtualBox > 4.3.12; they dont happen when using solely Virtualbox or cmd line with Vboxmanage.

[gonewest818]

@JVimes, I frankly don't remember anymore. Over on the Oracle side I seemed to be funneled into discussions about bugs related to security features added in recent releases. I suspect what's happening here is that the vboxmanage commands are getting into some unexpected state, the vagrant commands are getting confused eg by the error codes being returned, and vagrant is falling into some generic "cleanup" routine that has the effect of wiping out the vagrant files that are tracking the VMs state.

I may have opened a ticket but I don't remember - will have to search and see. If I did open one I'm certain there has been no response.

On Oct 29, 2014, at 11:32 AM, JVimes notifications@github.com wrote:

@gonewest818, did you come to a resolution on the VirtualBox thread? It dead-ended and jumped to another thread, and that thread seemed to say "fixed in 4.3.18", but this Vagrant issue still happens in 4.3.18. So maybe they're talking about something else. Is there a bug in the VirtualBox bug tracker?

—
Reply to this email directly or view it on GitHub.

[gonewest818]

@JVimes - looks like I didn't open a ticket before so I opened one:
https://www.virtualbox.org/ticket/13583

[JVimes]

Sweet, thanks @gonewest818!

[borntorun]

Tested @gonewest818 and the error occurs in fact with vboxmanage , so I retire my last comment... always learning...

[stepanzarubin]

For now I am doing this manually from VirtualBox gui, save state, then run again.

[gitowiec]

I also had this issue, installed this build https://www.virtualbox.org/download/testcase/VirtualBox-4.3.19-96923-Win.exe and it is gone!

[majkinetor]

@gitowiec Thanks man, that solves it here too.

[mokanfar]

this has been happening so much with me I've learned how to provision my boxes so I didn't lose too much in between windows restarts!

[Ecno92]

We had similar issues when using vagrant halt instead of vagrant suspend on multiple machines. I'm now running vagrant 1.6.5 and Virtualbox 4.3.18 r96516 and the issue seems to be resolved. In our case the vagrant image was still present, but could not get detected by Vagrant. When we did a vagrant up it started a new VM instead of using the existing one in virtualbox.

[heyfletch]

Was having the same issue on OSX. Downgraded from VirtualBox-4.3.26-98988-OSX.dmg to VirtualBox-4.3.20-96996-OSX.dmg. I tried a bunch of things, so not sure if the downgrade is what fixed it, but so far have not had a repeat of my vagrant virtualbox files disappearing.

[gabegm]

I am currently having the same problem on OSX 10.10 and will try @merchantguru 's solution

[mjmj]

Also having .vagrant/machines/default/virtualbox folder suddenly empty while using virtual box 5.0.2r102096 on OSX 10.10.5 and vagrant 1.7.4. Seen this on two different Mac's now, this one is brand new with only the above software added. Haven't issued any halt or suspend commands, but have closed the lid on my mbp. Saw the folder full with it's normal files (id, sync folder etc) then an ls on the directory moments later revealed all the files gone!

[gonewest818]

For what it is worth the virtualbox bug I reported months ago was supposedly fixed in 4.3.20. However I have since moved on to using docker-machine (and happy with it) so I can't confirm if the bug has resurfaced in a new way.

I will say, however, that back in the day I had a pretty simple bash script to reproduce the bug if someone cares to go back and try. That script Is attached to the vbox ticket.

https://www.virtualbox.org/ticket/13583