# WSL and VM Setup

Running Linux inside Windows or macOS through a subsystem or virtual machine, to get a Linux host without dedicated hardware.

**Rests on:** LTS Distribution Choice

**Leads to:** Tailscale Mesh Networking

*MLOps and Platform · Self-Hosting*


## Why learn this

This is the foundation for everything else in your self-hosting journey. Without Linux, you cannot run Docker, containers, or any of the services you plan to host. By the end of this page, you will have a working Linux environment on your Windows or macOS machine, with the knowledge to configure it to start automatically and avoid the performance pitfalls that catch most beginners. This unlocks: installing Docker, managing containers, setting up reverse proxies, and eventually hosting your own AI models.


## The intuition

Imagine you want to run a restaurant, but your kitchen was designed for making coffee. You could renovate, but that's expensive and risky. Instead, you set up a complete second kitchen inside your existing one — a separate, self-contained space where you can cook anything, while your coffee machine stays untouched. That's what WSL and VMs do: they create a private, isolated Linux 'kitchen' inside your Windows or macOS 'coffee shop'.

Both WSL and VMs achieve the same goal — running Linux on your computer without erasing your main operating system — but they do it in fundamentally different ways. A VM is like building a full model kitchen: it simulates an entire computer, complete with its own hardware, inside your real one. It's powerful and realistic, but it's heavy — it needs to pretend to have a CPU, memory, and disk, which takes a toll on performance.

WSL (Windows Subsystem for Linux) is smarter. Instead of simulating a whole computer, it runs the Linux kernel — the core of the operating system — directly on top of Windows, sharing the same hardware. Think of it as having a special pass that lets you use the real kitchen equipment without tearing down the walls, while still keeping your coffee machine running. This makes WSL much faster and lighter than a VM, starting in seconds and using only the memory it needs.

The catch? WSL and VMs both have a 'boundary' between your main system and Linux. Files you keep inside WSL stay in a special place that Windows can see, but moving files across that boundary is slow — like carrying groceries from the coffee shop to the model kitchen every time you want to cook. This is the 'gotcha' mentioned in your notes: keep your work inside Linux, not in Windows, and you'll be fine.


## An analogy

Think of WSL and VMs as different ways to run a second shop inside your existing one.

**The VM is a model shop.** You build a complete miniature version of a bakery inside your coffee shop — with a tiny oven, a tiny display case, and even a fake clock. It looks and works like a real bakery, but everything runs slower because it's all pretend. If you want to bake a loaf, you have to wait for the model oven to heat up, and you can't actually sell the bread — it's fake. That's a VM: it simulates hardware, so it's faithful but slow and resource-hungry.

**WSL is a kitchen pass.** Instead of building a model bakery, you get a special key that lets you use the actual ovens, mixers, and counters in the real bakery you share with the coffee shop. You can bake real bread, fast, using the same equipment. The downside? The bakery is right next to the coffee shop, and the door between them is narrow. If you try to carry a huge bag of flour through, it's a bottleneck — that's like copying files between Windows and WSL.

**Where the analogy breaks down:** In real kitchens, you can carry more flour if you make multiple trips. But in WSL, the door is fixed — the cross-boundary file access is slow regardless of how you do it, so you learn to keep your flour (your files) in the bakery (WSL) and not carry it through the door.

Another difference: the VM's model shop is fully enclosed — nothing leaks in or out. That's great for security, but it also means you need to configure everything inside it from scratch. WSL, being closer to the real hardware, shares more with Windows, which can be both a blessing (easier integration) and a curse (less isolation).


## Definition

WSL and VMs are two ways to run a Linux operating system inside Windows or macOS, giving you a Linux host without needing a separate computer — WSL by running the Linux kernel directly atop your existing OS, and VMs by simulating a complete virtual computer.


## How it connects

