Rewrite XVM post

1 files changed, 46 insertions, 77 deletions

diff --git a/content/posts/inessential-xvm.md b/content/posts/inessential-xvm.md
index afa8d63..eec9b5b 100644
--- a/content/posts/inessential-xvm.md
+++ b/content/posts/inessential-xvm.md
@@ -2,87 +2,56 @@
 title: "Inessential XVM"
 date: 2024-12-03T00:03:18-05:00
 draft: true
-description: "A brief guide for how to use xvm.mit.edu"
+description: "A brief guide to SIPB's XVM service"
 type: "post"
 tags: ["virtual-machines", "sipb", "mit", "linux"]
 ---
 
 
-TODO: The VNC viewer works again so this is outdated, ![XVM logo](/img/xvm.png)
-
-Message from Mitch:
-
-> The Arch CD is almost certainly booting correctly; it's fairly hard for the
-> CDs not to... at any given time, the autoinstallers are far more likely to
-> have grown a pile of problems.
-> 
-> By definition, any time you boot a VM from a CD, it is an HVM.  There's no
-> such thing as ability to boot a paravirtualized VM from a CD drive.  What you
-> configure your VM as (HVM or ParaVM) only affects how it boots normally using
-> its own disk; any time you boot it from a CD, that overrides your configuration
-> and starts it as an HVM so that it can have the CD drive.
-> 
-> HVMs don't typically support the serial console.  While it is possible for the
-> machine to emit messages over the appropriate serial port, as you saw a few
-> lines when you booted the Arch CD, almost none of the usual setups actually
-> use that as a console when they believe they have a VGA console.  Almost certainly,
-> after those few lines, when the archiso image loaded and enumerated the "hardware",
-> it saw a VGA console and everything further was sent there, which is why you didn't
-> see anything else on the serial console (which is what you get when you ssh to
-> ${VMNAME}@xvm-console.mit.edu).  The serial console was working correctly; the
-> machine just wasn't using it, which is as expected.
-> 
-> For an HVM, you need to use the VNC console, as you also tried to do.  xvm.mit.edu:10000
-> wasn't down; if you'd pulled out info from the browser's debugger, you'd have ended
-> up with a websocket URL.  Those are fairly obnoxious to debug, though if you'd have
-> looked deeper in the browser or gotten another tool to try to interact with a websocket,
-> you'd have seen the websocket closing with error code 1006.  That wouldn't occur
-> if xvm's port 10000 had actually been closed, but the effect is the same: it doesn't
-> work.
-> 
-> Error code 1006 translates, more or less, into "something low-level is wrong with the
-> websocket and you're not going to be told anything more helpful about what that is."
-> There isn't really any practical way for you to have gotten further in debugging.
-> However, on the other end of xvm.mit.edu:10000 is custom code that proxies the VNC
-> protocol to the actual hypervisors that host your VMs over a websocket with TLS.  The
-> internal certificates used for that TLS connection on each hypervisor had expired.
-> That was the actual problem.  The certificates have been regenerated and the VNC
-> servers and proxy have been restarted; the novnc console on the web now works again.
-> 
-> All of that said, while the novnc JavaScript-based console was broken, the old-fashioned
-> Java-based VNC app was working, if you'd managed to launch the JNLP file in a Java
-> Runtime Environment.
-> 
-> We don't typically go into this much detail about complicated problems, but since
-> you managed to get past the problem with the creative solution of firing up an
-> autoinstaller and using its debugging shell to copy an Arch image over the network
-> to your VM's disk, I figured you might be interested in knowing what was really
-> going on.
-> 
-> We apologize for the inconvenience and are glad you managed to solve the problem your
-> own way.
-
-I'm a member of [SIPB](https://sipb.mit.edu), a cool computing club at MIT that runs many projects for the MIT community. One of these projects is [XVM](https://xvm.mit.edu), which provides free Xen virtual machines to all MIT students! However... XVM dates from the early 2010s and uses Python 2, so it has a bunch of quirks that can trip up new users:
-
-1. You need a certificate to authenticate to the XVM website, which you can get [here](https://ca.mit.edu/ca/).
-2. VMs are limited to one core and 512 MB of RAM, which can be suffocatingly tight.
-3. The available boot CDs are pretty outdated. The autoinstaller either produces Debian 10 or Ubuntu 18.04.
-4. Xen is pretty weird and not like KVM which you might be more familiar with. There are two types of Xen VMs: ParaVMs and HVMs. Apparently ParaVMs are more efficient, but they require a specialized kernel. Most of the boot CDs can only be booted by a HVM. (Technically there are [more kinds of VMs in Xen](https://en.wikipedia.org/wiki/Xen#Types_of_virtualization) and I think the HVMs on XVM are actually "HVMs with PV drivers".)
-5. The VNC viewer on XVM is broken, so you can't see or interact with the display of your VM. Thus, if you boot up one of the boot CDs, you won't be able to do anything with it.
-
-From my understanding, ParaVMs only use the serial console and not the VNC viewer, so you can access them by first obtaining Kerberos tickets with `kinit kerb@ATHENA.MIT.EDU` and then doing `ssh -K vmname@xvm-console.mit.edu`. HVMs use the VNC viewer, so you can't really make an HVM currently.
-
-If you just want a Ubuntu or Debian VM, simply use the autoinstaller and give your VM the maximum RAM and disk space (you'll need it). Wait 15 minutes, and then boot it up and you'll be able to access it over the serial console. I recommend installing an SSH server so you can SSH into `vmname.xvm.mit.edu` for easier access. Also, remember to update your VM to a less ancient version of Ubuntu or Debian.
-
-But what if you don't want Ubuntu or Debian? Ready for some crazy XVM shenanigans?
-
-On XVM, you can't really boot anything other than the autoinstallers because VNC is broken. Thus, you have to 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. I also recommend installing a SSH server in your VM and using zram and a filesystem with compression to make your VM seem slightly larger.
+*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](https://sipb.mit.edu)'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](/img/xvm.png)
+
+## 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](https://xvm.mit.edu) requires you to use a certificate to authenticate, which you can get [here](https://ca.mit.edu/ca/).
+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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Xen#Types_of_virtualization), 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.
+
+## 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 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`.
-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. Congrats on your new VM on XVM!
+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 VMs on XVM are so resource-limited. And that's how you commit disk crimes on XVM!
+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!