The boot loader choice, briefly — full mechanism covered elsewhere

Velo boots every Linux workspace through VZEFIBootLoader rather than the faster direct-kernel-boot alternative, trading some raw boot speed for genuine compatibility with any distro's own GRUB or systemd-boot — the device inventory post's boot loader section covers the full mechanism, including why the EFI variable store is created once and reused rather than rebuilt on every boot. What that post doesn't get into, and what actually matters for "how long until this workspace is usable": how those pieces add up across a workspace's actual lifecycle, and the one case where none of it applies at all.

One direct consequence worth calling out here rather than just linking past: when an installer's bootloader writes no fallback boot entry and a fresh install comes up to an empty EFI shell — covered in the Ubuntu post — that's EFI firmware correctly finding nothing to boot, not a startup failure specific to Velo. A direct kernel boot wouldn't have that failure mode, because there'd be no firmware boot-order logic to fail in the first place — one more facet of the same speed-for-compatibility trade.

Where startup time actually goes, across a workspace's lifecycle

Put the pieces together and a workspace's "startup cost" isn't one number, it's front-loaded: a workspace's very first boot pays for NVRAM creation and, if it's a fresh install, the installer's own heavy disk activity — cache-accelerated per the disk performance post, but still real work. Every boot after that is cheaper by construction: NVRAM already exists and just loads, there's no installer in the loop, and EFI firmware is doing what it does on real hardware — finding an already-installed OS and handing off to its existing boot loader. The gap between "first boot of a fresh install" and "the fifth ordinary restart of the same workspace" is real and it isn't subtle.

The case where "startup" isn't a boot at all

Everything above describes an actual firmware-and-kernel boot sequence. Restoring a hibernated workspace is a categorically different operation: covered in depth here, a save/restore cycle serializes the VM's live memory and device state to disk and reloads it directly, resuming execution from exactly where it left off — no firmware boot, no kernel init, no systemd unit ordering, none of it. It's not a fast boot; it's not a boot at all. Not every configuration supports it — Velo's own SaveRestoreSupport.probe check rules it out for configurations using device types that don't support save/restore, most commonly the graphics device and serial console — but where it's available, it's the actual fast path for "get back to a working workspace quickly," not a faster boot loader.

What actually determines how fast a workspace comes up

  • First boot costs the most — NVRAM creation, and if it's a fresh install, the installer's own heavy disk activity, cache-accelerated but still real work.
  • Every boot after that is cheaper — NVRAM already exists, no installer in the loop, just EFI firmware finding and booting an already-installed OS.
  • Restore, where available, beats any boot — it isn't a fast boot, it's not booting at all, and it's the right tool when what you actually want is "back to exactly where I left off," not "started fresh."

Related reading: disk performance and the caching-mode tradeoff, disposable VM vs. snapshot for the restore path in full, and the Ubuntu post's EFI-shell gotcha, a real consequence of the boot-loader choice covered here. Or download Velo Workspaces and try it yourself.