Tengo una configuración bastante simple: Windows Server 2012 Hyper V Host, con dos máquinas virtuales (ambas Server 2012), una para IIS y otra para SQL Server. Todos se están conectando a través de la NIC física.
Anoche intenté agregar un conmutador virtual y configurar NIC virtuales en las dos máquinas virtuales (además de la NIC física).
Todavía no había cambiado los servidores para usar las NIC virtuales, pero por alguna razón, esto destruyó la velocidad de conexión entre las dos VM, a pesar de que las NIC virtuales no se estaban usando. ¡Estamos hablando de 200-500 milisegundos a 30-90 segundos por solicitud!
Así que esta mañana, después de ver el terrible impacto que tuvo en mi sitio, desactivé las dos NIC virtuales, ya que eso es todo lo que cambié y, efectivamente, las velocidades volvieron.
En última instancia, necesito que cambien al uso de v-NIC, pero primero debo solucionar este problema.
¿Qué podría estar causando esto? ¿Y qué puedo hacer para solucionarlo?
Detalles adicionales:
La configuración es realmente muy simple (lo que puede ser parte de mi problema, puede que esté simplificando demasiado lo que se necesita para configurarla).
Tengo un único servidor con una única NIC (física). Actualmente, esta NIC se utiliza para la comunicación entre el v-host e Internet, así como entre las dos VM e Internet. También se utiliza para la comunicación interna entre las dos máquinas virtuales.
Sin embargo, estoy intentando cambiar la comunicación interna para que pase por el interruptor virtual a través de vNIC, liberando la NIC física para usarla solo para comunicaciones externas.
Entonces agregué un conmutador virtual interno al v-host y luego agregué una NIC virtual a cada VM.
Después de hacer esto, fue cuando la velocidad de mi conexión (a través de la NIC física) disminuyó drásticamente. Al deshabilitar las vNIC (a través de la configuración de red de las VM) la velocidad volvió a la normalidad.
A continuación se muestran pantallas de configuración de VM para la NIC física externa y las vNIC internas (en una sola VM, ya que ambas están configuradas de manera idéntica).
Otra ronda de detalles
Al profundizar un poco más en el tema, parece que las NIC de Broadcom son conocidas por sus problemas de rendimiento. Este servidor tiene dos NIC Broadcom BCM5716C. Aquí hay algunos enlaces para discutir problemas conocidos:
Acceso lento a la red dentro de máquinas virtuales: Broadcom y Hyper-V
Red muy lenta de máquina virtual Hyper-V – VMQ – Broadcom
Entonces comencé a jugar con las configuraciones, deshabilitando varias configuraciones, una a la vez. Ninguno de los cambios pareció tener ningún impacto en el problema: si habilito la vNIC invitada, las velocidades de carga caen a más de 25 segundos. Desactívelo nuevamente, vuelven a 250 ms.un factor de 100!
También intenté instalar los controladores más recientes de Broadcom, no hubo diferencia.
En este punto, creo que es una cuestión de compatibilidad entre la NIC de Broadcom y Hyper-V. Pero no quiero pedir nuevas NIC y tomarme la molestia de cerrar el sitio, instalarlas y configurarlas, sólo para que el problema persista.
Por lo tanto, sería bueno si pudiera descartar definitivamente la NIC.
Configuración de NIC física en el administrador de conmutadores
Configuración del conmutador virtual en el administrador de conmutadores
Configuración de NIC física en la máquina virtual de base de datos
Configuración de NIC virtual en la máquina virtual de base de datos
Respuesta1
Tengo una configuración muy similar. Encontré la respuesta aquí (Transferencias de archivos extremadamente lentas a Hyper-V VM en la máquina local)
Con el chipset Broadcom desactivé las colas virtuales y desapareció toda la latencia. Realice este cambio en la NIC física, no en la NIC virtual.
Respuesta2
AFAIK, no existe el paso a través de NIC física en Hyper-V. Ha creado un vSwitch llamado "NIC física", que está asignado a un adaptador físico y ha habilitado el uso del sistema operativo de administración. En cada VM, hay una vNic que utiliza este conmutador. ¿Por qué quieres cambiar de un conmutador virtual a otro? Aparte de que el "nuevo" no está conectado a nada, realmente no veo el sentido.
Hyper-V es lo suficientemente inteligente como para enviar tráfico desde el conmutador virtual a la NIC física solo cuando el tráfico se enruta fuera del host, lo que significa que ya está haciendo lo que está tratando de lograr.