Anyone who has worked with standalone web apps knows that typically no two environments are the same, so they need to be tested and tweaked in a staged environment.  As a result, our consultants need a fast and reproducible method for creating environments to run and test installations, upgrades and new plugins. Vagrant addresses this need by making it easy to create and control virtual machines.  Out of the box, both Vagrant and VirtualBox are available to you free of charge if you don’t mind using VirtualBox as the virtualization engine.  Relatively recently, Vagrant provided an alternative for those of us that prefer to use VMWare Fusion or Workstation.  If you have paid for VMWare, why would you want to use the free alternative to it….right? In this article I’m going to review the VMWare plugin to determine whether or not it’s worth the extra $80 it costs to have this additional provider option.
We have spent a considerable amount of time creating Salt Stack state files for configurations specific to Atlassian applications.  And in my last blog I detailed a method of creating VM’s using Vagrant paired with Salt Stack for configuration management.
So, to test the difference between the two providers I’ll be installing the following software via Salt Stack:

  1. The latest versions of the Atlassian apps Jira and Confluence
  2. Users and groups
  3. Java7
  4. Nginx web-server
  5. PostgreSQL and blank databases for Jira and Confluence to use.

The idea with this is that as soon as the box is up and running, everything needed is installed and we can immediately access Jira and Confluence in a browser to complete setup.  Further, I need to be able to quickly destroy and recreate the box after making changes to configurations.  VirtualBox works quite well for these purposes so I’m going to compare this same set of configurations using the VMWare Fusion provider.  My tests are being done from a 2013 MacBook Pro with 16g RAM, with 500 gig SSD drive, and with the guest OS being Ubuntu 12.04.

Installing the VMWare Provider

The VMWare provider plugin is quite easy to install.  First go to http://www.vagrantup.com/vmware to purchase the license.  You will receive an email from HashiCorp with instructions on how to download the license file.  Once you have the license.lic file, issue the following commands and you’re all set!

Install Fusion Plugin
vagrant plugin install vagrant-vmware-fusion
vagrant plugin license vagrant-vmware-fusion license.lic
Install Workstation Plugin
vagrant plugin install vagrant-vmware-workstation
vagrant plugin license vagrant-vmware-workstation license.lic

First Impressions

The first thing I tried was to simply copy the directory containing my files that work fine under VirtualBox.  With the VirtualBox provider, all I have to do is navigate to the directory of the VagrantFile and type “vagrant up” to fire up the VM.  With the VMWare provider you have to add a “–provider vmware_fusion” to the command.  My first attempt resulted in an error.

An active machine was found with a different provider. Vagrant
currently allows each machine to be brought up with only a single
provider at a time. A future version will remove this limitation.
Until then, please destroy the existing machine to up with a new
provider.
Machine name: isos-test-com.isos-test.com
Active provider: virtualbox
Requested provider: vmware_fusion

Fortunately with the purchase of the provider plugin you get free support!  After contacting support, I found that copying the whole directory was a mistake because the hidden “.vagrant” directory that is automatically created contains directives specific to the previously used provider. Deleting that directory makes it forget the previously built VM and the provider used.
Being somewhat of a newbie to the command line, I can appreciate that in VirtualBox you can load up the VirtualBox Manager and see that a Vagrant box is created and the status of it at a glance.  One thing that I found somewhat irritating with VMWare is that the Vagrant box isn’t viewable in the Virtual Machine Library.  It looks like you only get it listed in the library if you create it using the GUI.  This isn’t a huge deal because Vagrant gives you all the tools you need to manage and view the status of the box in the command line.

vagrant -h
Usage: vagrant [-v] [-h] command [<args>]
    -v, --version                    Print the version and exit.
    -h, --help                       Print this help.
Available subcommands:
     box
     destroy
     halt
     help
     init
     package
     plugin
     provision
     reload
     resume
     ssh
     ssh-config
     status
     suspend
     up
     vbguest
For help on any individual command run `vagrant COMMAND -h`

Small Annoyances Exist

