WSL vs VirtualBox: cuando WSL es la herramienta equivocada

Dibuja la línea de decisión: lo que realmente eliges

La gente enmarca esto como “WSL vs VirtualBox”. Esa no es la elección real. La elección es:

• Sandbox de conveniencia vs sistema controlable. WSL es una sandbox de conveniencia fuertemente integrada con Windows. VirtualBox te da un límite de sistema controlable.
• Integración con Windows primero vs comportamiento Linux primero. WSL optimiza el ciclo de desarrollo en Windows. VirtualBox optimiza “esto se comporta como Linux en hardware”, porque eso es lo que es.
• Destino compartido vs destino explícito. WSL comparte más destino con el host Windows: rutas de E/S de archivos, intermediarios de red, comportamiento frente a presión de memoria, cadencia de actualizaciones, interferencia de herramientas corporativas. VirtualBox también se ve afectado por el host, pero tu radio de impacto es más fácil de razonar.

Si tu carga requiere control del kernel, redes de bajo nivel, semánticas de almacenamiento predecibles o la capacidad de tratar al invitado como una máquina separada: por defecto elige una VM. Si tu carga es mayormente herramientas de espacio de usuario y te importa la integración con Windows: por defecto elige WSL.

Regla pragmática: si planeas abrir bugs que comiencen con “En Linux esto funciona”, probablemente quieras VirtualBox. Si tu plan es “solo necesito un shell, git y un compilador”, probablemente quieras WSL.

Hechos y contexto histórico (las partes que la gente olvida)

• WSL 1 no era una VM. Tradujo llamadas al sistema de Linux a llamadas de Windows NT. Eso lo hizo ingenioso, rápido en algunos casos y fundamentalmente incompatible en otros.
• WSL 2 cambió a un kernel Linux real. Ese es el gran punto de inflexión: WSL 2 ejecuta un kernel Linux proporcionado por Microsoft en una VM ligera usando componentes de Hyper-V.
• VirtualBox precede a WSL por una década. VirtualBox empezó en Innotek, luego Sun, luego Oracle. Es lo bastante viejo como para haber resuelto problemas aburridos como “arrancar un invitado con dispositivos previsibles”.
• Hyper-V y VirtualBox tienen historia. Durante años compitieron por funciones de virtualización de hardware. VirtualBox moderno puede ejecutarse en hosts con Hyper-V habilitado, pero el rendimiento y las interacciones de características aún pueden ser… picantes.
• El modelo de sistema de archivos de WSL está intencionalmente dividido. Los archivos Linux almacenados dentro del disco virtual de WSL se comportan diferente a los archivos de Windows montados bajo /mnt/c. Esa diferencia no es cosmética; es una línea de rendimiento y corrección.
• Las herramientas de seguridad corporativas cambiaron el juego. Los agentes de protección de endpoints y DLP inspeccionan operaciones de archivos y tráfico de red. Las rutas de integración de WSL pueden amplificar esa sobrecarga en formas que una imagen de disco de VM no hace.
• VirtualBox se convirtió en el sustrato VM por defecto para una generación. Herramientas como Vagrant popularizaron “una VM por proyecto”. Esa expectativa mapea bien a VirtualBox y menos limpiamente a WSL.
• WSL obtuvo soporte para systemd más tarde. Los primeros usuarios de WSL tuvieron que pegar comportamientos de init. WSL moderno puede ejecutar systemd, pero eso no lo convierte mágicamente en “un servidor”.
• Las expectativas de red divergieron. VirtualBox te da modos NIC clásicos (NAT, bridged, host-only). WSL 2 usa una red virtual con NAT y Windows como intermediario, lo que afecta la conectividad entrante y la visibilidad de paquetes.

Diferencias de arquitectura que realmente importan

WSL 2: una VM ligera que no quiere sentirse como tal

WSL 2 ejecuta un kernel Linux dentro de una VM gestionada. Microsoft hizo el trabajo duro para que no tengas que pensar en ajustes de BIOS, controladores de disco y secuencias de arranque. Ese es el atractivo. Pero ese mismo enfoque “gestionado” significa que no obtienes control sobre muchos parámetros que importan cuando diagnosticas rendimiento, redes o comportamiento de almacenamiento.

Las diferencias principales que notarás:

• Límite del sistema de archivos: ext4-en-un-vhdx dentro de Linux vs NTFS de Windows montado en Linux bajo /mnt. Características de rendimiento distintas; comportamiento distinto de watchers de archivos; semánticas de metadata diferentes bajo carga.
• Límite de red: WSL 2 está detrás de NAT por defecto, con Windows haciendo enrutamiento y reenvío de puertos. Las conexiones entrantes, multicast y las expectativas de “solo enlazar a 0.0.0.0” pueden volverse extrañas.
• Gobernanza de recursos: La VM de WSL crece la memoria bajo demanda y no siempre se reduce cuando crees que debería a menos que la ajustes. Es conveniente hasta que deja de serlo.
• Expectativas de kernel/módulos: Ejecutas el kernel de Microsoft. No puedes cargar módulos de kernel arbitrarios como lo harías en una instalación normal de distro.

