Configuration guide

• 1: VM types
• 1.1: QEMU
• 1.2: VZ
• 1.3: WSL2
• 1.4: Krunkit
• 2: Intel-on-ARM and ARM-on-Intel
• 3: Network
• 3.1: Default user-mode network
• 3.2: user-v2 network
• 3.3: VMNet networks
• 4: Port Forwarding
• 5: Filesystem mounts
• 6: Environment Variables
• 7: AI
• 7.1: AI agents inside Lima
• 7.2: AI agents outside Lima (MCP)
• 7.2.1: Gemini
• 7.2.2: MCP tools
• 8: GPU acceleration
• 9: Plug-in
• 9.1: VM driver plugins
• 9.2: CLI plugins
• 10: Disks

1 - VM types

Lima supports several VM drivers for running guest machines:

The vmType can be specified only on creating the instance. The vmType of existing instances cannot be changed.

💡 For developers: See Virtual Machine Drivers for technical details about driver architecture and creating custom drivers.

See the following flowchart to choose the best vmType for you:

flowchart
  host{"Host OS"} -- "Windows" --> wsl2["WSL2"]
  host -- "Linux" --> qemu["QEMU"]
  host -- "macOS" --> intel_on_arm{"Need to run <br> Intel binaries <br> on ARM?"}
  intel_on_arm -- "Yes" --> just_elf{"Just need to <br> run Intel userspace (fast), <br> or entire Intel VM (slow)?"}
  just_elf -- "Userspace (fast)" --> vz
  just_elf -- "VM (slow)" --> qemu
  intel_on_arm --  "No" --> vz["VZ"]

The default vmType is QEMU in Lima prior to v1.0. Starting with Lima v1.0, Lima will use VZ by default on macOS (>= 13.5) for new instances, unless the config is incompatible with VZ. (e.g., legacyBIOS or 9p is enabled)

1.1 - QEMU

“qemu” option makes use of QEMU to run guest operating system.

“qemu” is the default driver for Linux hosts.

Recommended QEMU version:

• v8.2.1 or later (macOS)
• v6.2.0 or later (Linux)

An example configuration:

• CLI
• YAML

limactl start --vm-type=qemu

vmType: "qemu"

base:
- template://_images/ubuntu
- template://_default/mounts

1.2 - VZ

“vz” option makes use of native virtualization support provided by macOS Virtualization.Framework.

“vz” has been the default driver for macOS hosts since Lima v1.0.

An example configuration (no need to be specified manually):

• CLI
• YAML

limactl start --vm-type=vz

vmType: "vz"

base:
- template://_images/ubuntu
- template://_default/mounts

Caveats

• “vz” option is only supported on macOS 13 or above
• Virtualization.framework doesn’t support running “intel guest on arm” and vice versa

Known Issues

• “vz” doesn’t support legacyBIOS: true option, so guest machine like centos-stream and oraclelinux-8 will not work on Intel Mac.
• When running lima using “vz”, ${LIMA_HOME}/<INSTANCE>/serial.log will not contain kernel boot logs
• On Intel Mac with macOS prior to 13.5, Linux kernel v6.2 (used by Ubuntu 23.04, Fedora 38, etc.) is known to be unbootable on vz. kernel v6.3 and later should boot, as long as it is booted via GRUB. https://github.com/lima-vm/lima/issues/1577#issuecomment-1565625668 The issue is fixed in macOS 13.5.

1.3 - WSL2

Warning “wsl2” mode is experimental

“wsl2” option makes use of native virtualization support provided by Windows’ wsl.exe (more info).

An example configuration:

• CLI
• YAML

limactl start --vm-type=wsl2 --mount-type=wsl2 --containerd=system

# Example to run Fedora using vmType: wsl2
vmType: wsl2
images:
# Source: https://github.com/runfinch/finch-core/blob/main/Dockerfile
- location: "https://deps.runfinch.com/common/x86-64/finch-rootfs-production-amd64-1690920103.tar.zst"
  arch: "x86_64"
  digest: "sha256:53f2e329b8da0f6a25e025d1f6cc262ae228402ba615ad095739b2f0ec6babc9"
mountType: wsl2
containerd:
  system: true
  user: false

Caveats

• “wsl2” option is only supported on newer versions of Windows (roughly anything since 2019)

Known Issues

• “wsl2” currently doesn’t support many of Lima’s options. See this file for the latest supported options.
• When running lima using “wsl2”, ${LIMA_HOME}/<INSTANCE>/serial.log will not contain kernel boot logs
• WSL2 requires a tar formatted rootfs archive instead of a VM image
• Windows doesn’t ship with ssh.exe, gzip.exe, etc. which are used by Lima at various points. The easiest way around this is to run winget install -e --id Git.MinGit (winget is now built in to Windows as well), and add the resulting C:\Program Files\Git\usr\bin\ directory to your path.

1.4 - Krunkit

Warning “krunkit” is experimental

Krunkit runs super‑light VMs on macOS/ARM64 with a focus on GPU access. It builds on libkrun, a library that embeds a VMM so apps can launch processes in a hardware‑isolated VM (HVF on macOS, KVM on Linux). The standout feature is GPU support in the guest via Mesa’s Venus Vulkan driver (venus), enabling Vulkan workloads inside the VM. See the project: containers/krunkit.

Install krunkit (host)

brew tap slp/krunkit
brew install krunkit

For reference: https://github.com/slp/homebrew-krun

Using the driver with Lima

The krunkit driver is usually bundled with Lima as an external driver:

$ limactl info | jq .vmTypesEx
{
  "krunkit": {
    "location": "/opt/homebrew/Cellar/lima/2.0.1/libexec/lima/lima-driver-krunkit"
  },
  "qemu": {
    "location": "internal"
  },
  "vz": {
    "location": "internal"
  }
}

If the driver is not installed, build and install the driver as follows:

git clone https://github.com/lima-vm/lima
cd lima
# Replace vX.Y.Z with the actual version
git checkout vX.Y.Z
make ADDITIONAL_DRIVERS=krunkit additional-drivers
# Replace /usr/local with the actual installation prefix
cp -a _output/libexec/lima/lima-driver-krunkit /usr/local/libexec/lima/

See also Developers’ guide » Virtual Machine Drivers.

Quick start

You can run AI models either:

• With containers (fast to get started; any distro works), or
• Without containers (choose Fedora; build llama.cpp from source).

