Horses for courses, I think.
Running one standard server from a single vagrant config file location puts you back to the one host for multiple projects scenario, albeit moved from your host machine and into the guest.
The environment setup for one project could pollute the environment setup for another.
Sure, you can commit an ansible playbook or a chef cookbook or whatever to each project, but then you’re parallelising the need to specify a certain something across each project.
That’s not very clear. Hang on.
Suppose you have six projects and only one needs to be on PHP5.5 due to the live server environment, whereas all of the rest can be running 5.6+. With a single, standardised server, you have to edit the playbook for all six, not just the one.
(I know the PHP version isn’t the best example since it should be uniformly set to the latest and greatest in all but it’s the idea I’m referring to)
In a team environment, the chances are not insignificant that a dev would a) modify the playbook for the project that he’s on but b) not uniformly make the changes across all projects. If another dev git pulls and vagrant ups his project, he’ll change the configuration of his one standardised server and not necessarily notice.
(the provisioning step is generally a good time to go make a cup of tea )
The one virtual server per project eliminates this problem, but also puts one virtual machine into virtualbox per project. (one vagrantfile = one virtualbox machine effectively)
So like I said, horses for courses. If a standardised server to run all of your projects under suits your needs, then @swader 's approach is certainly the much better one.
Once you have a need to customise the server environment for a particular project, I’d consider switching to providing a vagrant setup (and consequently, a dedicated virtual machine) for that project to avoid polluting the standard server for the other projects and/or other devs. From my perspective, maintaining the vagrant environment inside the project repo is less troublesome than maintaining a separate repo for that environment (and if the vagrant clutter in the project root is troubling, it can always be moved to its own folder).