The default user-mode network maps the gateway IP to the host's 127.0.0.1,
so the guest can reach every host service via `host.lima.internal`,
including ones bound only to the loopback. That is useful for dev VMs but
exposes local databases and dev servers to a guest that runs untrusted
code, such as a CI runner.
Add `networkOpts.hostLoopback` to lima.yaml (default true, unchanged),
in a new `networkOpts` group for network options. When false, the
in-process gvisor-tap-vsock gateway maps the gateway IP and
0.0.0.0 to 0.0.0.1 instead of 127.0.0.1. The host has no route to 0.0.0.1,
so connections to `host.lima.internal` are refused at once, rather than
going to the host's LAN, and UDP to 0.0.0.0 cannot reach the host's
loopback either. DNS, outbound access and SSH are unaffected.
Only `vmType: vz` supports it. `qemu`, `krunkit`, `wsl2` and `hcs` reject
`false` rather than ignore it (krunkit's default host resolver sends DNS
through `host.lima.internal`, so it needs separate work), and so does a
`user-v2` network, which is a daemon shared by instances. The refusals
are in each driver's Validate, not in validateConfig, which Configure also
runs on deletion.
A proxy on the host's loopback, whether it comes from the host's network
settings, `env`, or `propagateProxyEnv`, is rewritten to the gateway
address, which `networkOpts.hostLoopback: false` makes unreachable. Lima
warns when that happens, and the docs say so.
A BATS test, run in the vz CI job, checks end to end that a host
loopback service is refused at once with `false` and reachable after
switching to `true`, that DNS keeps working, and that a `user-v2`
network is rejected.
Refs #5574
Assisted-by: Claude Code
Signed-off-by: Rana Md Ali Ahsan <rana@codesamplez.com>
An `additionalDisks` entry whose name did not fit in the filesystem label
was reformatted on every boot, silently destroying its contents.
`mkfs.ext4` silently truncates the label to 16 bytes, so a name longer
than 11 characters produced a label that could never match the
`/dev/disk/by-label/lima-${DISK_NAME}` node the first-time-setup guard
tested for. The guard was true on every boot and `mkfs` ran again. The
disk still mounted, because the mount uses the device path, so nothing
appeared to be wrong. (`mkfs.xfs` instead rejects a label over 12 bytes,
so an xfs disk with a name over 7 characters was never formatted at all.)
Identify the disk by the presence of a filesystem on its partition
instead: the guard tests whether `blkid -o value -s TYPE` prints anything.
It tests the output rather than the exit status, because util-linux blkid
exits 0 for a bare GPT partition-table entry that has no filesystem yet,
and BusyBox blkid (Alpine) ignores -o and -s and always exits 0. This
removes the length limit and, because a disk formatted by an older Lima
version also carries a filesystem, such disks are recognised rather than
reformatted on upgrade. A partition left without a filesystem by an
interrupted boot or a failed mkfs is formatted on the next boot. The
guard fails closed: if blkid is missing or reports an error, the disk is
left alone, so a disk whose state cannot be determined is never
reformatted.
The labels are kept as a convenience and clamped to what each filesystem
accepts, so that `mkfs.xfs` no longer aborts the boot. A GPT partition
label, which holds 36 characters, now carries the name as well. For an
fsType not listed here, the limit (and even whether mkfs.$FORMAT_FSTYPE
accepts a label at all) is unknown, so no label is set rather than guess
and risk aborting boot. The label is passed without a bash array, since
on Alpine /bin/bash is BusyBox ash, which has none.
Over-long names are reported at info level rather than as an error: the
disk works correctly now that identification does not depend on the
label. The notice is limited to Linux guests and disks Lima formats, the
only case in which a label is written. The `additionalDisks` comment in
the default template now points at the partition label, which keeps
names of up to 31 characters whole.
The disk-mount test regression check used a plain substring match, which
the new long-named disk's mount point ("/mnt/lima-data-with-a-long-name")
also satisfies, silently defeating the original disk's assertion. Anchor
the pattern to end-of-line.
Fixes#5407
Assisted-by: Claude Code
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Baptiste Collard <9626829+bcollard@users.noreply.github.com>
The documentation and the k3s template pass the control plane as a
URL ("https://<ADDRESS>:6443"), but the k8s template put the url
param into apiServerEndpoint unchanged, and kubeadm expects a bare
host:port there, so the documented command did not work.
Strip the https:// prefix in the template, so both forms work, and
make the template comment and the BATS test use the URL form.
Fixes#5552
Signed-off-by: Sarthak <sarthakshreshtha345@gmail.com>
Additional disks were always mounted at the hardcoded path
/mnt/lima-<name>, with no way to change that location or to attach a disk
without Lima mounting it. Issue #4065 asks for both: a custom mount point
and an attach-only mode so the guest can manage the disk itself (a
flexibility Colima can benefit from).
Add two optional, backwards-compatible fields to each additionalDisks
entry:
- mountPoint: absolute guest path to mount at (default /mnt/lima-<name>)
- mount: whether Lima auto-mounts the disk (default true; false attaches
the disk without mounting it)
A separate `mount` boolean is used rather than overloading an empty
mountPoint, per the discussion in #4065. nil for either field preserves
the current behavior. Values are passed to the guest via
LIMA_CIDATA_DISK_<i>_MOUNT / _MOUNTPOINT and honored by 05-lima-disks.sh
(non-swap disks only). mountPoint is validated to be an absolute guest
path (path.IsAbs, not the host-dependent filepath.IsAbs) and neither a
critical system path nor the reserved guest home directory.
Fixes#4065
Signed-off-by: Eugene Kalinin <e.v.kalinin@gmail.com>
systemd-resolved's LLMNR probe adds a multi-second delay to SSH logins on
Debian. Debian 13's sshd passes an UNKNOWN peer address for vsock connections
to Linux audit, which resolves it via LLMNR; that lookup is the delay.
Set LLMNR=no, gated behind the internal_disableLLMNR param so only the
Debian 13 image template opts in, mirroring the Ubuntu 26.04 workaround
pattern. Other distros keep LLMNR untouched.
Compare the param against the literal "true" rather than testing it for
non-emptiness, so setting it to "false" does not still emit LLMNR=no.
template_test covers "", "false" and "true", so reverting the template
alone fails that subtest.
Record in the debian-13 template why the workaround exists, with the
upstream OpenSSH commit that removes the need for it and the Debian bug
report tracking it downstream.
Fixes#5389
Signed-off-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Attach explicitly allowed host disks through a dedicated root-owned helper,
passing validated file descriptors to unprivileged VZ over an authenticated
Unix socket. Scope sudoers grants to the invoking user and exact device paths,
reject unsafe helper paths and socket symlinks, authenticate both peers, and
validate the received device identity.
Retain descriptors per VM while preserving process-lifetime network wrappers
used by krunkit. Lock whole host disks across instances sharing LIMA_HOME,
including raw/block aliases and partitions. Reject duplicate configuration
entries and external VZ drivers at runtime.
Compose network and block-device sudoers fragments through pkg/sudoers, match
complete generated lines, and warn when regeneration removes existing grants.
Keep integration-test grants in temporary fragments and revoke them before
detaching the test RAM disk. Add security, lifecycle, and real-disk regression
coverage and document installation requirements and remaining grant limits.
Signed-off-by: Nick Sweeting <git@sweeting.me>
Add the `macos-27` template for macOS 27 "Golden Gate" (27.0, build 26A428),
and repoint the `macos` aliases (`templates/macos.yaml` and
`templates/_images/macos.yaml`) from `macos-26` to `macos-27`.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Add support for `nestedVirtualization` in the QEMU driver:
- On macOS (aarch64, HVF): requires QEMU 11.1.0 or later and macOS 15 or
later (Apple M3 or later). QEMU 11.1 added nested virtualization support
to HVF for the aarch64 `virt` machine using `hv_vm_config_set_el2_enabled`
(https://wiki.qemu.org/ChangeLog/11.1). Enabled by appending
`virtualization=on` to the `-machine virt` option.
- On Linux (aarch64, KVM): requires QEMU 10.1.0 or later and a host kernel
(6.16 or later) booted with `kvm-arm.mode=nested`. Enabled by appending
`virtualization=on` to the `-machine virt` option.
- On Linux (x86_64, KVM): verifies that nested virtualization is enabled
in the host KVM module (`kvm_intel` or `kvm_amd` parameter `nested`) and
that CPU type `host` is used.
For unsupported architectures or accelerators, a warning is logged and
the field is ignored.
Tested on Apple M4 / macOS 26.5 with QEMU 11.1.0: the guest kernel
initializes KVM in nVHE mode and a nested KVM VM boots EDK2 to the
UEFI shell.
Fix#5419
Signed-off-by: Sharan Raj T <sharanrajtm@gmail.com>
The vz driver only creates a host output stream, so a guest with
`audio.device: vz` gets a speaker and no microphone: `/dev/snd` has
`pcmC0D0p` but no capture device, and nothing in the guest can record.
Add an opt-in `audio.microphone` boolean, default false. When it is set,
the driver also creates a host input stream and passes both streams to
SetStreams. It is opt-in because an input stream makes macOS ask for
microphone permission on behalf of the process that runs the VM, and
enabling sound alone should not trigger that prompt.
Code-Hex/vz exposes the input stream as
NewVirtioSoundDeviceHostInputStreamConfiguration. It requires macOS 12,
the same as the output stream the driver already creates, so this adds
no new platform requirement.
The key warns as experimental, and setting it without `audio.device`
warns and is ignored, like an `hda` interface request. The QEMU, WSL2,
and krunkit drivers report ignored audio fields via
reflectutil.UnknownNonEmptyFields in validateConfig; FillDefault
materializes every audio field, so zero-value defaults are normalized
back to nil before the check. WSL2's Start()-time audio.interface
warning is removed in favor of that check, and "Audio" joins its
knownYamlProperties so audio settings are reported once. The
--audio-microphone flag and the experimental-features docs entry follow
the audio.interface commit (a9b8e59a).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Vladimir Starkov <iamstarkov@gmail.com>
Make sure that "gnupg" package is installed on the host.
Also "apt-transport-https" is now included in "apt" deb.
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
Now supports a parameter "proxy" for pulling packages from:
proxy: "http://host.lima.internal:3142"
It is not a deb package, but we can still use the apt-proxy.
Need a new URL instead of https_proxy, if we want caching...
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
It has some issues with it being mounted as "nodev",
so revert to using a normal file system for $TMPDIR.
Same as 22b4887683,
when the template was using Fedora instead of Ubuntu.
Also add comment about no tmpfs for APPTAINER_TMPDIR.
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
Current support has some caveats:
- boot mode isn't supported since Windows VM doesn't have an equivalent step to Cloud-init's init stage
- yq mode isn't supported since Windows VM doesn't have yq engine by default
- all data mode files are stored under C:\ProgramData\Lima\provision\provision.data
- skipDefaultDependencyResolution in dependency mode is currently ignored
Signed-off-by: mie313 <mie313.tanaka@gmail.com>
Some distros publish CPU micro-architecture level variants of their
x86_64 cloud images (e.g. x86-64-v3, x86-64-v2) next to the regular one.
They still run as x86_64 in the guest, so they cannot be told apart by
arch alone.
Add an `archVariant` field on image entries, orthogonal to the existing
distro `variant` (server/minimal), plus a `--arch-variant` flag to select
it. Selection at start time filters by archVariant in parallel with
variant, so the base image stays the default and e.g. `--arch-variant v3`
picks the variant image. The arch field is left untouched (no x86_64v3).
Wire up:
- Ubuntu 26.04: amd64v3 image as archVariant v3.
- AlmaLinux 10: x86_64_v2 image as archVariant v2 (10 ships v3 by default
and v2 for older hardware).
Teach the ubuntu/almalinux update scripts to keep the vendor arch name
(amd64v3, x86_64_v2) for the stream-JSON/CHECKSUM lookup while emitting
arch: x86_64 for lima.
Relates to #5160
Signed-off-by: Eugene Kalinin <e.v.kalinin@gmail.com>
Jan Dubois