VirtualBox: una VM convencional con compensaciones convencionales

VirtualBox es “un ordenador en una ventana”. Obtienes hardware virtual explícito y un comportamiento de invitado más predecible. También obtienes sobrecarga, limitaciones de emulación de dispositivos y las tareas diarias del ciclo de vida de una VM: actualizaciones, snapshots, dimensionado de discos y modos de red.

Pero cuando algo se rompe, VirtualBox es el tipo de fallo que puedes razonar: modo NIC mal configurado, E/S de disco limitada, interfaz host-only no creada, guest additions faltantes. Estos son fallos aburridos. Los fallos aburridos son sobrevivibles.

Una idea para tener en una nota adhesiva, parafraseada y atribuida a Werner Vogels: Todo falla; construye sistemas que asuman fallos y se recuperen rápidamente. (idea parafraseada)

Primera broma, porque vamos a hablar de redes: NAT es como la conversación trivial de oficina—bien para salidas, incómodo cuando alguien intenta iniciar una conversación real.

Cuando WSL es la herramienta adecuada

WSL brilla cuando tu objetivo es ser productivo en Windows sin mantener una VM completa. Es una plataforma para desarrolladores, no un mini centro de datos.

Usa WSL cuando quieras iteración rápida e integración estrecha con Windows

• Herramientas CLI: git, ssh, curl, runtimes de lenguajes, gestores de paquetes, sistemas de build.
• Flujos de trabajo basados en texto: editores, linters, compiladores, pruebas unitarias, scripts locales.
• Contenedores (a menudo): Docker Desktop usa WSL 2 como backend para contenedores Linux; para muchos flujos de trabajo de desarrollo es la vía más sencilla.
• Desarrollo multiplataforma: Puedes compilar artefactos para Linux desde Windows sin hacer dual-boot.
• Servicios locales de bajo riesgo: Ejecutar una base de datos de desarrollo o una caché está bien, siempre que no lo trates como una línea base de producción.

Características “buenas raras” de WSL

• Acceso coherente a Windows: Puedes llamar a ejecutables de Windows desde WSL y viceversa. Eso no es “como Linux”, pero es extremadamente útil.
• Instalación sin fricción: Puedes aprovisionar una distro en minutos sin un ISO o un gestor de VMs.
• Carga operativa menor: No hay un ciclo de vida de un guest OS que vigilar de la misma manera que una VM completa; menos piezas móviles que parchear manualmente.

WSL es un gran valor por defecto para desarrollo local siempre que mantengas tus archivos de proyecto dentro del sistema de archivos de WSL (no en /mnt/c) y aceptes que algunas suposiciones de “Linux real” no se cumplirán.

Cuando WSL es la herramienta equivocada (y VirtualBox gana)

Si necesitas “una máquina”, no “un shell”, WSL empieza a mostrar costuras. Aquí están los casos que cambian la decisión.

1) Necesitas comportamiento a nivel de kernel, módulos u observabilidad de bajo nivel

Si trabajas con eBPF, desarrollo de módulos del kernel, flujos personalizados de iptables/nftables que esperan control completo o cualquier cosa que necesite una configuración específica del kernel: usa una VM real. El kernel de WSL es real, pero no es el tuyo. No obtienes paridad total con el kernel de una distro y no puedes asumir que puedes cargar lo que quieras.

2) Necesitas conectividad entrante predecible, comportamiento L2 o semánticas de “host real”

El modo bridged de VirtualBox da al invitado una dirección en tu LAN. Sigue virtualizado, pero se alinea con “esto es otra máquina”. El modelo NAT de WSL 2 está bien para conexiones salientes y desarrollo en localhost. Es menos adecuado cuando necesitas acceso entrante desde otros dispositivos, descubrimiento multicast, entornos de laboratorio o capturas de paquetes que deben ver la verdad.

3) Necesitas probar arranque, init o comportamientos del ciclo de vida del sistema operativo completo

¿Probar unidades de systemd, orden de arranque, cloud-init, cifrado de disco en el arranque o cambios en la línea de comandos del kernel? Usa VirtualBox. WSL ha mejorado (incluyendo soporte para systemd), pero el ciclo de vida sigue siendo “instancia WSL como entorno gestionado”, no “un servidor que puedes tratar como ganado”.

