The right Linux distro for a virtual machine depends on the use case. Ubuntu Server LTS for general use, Debian for stability, Fedora for bleeding-edge, Alpine for size, Fedora CoreOS for immutable. The right answer is to match the distro to the workload, not the other way around. The team that picks the right distro for the use case has fewer surprises at runtime.
Table of contents
- The four use cases that pick the distro
- Ubuntu Server LTS for general use
- Debian for stability
- Fedora for bleeding-edge
- Alpine for size
- Fedora CoreOS for immutable VMs
- Post-install: install the VM guest tools
- FAQ
The four use cases that pick the distro
There are four common use cases for a Linux VM, and each picks a different distro. The first is general-purpose Linux-on-Linux: the right answer is Ubuntu Server LTS. The second is long-running stability: the right answer is Debian. The third is bleeding-edge development: the right answer is Fedora. The fourth is small-footprint containers or services: the right answer is Alpine.
The right answer for a corporate fleet is Ubuntu Server LTS. The LTS (long-term support) cycle is 5 years, the package set is well-known, and the documentation is comprehensive. The wrong answer is to use a non-LTS distro on a production fleet, because the upgrade window is short and the support contracts do not exist.
The right answer for a single developer who wants to experiment is Fedora or the latest Ubuntu. The wrong answer is to use a non-LTS distro for production, where reliability matters more than the latest features.
Ubuntu Server LTS for general use
The right answer for most production VMs is Ubuntu Server LTS. The current LTS at the time of writing is 24.04 (Noble Numbat), supported until 2029. The LTS cycle is predictable, the package versions are stable, and the security updates are backported.
The right way to install Ubuntu Server in a VM is to download the ISO from the Ubuntu website, attach it to the VM, boot, and follow the installer. The wrong answer is to use a pre-built image from a third party — those images may be out of date or have non-default configurations.
The right answer for the disk layout is the installer’s default — one partition for root, one for EFI, one for swap. The right answer for the network is DHCP if the VM is on a virtual network with a DHCP server, or a static IP if the VM needs a predictable address. The right answer for SSH is to import your public key during install, which sets up the authorized_keys file correctly.
The wrong answer is to install the desktop version of Ubuntu on a server VM. The desktop uses more RAM and disk, runs unnecessary services, and adds attack surface. The right answer is the server install.
Debian for stability
The right answer for a long-running VM (3+ years) is Debian. The Debian release cycle is slow, the package versions are conservative, and the stability is well-known. The wrong answer is to confuse Debian with Ubuntu — they share a base, but Debian has a stricter stability policy and ships older packages.
The right way to install Debian in a VM is similar to Ubuntu: download the netinst ISO, attach to the VM, boot, and follow the installer. The right answer for the installer is the default. The right answer for the package selection during install is SSH server and standard system utilities — nothing more.
The right answer for a corporate fleet is Debian if your team has Debian expertise. The wrong answer is to use Debian if your team only knows Ubuntu — the small differences in package names, default config locations, and tool versions will cost more time than the stability benefit.
Fedora for bleeding-edge
The right answer for a development VM is Fedora. Fedora is the upstream of RHEL, with a 6-month release cycle and the latest packages. The wrong answer is to use Fedora on a production fleet, because the support window is short (13 months) and the upgrades are frequent.
The right answer for a developer who wants to test against the latest packages is Fedora. The right answer for a developer who wants a stable platform for years is Ubuntu LTS or Debian. The wrong answer is to mix the two — pick a side based on the workload.
The right way to install Fedora in a VM is similar to Ubuntu: download the ISO, attach to the VM, boot, follow the installer. The right answer for the network is the default. The right answer for the package selection is Fedora Server Edition plus any extras you need.
Alpine for size
The right answer for a small-footprint VM (a sidecar service, a DNS resolver, a minimal container base) is Alpine. Alpine’s base image is under 10 MB, the package manager is apk, and the default install has no unnecessary services.
The wrong answer is to use Alpine as a general-purpose desktop or development VM — the package set is much smaller than Ubuntu or Debian, and the muscle memory for apt-get does not transfer. The right answer is to use Alpine for the specific use case it is designed for: small, fast, secure-by-default.
The right way to install Alpine in a VM is to download the virt ISO (the KVM/QEMU-optimized variant), attach to the VM, boot, and run setup-alpine for the initial config. The wrong answer is to use the standard ISO, which is for x86 installs and is larger.
Fedora CoreOS for immutable VMs
The right answer for a container-host VM is Fedora CoreOS. CoreOS is an immutable OS — the root filesystem is read-only, updates are atomic, and the OS is designed to run containers. The right answer is to provision it with the FCCT (Fedora CoreOS Config Transpiler) and Ignition.
The wrong answer is to use CoreOS for a general-purpose VM. The wrong answer is to treat CoreOS like a regular Linux — it is not. The right answer is to use it for the use case it is designed for: container hosts and Kubernetes nodes.
The right answer for most teams is to skip CoreOS and use a regular distro (Ubuntu LTS, Debian, RHEL) with Docker or Podman. The right answer for a team that runs Kubernetes at scale is CoreOS or Flatcar Linux.
Post-install: install the VM guest tools
The right post-install step for any Linux VM is to install the guest tools. The tools provide better display resolution, clipboard sharing, drag-and-drop file transfer, and dynamic display resize.
For VirtualBox, the package is virtualbox-guest-utils (Debian/Ubuntu) or virtualbox-guest-tools (Fedora/RHEL). The right answer is to install it, then add the kernel module to the initramfs:
sudo apt install virtualbox-guest-utils
sudo rebootFor VMware, the tools are open-vm-tools and open-vm-tools-desktop (if you have a desktop). The right answer is open-vm-tools (not the legacy VMware Tools, which is deprecated).
For KVM/QEMU, the tools are qemu-guest-agent. The right answer is to install it and enable the agent in the VM’s libvirt config. The agent provides graceful shutdown, time sync, and other host-guest coordination.
The wrong answer is to skip the tools and live with the 1024x768 display and the broken clipboard. The right answer is to install them as part of the base install.
FAQ
Which distro is best for a developer who uses macOS?
The right answer for a developer who lives in a Mac is to run a Linux VM in UTM, Parallels, or VMware Fusion, with Ubuntu Server LTS as the guest. The right answer is Ubuntu because the muscle memory transfers to most production Linux servers. The wrong answer is Fedora — the release cycle is too short and the support window is too brief for a developer’s primary VM.
Which distro is best for a Kubernetes node?
The right answer is any distro with the Kubernetes packages you need, plus a long support window. The standard answer is Ubuntu LTS, RHEL, or Rocky Linux. The right answer for a homelab is Talos Linux, which is immutable and Kubernetes-native. The wrong answer is to use a desktop distro — the GUI adds attack surface and consumes resources.
Which distro is best for a database server?
The right answer is a stable LTS distro: Ubuntu LTS, Debian, or RHEL. The right answer is to use the distro that your team’s DBA is comfortable with. The wrong answer is to use a bleeding-edge distro on a database — the database itself is the application; the OS is just a runtime.
What is the difference between Ubuntu and Debian?
Both are Debian-family, but Ubuntu is the more aggressive fork with newer packages and a corporate backer (Canonical). The right answer is to use Ubuntu for newer hardware, NVIDIA drivers, and the latest features. The right answer is to use Debian for stability, smaller image size, and a less opinionated default config.
What about RHEL vs CentOS vs Rocky vs AlmaLinux?
RHEL is the paid Red Hat distro. CentOS Stream is the upstream rebuild that tracks just ahead of RHEL. Rocky Linux and AlmaLinux are downstream rebuilds of RHEL (the 1:1 rebuilds of the last free CentOS). The right answer for a corporate fleet is RHEL with a support contract. The right answer for a budget fleet is Rocky or AlmaLinux, which are functionally equivalent to RHEL.
Is Fedora stable enough for development?
Yes. The right answer for a developer who wants the latest packages is Fedora. The wrong answer is to use Fedora for production, where the 6-month release cycle and 13-month support window are too short. The right answer for a developer is to use Fedora for the dev VM and to use Ubuntu LTS for the production fleet.
Can I run Docker inside a Linux VM?
Yes. The right answer is to install Docker or Podman on the guest OS and run containers inside the VM. The right answer is to use a Linux kernel that supports the features Docker needs (cgroups, namespaces, overlayfs). The wrong answer is to run Docker-in-Docker with the --privileged flag on the VM unless you have a specific reason.
What is the right amount of disk and RAM for a Linux VM?
The right answer for a minimal server is 1 GB RAM and 10 GB disk. The right answer for a typical server (web, API, small database) is 2-4 GB RAM and 20-40 GB disk. The right answer for a development workstation is 8-16 GB RAM and 100+ GB disk. The right answer is to start small and grow as needed, not to over-provision from the start.
Which is better: LXC/LXD or full VMs?
LXC/LXD is a container-on-Linux kernel technology, not a VM. The right answer for a service that runs on Linux is LXD (lightweight, fast, near-native performance). The right answer for an operating system you need to test (Windows, a different Linux distribution) is a full VM. The right answer is to use both — LXD for Linux services, KVM/QEMU for OS-level isolation.
What about cloud images?
The right answer for a VM in the cloud is to use the cloud image (Ubuntu Cloud Image, Debian Cloud Image, etc.). The cloud image is pre-configured for cloud-init, has a smaller footprint, and boots in seconds. The wrong answer is to use a desktop or server ISO on a cloud VM — that is a misuse of cloud resources.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: