Vagrant: Re-associate vagrant with vm

[ReeceMarsland]

Vagrant has lost it's association with the already made vm and I need to re-associate it somehow. I found this thread: http://stackoverflow.com/questions/9434313/how-do-i-associate-a-vagrant-project-directory-with-an-existing-virtualbox-vm but the trick described does not work for me. Changing the id files causes 'vagrant status' to report that the machine is yet to be created. I can't even get vagrant to re-associate with the uuid of the vm it just built once I've changed the id file to something different.

I think the issue was caused by running:
vagrant up
vagrant suspend
sudo vagrant up (this created a new box and caused the link to be lost)

I can't see a command or config file setting that would enable me to force the path to the vm.

Running Vagrant version 1.2.2
Thanks

[thasmo]

For Vagrant 1.2.x there should be a file in ".vagrant\machines\default\virtualbox\id" with the VM id inside. The available VMs (of VirtualBox) should be in "C:\Users\$USER\VirtualBox VMs". There you can find a file called .vbox which holds the VM configuration using XML. The "Machine" node holds the machine id which you can copy and paste into the id file. Works for me I think.

[thasmo]

As for the bug - yes this seems to happen sometimes. There should be a bugreport somewhere I think. I suspect VirtualBox (to be more precise, "VBoxManage.exe") to freeze sometimes, for whatever reason, and when this happens, Vagrant assumes the VM does not exist. Not sure if that's the reason.

[ReeceMarsland]

I've located the correct uuid and edited that file but vagrant just won't pick it up, is there any other way to pair it up again with the vm?

Thanks

[mobmad]

Had the same issue and found a workaround. This is how it occurred:

1. Had two VMs running, went home for the day
2. Windows updated and restarted during the night
3. Came to work, fired up cygwin and ran vagrant up dev. Saw that vagrant began creating a new box and cancelled.
4. Opened Virtualbox and saw that no VMs where listed. Found the path to "Default Machine Folder", opened it in Windows and saw that my previous VMs still existed on disk
5. Deleted the thrid VM on disk that was accidentally created with "vagrant up"
6. Readded the old VMs to Virtualbox by going to "Machine -> Add..." and adding the VMs from disk manually
7. Ran vagrant status

At this point the VMs where still listed as "(not created)".

1. Ran VBoxManage list vms to find the ids of the VMs
2. Went in to ./vagrant/machines/dev/virtualbox/id and updated the id
3. Ran vagrant status

At this point the VMs where STILL listed as (not created). Began debugging by putting puts around in vagrant source code (tip if you ever need to do this, manipulate vagrant directly in C:\vagrant\embedded\gems\vagrant-1.2.1)

Found the issue why vagrant wouldn't report status correctly, even if the IDs matched. When I manipulated the ID directly in ./vagrant/machines/dev/virtualbox/id, I accidentally added a newline to the end.

Without the newline (eg. echo -n "insert-hash-to-vm-here" > vagrant/machines/dev/virtualbox/id), vagrant status finally worked again. I suspect this is your issue as well @ReeceMarsland ?

I still don't know what got VirtualBox to "loose" the VMs in the first place, but as far I can tell, that's a bug in VirtualBox and not Vagrant.

Vagrant version: 1.2.1
VirtualBox version: 4.2.12 r84980
Windows 7

[starrychloe]

2nd this bug.

$ vagrant status
Current machine states:

default                  not created (virtualbox)

The environment has not yet been created. Run `vagrant up` to
create the environment. If a machine is not created, only the
default provider will be shown. So if a provider is not listed,
then the machine is not created for that environment.

Chloe@xps ~/mydocuments/ODesk/AIDC
$ cat -n .vagrant/machines/default/virtualbox/id
     1  16d4bcdc-a907-42eb-962f-faef2c68f13c

Chloe@xps ~/mydocuments/ODesk/AIDC
$ n++ .vagrant/machines/default/virtualbox/id