4) Tu carga es sensible al almacenamiento o a la corrección

WSL es rápido cuando operas sobre archivos dentro de su sistema de archivos Linux. Puede ser dolorosamente lento cuando ejecutas fuerte churn de archivos en rutas montadas de Windows. El camino lento no es un bug; es un límite. Si tu carga requiere checkouts grandes, árboles masivos de node_modules o bases de datos que necesiten semánticas predecibles de fsync, debes planificar alrededor de ese límite o pasarte a una VM.

5) Necesitas passthrough USB o acceso a hardware

VirtualBox tiene soporte maduro para passthrough USB (con extension pack) y una historia bastante clásica para adjuntar dispositivos a un invitado. WSL tiene algunas opciones para escenarios USB/IP, pero no es lo mismo. Si estás flasheando dispositivos, usando dongles, adaptadores seriales o trabajando en embebidos: VirtualBox suele ser la respuesta limpia.

6) Necesitas fuerte aislamiento frente a herramientas de endpoint corporativas

Aquí hay una verdad incómoda: las herramientas de seguridad a menudo tratan a WSL como “solo más acceso a archivos de Windows”. Eso puede significar escaneo extra cuando construyes o descomprimes muchos archivos pequeños en /mnt/c. Una imagen de disco VirtualBox puede estar más aislada porque el host ve en su mayoría lecturas/escrituras secuenciales grandes a un único archivo, no una tormenta de operaciones de archivo.

7) Necesitas reproducibilidad estable para un equipo

WSL es lo bastante reproducible para muchos equipos de desarrollo, pero sigue ligado a versiones de Windows, versiones de WSL y a veces a comportamientos sutiles de integración. Las VMs de VirtualBox pueden fijarse más explícitamente: un ISO conocido, versión conocida de guest additions, hardware virtual conocido, modo de red conocido. Eso importa cuando “funciona en mi máquina” cuesta dinero real.

Segunda broma, porque el almacenamiento siempre merece una: “Funcionó hasta que pusimos el repo en /mnt/c” es la versión moderna de “funcionó en mi portátil”, solo que con más syscalls.

Tareas prácticas: comandos, salidas y decisiones

No eliges herramientas por sensaciones. Las eliges midiendo el cuello de botella y comprobando las suposiciones que normalmente te traicionan: ruta del sistema de archivos, modo de red, presión de memoria y límites host/invitado. Abajo hay comandos prácticos ejecutables con salidas de ejemplo y qué deberías decidir a partir de ellos.

Task 1: Confirmar versión de WSL y estado de la distro

cr0x@server:~$ wsl.exe --list --verbose
  NAME              STATE           VERSION
* Ubuntu-22.04      Running         2
  Debian            Stopped         2

Qué significa: Estás en WSL 2 (kernel en VM). Si esperabas semánticas de WSL 1 (traducción de syscalls), detente. Tu camino de troubleshooting difiere.

Decisión: Si tu problema es relacionado con kernel/módulos/pila de red, trata WSL como una VM gestionada con restricciones. No asumas que puedes “simplemente ajustar el kernel”.

Task 2: Identificar dónde viven tus archivos de proyecto (ext4 de WSL vs montaje de Windows)

cr0x@server:~$ pwd
/mnt/c/Users/alex/work/myapp

Qué significa: Estás compilando sobre el sistema de archivos de Windows vía DrvFs. Para churn intenso de archivos, este es el carril lento.

Decisión: Si builds/pruebas son lentos, mueve el repo al sistema de archivos de WSL (por ejemplo, /home/alex) antes de culpar a compiladores, Node o “WSL lento”.

Task 3: Medir tipo de sistema de archivos y opciones de montaje dentro de WSL

cr0x@server:~$ mount | head -n 6
none on / type lxfs (rw,noatime)
none on /mnt/wsl type tmpfs (rw,nosuid,nodev,noexec,relatime)
C:\ on /mnt/c type 9p (rw,noatime,aname=drvfs;path=C:\;uid=1000;gid=1000;metadata;case=off)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=1632048k,mode=755)

Qué significa: La unidad de Windows está montada vía un mecanismo basado en 9p. Ese es el límite que puede aplastar cargas de archivos pequeños.

Decisión: Si tu carga es sensible a operaciones de metadata (git status, npm install, yarn, pip, composer), manténla fuera de /mnt/c.

Task 4: Prueba rápida de estrés de archivos pequeños (diagnosticar el límite)

cr0x@server:~$ time bash -lc 'rm -rf /tmp/iotest && mkdir -p /tmp/iotest && for i in $(seq 1 20000); do echo $i > /tmp/iotest/f$i; done'

real    0m2.941s
user    0m0.715s
sys     0m2.147s

