Multipass VM Stuck in Starting: 3 Quick Fixes

1. Not Enough Disk Space for the VM (Most Common)

This is the culprit in about 70% of cases. Multipass allocates a default disk size when you launch a VM — often 5GB for the root disk. If your host is running low on free space, the VM can't start because it can't write its state file or allocate the backing store.

Check host disk space

# On Linux/macOS
df -h

# On Windows (PowerShell)
Get-PSDrive C | Select-Object Used,Free

If you have less than 10% free space on your system drive, that's your problem. Multipass uses a disk image that grows on demand. If the host can't expand it, the VM stays stuck.

The fix

1. Free up space. Delete temp files, old ISOs, unused VMs.
2. If you can't clear enough space, change the VM's disk allocation to a smaller value (like 3GB) using multipass set local.<instance-name>.disk=3G before starting it.
3. Or just delete and recreate the VM with multipass delete <name> && multipass purge, then launch with multipass launch --disk 3G.

Don't bother tweaking the default disk size in the GUI — it doesn't apply to already-created VMs.

2. Stale Multipass Daemon or Backend Service

Multipass runs a background daemon (on Windows it's a Windows Service, on macOS a launchd job). If that daemon crashes or gets into a weird state, VMs won't transition past 'Starting'. This usually happens after a host update, reboot, or sleep/wake cycle.

Check if the daemon is running

# On macOS
launchctl list | grep multipass

# On Linux
systemctl status multipassd

# On Windows
Get-Service multipass*

If you see it's not running or shows 'stopped', restart it:

# macOS
sudo launchctl unload /Library/LaunchDaemons/com.canonical.multipassd.plist
sudo launchctl load /Library/LaunchDaemons/com.canonical.multipassd.plist

# Linux
sudo systemctl restart multipassd

# Windows
Restart-Service Multipassd

Wait 30 seconds, then try multipass start <vm-name> again. Nine times out of ten this does it.

If the daemon restarts but the VM is still stuck, check the daemon logs:

# macOS/Linux
sudo journalctl -u multipassd -n 50

# Windows
Get-EventLog -LogName Application -Source multipass* -Newest 10

Look for lines containing disk, network, or timeout. If you see something like qemu-system-x86_64: failed to initialize KVM, that's a hardware virtualization issue (enable VT-x/AMD-V in BIOS).

3. Network Bridge or Hyper-V/NAT Conflict

Less common but annoying. Multipass creates a NAT network for VMs. If your host has a VPN active, or if Hyper-V's default switch is misconfigured, the VM can't get an IP and hangs during startup.

Quick test

multipass exec <vm-name> -- ip addr show 2>/dev/null || echo "VM not responding"

If you get no output or an error, the network stack is probably stuck.

The fix

1. Disconnect any VPN temporarily. Try starting the VM again.
2. On Windows, check Hyper-V Manager. Make sure the 'Multipass Switch' (or 'Default Switch') is enabled and not in an error state. If it's broken, delete it and run multipass restart — Multipass recreates it automatically.
3. On macOS, check if your firewall is blocking the bridge: sudo pfctl -s info. If packet filter is enabled, try sudo pfctl -d temporarily.
4. On Linux, check ip link show multipass*. If the bridge interface is down, bring it up with sudo ip link set <interface> up.

If none of these work, the nuclear option is to reset Multipass entirely:

multipass stop --all
multipass delete --all
multipass purge
multipass launch

That rebuilds the whole network and daemon state. You lose your VMs, but it's faster than debugging for an hour.

Quick Reference Summary

I've seen these three scenarios play out over and over. Start with #1, then #2, then #3. You'll have your VM running in under five minutes.