Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify VVV in Dropbox #88

Closed
jeremyfelt opened this issue Jun 30, 2013 · 10 comments
Closed

Clarify VVV in Dropbox #88

jeremyfelt opened this issue Jun 30, 2013 · 10 comments

Comments

@jeremyfelt
Copy link
Member

This isn't really a VVV problem, but we're in a decent place to figure it out and at least document it somewhere. I'm not entirely sure it's a problem yet either.

It seems that strange things can happen if you initiate a vagrant up from within a Dropbox directory. My working theory is that the .vagrant/ directory created during the process syncs with Dropbox and then somehow loses track of its uniqueness at some point, so when you do vagrant halt and vagrant up again, a second VM launches in Virtualbox and causes strangeness.

Totally unverified. And now that I'm writing this up without the book in front of me, I forget the setting that can be changed (I think) to move the .vagrant/ directory somewhere else.

All aside. I want to test VVV in Dropbox and see if we can clarify some behavior around it.

@teraphy
Copy link
Contributor

teraphy commented Jul 1, 2013

You are correct! Multiple boxes will accumulate by utilizing Dropbox as the id changes. While not a nice solution here is what I have done to avoid it in Windows:

* System 1: vagrant up then vagrant halt
* System 2: vagrant up then vagrant halt
* System 1:
 * Open the 'id' file and copy the uuid from: {your dropbox path}/vagrant-local/.vagrant/machines/default/virtualbox/id
 * Open the 'VirtualBox.xml': %userprofile%/.VirtualBox/VirtualBox.xml
 * Replace the current uuid under <MachineEntry uuid="{ REPLACE UUID }" src="PATH TO .VBOX FILE"> (~line 21)
 * Open the .vbox file in the above lines src entry
 * Replace the current uuid under <Machine uuid="{ REPLACE UUID }" (~line 9)

Still have to be careful with both VMs running as the databases might conflict due to them being in use.
Hope that helps!

@jeremyfelt
Copy link
Member Author

Awesome, thanks @teraphy!

Any chance that this can happen when using only one system? I think they symptom has come up there as well when just using Dropbox as a cheap backup.

@teraphy
Copy link
Contributor

teraphy commented Jul 2, 2013

I now see you meant one system. I figured with a Dropbox you were sharing.
I probably can't answer that with good data. When I halt a VM it tends to fail on me due to a Virtualbox error related to networking. In this case I was believing it didn't clean itself up properly (maybe in part due to Dropbox syncing files?) and would create a new VM. At which point I realized it was due to switching machines. I've always had my files in Dropbox to be honest.
With every halt it removes the id file within the .vagrant folder. Might be worth checking the xml files in the user path to see if Virtualbox cleaned them up. Also it might help to run the command vboxmanage.exe vms list found within the Virtualbox path to see if the VMs are valid or not.

@jeremyfelt
Copy link
Member Author

Closing this out with some info for future viewers:

  1. I would bet on random issues popping up from time to time when multiple machines are trying to share the same .vagrant/ directory created on vagrant up that is stored in a shared in a Dropbox directory
  2. If you set the environment variable VAGRANT_HOME to something other than that shared Dropbox directory on each machine that intends to share that Vagrant setup, then the sky should be the limit.

@simspace-dr
Copy link

I just learned about the VAGRANT_DOTFILE_PATH env variable here:
hashicorp/vagrant#3362

This simple change enables one vagrant environment on Dropbox or Copy (http://www.copy.com) by creating unique .vagrant directories for each computer. I did this on three different macs for vvv-apache and it worked perfectly.

I now have vvv-apache shared across three macs using Copy (similar to Dropbox).
In the vvv-apache directory are three .vagrant directories:

   .vagrant-home 
   .vagrant-work
   .vagrant-laptop

Here's how it's done on each computer ...

1. vagrant halt to shutdown machines
2. added "export VAGRANT_DOTFILE_PATH=.vagrant-laptop" to ~/.bashrc or  ~/.bashrc_profile
3. open new terminals to inherit the new env var
4. move .vagrant to .vagrant-laptop
5. vagrant up -- it works!
6. change "/.vagrant" to "/.vagrant*" in my .gitignore

Hope you find this helpful!
Chris S.

@kopepasah
Copy link
Contributor

@simspace-dr I've confirmed that this works (thanks); however, instead of modifying the .gitignore (which is shared by the repo), you can add an exclusion to .git/info/exclude instead.

Cheers.

@jeremyfelt jeremyfelt removed this from the 0.9 Release milestone Feb 22, 2015
@colin-marshall
Copy link

@simspace-dr @jeremyfelt @kopepasah:
Looking to set this up between my laptop and desktop and I'm a little confused about the workflow in regards to making sure the database stays synced between computers.

  • I'm assuming that I should never run vagrant up on one computer before running vagrant halt on the other computer so that they're never running the VM at the same time. Is this correct?
  • Do I need to write a script for importing the databases every time I switch computers and run vagrant up, even if I have setup the VAGRANT_DOTFILE_PATH on each system?

Thanks!

@kopepasah
Copy link
Contributor

@colin-marshall it is my understanding that syncing databases between machines is not possible, since there will be an entirely different machine.

@colin-marshall
Copy link

@kopepasah ok thanks, that answers my 2nd question. I believe it is possible to do but it would involve writing a script that would import the database backup files (created by the vagrant triggers plugin) on every vagrant up.

Were you just doing that manually @kopepasah or just not messing with the database on one of the systems?

@lock
Copy link

lock bot commented Feb 22, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Feb 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants