Problema

Después de migrar de VMware a Hyper‑V, muchos administradores se encuentran sin una vista única que combine la salud del hardware (servidores, SAN, componentes de red) y el estado de las máquinas virtuales. En VMware, vCenter entrega métricas de CPU, memoria, latencia de disco y alertas de hardware en una sola consola. Con Hyper‑V, la información está repartida entre Failover Cluster Manager, el propio Hyper‑V Manager y, a veces, herramientas de hardware propietarias. El reto es armar un stack de monitorización que:

  1. Detecte fallos de hardware (temperaturas, PSU, discos, conectividad SAN).
  2. Muestre el estado de los nodos del cluster (quórum, recursos, replicación).
  3. Informe la disponibilidad y el rendimiento de cada VM (CPU, RAM, discos, eventos de Live Migration).
  4. Envíe alertas accionables a los canales habituales (correo, Teams, Slack).

El problema no es exclusivo de un único sitio; cualquier entorno Hyper‑V con un cluster pequeño‑mediano necesita una solución que sea ligera, extensible y que no requiera licencias costosas.

Causa

Varias causas hacen que la monitorización sea fragmentada:

  • API dispares – Hyper‑V expone métricas a través de WMI/PowerShell, mientras que los equipos Lenovo ofrecen SNMP o APIs REST mediante XClarity. No existe un conector nativo que unifique ambas fuentes.
  • Falta de agente integrado – A diferencia de vCenter, Hyper‑V no incluye un agente de salud que envíe datos a un servidor central. Cada nodo necesita ser consultado individualmente.
  • Herramientas de gestión aisladas – Windows Admin Center (WAC) brinda una buena UI para el cluster, pero no genera alertas fuera del portal y carece de historial de métricas.
  • Política de costos – Las organizaciones que migran a Hyper‑V suelen buscar alternativas gratuitas o de bajo coste, descartando soluciones propietarias como System Center Operations Manager (SCOM).

El resultado es un “silencio” en la capa de monitoreo: los problemas de hardware pueden pasar desapercibidos hasta que una VM deja de responder, y viceversa.

Solución

Construir un stack de monitorización modular que combine:

  1. Windows Admin Center como punto de acceso rápido al cluster y a los nodos Hyper‑V.
  2. Integrador Lenovo XClarity (extensión para WAC o conector SNMP) para exponer hardware.
  3. Zabbix (u otra herramienta Open Source) como motor de recolección, almacenamiento histórico y generación de alertas.

Paso a paso

1. Desplegar Windows Admin Center fuera del cluster

Crear una VM dedicada (por ejemplo, Windows Server 2025 Core) y registrar los nodos del cluster. WAC ofrece extensiones para Hyper‑V, Failover Cluster y, opcionalmente, para XClarity. La ventaja es que la UI está aislada del plano de datos, evitando que una caída del cluster afecte la consola de gestión.

2. Conectar Lenovo XClarity

Instalar el Lenovo XClarity Integrator en la misma VM o en un contenedor. El integrador consume la API REST del Lenovo XClarity Administrator (XCA) y expone los sensores de hardware como objetos WMI que WAC puede visualizar. Si XCA ya está en producción, basta con habilitar la exportación SNMP y apuntar a Zabbix.

3. Configurar Zabbix como hub de métricas

  • Servidor Zabbix: VM Linux (CentOS/AlmaLinux) o contenedor Docker.
  • Agentes: Instalar zabbix-agent en cada nodo Hyper‑V y en la VM de WAC. Configurar los módulos system.run y system.cpu para ejecutar PowerShell remotos.
  • Plantillas: Utilizar la plantilla oficial Template OS Windows y añadir una plantilla personalizada Template Hyper-V. Esta incluye ítems como hyperv.vm.state, hyperv.vm.cpu.usage, hyperv.vm.memory.usage.
  • XClarity: Crear ítems SNMP que consulten OIDs de temperatura, estado de PSU y salud de discos. Si se usa el integrador, mapear los objetos WMI a ítems Zabbix mediante userparameter.

4. Definir triggers y acciones

