Máquina virtual Windows en Proxmox sin red: soluciones efectivas para el controlador NIC VirtIO

Guion de diagnóstico rápido

Si solo tienes 10 minutos y un gerente encima, haz esto en orden. El objetivo es encontrar el primer salto roto: Windows ↔ controlador VirtIO ↔ tap de QEMU ↔ bridge de Proxmox ↔ NIC física ↔ red/DHCP ascendente.

1) Demuestra si la VM está emitiendo tráfico en absoluto

• En el host Proxmox, identifica la interfaz tap de la VM y captura ARP/DHCP.
• Si no hay tráfico, el problema está dentro del invitado (controlador, adaptador deshabilitado, pila IP, desajuste de etiqueta VLAN en la configuración de la VM).
• Si hay tráfico pero no hay respuestas, está fuera del invitado (bridge, firewall, VLAN, switch ascendente, DHCP).

2) Valida el cableado del bridge en Proxmox

• ¿La NIC de la VM está conectada al bridge previsto (normalmente vmbr0)?
• ¿vmbr0 está realmente conectado a la NIC física o bond que piensas?
• ¿El firewall de Proxmox está silenciosamente bloqueando el tráfico saliente o DHCP?

3) Valida el adaptador y el controlador en Windows

• ¿Windows ve un dispositivo NIC en absoluto?
• Si lo ve, ¿el controlador está cargado y firmado? (VirtIO NetKVM)
• ¿ipconfig /all muestra un intento de DHCP o solo APIPA (169.254.x.x)?

4) Solo entonces persigue causas “avanzadas”

• Etiquetado VLAN y configuración de trunk.
• Desajuste de MTU / tramas jumbo con soporte parcial en la ruta.
• Multi-queue / offloads interactuando mal con determinados conmutadores virtuales o cadenas de firewall.
• Perfil de red de Windows y reglas de firewall (menos comunes de lo que la gente piensa, pero reales).

Modelo mental: dónde mueren los paquetes

Las fallas de red son más fáciles cuando las tratas como latencia de almacenamiento: mapeas la canalización y luego mides cada etapa. Una VM Windows en Proxmox suele verse así:

1. Pila de red de Windows (IP/DHCP/ARP) comunicándose con…
2. Dispositivo NIC VirtIO (virtio-net en QEMU), usando…
3. Controlador NetKVM (controlador virtio-net para Windows), que alimenta paquetes a…
4. Interfaz tap de QEMU (p. ej., tap100i0) en el host, conectada a…
5. Bridge de Linux (vmbr0) posiblemente con filtrado VLAN, luego…
6. NIC física/bond (p. ej., eno1, bond0) hacia…
7. Puerto del switch con política de trunk/access, luego…
8. Upstream gateway, DHCP y los dispositivos de seguridad que quieran intervenir.

Tu trabajo es decidir qué capa está mintiendo. Y siempre hay algo que miente.

Una cita que se queda pegada en muchas mentes de operaciones: No confiar es una estrategia. — idea parafraseada comúnmente atribuida en círculos de operaciones/confiabilidad.

Datos interesantes y contexto histórico (para que lo raro tenga sentido)

• VirtIO se creó para evitar la sobrecarga de la emulación. Las NIC emuladas como Intel E1000 son cómodas, pero consumen CPU porque el hipervisor finge ser hardware de otra era.
• El mito de “E1000 funciona en todas partes” es caro. A menudo “simplemente funciona” en Windows sin controladores adicionales, pero a alto rendimiento puede convertirse en tu cuello de botella antes de que lo notes.
• Windows no incluía controladores VirtIO por defecto. A diferencia de muchas distribuciones Linux, Windows normalmente necesita el ISO de VirtIO (o controladores inyectados) para almacenamiento y red.
• El nombre del controlador VirtIO importa. El controlador de Windows suele llamarse NetKVM; mezclar versiones puede causar fallos extraños tras actualizaciones de Windows que endurecen las políticas de controladores.
• QEMU/Proxmox puede presentar múltiples modelos de NIC. VirtIO (paravirtualizada), E1000, RTL8139 (ancestral) y más. Elegir el incorrecto es una decisión de rendimiento y soporte.
• El bridging en Linux no es magia. Un bridge Linux es un switch por software. Si adjuntas mal un puerto (tap) o configuras mal el filtrado VLAN, tus paquetes no van a ninguna parte con un silencio impresionante.
• El firewall de Proxmox es con estado y por capas. Hay niveles de Datacenter, Nodo y VM. Una regla permisiva en una capa no ayuda si otra capa descarta primero.
• APIPA (169.254/16) es la “insignia de lo intenté” de Windows. Significa que DHCP falló. No significa que la NIC esté bien; significa que Windows agotó el tiempo esperando una concesión.
• UEFI/Secure Boot cambia la aceptación de controladores. Algunas configuraciones de Windows con Secure Boot habilitado pueden rechazar controladores no firmados o mal firmados, incluyendo compilaciones antiguas de VirtIO.