Before running, install a small model on the host so examples can run quickly. We’ll use Qwen3‑1.7B GGUF:

mkdir -p models
curl -LO --output-dir models 'https://huggingface.co/Qwen/Qwen3-1.7B-GGUF/resolve/main/Qwen3-1.7B-Q8_0.gguf'

1) Run models using containers (easiest)

Start a krunkit VM with the default Lima template:

• CLI

limactl start --vm-type=krunkit
limactl shell default

Then inside the VM:

nerdctl run --rm -ti \
  --device /dev/dri \
  -v $(pwd)/models:/models \
  quay.io/slopezpa/fedora-vgpu-llama

For reference: https://sinrega.org/2024-03-06-enabling-containers-gpu-macos/

Once inside the container:

llama-cli -m /models/Qwen3-1.7B-Q8_0.gguf -b 512 -ngl 99 -p "Introduce yourself"

You can now chat with the model.

2) Run models without containers (hard way)

This path builds and installs dependencies (which can take some time. For faster builds, allocate more CPUs and memory to the VM. See options). Use Fedora as the image.

• CLI
• YAML

limactl start --vm-type=krunkit template://fedora
limactl shell fedora

vmType: krunkit

base:
- template://_images/fedora
- template://_default/mounts

mountType: virtiofs

Once inside the VM, install GPU/Vulkan support:

#!/bin/bash
# SPDX-FileCopyrightText: Copyright The Lima Authors
# SPDX-License-Identifier: Apache-2.0

set -eu -o pipefail

# Install required packages
dnf install -y dnf-plugins-core dnf-plugin-versionlock llvm18-libs

# Install Vulkan and Mesa base packages
dnf install -y \
  mesa-vulkan-drivers \
  vulkan-loader-devel \
  vulkan-headers \
  vulkan-tools \
  vulkan-loader \
  glslc

# Enable COPR repo with patched Mesa for Venus support
dnf copr enable -y slp/mesa-krunkit fedora-40-aarch64

# Downgrade to patched Mesa version from COPR
dnf downgrade -y mesa-vulkan-drivers.aarch64 \
  --repo=copr:copr.fedorainfracloud.org:slp:mesa-krunkit

# Lock Mesa version to prevent automatic upgrades
dnf versionlock add mesa-vulkan-drivers

# Clean up
dnf clean all

echo "Installing llama.cpp with Vulkan support..."
# Build and install llama.cpp with Vulkan support
dnf install -y git cmake clang curl-devel glslc vulkan-devel virglrenderer
(
  cd ~
  git clone https://github.com/ggml-org/llama.cpp
  (
    cd llama.cpp
    cmake -B build -DGGML_VULKAN=ON -DGGML_CCACHE=OFF -DGGML_NATIVE=OFF -DCMAKE_INSTALL_PREFIX=/usr
    cmake --build build --config Release -j8
    cmake --install build
  )
  rm -fr llama.cpp
)

echo "Successfully installed llama.cpp with Vulkan support. Use 'llama-cli' app with .gguf models."

The script will prompt to build and install llama.cpp with Venus support from source.

After installation, run:

llama-cli -m models/Qwen3-1.7B-Q8_0.gguf -b 512 -ngl 99 -p "Introduce yourself"

and enjoy chatting with the AI model.

Notes and caveats

• macOS Ventura or later on Apple Silicon is required.
• To verify GPU/Vulkan in the guest container or VM, use tools like vulkaninfo --summary.
• AI models on containers can run on any Linux distribution but without containers Fedora is required.
• For more information about usage of llama-cli. See llama.cpp README.md.
• Driver architecture details: see Virtual Machine Drivers.

2 - Intel-on-ARM and ARM-on-Intel

Lima supports several modes for running Intel-on-ARM and ARM-on-Intel:

• Slow mode
• Fast mode
• Fast mode 2

Slow mode: Intel VM on ARM Host / ARM VM on Intel Host

Lima can run a VM with a foreign architecture, using QEMU.

For port forwarding, the lima-additional-guestagents package has to be installed on the host.

An example configuration:

• CLI
• YAML

limactl start --vm-type=qemu --arch=x86_64 --plain

# Starting with Lima v2.0, `vmType` has to be expclitly set to "qemu" on non-Linux hosts.
vmType: "qemu"

# Supported architectures:
#   Non-experimental: aarch64, x86_64
#   Experimental:     armv7l, ppc64le, riscv64, s390x
#
# containerd is not automatically installed for the experimental architectures.
arch: "x86_64"

# A slow host may need `plain` to disable mounts, port forwards, and containerd, so as to avoid timeout.
plain: true

base:
- template://_images/ubuntu

Running a VM with a foreign architecture is extremely slow. Consider using Fast mode or Fast mode 2 whenever possible.

Fast mode: Intel containers on ARM VM on ARM Host / ARM containers on Intel VM on Intel Host

This mode uses QEMU User Mode Emulation. QEMU User Mode Emulation is significantly faster than QEMU System Mode Emulation, but it often sacrifices compatibility.

Set up:

lima sudo systemctl start containerd
lima sudo nerdctl run --privileged --rm tonistiigi/binfmt:qemu-v10.0.4-56@sha256:30cc9a4d03765acac9be2ed0afc23af1ad018aed2c28ea4be8c2eb9afe03fbd1 --install all

Run containers:

$ lima nerdctl run --platform=amd64 --rm alpine uname -m
x86_64

$ lima nerdctl run --platform=arm64 --rm alpine uname -m
aarch64

Build and push container images:

$ lima nerdctl build --platform=amd64,arm64 -t example.com/foo:latest .
$ lima nerdctl push --all-platforms example.com/foo:latest

See also https://github.com/containerd/nerdctl/blob/main/docs/multi-platform.md

Fast mode 2 (Rosetta): Intel containers on ARM VM on ARM Host

Rosetta is known to be much faster than QEMU User Mode Emulation. Rosetta is available for VZ instances on ARM hosts.

• CLI
• YAML

limactl start --vm-type=vz --rosetta

vmType: "vz"
rosetta:
  # Enable Rosetta for Linux.
  # Hint: try `softwareupdate --install-rosetta` if Lima gets stuck at `Installing rosetta...`
  enabled: true
  # Register rosetta to /proc/sys/fs/binfmt_misc
  binfmt: true

Enable Rosetta AOT Caching with CDI spec

Rosetta AOT Caching speeds up containers by saving translated binaries, so they don’t need to be translated again.
Learn more: WWDC2023 video

