Error MCE en Proxmox: el aviso que apuntaba a la RAM

Un error MCE en Proxmox significa que el procesador ha notificado a Linux una condición de fallo de hardware, por lo que conviene investigarlo, aunque no implique de forma automática que la CPU esté muriendo o que la memoria RAM sea inservible. Si lo ignoras, pierdes un aviso temprano y acabarás dando palos de ciego más adelante.

Un incidente ocurrido en un homelab en agosto de 2026 muestra cómo se desarrolla esta situación. Un Dell OptiPlex 5080 de 2020 con 32 GB de RAM llevaba tiempo ejecutando Proxmox VE con total fiabilidad cuando su capa de monitoreo empezó a registrar Hardware Error: Machine check events logged. El host seguía funcionando lo bastante bien como para que el aviso pudiera haberse descartado sin más como otra línea ruidosa del registro.

Descartarlo habría sido un error. Tras apagar el equipo, limpiarlo y reasentar la memoria RAM, la máquina empezó a mostrar códigos LED relacionados con la memoria durante el arranque. Al sustituir los cuatro módulos DDR4 originales de 8 GB por otro juego de cuatro módulos de 8 GB, el equipo volvió a iniciar con normalidad, y aquel oscuro mensaje de comprobación de la máquina se convirtió en una pista sólida para resolver el problema.

¿Qué significa realmente un error MCE en Proxmox?

Una MCE, o Machine Check Exception, es un error de hardware notificado a través de la arquitectura de comprobación de la máquina del procesador. La documentación del kernel de Linux describe estos eventos como informes de anomalías internas de hardware detectadas por la CPU. Los errores corregidos a menudo solo se registran, mientras que los errores no corregidos más graves pueden desencadenar acciones de recuperación más drásticas.

El mensaje en sí no constituye un diagnóstico. Una excepción de este tipo puede originarse en distintos subsistemas de hardware, y su significado depende de la CPU, del banco de machine check y de los detalles del evento. El aviso Machine check events logged indica que algo ocurrió por debajo de la capa habitual de aplicaciones, lo cual dista mucho de ser una orden para comprar un procesador nuevo.

Aquí es donde la resolución de problemas suele torcerse en un homelab. Una VM puede estar en perfecto estado, el almacenamiento seguir montado y el panel de Proxmox mostrar un aspecto impecable mientras el kernel del host registra indicios de que el hardware que sostiene esas cargas tiene problemas.

Toma el error MCE como la señal de partida para recopilar evidencias. Revisa el diario del kernel, los detalles de eventos de hardware, los datos del firmware, el comportamiento de la memoria, las temperaturas, la salud del almacenamiento y cualquier indicador físico de diagnóstico del sistema antes de decidir qué componente está fallando.

¿Por qué este aviso apuntó hacia la memoria RAM?

La excepción MCE no señalaba un módulo DIMM concreto, pero la investigación posterior aportó pruebas independientes que convirtieron a la memoria en la principal sospechosa. En cuanto se apagó el sistema, se limpió y se volvió a encajar la RAM, el OptiPlex empezó a hacer parpadear los LED de arranque que indican problemas de memoria.

La máquina contaba con cuatro módulos DDR4 de 8 GB, sumando 32 GB en total. Probar distintas combinaciones de ranuras no eliminó el aviso de memoria en el arranque. Al instalar un juego de repuesto de cuatro módulos, el host arrancó de nuevo sin reproducir el fallo.

Esa secuencia aporta mucha más información que un simple «MCE significa RAM defectuosa». El aviso dio la alarma, los diagnósticos físicos acotaron la búsqueda y cambiar los componentes modificó el resultado. Aun así, conviene probar los módulos originales uno por uno antes de dar por inservible cada módulo. Una ranura dañada, un mal contacto, la pista del controlador de memoria o un único módulo roto pueden hacer que un conjunto entero de cuatro módulos parezca culpable.

La documentación de RAS de Linux insiste en una idea similar: detectar un error de hardware es solo una parte del trabajo, porque atribuirlo al componente reemplazable más pequeño puede ser difícil, en particular con la memoria. Cruza las evidencias con calma y evita decisiones apresuradas.

¿Por qué fue útil el monitoreo adicional en un homelab Proxmox?

La capa de monitoreo no arregló nada por sí misma, pero sacó a la superficie una señal de hardware con tiempo suficiente para que el siguiente paso de diagnóstico fuera evidente.

Eso importa mucho en un homelab. La mayoría de los usuarios pasa el tiempo revisando el estado de las VM, el de los contenedores, la carga de CPU, el uso de RAM, las tareas de backup y el espacio en disco. Esas pantallas te indican si las cargas de trabajo responden, pero no siempre te advierten de que el host físico está empezando a fallar.

El debate en torno a este incidente volvió una y otra vez sobre esa carencia. Un usuario explicó que en su momento instaló ProxMenux solo para ver temperaturas de CPU que la interfaz estándar que utilizaba no mostraba. Con el tiempo, esa visibilidad adicional resultó de gran ayuda para consultar registros, acceder al terminal, monitorear desde el teléfono y gestionar alertas.

La documentación actual de hardware de ProxMenux sigue ese mismo principio. Recopila datos del host mediante herramientas estándar de Linux y muestra módulos de memoria, sensores térmicos, discos, GPU, dispositivos PCI, ventiladores, información del SAI y otros parámetros físicos del host cuando el hardware lo permite.