Primero, nombra el síntoma con precisión

“Sin red” es una queja, no un diagnóstico. Elige el síntoma más cercano; determina la ruta más rápida.

Síntoma A: Windows no muestra ningún adaptador Ethernet

Normalmente: modelo de NIC equivocado, falta de controlador VirtIO, dispositivo deshabilitado o Windows ocultándolo por dispositivos fantasma.

Síntoma B: El adaptador existe, pero tiene 169.254.x.x (APIPA)

Normalmente: DHCP no llega a la VM, las respuestas DHCP no llegan a Windows, o la NIC está atascada en un estado extraño por offloads/controlador.

Síntoma C: Tiene IP, pero no puede hacer ping al gateway

Normalmente: desajuste de VLAN, bridge erróneo, una regla de firewall que descarta, subred/gateway incorrecto o política del switch ascendente.

Síntoma D: Funciona brevemente y luego muere (o muere tras migración/reinicio)

Normalmente: conflicto de MAC, IP duplicada, estado de firewall de Proxmox, regresión del controlador de Windows tras una actualización, o características de offload/colas que interactúan mal.

Broma #1: DHCP es como una recepcionista—si no puedes llegar a ella, te quedarás en el vestíbulo para siempre y culparás al edificio.

Comprobaciones en el host (Proxmox): bridges, taps, firewall, VLANs

No empieces dentro de Windows. Empieza donde tienes las mejores herramientas: el host Proxmox. Allí puedes observar la realidad.

Tarea 1: Confirma que la NIC de la VM está adjunta al bridge que crees

cr0x@server:~$ qm config 100 | grep -E '^net[0-9]+:'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=1,tag=20

Qué significa la salida: La VM 100 tiene una NIC VirtIO con MAC DE:AD:BE:EF:10:00 adjunta a vmbr0, con firewall de Proxmox activado y etiqueta VLAN 20.

Decisión: Si bridge= es incorrecto (p. ej., vmbr1 cuando querías vmbr0), corrige la configuración de la VM antes de tocar Windows. Si existe tag=, debes confirmar que la VLAN 20 es correcta de extremo a extremo.

Tarea 2: Verifica que el bridge exista y tenga los puertos esperados

cr0x@server:~$ bridge link show
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 100
5: tap100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 100

Qué significa la salida: La NIC física eno1 y el tap de la VM tap100i0 están ambos esclavizados a vmbr0. Ese es el cableado básico.

Decisión: Si no ves el tap en el bridge correcto, la VM no está conectada. Reinicia la VM o inspecciona la configuración de red de Proxmox y la asignación de la NIC de la VM.

Tarea 3: Confirma que el bridge y las NIC están UP

cr0x@server:~$ ip -br link show vmbr0 eno1 tap100i0
vmbr0            UP             5a:9a:12:34:56:78 <BROADCAST,MULTICAST,UP,LOWER_UP>
eno1             UP             3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>
tap100i0         UP             fe:54:00:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>

Qué significa la salida: Los enlaces están administrativamente arriba y hay portadora presente (LOWER_UP).

Decisión: Si vmbr0 está DOWN, tienes un problema de red en el host. Si solo el tap está DOWN, mira el estado en tiempo de ejecución de la VM o problemas con el proceso QEMU.

Tarea 4: Revisa la configuración de red de Proxmox por cableados evidentes

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.0.2.10/24
        gateway 192.0.2.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

Qué significa la salida: vmbr0 es un bridge Linux con eno1 como su puerto; el host tiene IP en el bridge, no en eno1. Eso es normal en Proxmox.

Decisión: Si la IP del host está en la NIC física en lugar del bridge, las VMs no llegarán a la red a través del bridge como esperas. Corrígelo con cuidado (idealmente mediante una ventana de mantenimiento o acceso por consola).

Tarea 5: Confirma que existe la interfaz tap para esa VM y mapea al proceso QEMU correcto

cr0x@server:~$ ps -ef | grep -E 'kvm.*-id 100\b' | head -n 1
root     21488     1 35 10:21 ?        00:14:12 /usr/bin/kvm -id 100 -name WIN-APP01 ...

Qué significa la salida: QEMU/KVM está corriendo para la VM 100.

Decisión: Si QEMU no está en ejecución, estás solucionando una VM que en realidad no está arriba. Arregla el problema de arranque de la VM primero.

Tarea 6: Comprueba si el host ve tráfico en el tap de la VM (ARP/DHCP es suficiente)

cr0x@server:~$ tcpdump -ni tap100i0 -c 10 -vv
tcpdump: listening on tap100i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.100001 ARP, Request who-has 192.0.2.1 tell 0.0.0.0, length 46
10:25:11.200002 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:10:00, length 300
10:25:12.200010 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:10:00, length 300

