Support libvirt as a Vagrant provider

[slifty]

Apparently VirtualBox is a bit fraught when it comes to being genuinely free, so lets move our default / recommended / supported VM to something that is a little less unnerving in that aspect.

One option that came up was qemu but a little bit of digging should be done first.

Some extra reading: https://drewdevault.com/2018/09/10/Getting-started-with-qemu.html

[slifty]

Some more reading:

https://superuser.com/questions/1490188/what-is-the-difference-and-relationship-between-kvm-virt-manager-qemu-and-libv

https://www.thegeekyway.com/kvm-vs-qemu-vs-libvirt/

Note that we're running on: https://app.vagrantup.com/generic/boxes/debian10 which has providers for libvirt and hyperv.

[slifty]

I've done a bit of digging and wanted to document my findings.

1. VirtualBox is definitely the most used and most supported provider for Vagrant. That being said, Vagrant does support other providers. The way to use libvirt is to install the vagrant-libvirt plugin.

2. qemu is a hypervisor provider (i.e. the thing that can emulate / run virtual machines), but to actually use it with vagrant you use a manager like libvirt.

3. At face value, telling Vagrant which provider to use (once the plugin is installed) is very simple: (e.g. vagrant up --provider=libvirt)

I think supporting libvirt is a great idea, but this exploration has helped me realize that there's actually value in supporting multiple providers at once, so long as the providers we choose align with our FOSS requirements.

Supporting a provider in this context means:

• Providing documentation on how to run the development environment with that provider
• Setting any special configuration values for that provider in the Vagrantfile. (Vagrant lets you add blocks that are unique to specific providers, which we already do for VirtualBox).

Path Forward

Part of my personal challenge is that in addition to Vagrant not fully supporting libvirt, libvirt doesn't fully support OSX. I can work to develop libvirt support by, ironically, developing the devenv itself on a virtual machine (turtles all the way down), but it also might be appropriate for someone whose primary development machine is debian to take on adding the libenv support.

[slifty]

Some further developments:

1. We're going to continue to allow for VirtualBox as a supported virtualization provider for now.

However

2. We do want to eventually support libvirt before this dev environment will be really considered "ready" from the sense of v1.

It's possible to set up virtualbox on debian, but it's not trivial. It lives on unstable currently: https://metadata.ftp-master.debian.org/changelogs//contrib/v/virtualbox/virtualbox_6.1.18-dfsg-3_copyright