You haven't mastered any prior concept yet — this is your starting point. But looking ahead, this page directly feeds into your self-hosting journey. The notes in your library mention that 'WSL gives a genuine Linux environment on Windows with little overhead' and that 'autostart configuration is what makes it behave like a real server' — we'll cover both here. This concept connects to your neighbouring topics: 'Containerization' (you need Linux to run Docker), 'Reverse Proxy and TLS' (your Linux host will need to run nginx eventually), and 'Tailscale Mesh Networking' (you'll want to reach your services securely, which will live on this Linux environment). After this, you'll be ready for 'Container Orchestration Basics' and 'Docker Compose', which build directly on having a working Linux host.


## The mathematics

This concept doesn't require heavy mathematics, but there's one arithmetic idea that will help you understand resource allocation: percentages and ratios. When you create a VM, you decide how much of your real computer's memory (RAM) and processing power (CPU) to give it. That's a fraction — half, a quarter, a tenth — of what you actually have. Similarly, WSL has a setting that restricts how much memory it can use, often set as a percentage of your total RAM.

The second mathematical idea is the concept of a **ratio** — comparing two numbers. For example, if your computer has 16 GB of RAM and you give WSL 8 GB, that's a 1:2 ratio — WSL gets half. If you give a VM 4 GB, that's a 1:4 ratio. Understanding this helps you avoid a nasty surprise: if you allocate too much to Linux, your Windows or macOS might slow to a crawl because you've left yourself too little.

We'll also touch on **exponential growth** when we talk about disk space — your Linux environment's virtual disk starts small (a few GB) but can grow as you install more software. It's like compound interest, but in reverse — the more you install, the more space you need, and it grows faster than you expect.

Remaining memory for host OS = Total RAM - (VM allocation + WSL allocation)

Percent remaining = (Remaining memory / Total RAM) × 100


## A worked example

```
Suppose your computer has 16 GB of RAM. You want to run a VM for testing, so you allocate 4 GB to it. You also install WSL and set a memory limit of 8 GB. Calculate how much memory is left for your main operating system.

Step 1: 16 GB total - 4 GB (VM) = 12 GB remaining   # Subtract the VM's allocation from your total RAM.
Step 2: 12 GB - 8 GB (WSL) = 4 GB remaining   # Subtract WSL's allocation from the remaining RAM.
Step 3: 4 GB / 16 GB = 0.25 = 25%   # Calculate what fraction of your total RAM is left for Windows/macOS.

Result: Your main OS only gets 4 GB out of 16, which is 25% — likely too little, causing slowdowns. This illustrates why careful allocation matters.
```


## From scratch, in Python

```python
# A simple Python script to simulate the resource allocation calculation
# This script helps you visualise the arithmetic we did by hand.

# --- Building blocks ---
# A variable stores a value. A list holds values in order. A function is a reusable block of code.

# First, let's create a function that calculates remaining memory.
def remaining_memory(total_ram, vm_ram, wsl_ram):
    # This is like the formula: subtract VM and WSL allocations from total.
    left_over = total_ram - (vm_ram + wsl_ram)
    return left_over

# We can also calculate the percentage.
def percent_remaining(remaining, total):
    return (remaining / total) * 100

# Now let's use these functions with real numbers.
total = 16  # GB, your computer's RAM
vm = 4      # GB, allocated to a VM
wsl = 8     # GB, allocated to WSL

left = remaining_memory(total, vm, wsl)
print("Memory left for your main OS:", left, "GB")

percent = percent_remaining(left, total)
print("That is", percent, "percent of your total RAM.")

# You can run this script and try different numbers to see the effect.
```


## What the code does

We start with a function `remaining_memory` — that's a block of code we can reuse. It takes three numbers, adds the VM and WSL allocations together, subtracts from the total, and gives back the result. Then we have `percent_remaining` which divides the remaining by the total and multiplies by 100 to get a percentage. Below that, we set some real numbers (16, 4, 8) and call the functions, printing the results. Try changing the numbers to see what happens — for instance, if you set `vm = 8`, your main OS will be left with zero!


## Common misconceptions

**WSL is a virtual machine** — WSL is just another virtual machine, so it's slow and heavy like a VM.

WSL2 uses a lightweight, real Linux kernel that runs directly on Windows, not a simulated computer. It starts in seconds, uses memory dynamically, and shares the host's hardware efficiently. In fact: WSL is a genuine Linux environment with minimal overhead, whereas a VM simulates entire hardware, making it heavier and slower.

**WSL is for running a few commands only** — WSL is only good for running simple command-line tools, not full servers.

WSL2 can run full Linux distributions, including systemd, Docker, and any server software. It behaves like a real Linux box. In fact: WSL is a complete Linux environment capable of running production-grade services, including containers and databases.

**Files on Windows are fine to access from Linux** — I can keep my project files in C:\Users... and access them from WSL without issue.

Accessing files on the Windows filesystem from WSL crosses a boundary that incurs a huge performance penalty (often 10x slower) due to system call translation. In fact: Keep your files inside the WSL filesystem (e.g., ~/projects) for fast access; only use /mnt/c for occasional interop.

**VMs are better than WSL** — Since VMs are 'real' computers, they are always better for running servers.

VMs have overhead — they consume CPU and memory for simulating hardware. For most workloads, WSL2's Linux kernel is just as capable and far more efficient. In fact: Choice depends: VMs are better for complete isolation and testing different OSes, while WSL2 is lighter and integrates seamlessly for development.

**WSL needs extra hardware** — Running WSL requires a separate hard drive or a second machine.

WSL runs on your existing hardware, using a virtual disk that grows dynamically without partitioning. In fact: WSL uses a single file on your Windows drive as its virtual disk, requiring no extra hardware.

**Autostart is automatic** — Once I install WSL, services will start automatically when I reboot.

By default, WSL doesn't start services on Windows boot — you need to configure systemd or a startup task. In fact: To make WSL behave like a real server, you must explicitly configure autostart for WSL and the services inside it.


## In short

WSL gives you a real Linux environment inside Windows with minimal overhead, while a VM gives you a fully isolated simulated computer. Start with WSL for development, keep your files on the Linux side, and configure autostart to turn it into a server. Remember the resource allocation arithmetic so you don't choke your main OS.


## Where this is used

Here's where this concept gets real. In your self-hosting journey, this Linux environment is the bedrock for everything you'll run.

- **Large language models (LLMs):** If you ever want to host your own LLM (like a local ChatGPT), you'll need a Linux environment with powerful GPUs. WSL2 supports GPU passthrough on Windows, so you can train or run inference on your NVIDIA GPU without a separate Linux machine. In practice, you'd use a tool like `ollama` or `transformers` from Hugging Face, which rely on the Linux kernel to manage memory and processes efficiently.
- **Small language models on devices:** For on-device models (like a keyword spotter on your phone), you might not use WSL, but the principles of resource allocation apply — you have limited memory and need to optimise. Understanding how to allocate memory in WSL teaches you the mindset for squeezing models into tiny footprints.
- **Retrieval-augmented generation (RAG):** RAG systems need a vector database (like Chroma or Weaviate) and an embedding model. These run as services on a Linux host. With WSL, you can set up these services locally, test them, and later deploy to a cloud Linux server, confident the environment is the same.
- **Agentic systems:** Agents that plan, call tools, and act in loops are orchestrated by frameworks like LangChain. These run on Linux servers. By hosting them in WSL, you can develop and test them on your local machine before moving to a production VPS.
- **Everyday applied ML:** Recommendation systems, fraud detection, vision — most ML pipelines are developed on Linux. Data scientists often use WSL to get a Linux shell for PyTorch and TensorFlow without dual-booting.

**What a developer actually writes:** They open a WSL terminal, run `nvidia-smi` to check GPU availability, then create a Python virtual environment, install PyTorch with `pip install torch`, and start training. For a VM, they'd use something like VirtualBox or VMware, install Ubuntu, and then SSH into it to run similar commands.

**What breaks when done badly:** If you misconfigure memory limits, your main OS becomes unresponsive. If you keep your project files in Windows rather than inside WSL, file I/O becomes painfully slow — a 10x performance hit is common. If you don't set up autostart, your services won't come back up after a reboot, breaking your self-hosting promise of 'always on'.


---

Read this on the web: https://basavapurushottam.com/learn-ai/wsl-and-vm-setup