Qué significa la salida: La VM está emitiendo solicitudes ARP y DHCP. El dispositivo VirtIO y la pila de Windows al menos están intentando.

Decisión: Si ves solicitudes pero no respuestas, céntrate en bridge/firewall/VLAN/upstream DHCP. Si no ves nada, céntrate dentro de Windows (controlador o adaptador deshabilitado) o en la asignación de la NIC de la VM en Proxmox.

Tarea 7: Captura en el bridge o NIC física para ver si los paquetes salen del host

cr0x@server:~$ tcpdump -ni eno1 -c 10 -vv 'port 67 or port 68 or arp'
tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.200002 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:10:00, length 300
10:25:11.250123 IP 192.0.2.5.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 310

Qué significa la salida: Las solicitudes DHCP de la VM están alcanzando la NIC física, y las respuestas DHCP están regresando al host.

Decisión: Si las respuestas están en eno1 pero Windows aún tiene APIPA, la ruta de retorno desde el host a la VM está rota (firewall, filtrado del bridge, desajuste de etiqueta VLAN, o la VM no está recibiendo tramas).

Tarea 8: Comprueba el estado del firewall de Proxmox a nivel datacenter/nodo/VM

cr0x@server:~$ pve-firewall status
Status: enabled/running

Qué significa la salida: El servicio de firewall de Proxmox está habilitado y en ejecución. Eso no significa que esté bloqueando, pero sí que puede hacerlo.

Decisión: Si depuras un incidente en producción y las reglas son inciertas, deshabilita temporalmente el firewall a nivel VM para aislar (luego vuelve a habilitar con reglas correctas).

Tarea 9: Inspecciona rápidamente la configuración de firewall de la VM

cr0x@server:~$ qm config 100 | grep -E '^net0:'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=1,tag=20

Qué significa la salida: firewall=1 significa que se aplican reglas de firewall a nivel de VM.

Decisión: Para aislar, pon firewall=0 (a corto plazo) y vuelve a probar DHCP/ping. Si lo arregla, sabes dónde invertir tu tiempo.

Tarea 10: Comprueba el filtrado VLAN y la pertenencia VLAN en el bridge

cr0x@server:~$ bridge vlan show | sed -n '1,120p'
port              vlan-id
eno1              1 PVID Egress Untagged
eno1              20
tap100i0          20 PVID Egress Untagged

Qué significa la salida: El tap de la VM está sin etiquetar en la VLAN 20 (PVID 20), y el uplink eno1 lleva la VLAN 20. Esto es consistente con una VM configurada con tag=20 dependiendo del modo VLAN del bridge.

Decisión: Si falta la VLAN 20 en el uplink, la VM está atrapada en una isla VLAN. Arregla la configuración VLAN del bridge o el trunk del switch ascendente.

Tarea 11: Comprueba drops en ebtables/nftables (común cuando existen reglas de firewall)

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "tap100i0" oifname "vmbr0" accept
  }
}

Qué significa la salida: La política forward es drop, con una ruta de aceptación específica. Si tu ruleset real no permite DHCP (broadcast) apropiadamente, tendrás APIPA para siempre.

Decisión: Si la política es drop y no estás seguro de que las reglas cubran tu caso, corrige las reglas o abre temporalmente el forwarding para esa VM para validar la hipótesis.

Tarea 12: Confirma que no haya aprendizaje de MAC extraño o duplicados

cr0x@server:~$ bridge fdb show br vmbr0 | grep -i 'de:ad:be:ef:10:00'
de:ad:be:ef:10:00 dev tap100i0 master vmbr0 permanent

Qué significa la salida: El bridge conoce la MAC de la VM en tap100i0. Eso es esperado.

Decisión: Si ves la misma MAC en múltiples taps, clonaste una VM sin regenerar MACs. Corrige colisiones de MAC; causan “funciona a veces” que es el síntoma más caro.

Comprobaciones de configuración de VM: modelo de NIC, MAC, colas, BIOS/UEFI

Elige el modelo de NIC deliberadamente

En Proxmox puedes elegir modelos de NIC por VM. Aquí el consejo práctico:

• VirtIO: mejor rendimiento y menor sobrecarga de CPU. Requiere controladores en Windows.
• E1000/E1000e: bueno para “necesito que arranque y hable ahora”, pero el rendimiento puede ser mediocre bajo carga.
• RTL8139: no lo uses. Existe para perseguir entornos de laboratorio y formación.

Tarea 13: Verifica que el modelo de NIC sea VirtIO (si ese es el objetivo)

cr0x@server:~$ qm config 100 | grep -E '^net0:'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=1,tag=20

Qué significa la salida: Es VirtIO. Bien. Ahora Windows debe tener NetKVM.