Qué significa: Esta es tu línea base dentro del sistema de archivos Linux.

Decisión: Ejecuta la misma prueba bajo /mnt/c. Si es dramáticamente más lenta, tu “problema de rendimiento WSL” es en realidad un problema de ruta.

Task 5: Repetir la prueba de estrés en /mnt/c y comparar

cr0x@server:~$ time bash -lc 'rm -rf /mnt/c/Temp/iotest && mkdir -p /mnt/c/Temp/iotest && for i in $(seq 1 20000); do echo $i > /mnt/c/Temp/iotest/f$i; done'

real    0m38.772s
user    0m2.105s
sys     0m15.883s

Qué significa: Estás pagando sobrecarga por cruce de límite por archivo. Multiplícalo por gestores de paquetes y se pone feo.

Decisión: Mueve las cargas al ext4 de WSL o usa una VM con un sistema de archivos Linux nativo para esa carga. No “optimices” flags del compilador para arreglar un límite de sistema de archivos.

Task 6: Comprobar presión de memoria y si WSL acapara RAM

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       6.1Gi       431Mi       152Mi       1.2Gi       1.1Gi
Swap:          2.0Gi       1.4Gi       612Mi

Qué significa: La VM de WSL está bajo presión y swap. Eso a menudo se siente como “todo va lento”, incluyendo I/O y red.

Decisión: Si necesitas cargas sostenidas de mucha memoria, considera ajustar límites de recursos de WSL o mover la carga a una VM con asignación explícita de RAM. El swap en dev es el sonido de tu tarde siendo robada.

Task 7: Verificar expectativas de kernel y características (systemd, módulos)

cr0x@server:~$ uname -a
Linux cr0x 5.15.133.1-microsoft-standard-WSL2 #1 SMP Wed Oct 11 19:10:13 UTC 2023 x86_64 GNU/Linux

Qué significa: Estás ejecutando la variante de kernel de WSL. Es legítima, pero no es el build exacto del kernel de tu distro.

Decisión: Si requieres una versión/configuración específica del kernel (p. ej., para eBPF, comportamiento de LSM o disponibilidad de módulos), no arriesgues. Usa VirtualBox con un kernel de distro que controles.

Task 8: Diagnosticar alcanzabilidad entrante (chequeo de la realidad NAT de WSL)

cr0x@server:~$ ip addr show eth0 | sed -n '1,8p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:3a:7c:11 brd ff:ff:ff:ff:ff:ff
    inet 172.28.96.15/20 brd 172.28.111.255 scope global eth0
       valid_lft forever preferred_lft forever

Qué significa: Tu instancia WSL está en una red NAT privada (172.28.x.x). Otros dispositivos de la LAN no la alcanzarán directamente.

Decisión: Si necesitas que otras máquinas se conecten a servicios dentro de Linux sin gimnasia de proxy de puertos, prefiere VirtualBox con bridged networking.

Task 9: Ver qué piensa Windows sobre el modo de red de tu VM VirtualBox (pista desde invitado)

cr0x@server:~$ ip route
default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15

Qué significa: Ese 10.0.2.2 gateway es el NAT clásico de VirtualBox.

Decisión: Si necesitas acceso entrante desde tu LAN, NAT es el modo equivocado. Cambia a bridged o host-only + enrutamiento explícito dependiendo de tus necesidades.

Task 10: Validar networking bridged en un invitado VirtualBox

cr0x@server:~$ ip addr show enp0s3 | sed -n '1,8p'
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.77/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s3
       valid_lft 7200sec preferred_lft 7200sec

Qué significa: La VM está en la misma LAN que tu host. Otros dispositivos pueden alcanzarla y el descubrimiento de servicios se comporta normalmente.

Decisión: Para labs, pruebas multinodo o servicios entrantes, esta suele ser la configuración más limpia.

Task 11: Revisar uso de disco y la sorpresa de “vhdx de WSL nunca se encoge”

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc       1007G   96G  861G  11% /

Qué significa: Dentro de WSL puedes tener mucho espacio libre. En Windows, el vhdx subyacente puede seguir siendo enorme después de borrados.

Decisión: Si el disco de Windows se está llenando, debes recuperar espacio a nivel del disco virtual (export/import o compact). Si necesitas comportamiento predecible de crecimiento de disco, una VM con gestión explícita de disco virtual puede ser más fácil de operar.

Task 12: Confirmar si systemd es realmente PID 1 en WSL

cr0x@server:~$ ps -p 1 -o comm=
systemd

Qué significa: systemd está ejecutándose como init. Si fuera init u otra cosa, tus expectativas de gestión de servicios pueden ser incorrectas.

Decisión: Si tu stack depende de unidades y timers de systemd comportándose como en un servidor, asegúrate de que systemd esté habilitado; de lo contrario usa una VM y deja de negociar con init.