I should note that not everything using VirtualBox is perfect.  The error below typically (but not always) happens the first attempt at bringing up the box.

[isos-test-com.isos-test.com] Waiting for machine to boot. This may take a few minutes...
[isos-test-com.isos-test.com] Machine booted and ready!
Guest-specific operations were attempted on a machine that is not
ready for guest communication. This should not happen and a bug
should be reported.

The box is created and it is left running, so you have to destroy the box by typing “vagrant destroy” before you can attempt to bring it up again.  Usually, it only takes one additional attempt to get the box going and the Salt command state.highstate runs successfully – installing all the requisite software as expected.

VMware Destroy issues:

$ vagrant destroy default -f
[isos-test-com.isos-test.com] Stopping the VMware VM...

This hangs indefinitely…so I issue a control + c to stop the process.

^C[isos-test-com.isos-test.com] Waiting for cleanup before exiting...
Vagrant exited after cleanup due to external interrupt.

I check the status of the box as there is no way in VMWare to do this…

$ vagrant status default
Current machine states:
isos-test-com.isos-test.com not running (vmware_fusion)
The VM is powered off. To restart the VM, run `vagrant up`

So, the box is still there.  I told it to destroy, but all it seems to have done is shut it down.  So, I issue the destroy command again….

$ vagrant destroy default -f
[isos-test-com.isos-test.com] Deleting the VM...
[isos-test-com.isos-test.com] Running cleanup tasks for 'salt' provisioner...

And now it’s gone!  This is much easier using the VirtualBox provider.  Issuing Destroy shuts down and destroys the box within milliseconds without having to cancel the process first.

$ vagrant destroy
Are you sure you want to destroy the 'isos-test-com.isos-test.com' VM? [y/N] y
[isos-test-com.isos-test.com] Forcing shutdown of VM...
[isos-test-com.isos-test.com] Destroying VM and associated drives...
[isos-test-com.isos-test.com] Running cleanup tasks for 'salt' provisioner...
[isos-test-com.isos-test.com] Running cleanup tasks for 'shell' provisioner...
[isos-test-com.isos-test.com] Running cleanup tasks for 'shell' provisioner...

Time Test

Vagrant – VirtualBox, 1 box with salt installing 2 Atlassian apps

  • Box created and apps installed:  11:02
    Summary
    -------------
    Succeeded: 59
    Failed:     0
    -------------
    Total:     59

Vagrant – VMWare, 1 box with salt installing 2 Atlassian apps

  • Box created and apps installed:  9:55
    Summary
    -------------
    Succeeded: 59
    Failed:     0
    -------------
    Total:     59

As you can see, the VMWare provider was only slightly faster.

Comparison Conclusions

For our purposes at Isos Technology, the VMWare plugin for Vagrant (even if free like the VirtualBox) doesn’t seem to offer a lot of compelling reasons to switch. My initial experiences, in fact, make me favor the VirtualBox version a little more.  Being able to spin up instances successfully and destroy them quickly is a big consideration, but in our case the difference of little over a minute (~10% decrease) is not too earth shattering.  In future tests I would like to see if there is a bigger difference when setting up a multiple VM networked environment and maybe more Salt installations.  This might reveal more benefits of using the VMWare fusion.  Of course, there are several benefits of using VMWare over VirtualBox, but again, for our purposes I don’t see the benefits being that strong.
If you’re looking for a comparison between the two solutions outside of Vagrant, this article from Infoworld.com is pretty good.  For more information from Vagrant about the benefits of using the VMWare plugin, check out http://www.vagrantup.com/vmware#learn-more.
Finally, it must be noted that the total cost of the using Vagrant on OSX is not $80 but it is at least $130 (Vagrant + VMWare Fusion).  We here at Isos love Vagrant and do see value in the product. If possible, we would actually love to pay / donate to help support the default VirtualBox provider instead of paying for the VMWare provider. Please join us in helping convince the awesome author of Vagrant  (Mitchell Hashimoto) to setup a method to support such development. 🙂