The biggest thing it adds on top of VirtualBox is a consistent workflow. If it helps, think of what Vagrant does technically as useless, and think of Vagrant only as a process discipline: to get a dev environment for any project you "vagrant up", to close it out "vagrant destroy", to access it "vagrant ssh", etc.

As soon as you get this consistent workflow, then you can teach it to your entire organization and the whole company knows that ANY project in the company can be worked on using this workflow without any dependencies on their own machine.

And if ops decides to suddenly change the dev environment from VirtualBox to say... AWS... nothing changes! I've had large companies (200+ developers) switch from VirtualBox to VMware to AWS for their dev environments without their developers ever really noticing.

That is pretty cool.

Of course, on top of this, you get a lot of nice things: you get provisioners, you get automatic network configuration, you get the entire plugin community, you don't have to worry about stability on your own because you tap the collective stability of thousands of users, etc.

But the real power is workflow.

I use Vagrant daily. Here's an example I was working on today.

I needed to spin up 5 servers, a load balancer and 2 groups of 2 backend servers. I needed to provision them with Chef, have full name resolution, and be able to access the servers from my host machine.

Here's my Vagrantfile

    Vagrant.require_plugin "vagrant-chef-zero"
    Vagrant.require_plugin "vagrant-berkshelf"
    Vagrant.require_plugin "landrush"

    last_ip_octet = 10
    DOMAIN = "vagrant.dev"

    Vagrant.configure("2") do |config|
      config.landrush.enable
      config.chef_zero.chef_repo_path = "./"
      config.omnibus.chef_version = '11.8.0'
      config.vm.box = "opscode_ubuntu-12.04_provisionerless"
      config.vm.box_url = "https://opscode-vm.s3.amazonaws.com/vagrant/opscode_ubuntu-12.04_provisionerless.box"

      %w{default metrics}.each do |backend|
        (1..2).each do |i|
          config.vm.define "be_#{backend}_#{i}".to_sym do |cfg|
            last_ip_octet += 1
            cfg.vm.hostname = "be-#{backend}-#{i}.#{DOMAIN}"
            cfg.vm.network :private_network, :ip => "192.168.33."+last_ip_octet.to_s
            cfg.vm.provision :chef_client do |chef|
              chef.node_name = "be-#{backend}-#{i}"
              chef.add_role "backend_#{backend}"
            end
          end
        end
      end

      config.vm.provision :shell, :inline => "/usr/bin/apt-get update --fix-missing"
      config.vm.define :lb do |cfg|
        last_ip_octet += 1
        lb_ip = "192.168.33."+last_ip_octet.to_s

        cfg.vm.hostname = "lb.#{DOMAIN}"
        cfg.vm.network :private_network, :ip => lb_ip
        cfg.vm.provision :chef_client do |chef|
          chef.node_name = "lb"
          chef.add_role "lb"
        end
      end
    end

This utilizes a few vagrant plugins, vagrant-chef-zero, vagrant-berkshelf, and landrush which are one liners each to install. After that, I can type

    vagrant up  # build my stack from scratch
    vagrant destroy # destroy my stack
    vagrant ssh lb # ssh into the lb instance
    vagrant provision # execute chef (puppet, ansible, bash, etc)

Can you show me equivalent code that fulfills all my requirements using VirtualBox directly and will allow me to change a couple lines to spin this same infrastructure up in AWS or using VMWare?

Not the parent post, but from my limited use of Vagrant so far, the main difference is that there's a "base" image that you can quickly reset to in order to test the repeat-ability of your deploys. The images also automatically handle VirtualBox's shared folders feature and require little for configuration.

Other than that, I agree it's almost like just using VBox directly.

What? Automatically installing VirtualBox images, and setting them up with a development environment in 2-3 commands does seem "that different than just using VirtualBox directly"?