Task 13: Verificar que puedes enlazar y alcanzar un servicio desde el host Windows (integración localhost de WSL)

cr0x@server:~$ python3 -m http.server 8080
Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ...

Qué significa: El servicio está escuchando. Normalmente Windows puede alcanzarlo vía localhost:8080 gracias a la integración de WSL.

Decisión: Si Windows puede alcanzarlo pero otros dispositivos de la LAN no, eso es NAT de WSL por diseño. Decide si necesitas alcance LAN; si es así, considera una VM en bridged.

Task 14: Diagnosticar problemas de DNS (WSL vs VM se comportan distinto bajo VPNs)

cr0x@server:~$ resolvectl status | sed -n '1,18p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 172.28.96.1
       DNS Servers: 172.28.96.1

Qué significa: El DNS está mediado. Bajo algunos clientes VPN corporativos, esto puede romper expectativas de split-DNS o causar fallos intermitentes de resolución.

Decisión: Si el DNS es inestable y necesitas redeterminismo para un laboratorio o comportamiento tipo CI, una VM con su propia NIC en modo bridged a menudo evita las rarezas.

Guía rápida de diagnóstico

Cuando alguien dice “WSL va lento” o “la red de VirtualBox está rota”, tienes unos cinco minutos para evitar un día de superstición. Aquí hay un orden de operaciones ajustado que encuentra el cuello de botella rápidamente.

Primero: identifica el límite que estás cruzando

• ¿Dónde están los archivos? Si el proyecto está bajo /mnt/c, asume sobrecarga del límite de sistema de archivos primero.
• ¿Dónde está la red? Si la IP del invitado está en espacio NAT privado, asume problemas de alcanzabilidad entrante primero.
• ¿Dónde está la CPU? Si el host está bajo carga o la VM está hambrienta, asume planificación y presión de memoria.

Segundo: ejecuta las tres comprobaciones “suero de la verdad”

1. Chequeo de sistema de archivos: Ejecuta la prueba de archivos pequeños en ambas ubicaciones. Gran delta = problema de límite, no “tu app”.
2. Chequeo de memoria: Busca swap y poca memoria disponible. Swap = todo miente.
3. Chequeo de red: Confirma tipo de IP y ruta. NAT vs bridged te dice lo que es posible sin hacks.

Tercero: decide si estás depurando la app o la plataforma

• Si la falla es causada por supuestos de kernel/módulo, visibilidad de paquetes, red entrante o semánticas de almacenamiento: muévete a VirtualBox (u otro hipervisor completo).
• Si el problema es la ubicación de archivos, ajuste de recursos o un ajuste de integración faltante: arregla WSL y mantén el bucle de desarrollo ágil.

Mapa rápido de cuellos de botella

• Compilaciones/pruebas lentas: usualmente ruta de sistema de archivos o sobrecarga de escaneo de endpoints.
• No se alcanza el servicio desde otra máquina: WSL NAT; VirtualBox NAT; modo equivocado.
• VPN + rarezas de DNS: DNS mediado; decide si necesitas una NIC real.
• Dériva de reloj/tiempo: problemas de sincronización del host (más comunes en VMs que en WSL).
• “Funciona en Linux, no aquí”: desajuste de kernel/módulo/privilegios; elige una VM.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: npm/yarn/pip installs son glaciares en WSL

Causa raíz: El repo vive en /mnt/c y la carga crea muchísimas operaciones de archivos pequeños cruzando la frontera Windows↔Linux.

Solución: Mueve el repo a /home/<user> dentro de WSL. Si debes mantener fuentes en Windows, considera una VM con carpetas compartidas solo para ediciones ligeras, no para árboles de dependencias.

2) Síntoma: un servicio se enlaza a 0.0.0.0 pero otros dispositivos de la LAN no pueden alcanzarlo (WSL)

Causa raíz: WSL 2 está detrás de NAT. Windows a menudo puede alcanzarlo vía integración localhost; tu LAN no.

Solución: Usa port proxying/reenvío si es aceptable, o mueve el servicio a una VM en bridged para presencia real en la LAN.

3) Síntoma: la captura de paquetes no muestra el tráfico esperado

Causa raíz: La ruta de red virtual de WSL y la mediación de Windows ocultan/transforman lo que crees que estás capturando; quizá estás capturando la capa de interfaz equivocada.

Solución: Usa una VM con bridged networking y captura en la NIC del invitado, o captura en el host Windows en la interfaz correcta. Si necesitas verdad a nivel L2, prefiere una VM.

4) Síntoma: el espacio en disco en Windows desaparece tras “borrar muchas cosas” en WSL

