Moving on from Vagrant

My daily routine for starting each of my Virtual Machines has become:

  • First check the UUIDs for the VM:
 $ VBoxManage list vms | grep -i hero7
"hero7" {2856ae7c-bbb0-4110-8b5d-126abb6f2135}
  • Then check the UUIDs that Vagrant has stored:
 $ find .vagrant/ -type f -print -exec cat {} \; -exec echo \; .vagrant/machines/hero7/virtualbox/action_provision
1.5:ccd5fc98-f80f-45d9-9e26-40e1ad92ee08
.vagrant/machines/hero7/virtualbox/action_set_name
1429893049
.vagrant/machines/hero7/virtualbox/id
ccd5fc98-f80f-45d9-9e26-40e1ad92ee08
.vagrant/machines/hero7/virtualbox/index_uuid
9068bc65efae46509227f81413018494
.vagrant/machines/hero7/virtualbox/synced_folders
{"virtualbox":{"/media/sf_sharedVMFolder":{"guestpath":"/media/sf_sharedVMFolder","hostpath":"C:/sharedVMFolder","disabled":false},"/nasnfs":{"guestpath":"/nasnfs","hostpath":"//NAS/nasnfs","disabled":false},"/vagrant":{"guestpath":"/vagrant","hostpath":"C:/Users/rrusk/Documents/vagrant/hero7","disabled":false}}}

If the UUIDs match I can go ahead and start my VM in the usual way with “vagrant up”.

If they don’t match however, I have to take remedial action, or Vagrant will actually trash my VM! Vagrant has the same command (“vagrant up”) for starting a new VM, as it does for creating a new VM from scratch, and it decides whether or not to destroy all your work to-date based on whether or not these VMs match!

First I’ve got to edit each of the files with the faulty UUID, and replace it with the one provided by VBoxManage:

 $ vi .vagrant/machines/hero7/virtualbox/action_provision
 $ vi .vagrant/machines/hero7/virtualbox/id

This used to be all I had to do. This was sufficient as a fix, and then I upgraded to a newer version of Vagrant hoping the issue would be resolved. It wasn’t and now I have to replace some stupid ssh private key as well!

 $ rm .vagrant/machines/freeradius/virtualbox/private_key

And then on boot I’ll get the message saying it is generating a new private key (presumably tied to the UUID…), but sometimes it doesn’t and I have to ssh into the VM manually and replace the public key!

 $ curl https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub -o .ssh/authorized_keys
 $ chmod 600 .ssh/authorized_keys

It is unclear how or why the UUIDs stored become out of sync with VirtualBox. I’ve tried various ways to prevent this happening. I’ve tried ensuring graceful shut down of my VMs, and I’ve tried getting vagrant to shut them down itself (vagrant halt), and I’ve even tried being more patient when shutting down my own work machine (the “host” environment) but to no avail. There is no predictable pattern, and some days I come in and the UUIDs just don’t match!

But that is forgivable. As a programmer myself I know how hard it can be to synchronise state between two separate applications, but what is unforgivable is that vagrant has a single command for both starting & trashing your VM (vagrant up) that takes its cue on which to do, from this single flimsy premise!

Could they not have a separate command in each instance? I’ve raised a ticket asking just that, but after a few weeks I have yet to see any response, and in the meantime the other ticket where people are seeking remedies continues to hop!

I’ve been dealing with this problem for a few months now, and I’ve had to restore my work from scratch each time. As an exercise in developing understanding of the stuff I’m working on it has been okay, but it hasn’t been kind to my deadlines.

Today I’ve had enough and I’ve just decided to start using “VBoxManage” directly to handle my VirtualBox VMs. The convenience that Vagrant provides just isn’t worth the pain it regularly inflicts upon me.

For starters then, to boot my VM headless all I need to do is:

 $ VBoxManage startvm hero7 --type headless

To find out what port I can ssh in I can do:

 $ VBoxManage showvminfo hero7 --machinereadable | grep "^Forwarding"  
Forwarding(0)="ssh,tcp,,1122,,22"

If I need to change the port (perhaps due to another clashing VM):

 $ VBoxManage controlvm hero7 natpf1 ssh,tcp,,2222,,22

Then just ssh in the usual way:

 $ ssh vagrant@localhost -p 2222

Then once logged in I can (as root) mount my “/vagrant” folder with:

 # mount.vboxsf vagrant /vagrant

I’ll add more commands as I think of them, for my own reference as much as for the benefit of others! It’s a little trickier than using Vagrant to be sure, but at least it’s safe!

Vagrant is very definitely a cool tool by the way. If you want to quickly create and provision a VM it’s your only man, particularly in a devops setting, and it has some very powerful tools such as packer and vagrant cloud that make it indispensable!

For day-to-day development however it just has too much potential for creating a mess, and so for that reason I’m done with it as a developer tool. Quite embarrassing really as up to now I have been championing it amongst my colleagues, but sure we all make mistakes!

Leave a Reply

Your email address will not be published.