vagrant up not detecting a previously run VM

[g8d3]

Hi,

I am not sure how this part of Vagrant works, but I am getting:

$ vagrant up
[default] VM not created. Moving on...
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'opscode-ubuntu-12.04-i386'...
[default] Matching MAC address for NAT networking...
A VirtualBox machine with the name 'xxxxxxx' already exists.
Please use another name or delete the machine with the existing
name, and try again.

When I already had a VM working, I just wanted to restart VM to add a forwarded port, any help on this is appreciated.

Thanks.

[mitchellh]

Are you running vagrant from the same directory?

What OS are you on?

Can you get --debug output? (gist please)

[drpebcak]

@juanpastas sounds like you are looking for the vagrant reload command. If you already have a vagrant box running, vagrant reload will restart it. vagrant up is only for when the box is not currently running.

That being said, the error you are getting is kind of strange. Generally it will say the VM is already running and be done with it. You should gist your Vagrantfile for us to see.

[g8d3]

Thanks, I ended up rebuilding machine: vagrant destroy && vagrant up --provision.

I had to use --provision, because otherwise provision is not run.

[tomav]

Hmm, same problem here yesterday.
Destroyed, re-up + provision, worked well.
Got the problem again today.

Here is the debug : https://gist.github.com/tomav/92bade16e8929d38618b

[ghost]

I ran into the same issue with the basic vlad box. May need to start specifying the box name. I got it working with these commands.

vagrant destroy
boxname: yoursite.tld in settings.yml
rm -rf .vagrant in your cloned vlad folder

Even tried deleting the box with rm -rf Users/yourname/VirtualBox\ VMs/boxname/ with no luck

[reynoldsalec]

When I encountered this problem, I was able to solve it without reprovisioning a new virtual machine by checking my the VirtualBox ID using "vboxmanage list vms" and making sure it was the same as the id provided in "vagrantdirectory/.vagrant/machines/default/virtualbox/id". Somehow mine was changed to a different vm's id.

[cleargif]

@reynoldsalec my ID changed as well. Your suggestion worked for me. PHEW!

Think I know why it changed. Need to be more careful..

[hauptbenutzer]

This is still an issue. After adding a forwarded port and reloading, vagrant is no longer recognizing the previously run VM.

[ryanemmm]

Me too.