Ejemplos de triggers útiles:

  • VM fuera de línea – last("hyperv.vm.state",#3)=0 → alerta crítica.
  • CPU de nodo > 85 % durante 5 min – avg("system.cpu.util[,idle]",5m)>85 → alerta de rendimiento.
  • Temperatura del chasis > 70 °C – last("xclarity.chassis.temp")>70 → alerta de hardware.

Configurar acciones que envíen notificaciones a Slack o Teams mediante scripts curl o la integración nativa de Zabbix.

5. Visualizar con dashboards

Zabbix permite crear dashboards combinados: un panel muestra el estado del cluster (quórum, recursos), otro lista VMs con sus métricas, y un tercero presenta sensores de hardware. Exportar los dashboards a PDF o incrustarlos en WAC mediante iFrames para una vista única.

Alternativas prácticas

Necesidad Opción ligera Opción con más detalle
Solo métricas de VM PowerShell + CSV + Grafana (Telegraf) Zabbix + Plantilla Hyper‑V
Integración SNMP PRTG (versión gratuita) Nagios + plugins SNMP
Dashboard unificado WAC + XClarity UI System Center Virtual Machine Manager (SCVMM) + SCOM (si el presupuesto lo permite)

Escoger la alternativa depende del número de nodos, del nivel de detalle requerido y del presupuesto de licencias.

Cuándo aplicar esta solución

Ideal cuando:

  • El cluster tiene entre 2 y 10 nodos y no justifica SCOM.
  • Se necesita historial de métricas (CPU, memoria, I/O) para capacity planning.
  • Existe infraestructura Lenovo con XClarity ya desplegada.
  • Se prefiere una solución mayormente Open Source y con bajo coste de mantenimiento.

No recomendado si:

  • El entorno supera 20 nodos y la carga de métricas es muy alta; en ese caso SCOM o una solución basada en Prometheus/Grafana puede escalar mejor.
  • No se dispone de personal con conocimientos de PowerShell/WMI; la curva de aprendizaje de Zabbix puede ser un obstáculo.
  • Se requiere integración profunda con Azure Monitor o AWS CloudWatch; otras plataformas pueden ofrecer conectores nativos.

Código

# Instalar agente Zabbix en un nodo Hyper‑V (Windows Server 2025)
Invoke-WebRequest -Uri "https://cdn.zabbix.com/zabbix/binaries/stable/6.4/6.4.0/zabbix_agent-6.4.0-windows-amd64-openssl.msi" -OutFile "$env:TEMP\zabbix_agent.msi"
Start-Process msiexec.exe -ArgumentList "/i `"$env:TEMP\zabbix_agent.msi`" /quiet SERVER=10.0.0.5 HOSTNAME=`$(hostname) LOGTYPE=file" -Wait

# Añadir ítem de PowerShell para obtener estado de VMs
Add-Content -Path "C:\Program Files\Zabbix Agent\zabbix_agentd.conf" -Value 'UserParameter=hyperv.vm.state[*],powershell -NoProfile -Command "Get-VM -Name $1 | Select-Object -ExpandProperty State"'

# Reiniciar agente
Restart-Service zabbix-agent

Verificación

  1. Comprobar conectividad – Desde el servidor Zabbix, ejecutar zabbix_get -s <IP_nodo> -k hyperv.vm.state[NombreVM]. El resultado debe ser Running, Off o Paused.
  2. Validar métricas en el dashboard – Abrir el dashboard creado y confirmar que aparecen gráficos de CPU, memoria y temperatura.
  3. Probar trigger – Apagar una VM y esperar a que el trigger VM fuera de línea genere una alerta en Slack.
  4. Revisar histórico – En Zabbix, seleccionar la VM y verificar que el historial de los últimos 24 h contiene valores coherentes.

Notas adicionales

  • Seguridad – Configurar el agente Zabbix para usar TLS y limitar la IP del servidor en el firewall de Windows.
  • Rendimiento – Ajustar el intervalo de recolección a 60 s para métricas de hardware y a 300 s para métricas de VM; evita sobrecargar la red.
  • Escalabilidad – Si se añaden más nodos, replicar la configuración del agente mediante Group Policy o DSC (Desired State Configuration).
  • Mantenimiento – Actualizar la plantilla Hyper‑V cada vez que Microsoft añada nuevos contadores de rendimiento; los cambios suelen publicarse en el repositorio de Zabbix.
  • Documentación – Mantener un registro de los OIDs de XClarity y de los UserParameter en un repositorio Git; facilita la recuperación tras una reinstalación.