Causa raíz: El disco virtual de WSL crece pero no se encoge automáticamente; los borrados dentro de ext4 no compactan inmediatamente el VHDX.

Solución: Recupera espacio compactando/exportando-importando la distro. Si esto ocurre repetidamente, pon expectativas claras: WSL no es un gestor de almacenamiento thin-provisioned que puedes ignorar.

5) Síntoma: “Hyper-V está habilitado así que VirtualBox va lento/raro”

Causa raíz: VirtualBox puede ejecutarse sobre APIs de Hyper-V dependiendo de la configuración del host. El rendimiento y comportamiento de timing pueden cambiar, y algunas funciones pueden verse afectadas.

Solución: Decide qué hipervisor es el primario. Si debes mantener funciones de Hyper-V, prueba el rendimiento de VirtualBox en tus cargas base. Si necesitas máximo rendimiento de VM, considera ejecutarlo sin capas de hipervisor en competición.

6) Síntoma: los servicios del sistema no arrancan de forma fiable en WSL

Causa raíz: systemd no está habilitado o el ciclo de vida no es equivalente a una máquina completamente arrancada; servicios en background pueden depender del comportamiento de init.

Solución: Habilita systemd para la distro si procede y verifica PID 1. Si el ciclo de vida del servicio es central para tus pruebas, deja de pelear y usa una VM.

7) Síntoma: los watchers de archivos no detectan cambios o disparan tormentas

Causa raíz: Las semánticas de watchers atraviesan sistemas de archivos difieren; el comportamiento de inotify en rutas montadas de Windows no es equivalente al de FS nativo de Linux.

Solución: Mantén los árboles observados dentro del sistema de archivos de WSL. Para monorepos grandes con mucho uso de watch, una VM puede comportarse más predeciblemente.

8) Síntoma: “Mi base de datos es más lenta en WSL de lo esperado”

Causa raíz: Archivos de base de datos colocados en /mnt/c, o presión de memoria del host causando swap, o antivirus inspeccionando el conjunto de trabajo.

Solución: Pon el directorio de datos dentro de ext4 de WSL, asigna más memoria, excluye rutas apropiadas del escaneo según la política corporativa, o mueve cargas de BD a una VM.

Tres micro-relatos corporativos desde las trincheras

Micro-relato 1: El incidente causado por una suposición equivocada

Una empresa SaaS de tamaño medio (llamémosla “Northbridge”) estandarizó el desarrollo local en portátiles Windows. El equipo de plataforma respaldó WSL 2 como defecto y siguió adelante. Fue una buena decisión para el día a día de codificación.

Luego un equipo que construía un agente con mucha red empezó a probar comportamiento “realista” dentro de WSL. Su agente escuchaba conexiones entrantes desde otras máquinas en la LAN corporativa. Los desarrolladores reportaron conectividad intermitente: a veces funcionaba desde el host Windows, a veces no desde un segundo portátil. Culparon reglas de firewall, luego al agente, luego a los switches del lab de QA, porque eso es lo que hacen los humanos bajo presión de tiempo.

La suposición equivocada: “Enlazar a 0.0.0.0 dentro de WSL es equivalente a enlazar en una NIC del host.” No lo es. WSL 2 vive detrás de NAT, y Windows hace un enrutamiento clever a localhost que hace que las cosas parezcan bien desde la misma máquina. Desde la LAN, es otra historia.

El “incidente” no fue una caída; fue peor: un período de confianza falsa. Mergeron un cambio que parecía correcto probándolo en WSL pero fallaba en un entorno de staging con hosts Linux reales. Dos días de debugging después, la causa raíz fue simplemente que su plataforma de prueba nunca coincidió con su topología de despliegue.

La solución fue aburrida e inmediata: movieron las pruebas de integración de red a VMs VirtualBox con bridged networking. WSL siguió para codificación. El equipo dejó de intentar hacer que WSL se comportara como un host enrutable. La productividad subió y bajó el conteo de discusiones.

Micro-relato 2: La optimización que salió mal

Otra empresa (“Red Quarry”) gestionaba un monorepo grande con una cadena de herramientas Node pesada. Alguien decidió “optimizar” manteniendo el repo en el sistema de archivos de Windows para que las herramientas nativas de Windows lo indexaran y las copias de seguridad fueran más simples. El repo se montó en WSL bajo /mnt/c. A todos se les dijo que era la forma moderna e integrada.

Al principio estuvo bien. Luego aumentó el número de dependencias. Los pasos de build empezaron a crear y borrar cientos de miles de archivos pequeños. Los desarrolladores empezaron en secreto a ejecutar builds durante la noche. Eso no es un flujo de trabajo; es rendirse.