Decisión: Si es e1000 y buscas rendimiento, cambia a VirtIO después de tener preparados los controladores (o adjunta temporalmente una segunda NIC para migrar).

Tarea 14: Añade temporalmente una segunda NIC para instalar controladores

Este es un truco limpio: añade una NIC E1000 como salvavidas, luego instala los controladores VirtIO y después quita la E1000. Reduce la cirugía impulsiva de controladores.

cr0x@server:~$ qm set 100 -net1 e1000,bridge=vmbr0
update VM 100: -net1 e1000,bridge=vmbr0

Qué significa la salida: La VM ahora tiene una segunda NIC que Windows probablemente reconoce sin controladores adicionales.

Decisión: Si Windows se pone en línea vía E1000, has demostrado que la ruta de red está bien y el problema es el controlador VirtIO. Procede a instalar NetKVM y luego elimina la E1000.

Multi-queue y offloads: no te pongas creativo durante una interrupción

La NIC VirtIO admite múltiples colas para rendimiento y paralelismo. Genial cuando está afinado. También una fuente de problemas fantasma cuando lo combinas con ciertas versiones de Windows, controladores antiguos y filtrado de seguridad.

Tarea 15: Revisa la topología de CPU actual y considera el número de colas de la NIC

cr0x@server:~$ qm config 100 | grep -E '^(sockets|cores|cpu):'
cores: 8
cpu: x86-64-v2-AES
sockets: 1

Qué significa la salida: La VM tiene 8 vCPUs. Multi-queue puede ayudar, pero solo si los controladores y las cargas se benefician.

Decisión: Si estás en modo recuperación, mantén los valores por defecto. Afina después con mediciones, no por presentimientos.

Comprobaciones en Windows: estado del controlador, adaptadores ocultos, DHCP, métricas

Ahora entras en el invitado. Usa la consola desde Proxmox si RDP está caído (seguramente lo está). Si Windows no puede ver el adaptador, no ayudará de nada suplicar al DHCP.

Tarea 16: Lista adaptadores y comprueba si Windows ve algo

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Format-Table -Auto Name,Status,LinkSpeed,MacAddress"
Name            Status LinkSpeed MacAddress
----            ------ --------- ----------
Ethernet        Up     1 Gbps    DE-AD-BE-EF-10-00

Qué significa la salida: Windows ve un adaptador, está arriba y la MAC coincide. Es una buena señal.

Decisión: Si no se listan adaptadores (o solo “Disconnected” sin enlace), salta a la instalación del controlador y a las comprobaciones del Administrador de dispositivos.

Tarea 17: Comprueba la configuración IP y si DHCP tuvo éxito

