I have executed following commands (on Windows, using Git Bash) in the directory D:\vagrant\precise32\02-lamp\
$ vagrant box add precise32 http://files.vagrantup.com/precise32.box
$ vagrant init precise32
$ vagrant up
Note. I haven't changed original Vagrantfile.
I thought the directory D:\vagrant\precise32\02-lamp\ would be the place of the VDI-like file but it is not. The working directory serves as the shared folder.
I found the location of the Vagrant box
C:\Users\USER\.vagrant.d\boxes\precise32\0\virtualbox
According to Where is Vagrant saving changes to the VM I found in the VirtualBox GUI the location of the Virtual hard drive file. Which is
C:\Users\USER\VirtualBox VMs\02-lamp_default_1458429875795_57100\
I would like to put this file not in the system drive C:\ but in the data drive which is D:\.
How to set such vagrant configuration?
For VirtualBox, you can change the location of what is known as the Default Machine Folder through the GUI's Preferences dialog box.
This guide, while a couple of years old, works fine and I followed it last week for how to move an existing vagrant/VirtualBox drive to a new location.
EDIT
I have quoted the steps from the above link/guide, for posterity:
Move ~/.vagrant.d to the external drive. I renamed it vagrant_home so
I'd be able to see it without ls -a.
Set VAGRANT_HOME to
/path/to/drive/vagrant_home in ~/.bash_profile.
Open the VirtualBox
app, open Preferences, and set its Default Machine Folder to
/path/to/drive/VirtualBox VMs.
Close VirtualBox.
Move your
VirtualBox VMs folder to the drive. Reopen VirtualBox. You'll see
your VMs are listed as "inaccessible". Remove them from the list.
For
each VM in your VirtualBox VMs folder on the external drive, browse
to its folder in Finder and double-click the .vbox file to restore it
to the VirtualBox Manager. (Is there an easier method than this?)
Finally, move any existing Vagrant directories you've made with
vagrant init (these are the directories with a Vagrantfile in each) to
the external drive. Since these directories only store metadata you
could leave them on your main drive, but it's nice to keep everything
together so you could fairly easily plug the whole drive into another
machine and start your VMs from there.
It is also possible to do this via CLI for when you ALWAYS want to change where Virtualbox creates the VMs during import (because Virtualbox usually wants to put them in a single place rather than tracking wherever they live on the disk the way VMware does it).
Note that changing this setting via the GUI or CLI does NOT move existing VMs, it will simply set a new path to be used by the next machine imported/created. If you have existing machines you want to move, you could shutdown and close all of the instances of Virtualbox and then use mv /old/path /new/path from a cmd/shell window or cut and paste the folder to the new location in the GUI and then change the machinefolder to that path and open Virtualbox and it should detect all the existing VMs.
Using the CLI makes it much easier to script/automate if you have a large number of users needing to move the VMs path out of their home directory to avoid huge files getting automatically backed up. The "best" place for the VMs depends a little bit on your system, but /usr/local/ can be a good place to create a new folder on macOS or Linux.
# Look at the current path
vboxmanage list systemproperties | grep machine
# Output (commented for easier copying and pasting of commands)
# Default machine folder: /Users/<YourUser>/VirtualBox VMs
# Set it to a different folder in your home aka ~
# If you user has access to the path and can create files/folders, then
# the folder doesn't need to exist beforehand, Virtualbox will create it
vboxmanage setproperty machinefolder ~/VirtualMachines
# No output produced
vboxmanage list systemproperties | grep machine
# Output (commented for easier copying and pasting of commands)
# Default machine folder: /Users/<YourUser>/VirtualMachines
You can also set it to a folder outside of home, but this usually requires creation of the folder and the permissions to be fixed before Virtualbox can use it.
# [Optional] Only needed if moving out of the home directory to
# a place the user doesn't have permission to access by default
sudo mkdir -p /usr/local/VirtualMachines && \
sudo chown -R ${USER} /usr/local/VirtualMachines
# If you add : like this `${USER}:` to the above, instead of
# setting the group to admin or wheel it will use the user's default group
# which can be seen by running `id -g`
vboxmanage setproperty machinefolder /usr/local/VirtualMachines
# No output produced
vboxmanage list systemproperties | grep machine
# Output (commented for easier copying and pasting of commands)
# Default machine folder: /usr/local/VirtualMachines
If you change your mind you can easily set it back to the default, but you'll need to move your VMs back again yourself.
vboxmanage setproperty machinefolder default
vboxmanage list systemproperties | grep machine
# Output (commented for easier copying and pasting of commands)
# Default machine folder: /Users/<YourUser>/VirtualBox VMs
For each VM in your VirtualBox VMs folder on the external drive, browse to its folder in Finder and double-click the .vbox file to restore it to the VirtualBox Manager. (Is there an easier method than this?)
There is an easier way...
Go into the VirtualBox Manager GUI click Machine > Add and locate the .vbox you'd like to add back.
Related
Environment: Windows Host running Vagrant and VirtualBox with Ubuntu as the guest OS
Background: Doing basic provisioning inside Vagrantfile
When switching between various sites, I have found that I have to first run vagrant halt, cd in the Windows CLI to the base folder of the site I next want to work on (where the Vagrantfile is stored), and then vagrant up again in order for the synced folder in the guest OS to be mapped correctly to the code folder on the Windows host. This shutting down and restarting takes more time than I would like. I tried simply running vagrant provision after cd'ing in the Windows CLI to the folder of the site I want to work on, but this did not re-map the synced folder. I also tried vagrant suspend, cd'ed to another site folder, and then ran vagrant resume --provision, but this did not re-map the synced folder either. Is there any way to re-map the synced folder without going through the vagrant halt, cd another_site, vagrant up sequence?
1 Vagrantfile = 1 VirtualBox VM
so basically you're in folder1/ with its own Vagrantfile, you have started and managed this VM. You now want to "switch" to another VM (not just a folder) so you need to shutdown the current VM, go to the folder2 and start this VM.
What you want is to have a single VM and multiple project folder (site) linked within this VM. some projects like homestead let you easily managed this. Otherwise you can manage yourself: you need a single Vagrantfile (so it will be only 1 VM) and then all your projects within this project structure.
I want to know logical/conceptual difference between .vagrant and .vagrant.d directory
And also, what is the difference between the following keys
(Please observe the path of these two) one of which is placed in .vagrant directory and the other one in .vagrant.d directory in Windows 7?
C:\Users\username**.vagrant**\machines\default\virtualbox\private_key
C:\Users\username**.vagrant.d**\insecure_private_key
Could not find anywhere in the documentation and on the Internet as well. Thanks in advance.
.vagrant.d is usually placed in your home folder and stores system-wide data/settings, i.e. downloaded vagrant boxes.
.vagrant is placed in your environment/project folder and stores project-specific settings, i.e. current VM settings.
So if you work in user/myproject, create Vagrantfile there and exec vagrant up, then user/myproject/.vagrant directory will be created with VM specific data.
.vagrant.d/insecure_private_key is default insecure private key to access your VMs, it's replaced by vagrant on first VM start with private_key from project's .vagrant directory. In your example: private_key for default VM started with virtualbox provider.
I'm using Vagrant on two machines (home and office) with my working directories stored in Dropbox. I regularly run into the pronblem:
The VirtualBox VM was created with a user that doesn't match the
current user running Vagrant. VirtualBox requires that the same user
be used to manage the VM that was created. Please re-run Vagrant with
that user. This is not a Vagrant issue.
This is easily solved, brute-force, by rm -rf .vagrant, but I'd like to find a more elegant solution -- like an easily automated way to put the .vagrant files elsewhere.
Update
Here's the scenario: a working directory shared between office and home machine via Dropbox.
I vagrant up on office machine, successfully.
I shut down office machine and go home.
I get the message about on vagrant up, saying the id values aren't the same as when I created. (503 vs 501 in general)
I do rm -rf .vagrant and do vagrant up again, successfully.
When I go back to the office, same problem.
On the original issue
I get the message about on vagrant up, saying the id values aren't the
same as when I created. (503 vs 501 in general)
you can fix it by editing your UID in the following file .vagrant\machines\default\virtualbox\creator_uid and changing the 501/503 to a 0. (0 means you run as sudo)
But I think another issue that will pop up is that each of your machines is creating its own VM and stores it under your /Users/user/Documents/Virtual Machines and you're not sharing those files.
when you create a VM using VirtualBox, vb will assign the VM and id - this id is key and will make the link between vagrant and vb. As you create 2 different VMs, the VM have different Id and vagrant is not able to switch between the 2.
Hope this is clear so far, but how to go from there - you would have couple of options:
apparently you don't mind much about the content of the VM (as you do rm -rf so you recreate the VM each time you switch computer) so you can create a .vagrant.home and .vagrant.office and switch the .vagrant to point to the corresponding folder when you change machine so at least you don't need to recreate the VM, you can just start the VM from the corresponding computer. This is not ideal but will work.
you can avoid switching the .vagrant directory from above points by setting the env variable VAGRANT_CWD so you will not store the .vagrant directory under your dropbox account but you can have a script that export this variable and store the .vagrant directory separately on each of your machine (a folder that is not shared) so each machine will create its own VM.
You can have the VAGRANT_CWD set in your bash profile for each computer if you plan to have a different location, but you can also have for example a workhere.sh script that will just do export VAGRANT_CWD=/folder... if you have the same settings on both computer and just do source workhere before you do vagrant up
the other option (I did not test) will involve a few steps: export/import the VM once created from VirtualBox into one computer to another. The issue here will be to keep Id. I am not sure but normally virtual box should keep the Id when you import into the other computer.
you can check the file under /Users/<user>/Library/VirtualBox/VirtualBox.xml and review the entry under <MachineRegistry>, you will get the uuid of the machine entry, make sure they match between your 2 computers after you export/import
for vagrant there is another file you need to sync between your 2 computer /Users/<user>/.vagrant.d/data/machine-index/index which list of available VM on the computer. If you have other VM on one computer not available on this other, it would be ok to sync but best is to copy only the necessary entry for the VM you want to sync.
After you've done this and you sync the .vagrant folder, you should be able to vagrant up from one computer or the other.
Again, I did not test all the steps but I assume this would work.
Few notes:
this will work only if the 2 computers have the same settings (same OS (if not version at least same family), folder structure as some files involve full path, same virtual box version ...)
vagrant box should be in sync on the 2 computers (but I assume this is the case as you can vagrant up from same Vagrantfile)
if you destroy/create the VM on any of the computer, you will need to sync again the Id as virtual box will assign a new Id each time you create a new VM
Vagrant provides an environment variable for exactly this use case: VAGRANT_DOTFILE_PATH
See the documentation here:
https://www.vagrantup.com/docs/other/environmental-variables.html#vagrant_dotfile_path
VAGRANT_DOTFILE_PATH
VAGRANT_DOTFILE_PATH can be set to change the directory where Vagrant stores VM-specific state, such as the VirtualBox VM UUID. By default, this is set to .vagrant. If you keep your Vagrantfile in a Dropbox folder in order to share the folder between your desktop and laptop (for example), Vagrant will overwrite the files in this directory with the details of the VM on the most recently-used host. To avoid this, you could set VAGRANT_DOTFILE_PATH to .vagrant-laptop and .vagrant-desktop on the respective machines. (Remember to update your .gitignore!)
I just trying to add Vagrant to my workflow and I have following probably noob problem. I pull standard hashicorp standard 14.04 image, vagrant up it, SSH to it install my python requirements on it and then then try to execute build commands against code in Vagrant shared folder and run in to problems. Basic errors I get say those locations don't exist or cannot be found.
First action I, go ls /vagrant and can see my shared folders. I cannot cd to them from Vagrant machine I have tried to halt the machine.
Vagrantfile shared folder code.
{"virtualbox":{"/vagrant":{"guestpath":"/vagrant","hostpath":"/Users/Kimmo/Documents/Mist.io","disabled":false}}}
I am using Virtualbox as provider newest version.
My dev machine is OSX 10.9.5
There are not access limitations on the folder itself.
Thanks for you help in advance :)
Does /vagrant exists inside the VM just after you start it ?
If no you can add this parameter : "create":true. According to the doc, for the create: true paramater : If true, the host path will be created if it does not exist. Defaults to false.
If the folder /vagrant exists but you can cd or ls it, you can add parameters wich will define the right/owner of this folder:
owner: (string) the user who should be the owner of this synced folder. By default this will be the SSH user. Some synced folder types don't support modifying the owner.
group: (string) the group that will own the synced folder. By default this will be the SSH user. Some synced folder types don't support modifying the group.
Also for the hostpath parameter you have to give him a folder path, not a file path. In your conf I can see: "hostpath":"/Users/Kimmo/Documents/Mist.io". If Mist.io is a file and you want to access this file inside your VM, just give the path to the folder containing this file, /Users/Kimmo/Documents in your case.
I have created a puppet/vagrant/VirtualBox generated installation of Ubuntu running on a Windows host; see https://bitbucket.org/dmenne/rstudio-shiny-server-on-ubuntu for details. This allows users to run RStudio and Shiny server on Windows. In Vagrantfile, I have
config.vm.synced_folder "shiny-server", "/srv/shiny-server", create:true
to create a shared folder. When I start the VM with vagrant up or vagrant reload, everything works ok.
One customer does not want to install vagrant etc, and asks for a standalone VM to be started/stopped with the VirtualBox Manager on Windows. However, after I shutdown a vagrant-booted VM Box, my synced folders do not connect/mount again on VM restart, even if they turn up correctly in the shared folders dialog of the VirtualBox Manager.
How can I shrink-wrap a Vagrant-generated VM so it can be started/stopped without Vagrant?
EDIT March 2015:
I still could not resolve this. When I force automount, on restore media/sf_<folder> is synced, not the required folder. How can I force VirtualBox to use sync-template from Vagrantfile after a restart?
And how do I force automount in vagrant without doing it manually.
After some further debugging and the lack of response to a similar query on the google/vagrant forum:
When you use synced folders in puppet, you must restart VirtualBox with vagrant up or vagrant reload
If you use the VirtualBox GUI to stop/restart, automount restores the synced folders incorrectly, i.e. to /media/sf_; this cannot be corrected without using a vagrant reload,
The only alternative without vagrant is to save the state in VirtualBox (CTRL-V). After a restart, the synced folders are restored correctly. However, it is probably impossible to force end-users to always manually save the state.
To use persistent synced folders, you must use upstart or similar methods; it cannot be done with Vagrantfile only.
See also Alvaro's response:
https://groups.google.com/forum/#!topic/vagrant-up/oBU0kqPLzYk
There are two parts to getting this to work. First, we need to get the synced folders automatically mounting from the host, which is the case of a Linux guest is a bit of a misnomer, because it's more "being automatically made available for mounting", or "automatically shared". For each shared folder (gemainsame ordner) you must turn on auto mount (automatische einbinden)
To do this, click on the edit shared folder icon for each share
And check auto mount (automatische einbinden)
At the end you should see "Ja" under "automatische Einbinden" for all the shares to should auto-sync
If the guest system is Ubuntu (or any Linux system), then having done this, all the synced folders should now be visible within to the guest, but the guest won't automatically mount them. You will need to put an entry into your /etc/fstab for each folder you want automatically mounted in the guest.
Since you are using VirtualBox, Vagrant will presumably choose to implement the synced folders using VirutalBox's shared folder provisioning method. To the guest system in Linux, depending on your version of Guest Additions, this looks like either an smb/cifs share with the name (by default) of //vboxsrv/, or a file system of type "vboxsf".
The vboxsf is from more recent version of guest additions (4.1.18 onwards at least), and automount option 'just works'. On booting a Linux guest VM with an automount set share called 'bob', the system should mount Bob automatically (without an fstab entry) at /media/sf_Bob. The full output of the relevant line from mount is
none on media/sf_Bob type vboxsf (rw,nodev,relatime)
If this isn't working, check that you can see a samba network share from within your guest system, using smbclient or smbtree. It should look like //vboxsrv/Bob. In your fstab then, you would add a line like this
#share name #mount point in guest #fstype #options #dump/pass
//vboxsrv/Bob /mnt/Bob cifs auto,rw 0 0
You may wish to read the manual page for mount.cifs to tune the options for each mount, especially with regards to file ownership and permissions (relevant options to investigate are forceuid, uid, forcegid, gid, file_mode, and dir_mode)