# ===================================================================== #1# BASIC CONFIGURATION2# ===================================================================== #34# Default values in this YAML file are specified by `null` instead of Lima's "builtin default" values,5# so they can be overridden by the $LIMA_HOME/_config/default.yaml mechanism documented at the end of this file.67# VM type: "qemu", "vz" (on macOS 13 and later), or "default".8# The vmType can be specified only on creating the instance.9# The vmType of existing instances cannot be changed.10# 🟢 Builtin default: "vz" (on macOS 13.5 and later), "qemu" (on others)11vmType: null1213# Arch: "default", "x86_64", "aarch64".14# 🟢 Builtin default: "default" (corresponds to the host architecture)15arch: null1617# OpenStack-compatible disk image.18# Each image has a `location` URL for the disk image, an `arch` setting, and an optional `digest`.19# 🟢 Builtin default: none (must be specified)20# 🔵 This file: Ubuntu images (inherited via the `base` mechanism later in this file)21images: []2223# CPUs24# 🟢 Builtin default: min(4, host CPU cores)25cpus: null2627# Memory size28# 🟢 Builtin default: min("4GiB", half of host memory)29memory: null3031# Disk size32# 🟢 Builtin default: "100GiB"33disk: null3435# Expose host directories to the guest, the mount point might be accessible from all UIDs in the guest36# "location" can use these template variables: {{.Home}}, {{.Dir}}, {{.Name}}, {{.UID}}, {{.User}}, {{.Param.Key}},37# {{.GlobalTempDir}}, and {{.TempDir}}. The global temp dir is always "/tmp" on Unix.38# "mountPoint" can use these template variables: {{.Home}}, {{.Name}}, {{.Hostname}}, {{.UID}}, {{.User}}, and {{.Param.Key}}.39# 🟢 Builtin default: [] (Mount nothing)40# 🔵 This file: Mount the home as read-only (inherited via the `base` mechanism later in this file)41# Until Lima v1.2, /tmp/lima was mounted too as writable.42mounts: []43# - location: "~"44# # Configure the mountPoint inside the guest.45# # 🟢 Builtin default: value of location46# mountPoint: null47# # Setting `writable` to true is discouraged when mountType is set to "reverse-sshfs".48# # 🟢 Builtin default: false49# writable: null50# sshfs:51# # Enabling the SSHFS cache will increase performance of the mounted filesystem, at52# # the cost of potentially not reflecting changes made on the host in a timely manner.53# # Warning: It looks like PHP filesystem access does not work correctly when54# # the cache is disabled.55# # 🟢 Builtin default: true56# cache: null57# # SSHFS has an optional flag called 'follow_symlinks'. This allows mounts58# # to be properly resolved in the guest os and allow for access to the59# # contents of the symlink. As a result, symlinked files & folders on the Host60# # system will look and feel like regular files directories in the Guest OS.61# # 🟢 Builtin default: false62# followSymlinks: null63# # SFTP driver, "builtin" or "openssh-sftp-server". "openssh-sftp-server" is recommended.64# # 🟢 Builtin default: "openssh-sftp-server" if OpenSSH SFTP Server binary is found, otherwise "builtin"65# sftpDriver: null66# 9p:67# # Supported security models are "passthrough", "mapped-xattr", "mapped-file" and "none".68# # "mapped-xattr" and "mapped-file" are useful for persistent chown but incompatible with symlinks.69# # 🟢 Builtin default: "none" (since Lima v0.13)70# securityModel: null71# # Select 9P protocol version. Valid options are: "9p2000" (legacy), "9p2000.u", "9p2000.L".72# # 🟢 Builtin default: "9p2000.L"73# protocolVersion: null74# # The number of bytes to use for 9p packet payload, where 4KiB is the absolute minimum.75# # 🟢 Builtin default: "128KiB"76# msize: null77# # Specifies a caching policy. Valid options are: "none", "loose", "fscache" and "mmap".78# # Try choosing "mmap" or "none" if you see a stability issue with the default "fscache".79# # See https://www.kernel.org/doc/Documentation/filesystems/9p.txt80# # 🟢 Builtin default: "fscache" for non-writable mounts, "mmap" for writable mounts81# cache: null8283# List of mount types not supported by the kernel of this distro.84# Also used to resolve the default mount type when not explicitly specified.85#86# NOTE: 9p is broken in Linux v6.9, v6.10, and v6.11.87# The issue was fixed in Linux v6.12-rc5 (https://github.com/torvalds/linux/commit/be2ca38).88#89# 🟢 Builtin default: []90mountTypesUnsupported: null9192# Mount type for above mounts, such as "reverse-sshfs" (from sshocker), "9p" (QEMU’s virtio-9p-pci, aka virtfs),93# or "virtiofs" (experimental on Linux; needs `vmType: vz` on macOS).94# 🟢 Builtin default: "default" (resolved to be "9p" for QEMU since Lima v1.0 on non-Windows, "virtiofs" for vz)95mountType: null9697# Enable inotify support for mounted directories (EXPERIMENTAL)98# 🟢 Builtin default: Disabled by default99mountInotify: null100101# ===================================================================== #102# ADVANCED CONFIGURATION103# ===================================================================== #104105# Lima disks to attach to the instance. The disks will be accessible from inside the106# instance, labeled by name. (e.g. if the disk is named "data", it will be labeled107# "lima-data" inside the instance). The disk will be mounted inside the instance at108# `/mnt/lima-${VOLUME}`.109# 🟢 Builtin default: []110additionalDisks:111# disks should either be a list of disk name strings, for example:112# - "data"113# or a list of disk objects with extra parameters, for example:114# - name: "data"115# format: true116# fsType: "ext4"117118ssh:119# A localhost port of the host. Forwarded to port 22 of the guest.120# 🟢 Builtin default: 0 (automatically assigned to a free port)121localPort: null122# Load ~/.ssh/*.pub in addition to $LIMA_HOME/_config/user.pub .123# This option is useful when you want to use other SSH-based124# applications such as rsync with the Lima instance.125# If you have an insecure key under ~/.ssh, do not use this option.126# 🟢 Builtin default: false (since Lima v1.0)127loadDotSSHPubKeys: null128# Forward ssh agent into the instance.129# The ssh agent socket can be mounted in a container at the path `/run/host-services/ssh-auth.sock`.130# Set the environment variable `SSH_AUTH_SOCK` value to the path above.131# The socket is accessible by the non-root user inside the Lima instance.132# 🟢 Builtin default: false133forwardAgent: null134# Forward X11 into the instance135# 🟢 Builtin default: false136forwardX11: null137# Trust forwarded X11 clients138# 🟢 Builtin default: false139forwardX11Trusted: null140# Enable SSH over vsock.141# 🟢 Builtin default: true for vz, false for other vmTypes142overVsock: null143144caCerts:145# If set to `true`, this will remove all the default trusted CA certificates that146# are normally shipped with the OS.147# 🟢 Builtin default: false148removeDefaults: null149150# A list of trusted CA certificate files. The files will be read and passed to cloud-init.151files:152# - examples/hello.crt153154# A list of trusted CA certificates. These are directly passed to cloud-init.155certs:156# - |157# -----BEGIN CERTIFICATE-----158# YOUR-ORGS-TRUSTED-CA-CERT-HERE159# -----END CERTIFICATE-----160# - |161# -----BEGIN CERTIFICATE-----162# YOUR-ORGS-TRUSTED-CA-CERT-HERE163# -----END CERTIFICATE-----164165# Upgrade the instance on boot166# Reboot after upgrade if required167# 🟢 Builtin default: false168upgradePackages: null169170containerd:171# Enable system-wide (aka rootful) containerd and its dependencies (BuildKit, Stargz Snapshotter)172# Note that `nerdctl.lima` only works in rootless mode; you have to use `lima sudo nerdctl ...`173# to use rootful containerd with nerdctl.174# 🟢 Builtin default: false175system: null176# Enable user-scoped (aka rootless) containerd and its dependencies177# 🟢 Builtin default: true (for x86_64 and aarch64)178user: null179# # Override containerd archive180# # 🟢 Builtin default: hard-coded URL with hard-coded digest (see the output of `limactl info | jq .defaultTemplate.containerd.archives`)181# archives:182# - location: "~/Downloads/nerdctl-full-X.Y.Z-linux-amd64.tar.gz"183# arch: "x86_64"184# digest: "sha256:..."185186# Provisioning scripts need to be idempotent because they might be called187# multiple times, e.g. when the host VM is being restarted.188# The scripts can use the following template variables: {{.Home}}, {{.Name}}, {{.Hostname}}, {{.UID}}, {{.User}}, and {{.Param.Key}}.189#190# EXPERIMENTAL Alternatively the script can be provided using the "file" property. This file is read when the instance191# is created and then stored under the "script" property. When "file" is specified "script" must be empty.192# The "file" property can either be a string (URL), or an object with a "url" and "digest" properties.193# The "digest" property is currently unused.194# Relative script files will be resolved relative to the location of the template file.195# 🟢 Builtin default: []196# provision:197# # `system` is executed with root privileges198# - mode: system199# script: |200# #!/bin/bash201# set -eux -o pipefail202# export DEBIAN_FRONTEND=noninteractive203# apt-get install -y vim204# # `user` is executed without root privileges205# - mode: user206# file:207# url: user-provisioning.sh208# digest: deadbeef209# # `boot` is executed directly by /bin/sh as part of cloud-init-local.service's early boot process,210# # which is why there is no hash-bang specified in the example211# # See cloud-init docs for more info https://docs.cloud-init.io/en/latest/reference/examples.html#run-commands-on-first-boot212# - mode: boot213# script: |214# systemctl disable NetworkManager-wait-online.service215# # `dependency` is executed before the regular dependency resolution workflow in216# # pkg/cidata/cidata.TEMPLATE.d/boot/30-install-packages.sh217# # If skipDefaultDependencyResolution is set on at least one `dependency` mode provisioning script, the regular218# # dependency resolution workflow in pkg/cidata/cidata.TEMPLATE.d/boot/30-install-packages.sh will be skipped.219# - mode: dependency220# skipDefaultDependencyResolution: false221# script: |222# #!/bin/bash223# dnf config-manager --add-repo ...224# dnf install ...225# # `ansible` is executed after other scripts are complete226# # It requires `ansible-playbook` command to be installed.227# # Environment variables such as ANSIBLE_CONFIG can be used, to control the behavior of the playbook execution.228# # See ansible docs, and `ansible-config`, for more info https://docs.ansible.com/ansible/latest/playbook_guide/229# # DEPRECATED The ansible mode is deprecated, and should not be used. Instead call ansible-playbook directly,230# # either from the host after the instance is started or from the instance by running ansible locally instead.231# - mode: ansible232# playbook: playbook.yaml233# # `data` is a file that is written to the guest filesystem and not executed at all.234# # The file is written after the boot scripts, but before any other provisioning scripts are run.235# # Note that reverse-sshfs mounts are not established at this time; other mount types are already mounted.236# # The `path` and `content` properties are required. The `file` property can be used the same way as with237# # other provisioning scripts, in which case `content` must be empty. The `owner` defaults to "root:root";238# # the permissions default to 644. The `overwrite` property defaults to `true`, in which case the file will239# # be overwritten on every boot.240# # `path`, `contents`, and `owner` are evaluated as guest templates (see above).241# - mode: data242# path: /etc/conf.d/example243# content: |244# FOO=bar245# owner: "root:root"246# permissions: 644247# overwrite: false248# # Create or edit a file in the guest filesystem by using `yq`.249# # The file specified by `path` will be updated by `expression`.250# # An empty file of the required `format` will be created if it does not yet exist.251# # `format` defaults to "auto" and will be detected by file extension of `path`.252# # If the extension is not recognized by `yq` then `format` must be set to a253# # value from this list:254# # "auto", "csv", "ini", "json", "props", "tsv", "toml", "xml", "yaml"255# # See https://github.com/mikefarah/yq for more info.256# # Any missing directories will be created as needed.257# # The file permissions will be set to the specified value.258# # The file and directory creation will be performed as the specified owner.259# # If the existing file is not writable by the specified owner, the operation will fail.260# # `path` and `expression` are required.261# # `owner` and `permissions` are optional. Defaults to "root:root" and 644.262# - mode: yq263# path: "{{.Home}}/.config/docker/daemon.json"264# expression: ".features.containerd-snapshotter = {{.Param.containerdSnapshotter}}"265# format: auto266# owner: "{{.User}}"267# permissions: 644268#269# Q. In what order are provision scripts executed?270# A. All provisions are processed per boot by each module in stages of cloud-init as follows:271# 1. cloud-init 'init' stage272# bootcmd:273# - `mode: boot` scripts are executed274#275# 2. cloud-init 'config' stage276# write_files:277# - `00-lima.boot.sh` is created, but not executed278#279# 3. cloud-init 'final' stage280# scripts_per_boot:281# - `00-lima.boot.sh` is executed; remaining provisions are processed in the following order:282# - LIMA pre-defined boot scripts:283# - `boot/{00-..., ..., 25-...}`284# - `boot/30-install-packages.sh`285# - `mode: dependency` scripts are executed286# - `boot/{35-..., ...}`287# - `mode: data` files are copied288# - `mode: yq` files are processed289# - `mode: system` scripts are executed290# - `mode: user` scripts are executed291292# Probe scripts to check readiness.293# The scripts run in user mode. They must start with a '#!' line.294# The scripts can use the following template variables: {{.Home}}, {{.Name}}, {{.Hostname}}, {{.UID}}, {{.User}}, and {{.Param.Key}}.295# EXPERIMENTAL Alternatively the script can be provided using the "file" property. This file is read when the instance296# is created and then stored under the "script" property. When "file" is specified "script" must be empty.297# The "file" property can either be a string (URL), or an object with a "url" and "digest" properties.298# The "digest" property is currently unused.299# Relative script files will be resolved relative to the location of the template file.300# 🟢 Builtin default: []301# probes:302# # Only `readiness` probes are supported right now.303# - mode: readiness304# description: vim to be installed305# script: |306# #!/bin/bash307# set -eux -o pipefail308# if ! timeout 30s bash -c "until command -v vim; do sleep 3; done"; then309# echo >&2 "vim is not installed yet"310# exit 1311# fi312# hint: |313# vim was not installed in the guest. Make sure the package system is working correctly.314# Also see "/var/log/cloud-init-output.log" in the guest.315316# ===================================================================== #317# FURTHER ADVANCED CONFIGURATION318# ===================================================================== #319320# A template should specify the minimum Lima version required to parse this template correctly.321# It should not be set if the minimum version is less than 1.0.0322# 🟢 Builtin default: not set323# 🔵 This file: "1.1.0" to use the `base` templating mechanism324minimumLimaVersion: 2.0.0325326# EXPERIMENTAL327# Default settings can be imported from base templates. These will be merged in when the instance328# is created, and the combined template is stored in the instance directory.329# This setting can be either a single string (URL), or a list of locators.330# A locator is again either a string (URL), or an object with "url" and "digest" properties, e.g.331# base: [{url: ./base.yaml, digest: decafbad}, …]332# The "digest" property is currently unused.333# Any relative base template name will be resolved relative to the location of the main template.334# 🟢 Builtin default: no base template335# 🔵 This file: Ubuntu images and default mount points336base:337- template:_images/ubuntu338- template:_default/mounts339340# User to be used inside the VM341user:342# User name. An explicitly specified username is not validated by Lima.343# 🟢 Builtin default: same as the host username, if it is a valid Linux username, otherwise "lima"344name: null345# Full name or display name of the user.346# 🟢 Builtin default: user information from the host347comment: null348# Numeric user id. It is not currently possible to specify a group id.349# 🟢 Builtin default: same as the host user id of the current user (NOT a lookup of the specified "username").350uid: null351# Home directory inside the VM, NOT the mounted home directory of the host.352# It can use the following template variables: {{.Name}}, {{.Hostname}}, {{.UID}}, {{.User}}, and {{.Param.Key}}.353# 🟢 Builtin default: "/home/{{.User}}.linux"354home: null355# Shell. Needs to be an absolute path.356# 🟢 Builtin default: "/bin/bash"357shell: null358359vmOpts:360qemu:361# Minimum version of QEMU required to create an instance of this template.362# Will be ignored if the vmType is not "qemu"363# 🟢 Builtin default: not set364minimumVersion: null365# Specify desired QEMU CPU type for each arch.366# You can see what options are available for host emulation with: `qemu-system-$(arch) -cpu help`.367# Setting of instructions is supported like this: "qemu64,+ssse3".368# 🟢 Builtin default: hard-coded arch map with type (see the output of `limactl info | jq .defaultTemplate.cpuType`)369cpuType:370# aarch64: "max" # (or "host" when running on aarch64 host)371# armv7l: "max" # (or "host" when running on armv7l host)372# riscv64: "max" # (or "host" when running on riscv64 host)373# x86_64: "max" # (or "host" when running on x86_64 host; additional options are appended on Intel Mac)374vz:375# Specify the disk image format: "raw" or "asif".376# Currently only applies to the primary disk image.377# "asif" requires macOS 26+, and does not support converting back to "raw".378# 🟢 Builtin default: "raw"379diskImageFormat: null380rosetta:381# Enable Rosetta inside the VM; needs `vmType: vz`382# Hint: try `softwareupdate --install-rosetta` if Lima gets stuck at `Installing rosetta...`383# 🟢 Builtin default: false384enabled: null385# Register rosetta to /proc/sys/fs/binfmt_misc386# 🟢 Builtin default: false387binfmt: null388389# OS: "Linux".390# 🟢 Builtin default: "Linux"391os: null392393# DEPRECATED: Use vmOpts.qemu.cpuType instead. See the vmOpts.qemu.cpuType section above for configuration.394cpuType:395396# DEPRECATED: Use vmOpts.vz.rosetta instead. See the vmOpts.qemu.cpuType section above for configuration.397rosetta:398enabled: null399binfmt: null400401# Specify the timezone name (as used by the zoneinfo database). Specify the empty string402# to not set a timezone in the instance.403# 🟢 Builtin default: use name from /etc/timezone or deduce from symlink target of /etc/localtime404timezone: null405406firmware:407# Use legacy BIOS instead of UEFI. Ignored for aarch64 and vz.408# 🟢 Builtin default: false409legacyBIOS: null410# # Override UEFI images411# # 🟢 Builtin default: uses VM's default UEFI, except for qemu + aarch64.412# # See <https://lists.gnu.org/archive/html/qemu-devel/2023-12/msg01694.html>413# images:414# - location: "~/Downloads/edk2-aarch64-code.fd.gz"415# arch: "aarch64"416# digest: "sha256:..."417# vmType: "qemu"418419audio:420# EXPERIMENTAL421# QEMU audiodev, e.g., "none", "coreaudio", "pa", "alsa", "oss".422# VZ driver, use "vz" as device name423# Choosing "none" will mute the audio output, and not play any sound.424# Choosing "default" will pick a suitable choice of: coreaudio, pa, dsound, oss.425# As of QEMU v6.2 the default is to create a disconnected sound device426# that is still visible in the guest but not connected to the host.427# 🟢 Builtin default: ""428device: null429430video:431# QEMU display, e.g., "none", "cocoa", "sdl", "gtk", "vnc", "default".432# Choosing "none" will hide the video output, and not show any window.433# Choosing "vnc" will use a network server, and not show any window.434# Choosing "default" will pick the first available of: gtk, sdl, cocoa.435# As of QEMU v6.2, enabling anything but none or vnc is known to have negative impact436# on performance on macOS hosts: https://gitlab.com/qemu-project/qemu/-/issues/334437# 🟢 Builtin default: "none"438display: null439# VNC (Virtual Network Computing) is a platform-independent graphical440# desktop-sharing system that uses the Remote Frame Buffer protocol (RFB)441vnc:442# VNC display, e.g.,"to=L", "host:d", "unix:path", "none"443# By convention the TCP port is 5900+d, connections from any host.444# 🟢 Builtin default: "127.0.0.1:0,to=9"445display: null446447# The instance can get routable IP addresses from the vmnet framework using448# https://github.com/lima-vm/socket_vmnet.449# 🟢 Builtin default: []450networks:451# Lima can manage daemons for networks defined in $LIMA_HOME/_config/networks.yaml452# automatically. The socket_vmnet binary must be installed into453# secure locations only alterable by the "root" user.454# - lima: shared455# # MAC address of the instance; lima will pick one based on the instance name,456# # so DHCP assigned ip addresses should remain constant over instance restarts.457# macAddress: ""458# # Interface name, defaults to "lima0", "lima1", etc.459# interface: ""460# # Interface metric, lowest metric becomes the preferred route.461# # Defaults to 100. Builtin SLIRP network uses 200.462# metric: 100463#464# Lima can also connect to "unmanaged" networks addressed by "socket". This465# means that the daemons will not be controlled by Lima, but must be started466# before the instance. The interface type (host, shared, or bridged) is467# configured in socket_vmnet and not in lima.468# - socket: "/var/run/socket_vmnet"469470471# The "vzNAT" IP address is accessible from the host, but not from other guests.472# Needs `vmType: vz`473# - vzNAT: true474475# Port forwarding rules. Forwarding between ports 22 and ssh.localPort cannot be overridden.476# Rules are checked sequentially until the first one matches.477# portForwards:478# - guestPort: 443479# hostIP: "0.0.0.0" # overrides the default value "127.0.0.1"; allows privileged port forwarding480# # default: hostPort: 443 (same as guestPort)481# # default: guestIP: "127.0.0.1" (also matches bind addresses "0.0.0.0", "::", and "::1")482# # default: proto: "tcp" (other options: "udp, "any")483#484# - guestPortRange: [4000, 4999]485# hostIP: "0.0.0.0" # overrides the default value "127.0.0.1"486# # default: hostPortRange: [4000, 4999] (must specify same number of ports as guestPortRange)487#488# - guestPort: 80489# hostPort: 8080 # overrides the default value 80490#491# - guestIP: "127.0.0.2" # overrides the default value "127.0.0.1"492# hostIP: "127.0.0.2" # overrides the default value "127.0.0.1"493# # default: guestPortRange: [1, 65535]494# # default: hostPortRange: [1, 65535]495#496# - guestIP: 0.0.0.0 # otherwise defaults to 127.0.0.1497# proto: any # tcp and udp498# ignore: true # don't forward these ports (guestPortRange, in this case 1-65535)499#500# - guestPort: 7443501# guestIP: "0.0.0.0" # Will match *any* interface502# guestIPMustBeZero: false # 0.0.0.0 matches any bound interface, not just 0.0.0.0 itself503# hostIP: "0.0.0.0" # Forwards to 0.0.0.0, exposing it externally504#505# - guestSocket: "/run/user/{{.UID}}/my.sock"506# hostSocket: mysocket507# # default: reverse: false508# # "guestSocket" can include these template variables: {{.Home}}, {{.Name}}, {{.Hostname}}, {{.UID}}, {{.User}}, and {{.Param.Key}}.509# # "hostSocket" can include {{.Home}}, {{.Dir}}, {{.Name}}, {{.UID}}, {{.User}}, and {{.Param.Key}}.510# # "reverse" can only be used for unix sockets right now, not for tcp sockets.511# # Put sockets into "{{.Dir}}/sock" to avoid collision with Lima internal sockets!512# # Sockets can also be forwarded to ports and vice versa, but not to/from a range of ports.513# # Forwarding requires the lima user to have rw access to the "guestsocket",514# # and the local user rwx access to the directory of the "hostsocket".515#516# # Lima internally appends this fallback rule at the end:517# - guestIP: "127.0.0.1"518# proto: "any"519# guestPortRange: [1, 65535]520# hostIP: "127.0.0.1"521# hostPortRange: [1, 65535]522# # Any port still not matched by a rule will not be forwarded (ignored)523524# Copy files from the guest to the host. Copied after provisioning scripts have been completed.525# copyToHost:526# - guest: "/etc/myconfig.cfg"527# host: "{{.Dir}}/copied-from-guest/myconfig"528# # deleteOnStop: false529# # "guest" can include these template variables: {{.Home}}, {{.Name}}, {{.Hostname}}, {{.UID}}, {{.User}}, and {{.Param.Key}}.530# # "host" can include {{.Home}}, {{.Dir}}, {{.Name}}, {{.UID}}, {{.User}}, and {{.Param.Key}}.531# # "deleteOnStop" will delete the file from the host when the instance is stopped.532533# Message. Information to be shown to the user, given as a Go template for the instance.534# The same template variables as for listing instances can be used, for example {{.Dir}}.535# You can view the complete list of variables using `limactl list --list-fields` command.536# It also includes {{.HostOS}} and {{.HostArch}} vars, for the runtime GOOS and GOARCH.537# 🟢 Builtin default: ""538# message: |539# This will be shown to the user.540541# Extra environment variables that will be loaded into the VM at start up.542# These variables are consumed by internal init scripts, and also added543# to /etc/environment.544# If you set any of "ftp_proxy", "http_proxy", "https_proxy", or "no_proxy", then545# Lima will automatically set an uppercase variant to the same value as well.546# 🟢 Builtin default: {}547# env:548# KEY: value549550# Defines variables used for customizing the functionality.551# Key names must start with an uppercase or lowercase letter followed by552# any number of letters, digits, and underscores.553# Values must not contain non-printable characters except for spaces and tabs.554# These variables can be referenced as {{.Param.Key}} in lima.yaml.555# In provisioning scripts and probes they are also available as predefined556# environment variables, prefixed with "PARAM_" (so `Key` → `$PARAM_Key`).557# param:558# Key: value559560# Lima will override the proxy environment variables with values from the current process561# environment (the environment in effect when you run `limactl start`). It will automatically562# replace the strings "localhost" and "127.0.0.1" with the host gateway address from inside563# the VM, so it stays routable. Use of the process environment can be disabled by setting564# propagateProxyEnv to false.565# 🟢 Builtin default: true566propagateProxyEnv: null567568# The host agent implements a DNS server that looks up host names on the host569# using the local system resolver. This means changing VPN and network settings570# are reflected automatically into the guest, including conditional forward,571# and mDNS lookup. By default, only IPv4 addresses will be returned. IPv6 addresses572# can only work when using a vmnet network interface and the host has working573# IPv6 configured as well.574hostResolver:575# 🟢 Builtin default: true576enabled: null577# 🟢 Builtin default: false578ipv6: null579# Static names can be defined here as an alternative to adding them to the hosts /etc/hosts.580# Values can be either other hostnames, or IP addresses. The host.lima.internal name is581# predefined to specify the gateway address to the host.582# 🟢 Builtin default: {}583hosts:584# guest.name: 127.1.1.1585# host.name: host.lima.internal586587# If hostResolver.enabled is false, then the following rules apply for configuring dns:588# Explicitly set DNS addresses for qemu user-mode networking. By default, qemu picks *one*589# nameserver from the host config and forwards all queries to this server. On macOS590# Lima adds the nameservers configured for the first host interface in service order,591# that has an IPv4 address, to the list. In case this still doesn't work (e.g. VPN592# setups), the servers can be specified here explicitly. If nameservers are specified593# here, then the configuration from network preferences will be ignored.594# 🟢 Builtin default: []595# dns:596# - 1.1.1.1597# - 1.0.0.1598599# Prefix to use for installing guest agent, and containerd with dependencies (if configured)600# 🟢 Builtin default: /usr/local601guestInstallPrefix: null602603# When the "plain" mode is enabled:604# - the YAML properties for mounts, port forwarding, containerd, etc. will be ignored605# - guest agent will not be running606# - dependency packages like sshfs will not be installed into the VM607# User-specified provisioning scripts will be still executed.608# 🟢 Builtin default: false609plain: null610611# When the "nestedVirtualization" feature is enabled:612# - Allows running a VM inside the guest VM.613# - The guest VM must configure QEMU with the `-cpu host` parameters to run a nested VM:614# qemu-system-aarch64 -accel kvm -cpu host -M virt615# - Without specifying `-cpu host`, nested virtualization may fail with the error:616# qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument617# - Only supported on Apple M3 or later with `vmType: vz`.618# 🟢 Builtin default: false619nestedVirtualization: null620621# ===================================================================== #622# GLOBAL DEFAULTS AND OVERRIDES623# ===================================================================== #624625# The builtin defaults can be changed globally by creating a $LIMA_HOME/_config/default.yaml626# file. It will be used by ALL instances under the same $LIMA_HOME, and it627# will be applied on each `limactl start`, so can affect instance restarts.628629# A similar mechanism is $LIMA_HOME/_config/override.yaml, which will take630# precedence even over the settings in an instances lima.yaml file.631# It also applies to ALL instances under the same $LIMA_HOME, and is applied632# on each restart. It can be used to globally override settings, e.g. make633# the mount of the home directory writable.634635# EXPERIMENTAL636# A third mechanism is $LIMA_HOME/_config/base.yaml. It is similar to637# `default.yaml` but will be merged during the `base` template embedding638# when the instance is created, and not on every start. It becomes part639# of the lima.yaml file.640641# On each instance start the config settings are determined: If a value is642# not set in `lima.yaml`, then the `default.yaml` is used. If that file643# doesn't exist, or the value is not defined in the file, then the builtin644# default is used. If `override.yaml` exists and defines the value, then645# it overrides whatever has been chosen so far.646647# For slices (e.g. `mounts`, `provision`) and maps (`env`) the entries are648# combined instead of replacing each other. Slices are produced from override649# settings, followed by lima.yaml, followed by default.yaml (but NOT from650# builtin defaults). Maps are produced starting with default.yaml values,651# overwriting with lima.yaml ones, overwriting with override.yaml.652653# Exceptions:654# - `dns` will use the list from the highest priority file; they are not655# combined. If override.yaml defines a list of `dns` entries, then the656# settings in default.yaml and lima.yaml are ignored.657#658# - `mounts` will update the `writable` setting when 2 entries have the659# same `location` value. For this reason they are processed in the opposite660# order: starting with default, followed by lima, and then override.661#662# -`networks` will replace lower priority entries with the same `interface`663# name with higher priority definitions. This does not apply if the664# `interface` field is empty. `networks` are therefore also processed665# in lowest to highest priority order.666667# ===================================================================== #668# END OF TEMPLATE669# ===================================================================== #670671672