La optimización fracasó porque atacó el cuello de botella equivocado. El equipo optimizó para “copia única de archivos” y “conveniencia de herramientas Windows”, pero lo pagó con sobrecarga por archivo y amplificación del escaneo por endpoint. Cada creación de archivo se convertía en una operación cruzada de límite más inspección de seguridad. La máquina estaba haciendo trabajo; simplemente no el trabajo que alguien pidió.

Al final, el SRE del equipo ejecutó una pequeña prueba de estrés: crear 20k archivos en /tmp vs /mnt/c. La ratio fue humillante. Movieron los repos por defecto al sistema de archivos de WSL y usaron integraciones de editor para acceder a ellos. La indexación se reconfiguró para apuntar a rutas del lado Linux cuando fue posible.

El resultado: los tiempos de build cayeron drásticamente sin tocar una sola flag de compilador. La “optimización” que necesitaban no fue código más rápido—fueron menos cruces de frontera.

Micro-relato 3: La práctica aburrida pero correcta que salvó el día

Una fintech (“Halcyon Ledger”) tenía necesidades estrictas de reproducibilidad. Sus ingenieros usaban hosts Windows, pero su pipeline de release dependía de empaquetado Linux y comportamiento cercano al kernel. También tenían auditores que no se preocupaban por tus sentimientos sobre la elección de herramientas.

El equipo de plataforma tomó una decisión poco sexy: cada proyecto se entregaba con una definición de VM VirtualBox fijada, una versión de distro conocida y una documentación del modo de red. Los desarrolladores podían seguir usando WSL para editar y scripts rápidos, pero cualquier cosa que importara—empaquetado, pruebas de integración, comportamiento de red—corría en la VM.

Esto pareció “trabajo extra” hasta que una actualización de Windows cambió algo en el comportamiento de red de WSL para un subconjunto de portátiles. Los desarrolladores perdieron medio día persiguiendo rarezas de DNS y reenvío de puertos. El pipeline de release no pestañeó porque no corría sobre la interpretación del desarrollador de WSL esa semana. Corría en la caja VM aburrida que se comportaba igual que ayer.

El ahorro vino de la predictibilidad, no del rendimiento. Las imágenes VM se trataron como artefactos: versionadas, probadas y ocasionalmente rotadas. Nadie lo presumió. Ahí sabes que funcionó.

Listas de verificación / plan paso a paso

Checklist A: Decidir WSL o VirtualBox para un proyecto nuevo

1. ¿Necesitas conexiones entrantes desde otras máquinas? Si sí, prefiere VirtualBox con bridged networking.
2. ¿Necesitas módulos del kernel, eBPF o red de bajo nivel? Si sí, prefiere VirtualBox.
3. ¿La carga es intensiva en archivos pequeños? Si sí, WSL está bien solo si el proyecto vive dentro de ext4 de WSL.
4. ¿Necesitas dispositivos USB o adaptadores seriales? Si sí, prefiere passthrough USB de VirtualBox.
5. ¿La reproducibilidad en equipo es crítica? Si sí, prefiere una baseline de VM (VirtualBox) y trátala como artefacto.
6. ¿Es esto mayormente herramientas CLI y builds locales? Si sí, WSL suele ser la mejor experiencia.

Checklist B: Hacer que WSL se comporte (la configuración “no luchar contra la física”)

1. Mantén código y árboles de dependencias en /home, no en /mnt/c.
2. Usa editores de Windows que puedan abrir rutas WSL sin mover archivos a NTFS.
3. Verifica systemd si dependes de él: checa PID 1 y estado de servicios.
4. Vigila la memoria: si estás en swap, ajusta límites de recursos o cambia de plataforma.
5. Sé explícito sobre expectativas de red: desarrollo en localhost está bien; alcanzabilidad LAN no es una característica por defecto.

Checklist C: Hacer VirtualBox aburrido y fiable

1. Elige un modo de red que coincida con la realidad:
   • NAT para desarrollo solo con salida.
   • Bridged para “esta VM es un host real en la LAN”.
   • Host-only para labs aislados con enrutamiento explícito.
2. Asigna recursos explícitamente: RAM y número de CPU. No confíes en crecimiento dinámico.
3. Usa snapshots con moderación e intención (antes de cambios riesgosos), no como estilo de vida.
4. Decide cómo compartes archivos. Las carpetas compartidas son cómodas pero pueden ser más lentas y menos tipo Linux que un sistema de archivos nativo.
5. Versiona tu baseline de VM para equipos. Si importa, fíjala.

Paso a paso: Migrar un proyecto de WSL-on-/mnt/c a WSL ext4

