Si tus máquinas virtuales funcionan con normalidad por la mañana, pero luego empiezan a fallar, a perder paquetes o a sufrir una caída drástica del rendimiento cuando la carga de trabajo aumenta, es un verdadero quebradero de cabeza averiguar la causa. Normalmente, el problema no reside en Hyper-V en sí, sino en lo que hay debajo: concretamente, la tarjeta de red y cómo gestiona todo ese tráfico. Solucionar este tipo de problemas requiere algunos ajustes, principalmente desactivar algunas funciones de descarga molestas o actualizar los controladores, y si lo haces bien, es como encender un interruptor: todo se estabiliza. Así que aquí tienes un resumen de lo que ha funcionado en el pasado y lo que debes revisar.
Cómo solucionar problemas de red de NIC y Hyper-V durante picos de carga
¿Por qué sucede esto?
Básicamente, durante las horas pico, las NIC intentan ser inteligentes. Descargan ciertas sumas de verificación, división de paquetes y tareas de cola para ahorrar ciclos de CPU. Suena bien, ¿verdad? Pero en realidad, especialmente con controladores antiguos o genéricos (sí, Windows Update a menudo te da la versión lenta y con errores), estas rutas de descarga a veces se cruzan al pasar por el conmutador virtual. Las sumas de verificación se corrompen, los datos llegan dañados o corruptos y, de repente, tu red de VM se vuelve muy inestable. El principal culpable es VMQ, la tecnología de cola de máquina virtual que distribuye la carga entre los núcleos. Si el controlador o el hardware son inestables, puede producir corrupción de paquetes solo bajo una carga pesada cuando toda esa descarga se satura.
La solución consiste en deshabilitar o actualizar estas funciones de descarga. Eso es lo que he visto que funciona, al menos en la mayoría de los casos.
Solución 1: Actualice el controlador de su tarjeta de red desde el sitio web del proveedor.
Esto es bastante obvio, pero a menudo se pasa por alto. Los controladores obsoletos suelen ser la causa de todos estos errores de descarga de potencia. No te fíes solo de Windows Update; ve directamente al sitio web del fabricante del hardware. Suelen tener un controlador más reciente y optimizado que corrige problemas conocidos.
- Abre el Administrador de dispositivos y busca tu tarjeta de red; fíjate en el modelo exacto para obtener el controlador correcto.
- Dirígete al sitio web del fabricante: Intel, Broadcom, Realtek, o quienquiera que haya fabricado tu tarjeta de red.
- Descarga el controlador más reciente para tu modelo exacto y versión de Windows. A veces, la versión más reciente se encuentra oculta en la sección «Descargas de soporte más recientes».
- Ejecuta el instalador y luego reinicia. Sí, puede que te pida reiniciar, pero créeme, los controladores genéricos de Windows suelen estar desactualizados o carecen de la corrección crítica.
En algunos casos, he notado que Windows Update instala un controlador antiguo que, en realidad, empeora las cosas. Usar el controlador más reciente del fabricante suele solucionar el problema, o al menos mejora la situación.
Solución 2: Deshabilitar VMQ en la NIC física.
Si la actualización del controlador no solucionó el problema, el siguiente paso es desactivar VMQ. En una configuración de un solo host, el impacto es mínimo, pero puede reducir drásticamente la corrupción de paquetes durante los picos de carga.
- Abra PowerShell como administrador ( Windows + Xluego seleccione Terminal (Administrador) ).
- Compruebe el estado de VMQ con:
Get-NetAdapterVmq - Identifique su tarjeta de red física, que normalmente está etiquetada como «Ethernet» o similar.
- Deshabilite VMQ para esa NIC con:
Disable-NetAdapterVmq -Name "Ethernet"
Como alternativa, puedes hacer lo mismo a través de la interfaz gráfica: abre el Administrador de dispositivos, busca tu tarjeta de red, ve a la pestaña Avanzado y desactiva las colas de máquinas virtuales. El resultado es el mismo. Ten en cuenta que algunas tarjetas de red o controladores gestionan esto de forma diferente y, en algunos casos, puede ser necesario reiniciar el equipo para que los cambios surtan efecto.
Este paso ha sido útil en muchísimos casos, sobre todo con tarjetas de red Intel o Broadcom antiguas. Es una simple acción como «desactivar la descarga de procesamiento inestable» que puede solucionar el problema.
Solución 3: Desactivar las funciones de descarga TCP.
Si VMQ no fue el héroe, tal vez sean los motores de descarga TCP los que estén causando el problema. Estas funciones, como Large Send Offload y Checksum Offload, están diseñadas para acelerar el proceso, pero bajo carga pueden generar paquetes incompletos.
- En el Administrador de dispositivos, expanda Adaptadores de red. Busque su NIC, haga clic con el botón derecho > Propiedades.
- Cambia a la pestaña Avanzado.
- Cambie la siguiente configuración a Deshabilitado :
- Descarga de envíos grandes V2 (IPv4)
- Descarga de envíos grandes V2 (IPv6)
- Descarga de suma de comprobación TCP
- Descarga de suma de comprobación UDP
Este ajuste sacrifica un poco de eficiencia de la CPU a cambio de una gestión de paquetes mucho más fiable bajo presión. En la mayoría de las configuraciones, merece la pena, y es posible que observes que el rendimiento se mantiene estable durante las horas punta. Estás desactivando algunas rutas de descarga que la tarjeta de red utiliza para hacer trampas, pero a menudo recurren a la manipulación inversa con tramas corruptas.
Solución 4: Deshabilitar RSC (Receive Segment Coalescing) en el conmutador virtual.
Se supone que RSC mejora el rendimiento de la CPU agrupando paquetes, pero lleva tiempo causando problemas de rendimiento e integridad de paquetes en Hyper-V. Aunque parezca extraño, desactivarlo podría solucionar la oleada de corrupción durante los picos de carga.
- Abra PowerShell como administrador.
- Compruebe la configuración actual con:
Get-VMSwitch | Select Name, SoftwareRscEnabled - Si está habilitado, desactívelo:
Set-VMSwitch -Name "YourSwitchName" -EnableSoftwareRsc $false
Luego, realiza algunas pruebas de carga; si la corrupción de paquetes cesa con cargas altas, ese era el problema. Nota: Reemplaza YourSwitchName con el nombre real de tu switch, que puedes listar con Get-VMSwitch. En muchas configuraciones, dejar RSC deshabilitado mantiene la red estable.
Corrección 5: Emparejar MTU y marcos Jumbo de extremo a extremo
Este problema es sutil: si la MTU o los Jumbo Frames no coinciden entre los dispositivos, comienzan a transmitirse fragmentos, lo que a menudo se confunde con pérdida o corrupción de paquetes. Durante periodos de alto tráfico, esta discrepancia es lo primero que provoca retrasos o comportamientos anómalos.
- En el Administrador de dispositivos, vaya a la pestaña Avanzado de su tarjeta de red y busque Paquete Jumbo.
- Si los jumbo frames están activados en el host pero no en el switch o router, los frames se recortarán o se perderán.¿La mejor solución? Configurar la misma MTU en todos los dispositivos: habilitar los jumbo frames en todas partes (si la red lo admite) o desactivarlos por completo y mantener 1500 bytes.
Para comprobar o cambiar la MTU en la línea de comandos:
netsh interface ipv4 show subinterfacesnetsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistentLo mismo aplica para IPv6 si es necesario. Mantener la configuración de todos los dispositivos consistente evita el caos de fragmentación que empeora bajo carga, especialmente durante picos de tráfico.
Cómo mantenerlo todo estable
- Descarga siempre los controladores de red directamente del fabricante, no de Windows Update. Los controladores obsoletos suelen ser la causa oculta de estos errores.
- Desactive VMQ de antemano si las tarjetas de red son antiguas o los controladores son inestables. Es mejor que lidiar con problemas posteriores.
- Iguala la configuración de MTU y tramas jumbo en todos los conmutadores, enrutadores y máquinas virtuales para evitar que se produzcan errores.
- Realice pruebas de carga en su red antes de la implementación para detectar estos problemas a tiempo: un conmutador puede funcionar sin problemas en reposo, pero convertirse en un desastre cuando está en uso.
La gente también pregunta
¿Por qué Hyper-V descarta paquetes bajo una carga de trabajo elevada?
En la mayoría de los casos, el problema reside en las funciones de descarga de la tarjeta de red. Las funciones como VMQ, Large Send Offload o checksum offload, que aceleran el procesamiento con poco tráfico, tienden a fallar o corromperse cuando el tráfico alcanza niveles críticos. Desactivar estas funciones suele solucionar el problema de la sobrecarga de paquetes.
¿Debo deshabilitar VMQ en Hyper-V?
Si utilizas un único servidor o experimentas problemas, sí, especialmente con tarjetas de red o controladores antiguos. Si bien VMQ ayuda a distribuir la carga en servidores con varias tarjetas de red, puede causar más problemas que beneficios en una configuración sencilla. Deshabilitar VMQ suele solucionar la pérdida aleatoria de paquetes o la corrupción bajo cargas elevadas, prácticamente sin una disminución notable del rendimiento.
¿Desactivar la descarga TCP ralentiza el sistema?
Sí, en cierto modo. Traslada parte de la carga de la CPU al procesador, pero en las CPU modernas, la pérdida de rendimiento es mínima. Normalmente, la estabilidad y la seguridad del tráfico compensan con creces ese pequeño sacrificio. La mayoría de las configuraciones ni siquiera notarán la diferencia, ¿pero paquetes rotos? Eso ya es otra historia.
Esperemos que estos trucos ayuden a alguien a evitar pasar horas intentando solucionar problemas de red durante las horas punta. A veces, una simple actualización de controladores o un pequeño ajuste lo soluciona más rápido de lo esperado.¡Buena suerte!