Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I've been using VirtualBox for many years to create a development environment.

A lot of my colleagues are talking about Vagrant and many people seem very excited about it but I just can't seem to grasp the benefits of it.. seems to me like it's a series of new commands to learn in order to do the same things I did with Virtualbox.

With VirtualBox, I install and configure an environment perfectly, then I can package it up as an OVA or whatever and share it with other office users. You can take a snapshot in VirtualBox if something goes wrong.

Puppet and chef aren’t really part of Vagrant, they’re their own thing right?

So yes, what benefits specifically does Vagrant offer over VirtualBox on it's own?

share|improve this question

4 Answers 4

up vote 85 down vote accepted

This is a big question, so I'm going to break it up into two sections.


Vagrant is used to set up one or more virtual machines by:

  • Importing pre-made images (called "boxes")
  • Setting VM-specific settings (IP address, hostnames, port forwarding, memory, etc.)
  • Running provisioning software like Puppet or Chef

Note that it doesn't install software or set up the machine past loading the VM and setting VirtualBox settings. Think of it as a scripting engine for VirtualBox.

Here are some reasons I've seen for using Vagrant over just VirtualBox.

1. Set Up Multi-VM Networks with Ease

Most of the Vagrant power-user content I've read has been about setting up multiple VMs at the same time. Vagrant gives you a single config file to set these up, enabling you to launch all of them with one command.

Say you've configured three VMs to network with each other using static IPs on the 192.168.1.* subnet. You find yourself in a location that is already using that subnet to hand out IP addresses, and your VMs now conflict. With Vagrant, you can simply edit the Vagrantfile and reload the VMs, whereas with VirtualBox you'd have to open the settings for each VM, if not boot each VM and change them inside.

2. Source Control

By putting the settings in a text file, it enables the configuration to be put under source control. Made some changes last week and accidentally broke the image? Just revert the changes and reload the VM. You can accomplish this with VirtualBox snapshots, but it will take up much more space than just a Vagrantfile.

3. Various Platforms

There's a large number of boxes available at sites such as This enables you to try various OSes or distributions, applying the same provisioning to set up similar environments. This can help with testing or adding support to new platforms, and would be time-consuming using just VirtualBox.

There are a lot of arguments for using provisioning software, as well as using image snapshots. For additional discussion, I'll point you to Stephen Nelson-Smith's excellent article How to Build 100 Web Servers in a Day.

share|improve this answer
Still, I do not understand why I should use vagrant in development environment! Because, it's expensive ( if you want to use VMWare! ) We can prepare a virtual machine like base boxes which is used by vagrant then get clone by VMware to setting up another virtual machine. First and foremost, we can control all virtual machine settings by vmrun command that offered by VMware even IP address changes or running a script inside the guest machine! – Oğuz Çelikdemir Jul 14 '14 at 8:33
@OğuzÇelikdemir That's a fair point. Vagrant just puts an easier front-end to VMWare with regards to bringing up a new machine. Behind the scenes, it's using vmrun to control it. I had always used VirtualBox, and thus don't have any experience with the VMWare backend. – Adam Lukens Jul 17 '14 at 19:34

In addition to the excellent answer given by Adam, Vagrant ties everything all together. Although Chef and Puppet (and Salt and shell scripts and whatever other provisioner you want to use) are separate things, Vagrant ties it all together and makes it work with just a vagrant up.

That one command will

  1. just start the VM if that's all that is needed, but it'll also
  2. create the box from your specified base box if that is also not done yet, but if you don't even have the base box on your machine it'll first
  3. fetch it from its URL and download it to your machine.

You don't have to think about all that. Let's say you're switching to a different project, one started by a coworker. You just checkout the code from your repo, and run vagrant up, not worrying about downloading ISOs or installing anything, or wondering which version of which distro you need to use for that particular client, or whether you have a copy of a VM that's already got everything you need.

