Vagrant VM not saving any changes; creates new VM upon every `halt/suspend + up` (Windows Vagrant, VirtualBox, RailsDevBox) - ruby-on-rails

Question

I am trying to use Virtual Box + Vagrant + Rails Dev Box on a Windows machine. I am able to run vagrant up and vagrant ssh to get into the virtual machine but none of the changes that I make are being saved, such as installing rails. Every time I halt Vagrant and start again, it's as if I loaded it for the first time. The process goes through all the steps that make the first vagrant up.
I have noticed, however, is that the one change I made to the Vagrantfile (synced folders location) is persisting. Also, if I use vagrant reload, the changes seem to persist. So it looks like the problem only happens if I use vagrant halt or vagrant suspend followed by vagrant up. But I wasn't under the impression that vagrant halt (and especially not vagrant suspend) is supposed to destroy a VM.
And when I open VirtualBox Manager I can see a bunch of instances of rails-dev-box VM's that have been created.
I found an issue that looks like this in the Vagrant Github issues site but honestly the discussion is totally over my head and I wasn't able to understand the resolution even though that thread is closed.
If anyone knows what is causing and could explain in "newbie" terms or, if my problem is too opaque, could walk me through the next steps to debug, I would really appreciate it!
EDIT
After writing this out and thinking about it more, I realized the problem is not actually that "changes aren't being saved." They're being saved...but I'm just being taken to a brand new VM any time I run vagrant up.

Answer 1

Have you tried vagrant resume instead of vagrant up?

Answer 2

I have been having this same issue, and have a couple possible solutions.
The file Vagrant uses to keep track of the default VM is .vagrant/machines/default/virtualbox/id. (The contents of that file will be the UUID of the VM, which can be found in the VirtualBox.xml file.) If there is anything wrong with the VM referenced there, then Vagrant apparently just deletes the file and tells you to start over.
One GitHub issue reported this same problem, in that case the VM was in an "invalid state" in VirtualBox. The problem was solved by deleting a corrupted save state.
That may be the issue that you are having, though it was not mine. If and when I figure out why I am having this issue, I will update this answer.
Edit: I booted up my vagrant VM manually from VirtualBox Manager (though I was not able to use it for development, because the shared folder wasn't set up by Vagrant). I didn't see any major problems, so I shut it back down. Next I replaced the id file manually, as described above. I did vagrant up again and it worked. Note that in order to keep it from being re-provisioned, you also need to re-create the action_provision file in that same folder. The contents of mine are: 1.5:<uuid>, where <uuid> is the machine's UUID. (I am not sure what the 1.5 means..) I have since done both vagrant suspend and vagrant halt (each followed by vagrant up) multiple times, and haven't had any further problems. I still don't know what caused this issue. If I have any other problems, or find out why this happened, I will again report back here.
Edit 2: I have finally figured out the problem. First, to help track things down, I did VAGRANT_LOG=debug vagrant status. This produced a lot of output, but as I dug through it, I found one line in particular of interest: VBoxManage.exe: error: could not find a registered machine with uuid <uuid>. I then did some manual debugging, and found that VBoxManage.exe list vms returned blank. It turns out that VirtualBox had lost track of my .VirtualBox folder, because I was doing all of this in Cygwin. Some more debugging, and I found that the environment variable that VirtualBox was looking for was HOME. I set that to my Windows home directory (/cygdrive/c/Users/<me>) in my .bashrc, and it fixed the problem, this time more permanently.
TL;DR:
Open the VirtualBox GUI and make sure there are no errors related to your VM.
If you are in Cygwin, ensure that HOME is set to the right value.
Otherwise, prepend VAGRANT_LOG=debug to any Vagrant command to debug further.

Answer 3

First, get the state of the VM to where you want it i.e. all things installed and configured.
While the VM is running, executing vagrant global-status gets the 'id' of the box and then do a vagrant package {id} packages it into a local package.box file.
vagrant box add package.box --name {whatever-name} - should get your box added to the list of available ones.
Then you can either create a new Vagrantfile or modify the existing one to load the vm with this new name.
Hope this helps.