¿Un cambio de red de cinco minutos se convierte en toda una tarde de clics?
Con vSwitches estándar, cada grupo de puertos se crea individualmente en cada host ESXi: host por host, VLAN ID y teaming a mano cada vez. COD despliega vSwitches estándar y grupos de puertos en varios hosts y clústeres de una sola vez, con dry run y registro de auditoría, multi-tenant y on-premise.
Estructura del hipervisor con detección automática de mismatches en los grupos de puertos.
¿Le suena familiar?
Cluster hopping: crear cada grupo de puertos en cada host individualmente
El dolor: En entornos con vSwitches estándar, cada nuevo grupo de puertos, por ejemplo para una VLAN nueva, debe crearse individualmente en cada host ESXi: abrir el vSphere Client, ir host por host, VLAN ID y NIC teaming a mano cada vez.
La consecuencia: Un devorador de tiempo en cada cambio de red, y cada paso manual es una ocasión para erratas. Un host olvidado suele descubrirse solo cuando una VM debe aterrizar allí y falta la red.
Así lo resuelve COD: El módulo crea vSwitches estándar, opcionalmente con NIC físicas agrupadas, y grupos de puertos en varios hosts y clústeres a la vez. Modificar y borrar se hace igual de centralizado. El inventario de vCenter muestra de antemano datacenters, clústeres, hosts, redes y pNIC, de modo que ve adónde va el despliegue.
Misma VLAN ID, otro nombre: deriva silenciosa entre hosts
El dolor: Clústeres crecidos con los años, varios administradores, todo a mano: la misma VLAN ID se llama «VLAN20_Server» en un host y «Server-VLAN» en el siguiente. En el vSphere Client eso no salta a la vista en ningún sitio. Quien quiere comprobarlo exporta listas y compara nombres en Excel.
La consecuencia: Fuente clásica de errores en migraciones: las VM aterrizan en la red equivocada o un traslado falla porque en el host de destino falta la red con el mismo nombre, y la búsqueda del error se alarga.
Así lo resuelve COD: La detección de mismatches de nombres de VLAN avisa automáticamente cuando la misma VLAN ID figura con nombres de grupo de puertos distintos en vSwitches del mismo nombre a través de los hosts. El inventario de vCenter hace visible la topología real, en lugar de que usted vaya clicando host por host.
Cambios de red en hosts de producción: en vivo, sin ensayo, sin evidencia
El dolor: Los cambios en vSwitches y grupos de puertos actúan directamente en producción. Quien borra el grupo de puertos equivocado o se equivoca en la VLAN ID deja al instante sin red VMs en marcha. Después apenas se puede demostrar quién cambió qué y cuándo.
La consecuencia: Riesgo de caída en cada cambio fuera de la ventana de mantenimiento. El historial de cambios ausente se convierte rápido en un finding en auditorías NIS2 y KRITIS.
Así lo resuelve COD: El dry run está activo de forma predeterminada: crear, modificar y borrar se simula sin riesgo antes de desplegar el cambio. Cada cambio ejecutado queda en el registro de auditoría, con tipo, datos enviados y devueltos, momento y usuario. El acceso está protegido por roles.
Por qué COD, no solo una función
El módulo de hipervisor forma parte de la misma plataforma en la que ya gestiona su infraestructura: basado en roles, multi-tenant y on-premise. Varios vCenter se integran mediante varios accesos centrales y se controlan en un solo lugar. Dry run y registro de auditoría no son una herramienta adicional, sino que están integrados en el despliegue: primero simular, luego desplegar, todo demostrable.
Preguntas frecuentes
Las redes virtuales bajo control central.
Solicite una demo en directo. Le mostramos el módulo Hypervisor de forma práctica en su entorno, sin presión comercial, o descargue la ficha técnica con todos los datos resumidos en PDF.