Novedades de Linux kernel 7.1 para servidores

Novedades de Linux kernel 7.1

Linux kernel 7.1 se publicó el 14 June 2026, nueve semanas después de 7.0. Para un usuario de VPS (virtual private server), los cambios relevantes se concentran en cuatro áreas: almacenamiento y sistemas de archivos, redes, gestión de memoria y control de procesos y contenedores. El resto de la versión corresponde principalmente a trabajos de escritorio y gráficos que un servidor sin interfaz gráfica nunca carga.

Primero hay que responder a otra pregunta. Es casi seguro que 7.1 no se está ejecutando en su servidor y no lo hará durante mucho tiempo. kernel.org no incluye 7.1 entre las versiones de soporte prolongado. A fecha de 11 August 2026, las ramas de soporte prolongado son 6.18, 6.12, 6.6, 6.1, 5.15 y 5.10, y todas las distribuciones de servidor principales se basan en una de ellas o en una rama que mantienen por su cuenta. La diferencia entre «novedades del kernel» y «novedades disponibles en su servidor» es de varios años, por lo que esta guía cubre ambos aspectos.

Qué kernel ejecuta actualmente su VPS

uname -r
uname -srm
systemd-detect-virt

uname -r muestra la versión del kernel en ejecución. En Ubuntu 24.04 aparece como 6.8.0-79-generic. La parte anterior al primer guion corresponde a la línea upstream. Todo lo que aparece después es el número de compilación propio de la distribución y no sigue en absoluto a upstream. El 6.8.0-79 de Canonical incluye miles de correcciones retroportadas desde kernels posteriores, por lo que no es el código que Linus etiquetó como 6.8 en marzo de 2024. Por eso, decir «mi kernel es antiguo» aporta menos información de la que parece. Las funciones son antiguas. Por lo general, las correcciones de seguridad no lo son.

systemd-detect-virt indica si puede cambiar el kernel. Muestra kvm en una máquina virtual completa, donde usted arranca su propia imagen del kernel y una actualización es una actualización real. Muestra lxc o openvz en la virtualización mediante contenedores, donde se comparte el kernel del host. En un plan de contenedores, uname -r muestra el kernel del proveedor; instalar un paquete del kernel no cambia nada que pueda arrancar, y ninguna función de esta versión estará disponible hasta que el proveedor reinicie el host con un kernel más reciente. Ejecute esta comprobación antes de planificar cualquier trabajo relacionado con el kernel.

[
  {
    "distro": "Ubuntu 26.04 LTS (7.0)",
    "releases_behind_7_1": 1,
    "notes": "GA kernel, shipped with the April 2026 release"
  },
  {
    "distro": "Ubuntu 24.04 LTS, HWE (6.17)",
    "releases_behind_7_1": 4,
    "notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
  },
  {
    "distro": "Debian 13 trixie (6.12)",
    "releases_behind_7_1": 9,
    "notes": "upstream longterm line, kernel.org projected EOL December 2028"
  },
  {
    "distro": "RHEL 10 and its rebuilds (6.12)",
    "releases_behind_7_1": 9,
    "notes": "Red Hat backports fixes into its own frozen 6.12 stream"
  },
  {
    "distro": "Ubuntu 24.04 LTS, GA (6.8)",
    "releases_behind_7_1": 13,
    "notes": "the default unless you install the HWE stack"
  },
  {
    "distro": "Ubuntu 22.04 LTS, GA (5.15)",
    "releases_behind_7_1": 26,
    "notes": "upstream longterm line, kernel.org projected EOL December 2026"
  }
]

Son 6 plataformas, y ninguna arranca 7.1. La más reciente es Ubuntu 26.04 LTS (7.0), que está 1 versiones upstream por detrás. La más antigua que sigue teniendo soporte está 26 versiones por detrás. El kernel GA predeterminado de Ubuntu 24.04 está 13 versiones por detrás, mientras que Debian 13 y RHEL 10 están 9 por detrás en la línea longterm 6.12. Contar versiones es una medida aproximada, porque ignora todo lo que las distribuciones retroportan, pero muestra la magnitud de la diferencia. Si está valorando cuál de estas opciones utilizar, la decisión entre una versión LTS y una versión intermedia en un servidor es el criterio subyacente a estas cifras.