You don't even need to worry about whether they've set things up using Chef or Puppet or just shell scripts. (Okay, so you might need to do a bundle install or otherwise make sure you've got everything installed, but still not a big deal.)

By tying everything together, and providing a unified interface for it all, it can make all but the simplest use cases much much easier. At first you may feel like you're just relearning a new way to do what you're already doing, but once you get deeper into Vagrant use you'll discover you can do much more with much less effort. It'll be well worth the initial time investment.

share|improve this answer
But it's a hell of a lot easier and faster for me to send a developer a presetup VM image than it is for them to install vagrant, learn how to use it, and deal with any of the myriad problems that come up, particularly when supporting windows boxes. I just really DO NOT get it, either. Seems to be nothing but fanboys. – hopeseekr Nov 26 '14 at 1:40
Installing Vagrant is unbelievably easy these days. Anyone who can't install it can't possibly be trusted to write code. Having a Vagrantfile in your source code that the developer checks out is actually far easier than sending a VM. The Vagrantfile defines the setup, including the URL from which to download the base VM (which it then configures). If you don't initially need to make configuration changes, then you're all set. But as you work on your project, you'll likely need to make changes. Do that in your Vagrantfile. – iconoclast Nov 26 '14 at 3:33
Since you're keeping the Vagrantfile with your code, all developers joining the project will automatically get the changes you make to your VM, since you're making them in the Vagrantfile. Configuring your Vagrantfile doesn't need to be difficult. You can use shell provisioning if you find the Chef and Puppet to be overkill (which they often are). If you can enter the shell commands in the VM, then it's a tiny hurdle to set up shell provisioning commands in the Vagrantfile. It will take a small up-front effort and save you lots of headaches in the long run. – iconoclast Nov 26 '14 at 3:33
@hopeseekr I too was thinking this. I've kept reading trying to see the benefit. I think I finally get it. I've been reading a book on Python networking. Testing is a complex setup imitating machines you can use to learn. You can build a VM w/Linux, do it by hand, and I'm one person, so that's ok. I Installed Vagrant on Windows and entered three Vagrant commands to call up his image to use on VirtualBox. What if I had 50 PCs? long time to setup with snapshots. What if there are changes? 50 updates? For me I was able to start working immediately without setting up everything. – johnny Oct 30 at 16:36
and when you need to change something on all 50 computers? – iconoclast Nov 2 at 17:02

Ability to integrate chef or puppet in with VM provisioning is key. Most Vagrant users will tell you they run 'vagrant provision' and occassionally 'vagrant reload' much more often than 'vagrant up' or 'vagrant destroy'. These tasks indicate the real work is not in spinning up/down VMs but 'managing' them after the fact.

To pose a better question (posed by proficient Chef users, anyway) might be why use Vagrant and not knife with the appropriate plugin (will get to virtualbox plugin, in a moment)? For instance, passing argument values stored in a data bag to a knife plugin is (way) more intelligent, flexible and manageable than juggling one giant Vagrantfile. I typically define my 'dynamic' resources like # of CPUs, amount of memory, which OS to deploy, hostname, IP, routes, etc, in chef databag(s) such that I don't need to keep changing my recipe ;-). Editing a databag through Chef web interface is a really easy data entry task I can give to the most junior operators. With Vagrantfile, your forever modiyfing code and believe it or not - code breaks - which pretty much guarantees you'll NOT be handing off simple changes to Operations staff, ever.

Aside from the fact knife does not yet have a plugin for virtualbox (though I envision one in the not too distant future), there are already plugins for most 'enterprise' virtualization products, including vmware, xenserver and just about every major 'cloud' provider, as well. This means knife is far superior to what Vagrant offers if/when you are ready to move beyond virtualbox. For now, Chef community seems happy to let virtualbox users limp along with Vagrant by not integrating virtualbox apis for a knife plugin. There is a knife-vagrant plugin that does allow for use of data bags to pass arguments. But, it still requires vagrant software and it's monolithic Vagrantfile to function.

So, I'll go out on a limb and say Vagrant is definitely NOT 'better' than Chef with knife; but necesary (for now) if you insist on virtualbox and perhaps 'easier' than managing chef with data bags, provided you have a fairly simple environment to manage.

share|improve this answer

Here are two more developer use-cases that vagrant simplifies (over "plain" VirtualBox). I didn't see these use-cases called out specifically in the previous answers.

  1. Vagrant helps with the aim of keeping the development and production platforms as close to each other as possible. In an ideal world, you would provision the production environment with THE SAME scripts used to provision the Vagrant VM, minimising surprises at deploy time.

  2. Integration tests and continuous integration: Vagrant is easy to control from tests, and therefore entire multi-machine stacks can be easily controlled from tools such as Jenkins when doing test runs.

Yes, "plain" VirtualBox can be used here too - but the conventions used by vagrant make it more simple to set these scenarios up.

share|improve this answer
I seriously just copy the vmx and vmdk from Windows to Linux. Maybe it's different in the virtualbox world, but I doubt it! What's easier? Copying a file or messing with vagrantfiles and the myriad of problems that can go wrong? – hopeseekr Nov 26 '14 at 1:42
To put a finer point on it, Vagrant can be thought of as a virtual definition language that can describe the characteristics of a virtual machine --independent of whether it is hosted under VirtualBox, VMware, Parallels, or what-have-you. See how Vagrant is not "competition to" VirtualBox, but works with it, or beyond it. – MarkHu Feb 14 at 4:36

protected by Community Nov 2 at 10:19

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.