cr0x@server:~$ ipconfig /all
Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . : Red Hat VirtIO Ethernet Adapter
   Physical Address. . . . . . . . . : DE-AD-BE-EF-10-00
   DHCP Enabled. . . . . . . . . . : Yes
   Autoconfiguration IPv4 Address. . : 169.254.22.10(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . :

Qué significa la salida: Dirección APIPA. DHCP no completó. O las solicitudes no salen, las respuestas no llegan, o DHCP está bloqueado.

Decisión: Correlaciona con las tareas tcpdump en el host. Si el host ve respuestas DHCP pero Windows no obtiene concesión, sospecha del firewall del host/filtrado del bridge o problemas del controlador.

Tarea 18: Fuerza la renovación DHCP y observa errores

cr0x@server:~$ ipconfig /release
Windows IP Configuration

No operation can be performed on Ethernet while it has its media disconnected.

cr0x@server:~$ ipconfig /renew
Windows IP Configuration

An error occurred while renewing interface Ethernet : unable to contact your DHCP server. Request has timed out.

Qué significa la salida: O bien Windows cree que el enlace está caído (“media disconnected”) o las solicitudes DHCP no son respondidas.

Decisión: Si muestra “media disconnected”, sospecha problemas de controlador/virtio o de adjunto tap/bridge en Proxmox. Si solo hay timeout de DHCP, sospecha upstream o firewall/VLAN.

Tarea 19: Comprueba el estado del controlador mediante PowerShell

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Format-Table -Auto Status,Problem,Class,FriendlyName"
Status Problem Class FriendlyName
------ ------- ----- ------------
OK     0       Net   Red Hat VirtIO Ethernet Adapter

Qué significa la salida: El dispositivo está sano desde la perspectiva PnP.

Decisión: Si Status es Error o Problem es distinto de cero, necesitas instalar/actualizar el controlador o reenumerar el dispositivo.

Tarea 20: Busca NICs ocultas/fantasma que roben la configuración

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net -Status Unknown,Error | Format-Table -Auto FriendlyName,Status,Problem"
FriendlyName                         Status   Problem
------------                         ------   -------
Microsoft Kernel Debug Network Adapter Error    28

Qué significa la salida: Puedes tener adaptadores obsoletos o adaptadores de depuración que interfieran, dependiendo del entorno.

Decisión: Elimina adaptadores obsoletos en el Administrador de dispositivos (mostrar dispositivos ocultos) si tienes cambios de MAC o creación repetida de NICs.

Tarea 21: Prueba la pila local frente a la externa con ping + tabla de rutas

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.0.2.1       192.0.2.50     25
        192.0.2.0    255.255.255.0         On-link      192.0.2.50    281
===========================================================================

cr0x@server:~$ ping -n 3 192.0.2.1
Pinging 192.0.2.1 with 32 bytes of data:
Reply from 192.0.2.1: bytes=32 time<1ms TTL=64
Reply from 192.0.2.1: bytes=32 time<1ms TTL=64
Reply from 192.0.2.1: bytes=32 time<1ms TTL=64

Qué significa la salida: El enrutamiento es sano, el gateway es alcanzable. Si DNS o el externo fallan, has acotado el problema.

Decisión: Si el ping al gateway falla pero tienes concesión, sospecha desajuste de VLAN, firewall o seguridad de puerto ascendente.

Soluciones para el controlador VirtIO: instalar, actualizar y recuperar

VirtIO en Windows no es complicado, pero no perdona controladores medio instalados, ISOs obsoletos y desajustes con Secure Boot. El enfoque más limpio: monta el ISO de controladores VirtIO en Proxmox, instala NetKVM correctamente y reinicia una vez.

Prepara el ISO del controlador VirtIO (lado host)

Tarea 22: Confirma el almacenamiento ISO y la presencia del ISO VirtIO

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active       100000000        20000000         80000000       20%
...
cr0x@server:~$ ls -lh /var/lib/vz/template/iso | grep -i virtio
-rw-r--r-- 1 root root  520M Aug  1 09:12 virtio-win.iso

Qué significa la salida: Tu almacenamiento de ISOs está disponible y el ISO VirtIO está presente.

Decisión: Si falta el ISO, no puedes instalar controladores sin otra vía (p. ej., inyectar controladores o usar una E1000 como salvavidas). Lleva el ISO al almacenamiento ISO primero.

Adjunta el ISO a la VM (lado host)

Tarea 23: Adjunta el ISO VirtIO como CD-ROM

cr0x@server:~$ qm set 100 -ide2 local:iso/virtio-win.iso,media=cdrom
update VM 100: -ide2 local:iso/virtio-win.iso,media=cdrom

Qué significa la salida: La VM tiene el ISO de controladores adjuntado.

Decisión: Arranca Windows e instala/actualiza el controlador NetKVM desde el CD montado.

Instala/actualiza NetKVM dentro de Windows

Puedes hacerlo mediante el Administrador de dispositivos, pero en producción prefiero comandos repetibles. Aun así, la interfaz gráfica está bien si estás en la consola y el tiempo apremia.

Tarea 24: Confirma que el CD VirtIO es visible y localiza el INF de NetKVM

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Where-Object DriveLetter | Format-Table -Auto DriveLetter,FileSystemLabel"
DriveLetter FileSystemLabel
----------- ---------------
D           virtio-win

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path D:\NetKVM -Recurse -Filter netkvm.inf | Select-Object -First 3 FullName"
FullName
--------
D:\NetKVM\w10\amd64\netkvm.inf

Qué significa la salida: El INF del controlador es accesible para variantes de Windows 10/Server en amd64.

Decisión: Usa pnputil para agregar/instalar el controlador desde el directorio adecuado para tu SO.

Tarea 25: Agrega e instala el controlador NetKVM usando pnputil

cr0x@server:~$ pnputil /add-driver D:\NetKVM\w10\amd64\netkvm.inf /install
Microsoft PnP Utility

Driver package added successfully.
Published Name: oem42.inf
Driver package installed on matching devices.

Qué significa la salida: El paquete de controladores está registrado e instalado para el hardware coincidente (tu NIC VirtIO).

Decisión: Reinicia la VM. Sí, reinicia. Las instalaciones de controladores que “no necesitan reinicio” son cómo acabas depurando fantasmas.

Tarea 26: Verifica que la descripción del adaptador sea VirtIO y que el enlace esté activo tras el reinicio

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Format-Table -Auto Name,Status,InterfaceDescription"
Name     Status InterfaceDescription
----     ------ --------------------
Ethernet Up     Red Hat VirtIO Ethernet Adapter

Qué significa la salida: NetKVM funciona y la interfaz está arriba.

Decisión: Si el estado sigue siendo Down/Disconnected mientras el host ve tráfico, revisa etiquetas VLAN, firewall de Proxmox y ajustes avanzados del adaptador en Windows.

Cuando Secure Boot o la firma del controlador te bloquean

Si Windows rechaza el controlador (Código 52, problemas de firma), tienes tres opciones sensatas:

• Usar una compilación más reciente del controlador VirtIO que esté correctamente firmada para tu versión de Windows y la política de Secure Boot.
• Deshabilitar Secure Boot para esa VM (solo si la política lo permite; muchas organizaciones no lo permiten).
• Cambiar temporalmente el modelo de NIC a E1000 para restaurar el acceso, y luego planear un despliegue controlado del controlador VirtIO.

Tarea 27: Comprueba problemas del dispositivo relacionados con la firma del controlador

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Where-Object Status -ne 'OK' | Format-Table -Auto FriendlyName,Status,Problem"
FriendlyName                         Status Problem
------------                         ------ -------
Red Hat VirtIO Ethernet Adapter       Error  52

Qué significa la salida: El Problema 52 comúnmente indica que Windows no puede verificar la firma del controlador.

Decisión: Actualiza a una versión firmada del controlador adecuada para tu SO, o cambia la configuración de Secure Boot según la política. No “deshabilites la aplicación” en producción a menos que disfrutes las auditorías.

Broma #2: Una VM sin controlador NIC es como una llamada en conferencia en silencio—todos técnicamente están conectados y no pasa nada útil.

Tres micro-historias del mundo corporativo (las que arruinan los viernes)

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

Un equipo migró una pequeña flota de servidores Windows utilitarios desde un cluster VMware envejecido a Proxmox. El plan era “simple”: recrear VMs, adjuntar discos, usar VirtIO en todas partes y celebrar. El primer servidor arrancó, los servicios parecían saludables y luego la monitorización se encendió: sin métricas, sin RDP, sin parches, sin tráfico de dominio.

La suposición fue que Windows “encontraría la NIC eventualmente”. Estaban acostumbrados a E1000 en otros entornos y pensaron que VirtIO era una mejora de rendimiento, no un cambio de hardware que requería controlador. La consola mostraba un vacío familiar: ningún adaptador, nada en la categoría de red y el Administrador de dispositivos tenía un “Ethernet Controller” con un signo amarillo.

Alguien intentó arreglarlo reinstalando componentes de red de Windows y reseteando Winsock. Eso es como pulir el capó cuando falta el motor. La solución real fue aburrida: montar el ISO VirtIO, instalar NetKVM y reiniciar.

El informe postmortem también fue aburrido, que es el punto: la lista de verificación de la imagen no incluía “ISO VirtIO adjunto” como paso requerido. El equipo lo añadió. La siguiente ola de migraciones fue fluida y la única interrupción fue la que se merecían.

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

Otra organización ejecutaba VMs Windows de transferencia de archivos de alto rendimiento en Proxmox. Alguien leyó que multi-queue de VirtIO más offloads agresivos podían aumentar el rendimiento. Subieron las configuraciones, aumentaron las colas y declararon victoria sobre una prueba sintética.

Luego llegó el tráfico real. Bajo carga, las transferencias se atascaron intermitentemente. Los clientes veían timeouts. Las VMs tenían enlace, IPs y pings perfectos. El equipo perdió horas porque la falla no fue un corte total; fue “raro”, el modo de fallo que más consume tiempo.

En el host, tcpdump mostró ráfagas de retransmisiones. Dentro de Windows, los registros de eventos sugerían reinicios del controlador. Nada gritaba “problema de offload”, porque raramente lo hace. Finalmente retrocedieron los ajustes de offload y devolvieron las colas a valores por defecto. El problema desapareció.

Después, reintrodujeron cambios gradualmente, una variable a la vez, y midieron tasas de éxito de transferencia reales en vez de throughput bruto. La optimización no falló porque optimizar sea malo; falló por optimizar sin plan de reversión y sin pruebas con carga real.

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

Una empresa tenía una regla: cada plantilla de Windows incluía controladores VirtIO preinstalados, incluso si el modelo de NIC inicial era E1000. La razón era simple: no quieres descubrir controladores faltantes durante una llamada de respuesta a incidentes.

También exigían que cada VM tuviera una “NIC de emergencia” documentada: un segundo adaptador que pudiera habilitarse temporalmente (o añadirse rápido) para recuperar conectividad. Suena paranoico. Es seguro barato.

Durante un mantenimiento, un lote de VMs se reinició y un subconjunto levantó la red sin VirtIO por una regresión de controlador tras el parcheo. El ingeniero on-call no discutió metafísica. Cambió esas VMs al modelo de la NIC de emergencia, recuperó el acceso y luego desplegó la versión de controlador VirtIO conocida como buena.

Sin noche heroica, sin escalada a proveedor, sin ediciones aleatorias del registro. Solo una vía de escape documentada y practicada. El informe del incidente fue corto, y eso es lo mejor que puedes decir de un informe de incidente.

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

1) Síntoma: Windows muestra “Ethernet Controller” con signo de exclamación amarillo

