{"id":11861,"date":"2026-05-26T21:46:28","date_gmt":"2026-05-26T19:46:28","guid":{"rendered":"https:\/\/bitacora.eniac2000.com\/?p=11861"},"modified":"2026-05-26T21:54:55","modified_gmt":"2026-05-26T19:54:55","slug":"nuevo-servidor-de-virtualizacion-control-termico-avanzado-para-el-verano","status":"publish","type":"post","link":"https:\/\/bitacora.eniac2000.com\/?p=11861","title":{"rendered":"Nuevo servidor de virtualizaci\u00f3n \u2013 Control t\u00e9rmico avanzado para el verano"},"content":{"rendered":"
Esta entrada es la parte 7 de 7 de la serie Nuevo servidor de virtualizaci\u00f3n<\/a><\/div>\n

Hace ya un par de a\u00f1itos empec\u00e9 una serie sobre el nuevo servidor de virtualizaci\u00f3n<\/a> que tengo instalado en casa. En su momento, uno de los art\u00edculos de la serie estuvo dedicado a la reducci\u00f3n de los niveles de ruido<\/a>, aspecto clave para poder tener un servidor de tipo enracable en un entorno dom\u00e9stico. Ese art\u00edculo trataba de c\u00f3mo, gracias al proyecto iLO4 unlock, consegu\u00ed bajar el r\u00e9gimen de giro de los ventiladores del DL360p Gen8 del 50% al 19%, con lo que pasaba a ser viable tener un servidor de este tipo en un entorno dom\u00e9stico. Dos a\u00f1os despu\u00e9s, y cuando a\u00fan no hemos llegado al verano, he tenido que realizar algunas actuaciones para controlar esta velocidad de giro. Que es de lo que va este art\u00edculo.<\/p>\n\n\n\n

El problema: el verano y la escalada de ventiladores<\/h2>\n\n\n\n

El comando m\u00e1gico que me hab\u00eda funcionado durante dos a\u00f1os era fan pid lo 1200<\/code>, que permite al PID interno de la iLO bajar los ventiladores hasta aproximadamente un 18%. En invierno, con temperaturas ambiente de 20\u00b0C, el servidor se manten\u00eda silencioso sin problemas. Pero al llegar el verano, con el sensor inlet<\/em> (que mide la temperatura de entrada de aire) superando los 28\u00b0C, los ventiladores empezaban a escalar de forma descontrolada, llegando a alcanzar valores de hasta el 75% en la zona derecha del servidor (la que aloja el almacenamiento y las tarjetas PCIe). Y eso suena como un Mig 21 despegando.<\/p>\n\n\n\n

\"Escalada
Escalada de temperaturas de Santiponce, la habitaci\u00f3n del servidor y el sensor inlet <\/em>en la \u00faltima semana, en la parte superior. En la inferior, el % de velocidad de giro de los ventiladores<\/figcaption><\/figure>\n\n\n\n

El problema tiene una explicaci\u00f3n t\u00e9cnica interesante. El DL360p Gen8 tiene dos zonas f\u00edsicas de ventilaci\u00f3n independientes: los bloques 1-4 (izquierda, donde est\u00e1n las CPUs y la memoria) y los bloques 5-8 (derecha, donde est\u00e1n la controladora de discos y los slots PCIe). Cuando la temperatura sube, la iLO ventila ambas zonas de forma independiente, y resulta que la zona derecha es mucho m\u00e1s problem\u00e1tica: tiene componentes que generan calor de manera constante (como la controladora HD y la tarjeta de red) y que no responden al aire fr\u00edo de la misma forma que las CPUs.<\/p>\n\n\n\n

El servidor est\u00e1 ubicado en una habitaci\u00f3n que cuenta con aire acondicionado; durante el invierno y buena parte de la primavera y el oto\u00f1o el servidor puede estar perfectamente sin aire acondicionado y manteniendo niveles de giro de los ventiladores de entre el 18 y el 20%. Pero en verano (que cada vez es m\u00e1s largo, llega antes y se va m\u00e1s tarde) la cosa cambia. Me ve\u00eda obligado a hacer uso del aire acondicionado para mantener los ventiladores en niveles razonables, pero a costa de tener un coste energ\u00e9tico considerable. Y este a\u00f1o el \u00abverano\u00bb se ha adelantado, teniendo ya desde el 21 de mayo temperaturas que en Santiponce alcanzaban los 35\u00baC.<\/p>\n\n\n\n

An\u00e1lisis con inteligencia artificial: Claude como copiloto<\/h2>\n\n\n\n

Para abordar el problema decid\u00ed utilizar un enfoque diferente al habitual: trabajar codo a codo con Claude Code para analizar el problema y aplicar soluciones. Como ya he comentado en otras ocasiones, el uso de Claude Code como asistente de ingenier\u00eda<\/a> me permite ejecutar comandos SSH, leer APIs, monitorizar valores en tiempo real y proponer soluciones bas\u00e1ndose en los datos que obtiene directamente del servidor, actuando como un ingeniero de sistemas.<\/p>\n\n\n\n

Un detalle importante: durante gran parte del tiempo no tengo acceso f\u00edsico al servidor. Esto implica que cualquier error que cuelgue la iLO o fije los ventiladores en un valor incorrecto que requiera intervenci\u00f3n f\u00edsica me puede generar graves problemas. Esto es un condicionante clave para todo el proceso de an\u00e1lisis y prueba de soluciones. Implica que cada comando nuevo deb\u00eda ser validado antes de ejecutarse, teniendo la absoluta certeza de que no iba a causar efectos adversos o no previstos. Y obligaba a tomar un enfoque incremental y reversible.<\/p>\n\n\n\n

El proceso de an\u00e1lisis consisti\u00f3 en varias fases. En primer lugar, con mi agente de ingenier\u00eda, utilic\u00e9 Gemini y NotebookLM como fuentes de an\u00e1lisis documental, buscando referencias espec\u00edficas de uso de par\u00e1metros del parche de la iLO, modos de uso y funciones documentadas. Una vez obtenido el respaldo documental, con Claude establec\u00ed un plan de acci\u00f3n para implementar soluciones para la problem\u00e1tica, y por \u00faltimo us\u00e9 ChatGPT como adversario en funci\u00f3n de abogado del diablo, para buscar puntos d\u00e9biles y defectos en la aproximaci\u00f3n definida. El segundo paso fue usar Claude Code para acceder a los datos de los sensores a trav\u00e9s de la API Redfish de la iLO, procesarlos para identificar qu\u00e9 sensores estaban forzando la escalada de ventiladores. Llegados a este punto, el tercer paso fue hacer una propuesta de uso de par\u00e1metros adecuados para adecuar mi script<\/em> inicial de reducci\u00f3n de par\u00e1metros de los sensores al escenario veraniego, aplicarlos uno a uno via SSH, y monitorizar el efecto durante periodos de 30 a 60 minutos, con lecturas cada 2-5 minutos.<\/p>\n\n\n\n

Entendiendo el PID de la iLO<\/h2>\n\n\n\n

Antes de describir la soluci\u00f3n, merece la pena explicar c\u00f3mo funciona el control de ventiladores de la iLO4 una vez desbloqueado. El sistema se basa en un controlador PID (Proporcional-Integral-Derivativo) con varios par\u00e1metros por sensor:<\/p>\n\n\n\n

    \n
  • fan pid XX lo YYYY<\/code> \u2014 El valor m\u00ednimo de PWM (Pulse Width Modulation<\/em> o Modulaci\u00f3n por Ancho de Pulsos,que permite controlar cu\u00e1nta energ\u00eda reciben los ventiladores) que el PID puede solicitar. Con lo 1200<\/code>, los ventiladores pueden bajar hasta ~18% de su r\u00e9gimen de giro m\u00e1ximo. Existe un comando equivalente, fan pid XX hi YYYY<\/code>, que permite establecer el valor m\u00e1ximo para el PID.<\/li>\n\n\n\n
  • fan pid XX sp YYYY<\/code> \u2014 El setpoint<\/em>: la temperatura objetivo para cada sensor, en d\u00e9cimas de grado. El PID intenta mantener el sensor por debajo de este valor.<\/li>\n\n\n\n
  • fan p X max YY<\/code> \u2014 Un ceiling<\/em> (techo) de PWM para cada bloque de ventiladores. Limita la velocidad m\u00e1xima, independientemente de lo que el PID solicite. De igual manera, existe el fan p X min YY<\/code>, que establece un suelo para la velocidad del ventilador, no permitiendo que se baje de dicho nivel.<\/li>\n\n\n\n
  • fan t XX off<\/code> \u2014 Deshabilita un sensor del c\u00e1lculo PID. El hardware sigue monitoriz\u00e1ndolo para emergency shutdown, pero no influye en la velocidad de los ventiladores.<\/li>\n<\/ul>\n\n\n\n

    La f\u00f3rmula simplificada es: output = max(clamp(PID_output, pid_lo, pid_hi), pwm_min)<\/code>, con el resultado final limitado por fan p max<\/code>.<\/p>\n\n\n\n

    Un aspecto importante es que estos ajustes del PID son vol\u00e1tiles: se pierden cuando la iLO se reinicia o cuando el servidor arranca tras un corte de luz. Esto significa que es necesario establecer un mecanismo que los vuelva a aplicar autom\u00e1ticamente en cada arranque, algo que abordar\u00e9 m\u00e1s adelante.<\/p>\n\n\n\n

    Iteraci\u00f3n 1: Identificar los sensores problem\u00e1ticos<\/h2>\n\n\n\n

    El primer paso fue entender por qu\u00e9 la zona derecha escalaba tanto. Con el script <\/em>original s\u00f3lo realizaba un proceso iterativo para aplicar fan pid lo 1200<\/code> a los 53 sensores que tiene definida la iLO y tres sensores deshabilitados. Todos los dem\u00e1s sensores ten\u00edan sus setpoints <\/em>de f\u00e1brica de iLO, que en muchos casos eran bastante conservadores.<\/p>\n\n\n\n

    \"Listado
    Listado de sensores, su funci\u00f3n, valor actual y estado, y l\u00edmites de funcionamiento, tanto de alerta como cr\u00edtico. El servidor siempre estaba en valores alejados de los l\u00edmites, pero aun as\u00ed demandaba velocidades de giro muy altas<\/figcaption><\/figure>\n\n\n\n

    Mediante la API Redfish, extraje las temperaturas de los 42 sensores activos y las compar\u00e9 con sus umbrales de precauci\u00f3n (la temperatura a la que iLO genera una alerta). Pude descubrir que varios sensores estaban operando a un porcentaje muy alto de su setpoint <\/em>de f\u00e1brica, lo que hac\u00eda que el PID pidiera velocidades de ventilador muy altas para intentar enfriarlos, en concreto:<\/p>\n\n\n\n

      \n
    • 32-HD Cntlr Zone<\/strong>: 43\u00b0C con un SP de f\u00e1brica muy bajo \u2014 72% de SP, principal causante de la escalada en la zona derecha.<\/li>\n\n\n\n
    • 36-PCI 2 Zone<\/strong>: 40\u00b0C, otro sensor de la zona derecha que no baja por mucho que ventiles.<\/li>\n\n\n\n
    • 14-Chipset1 Zone<\/strong>: 42\u00b0C, sensor global que puntualmente lideraba la demanda.<\/li>\n\n\n\n
    • 33-34 PCI 1 Zone<\/strong>: sensores de un slot PCI-E vac\u00edo que estaban contribuyendo al c\u00e1lculo PID sin motivo.<\/li>\n<\/ul>\n\n\n\n

      Iteraci\u00f3n 2: Setpoints <\/em>por zona<\/h2>\n\n\n\n

      Durante las pruebas con Claude pude determinar que los niveles a los que los sensores empezaban a demandar velocidades de giro m\u00e1s elevadas eran sensiblemente m\u00e1s bajos que los niveles de precauci\u00f3n declarados, por lo que los ventiladores empezaban a escalar a\u00fan estando muy lejos de los niveles de precauci\u00f3n formales. Es una aproximaci\u00f3n prudente desde el punto de vista del fabricante, que prefiere quedarse muy lejos de los niveles de riesgo, pero que implica que los ventiladores se disparan a\u00fan en circunstancias donde podr\u00edan funcionar a baja velocidad.<\/p>\n\n\n\n

      La soluci\u00f3n fue asignar setpoints <\/em>personalizados a cada sensor, calibrados a partir de los umbrales de precauci\u00f3n reales de la iLO. La idea es sencilla: si el nivel de precacuci\u00f3n de un sensor est\u00e1 en 65\u00b0C y la temperatura real es de 43\u00b0C, podemos poner un SP de 64\u00b0C (98% del nivel de precauci\u00f3n) y el PID ver\u00e1 que el sensor est\u00e1 al 67% de su objetivo, en lugar de, por ejemplo, al 90% con el SP de f\u00e1brica. El PID pedir\u00e1 menos velocidad de ventilador.<\/p>\n\n\n\n

      Esto requiri\u00f3 ir sensor por sensor, consultando los valores de precauci\u00f3n en la web de la iLO, y calibrando cada SP entre el 85% y el 97% de dicho valor. Los sensores de la zona de almacenamiento, que son los m\u00e1s problem\u00e1ticos porque generan calor constante que no responde al caudal de aire, recibieron SPs m\u00e1s agresivos (97-98% del nivel de precauci\u00f3n). Los de las CPUs y memoria, que s\u00ed responden bien al aire fr\u00edo, mantuvieron SPs m\u00e1s conservadores (86-93%).<\/p>\n\n\n\n

      Adem\u00e1s, deshabilit\u00e9 del PID un total de 13 sensores que no aportaban informaci\u00f3n \u00fatil: el sensor de inlet <\/em>(no tiene sentido que el PID reaccione a la temperatura del aire de entrada), sensores de slots PCI vac\u00edos, sensores redundantes de la zona de salida del aire, y sensores declarados pero sin uso en mi modelo de servidor, que reportaban 0\u00b0C.<\/p>\n\n\n\n

      Iteraci\u00f3n 3: El ceiling <\/em>con fan p max<\/h2>\n\n\n\n

      Con los setpoints <\/em>calibrados, los ventiladores ya no escalaban descontroladamente, pero segu\u00edan subiendo m\u00e1s de lo deseable en verano cuando el aire acondicionado dejaba de funcionar, y la temperatura ambiental empezaba a subir. Descubr\u00ed que el PID, aunque mejorado, segu\u00eda pidiendo velocidades del 50-55% en la zona derecha cuando la temperatura de la habitaci\u00f3n sub\u00eda por encima de los 27\u00baC.<\/p>\n\n\n\n

      La soluci\u00f3n fue a\u00f1adir un ceiling<\/em> (techo) mediante fan p max 89<\/code> en los 8 bloques, lo que equivale a un 35% de velocidad. Este comando limita la salida m\u00e1xima del PID: por mucho que el controlador quiera subir los ventiladores, no pueden pasar del 35%. Es importante entender que fan p max<\/code> funciona como un techo, no como un bloqueo: si el PID quiere un 25%, los ventiladores van al 25%. Solo interviene cuando el PID pide m\u00e1s del 35%.<\/p>\n\n\n\n

      Una vez establecido el valor, estuve haciendo un proceso de monitorizaci\u00f3n bastante intensivo con Claude Code. Ten\u00eda la intuici\u00f3n de que un punto estable de giro pod\u00eda estar en torno al 30-35% de los valores de giro incluso en verano, pero era necesario verificarlo. As\u00ed que fui bajando estos valores progresivamente desde el 41% hasta el 24%, con varias horas de monitorizaci\u00f3n, y reportes tanto por consola como por Telegram. Y el punto \u00f3ptimo de estabilidad estaba en el 34%.<\/p>\n\n\n\n

      \"Captura
      Captura de pantalla de uno de los mensajes de Telegram, con el nivel de temperatura de los sensores con respecto a su l\u00edmite de precauci\u00f3n. Recib\u00eda estos mensajes cada 5 minutos<\/figcaption><\/figure>\n\n\n\n

      Un experimento interesante que tambi\u00e9n realic\u00e9 fue quitar el ceiling <\/em>temporalmente para ver qu\u00e9 ped\u00eda el PID realmente tras unas cuantas horas con el valor limitado al 35%. Los resultados fueron reveladores:<\/p>\n\n\n\n

      Bloque<\/th>Zona<\/th>Con ceiling (35%)<\/th>Sin ceiling<\/th><\/tr><\/thead>
      0 (Fan Block 1)<\/td>Izquierda – CPU<\/td>34%<\/td>56%<\/td><\/tr>
      7 (Fan Block 8)<\/td>Derecha – Storage<\/td>34%<\/td>94%<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

      Sin ceiling<\/em>, la zona derecha se dispar\u00f3 al 94%. El ceiling <\/em>es lo que mantiene este servidor silencioso en verano, pese a que los valores de los sensores nunca llegaron a escalar realmente a valores cercanos a los l\u00edmites de precauci\u00f3n.<\/p>\n\n\n\n

      Con estos resultados en mente, desarroll\u00e9 una nueva versi\u00f3n del script<\/em>, con las siguientes acciones:<\/p>\n\n\n\n