First draft of XVM post

1 files changed, 88 insertions, 0 deletions

diff --git a/content/posts/inessential-xvm.md b/content/posts/inessential-xvm.md
new file mode 100644
index 0000000..d5eb115
--- /dev/null
+++ b/content/posts/inessential-xvm.md
@@ -0,0 +1,88 @@
+---
+title: "Inessential XVM"
+date: 2024-12-03T00:03:18-05:00
+draft: true
+description: "A brief guide for how to use xvm.mit.edu"
+type: "post"
+tags: ["virtual-machines", "sipb", "mit", "linux"]
+---
+
+
+TODO: The VNC viewer works again so this is outdated
+
+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.
+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!
+
+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!