This guide is intended for MIT students, but you can still read it if you’re not one, although you won’t be able to try out XVM.

Like free stuff? If you’re an MIT student, did you know you can get a free virtual machine, courtesy of SIPB’s XVM project? That’s right, your own tiny VM, for free! Mandatory disclaimer: the VMs are indeed… very tiny, with only one core and 512 MiB of RAM, and XVM has some quirks. But you can still do a lot of cool stuff with it!

XVM logo

Using the autoinstaller

First off, make sure you know the basics of Linux and server administration. If you just want an Ubuntu or Debian VM, here’s how you do it.

  1. The XVM website requires you to use a certificate to authenticate, which you can get here.
  2. Pick a name for your VM (this guide will use the name “fuzzball”) Give your VM the maximum RAM and disk space (you’ll need it!) and select “Autoinstall” and the latest version of Ubuntu or Debian, although yeah the ones on XVM are a bit old.
  3. Wait 15 minutes and boot it up after the installation finishes.
  4. Obtain Kerberos tickets (either log into an Athena dialup or run kinit kerb@ATHENA.MIT.EDU on your computer) and do ssh -K fuzzball@xvm-console.mit.edu to access your brand new VM using its serial console.
  5. It’s much more convenient to access your VM over normal SSH instead of the serial console, so in the serial console, log in as root and add a new user (we’ll call them “fuzzy”), set their password, add your SSH public key to the user, and disable password login for SSH since your VM is exposed to the public internet.
  6. Now use ssh fuzzy@fuzzball.xvm.mit.edu to SSH in! Finally, upgrade your VM to a less ancient version of its OS. Congrats on your new tiny tiny VM!

Using boot CDs

But what if you don’t want Ubuntu or Debian? Luckily, XVM has plenty of (also ancient) boot CDs for installing other OSes. But before we get started, we need to talk about Xen.

XVM internally uses the Xen hypervisor to run VMs. Xen is pretty weird. It dates back from before the days of Intel VT-x and AMD-V, when x86 CPUs didn’t have hardware support for virtualization (the MIT 6.1810 class has a great lecture on what the heck Intel VT-x does). Thus, Xen supports ParaVMs, which use a specialized kernel that knows it’s in a weird hypervisor and interacts with the hypervisor to run supervisor mode instructions. This is called paravirtualization.

Alternatively, Xen has a different type of VM, HVMs, which use hardware virtualization support to run unmodified OSes. HVMs are generally less efficient since they have to emulate devices like network cards and disks, but you can use special paravirtualized drivers in a HVM to avoid this performance cost. On XVM, the autoinstaller always produces ParaVMs and the boot CDs always boot up as HVMs.

XVM has two kinds of consoles: the serial console and the VNC console. ParaVMs only support the serial console (step 4 in the previous section) and HVMs usually only use the VNC console.

For creating a HVM from a boot CD, it’s pretty similar to making a VM using other virtualization software like VirtualBox or QEMU/KVM which you might be more familiar with. You might need to manually add the xen-netfront and xen-blkfront modules to the initramfs of the VM for the paravirtualized network and disk drivers.

Surviving with 512 MiB

Your VM on XVM might feel suffocatingly small due to the RAM limitations, but you can make it slightly more bearable by enabling zram, which compresses infrequently used data in RAM. The easiest way to do that is with zram-generator.

Similarly, the XVM disk is pretty small and slow, but again, compression to the rescue! Btrfs with zstd compression can improve disk speeds slightly, at the expense of more CPU usage.

I’m running Caddy and cgit on my VM and they both work incredibly well with limited RAM.

And now time for something cursed!

Before I wrote this guide, I wanted to make a VM on XVM but the VNC console was broken due to some expired TLS certificates. Thus, only the autoinstallers worked, since the broken VNC console made it basically impossible to interact with HVMs booted from the boot CDs (although you could still use the legacy Java version of the VNC console, which I didn’t try). Instead, I came up with a different (cursed!) method: interrupt the autoinstaller and make it write a different OS to the VM’s disk. Here’s how it goes.

  1. Install your desired OS to a VM on your own computer with a 4G raw disk, for instance, using QEMU/KVM. Make sure the VM uses BIOS instead of UEFI. Add console=ttyS0,115200 to the boot parameters to get a serial console and add the xen-netfront and xen-blkfront module to the initramfs.
  2. Copy the disk image to some web server.
  3. Boot the ParaVM Ubuntu 18.04 autoinstaller on XVM, connect to its serial console, then hit enter a few times to interrupt it during IPv6 configuration (MIT, being at the forefront of bleeding-edge technology, doesn’t have IPv6 anyways). Now hit tab to leave the network configuration screen and select the option to get a shell.
  4. Write the disk image to the XVM disk with wget https://web.server/disk.image --no-check-certificate -O- > /dev/xvda. (Not sure why I needed --no-check-certificate 🙀)
  5. Resize the partitions on /dev/xvda to fill the entire VM’s disk. (I’m not actually sure how to do this step since the autoinstaller is pretty barren and I couldn’t find fdisk. I instead booted up the new VM and resized the live / partition 🙀🙀🙀 and rebooted and ran btrfs filesystem resize max / which somehow worked.)
  6. Power off the VM and change it a HVM, then boot it up.

Yeah, this method is pretty cursed, but honestly, it’s way more pleasant to install the OS in a VM on your computer beforehand and then write the image to /dev/xvda since XVM is so resource-limited. And that’s how you commit disk crimes on XVM!