Causa raíz: Se presentó la NIC VirtIO, pero no se instaló NetKVM.

Solución: Adjunta el ISO VirtIO, instala el controlador mediante el Administrador de dispositivos o pnputil (Tarea 25), reinicia.

2) Síntoma: El adaptador existe, APIPA 169.254.x.x, sin servidor DHCP mostrado

Causa raíz: Tráfico DHCP bloqueado o sin llegar al servidor DHCP (desajuste de VLAN, firewall, bridge equivocado).

Solución: tcpdump en tap y uplink (Tareas 6–7). Si las respuestas no vuelven al tap, revisa firewall de Proxmox (Tareas 8–11) y configuración VLAN (Tarea 10).

3) Síntoma: El host ve respuesta DHCP en la NIC física, Windows sigue con APIPA

Causa raíz: La respuesta no se reenvía al tap (filtrado del bridge, reglas de firewall, desajuste de filtrado VLAN).

Solución: Valida pertenencia VLAN del bridge (Tarea 10), ruleset de nftables (Tarea 11) y que el tap esté en el bridge correcto (Tarea 2).

4) Síntoma: La VM tiene IP, puede hacer ping a la IP del bridge del host, pero no al gateway

Causa raíz: Desajuste de trunk/access en el switch ascendente, o el etiquetado de Proxmox no coincide con la política del switch.