Chloe@xps ~/mydocuments/ODesk/AIDC
$ cat -n .vagrant/machines/default/virtualbox/id
     1  16d4bcdc-a907-42eb-962f-faef2c68f13c
Chloe@xps ~/mydocuments/ODesk/AIDC
$ vagrant status
Current machine states:

default                  poweroff (virtualbox)

The VM is powered off. To restart the VM, simply run `vagrant up`

[gnat42]

Thanks @mobmad that fixed it for me as well.

Seems like vagrant should be a bit more graceful and handle newlines or only read the first line or something

[scotthelm]

+1 for removal of newline at the end of the id file. Worked for me. I'm going to look around and see where that's file's read and put a chomp in there or something. Crisis averted. Thanks @mobmad and @starrychloe

[tiagojco]

+1
Thanks @mobmad . Nice job :+1:

[thestupidestthing]

oh gosh. good catch. vim was sticking a newline in there. thanks.

[4fthawaiian]

"echo -n" ftw!

Spent several hours getting this VM just the way I wanted it. Thanks SO much.

[fgrehm]

@ReeceMarsland would you be able to confirm that it works with the 'echo -n' so we can close this issue? ;)

[livid]

Encounter this issue today. echo -n fixed the problem.

I guess this could be fixed in code where UUID is read from id?

[4fthawaiian]

Isn't the real issue the fact that the vm became disassociated in the first place? I don't see the fact that we've found a workaround as a resolution to the issue. Or, maybe I'm over-thinking it?

[thasmo]

I think this was fixed in #2024.

[livid]

So this issue is fixed in #2024 on Aug 9, and I had the problem in 1.2.7, which is packaged on Jul 28. So I guess this fix will be included in next release.

[thasmo]

Yes. The next release should be 1.3.0, which includes the fix listed here: "core: strip newlines off of ID file values [GH-2024]" https://github.com/mitchellh/vagrant/blob/master/CHANGELOG.md

[fgrehm]

@thasmo tks for pointing out! I believe we are good to close this issue as GH-2024 has been merged :)

@ReeceMarsland please let us know if you are still having issues with this ;)

[jasonm23]

+1 to watch this issue

[franciscodelgadodev]

Thanks @mobmad ! it works! :)

[benissimo]

@mobmad Thank you _very very much_ for listing the steps you took to manually re-associate your vm. You saved me a lot of pain. Much appreciated!

[funroll]

+1 @benissimo - Thanks very much @mobmad.

I had to change the path, here's the final command that worked for me:

echo -n "19262da0-4890-4f58-9fab-954c379dac15" > .vagrant/machines/default/virtualbox/id

[ldong]

@mobmad, any idea on mac vagrant 1.6 which its path is ~/.vagrant.d instead of ~/.vagrant
Thank you in advance.

[drpebcak]

@ldong the steps are the same on all platforms. ~/.vagrant.d lives in your home folder. He's telling you to modify the .vagrant folder that is in your project.

[ldong]

@drpebcak Thanks for the clarification. I eventually got it working, thanks @mobmad .

[pruthvis]

@mobmad :+1:

[adrianmaurer]

thanks @mobmad +1

[zkwsk]

Here is the exact process I followed to fix this on Mac OS X 10.9 and vagrant 1.6.3:

• Get the VM id of the disassociated vm with VboxManage list vms
• Removed the VM from VirtualBox _without_ deleting the data.
• Moved the data out of the default VM directory.
• "vagrant up" to spin up a new machine with the original vagrantfile to regenerate the .vagrant dir.
• Delete the new machine from Virtual Box and remove data this time.
• Moved the old VM back into the VirtualBox folder and added it using Machine > Add...
• Edited .vagrant/machines/default/virtualbox/id and replaced the id with the one retrieved in step one (beware of line breaks)
• Vagrant up -> Success!

[vartagg]

@mobmad gj.
Vagrant 1.6.5 on Windows 7: regression bug.

[rominf]