Almacenamiento y sistemas de archivos en 7.1

7.1 permite generar y verificar T10 PI (información de protección) dentro del sistema de archivos, en lugar de hacerlo sólo en la capa de bloques, y añade compatibilidad flexible con la alineación T10. T10 PI son bytes adicionales asociados a cada bloque. Contienen una suma de comprobación y una etiqueta que identifica a qué bloque pertenecen los datos. Así, una escritura dirigida al bloque equivocado o incompleta se detecta en lugar de devolverse como datos válidos. El problema para un cliente de VPS es el hardware. El dispositivo debe exponer los metadatos de integridad, y un disco virtual normalmente no los expone.

ls /sys/block/vda/integrity/

En la mayoría de los discos de VPS, esto devuelve No such file or directory, porque la capa de bloques sólo crea el directorio integrity cuando el dispositivo registra compatibilidad con integridad. Ese error es la respuesta normal en este caso, no un fallo. Si quiere saber qué tipo de disco tiene realmente antes de seguir leyendo sobre las funciones de almacenamiento, primero debe comprobar si el disco del VPS es realmente NVMe, y la diferencia entre NVMe y un SSD SATA en un VPS explica por qué la respuesta cambia sus cifras.

Btrfs incorpora correcciones para la amplificación de escritura de copy-on-write bajo presión de memoria, además de un cambio que acelera el borrado del primer extent de un rango supervisado. El merge que lo introduce informa de un 10% más de rendimiento en la carga de trabajo de prueba. Su operación de apagado ya no está marcada como experimental. XFS mejora el vaciado de rangos puestos a cero y las búsquedas mediante iomap, y añade un puntero de escritura a la geometría de los grupos en tiempo real, como base para dispositivos zonificados. NTFS se reescribe por completo en esta versión, con compatibilidad total de escritura y una conversión a iomap. Esto es importante si alguna vez monta en su servidor una imagen de disco procedente de un equipo Windows.

Otros cambios menores de almacenamiento que conviene conocer: ublk, el controlador de bloques en espacio de usuario, incorpora E/S sin copia; io_uring incorpora comandos de paso directo SCSI; la compatibilidad con unidades auto-cifradas SED-OPAL incorpora el comando STACK_RESET y amplía el modo de usuario único; hay un nuevo controlador de caracteres fs-dax para dispositivos de acceso directo; y VFS amplía inode->i_ino de unsigned long a u64, lo que elimina el límite del número de inode en compilaciones de 32 bits. En los sistemas de archivos de red, el servidor NFS del kernel ahora puede firmar sus identificadores de archivo mediante una opción de montaje sign_fh, y el cliente CIFS incorpora O_TMPFILE.

Redes: arrendamiento de colas y lo que aporta a un contenedor

El cambio principal en redes es el arrendamiento de colas de hardware. Un dispositivo de red virtual ahora puede arrendar una cola vinculada a una cola real de un dispositivo de red físico y actuar como su proxy. Esto está pensado para los contenedores. Hasta ahora, un contenedor que necesitaba AF_XDP (address family express data path, el tipo de socket que entrega paquetes sin procesar al espacio de usuario sin copiarlos a través de la pila de red) tenía que recibir algo parecido al dispositivo completo. Con una cola arrendada, obtiene una cola de hardware, ejecuta AF_XDP y proveedores de memoria a velocidad nativa, y el host conserva el resto de la NIC. Esto se incorpora junto con la compatibilidad con AF_XDP en la ruta de copia cero de io_uring.

En el funcionamiento habitual, los sockets de sockfs ahora aceptan atributos extendidos user.*. Un socket AF_UNIX basado en una ruta ya heredaba la compatibilidad con xattr del sistema de archivos subyacente, pero un socket que sólo existía en sockfs no tenía esa capacidad. Ahora un proceso puede etiquetar un socket y un programa eBPF puede filtrar según esa etiqueta.

