Two (accidental) VirtualBox machines from one Vagrant file

[Stephen Platz]

I recently merged some code from the main development branch of our project repository into my local working branch. Later I tried to ssh into my Vagrant environment and got the following message

The provider for this Vagrant-managed machine is reporting that it

is not yet ready for SSH. Depending on your provider this can carry

different meanings. Make sure your machine is created and running and

try again. Additionally, check the output of `vagrant status` to verify

that the machine is in the state that you expect. If you continue to

get this error message, please view the documentation for the provider

you're using.

vagrant status showed that my (running) machine had not been created! I opened the VirtualBox GUI and saw that it was indeed running, so I shut it down in that interface. When I ran vagrant up again, it provisioned a new machine! Now in the VirtualBox GUI, there are two default machines for this project. One of them is serving the old site and database etc. that I need for development, but I'm not able to use it with vagrant up or even vagrant up NAME (with the NAME taken from the VirtualBox interface). Merging the code should not have affected my Vagrant environment in any way that I can imagine, the Vagrantfile was completely unchanged. I'm wondering what I should do next. Is there an advanced way for me to continue using the earlier provisioned machine? 

[Alvaro Miranda Aguilera]

Hello,

When you do vagrant up, Vagrant read the Vagrantfile.

them it create a folder .vagrant and there is information there that tells vagrant what Box is being used.

Say we start creating a new Vagrantfile:

0 kikitux@mini ~/Downloads/precise64 (master) $ vagrant status

..

default                   not created 

.. 

0 kikitux@mini ~/Downloads/precise64 (master) $ VBoxManage list vms

 

There is no boxes in Virtualbox at this point

After the VM starts:

0 kikitux@z2-3 ~/Downloads/precise64 (master) $ VBoxManage list vms

"precise64_default_1476037178626_18578" {0839bd49-bee9-4ecf-be14-a38b202b13c4}

if we look for this id, you will notice:

0 kikitux@z2-3 ~/Downloads/precise64 (master) $ grep -iR 0839bd49-bee9-4ecf-be14-a38b202b13c4 .

./.vagrant/machines/default/virtualbox/id:0839bd49-bee9-4ecf-be14-a38b202b13c4

So, if you want to recover the VM, you can just update .vagrant/machines/default/virtualbox/id

This .vagrant folder should be excluded from the VCS, since is not meant to be shared, so if you have say a folder in dropbox or a share computer, the 2nd person doing vagrant up will check the box is not there, will create a new one, and will override the file.

Hope this helps.

Alvaro.

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/vagrant/issues
IRC: #vagrant on Freenode
---
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/47ace2ca-4347-4064-ba99-caac80c10a74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alvaro