Una actualización del kernel de SLES aún puede mostrar "se requiere reiniciar" después de habilitar Live Patching. Esto no significa automáticamente que la configuración haya fallado: los parches en vivo cubren solo las correcciones que SUSE puede ofrecer de forma segura para el kernel que se está ejecutando actualmente, mientras que un kernel de reemplazo o las correcciones que no se pueden aplicar mediante Live Patching aún requieren un reinicio. La guía de SUSE SLES 16.0 Kernel Live Patching, publicada el 8 de octubre de 2026, ofrece una ruta de configuración más reciente: instalar el kernel_livepatchingpatrón bajo la suscripción estándar de SLES. SLES 15 SP7 utiliza una extensión de Live Patching independiente y el lp_slespatrón.
Siga el procedimiento correspondiente a su versión, aplique las actualizaciones mediante el flujo de trabajo habitual de paquetes de SUSE y verifique el parche activo klp -v patches. Estos pasos presuponen un host SLES registrado con acceso a sus repositorios de actualización compatibles.
Identifique la versión y el kernel en ejecución. Ejecute:
cat /etc/os-release
uname -r
uname -m
Registre la versión de SLES, la versión del kernel y la arquitectura. Los paquetes de parches en vivo coinciden con una revisión específica del kernel, por lo que un paquete para un kernel en ejecución diferente no demuestra que el kernel activo esté parcheado. Los comandos a continuación utilizan las instrucciones actuales de SLES 16.0 y SLES 15 SP7; no copie un patrón o ruta de activación específicos de una versión a una versión diferente.
En SLES 16.0, instale el patrón incluido. La guía actual de SUSE indica que Kernel Live Patching está incluido en la suscripción estándar de SLES. Instale su patrón:
sudo zypper install -t pattern kernel_livepatching
Si sus repositorios contienen un parche en vivo válido para el kernel instalado, el gestor de paquetes lo selecciona durante la instalación; SUSE documenta que el kernel se parchea en vivo como parte de este proceso. No se requiere ningún código de registro adicional para la aplicación de parches en vivo en este procedimiento de SLES 16.0.
En SLES 15 SP7, active primero la extensión. Esta versión requiere suscripciones activas a SLES y SLES Live Patching. Consulte la lista de extensiones disponibles y utilice el comando de activación exacto específico de la arquitectura que se muestra:
sudo SUSEConnect --list-extensions
sudo SUSEConnect -p sle-module-live-patching/15.7/x86_64 -r LIVE_PATCHING_REGISTRATION_CODE
El segundo comando es un ejemplo para x86_64. Reemplácelo con la ruta exacta del producto que se muestra en su propia --list-extensionssalida y proporcione el código de registro de Live Patching válido. Luego, instale el patrón requerido:
sudo zypper install -t pattern lp_sles
La activación por sí sola no instala los patrones ni los paquetes; complete ambos pasos antes de esperar los paquetes de parches en vivo desde los canales de actualización.
Aplique actualizaciones periódicas del sistema. Los parches en vivo del kernel llegan como paquetes a través del mecanismo de actualización regular. Para una ejecución manual de parches, utilice el mismo flujo de trabajo de mantenimiento aprobado que para el resto del host, por ejemplo:
sudo zypper refresh
sudo zypper patch
Revise el plan de paquetes antes de confirmarlo, especialmente en sistemas de producción. Un paquete de parches en vivo puede actualizar las correcciones elegibles para el kernel en ejecución sin reiniciar las cargas de trabajo, pero la misma transacción de actualización también puede ofrecer un nuevo paquete base del kernel. La instalación de dicho paquete aún puede generar una recomendación de reinicio. Los parches en vivo son acumulativos para su revisión de kernel objetivo; no reemplazan el mantenimiento habitual del kernel.
Compruebe si hay algún parche activo. Una vez finalizada la actualización, revise los detalles del parche:
sudo klp -v patches
SUSE documenta este comando para comprobar el estado de los parches y ver las vulnerabilidades (CVE) o defectos corregidos por el parche activo. Confirme que el parche listado corresponde al kernel en ejecución registrado en el paso 1. Un paquete de parche inicial o semilla puede no contener correcciones; prepara esa revisión del kernel para futuros parches. Su sola presencia no significa que se haya aplicado una corrección de seguridad específica.
Solucione problemas de estado vacío o incorrecto. Compruebe si existe un paquete de parches en vivo para el kernel en ejecución y si hay datos del ciclo de vida disponibles:
sudo zypper se --details 'kernel-livepatch-*'
sudo zypper lifecycle
Para las fechas del ciclo de vida, SUSE indica que el lifecycle-data-sle-module-live-patchingpaquete debe estar instalado. Si no existe un paquete de parches para el kernel en ejecución, confirme que los repositorios o canales de Live Patching correctos estén habilitados y que la corrección correspondiente sea apta para la aplicación de parches en vivo. No infiera un fallo de una lista de parches vacía si no se ha publicado ninguna actualización que cumpla los requisitos.
Programa el reinicio que requiere una actualización completa del kernel. SUSE no puede convertir todas las correcciones en parches en vivo; algunos cambios requieren reemplazar estructuras de datos del kernel o, de otro modo, no se pueden aplicar de forma segura en tiempo de ejecución. Mantén las actualizaciones normales del kernel en tu plan de mantenimiento y reinicia cuando la actualización lo requiera. Evita ocultar los avisos de reinicio bloqueando indefinidamente los paquetes del kernel: esto pospone las correcciones completas del kernel en lugar de aplicarlas en vivo.
Para una ventana de mantenimiento sin reinicio, proceda únicamente cuando la actualización contenga un paquete de parches en vivo compatible con el kernel en ejecución y su política de cambios lo permita. Considere una actualización completa del paquete del kernel como pendiente hasta que el host haya arrancado con el nuevo kernel.
La comprobación se realiza correctamente cuando klp -v patchesse identifica la información de parches en vivo activa para el kernel mostrado por uname -r, y la corrección esperada aparece en los detalles del parche. El host debería permanecer con la misma versión del kernel en ejecución, ya que no se produjo ningún reinicio. Si el gestor de actualizaciones aún solicita un reinicio, compruebe si instaló un nuevo kernel base o una corrección fuera del alcance de Live Patching; esta solicitud es un requisito de mantenimiento, no algo que el comando live-patch status pueda cancelar.
Configure la ruta de Live Patching correcta para SLES 16.0 o 15 SP7, aplique las correcciones del kernel que cumplan los requisitos y confirme qué está activo sin confundirlo con una actualización del kernel que requiera reiniciar el sistema.
SLES 15 SP5 puede migrar en línea a SP6, pero cada nodo debe reiniciarse. Utilice una actualización progresiva probada o una transición azul-verde para mantener las cargas de trabajo accesibles.
Cree, refine y verifique un perfil de AppArmor con privilegios mínimos en SLES 15 SP7, con una nota clara sobre la configuración predeterminada de SELinux en SLES 16.
Utilice el perfil STIG compatible con SUSE para analizar SLES 15, probar la remediación, revisar los hallazgos restantes y conservar la evidencia de la evaluación.
Para rastrear una conexión fallida a Cockpit, utilice DNS, el puerto 9090, el socket systemd, firewalld, TLS y la configuración de inicio de sesión, siguiendo las directrices actuales de SUSE.
Cree una conexión Ethernet redundante en SLES 15 con YaST y Wicked, configure la agregación de enlaces activo-pasivo y verifique ambos puertos y la conmutación por error.
Convierta un sistema SLES 15 existente en un perfil AutoYaST revisado, valídelo y utilícelo para implementar un servidor de prueba con menos pasos manuales.
Instale las herramientas SLES 15 KVM y libvirt, habilite el servicio de host correcto y configure las máquinas virtuales seleccionadas para que se inicien después de un reinicio.
Utilice las tareas de systemd y el registro de arranque anterior para localizar un servicio lento, un punto de montaje o una dependencia de almacenamiento, y luego corríjalo sin enmascarar la causa.
Utilice firewall-cmd para inspeccionar la zona activa, permitir HTTP de forma segura, preservar el acceso SSH y verificar que la regla se mantenga tras una recarga en SLES 15.