Se eliminan dos elementos. UDP-Lite desaparece porque no tenía usuarios. IPv6 ya no se puede compilar como módulo cargable: si se necesita IPv6, se compila dentro del kernel. Esto último no es visible en los kernels de ninguna distribución, porque las distribuciones habituales para servidores ya compilan IPv6 dentro del kernel.

Gestión de memoria: la tabla de swap está terminada

La reestructuración de swap llega a su tercera fase, que elimina el mapa de swap estático. El recuento de swap ahora se almacena directamente en la tabla de swap. El ahorro indicado es de aproximadamente el 30% de los metadatos estáticos de swap. Esta es memoria que el kernel reserva en proporción al tamaño del dispositivo de swap, independientemente de que se use swap. En términos absolutos, la reducción es pequeña en un archivo de swap pequeño y aumenta con el tamaño de swap configurado.

MGLRU (multi-generational least recently used, el algoritmo más reciente de recuperación de páginas) ahora puede comprobar el indicador young de las páginas por lotes en lugar de hacerlo una página cada vez. La cifra publicada con este cambio indica una mejora superior al 60% en un servidor Arm64 de 32 núcleos. El procesamiento por lotes aporta más ventajas cuando el coste por página es mayor. Por eso esa cifra se obtuvo en una máquina Arm grande. Si ejecuta un VPS Arm en lugar de uno x86, este es el cambio de 7.1 que más probablemente aparecerá en sus propias mediciones, aunque no a esa escala en sistemas de dos o cuatro núcleos.

También se incluyen la eliminación de las transferencias desde cgroups de memoria que están terminando, un menor consumo de CPU en los análisis de khugepaged y una refactorización importante de maple tree relacionada con la gestión de sus nodos grandes. No hay nada que configurar en estos cambios. Se perciben como una ligera reducción del tiempo de sistema.

Programadores: subprogramadores sched_ext y FRED habilitado de forma predeterminada

sched_ext, la clase de programador extensible que permite escribir un programador de CPU como un programa BPF y cargarlo durante la ejecución, llegó en 6.12. La versión 7.1 añade la estructura básica para los subprogramadores, de modo que un grupo de control pueda ejecutarse posteriormente con su propio programador. Lea esa frase con atención. La implementación no está terminada en 7.1 y, en particular, falta la ruta de encolado. Por tanto, esta versión prepara una función para una versión posterior; todavía no puede habilitarla.

Intel FRED (entrega flexible de retornos y eventos) queda habilitado de forma predeterminada en el hardware compatible. FRED sustituye la ruta heredada de entrega de eventos de x86 por otra más sencilla. Está disponible en el kernel desde 6.9, pero requería el argumento de arranque fred=on. Habilitarlo de forma predeterminada indica que el hardware comercial se ha probado lo suficiente. Las mediciones publicadas hasta ahora, de entre 4% y 7% en cargas con mucha E/S, proceden de pruebas de Phoronix en hardware cliente. No presuponga ese resultado en un servidor hasta medir su propia carga de trabajo.

La ejecución mediante proxy incorporó la migración del donante para acelerar al propietario remoto de un bloqueo. EEVDF recibió correcciones relacionadas con el desfase negativo. Además, el núcleo de temporizadores de alta resolución se reescribió de forma considerable. Son cambios que mejoran la latencia y que no se exponen mediante ningún archivo de configuración.

Nuevos controles de procesos y contenedores en clone3()

Se añadieron tres indicadores a clone3(). Cada uno cierra una deficiencia que los supervisores han corregido manualmente durante años. CLONE_AUTOREAP hace que el proceso hijo se recoja a sí mismo al salir. Así nunca se convierte en un proceso zombi a la espera de un proceso padre que quizá nunca llame a wait(). CLONE_NNP establece no_new_privs en el proceso hijo en el momento de crearlo. Esto elimina la ventana entre la llamada a clone y el momento en que el proceso hijo establece el indicador por sí mismo. CLONE_PIDFD_AUTOKILL vincula el ciclo de vida del proceso hijo al pidfd devuelto al proceso padre. Al cerrar el pidfd, el proceso hijo termina. De este modo, si un supervisor termina, no puede dejar procesos huérfanos en ejecución.