How to use Rosetta AOT Caching:

• Run a container:
  Add --device=lima-vm.io/rosetta=cached to your docker run command:

  docker run --platform=linux/amd64 --device=lima-vm.io/rosetta=cached ...
  

• Build an image:
  Add # syntax=docker/dockerfile:1-labs at the top of your Dockerfile to enable the --device option.
  Use --device=lima-vm.io/rosetta=cached in your RUN command:

  # syntax=docker/dockerfile:1-labs
  FROM ...
  ...
  RUN --device=lima-vm.io/rosetta=cached <your amd64 command>
  

• Check if caching works:
  Look for cache files in the VM:

  limactl shell {{.Name}} ls -la /var/cache/rosettad
  docker run --platform linux/amd64 --device=lima-vm.io/rosetta=cached ubuntu echo hello
  limactl shell {{.Name}} ls -la /var/cache/rosettad
  # You should see *.aotcache files here
  

• Check if Docker recognizes the CDI device:
  Look for CDI info in the output of docker info:

  docker info
  ...
  CDI spec directories:
    /etc/cdi
    /var/run/cdi
  Discovered Devices:
    cdi: lima-vm.io/rosetta=cached
  

• Learn more about CDI:
  CDI spec documentation

3 - Network

See the following flowchart to choose the best network for you:

flowchart
connect_to_vm_via{"Connect to the VM via"} -- "localhost" --> default["Default"]
  connect_to_vm_via -- "IP" --> connect_from{"Connect to the VM IP from"}
  connect_from -- "Host" --> vm{"VM type"}
  vm -- "vz" --> vzNAT["vzNAT (see the VMNet page)"]
  vm -- "qemu" --> shared["socket_vmnet (shared)"]
  connect_from -- "Other VMs" --> userV2["user-v2"]
  connect_from -- "Other hosts" --> bridged["socket_vmnet (bridged)"]

3.1 - Default user-mode network

By default Lima only enables the user-mode networking aka “slirp”.

The subnet is hard-coded to 192.168.5.0/24. Use user-v2 network to customize the subnet.

Guest IP (192.168.5.15)

The guest IP address is set to 192.168.5.15.

This IP address is not accessible from the host by design.

Use VMNet to allow accessing the guest IP from the host and other guests.

Host IP (192.168.5.2)

The loopback addresses of the host is 192.168.5.2 and is accessible from the guest as host.lima.internal.

DNS (192.168.5.3)

If hostResolver.enabled in lima.yaml is true, then the hostagent is going to run a DNS server over tcp and udp - each on a separate randomly selected free port. This server does a local lookup using the native host resolver, so it will deal correctly with VPN configurations and split-DNS setups, as well as mDNS, local /etc/hosts etc. For this the hostagent has to be compiled with CGO_ENABLED=1 as default Go resolver is broken.

These tcp and udp ports are then forwarded via iptables rules to 192.168.5.3:53, overriding the DNS provided by QEMU via slirp.

Currently following request types are supported:

• A
• AAAA
• CNAME
• TXT
• NS
• MX
• SRV

For all other queries hostagent will redirect the query to the nameservers specified in /etc/resolv.conf (or, if that fails - to 8.8.8.8 and 1.1.1.1).

DNS over tcp is rarely used. It is usually only used either when user explicitly requires it, or when request+response can’t fit into a single UDP packet (most likely in case of DNSSEC), or in the case of certain management operations such as domain transfers. Neither DNSSEC nor management operations are currently supported by a hostagent, but on the off chance that the response may contain an unusually long list of records - hostagent will also listen for the tcp traffic.

During initial cloud-init bootstrap, iptables may not yet be installed. In that case the repo server is determined using the slirp DNS. After iptables has been installed, the forwarding rule is applied, switching over to the hostagent DNS.

If hostResolver.enabled is false, then DNS servers can be configured manually in lima.yaml via the dns setting. If that list is empty, then Lima will either use the slirp DNS (on Linux), or the nameservers from the first host interface in service order that has an assigned IPv4 address (on macOS).

3.2 - user-v2 network

user-v2 network provides a user-mode networking similar to the default user-mode network and also provides support for vm -> vm communication.

To enable this network mode, define a network with mode: user-v2 in networks.yaml

By default, the below network configuration is already applied (Since v0.18).

...
networks:
  user-v2:
    mode: user-v2
    gateway: 192.168.104.1
    netmask: 255.255.255.0
...

Instances can then reference these networks from their lima.yaml file:

• CLI
• YAML

limactl start --network=lima:user-v2

networks:
   - lima: user-v2

An instance’s IP address is resolvable from another instance as lima-<NAME>.internal. (e.g., lima-default.internal.).

Note

Enabling user-v2 network will disable the default user-mode network.

Accessing VMs from the host

By default, the lima-<NAME>.internal hostnames are only resolvable from within the guest VMs. To access the guest network from the host, use limactl tunnel to create a SOCKS proxy:

limactl tunnel <INSTANCE>

The command will output the proxy address (the port is randomly assigned):

$ limactl tunnel default
Set `ALL_PROXY=socks5h://127.0.0.1:<PORT>`, etc.
The instance can be connected from the host as <http://lima-default.internal> via a web browser.

You can then access any VM on the user-v2 network from the host using the SOCKS proxy:

• curl
• Environment variable
• Web browser

curl --proxy socks5h://127.0.0.1:<PORT> http://lima-default.internal

export ALL_PROXY=socks5h://127.0.0.1:<PORT>
curl http://lima-default.internal

Note

limactl tunnel is experimental.

3.3 - VMNet networks

VMNet assigns a “real” IP address that is reachable from the host.

The configuration steps are different for each network type:

• vzNAT
• socket_vmnet

vzNAT

For VZ instances, the “vzNAT” network can be configured as follows:

• CLI
• YAML

limactl start --vm-type=vz --network=vzNAT

networks:
- vzNAT: true

The range of the IP address is not specifiable.

The “vzNAT” network does not need the socket_vmnet binary and the sudoers file.

The “vzNAT” network also has a significant advantage in the throughput. See the benchmark result.

socket_vmnet

Managed (192.168.105.0/24)

socket_vmnet can be used for adding another guest IP that is accessible from the host and other guests, without depending on vz. It must be installed according to the instruction provided on https://github.com/lima-vm/socket_vmnet.