No todo usuario de Proxmox necesita esa herramienta concreta, pero un host de virtualización sí precisa cierta supervisión por debajo de la capa de hipervisor, especialmente cuando una única máquina física sostiene multitud de servicios.

Para disponer de un contexto de plataforma más amplio, el centro de Proxmox de Mr.PlanB analiza el catálogo actual de Proxmox y las decisiones operativas que implica su gestión.

¿Hace falta ProxMenux específicamente para detectar problemas de hardware?

No. Lo que necesitas es algo que capte señales útiles del hardware y te las haga llegar; qué aplicación concreta lo haga resulta secundario.

Varios participantes en la conversación propusieron alternativas. Algunos preferían Netdata. Otros mencionaron Pulse para el monitoreo de Proxmox, integraciones con Glances, Zabbix, procesar registros del kernel directamente y crear alertas personalizadas. Un responsable de homelab describió un informe matutino generado por IA que analizaba los registros del clúster y destacaba comportamientos anómalos de almacenamiento para revisarlos más tarde.

Estas soluciones varían en complejidad pero resuelven la misma necesidad: los registros en bruto solo sirven de ayuda si alguien los lee, comprende por qué son importantes y los relaciona con un componente físico antes de que el host se caiga.

Zabbix surgió en la charla porque puede situarse por encima de los hosts individuales y centralizar la supervisión de entornos más extensos. Si tu montaje se parece más a eso, la descripción general de monitoreo con Zabbix explica la arquitectura y las ventajas e inconvenientes de una plataforma de supervisión global frente a un complemento centrado en el host.

La entrega efectiva de las alertas importa más que el panel visual. Una gráfica perfecta que nadie abre en tres semanas vale menos que una notificación modesta que te llega cinco minutos después de que el kernel empiece a registrar un nuevo fallo de hardware.

¿Indica cada MCE que el servidor está a punto de fallar?

No, y la propia conversación ofreció un contraejemplo. Un usuario relató que su servidor llevaba años registrando eventos MCE sin que se encontrara la causa raíz, manteniéndose en marcha a través de varias actualizaciones y reinicios. Otro comentarista argumentó que los mensajes de comprobación en hardware antiguo no deben catalogarse de inmediato como fallos críticos. Eso encaja con la distinción que hace el kernel entre estados de machine check corregidos y no corregidos.

Por tanto, la forma de reaccionar depende del contexto. Un evento aislado y corregido que no vuelve a repetirse, sin síntomas en las aplicaciones, sin fallos de memoria, sin errores de disco ni avisos físicos en el chasis, es un escenario muy distinto a una serie continuada de avisos que coincide con fallos al arrancar o alertas específicas de un componente.

La frecuencia también cuenta. Un solo evento es motivo para anotar lo sucedido. Varios eventos repetidos marcan una tendencia. Una excepción MCE seguida de LED de diagnóstico de memoria y una posterior recuperación tras cambiar la RAM constituye una cadena de indicios mucho más concluyente.

Cambiar piezas de hardware tras la primera alerta MCE supone malgastar dinero, e ignorar el aviso es una mala costumbre: utiliza la notificación para decidir qué inspeccionar a continuación.

¿Qué conviene comprobar tras ver un MCE en Proxmox?

Conserva primero las evidencias antes de que reinicios sucesivos entierren el contexto. Revisa el diario del kernel alrededor del incidente, anota la marca de tiempo y busca mensajes cercanos sobre memoria, EDAC, PCIe, almacenamiento, temperaturas o bancos de comprobación de la CPU.

Compara después las evidencias de software con el comportamiento físico del hardware. Comprueba los LED de diagnóstico del fabricante, los registros de eventos del firmware si existen, las temperaturas, el encaje de la memoria, modificaciones recientes en los componentes, la estabilidad eléctrica y si el problema aparece bajo una carga de trabajo concreta. Si sospechas de la memoria, prueba los módulos de forma metódica en lugar de alternar combinaciones al azar hasta que el equipo decida arrancar.

Piensa también en la recuperación. Si un host pequeño asume el DNS, el enrutamiento, el almacenamiento, la domótica u otros servicios de los que dependes a diario, disponer de componentes de repuesto vale mucho más que su precio de reventa. El usuario del caso tenía casualmente a mano otros cuatro módulos DDR4 de 8 GB, lo que convirtió lo que podría haber sido una larga parada en una resolución rápida.

Varios usuarios de homelab bromearon con incredulidad ante esa suerte, pero otro participante defendió con acierto el valor de los recambios: esperar varios días a que llegue un pedido de memoria resulta muy distinto cuando el servidor caído aloja servicios que tu familia necesita. Al final, contar con repuestos depende del tiempo de recuperación que estés dispuesto a tolerar.

Una regla práctica: investiga una vez y automatiza para siempre

Cuando un host Proxmox notifique una excepción MCE, registra el evento, crúzalo con otras pruebas de hardware, evalúa el componente sospechoso y deja configurado el sistema para que este tipo de aviso te llegue de forma automática la próxima vez.

Para un nodo de pruebas prescindible, revisar de vez en cuando a mano puede ser suficiente. Para un host que sostiene servicios que echarías de menos en cuestión de una hora, las alertas a nivel de hardware, el monitoreo de registros y un pequeño plan de recuperación representan un seguro muy económico.

La herramienta de monitoreo no detectó «RAM defectuosa» por sí sola. Entregó un aviso del kernel poco común con la antelación necesaria para que el administrador abordara el problema con método, antes de quedarse con un host inoperativo y sin pistas sobre por dónde empezar.