Development setup, February 2022
2022-02-??
It's been a while since I wrote about using xhyve for virtual machines. Or about using Acme. But I'm still at it, with two changes.
The first change is the fact that I turned Acme into a remote editor, so I
can work on a local Linux VM while staying in the host macOS GUI. I do
this by turning plan9port's devdraw
into a kind of X display server.
Acme itself runs on the VM, but whenever it tries to talk to
devdraw
, its commands go across an SSH forwarded connection back to
devdraw
running on the host OS. There is some inevitable friction, but
for the most part I'm able to separate my activities into things that
happen on the host (web browsing, Slack, etc.) and on the VM (editing
source code, compiling, running tests etc.). It helps a lot that Acme
is a combined text editor and shell.
The big benefit of working like this is that I get a lot of the
upsides of working on Linux, without the downsides of having to keep
Linux-on-the-desktop working smoothly. Some of the benefits are that I
can use perf record
the same way I use it on real servers (perf
is
for Linux only), and that compilation and test suites that spawn many
processes run much faster (macOS makes spawning processes slow).
The second change is that I replaced Xhyve with a homegrown replacement based on Virtualization.framework. Xhyve, which extends Hypervisor.framework into something actually useful, does not work on the new M1 ARM Apple computers. Luckily, most of the functionality of Xhyve is now provided by macOS itself, via Virtualization.framework. By writing a small "glue" application that calls into the framework I was able to replace Xhyve in my virtual machine management tooling. The glue application I wrote is based on vftool.
Apart from the obvious improvement that now I have a VM system that
works at all on M1 hardware, it is also nice that it is now possible
to boot the VM without sudo
.
Tags: acme