Desde el 6 de noviembre de 2026, Lima arranca máquinas virtuales en Windows hablando directamente con Host Compute System, la misma capa de virtualización sobre la que funciona WSL2, sin QEMU ni toolchain Unix. La versión 2.3 también da a las VMs de Linux una IP alcanzable desde el host, algo que hasta ahora solo tenía macOS con socket_vmnet. Y para quien usa Lima como caja de arena de agentes de código, por fin se puede dejar fuera del sandbox el .env.
Lima (Linux Machines) es la CLI que lanza VMs locales y que muchos conocimos como la forma de tener containerd en un Mac. Es proyecto Incubating de la CNCF desde octubre de 2025 y hoy se usa tanto para contenedores como para aislar agentes de IA.
Windows: el driver hcs, nativo pero experimental
Hasta la 2.2, en Windows había dos drivers, wsl2 y qemu. La 2.3 añade hcs, que llama a la API de Host Compute System. Es el cambio más interesante de la versión, pero hoy es una vista previa y su documentación lo dice sin rodeos:
- Solo modo
plain: sin montajes de ficheros y sin redirección dinámica de puertos. - Una única instancia
hcsa la vez, porque la subred de HCN es fija. - Hay que pasar un servidor DNS explícito con
--dns. - Solo se ha probado en Windows 11 x86_64, y
limactldebe ejecutarse desde una consola de administrador. - Arranca desde
.vhdx; si la imagen es.qcow2, Lima la convierte sola.
La preparación son dos pasos: activar la virtualización y añadirte al grupo Hyper-V Administrators.
net localgroup "Hyper-V Administrators" <usuario> /add
limactl start --vm-type hcs --plain --dns 8.8.8.8
limaMientras no haya montajes, hcs sirve para tener una Linux limpia y rápida de levantar, no para editar en el host y compilar en la VM. Para eso, wsl2 sigue siendo la opción práctica. El resto de mejoras de Windows sí son útiles ya: Lima reconoce el cliente SSH de Windows, maneja bien las rutas, encuentra QEMU en su directorio de instalación por defecto sin tocar el PATH, y los invitados Windows de la 2.2 aceptan scripts de provision (system, user, data y dependency).
Linux: redes shared, host y bridged por fin
Las redes gestionadas lima: shared, lima: host y lima: bridged solo funcionaban en macOS. La 2.3 trae lima-privileged-net, un pequeño ayudante con privilegios que crea un bridge por red, levanta dnsmasq para DHCP y DNS, añade las reglas de NAT en modo shared y entrega a cada instancia su propio dispositivo tap. Solo toca interfaces que siguen el esquema de nombres de Lima y borra la red cuando sale la última instancia.
El precio es una configuración inicial con sudoers: Lima tiene que estar instalado como root (el comando se niega a generar reglas para un ayudante que no sea de root) y necesitas dnsmasq.
limactl sudoers >etc_sudoers.d_lima
less etc_sudoers.d_lima
sudo install -o root -m 0440 etc_sudoers.d_lima /etc/sudoers.d/lima
rm etc_sudoers.d_lima
limactl start --network=lima:shared --vm-type=qemuPara quien prueba en local un clúster de varios nodos o un servicio que necesita una IP real, Linux queda por fin a la altura del Mac.
Sandboxes de agentes con menos fugas
Esta es la parte que más uso le veo. limactl shell --sync copia el proyecto a la VM para que un agente trabaje allí y luego pregunta si quieres traer los cambios de vuelta. Hasta ahora copiaba todo: .env, .git y node_modules incluidos. La 2.3 añade --sync-exclude, repetible y con los patrones de --exclude de rsync, o un fichero .limasyncignore en el proyecto:
limactl shell --sync . --sync-exclude .git --sync-exclude node_modules defaultLa segunda fuga que cierra es la red. Por defecto, la VM llega a lo que escucha en el 127.0.0.1 del host a través de host.lima.internal. Con networkOpts.hostLoopback: false esas conexiones se rechazan, así que tu base de datos local queda fuera del alcance del agente. La limitación importante es que solo funciona con el driver VZ, es decir, en macOS. Además, las herramientas MCP de Lima incluyen ahora replace, para que el agente haga ediciones puntuales dentro del invitado en vez de reenviar ficheros enteros.
macOS: discos reales y un cuidado especial con root
Las VMs VZ pueden recibir un disco de bloques (un SSD externo o un USB) con --block-device=/dev/diskN. Una implementación anterior se retiró tras un informe de seguridad, y el rediseño se nota: Lima nunca abre el disco como root, lo hace lima-privileged-block-device, que solo acepta los dispositivos listados en un sudoers que generas, revisas y validas tú. La trampa es que el ayudante y todos sus directorios padre deben ser de root, y las instalaciones típicas de Homebrew son escribibles por el usuario. Para esta función hay que extraer el tarball de la release en /opt/lima y usar ese limactl. Y nunca des acceso al disco de arranque.
Completa la versión limactl menu, una TUI experimental que lista las instancias con su estado, tipo de VM, CPU y memoria, y permite abrir shell, arrancar, parar o borrar con confirmación.
Cómo instalarlo
# macOS y Linux con Homebrew
brew install lima
# Windows, desde PowerShell
winget install Lima.LimaTambién hay paquetes en MacPorts y Nix, y binarios en las releases de GitHub para extraer en /usr/local. Si vas a usar los ayudantes con privilegios (lima-privileged-net o el de discos), instala desde el tarball como root: con Homebrew el comando limactl sudoers no te dejará seguir.
Antes de llevarlo a tu flujo diario
- Comprueba que tus instancias actuales arrancan igual tras actualizar; el
vmTypede una instancia no se puede cambiar, así que para probarhcscrea una nueva. - Si usas
--synccon agentes, añade un.limasyncignorecon.env,.gity los directorios pesados antes de la próxima sesión. - En Linux, lee el fichero que genera
limactl sudoersantes de instalarlo: concede root a un binario concreto, y debe ser de root. - En macOS, activa
networkOpts.hostLoopback: falseen las plantillas que uses como sandbox.
Fuentes
- Lima v2.3: native on Windows, VMnet on Linux, and menu TUI (CNCF, 8 de noviembre de 2026)
- HCS driver (documentación de Lima)
- Installation (documentación de Lima)