Note that installation using Homebrew is not secure and not recommended by the Lima project. Homebrew installation will only work with Lima if password-less sudo is enabled for the current user. The limactl sudoers command requires that socket_vmnet is installed into a secure path only writable by root and will reject socket_vmnet installed by Homebrew into a user-writable location.

# Install socket_vmnet as root from source to /opt/socket_vmnet
# using instructions on https://github.com/lima-vm/socket_vmnet
# This assumes that Xcode Command Line Tools are already installed
git clone https://github.com/lima-vm/socket_vmnet
cd socket_vmnet
# Change "v1.2.2" to the actual latest release in https://github.com/lima-vm/socket_vmnet/releases
git checkout v1.2.2
make
sudo make PREFIX=/opt/socket_vmnet install.bin

# Set up the sudoers file for launching socket_vmnet from Lima
limactl sudoers >etc_sudoers.d_lima
less etc_sudoers.d_lima  # verify that the file looks correct
sudo install -o root etc_sudoers.d_lima /etc/sudoers.d/lima
rm etc_sudoers.d_lima

Note

Lima before v0.12 used vde_vmnet for managing the networks. vde_vmnet is no longer supported.

Lima v0.14.0 and later used to also accept socket_vmnet installations if they were owned by the admin user. Starting with v1.0.0 only root ownership is acceptable.

The networks are defined in $LIMA_HOME/_config/networks.yaml. If this file doesn’t already exist, it will be created with these default settings:

# Path to socket_vmnet executable. Because socket_vmnet is invoked via sudo it should be
# installed where only root can modify/replace it. This means also none of the
# parent directories should be writable by the user.
#
# The varRun directory also must not be writable by the user because it will
# include the socket_vmnet pid file. Those will be terminated via sudo, so replacing
# the pid file would allow killing of arbitrary privileged processes. varRun
# however MUST be writable by the daemon user.
#
# None of the paths segments may be symlinks, why it has to be /private/var
# instead of /var etc.
paths:
# socketVMNet requires Lima >= 0.12 .
  socketVMNet: /opt/socket_vmnet/bin/socket_vmnet
  varRun: /private/var/run/lima
  sudoers: /private/etc/sudoers.d/lima

group: everyone

networks:
  shared:
    mode: shared
    gateway: 192.168.105.1
    dhcpEnd: 192.168.105.254
    netmask: 255.255.255.0
  bridged:
    mode: bridged
    interface: en0
    # bridged mode doesn't have a gateway; dhcp is managed by outside network
  host:
    mode: host
    gateway: 192.168.106.1
    dhcpEnd: 192.168.106.254
    netmask: 255.255.255.0

Instances can then reference these networks:

• CLI
• YAML

limactl start --network=lima:shared

networks:
  # Lima can manage the socket_vmnet daemon for networks defined in $LIMA_HOME/_config/networks.yaml automatically.
  # The socket_vmnet binary must be installed into a secure location only alterable by the "root" user.
  # - lima: shared
  #   # MAC address of the instance; lima will pick one based on the instance name,
  #   # so DHCP assigned ip addresses should remain constant over instance restarts.
  #   macAddress: ""
  #   # Interface name, defaults to "lima0", "lima1", etc.
  #   interface: ""

The network daemon is started automatically when the first instance referencing them is started, and will stop automatically once the last instance has stopped. Daemon logs will be stored in the $LIMA_HOME/_networks directory.

Since the commands to start and stop the socket_vmnet daemon requires root, the user either must have password-less sudo enabled, or add the required commands to a sudoers file. This can be done via:

limactl sudoers >etc_sudoers.d_lima
less etc_sudoers.d_lima  # verify that the file looks correct
sudo install -o root etc_sudoers.d_lima /etc/sudoers.d/lima
rm etc_sudoers.d_lima

The IP address is automatically assigned by macOS’s bootpd. If the IP address is not assigned, try the following commands:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/libexec/bootpd
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblock /usr/libexec/bootpd

Unmanaged

Lima can also connect to “unmanaged” networks addressed by “socket”. This means that the daemons will not be controlled by Lima, but must be started before the instance. The interface type (host, shared, or bridged) is configured in socket_vmnet and not in lima.

networks:
  - socket: "/var/run/socket_vmnet"

4 - Port Forwarding

Lima supports automatic port-forwarding of localhost ports from guest to host.

Port forwarding types

Lima supports two port forwarders: SSH and GRPC.

The default port forwarder is shown in the following table.

The default was once changed to GRPC in Lima v1.0, but it was reverted to SSH in v1.0.1 due to stability reasons. The default was further reverted to GRPC in Lima v1.1, as the stability issues were resolved.

Using SSH

SSH based port forwarding was previously the default mode.

To explicitly use SSH forwarding use the below command

LIMA_SSH_PORT_FORWARDER=true limactl start

Advantages

• Outperforms GRPC when VSOCK is available

Caveats

• Doesn’t support UDP based port forwarding
• Spawns child process on host for running SSH master.

SSH over AF_VSOCK

If VM is VZ based and systemd is v256 or later (e.g. Ubuntu 24.10+), Lima uses AF_VSOCK for communication between host and guest. SSH based port forwarding is much faster when using AF_VSOCK compared to traditional virtual network based port forwarding.

To disable this feature, set .ssh.overVsock to false:

limactl start --set '.ssh.overVsock=false'

Using GRPC

In this model, lima uses existing GRPC communication (Host <-> Guest) to tunnel port forwarding requests. For each port forwarding request, a GRPC tunnel is created and this will be used for transmitting data

To enable this feature, set LIMA_SSH_PORT_FORWARDER to false:

LIMA_SSH_PORT_FORWARDER=false limactl start

Advantages

• Supports both TCP and UDP based port forwarding
• Performs faster compared to SSH based forwarding, when VSOCK is not available
• No additional child process for port forwarding

Accessing ports by IP address

To access a guest’s ports by its IP address, connect the guest to the vzNAT or the lima:shared network.

The vzNAT network is extremely faster and easier to use, however, vzNAT is only available for VZ guests.

limactl start --network vzNAT
lima ip addr show lima0

See Config » Network » VMNet networks for the further information.

Benchmarks

The benchmarks detail above are obtained using the following commands

Host -> limactl start vz

VZ Guest -> iperf3 -s

Host -> iperf3 -c 127.0.0.1 //Benchmark for TCP (average of "sender" and "receiver")
Host -> iperf3 -c 127.0.0.1 -R //Benchmark for TCP Reverse (same as above)