• Using Vagrant 1.6.5, VirtualBox 4.3.16
• Vagrant box was running for a week or so. No problems
• Yesterday, I installed grunt-contrib-jade (that's the only thing I can think of that changed on the vm)
• Last night, shut down my laptop (thought I shut down the vm... guess I didnt)
• This morning, noticed vm was "aborted" in VirtualBox
• Tried vagrant up... vagrant reload... vagrant up --provision
• Kept getting error:

"A VirtualBox machine with the name 'MyBox' already exists.
Please use another name or delete the machine with the existing
name, and try again."

• Tried: `vagrant destroy && vagrant up --provision
• Same error
• Deleted the VM from VirtualBox
• Again: vagrant destroy && vagrant up --provision
  * Vagrant box is back and running *

[dotnetwise]

Same error, none of the above worked for me.

[Xicoria]

Same error. Solve downgrading to VirtualBox 4.3.12.

[geocine]

@Xicoria I tried your suggestion but it did not work for me .

[Xicoria]

@geocine Detail: I always run vagrant as administrator (and also VM virtualbox manager to see the machine status) .
After the downgrade the VM is not being destroyed anymore.
Using Vagrant version 1.6.5, VirtualBox 4.3.12, Win8.1 64bits

[geocine]

@Xicoria . I'll check virtualbox mamager and vagrant again later. I do have Win 8.1 64bit with UAC disabled. cmd is in Administrator mode. I am using Virtualbox 4.3.12.

[sys0dm1n]

I had the same issue, @reynoldsalec solution worked perfectly for me. Thank you

[ianks]

I have run into this issue as well. I use this box as a development environment on a Mac, so I don't want to risk destroying the box. I need to get back in. Pretty lost here, any ideas??

I tried @reynoldsalec solution, but there seems to be no ID in my ~/.vagrant/machines/default/virtualbox

[sys0dm1n]

@ianks check your ID path again. the ".vagrant" folder should be in the same location as the "Vagrantfile" file. So if your Vagrantfile is not in your home directory "~/" you will not find any ".vagrant" folder.

[mikevanwinkle]

I also had this issue and found that I had no id file in the ~/.vagrant/machines/default/virtualbox directory. But I was able through trial and error to figure out the id using vboxmanage list vms and then just ran
echo "2d224f19-42c4-4ed0-a7b7-a16e80a3d015" > .vagrant/machines/default/virtualbox/id.
After doing this the VM is recognized as expected. Now ... why I didn't have an id file ... who knows

[mattyep]

Thanks @reynoldsalec, your solution worked for me.

[ruskotron]

is there a command that will let me reset the UUID when this happens?

[ianks]

@mitchellh any idea where this bug is originating?

[antoinemenini]

same error for me

[DieguinhoHR]

Same error for me.

[hidekuro]

Same error for me in Windows.
In my case, it was because it was not run the command prompt with administrator privileges.
Delete the virtual machine in VirtualBox GUI, and please try to run the command prompt with administrator privileges.

[ruskotron]

Workaround is well-established. Determine UUID using VirtualBox. Set this UUID in all files descended from .vagrant in your current workspace.

Would be handy if vagrant had the capability to detect this condition and recover itself.

[ianks]

Would be handy if vagrant had the capability to detect this condition and recover itself.

:+1:

[johnkramlich]

@mikevanwinkle your workaround worked for me. I'm not sure if this is related but I took a snapshot of the vm prior to the issue showing up. Pure speculation, but possibly the UUID changes when you take a snapshot and the vagrant files do not reflect that change.

[DevJackSmith]

Thanks @reynoldsalec, your solution worked for me too. And I know the cause of my issue:
My macbook was sleeping when it ran out of battery. So vagrant crashed/shutdown. And when I tried to start it up again it didn't look/find existing virtualbox, so it created a new one.
Can we reopen the issue please?

[droidlabour]

1. Create a new_box
2. vagrant ssh new_box and copy .ssh/authorized_keys
3. vagrant halt new_box
4. Replace the new VMDK with the older one.
5. vagrant up new_box [it'll ask for vagrant password ,just enter vagrant which is the default password for vagrant user]
6. To remove that password prompt, just replace the .ssh/authorized_keys with the one at Step 2

[dcorb]

Same here. My Mac ran out of battery and I got this error.
I followed @reynoldsalec solution. Thanks! Step by step:
Run vboxmanage list vms, copy the id of the problematic machine (between curly brackets)
Paste the id in this file, replacing the previous one:
sudo nano .vagrant/machines/default/virtualbox/id

I could "vagrant up" again, as normally.

[tonnyk]

Was experiencing same issue but running
sudo vagrant up solved the issue

[ponchog]

The solution provided by @reynoldsalec and detailed by @dcorb worked for me. Thanks!

[ksingh7]

Thanks solution provided by @reynoldsalec worked for me as well. However this is just a workaround.

@mitchellh if i remember correctly this problem ( VM id got changed for vagrant ) occurred after i created snapshot of my vm. Earlier it was working fine. So do you managed find a permanent fix.

[ruskotron]

The most troubling aspect of this issue is that when it occurs it will trash your existing box!

It seems to me a fundamental flaw that you have a single command ("vagrant up") for both starting an existing box, and provisioning an existing one. The fact that vagrant makes the decision on which to do is based on some flawed logic around persisted UUIDs is a consequent issue.

[ksingh7]

@ruskotron +1
It would be more sensible if we have commands like

vagrant create foo
vagrant up foo
vagrant halt foo

[Dr-Horv]

@ruskotron @ksingh7 I agree. Quite an annoyance. Ran into this issue twice now, first time I didn't bother to find a solution but just created a new box, quite time consuming though.

Separate create/provision from starting a box would be good.

[ruskotron]

I would recommend ditching vagrant altogether for day-to-day management of VMs. It's great for provisioning new VMs, but the ever-present threat of it capriciously destroying your work means you shouldn't use it beyond that. Once you're set up you should just use the VM-system native tools for starting stopping your VMs.

I'm working with VirtualBox so I created this simple script that use the VBoxManage command:

https://gist.github.com/ruskotron/fbf04bac53d86d84498c

It will boot your VM by name (rather than UUID) and ssh into the correct local port (presuming you're using local NAT interface for SSH).

It logs in twice, once to setup your shares and a second time to start your session. Unfortunately as it stands you have to type in a password for each login, but it should be very straightforward to add your ssh private key to ~/.ssh/authorized_keys.

Hopefully this helps some people.

[gitressa]

I ran into this when I wanted to create a new machine, and got the "A VirtualBox machine with the name 'xxxxxxx' already exists." message. As ConnorHoehn commented I changed "boxname: vlad" in settings.yml, and don't get the "vlad_vlad already exists" message, in stead a new VirtualBox machine is created.

[bobwhitelock]

I've had this issue occur as well; in my case this happened when attempting to vagrant reload a box with an nfs shared folder, and then when prompted for admin privileges to enable this I hit ctrl-c rather than enter my password. I then got this issue when trying to reload the box again. Changing the UUID as suggested above did fix this however.

[EIrwin]

Why is this issue closed? It is clearly still an issue and the proposed fixes are not sufficient.

[antarus]

Why is this issue closed?
Every day on vagrant up, the problem occur...

[EIrwin]

@antarus I have the same issue, everyday I am forced to blast my VM and run vagrant up again. I am debating getting rid of Vagrant all together if I can't find a way around this.

[EIrwin]

So I am running Yosemite v10.10.3 and was having this issue frequently (multiple times per day).

I haven't been able to reproduce it 100% of the time, but I started running vagrant suspend prior to shutting down my laptop and it seems to happen less frequently (maybe not at all).

Obviously this is not a solution, but may help us track down the issue quicker.

Any update on this issue being reopened?

[coolbrg]

Thanks @reynoldsalec for the solution. It worked well.

[pitbulmaniak]

Here the solution I found.

1. Go to VirtualBox Manager (GUI) and start the VM with the mentioned name from there.
2. Figure out the id using "vboxmanage list vms" and update the id file (.vagrant/machines/default/virtualbox/id)
3. restart the VM from vagrant with graceful shutdown.
   use

vagrant halt
and then
vagrant up (--provision)

[kpatryk]

Yeap. This problem is still not solved so I guess this ticket should not be closed. I used the latest version of Vagrant 1.7.4 and VirtualBox 5.0.2 under Linux Mint 17 Qiana.

The workaround provided by @reynoldsalec worked for me as well, but it is annoying as it occured to me twice today without any particular reason.

[robsmall]

@pitbulmaniak had the solution that worked for me.

[EIrwin]

Again, although helpful as a temporary fix, @pitbulmaniak and other temporary ways of getting by this are not a solution to the root problem. Lets open the issue and figure out the actual cause and find an actual solution for the long run.

[ruskotron]

Root problem as far as I'm concerned is that the 'up' command does something either benign, or utterly destructive depending on context. That's a regrettable design mistake and any other kind of fix is kludging around it. Unfortunately the book has already been written and published, and it already describes this as the vagrant workflow, so it makes a proper fix a bit of a commercial issue.

However I think a simple error-message when somebody tries to 'up' a VM in a directory where one exists (perhaps following a tutorial in the book) advising them of the new command (e.g. "vagrant start") would do the job nicely!

But ultimately it's hard to expect any heroics though seeing as this is free software.

[cjmosure]

@reynoldsalec solution worked for meh

[juukie]

Tanks @pitbulmaniak. Setting the correct id worked.

[siliconmeadow]

@reynoldsalec ++

[brycepj]

Is it silly to ask why I don't have a dir at ~/.vagrant like everyone is talking about?

I have .vagrant.d but that doesn't have a machines dir.

[adcuz]

@brycepj It's the .vagrant directory in your project folder that contains the machines directory.

[ecokeley]

@reynoldsalec ++
I had 2 versions of the same basebox and somehow the default/id changed to the other VM. I swapped the id and it worked.

[XzAeRo]

The only issue with this (besides all the hassle of the machine id), is that my machine isn't capable of provisioning anymore, because it isn't capable of connecting through ssh (using private key, which I assume it was changed as well).

This is really annoying!

Edit: I removed everything. Destroyed the machines, deleted .vagrant/ folders in all of the projects, AND then deleted the .vagrant.d/ folder, and the behavior is gone after vagrant up'ing a project and halting repeatedly (and suspending my host machine in between which "caused" the error).

[abarry]

This solved the issue for me
First you need the vm's id which you can get with the following command :
vboxmanage list vms

Then run :
echo "ea38889c-1103-4392-84a5-21420e662a18" > .vagrant/machines/cffbodev50/virtualbox/id

and finally run :
vagrant up --no-provision

[mm0]

@abarry's Solution worked for me.

However, SSH connection was having authentication issues as private_key was missing.

Had to copy ~/.vagrant.d/insecure_private_key to .vagrant/machines/default/virtualbox/private_key and then vagrant halt && vagrant up which then regenerated a secure SSH key.

[Harreh]

For me, there was an issue with going from laravel homestead v3.0.2 to v3.1.0. Downgrading back to my original version fixed it

[nirajp]

For me, .vagrant/machines/ already had a default folder, while vagrant up was trying to create a new folder with machinename.
It worked, after I deleted the new machinename that vagrant tried to create & renamed default to machinename.

[bgrrtt]

@DevJackSmith just happened to me.

[nilesh1791]

open virtualbox select the required project and remove. vagrant up --provision.

[naumoff]

5 years and bug still exist. it is shame.

[Icedroid]

I has meet the same issue.

[tolmasky]

Can report this is still happening. Should re-open. Happened to me on Parallels (not VirtualBox).

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.