Los espacios de nombres de montajes recibieron un tratamiento similar. CLONE_EMPTY_MNTNS para clone3() y UNSHARE_EMPTY_MNTNS para unshare() crean un espacio de nombres de montajes vacío, en lugar de la copia completa habitual de los montajes del proceso padre, que después el runtime debe desmontar. FSMOUNT_NAMESPACE permite que fsmount() coloque un sistema de archivos directamente en un espacio de nombres nuevo. Los runtimes de contenedores han montado esta funcionalidad manualmente durante una década. Al hacerlo en una sola llamada, el runtime ya no parte de un espacio de nombres que contiene todos los montajes del host.

En el ámbito de la virtualización, guest_memfd ahora admite userfaultfd. Esto permite que un hipervisor gestione los fallos de página del invitado desde el espacio de usuario. KVM protegido en Arm incorporó compatibilidad con memoria anónima, aunque la propia integración indica que todavía no está preparada para producción.

Cuándo llegará el kernel 7.1 a su servidor

Fedora ya lo tiene. El repositorio de actualizaciones de Fedora 44 pasó a la serie 7.1 durante julio y agosto de 2026, porque Fedora cambia la base de su kernel a nuevas ramas estables dentro de una misma versión. Arch y openSUSE Tumbleweed lo tienen por el mismo motivo. Esos sistemas sirven para hacer pruebas, no para ejecutar servicios.

El resto debe esperar, y esa espera es intencionada. Debian 13 se publicó con 6.12 y permanece en 6.12 durante todo el ciclo de vida de la versión, con las correcciones retroportadas a esa rama. RHEL 10 se publicó con 6.12.0 y aplica el mismo enfoque. Ubuntu 26.04 LTS se publicó con 7.0 en abril de 2026. Ubuntu 24.04 LTS tiene una pila de habilitación de hardware que incorpora en la versión LTS un kernel más reciente de versiones posteriores de Ubuntu. Esa pila está en 6.17 desde la versión de punto 24.04.4 y está previsto que pase a 7.0 con 24.04.5 el 27 de agosto de 2026. Una versión de punto no es una versión nueva de Ubuntu. Es la misma 24.04 con todas las actualizaciones acumuladas desde su publicación incluidas en nuevos medios de instalación. Por eso, qué cambia 24.04.5 en un servidor que ya actualiza es la rama del kernel HWE y poco más.

Aquí es donde suele producirse el error. Una pila HWE salta al kernel que incluya la versión intermedia más reciente, por lo que puede omitir por completo una rama de upstream. 7.0 está en una versión LTS de Ubuntu. 7.1 puede no convertirse nunca en la base de una versión LTS, porque la versión intermedia posterior incluirá una rama más reciente. Lo que llega a su LTS desde 7.1 son las correcciones, retroportadas a la rama que esté utilizando. La mayoría de las funciones nuevas no se incorporan.

Si necesita un kernel más reciente en un servidor estable, las opciones compatibles son limitadas.

# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot

Después del reinicio, compruebe qué kernel se ha iniciado realmente:

uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-required

uname -r debería mostrar ahora la nueva rama, y dpkg -l muestra todas las imágenes de kernel que siguen instaladas. Si uname -r muestra la versión antigua mientras dpkg -l incluye la nueva, el paquete se instaló, pero no cambió la entrada predeterminada del gestor de arranque: revise las entradas del menú de GRUB. Que exista /var/run/reboot-required significa que un paquete actualizó el kernel y que desde entonces no se ha reiniciado el sistema. Es el motivo más habitual por el que un servidor parcheado sigue ejecutando el código vulnerable.

¿Debería perseguir la versión 7.1 en un VPS de producción?

No. La razón no es la precaución por sí misma. El kernel de una distribución forma parte de un contrato de soporte. Canonical, Red Hat, SUSE y Debian incorporan correcciones de seguridad mediante backports en su línea congelada y las prueban con el espacio de usuario que distribuyen junto con ella. Un kernel mainline de un archivo de terceros o una compilación manual le proporciona las funciones nuevas, pero elimina ese trabajo, porque nadie incorpora las correcciones mediante backports en su compilación. Usted pasa a mantener un kernel.

