Jonathan's Pancheria

dotcom Thousandaire

I forgot to document this after the 1st Vagrant-based development VM I set up, so I’ll do it now so I do not lose it again.

Virtualbox disables symbolic links on host folders shared into the guest as of 4.1.8

Just stop. and. enjoy. that. for. a. second.

Then peruse this ticket in the Virtualbox bug tracker (but read on in this post before trying to fix the problem because I will point you to the correct fix in a bit). I totally get why, in the general case they needed to do this. If you’re using Virtualbox in any sort of production environment, any issues with privilege escalation or sandbox breakout are bad, bad, bad.

However, I’m using Virtualbox as part of Vagrant to manage development VMs. My use case is a bit different. I want to fire up a VM into which I share my source code folders from my host box into one or more VMs. I do this so I can, for example, just have one text editor open with one source tree on my host, but have it running in a VM. I can build or recreate Vagrant/virtualbox VMs at a whim and not worry about losing my source code in an accidental delete. I can probably think of more use cases.

With the default settings as shipped as of 4.1.8, I can’t do that anymore. The problem is that the chance that any reasonable Linux software development ends up making symlinks around the source dir (which, remember, is shared from the host in my case) approaches 100%. In fact, if you’re using node.js and using most any package via npm it probably defaults to exactly 100%. Symlinks, which are disabled by default.

Fortunately, all is not lost.

How to set Virtualbox settings back so you can share a host folder into a guest and make symlinks

Refer to this comment on the ticket in the ticket I referenced earlier in the Virtualbox bug tracker for instructions on how to fix the problem. The one trick to remember is that the SHARE_NAME is actually the name of the host “Filesystem” within the VM. So consider this example from one of my vagrant VMs:

vagrant@precise64:/vm_src/$ df
Filesystem                 1K-blocks      Used Available Use% Mounted on
/dev/mapper/precise64-root  82711212   3063948  75504980   4% /
udev                          178068        12    178056   1% /dev
tmpfs                          74852       284     74568   1% /run
none                            5120         0      5120   0% /run/lock
none                          187128         0    187128   0% /run/shm
/dev/sda1                     233191     27483    193267  13% /boot
v-data                     344580864 303729368  40851496  89% /directory_you_mounted_from_your_host_with_your_files
v-root                     344580864 303729368  40851496  89% /vagrant
v-csc-1                    344580864 303729368  40851496  89% /tmp/vagrant-chef-1/chef-solo-1/cookbooks

You actually want to run the following command to have symlinks re-enabled on the host folder you’ve shared out as directory_you_mounted_from_your_host_with_your_files, you actually want to issue the following command (replacing vagrant_server_name_plus_random_number with the actual name of your server):

VBoxManage setextradata vagrant_server_name_plus_random_number VBoxInternal2/SharedFoldersEnableSymlinksCreate/v-data 1

You will probably have to look in the Virtualbox admin GUI to find the actual server name because when you create a box with vagrant it sticks an arbitrary number onto the end of the name you give your server. Notice carefully there’s a 1 at the end of that command, which means to set that value to “true”.

Do the above, then (to be safe, I haven’t verified the minimum set of commands to make it work):

vagrant reload _your_vm_name_

and then vagrant ssh back in and symlinks will now work within the guest in the shared host folder.

Published on 14/01/2013 at 11:29PM .

0 comments

I am doing a bunch of work in VMs managed with Vagrant+chef, and I have several different VMs configured for different projects/roles so that I can do dev work on a VM that has just the set of things on it that a QA or production box will have.  To make it easier, I put together some bash functions and a tab completion setup in my .bash_profile to make it easier to work with vagrant and multiple VMs.  I will describe what I wanted to accomplish and how I did it.

Rationale

What I wanted was to be able to have multiple VMs and have it be easy to run a command against any of them without having to cd (change directory) to the correct directory for a server and then do what I needed. The idea is that the following commands should behave as follows:

  • vag server_a up: bring server_a up via vagrant up in server_a’s directory
  • vag server_name vagrant_command …: in general, run the vagrant command vagrant_command for the server server_name
  • firevm server_name: this is the one special command addition I made. I find it useful when I’m doing work on a server to bring it up from a suspended state, ssh into it, do my thing, then suspend the server when I log out of the ssh session. firevm is the name of the command I wanted to do that
  • Tab completion should work on the vag AND firevm command, so that if I tab-complete where server_name should be I should see a list of the servers available. For vag I also want it so that if I tab-complete on vagrant_command I get auto-complete against the list of vagrant subcommands

How I Did It

Where the Vagrant-powered VMs have to live

To make the scripting easy, I decided that all the Vagrant setups would live in one directory.

Setting Up the .bash_profile file

I put the following code in my ~/.bash_profile file (also available in this gist): 

The vag function

The vag function takes care of the vag server_name vagrant_sub-command ….

Implementing tab completion

The _vagrant_servers() function and the complete -F … command that follows it handles the tab completion. For the first argument to the commands it completes for, it shows the list of servers (directory names) in the common directory that your vagrant servers live in. If you are using the vag command, it will provide tab completion on the second argument with the list of vagrant sub-commands available. The list of subcommands was scraped out of the invocation of the vagrant command line with no arguments earlier in the script where VAGRANT_SUBCMDS is defined. No other arguments past those supported get any tab completion.

The firevm special command

Finally, the firevm shell function takes care of the special handling to resume the vm, ssh into it, and then suspend it.

Published on 11/01/2013 at 12:31AM under . Tags , , , , , ,

0 comments

Powered by Typo – Thème Frédéric de Villamil | Photo L. Lemos