The benchmark result, especially the throughput of vzNAT, highly depends on the performance of the hardware.

5 - Filesystem mounts

Lima supports several methods for mounting the host filesystem into the guest.

The default mount type is shown in the following table:

Mount types

reverse-sshfs

The “reverse-sshfs” mount type exposes the host filesystem by running an SFTP server on the host. While the host works as an SFTP server, the host does not open any TCP port, as the host initiates an SSH connection into the guest and let the guest connect to the SFTP server via the stdin.

An example configuration:

• CLI
• YAML

limactl start --mount-type=reverse-sshfs

mountType: "reverse-sshfs"
mounts:
- location: "~"
  sshfs:
    # Enabling the SSHFS cache will increase performance of the mounted filesystem, at
    # the cost of potentially not reflecting changes made on the host in a timely manner.
    # Warning: It looks like PHP filesystem access does not work correctly when
    # the cache is disabled.
    # 🟢 Builtin default: true
    cache: null
    # SSHFS has an optional flag called 'follow_symlinks'. This allows mounts
    # to be properly resolved in the guest os and allow for access to the
    # contents of the symlink. As a result, symlinked files & folders on the Host
    # system will look and feel like regular files directories in the Guest OS.
    # 🟢 Builtin default: false
    followSymlinks: null
    # SFTP driver, "builtin" or "openssh-sftp-server". "openssh-sftp-server" is recommended.
    # 🟢 Builtin default: "openssh-sftp-server" if OpenSSH SFTP Server binary is found, otherwise "builtin"
    sftpDriver: null

The default value of sftpDriver has been set to “openssh-sftp-server” since Lima v0.10, when an OpenSSH SFTP Server binary such as /usr/libexec/sftp-server is detected on the host. Lima prior to v0.10 had used “builtin” as the SFTP driver.

Caveats

• A mount is disabled when the SSH connection was shut down.
• A compromised sshfs process in the guest may have access to unexposed host directories.

9p

The “9p” mount type is implemented by using QEMU’s virtio-9p-pci devices. virtio-9p-pci is also known as “virtfs”, but note that this is unrelated to virtio-fs.

An example configuration:

• CLI
• YAML

limactl start --vm-type=qemu --mount-type=9p

vmType: "qemu"
mountType: "9p"
mounts:
- location: "~"
  9p:
    # Supported security models are "passthrough", "mapped-xattr", "mapped-file" and "none".
    # "mapped-xattr" and "mapped-file" are useful for persistent chown but incompatible with symlinks.
    # 🟢 Builtin default: "none" (since Lima v0.13)
    securityModel: null
    # Select 9P protocol version. Valid options are: "9p2000" (legacy), "9p2000.u", "9p2000.L".
    # 🟢 Builtin default: "9p2000.L"
    protocolVersion: null
    # The number of bytes to use for 9p packet payload, where 4KiB is the absolute minimum.
    # 🟢 Builtin default: "128KiB"
    msize: null
    # Specifies a caching policy. Valid options are: "none", "loose", "fscache" and "mmap".
    # Try choosing "mmap" or "none" if you see a stability issue with the default "fscache".
    # See https://www.kernel.org/doc/Documentation/filesystems/9p.txt
    # 🟢 Builtin default: "fscache" for non-writable mounts, "mmap" for writable mounts
    cache: null

The “9p” mount type requires Lima v0.10.0 or later.

Caveats

• The “9p” mount type is known to be incompatible with CentOS, Rocky Linux, and AlmaLinux as their kernel do not support CONFIG_NET_9P_VIRTIO.

virtiofs

Warning “virtiofs” mode is experimental on Linux hosts

The “virtiofs” mount type is implemented via the virtio-fs device by using apple Virtualization.Framework shared directory on macOS and virtiofsd on Linux. Linux guest kernel must enable the CONFIG_VIRTIO_FS support for this support.

An example configuration:

• CLI
• YAML

limactl start --vm-type=vz --mount-type=virtiofs

vmType: "vz"  # only for macOS; Linux uses 'qemu'
mountType: "virtiofs"
mounts:
- location: "~"

Caveats

• For macOS, the “virtiofs” mount type is supported only on macOS 13 or above with vmType: vz config. See also vmtype.
• For Linux, the “virtiofs” mount type requires the Rust version of virtiofsd. Using the version from QEMU (usually packaged as qemu-virtiofsd) will not work, as it requires root access to run.

wsl2

Warning “wsl2” mode is experimental

The “wsl2” mount type relies on using WSL2’s native disk sharing, where the root disk is available by default at /mnt/$DISK_LETTER (e.g. /mnt/c/).

An example configuration:

• CLI
• YAML

limactl start --vm-type=wsl2 --mount-type=wsl2

vmType: "wsl2"
mountType: "wsl2"

Caveats

• WSL2 file permissions may not work exactly as expected when accessing files that are natively on the Windows disk (more info)
• WSL2’s disk sharing system uses a 9P protocol server, making the performance similar to Lima’s 9p mode (more info)

Mount Inotify

Warning “mountInotify” is experimental

The mountInotify support enables inotify support for all different mountTypes like 9p, virtiofs etc.

When mountInotify is enabled,

• hostagent will listen and send inotify events from host machine to guest.
• Guest will modify the file to trigger inotify on guest side

This support will be enabled only for writable mounts because only for writable mount guest will be able to trigger inotify

An example configuration:

• CLI
• YAML

limactl start --mount-inotify

mountInotify: true
mounts:
  - location: "~"
    writable: true

Caveats

• For mountType: 9p, Inotify events are not triggered for nested files from the listening directory.
• Inotify events are not triggered when files are removed from host

6 - Environment Variables

Environment Variables

This page documents the environment variables used in Lima.

LIMA_HOME

• Description: Specifies the Lima home directory.
• Default: ~/.lima
• Usage:

  export LIMA_HOME=~/.lima-custom
  lima
  

LIMA_INSTANCE

• Description: Specifies the name of the Lima instance to use.
• Default: default
• Usage:

  export LIMA_INSTANCE=my-instance
  lima uname -a
  

LIMA_SHELL

• Description: Specifies the shell interpreter to use inside the Lima instance.
• Default: User’s shell configured inside the instance
• Usage:

  export LIMA_SHELL=/bin/bash
  lima
  

LIMA_TEMPLATES_PATH

