Add vagrant-vbguest plugin

[patcon]

https://github.com/dotless-de/vagrant-vbguest

Technically, whenever a user spins up a new basebox, they should make sure that the Virtualbox Guest Additions package in the VM matches the version of virtualbox that they're running on their host machine. Baseboxes always come with one installed, but the basebox vbguest version is rarely as up-to-date as your host vbox version, so they're not in sync.

We can use this plugin to keep them in sync. It does a quick check on the version on each up/reload, and only runs when needed (it can take a little bit of time).

[pirog]

how much time is a "little bit of time"... not that i am against this at all but from a potential new-user/drupaler accessibility standpoint we really want the build and spin ups to be as fast as possible.

[patcon]

no plugin: vagrant up 6.86s user 1.25s system 15% cpu 52.294 total
with plugin: vagrant up 11.32s user 1.60s system 13% cpu 1:38.41 total

Appears to be about 45s difference (with an empty chef run). Most of the time is apt-get update and apt-get install for the right packages needed to install the guest additions package.

This plugin might solve this problem more generally, and also help boot time in other areas:
https://github.com/fgrehm/vagrant-cachier

Other than the general feel-goodiness of standardizing the guest additions version (as oracle recommends with low priority for minor version changes), it's worth pointing out that, among other things, guest additions are claimed to help support:

• Shared folders
• Generic host/guest communication channels
• Time synchronization
• Shared clipboard
• Automated logons (credentials passing)

Looks like we could probably get by without it, so long as we're not using windows, or native vbox shares. Just something that might lead to edge-case failures

[wizonesolutions]

vagrant-vbguest is a must for me. If I'm provisioning a VM, I kind of expect it to take a little while. Perhaps we could not bundle it but include it in a rake command the user can run after provisioning. So they can get a fast startup at first and play around, and then when/if stuff breaks or they want to get serious they run a rake optimize command or whatev.

[patcon]

Thanks Kev. Since we're aiming to use vagrant's package installer, nothing is getting "bundled" as far as I know (if we're referring to bundler and Gemfiles). In the commit, we've got the plugin added to the rake install_plugins task.

rake optimize sounds interesting. How do you imagine that might work? Would it be something for this issue, or worth opening another so we don't forget the intent?

[wizonesolutions]

Another issue's fine. (and maybe copy this)

My thought is that rake optimize does some of the interesting stuff that takes more time than what we for the first-time user experience. This is the only example I have of that right now, and I'm not sure how well it's named. It's optimizing the experience, not necessarily optimizing performance.

(btw, I didn't mean Bundler. Was just speaking English :))

[patcon]

Ooooohhh.. Gotcha. Like a wizard for fine-tuning, but not intended as required for the first run? I like it!

[patcon]

@pirog you had a concern about boot time. Is 45s from fresh boot acceptable to merge?

Note: I've opened this issue to see if it might be improved: dotless-de/vagrant-vbguest#67

[wizonesolutions]

Exactly, @patcon. Then we can satiate the impulse buyers without alienating the power users :D