Las excepciones existen, pero son limitadas: hardware que el kernel antiguo no puede controlar, o un cambio de rendimiento que haya medido con su propia carga de trabajo y que necesite lo suficiente como para asumir sus consecuencias. En un VPS, la primera situación casi nunca se aplica, porque el hardware que ve es virtual. Para todo lo demás, mantenga actualizado el kernel de la distribución y reinicie cuando se lo solicite. Si ya tiene prevista una actualización de la distribución, pasar de Ubuntu 24.04 a 26.04 le lleva de 6.8 a 7.0 en un solo paso, un salto mayor que el que le proporcionará cualquier paquete de kernel individual.

FAQ

¿Cómo compruebo qué kernel de Linux ejecuta mi VPS?

Ejecute uname -r. Muestra algo parecido a 6.8.0-79-generic. El número anterior al primer guion es la línea upstream en la que se basa la compilación de su distribución. Todo lo que aparece después es el número de compilación propio de la distribución, que incluye correcciones retroportadas. Después, ejecute systemd-detect-virt. Si muestra lxc o openvz, usa virtualización mediante contenedores, comparte el kernel del host y no puede cambiarlo. Si muestra kvm, arranca su propia imagen del kernel y usted debe realizar las actualizaciones.

¿Linux 7.1 es un kernel con soporte a largo plazo?

No. A fecha de 11 August 2026, las líneas con soporte a largo plazo que aparecen en kernel.org son 6.18, 6.12, 6.6, 6.1, 5.15 y 5.10, y 7.1 no está entre ellas. Es una versión estable normal, y su línea estable deja de mantenerse poco después de que aparece la siguiente versión mainline. Si quiere un kernel con años de correcciones aplicadas y años de correcciones futuras, eso es lo que ya ofrece el kernel de su distribución.

¿Cuándo publicarán Ubuntu o Debian el kernel 7.1?

Probablemente nunca como versión predeterminada. Debian 13 permanece en 6.12 durante todo el ciclo de vida de la versión, y RHEL 10 permanece en 6.12.0. Ubuntu 26.04 LTS publicó la versión 7.0, y una pila de habilitación de hardware de Ubuntu cambia al kernel que incluya la versión interim más reciente, por lo que puede omitir por completo una línea upstream. Está previsto que Ubuntu 24.04 LTS cambie su kernel HWE a 7.0 con la versión puntual 24.04.5, el 27 August 2026. Las correcciones de 7.1 le llegarán como backports en una línea anterior. Normalmente, las funcionalidades no.

¿Qué aspectos de Linux 7.1 son realmente importantes en un servidor privado virtual?

Cuatro aspectos. La asignación de colas de hardware permite que un contenedor use una cola real de NIC para AF_XDP a velocidad nativa. La tercera fase de la reestructuración de swap elimina el mapa de swap estático y reduce un 30% la metadata que el kernel mantiene para el dispositivo de swap, según lo publicado. MGLRU puede comprobar por lotes los indicadores de páginas jóvenes, con la mayor mejora publicada en un servidor Arm con muchos núcleos. Además, clone3() incorporó CLONE_AUTOREAP, CLONE_NNP y CLONE_PIDFD_AUTOKILL, que hacen más segura la supervisión de procesos hijos. También se añadió la información de protección T10 a nivel del sistema de archivos, pero un disco virtual rara vez expone la metadata de integridad que necesita.

¿La actualización del kernel puede dejar inutilizable mi VPS?

Los fallos habituales ocurren durante el arranque. Un /boot lleno hace que update-initramfs falle con No space left on device durante la instalación y deja el paquete configurado a medias: elimine los kernels antiguos con sudo apt autoremove --purge y vuelva a instalarlo. Los módulos externos compilados para el kernel antiguo dejan de cargarse. Por tanto, todo lo que gestione DKMS debe recompilarse, y un error durante la recompilación permanece oculto hasta que falta el módulo en tiempo de ejecución. Además, si uname -r sigue mostrando la versión antigua después de reiniciar mientras dpkg -l enumera la imagen nueva, la instalación no se ha roto: no se actualizó la entrada predeterminada del gestor de arranque.