Give an Ubuntu VM too little and it crawls; give it too much and you starve the host and every other VM on it. Sizing advice online ranges from fantasy minimums to datacentre excess. This page gives starter numbers you can trust, then shows you how to measure and adjust like an administrator instead of guessing forever.
Sizing a virtual machine feels like it needs a formula. It mostly needs three honest facts: Ubuntu Server is genuinely light, Ubuntu Desktop is a full desktop and priced like one, and the host's physical RAM is a wall that no setting can move. Start from the numbers below, run the VM for a week, then grow only what the measurements indict. That method beats every 'perfect sizing' table on the internet.
Ubuntu Server for services (files, web, monitoring, containers, a small database): 2 vCPU, 2 to 4 GB RAM, 25 to 40 GB disk. Ubuntu's own minimums are lower - it will install in less - but minimums describe survival, not a machine you enjoy administering. A genuinely idle server (DNS, a jump box) can live on 1 vCPU and 1 to 2 GB.
Ubuntu Desktop: 2 to 4 vCPU, 4 GB RAM as the floor and 8 GB if a browser with real tabs is involved, 40 GB disk and up. The graphical environment itself is a permanent background workload before you open a single application.
Disk honesty: a fresh Ubuntu Server sits well under 10 GB used. Give room for logs, updates and growth - but with thin provisioning, unused provisioned space costs nothing until written, so 40 GB provisioned on a 100 GB datastore is a plan, not a waste.
ESXi and its management services consume host memory before any VM starts - think in terms of a few GB on a typical install, more with large configurations. The arithmetic that keeps you safe:
When a host starts swapping or a datastore fills, every VM suffers at once. Sizing is how you protect the neighbours from each other.
A vCPU is a scheduled slice of a physical core's time, not a private core. Consequences that surprise newcomers:
Inside the guest, top and nproc tell you what it sees; on the host, the VM's performance tab tells you what it actually got. Trust the pair, not either alone.
CPU time can be sliced thin and shared gracefully; memory cannot. ESXi has emergency tricks when VMs collectively demand more RAM than exists - ballooning (asking guests to hand memory back) and, at the end of the line, host swapping to disk - and a VM whose memory is being swapped is a VM in pain, however cheerful its settings look.
So the discipline is simple:
free -h separates real pressure from Linux simply using spare RAM as cache - a full "buff/cache" column is health, not hungerThe professional loop: create the VM at the starter size, run its real workload for a week, then read three numbers - guest CPU saturation, guest memory pressure (free -h and swap usage), and the host's overall saturation. Grow the resource that is provably short, by one step, and keep a note of what you changed and why.
What this beats: creating every VM at the biggest size "to be safe" (which guarantees the host runs out and everything is slow together), and chasing every graph spike with a settings change. Virtual machines are adjustable by design - use that, and let evidence drive it.
The full process on a live ESXi host - creating the virtual machine, installing Ubuntu and fixing the common problems, exactly as they appear on screen.
Watch Full VideoESXi will let you configure it and even power VMs on, using memory overcommit tricks - but when the running VMs actually need that memory at the same time, the host balloons and then swaps to disk, and performance falls off a cliff. Budget the RAM of simultaneously running VMs against the physical total minus the hypervisor's own share, and treat overcommit as a safety net, not a plan.
For light duties - DNS, a VPN endpoint, a monitoring target, a practice box - yes, honestly it is. Services with real work (databases, file serving to several users, container stacks) earn 2 vCPU quickly, and measurement, not worry, should promote them. Giving a sleepy VM 8 vCPUs does not make it faster; on a busy host it can do the opposite.
Thin disks grow silently as guests write data, and snapshots grow too - every day a snapshot lives, it stores another day of changes. Check the datastore for old snapshot files and forgotten VMs, confirm what each thin disk has actually consumed, and keep a standing free-space margin so growth never reaches the point where ESXi pauses VMs to protect itself.