The frame: disposable changes the maths

Much published VM advice optimizes for crash consistency on a server patched in place for years. A disposable workspace, deleted when you close it, has a different risk profile: losing data to an unclean shutdown hardly matters when the disk is thrown away anyway. That changes which trade-offs are worth making, and it's the lens for everything below: what's free, what's a trade worth taking only because the VM is disposable, and what's advice written for somewhere else.

I/O scheduler: set it to none

Linux's I/O scheduler reorders and merges requests to reduce physical disk-head movement. A virtio-blk disk has no head to move; it's backed by a sparse file the Mac already manages. Red Hat's virtualization tuning guide says guests on virtualized storage generally do better with none (the modern name for noop), because a second layer of reordering in the guest duplicates, and sometimes fights, what the host already does. Kernel discussions around virtio_blk have measured about 270k 4K random-read IOPS with mq-deadline against 450k with none on the same device. The exception is a guest with direct access to physical storage, which doesn't apply: the Virtualization framework has no device passthrough for Linux guests.

cat /sys/block/vda/queue/scheduler
echo none | sudo tee /sys/block/vda/queue/scheduler

TRIM: keep the sparse disk sparse

A sparse disk file only shrinks when the guest tells the host which blocks are free. Apple's virtio-blk supports the standard discard feature for this, but only if the guest's filesystem sends TRIM. Without it, a workspace's disk only ever grows to its high-water mark, even as you delete files inside it.

The usual modern approach is a periodic fstrim rather than the discard mount option, batching the work instead of paying a little on every delete. Most distributions ship fstrim.timer; make sure it's on:

sudo systemctl enable --now fstrim.timer
sudo fstrim -v /

Run it by hand just before you save a workspace as a base image, too. A smaller image means less to carry into every clone.

Memory: zram rather than a swap file

For a memory-tight workspace, the usual advice to keep swappiness low to avoid disk thrashing doesn't carry over, because zram swap isn't disk I/O. It compresses into RAM you already have, never touches the virtio disk, and doesn't grow the disk image you're keeping small with TRIM. Because it's fast, the usual guidance flips: zram setups often use a vm.swappiness well above the default, sometimes 100 or more, so the kernel uses it before dropping file cache.

sudo apt install zram-tools   # or: dnf install zram-generator
echo 'vm.swappiness=150' | sudo tee /etc/sysctl.d/99-zram.conf

Filesystem journaling: a real trade-off

This is the one setting here with a real downside. ext4's default data=ordered mode prevents a specific failure: a crash leaving stale or garbage data in a file because data and metadata were written out of order. data=writeback drops that guarantee (a crash right after a write can leave wrong data in that file) in return for better throughput, since it journals only metadata. On a long-lived server that's a bad trade. On a disposable workspace, deleted on close however it exits, the risk overlaps almost entirely with one you've already accepted, so it's a fair choice here and not a default to carry elsewhere.

noatime is the free win next to it: it skips the access-time write on every read, which almost nothing depends on. Both go in /etc/fstab:

UUID=xxxx  /  ext4  defaults,noatime,data=writeback  0  1

Shared folders: VirtioFS caching

Shared folders and the Rosetta share run over VirtioFS, and its caching mode trades coherency for speed. none disables client-side caching for maximum coherency; auto behaves like NFS, with about a one-second metadata cache; always caches for a long time, which speeds up workloads that stat many small files (an npm install, a big Git checkout) at the cost of coherency. The cost is concrete: there's a documented case of a host-side edit in a read-only VirtioFS share taking minutes to appear in the guest under a long-cache setup. If you edit on the Mac and expect the guest to see changes at once, know this before it looks like a sync bug.

Set it once, in a base image

These are all settings inside the guest, made in whichever distribution you run: Ubuntu, Debian, Fedora or another. Make them once in a workspace, save it as a base image, and every clone inherits them. Clones are copy-on-write, so a trimmed, tuned base image also makes every future clone cheaper. Keep the data=writeback choice for base images you use with disposable workspaces, where its risk is already accepted.

Related reading: why VMs on Apple Silicon perform the way they do, Linux VM disk performance, the disposable VM workflow this tuning serves, and a naming convention for base images as you save new generations. Or download Velo Workspaces and try it yourself.