Occasionally, if Virtualbox or Vagrant crash during my laptop's shutdown/tidyup process, I find that, somehow between the two of them, they lose track of which Virtualbox VM corresponds to which Vagrantf project. This is most evident the next time I try to boot the VM up with vagrant up, and I see the message:
A VirtualBox machine with the name <VM_NAME> already exists. Please use another name or delete the machine with the existing name, and try again.
It does happen and your machine isn't truly lost, nor (probably) is any data that was on it. There are quick-ish fixes for this, although I don't know if they're always guaranteed to work.
The core prroblem is that the file in your Vagrant project .vagrant/machines/<name>/virtualbox/id has been replaced, with a brand new UUID. You want to revert the old UUID, which can be found in the file ~/Virtualbox VMs/<VM_NAME>/<VM_NAME>.vbox. This is a long XML file, but at the top you should see an entry of the form:
<Machine uuid="{<UUID>}" name="<VM_NAME>" ...
However, by this point, Vagrant has given up the old machine entirely, and so blasted away a few other files. So you need to ensure files are created in .vagrant/machines/<name>/virtualbox/ as follows:
- id: this should just contain the <UUID> without surrounding curly brackets.
- action_set_name: this should be single number representiing a recent epoch timestamp: converters are available.
- action_provision: this seems to be a decimal number, followed by a colon, followed by <UUID>. If anyone knows how the number is derived (it doesn't appear in my Vagrantfile) then do let me know!
- index_uuid: I haven't been able to derive this; but vagrant up seems to recreate it anyway.
- private_key and synced_folders: you should let vagrant up recreate these.
You might also find that Vagrant has begun to create a new Virtualbox VM, so you should delete any new VMs in the Virtualbox UI that you don't recognize.
