Windows 10 Home, Latest Vagrant, Latest Virtualbox, Won't Start Boxes

Good afternoon,

We’ve got a user on Windows 10 Home (and thus, can’t use Hyper-V, and must use Virtualbox). They have successfully installed the latest (as of March 30th) version of Virtualbox and Vagrant on their 64-bit Windows 10 Home.

They were able to vagrant up, and predictably use vagrant up; vagrant rsync; vagrant provision.

However, after a forced reboot of their laptop, they were absolutely unable to bring up the Vagrantfile any longer. We use vagrant global-status to vagrant destroy all of them, by ID and also by name. As that didn’t work, we went into Virtualbox and removed the VMs by hand (including the on-disk files), and validated by checking their “Virtualbox VMs” directory, which was empty.

And yet, no matter what, the user could not vagrant up any longer. When they attempted to do so (after validating there were NO VMs in global-status), each run would simply result in them being told that “Virtualbox machine with the name already exists”.

We do set the name in the Vagrantfile (for predictability reasons, and other development reasons), and so while we’re relatively certain that we could probably get Vagrant to bring up a VM by removing the name setting, we cannot find ANY reason that this user is unable to bring up VMs with vagrant up. We even went so far as to uninstall Vagrant, reboot, uninstall Virtualbox, reboot, reinstall each of them, reboot, and still the same behavior.

Has anyone had any issues like this? It seems strongly like a bug, but in at least 5 years using Vagrant, I’ve never ran into this type of issue.

Thanks in advance,

Hi Michael,

Thanks for the detailed report. Do you recall seeing any error messages when you tried to destroy the machine using the ID listed in vagrant global-status?

Vagrant uses the VBoxManage command to get the list of VirtualBox VMs, and it sounds like that machine is still being listed for some reason.

Would you be willing to run VBoxManage list vms on that Windows 10 machine? That should return a list of VMs with their UUIDs, and then you can get more details about the particular VM with VBoxManage showvminfo <uuid>. For example:

VBoxManage showvminfo {e90ff7d4-d5ba-4a1a-a2f1-d6c2e126bb39}

We’d be interested in seeing if there are any references to files still on disk. Finally, you could try deleting the VM from the command line with, e.g.:

VBoxManage unregistervm --delete {e90ff7d4-d5ba-4a1a-a2f1-d6c2e126bb39}

Thanks for taking the time to look into this.

I’ll ask the user to do this. So that I know, do they need to run this as an Administrator with UAC permissions?

Running the commands as the standard (unelevated) user should be sufficient. Cheers!