@webconsult, thank you for howto. It worked for me. Just to add my two cents:

1. It causes to run provisioning one more time (for a dummy machine, or for the old one if you killed dummy machine before provisioning).
2. I skipped moving VM data and it worked just fine.

[goliney]

@mobmad , you saved my day!

[mdular]

+1

[robe01]

I had the same problem. I solved it by going back to an older version of my ".vagrant" folder by using Windows 8.1's 'FileHistory' programme.

It seems that virtualbox deleted all of the files in ".vagrant\machines\default\virtualbox" for some reason, so when I went to 'vagrant up' again, new files were put in place for a new vagrant machine. Thank god I back-up my work.

[paulschreiber]

I hit this bug with VIP Quickstart. @mobmad's solution worked for me.

$ VBoxManage list vms|grep quickstart
"vip-quickstart_default_1431365185830_12124" {50feafd3-74cd-40b5-a170-3c976348de27}
$ echo -n "50feafd3-74cd-40b5-a170-3c976348de27" > .vagrant/machines/default/virtualbox/id

[tylerehc]

I'm having some trouble finding my .vagrant file. I've checked the directory with vagrantfile in it. Any suggestions?

[jasonm23]

@catalyze it will be hidden by default, if on OSX or Linux you can do

ls -a

From a terminal/shell, to include hidden files. I guess you're not on Windows, because it would show the file anyway (IIRC).

[Umojivity1]

Thank y'all :+1:

[jpSimkins]

+1
Thanks @mobmad . Nice job :+1:

[tylerehc]

@jasonm23 Bingo, that was it. Thanks!

[janzenz]

Question: Why does vagrant disassociate itself? I have ignored .vagrant in my .gitignore file. This happens randomly or when I do git checkout. Vagrantfile is part of my git.

[rlam3]

but why does the command vagrant global-status not see it?

[benlk]

If the key-based ssh authentication no longer works after following @mobmad's instructions, you can get in with the user:pass combo vagrant:vagrant (usually).

To regain key-based ssh authentication, follow these instructions: https://gist.github.com/benlk/d0cf2b3251e6c09758f36ccd14d6894e

[fabacab]

but why does the command vagrant global-status not see it?

@rlam3 Vagrant's global-status uses a different index file, stored somewhere in $HOME. Specifically, in ~/.vagrant.d/data/machine-index/index file on *nix hosts. This is a JSON file, with the individual machines keyed by Vagrant's UUID. The UUID here is different than the VM provider's UUID. You can find it in the specific Vagrant environment's hidden directory, something like .vagrant/machines/default/virtualbox/index_uuid (for a VirtualBox-backed VM).

Check that index file, and if your machine's UUID is not listed, you'll have to manually correct the index file to include it. Once you re-add your machine description as a JSON object to the machines key indexed by the Vagrant machine's index_uuid, the global-status command will recognize your vagrant VM again.

[varun50]

@mobmad Great thanks. Was wondering what's going wrong and couldn't figure out the problem until I saw this. Another abnormal feature I observed is my ./vagrant/machines/dev/virtualbox/ was completely wiped off, luckily mine is a three node VM so I copied the config files from other node and changed the ID and it worked. Able to get my old vm back. Thanks a lot.

[krcrawford]

@mobmad and @benlk:

After copying the id back to the empty machine folder, you will find that the ssh access is non-existent.

The quicker fix for regaining your ssh access from your Vagrantfile location for your guest machine is:

cp .vagrant/machines/default/virtualbox/private_key .vagrant/machines/<your-guest-machine-name>/virtualbox

Of course, this only works in cases where there are no specialized private key additions.

[inoas]

For me the whole folder became empty in .vagrant/machines/default/virtualbox/

It became empty when OS X decided to kill processes on 5% battery and then I vagrant up'ed (while it probably shut down).

used VBoxManage list vms to pick up the uuid, copied all the files that where missing from some other box, adapted the uuid, vagrant status said ok, vagrant up worked again.

[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.