Solución: Confirma el tag de la VM y la configuración VLAN del bridge (Tareas 1, 10). Valida la configuración del puerto del switch (fuera de Proxmox). Como prueba rápida, elimina la etiqueta VLAN y coloca la VM sin etiquetar en la VLAN nativa solo si la política lo permite.

5) Síntoma: La red funciona hasta la migración en vivo, luego muere

Causa raíz: Configuración inconsistente de bridge/VLAN/firewall entre nodos; el vmbr0 del nodo destino no es idéntico.

Solución: Compara /etc/network/interfaces y la configuración de firewall entre nodos. Estandariza bridges y filtrado VLAN en todos los nodos. No trates a los nodos del cluster como copos de nieve.

6) Síntoma: Caídas aleatorias bajo carga, pings mayormente bien

Causa raíz: Interacción offload/cola/controlador, o desajuste de MTU en parte de la ruta.

Solución: Reduce a valores por defecto (colas/offloads), prueba con tráfico sostenido. Confirma MTU en vmbr, tap, NIC física y upstream. Evita tramas jumbo a menos que toda la ruta esté verificada.

7) Síntoma: Dos VMs clonadas “tienen red”, pero una es inestable

Causa raíz: MAC o IP duplicados, luchas de caché ARP, seguridad de puerto en switch.

Solución: Asegura MACs únicas en la configuración de Proxmox; regenera si es necesario. Limpia cachés ARP upstream si hace falta. Usa la Tarea 12 para detectar duplicados de MAC en el bridge.

8) Síntoma: Windows dice “Media disconnected” aunque la VM esté ejecutándose

Causa raíz: NIC no adjuntada al bridge, tap ausente/caído o controlador de Windows que no se enlaza correctamente.

Solución: Valida presencia del tap en el bridge (Tarea 2), estado UP de las interfaces (Tarea 3) y estado PnP en Windows (Tarea 19). Considera añadir temporalmente la E1000 como salvavidas (Tarea 14).

Listas de verificación / plan paso a paso

Lista A: Has creado una VM Windows nueva y no tiene red

1. En host: qm config <vmid> | grep '^net' → confirma bridge, tag, firewall.
2. En host: bridge link show → confirma que el tap está esclavizado al bridge previsto.
3. En host: tcpdump -ni tapX → confirma si existe tráfico alguno.
4. Si no hay tráfico: en Windows, revisa el Administrador de dispositivos por NetKVM faltante; monta el ISO VirtIO e instala el controlador.
5. Si hay tráfico pero no hay respuestas: revisa VLAN y firewall; captura en la NIC física para ver si regresan las respuestas.
6. Tras instalar el controlador: reinicia; verifica que ipconfig /all muestre una concesión, no APIPA.

Lista B: Convertiste de E1000 a VirtIO y perdiste acceso

1. No hagas clics impulsivos. Añade una segunda NIC E1000 (Tarea 14) para restaurar acceso.
2. Adjunta el ISO VirtIO (Tarea 23).
3. Instala NetKVM vía pnputil (Tarea 25).
4. Reinicia.
5. Confirma que el adaptador VirtIO esté activo y tenga la IP correcta.
6. Elimina la NIC E1000 después de verificar la salud del servicio.

Lista C: Dirección APIPA y timeouts DHCP

