Oh, wow. They've also changed the license a couple of times in 2016 and 2017 to make it more restrictive.

Early 2016: https://web.archive.org/web/20160411070811/https://www.virtu... Late 2016: https://web.archive.org/web/20161208112443/https://www.virtu... Current, last changed July 2017: https://www.virtualbox.org/wiki/VirtualBox_PUEL

In the earlier licenses, "personal use" was just defined as the person using it being the same person as who installed it, and only one person remotely accessing the desktop at a time. So I had interpreted this as being OK for developer VMs in which the developer installs it themselves and uses it for their own development purposes. It also contained an "evaluation use" with a vaguely defined period.

The current license now defines "personal use" as explicitly non-commercial use, and adds more restrictions on client access that applies to any type of clients and not just remote desktop access, as well as explicitly defining the evaluation use period to being 30 days.

So while I didn't really have a concern about developers using VirtualBox with the extension pack previously, given the new license and the fact that they seem to be enforcing it via phoning home, it looks like it's time to set a policy of no one using it.

Luckily, we've already pretty much transitioned everything over to libvirt/KVM on Linux hosts, and people have generally been using VMWare or VMWare Fusion on Windows and Mac hosts.

I have a devops guy trying to push me to use Vagrant at the moment, but I am aware of these issues with virtualbox. I was thinking about using one of the lxc shims, but now you have me curious, how useful is openshift in that "I want to spin local vms up for testing" approach? I thought it was much more geared to server and not workstation, as opposed to vagrant.

Of course others are right, virt-manager is probably a better replacement I think.

So OpenShift (or OKD) is just Redhat's Kubernetes platform. If your dev team isn't already in a docker-like workflow, it's going to be a hard sell. I've found many devops-y people love to be able to SSH into the environment to change code as it runs, and that's not possible with an environment like this.

You can spin up KVMs in OpenShift, but I have the feeling it's not going to be quite what you're looking for. I suppose it's all going to be a matter of what workflow is most comfortable for your devops people. If you have an OpenStack install, Vagrant can control those AND they can login and poke around.

Also FYI virt-manager is deprecated in RHEL 8, and is superceded by Cockpit.

Out of curiosity, what feature in the extension pack are you using with Vagrant?

USB pass through support to drive hardware debuggers here.

PXE booting mostly.

Why not use KVM via vagrant-libvirt? It's pretty easy to set up and works like a charm. See https://news.ycombinator.com/item?id=18727059

So one problem with that is not all of our team uses Linux, we're a Mac/Linux hybrid team. Our workflow was to edit the puppet manifests locally and then Vagrant up, and we wanted something that would work across different dev machines. However, the fussiness of environment setup started to go higher the further we got from VBox; our team didn't really want to invest time into a workflow that was supposed to be an intermediate step to our "end game" development pipeline, so we just left it. Thanks for the link though!

You can have mixed provider vagrant files.