The boot loader, briefly

Velo Workspaces boots every Linux workspace with VZEFIBootLoader rather than the faster direct kernel boot, giving up a little raw speed for compatibility with any distribution's own GRUB or systemd-boot. The device inventory post covers the mechanism, including why the EFI variable store is created once and reused. This post is about how that adds up over a workspace's life, from creation to the fifth ordinary restart.

First boot: cloud image or installer

A workspace's first start costs the most, and how much depends on where it came from.

  • From a cloud image, most of the work happens before the first boot: the app converts the downloaded qcow2 image into a raw disk sized to your choice. The first boot then runs cloud-init, which creates your account, adds your SSH key, grows the filesystem and starts SSH. That usually takes under a minute.
  • From an installer, the first boot is the install: the installer unpacks and writes a whole system, heavy disk work that disk caching speeds up but can't remove. Automatic installs save you the clicking, not the writing.

Every boot after that is cheaper

From then on, the EFI variable store already exists and just loads, there's no installer or cloud-init setup in the way, and the firmware does what it does on real hardware: finds the installed system and hands over to its boot loader. The gap between the first boot of a fresh install and an ordinary restart of the same workspace is large, and very noticeable.

When "startup" isn't a boot at all

Restoring a saved (suspended) workspace is a different operation. Saving writes the VM's live memory and device state to disk; restoring reads it back and carries on exactly where it stopped, with no firmware, no kernel start-up and no services to launch. It isn't a faster boot; it isn't a boot. Not every configuration supports it: the app checks whether the workspace's devices can be saved and restored, and some, the graphics device and serial console most often, rule it out. Where it's available, it's the real fast path back to where you were.

What decides how fast a workspace comes up

  • The first boot costs the most: cloud-init setup for a cloud image (usually under a minute), or a whole install for an installer image.
  • Later boots are cheaper: just firmware finding an installed system.
  • A restore, where available, beats any boot, when you want to be back exactly where you left off rather than starting fresh.
  • A clone of a base image skips setup entirely: it boots like an ordinary restart, which is why disposable workspaces start in seconds.

Related reading: disk performance and caching, the device inventory post, and why ARM VMs feel native once they're running. Or download Velo Workspaces and try it yourself.