1. Crea un directorio de trabajo dentro de WSL: mkdir -p ~/work.
2. Clona el repo dentro de WSL: git clone ... ~/work/myapp.
3. Reinstala dependencias dentro de WSL (no reutilices a ciegas una cache del lado Windows).
4. Actualiza la configuración del editor para abrir la ruta WSL.
5. Vuelve a ejecutar la prueba de estrés y tu build. Si la diferencia no es obvia, tu cuello de botella no es el sistema de archivos.

Paso a paso: Migrar “necesita red de host real” de WSL a VirtualBox

1. Crea una VM con la distro que despliegas (coincide la versión mayor).
2. Configura la red en Bridged Adapter.
3. Instala tu stack y enlaza servicios a la NIC del invitado.
4. Valida la alcanzabilidad desde otro dispositivo de la LAN.
5. Documenta la configuración de la VM (modo NIC, expectativas de puertos, reglas de firewall) en el repo para que la próxima persona no lo redescubra por sufrimiento.

Preguntas frecuentes

1) ¿WSL 2 es “una VM real”?

Usa un kernel Linux real en un entorno tipo VM. Pero está gestionado e integrado de formas que lo hacen comportarse distinto a una VM autogestionada que controlas de extremo a extremo.

2) Si WSL 2 usa un kernel real, ¿por qué la gente aún dice que no es Linux real?

Porque “Linux real” suele implicar control sobre kernel, módulos, ciclo de arranque y comportamiento predecible de dispositivos/red. WSL es userland Linux real sobre un kernel gestionado con restricciones de integración.

3) ¿Cuál es el único mayor error de rendimiento en WSL?

Poner tu proyecto (y especialmente directorios de dependencias) en /mnt/c y luego ejecutar herramientas Linux que crean o stattean miles de archivos.

4) ¿Cuándo es mala idea VirtualBox?

Cuando necesitas el ciclo de integración estrecho con Windows y no necesitas semánticas de máquina completa. También cuando la configuración de hosts de tu organización hace que VirtualBox sea lento por capas de virtualización en competición—prueba en tu hardware base antes de estandarizar.

5) ¿Puede WSL reemplazar a VirtualBox para laboratorios de Kubernetes?

A veces. Clústeres de nodo único de desarrollo pueden funcionar bien. Si necesitas realismo multinodo, ingreso desde otras máquinas o comportamientos CNI que asumen nodos enrutable, un laboratorio con VMs suele ser menos sorprendente.

6) ¿Por qué el acceso a localhost funciona desde Windows a WSL, pero el acceso LAN no?

Porque Windows y WSL cooperan para reenviar algunos puertos a localhost. Eso no es lo mismo que que el invitado WSL tenga una dirección enrutable en la LAN.

7) ¿Necesito systemd en WSL?

Si tus herramientas esperan unidades systemd, timers, comportamiento de journal o dependencias de servicio, sí. Si solo ejecutas shells y procesos únicos, no. Si intentas probar el ciclo de arranque de un servidor, usa una VM de todos modos.

8) ¿Y los dispositivos USB y puertos seriales?

VirtualBox tiene una historia directa para passthrough USB (con los componentes adecuados). WSL puede manejar algunos escenarios de dispositivo, pero si el acceso hardware es central, una VM suele ser el camino con menos arrepentimiento.

9) ¿Puedo hacer que WSL se comporte como bridged networking?

Puedes aproximarlo con reenvío de puertos y configuración de red en Windows, pero no es el modelo por defecto. Si bridged es un requisito, elige una VM donde bridged sea un control de primera clase.

10) ¿Deberían los equipos estandarizar en una sola herramienta?

Estandariza en resultados. Para codificación, WSL a menudo es la mejor experiencia en Windows. Para pruebas de integración y reproducibilidad, una baseline de VM fijada suele ser la opción más calmada.

Próximos pasos que puedes hacer hoy

• Audita dónde viven tus repos. Si están en /mnt/c y te quejas del rendimiento, mueve un repo a /home y vuelve a medir.
• Decide tu requisito de red. Si otras máquinas deben conectar entrante, deja de fingir que NAT está bien. Usa VirtualBox en modo bridged para esa carga.
• Ejecuta las pruebas de estrés y guarda los resultados. Tener un número de referencia convierte debates en ingeniería.
• Separa “shell de dev” de “entorno de integración”. WSL para iteración diaria; VirtualBox para realismo y reproducibilidad cuando importe.
• Escribe las reglas de límite. Una guía interna de dos páginas vence veinte hilos de Slack y un onboarding basado en folklore.

Elige WSL cuando quieras rapidez de configuración y un gran ciclo de desarrollo en Windows. Elige VirtualBox cuando necesites una máquina que puedas razonar—red, almacenamiento, comportamiento del kernel, y todo. Usa ambos cuando vayas en serio: WSL para comodidad, una VM para la verdad.