• Description: Specifies the directories used to resolve template:// URLs.
• Default: $LIMA_HOME/_templates:/usr/local/share/lima/templates
• Usage:

  export LIMA_TEMPLATES_PATH="$HOME/.config/lima/templates:/usr/local/share/lima/templates"
  limactl create --name my-vm template://my-distro
  

LIMA_WORKDIR

• Description: Specifies the initial working directory inside the Lima instance.
• Default: Current directory from the host
• Usage:

  export LIMA_WORKDIR=/home/user/project
  lima
  

LIMA_SHELLENV_ALLOW

• Description: Specifies a comma-separated list of environment variable patterns to allow when propagating environment variables to the Lima instance with --preserve-env. When set, only variables matching these patterns will be passed through, completely overriding the default block list behavior. This feature only applies to Lima v2.0.0 or later.
• Default: unset (when using --preserve-env, all variables are propagated except those matching the block list patterns)
• Usage:

  export LIMA_SHELLENV_ALLOW="FPATH,XAUTHORITY,CUSTOM_*"
  limactl shell --preserve-env default
  

• Behavior:
  • Without --preserve-env: No environment variables are propagated (regardless of this setting)
  • With --preserve-env and LIMA_SHELLENV_ALLOW unset: All variables are propagated except those in the block list
  • With --preserve-env and LIMA_SHELLENV_ALLOW set: Only variables matching the allow patterns are propagated (block list is ignored)
• Note: Patterns support wildcards using * at the end (e.g., CUSTOM_* matches CUSTOM_VAR, CUSTOM_PATH, etc.).

LIMA_SHELLENV_BLOCK

• Description: Specifies a comma-separated list of environment variable patterns to block when propagating environment variables to the Lima instance with --preserve-env. Can either replace the default block list or extend it by prefixing with +. This feature only applies to Lima v2.0.0 or later.

• Default: A predefined list of system and shell-specific variables that should not be propagated:

  • Shell variables: BASH*, SHELL, SHLVL, ZSH*, ZDOTDIR, FPATH
  • System paths: PATH, PWD, OLDPWD, TMPDIR
  • User/system info: HOME, USER, LOGNAME, UID, GID, EUID, GROUP, HOSTNAME
  • Display/terminal: DISPLAY, TERM, TERMINFO, XAUTHORITY, XDG_*
  • SSH/security: SSH_*
  • Dynamic linker: DYLD_*, LD_*
  • Internal variables: _* (variables starting with underscore)

  See GetDefaultBlockList() for the complete list.

• Usage:

  # Replace default block list entirely (not recommended)
  export LIMA_SHELLENV_BLOCK="SECRET_*,PRIVATE_*"
  
  # Extend default block list (recommended)
  export LIMA_SHELLENV_BLOCK="+SECRET_*,PRIVATE_*"
  limactl shell --preserve-env default
  

• Note: Patterns support wildcards using * at the end (e.g., SSH_* matches SSH_AUTH_SOCK, SSH_AGENT_PID). Use the + prefix to add to the default block list rather than replacing it entirely. This variable only affects the --preserve-env flag behavior.

LIMACTL

• Description: Specifies the path to the limactl binary.
• Default: limactl in $PATH
• Usage:

  export LIMACTL=/usr/local/bin/limactl
  lima
  

LIMA_SSH_OVER_VSOCK

• Description: Specifies to use vsock for SSH connection instead of port forwarding.
• Default: true (since v2.0.0)
• Usage:

  export LIMA_SSH_OVER_VSOCK=true
  

• Note: This variable is effective only if the VM is VZ based and systemd is v256 or later (e.g. Ubuntu 24.10+).
• Deprecated: This variable is deprecated in favor of the YAML field .ssh.overVsock (since v2.0.2).

LIMA_SSH_PORT_FORWARDER

• Description: Specifies to use the SSH port forwarder (slow) instead of gRPC (fast, previously unstable)
• Default: false (since v1.1.0)
• Usage:

  export LIMA_SSH_PORT_FORWARDER=false
  

• The history of the default value:

  Version	Default value
  v0.1.0	true, effectively
  v1.0.0	false
  v1.0.1	true
  v1.1.0	false

LIMA_USERNET_RESOLVE_IP_ADDRESS_TIMEOUT

• Description: Specifies the timeout duration for resolving the IP address in usernet.
• Default: 2 minutes
• Usage:

  export LIMA_USERNET_RESOLVE_IP_ADDRESS_TIMEOUT=5
  

_LIMA_QEMU_UEFI_IN_BIOS

• Description: Commands QEMU to load x86_64 UEFI images using -bios instead of pflash drives.
• Default: false on Unix like hosts and true on Windows hosts
• Usage:

  export _LIMA_QEMU_UEFI_IN_BIOS=true
  

• Note: It is expected that this variable will be set to false by default in future when QEMU supports pflash UEFI for accelerated guests on Windows.

_LIMA_WINDOWS_EXTRA_PATH

• Description: Additional directories which will be added to PATH by limactl.exe process to search for tools. It is useful, when there is a need to prevent collisions between binaries available in active shell and ones used by limactl.exe - injecting them only for the running process w/o altering PATH observed by user shell. Is is Windows specific and does nothing for other platforms.
• Default: unset
• Usage:

  set _LIMA_WINDOWS_EXTRA_PATH=C:\Program Files\Git\usr\bin
  

• Note: It is an experimental setting and has no guarantees being ever promoted to stable. It may be removed or changed at any stage of project development.

QEMU_SYSTEM_AARCH64

• Description: Path to the qemu-system-aarch64 binary.
• Default: qemu-system-aarch64 found in $PATH
• Usage:

  export QEMU_SYSTEM_AARCH64=/usr/local/bin/qemu-system-aarch64
  

QEMU_SYSTEM_ARM

• Description: Path to the qemu-system-arm binary.
• Default: qemu-system-arm found in $PATH
• Usage:

  export QEMU_SYSTEM_ARM=/usr/local/bin/qemu-system-arm
  

QEMU_SYSTEM_PPC64

• Description: Path to the qemu-system-ppc64 binary.
• Default: qemu-system-ppc64 found in $PATH
• Usage:

  export QEMU_SYSTEM_PPC64=/usr/local/bin/qemu-system-ppc64
  

QEMU_SYSTEM_RISCV64

• Description: Path to the qemu-system-riscv64 binary.
• Default: qemu-system-riscv64 found in $PATH
• Usage:

  export QEMU_SYSTEM_RISCV64=/usr/local/bin/qemu-system-riscv64
  

