Lima v2.3 replaces the QEMU‑based Windows path with a native driver that talks directly to the Windows Host Compute System (HCS) API, introduces a privileged helper that provides real‑IP networking on Linux hosts, and ships a menu‑driven terminal UI. For anyone who spins up local VMs to sandbox AI workloads, run CI pipelines, or test security controls, the release removes extra toolchains, makes network reachability predictable, and improves day‑to‑day ergonomics.
Native Windows driver (HCS)
The new hcs driver is the third option for Windows, alongside the existing wsl2 and QEMU drivers. It leverages the same virtualization layer that powers WSL2, so VMs start without QEMU or a Unix toolchain. To use it, enable Hyper‑V, add the user to the Hyper‑V Administrators group, and restart the terminal. Then launch a VM with:
limactl start --vm-type hcs --plain --dns 8.8.8.8 limaOnly plain mode is supported: there are no file mounts, no dynamic port forwarding, and only a single HCS instance can run because the HCN subnet is fixed. A DNS server must be supplied via --dns. The driver now auto‑detects the Windows built‑in SSH client, resolves Windows paths correctly, and finds QEMU in its default install location without manual PATH tweaks.
Linux real‑IP networking
Linux previously relied on shared or host‑only networks that were only reachable on macOS via socket_vmnet. v2.3 adds lima-privileged-net, a small setuid helper that creates a bridge, runs dnsmasq for DHCP/DNS, and configures NAT/forwarding for the lima:shared mode. Because bridge and tap creation need root, Lima now generates a sudoers snippet that grants the current user permission to run the helper. The workflow is:
- Install Lima and
dnsmasqas root. - Generate the sudoers file:
limactl sudoers >etc_sudoers.d_lima - Install it to
/etc/sudoers.d/limawith appropriate permissions. - Start an instance:
limactl start --network=lima:shared --vm-type qemu
When the last VM exits, the helper tears down the bridge and tap devices, limiting the surface area of privileged operations.
Menu‑driven TUI and usability tweaks
A new terminal UI replaces the previous raw command output, giving a searchable list of VMs, status indicators, and quick actions such as shell, copy, and reverse‑sshfs mounts. On Windows, Lima now automatically discovers the built‑in SSH client and correctly translates Windows paths, reducing friction for developers who invoke limactl shell or limactl copy. The installer also checks common QEMU locations (%PROGRAMFILES%\QEMU) without requiring manual PATH edits.
Block‑device support on macOS
v2.3 adds the ability to attach a raw block device (USB drive or external SSD) to VZ‑based macOS guests. Because configuring the device requires root, Lima generates a dedicated sudoers rule for the specific /dev/diskX device. The steps mirror the Linux helper: extract the Homebrew archive to a root‑owned location (e.g., /opt/lima), generate the rule with limactl sudoers --block-device=/dev/disk4, review it, and install it to /etc/sudoers.d/lima. Once in place, a VM can be started with limactl start --vm-type=vz --block-device=/dev/disk4 template:default, exposing the device inside the guest under /dev/disk/by-id/virtio-*.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
For AI, cloud, and security engineers, the native Windows driver eliminates the need to ship QEMU binaries or maintain a Unix‑like toolchain on Windows CI runners. Linux users gain a routable IP address without resorting to port‑forward hacks, simplifying service discovery and network‑policy testing. The TUI reduces the cognitive load of managing multiple local VMs, and the block‑device feature opens a path for high‑throughput data ingestion directly into a VM. Teams should evaluate the HCS driver for Windows‑only pipelines, audit the sudoers rules generated for the Linux helper, and test the new networking mode against existing firewall or security policies before adopting it in production‑like environments.
