Goodbye VirtualBox 2020-05-11

Believe it or not, this web site (and a few others) are actually hosted on a laptop behind a 15Mbit residential DSL connection. So is a Linux based mail filter server, a Windows 2003 based IMAP/POP/Submission mail server, a Linux based XMPP server, a Linux based BIND DNS server, and some other junk. This stuff is all able to live on a single laptop because of VirtualBox, which emulates a PC and can run multiple "guest" operating systems at the same time. VirtualBox was originally made by innotek which was bought by Sun in 2008 which was subsequently bought by Oracle in 2010. There are lots of other software packages that let users run multiple operating systems, but I have found VirtualBox to be one of the easiest to manage... even if I am not a fan of Sun or Oracle.

I have tried a bunch of other virtualization applications but haven't really been impressed enough by any of them to dump VirtualBox yet. Proxmox came pretty close... I really like the interface but I think their attitude about removing the nag screen is just a dick move. Just recently though, I thought that maybe I could get by with just KVM based virtual machines that I manage from plain old command line. Using a combination of KVM and libvirt I have been toying with some VM's and liking it. I obviously don't get a fancy interface that lets me mouse my way through VM management but I do get a nice lean host system that doesn't gobble up a lot of memory (which is much better spent on the actual guests than the host). The command line stuff isn't that hard to remember, it only requires a short cheat sheet, and since the virtual machines are generally intended to just run and stay running it really isn't something I have to use on a day to day basis. So, what kind of commands are necessary? Well, here's a few examples:

List RUNNING VMs # virsh list List ALL VMs # virsh list --all Start a VM # virsh start server01 Show VNC display # virsh vncdisplay server01 Hard power off a VM # virsh destroy server01 Save VM state to a file # virsh save server01 /path/server01.kvmsave Restore VM state from file # virsh restore /path/server01.kvmsave Remove a VM # virsh undefine server01

One of the things that irritated me a bit with this setup was that I had to manually create a bridge for VM's to connect to the network. Basically since I want my VM's to be on the same network segment as the host, I had to do something like this:

/etc/network/interfaces # Primary NIC
auto eth0
iface eth0 inet manual
# KVM bridge
auto br1
iface br1 inet static
   address 192.168.1.2
   netmask 255.255.255.0
   network 192.168.1.0
   broadcast 192.168.1.255
   gateway 192.168.1.1
   bridge_ports eth0
   bridge_stp off
   bridge_fd 0
   bridge_maxwait 0
   dns-nameservers 192.168.1.1

This gives my host an IP address of 192.168.1.2 and then my virtual machines are just connected to the bridge device br1 and it is as if they are just plugged in to the same switch as my host. This is handled automagically by VirtualBox but must be done manually with this KVM setup. So what about actually creating a virtual machine? It might look a bit ugly at first but once you chop it up in to sections it isn't so bad:

Create a VM # virt-install --name devuan01 --os-type linux --os-variant debian9 --ram 1024 \
--disk /kvm/disk/devuan01.img,device=disk,bus=virtio,size=10,format=qcow2 \
--graphics vnc,listen=0.0.0.0 --noautoconsole --hvm \
--cdrom /kvm/iso/devuan_ascii_2.0.0_i386_netinst.iso \
--boot cdrom,hd --network bridge:br1

Most of these kind of speak for themselves... "devuan01.img" is the 10GB disk file that will serve as the VM's hard drive, "vnc,listen=0.0.0.0" is the VNC listener that will let you connect to the VM and complete the install of the OS, the .iso file is the CDROM image that the machine will boot from, and of course br1 is the network connection to the bridge adapter described above. One little extra thing I did was create an encrypted volume that I mounted at /kvm/disk. The bad news is that I have to disable autostart on all my VM's and start them manually, the good news is that I know all of my VM contents are encrypted at rest without any encryption required on a per-VM case. I'm actually working on migrating some of my services over to this setup right now and will hopefully be able to decommission all the old VBox stuff soon.

Some asshat dumped these on my road recently

Seriously, we have had an environmental fee built in to the cost of all tires here for years and years. Tires can be dropped off for free at pretty well any garage. What jackass would dump these in the ditch?