16

I've recently started using Virtualbox, Vagrant and VVV for my local Wordpress development environment. It's very slick.

One issue I've had is that after shutting things down with 'vagrant halt', the next time I start with 'vagrant up' I get this error: 

==> default: Setting the name of the VM: vagrant-local 
The name of your virtual machine couldn't be set because VirtualBox
is reporting another VM with that name already exists. Most of the
time, this is because of an error with VirtualBox not cleaning up
properly. To fix this, verify that no VMs with that name do exist
(by opening the VirtualBox GUI). If they don't, then look at the
folder in the error message from VirtualBox below and remove it
if there isn't any information you need in there.

VirtualBox error:

VBoxManage.exe: error: Could not rename the directory 'C:\VirtualBox VMs\ubuntu-cloudimg-trusty-va
230_94704' to 'C:\VirtualBox VMs\vagrant-local' to save the settings file (VERR_ALREADY_EXISTS)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component SessionMachine, interface IMac
VBoxManage.exe: error: Context: "SaveSettings()" at line 3015 of file VBoxManageModifyVM.cpp

I visit the location listed C:\VirtualBox VMs\ and indeed, that directory 'vagrant-local' already exists. If I delete (or rename) this directory and run 'vagrant up' again, the machine starts. But, it also performs the full provisioning process. Which, of course, takes a very long time.

I'm using all the default configurations for VVV and Vagrant out-of-the-box. What should I do to help VirtualBox "clean up properly" and recognize that it doesn't need to recreate the VM every time I halt and restart.

Or, am I just missing something?

"Beginner level" responses are welcome, if not preferred. I'm a beginner in this area and I appreciate the help! Thanks.

CURRENT STATUS: I've deleted the VM in question from C:\VirtualBox VMs\; Running Git Bash as administrator, I've been able to use vagrant up (full provision takes place), vagrant halt, and vagrant up again all with expected results (no provisioning on second up). As of now, it appears that everything is working. Appears... :)

ensminger
  • 671
  • 3
  • 6
  • 14
  • is it happening the same for any vm ? did you try to create a new vm from vagrant and the same error ? I am not windows expert but the error could be a permission issue, can you try running vagrant with administrator privilegies – Frederic Henri Sep 16 '15 at 12:46
  • Yes. This issue is persistent with all VMs on the machine. I have been running the command line as an administrator with the same result. Is "Run as administrator" a setting somewhere within vagrant, or is this sufficient? – ensminger Sep 19 '15 at 03:40
  • something weird, it should be ok with running cli as admin. after you run `vagrant up` is `vagrant status` giving you status of VM ? and can you do `vagrant suspend` and `vagrant up` again or same message ? – Frederic Henri Sep 19 '15 at 10:03
  • I can check on the status. I've found some insight [on this thread](https://github.com/mitchellh/vagrant/issues/1198) as I've also experienced the issue as described by the OP on this same workstation. If this is a permissions issue, are there any particular permissions settings that I should check on? ie. What should my permissions be and for what directories involved? – ensminger Sep 21 '15 at 20:08
  • running on windows, you should be fine if you run as administrator – Frederic Henri Sep 21 '15 at 20:22
  • Thank you so much for your help! Current status: Running Git Bash as administrator, I've just used `vagrant up`, `vagrant halt`, and `vagrant up` again all with expected results. As of now, it appears that everything is working. Appears... :) I would accept your answer to consider it closed, but I lack the reps. – ensminger Sep 21 '15 at 20:29
  • Good thing ... well as OP you should be able to [accept an answer](http://meta.stackexchange.com/questions/5234/how-does-accepting-an-answer-work) but potentially could not vote up – Frederic Henri Sep 21 '15 at 20:32
  • Done. [sheepish face] Thanks again. – ensminger Sep 21 '15 at 20:38

6 Answers6

24

If you are on a Mac, and vagrant destroy doesn't work, and you get the message: The name of your virtual machine couldn't be set because VirtualBox is reporting another VM with that name already exists. Then you need to go to the VirtualBox VMs folder in your user folder and delete the VM folder.

It's in a weird state where it can't build the VM because it's trying to create settings for a folder that is already there with the same name.

Gustavo Morales
  • 2,614
  • 9
  • 29
  • 37
DDT
  • 395
  • 3
  • 14
4

Mine was a little simpler than most of these. I checked the "Virtual Box VMs" directory (for windows) and deleted the folder that was named what it was trying to be named as. This resolved the issue for me.

Chris
  • 600
  • 7
  • 15
1

I got above mentioned git bash error while vagrant up. There are multiple possibilities to occur this issue.

I have used below mentioned steps and vagrant command working properly.

  1. Open Oracle VM virtual manager - In this Oracle VM virtual manager panel, Remove current running virtual machine.
  2. Exit from git bash command prompt
  3. Open git bash again
  4. Run vagrant up command as vagrant up

Vagrant up command will run successfully.

Please note: Make sure you will run vagrant halt command while close git bash command prompt.

First, vagrant halt and then exit command.

tshepang
  • 12,111
  • 21
  • 91
  • 136
Sudhir
  • 11
  • 2
0

Hum .. This is a weird issue. when you run vagrant halt it just send signal to terminate the VM.

Vagrant keeps all the configuration under a .vagrant directory (at least for mac os and linux, not fully sure if windows) , you should never delete this directory as it has all the reference to your vm, so when you run vagrant up next time, vagrant will search for information from this directory to start the corresponding vm, and it knows it does not need to recreate the VM nor provisioning.

The correct way to remove information about your vm is to run vagrant destroy, it will delete all the .vagrant directory and the vm.

The are then ways to make this linkage again from .vagrant and your vm but its a bit tricky and not sure they are officially supported

When you use vagrant, VirtualBox should become (almost) transparent, you should not need to start it to use your VM, everything should be run from vagrant (at least at beginner level)

Note : running on windows, you should be fine if you run as administrator

Frederic Henri
  • 51,761
  • 10
  • 113
  • 139
  • Thanks for the response! I am on Windows. I am aware of `vagrant destroy` (as I've used it to remove a few "practice" machines). In this scenario, I'm using `vagrant halt` with the [default intention of simply "powering off"](https://docs.vagrantup.com/v2/cli/halt.html). This is the right command to use for this, correct? – ensminger Aug 31 '15 at 15:41
  • 1
    yes, `vagrant halt` is basically the same as running `sudo shutdown -P now` – Frederic Henri Aug 31 '15 at 16:46
0

VBoxManage: error: Could not rename the directory '<SOURCE>' to '<DESTINATION>' to save the settings file (VERR_ALREADY_EXISTS)

If you don't care about your VM state and you can provision it from scratch, remove your destination folder, then it should work. Also double check if you've removed it from VirtualBox list as well.

This could happened with VirtualBox not cleaning up properly or you interrupted the process of cleaning (e.g. Ctrl-C in the middle of vagrant destroy).

kenorb
  • 155,785
  • 88
  • 678
  • 743
0

In my case, I had to clean the VirtualBox files. It basically shows the file location with the error message but in case you don't see it, Follow these commands. I'm on Ubuntu 22.02.

cd /home/<username>/VirtualBox\ VMs/

and see if you see any unnecessary directories inside.

ls

You need to delete the file directories you don't need, so run

rm -rf <directory-name>

Then go back to your vagrant directory and hit,

vagrant up

It would solve the issue!

Disapamok
  • 1,426
  • 2
  • 21
  • 27