1. Host: tcpdump -ni tap... — ¿ves DHCP DISCOVER/REQUEST?
2. Host: tcpdump -ni eno1 ... — ¿ves respuestas DHCP regresando?
3. Si las respuestas no regresan: DHCP upstream o puerto del switch está mal.
4. Si las respuestas llegan al host pero no a la VM: filtrado firewall/bridge/VLAN en el host está mal.
5. Deshabilita temporalmente el firewall de la VM para aislar, luego vuelve a habilitar con reglas correctas.
6. Sólo después de validar la ruta: considera actualizar el controlador o ajustar offloads.

Lista D: Problemas de migración en el cluster

1. Compara bridges entre nodos (/etc/network/interfaces), incluido el filtrado VLAN.
2. Confirma postura de firewall idéntica entre nodos.
3. Valida la consistencia de nombres de uplink NIC (eno1 vs enpXsY).
4. Ejecuta las mismas pruebas tcpdump en nodos origen y destino.
5. Estandariza la configuración; no parchees por nodo a menos que disfrutes incidentes recurrentes.

Preguntas frecuentes

1) ¿Debería usar E1000 para que Windows siempre funcione?

Para un rescate puntual, E1000 está bien. En producción, prefiere VirtIO una vez que los controladores estén preparados. E1000 es un valor por defecto fácil que a la larga se convierte en un impuesto de rendimiento.

2) Mi VM Windows muestra APIPA. ¿Eso prueba que el controlador VirtIO está instalado?

No necesariamente. Prueba que Windows tiene alguna interfaz y que intentó DHCP. Aún debes verificar que el dispositivo sea la NIC VirtIO y que el controlador esté sano.

3) ¿Puede el firewall de Proxmox romper DHCP?

Sí. DHCP usa muchos broadcasts y puede ser bloqueado por políticas con DROP por defecto o reglas faltantes. Si ves respuestas DHCP en el uplink pero no en el tap, sospecha filtrado de firewall/bridge.

4) ¿Necesito QEMU Guest Agent para la red?

No. Guest Agent ayuda con reporte de IP, apagado y algo de automatización. No hace funcionar la NIC. Pero hace la vida menos miserable una vez que la NIC funciona.

5) ¿Por qué funciona en un nodo pero no tras la migración?

Porque los nodos del cluster derivan. Alguien “arregló rápido” un bridge o filtrado VLAN en un host. La migración movió la VM a otra realidad. Estandariza la configuración de red en todos los nodos.

6) ¿Qué pasa si Secure Boot está habilitado y NetKVM no carga?

Usa una versión de VirtIO firmada correctamente para tu build de Windows. Si la política lo permite, deshabilita Secure Boot para la VM. De lo contrario, usa E1000 temporalmente mientras preparas controladores firmados.

7) ¿Puede el etiquetado VLAN en Proxmox entrar en conflicto con la configuración del switch?

Constantemente. Si la VM está etiquetada con VLAN 20 pero el puerto del switch es access VLAN 1, habrá silencio. Alinea la etiqueta de la VM, el filtrado VLAN del bridge y la política del puerto físico.

8) ¿Cómo digo si el problema está dentro de Windows o en la red de Proxmox?

Captura tráfico en la interfaz tap de la VM. Si ves DHCP/ARP saliendo, al menos Windows está emitiendo. Si ves respuestas en el uplink pero no en el tap, es problema del host. Si no ves nada en el tap, es estado del controlador/adaptador del invitado o la asignación de la NIC de la VM.

9) ¿Es seguro deshabilitar offloads o reducir colas para arreglar inestabilidad?

Es seguro como diagnóstico y a menudo seguro a largo plazo. Mide después de los cambios. Los offloads pueden ayudar, pero también introducir comportamientos difíciles de diagnosticar según el controlador y el filtrado.

10) ¿Cuál es la acción más rápida para «volver en línea»?

Añadir una segunda NIC E1000, levantar la VM, instalar los controladores VirtIO y luego quitar la E1000. Es práctico, reversible y no requiere adivinanzas.

Conclusión: siguientes pasos para evitar repeticiones

Arreglar una VM Windows sin red en Proxmox normalmente no es una maldición mística de Windows. Es un controlador VirtIO faltante, un desajuste de bridge, una política de firewall o una configuración VLAN casi correcta. La ruta más rápida siempre es la misma: verifica la configuración de la VM, observa el tráfico en el tap, confirma el comportamiento del bridge y uplink, y luego corrige el controlador del invitado solo cuando hayas probado la ruta de red.

Haz lo siguiente:

1. Estandariza la política de NICs: VirtIO por defecto, con controladores preparados en las plantillas.
2. Mantén una vía de rescate: procedimiento documentado “añadir NIC E1000 lifeline” para emergencias.
3. Haz idéntica la red del cluster: mismos bridges, filtrado VLAN y postura de firewall en cada nodo.
4. Operativiza las comprobaciones: el paso tcpdump en el tap detecta la mitad de las fallas en menos de un minuto.