pmx50: observación del peer tras nueva alerta de reinicio¶
20 de octubre de 2026, 02:14:52 CEST / 00:14:52 UTC. Root comunicó un reinicio no ordenado de pmx50, identificado inicialmente como cuarto incidente, con nuevo boot ID <REDACTED_UUID>. Ese boot ID procede de Root, no de la lectura del peer que se documenta aquí.
Una única sesión SSH de sólo lectura a pmx2, con confianza de host existente, consultó /cluster/resources --type vm mediante pvesh y filtró en RAM exclusivamente id, node y status. Se leyeron boot ID/uptime de pmx51 y journals de los últimos diez minutos, limitados a 45 entradas corosync y 25 de cada unidad HA. No se consultaron configuraciones completas, guests, aplicaciones ni pmx50 directamente. Sin failover, tuning, reinicios ni recuperación manual.
Estado observado¶
La API devolvió 28/28 guests running: ocho en proxmox (pmx50) y veinte en proxmox2 (pmx51).
| Nodo observado | IDs runtime según API | Running |
|---|---|---|
| pmx50 | 186, 208, 219, 251, 270, 280, 281, 305 | 8/8 |
| pmx51 | 100, 110, 123, 155, 171, 172, 200, 204, 212, 213, 214, 215, 216, 217, 218, 220, 271, 301, 302, 303 | 20/20 |
Los IDs 171 y 208 son QEMU; los demás son LXC. PBS186, VM208 y Caddy270 estaban registrados running en pmx50. Maint212, observa217, CT218, Jellyfin220 y Caddy271 estaban running en pmx51. running es estado de infraestructura informado por API, no prueba de login, aplicación sana, montaje correcto, backups ni restauración. No se acredita un failover ni una migración por esta lista.
pmx51 conservaba boot ID <REDACTED_UUID> y uptime 15.360,57 s, unas 4 h 16 min. No aparece un reinicio reciente del peer en esa observación.
Dos episodios de pérdida de enlace retenidos¶
Los journals seleccionados cubren los diez minutos previos a cada consulta realizada alrededor de las 02:14:53 CEST. Retuvieron dos episodios, que no deben confundirse con prueba de dos reinicios físicos:
| Evento del peer | Primer episodio, CEST | Segundo episodio, CEST |
|---|---|---|
| KNET host 1 link 0 down / sin enlaces activos | 02:10:52,955 | 02:13:19,770 |
| Token no recibido durante 7.500 ms | 02:10:55,801 | 02:13:21,855 |
| Token timeout 10.000 ms, nueva configuración | 02:10:58,301 | 02:13:24,355 |
| Membership deja host 1 | 02:11:10,328 | 02:13:36,357 |
| CRM proxmox online → unknown | 02:11:22,229 | 02:13:48,262 |
| Membership incorpora host 1 | 02:11:36,608 | 02:13:56,685 |
| CRM proxmox unknown → online | 02:11:42,256 | 02:13:58,282 |
La primera pérdida de enlace hasta reincorporación de membership duró aproximadamente 43,65 s; la segunda, 36,91 s. Se retuvieron mensajes de espera del Qdevice y membership reducido a nodo 2; no se infiere pérdida de quorum sin su estado explícito. Corosync volvió a registrar sincronización de servicio completa en ambos episodios.
CRM devolvió cuatro transiciones de estado indicadas arriba; LRM no devolvió entradas en la ventana. No se retuvo una orden de fencing ni de traslado en estas unidades y límites. La ausencia de un mensaje en esta selección no descarta eventos fuera de ventana/unidad ni pérdidas de journal.
Resultado: los 28 guests figuraban running tras la alerta, y el peer acredita dos interrupciones diferenciadas de conectividad/membership. La causa y el número exacto de boots de pmx50 requieren correlación con boot IDs y evidencias del host que recoge Root. No se atribuye causalidad a la recarga de reglas anterior ni a otro trabajo contemporáneo.
Evidencia y límites¶
Evidencia filtrada local privada, modo0600 y fsync de archivo/directorio: ~/.local/state/homelab-incident-evidence/fourth-peer-20261020T001454Z.json. Incluye únicamente los metadatos autorizados y mensajes de esas unidades; sin secretos ni configuraciones completas. Hash SHA256: <REDACTED>.
Las tres consultas journal y la API terminaron con rc0. Corosync devolvió 43 entradas de un máximo45; CRM cuatro de un máximo25; LRM cero de un máximo25. No hubo nuevas lecturas tras esta captura ni acciones de recuperación.