QEMU_SYSTEM_S390X

• Description: Path to the qemu-system-s390x binary.
• Default: qemu-system-s390x found in $PATH
• Usage:

  export QEMU_SYSTEM_S390X=/usr/local/bin/qemu-system-s390x
  

QEMU_SYSTEM_X86_64

• Description: Path to the qemu-system-x86_64 binary.
• Default: qemu-system-x86_64 found in $PATH
• Usage:

  export QEMU_SYSTEM_X86_64=/usr/local/bin/qemu-system-x86_64
  

7 - AI

There are two kinds of scenario to use Lima with AI:

• AI agents inside Lima: running an AI agent inside a VM
• AI agents outside Lima: calling Lima’s MCP tools from an AI agent running outside a VM

7.1 - AI agents inside Lima

Lima is useful for running AI agents (e.g., Claude Code, Codex, Gemini) inside a VM, so as to prevent agents from directly reading, writing, or executing the host files.

See also:

• Examples » AI.
• Config » GPU

7.2 - AI agents outside Lima (MCP)

Starting with Lima v2.0, Lima provides Model Context Protocol (MCP) tools for reading, writing, and executing local files using a VM sandbox.

7.2.1 - Gemini

This page describes how to use Lima as an sandbox for Google Gemini CLI.

Prerequisite

In addition to Gemini and Lima, make sure that limactl mcp plugin is installed:

$ limactl mcp -v
limactl-mcp version 2.0.0-alpha.1

The limactl mcp plugin is bundled in Lima since v2.0, however, it may not be installed depending on the method of the installation.

Configuration

1. Run the default Lima instance, with a mount of your project directory:

limactl start --mount-only "$(pwd):w" default

Drop the :w suffix if you do not want to allow writing to the mounted directory.

2. Create .gemini/extensions/lima/gemini-extension.json as follows:

{
  "name": "lima",
  "version": "2.0.0",
  "mcpServers": {
    "lima": {
      "command": "limactl",
      "args": [
        "mcp",
        "serve",
        "default"
      ]
    }
  }
}

3. Modify .gemini/settings.json so as to disable Gemini CLI’s built-in tools except ones that do not relate to local command execution and file I/O:

{
  "coreTools": ["WebFetchTool", "WebSearchTool", "MemoryTool"]
}

Usage

Just run gemini in your project directory.

Gemini automatically recognizes the MCP tools provided by Lima.

7.2.2 - MCP tools

Lima implements the “MCP Sandbox Interface” (tentative name): https://pkg.go.dev/github.com/lima-vm/lima/v2/pkg/mcp/msi

MCP Sandbox Interface defines MCP (Model Context Protocol) tools that can be used for reading, writing, and executing local files with an appropriate sandboxing technology, such as Lima.

The sandboxing technology can be more secure and/or efficient than the default tools provided by an AI agent.

MCP Sandbox Interface was inspired by Google Gemini CLI’s built-in tools.

glob

Description

Finds files matching specific glob patterns (e.g., src/**/*.ts, *.md)

Input Schema

{
    "additionalProperties": false,
    "properties": {
        "path": {
            "description": "The absolute path to the directory to search within. If omitted, searches the tool's root directory.",
            "type": [
                "null",
                "string"
            ]
        },
        "pattern": {
            "description": "The glob pattern to match against (e.g., '*.py', 'src/**/*.js').",
            "type": "string"
        }
    },
    "required": [
        "pattern"
    ],
    "type": "object"
}

Output Schema

{
    "additionalProperties": false,
    "properties": {
        "matches": {
            "description": "A list of absolute file paths that match the provided glob pattern.",
            "items": {
                "type": "string"
            },
            "type": "array"
        }
    },
    "required": [
        "matches"
    ],
    "type": "object"
}

list_directory

Description

Lists the names of files and subdirectories directly within a specified directory path.

Input Schema

{
    "additionalProperties": false,
    "properties": {
        "path": {
            "description": "The absolute path to the directory to list.",
            "type": "string"
        }
    },
    "required": [
        "path"
    ],
    "type": "object"
}

Output Schema

{
    "additionalProperties": false,
    "properties": {
        "entries": {
            "description": "The directory content entries.",
            "items": {
                "additionalProperties": false,
                "properties": {
                    "is_dir": {
                        "description": "true for a directory",
                        "type": [
                            "null",
                            "boolean"
                        ]
                    },
                    "mode": {
                        "description": "file mode bits",
                        "type": [
                            "null",
                            "integer"
                        ]
                    },
                    "name": {
                        "description": "base name of the file",
                        "type": "string"
                    },
                    "size": {
                        "description": "length in bytes for regular files; system-dependent for others",
                        "type": [
                            "null",
                            "integer"
                        ]
                    },
                    "time": {
                        "description": "modification time",
                        "type": "string"
                    }
                },
                "required": [
                    "name"
                ],
                "type": "object"
            },
            "type": "array"
        }
    },
    "required": [
        "entries"
    ],
    "type": "object"
}

read_file

Description

Reads and returns the content of a specified file.

Input Schema

{
    "additionalProperties": false,
    "properties": {
        "path": {
            "description": "The absolute path to the file to read.",
            "type": "string"
        }
    },
    "required": [
        "path"
    ],
    "type": "object"
}

Output Schema

{
    "additionalProperties": false,
    "properties": {
        "content": {
            "description": "The content of the file.",
            "type": "string"
        }
    },
    "required": [
        "content"
    ],
    "type": "object"
}

run_shell_command

Description

Executes a given shell command.

Input Schema

{
    "additionalProperties": false,
    "properties": {
        "command": {
            "description": "The exact shell command to execute. Defined as a string slice, unlike Gemini's run_shell_command that defines it as a single string.",
            "items": {
                "type": "string"
            },
            "type": "array"
        },
        "description": {
            "description": "A brief description of the command's purpose, which will be potentially shown to the user.",
            "type": "string"
        },
        "directory": {
            "description": "The absolute directory in which to execute the command. Unlike Gemini's run_shell_command, this must not be a relative path, and must not be empty.",
            "type": "string"
        }
    },
    "required": [
        "command",
        "directory"
    ],
    "type": "object"
}

Output Schema

