Cambio de kernel Proxmox¶
Revisado el 20 de octubre de 2026 contra la ayuda de qm shutdown del nodo.
Este procedimiento es manual. No autoriza un reboot durante una investigación
ni sustituye los contratos de almacenamiento, HA y mantenimiento.
El 16 de mayo se registró un apagado de pmx50 atascado en pve-guests durante
más de diez minutos y una intervención física posterior. No se conserva aquí
una prueba de su causa. Los resets por watchdog del 20 de octubre son incidentes
distintos: evidencia y límites.
Preparación y propietarios¶
Antes de una ventana autorizada, consultar el inventario vivo desde un nodo:
pvesh get /cluster/resources --type vm --output-format json
ha-manager status
proxmox-boot-tool kernel list
uname -r
Confirmar nodo afectado, propietarios actuales, dependencias, recursos HA, trabajos activos y capacidad real del destino. No asumir que HAOS171, PBS186 ni los LXC siguen en el nodo de una revisión histórica. A 20 de octubre, HAOS171 está en pmx51 y VM208/PBS186 en pmx50; esto no es un inventario permanente.
No entrar en mantenimiento HA ni migrar automáticamente: hay recursos con restricciones de nodo y el margen N-1 sigue ajustado. El diseño detallado de transiciones de mantenimiento explica escritores, clientes NFS y el loop de PBS situado en el host. La consola mantiene deshabilitadas las transiciones L2–L4. Resolver esas condiciones antes de ejecutar una intervención de host.
Identificar el filesystem y la estrategia de recuperación reales antes de crear
snapshots. El dataset histórico zfs-ha/ROOT/pve-1 no es un nombre universal.
Un snapshot local del sistema no sustituye una copia externa ni la recuperación
de las aplicaciones y del NAS.
Apagado limpio del invitado¶
qm stop detiene la VM; no es el apagado limpio descrito en la versión anterior
de este runbook. qm shutdown solicita ACPI y espera al sistema invitado.
La ayuda instalada confirma --forceStop=0 como valor por defecto.
Sólo para VM208, después de comprobar su propietario actual, que no la gestiona HA y que sus tareas y escritores están drenados, ejecutar en ese propietario:
Continuar únicamente si figura stopped. Si vence el plazo o falla el apagado,
parar el procedimiento y estudiar el invitado; no convertir el timeout en
qm stop, --forceStop 1, --skiplock o un reset automático.
Para recursos registrados en HA, acordar y aplicar primero el estado deseado mediante el procedimiento HA correspondiente: un apagado aislado de la VM puede contradecirlo y provocar un nuevo arranque. No copiar el comando de VM208 a HAOS171 sin resolver su política y sus requisitos específicos.
Registrar los estados previos de los invitados para restaurar únicamente los que estuvieran ejecutándose. Drenar PBS y resolver sus mounts en el host, además de los restantes invitados afectados. Conservar una copia privada de configuración PVE y la versión del kernel previa mediante el mecanismo de backup existente.
Arranque del host y validación¶
Sólo tras completar las condiciones anteriores se ejecuta el reboot de la ventana planificada. No se ordenó ningún reboot al corregir este documento.
Después, desde el nodo recuperado:
Comprobar almacenamiento con su herramienta correspondiente; usar zpool status
sólo si realmente hay pools ZFS. Un error de checksum requiere investigación y
plan de recuperación: no desencadena scrub, reparación ni limpieza automática.
En particular, no ejecutar scrub Btrfs en TerraMaster por sus antecedentes NFS.
Restaurar los estados previos con los propietarios y mecanismos HA correctos.
Validar quorum, mounts, servicios y copias; un estado running no demuestra salud
funcional. No despertar servicios bajo demanda sólo para comprobar una URL.
Recuperación si el host no vuelve¶
pmx50 no tiene IPMI acreditado. No encadenar reintentos de reboot ni cortes de corriente remotos: conservar la última evidencia y preparar acceso físico o KVM. Un power-cycle es una intervención de recuperación separada, con riesgo para escritores y almacenamiento; no es un paso automático de este procedimiento.
Proxmox puede conservar kernels anteriores. Verificar los que están instalados y su compatibilidad antes de elegir uno; no asumir que hay exactamente dos. Un cambio de kernel fijado y un nuevo arranque requieren otra decisión de mantenimiento y las mismas condiciones de drenaje. No se ha cambiado el kernel ni su selección durante esta revisión.