Give a VM too little and it crawls; too much and your host starves. Allocation rules for Windows, Linux and macOS guests.
Updated 11 Nov 2026 · 8 min read
Quick answer
Allocate a VM roughly what you’d give a real machine for the same job, while always leaving the host enough: keep at least 4–6GB for a Windows host (2–4GB for Linux). Practical numbers: 4GB for a light Linux guest, 8GB for a Windows 11 guest, 16GB for a development or testing guest. Total allocated across all running VMs should stay below about 75% of your physical RAM.
Contents
A virtual machine is a computer inside your computer, and its memory comes from the same pool as everything else. Give the guest too little and it crawls; too much and the host starves. The fix is simple arithmetic: a guest gets roughly what a real machine would need for the same job, the host keeps what it needs, and the total stays below about 75% of physical RAM.
How VM memory works: the guest/host split
When you allocate 8GB to a virtual machine, the hypervisor — VirtualBox, VMware, Hyper-V, or whichever you use — reserves that memory from your physical RAM and hands it to the guest operating system. Inside the guest, that memory behaves exactly like physical RAM. From the host’s point of view, that 8GB is gone for as long as the VM is running. That is the fundamental trade, and it is why the host’s share matters as much as the guest’s. A typical Windows 11 host idles at roughly 3–5GB with a normal set of startup apps (an estimate), before you open a browser or the hypervisor’s interface; a Linux host is lighter, typically needing 2–4GB kept aside. Whatever the host cannot get from RAM, it pages to disk — and when both host and guest page at the same time, everything slows down at once.
Allocation cheat sheet
Practical allocations — what you would give a real machine for the same job. “Minimum” runs without constant paging; “smooth” feels like a real machine.
| Guest | Minimum | Smooth |
|---|---|---|
| Linux desktop (Ubuntu etc.) | 2GB | 4GB |
| Linux server / CLI | 512MB–1GB | 2GB |
| Windows 10/11 guest | 4GB | 8GB |
| Windows dev/test guest | 8GB | 16GB |
| macOS guest (where supported) | 4GB | 8GB |
A light Linux guest is the cheapest VM you can run: 4GB gives it a desktop, a browser and a terminal with room to spare, and a headless server guest is happy on 1–2GB. Windows is the expensive one, because a Windows guest has the same baseline as a Windows host — roughly 3–5GB for the OS — before it does any work at all. That is why 4GB is the minimum for a Windows 11 guest and 8GB is the smooth figure. The rule behind the table: allocate a VM roughly what you would give a real machine for the same job.
The host always eats first
The classic beginner error: 16GB host, 12GB given to one VM — then wondering why both are slow. The host is left with 4GB, of which Windows itself takes 3–5GB, leaving nothing for the browser or anything else. The host pages, the guest pages, and both machines crawl. Reserve the host’s share first and allocate the guest from what is left. On a 16GB host, run one 6–8GB VM comfortably. On a 32GB host, the starting point for multiple VMs, you can run two 8GB guests or one 16GB development guest. For a lab with three or more guests, 64GB is where the arithmetic stops being a compromise. See whether 32GB is enough and whether 64GB is overkill.
| Host RAM | Keep for host | Available for VMs | Comfortable setup |
|---|---|---|---|
| 16GB | 6–8GB (Windows) | 8–10GB | One 8GB Windows guest |
| 32GB | 8GB (Windows) | ~24GB | Two 8GB guests, or one 16GB dev guest |
| 64GB | 8GB (Windows) | ~48GB | Several guests / test lab |
The host’s share is not just the operating system — it is the OS, the hypervisor, and whatever you run alongside the VM, usually a browser and often an IDE. A Windows host with a browser full of tabs needs 6–8GB kept aside, not 4GB.
What happens when you over-allocate
Over-allocation has a recognisable signature: everything gets slow at once. The guest is slow because it is paging, the host is slow because it is paging too, and the disk light stays busy. The confusing part is that both machines report plenty of RAM while both are actually starved — the total promised exceeds the physical RAM available, and the shortfall comes from disk. The rule that prevents it: total allocated across all running VMs should stay below about 75% of your physical RAM. On a 32GB host, that is 24GB for guests, leaving 8GB for the host. The 75% figure is a ceiling, not a target. If you are already over-allocated, shut down a VM or reduce an allocation, then check Task Manager’s “Committed” memory on the host (see RAM usage at 100%).
Watch out: never allocate close to 100% of physical RAM across guests. Some hypervisors allow overcommit, but the excess comes from disk swapping and performance collapses. Treat physical RAM as the hard budget.
Dynamic memory and ballooning
Most hypervisors offer a way to avoid fixed allocations: Hyper-V’s Dynamic Memory, VMware’s ballooning, and VirtualBox’s memory controls all let a VM start small and grow on demand. For server guests with spiky loads it works well — a web server that idles at 1GB and spikes to 6GB during a test run is the ideal case. For interactive desktop guests, it is less good: a desktop VM wants its memory resident and stable, and growing on demand shows up as stutters at the exact moment you are trying to do something. Use dynamic memory for server and test guests, and a fixed, sensible allocation for a desktop VM you work in. A fixed 8GB for a Windows desktop guest is smoother than a dynamic 2–16GB range. If you do use dynamic memory, set the startup amount to at least the guest’s minimum.
Running several VMs at once
Running several VMs is where the arithmetic becomes a plan. Work it out on paper before starting the VMs: host share first, then each guest, then check the total against the 75% rule. Two tips: stagger what runs — a lab where guests start on demand uses far less memory than one where everything runs all day — and give each guest only what its job needs. A Linux server guest running a test database does not need 8GB. Storage matters too: several VMs paging at once will hammer a single drive, so put them on a fast NVMe drive and give each VM its own virtual disk file.
| Host RAM | Example setup | Host keeps | Guests total |
|---|---|---|---|
| 16GB | One Windows guest (8GB) | 8GB | 8GB |
| 16GB | Two Linux guests (4GB + 4GB) | 8GB | 8GB |
| 32GB | Windows (8GB) + Linux (8GB) + server (4GB) | 8GB | 20GB |
| 32GB | One Windows dev guest (16GB) | 8GB | 16GB |
| 64GB | Two Windows dev guests (16GB + 16GB) | 8GB | 32GB |
Verdict: how much RAM for a VM?
Allocate a VM roughly what you would give a real machine for the same job, while always leaving the host enough: keep at least 4–6GB for a Windows host (2–4GB for Linux). Practical numbers: 4GB for a light Linux guest, 8GB for a Windows 11 guest, 16GB for a development or testing guest. Total allocated across all running VMs should stay below about 75% of your physical RAM. On a 16GB host, that means one VM at a time, done well. On a 32GB host, two guests, or one heavy development guest. If you are building a machine whose job is virtualisation, 32GB is the realistic starting point and 64GB is where a multi-VM lab stops being a compromise.
Frequently asked questions
Can I allocate more RAM than I physically have?
Some hypervisors allow overcommit, but the excess comes from disk swapping and performance collapses. Treat physical RAM as the hard budget.
How much RAM for 3 VMs at once?
On a 32GB host: host keeps 8GB, then 8GB + 8GB + 4GB across the guests. On 16GB, run them one or two at a time.
How much RAM does a Windows 11 VM need?
4GB minimum to install and run, 8GB to feel smooth. A Windows development or testing guest wants 16GB.
Should I use dynamic memory or a fixed allocation?
Fixed for a desktop VM you work in — it is smoother. Dynamic memory is fine for server or test guests with spiky loads.
Can I change a VM’s RAM after creating it?
Yes — shut the VM down, change the memory setting, and start it again. Most hypervisors do not allow changing RAM on a running VM.