{
    "additionalProperties": false,
    "properties": {
        "error": {
            "description": "Any error message reported by the subprocess.",
            "type": "string"
        },
        "exit_code": {
            "description": "Exit code of the command.",
            "type": [
                "null",
                "integer"
            ]
        },
        "stderr": {
            "description": "Output from the standard error stream.",
            "type": "string"
        },
        "stdout": {
            "description": "Output from the standard output stream.",
            "type": "string"
        }
    },
    "required": [
        "stdout",
        "stderr"
    ],
    "type": "object"
}

search_file_content

Description

Searches for a regular expression pattern within the content of files in a specified directory. Internally calls ‘git grep -n –no-index’.

Input Schema

{
    "additionalProperties": false,
    "properties": {
        "include": {
            "description": "A glob pattern to filter which files are searched (e.g., '*.js', 'src/**/*.{ts,tsx}'). If omitted, searches most files (respecting common ignores).",
            "type": [
                "null",
                "string"
            ]
        },
        "path": {
            "description": "The absolute path to the directory to search within. Defaults to the current working directory.",
            "type": [
                "null",
                "string"
            ]
        },
        "pattern": {
            "description": "The regular expression (regex) to search for (e.g., 'function\\s+myFunction').",
            "type": "string"
        }
    },
    "required": [
        "pattern"
    ],
    "type": "object"
}

Output Schema

{
    "additionalProperties": false,
    "properties": {
        "git_grep_output": {
            "description": "The raw output from the 'git grep -n --no-index' command, containing matching lines with filenames and line numbers.",
            "type": "string"
        }
    },
    "required": [
        "git_grep_output"
    ],
    "type": "object"
}

write_file

Description

Writes content to a specified file. If the file exists, it will be overwritten. If the file doesn’t exist, it (and any necessary parent directories) will be created.

Input Schema

{
    "additionalProperties": false,
    "properties": {
        "content": {
            "description": "The content to write into the file.",
            "type": "string"
        },
        "path": {
            "description": "The absolute path to the file to write to.",
            "type": "string"
        }
    },
    "required": [
        "path",
        "content"
    ],
    "type": "object"
}

Output Schema

{
    "additionalProperties": false,
    "type": "object"
}

8 - GPU acceleration

Lima VM supports GPU acceleration for the following VM types:

• krunkit.

9 - Plug-in

9.1 - VM driver plugins

See Virtual Machine Drivers.

9.2 - CLI plugins

Warning Support for CLI plugins is experimental

Lima supports a plugin-like command aliasing system similar to git, kubectl, and docker. When you run a limactl command that doesn’t exist, Lima will automatically look for an external program named limactl-<command> in your system’s PATH and additional directories.

Plugin Discovery

Lima discovers plugins by scanning for executables named limactl-<plugin-name> in the following locations:

1. Directory containing the limactl binary (including symlink support)
2. All directories in your $PATH environment variable
3. <PREFIX>/libexec/lima - For plugins installed by package managers or distribution packages

Plugin discovery respects symlinks, ensuring that even if limactl is installed via Homebrew and points to a symlink, all plugins are correctly discovered.

Plugin Information

Available plugins are automatically displayed in:

• limactl --help - Shows all discovered plugins with descriptions in an “Available Plugins (Experimental)” section

Available Plugins (Experimental):
  ps                  Sample limactl-ps alias that shows running instances
  sh

• limactl info - Includes plugin information in the JSON output

{
   "plugins": [
      {
         "name": "ps",
         "path": "/opt/homebrew/bin/limactl-ps"
      },
      {
         "name": "sh",
         "path": "/opt/homebrew/bin/limactl-sh"
      }
   ]
}

Plugin Descriptions

Lima extracts plugin descriptions from script comments using the <limactl-desc> format. Include a description comment in your plugin script:

#!/bin/sh
# <limactl-desc>Docker wrapper that connects to Docker daemon running in Lima instance</limactl-desc>
set -eu

# Rest of your script...

Format Requirements:

• Only files beginning with a shebang (#!) are treated as scripts, and their <limactl-desc> lines will be extracted as the plugin description i.e Must contain exactly <limactl-desc>Description text</limactl-desc>
• The description text should be concise and descriptive

Limitations:

• Binary executables cannot have descriptions extracted and will appear in the help output without a description
• If no <limactl-desc> comment is found in a script, the plugin will appear in the help output without a description

Creating Custom Aliases

To create a custom alias, create an executable script with the name limactl-<alias> and place it somewhere in your PATH.

Example: Creating a ps alias for listing instances

1. Create a script called limactl-ps:

   #!/bin/sh
   # Show instances in a compact format
   limactl list --format table "$@"
   

2. Make it executable and place it in your PATH:

   chmod +x limactl-ps
   sudo mv limactl-ps /usr/local/bin/
   

3. Now you can use it:

   limactl ps                    # Shows instances in table format
   limactl ps --quiet            # Shows only instance names
   

Example: Creating an sh alias

#!/bin/sh
# limactl-sh - Connect to an instance shell
limactl shell "$@"

After creating this alias:

limactl sh default           # Equivalent to: limactl shell default
limactl sh myinstance bash   # Equivalent to: limactl shell myinstance bash

How It Works

1. When you run limactl <unknown-command>, Lima first tries to find a built-in command
2. If found, Lima executes the external program and passes all remaining arguments to it
3. If not found, Lima shows the standard “unknown command” error

This system allows you to:

• Create personal shortcuts and aliases
• Extend Lima’s functionality without modifying the core application
• Share custom commands with your team by distributing scripts
• Package plugins with Lima distributions in the libexec/lima directory

Package Installation

Distribution packages and package managers can install plugins in <PREFIX>/libexec/lima/ where <PREFIX> is typically /usr/local or /opt/homebrew. This allows plugins to be:

• Managed by the package manager
• Isolated from user’s $PATH
• Automatically discovered by Lima

Experimental Status

Experimental Feature: The CLI plugin system is currently experimental and may change in future versions. Breaking changes to the plugin API or discovery mechanism may occur without notice.

10 - Disks

This guide explains how to increase the disk size of a Lima VM when you’ve run out of space, as well as how to edit the disk size using the limactl CLI.

Resize Disk Using limactl

Starting with v1.1, Lima supports editing the disk size of an existing instance using the --disk flag with the limactl edit command.
This is the recommended and simplest way to resize your VM disk.

limactl edit <vm-name> --disk <new-size>

Example for 20GB:

limactl edit default --disk 20

Note:

• Increasing disk size is supported, but shrinking disks is not recommended.
• The instance may need to be stopped before editing disk size.