Novedades del kernel Linux 7.1 para servidores

Novedades en el kernel de Linux 7.1

El kernel de Linux 7.1 se publicó el 14 de junio de 2026, nueve semanas después de la versión 7.0. Para un usuario de VPS (servidor privado virtual), los cambios relevantes se agrupan 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 se centra principalmente en mejoras de escritorio y gráficos que un servidor sin monitor (headless) nunca carga.

Existe una segunda respuesta que debe conocer primero. Es casi seguro que la versión 7.1 no se está ejecutando en su servidor, y no lo hará en mucho tiempo. kernel.org no lista la 7.1 como una versión de soporte a largo plazo (longterm). A fecha de 11 de agosto de 2026, las líneas de soporte a largo plazo son 6.18, 6.12, 6.6, 6.1, 5.15 y 5.10, y todas las distribuciones de servidor convencionales se basan en una de estas o en una línea que mantienen por cuenta propia. "Novedades en el kernel" y "novedades en su servidor" tienen años de diferencia, por lo que esta guía cubre ambas partes.

Qué kernel está ejecutando su VPS en este momento

uname -r
uname -srm
systemd-detect-virt

uname -r muestra la versión del kernel en ejecución. En Ubuntu 24.04 se ve como 6.8.0-79-generic. La parte anterior al primer guion es la línea de desarrollo principal (upstream). Todo lo que sigue es el número de compilación propio de su distribución y no guarda relación con el desarrollo principal. El 6.8.0-79 de Canonical incluye miles de correcciones adaptadas (backported) de kernels posteriores, por lo que no es el código que Linus etiquetó como 6.8 en marzo de 2024. Por esto, decir "mi kernel es antiguo" tiene menos significado de lo que parece. Las funcionalidades son antiguas. Las correcciones de seguridad, generalmente, no lo son.

systemd-detect-virt le indica si puede cambiar el kernel. Muestra kvm en una máquina virtual completa, donde usted arranca su propia imagen de kernel y una actualización es una actualización real. Muestra lxc o openvz en virtualización por contenedores, donde el kernel del host es compartido. En un plan de contenedores, uname -r muestra el kernel del proveedor; instalar un paquete de kernel no cambia nada que usted pueda arrancar, y ninguna funcionalidad de esa versión estará disponible para usted 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"
  }
]

Eso suma 6 plataformas, y ninguna de ellas arranca la versión 7.1. La más reciente es Ubuntu 26.04 LTS (7.0), que está 1 versión por detrás de la línea principal. La más antigua que aún cuenta con soporte está 26 versiones por detrás. El kernel GA predeterminado de Ubuntu 24.04 se sitúa 13 versiones atrás, mientras que Debian 13 y RHEL 10 se sitúan 9 atrás en la línea de soporte a largo plazo 6.12. Contar versiones es una medida aproximada, ya que ignora todo lo que las distribuciones adaptan, pero muestra la magnitud de la brecha. Si está evaluando cuál de estas ejecutar, el compromiso entre versiones LTS y versiones provisionales en un servidor es la decisión que subyace a estas cifras.

Almacenamiento y sistemas de archivos en 7.1

La versión 7.1 añade la capacidad de generar y verificar T10 PI (información de protección) dentro del sistema de archivos, en lugar de limitarse únicamente a la capa de bloques, junto con soporte flexible para la alineación T10. T10 PI consiste en bytes adicionales adjuntos a cada bloque que contienen una suma de comprobación y una etiqueta que identifica a qué bloque pertenecen los datos; de este modo, una escritura mal dirigida o incompleta se detecta en lugar de devolverse como datos correctos. El inconveniente para un inquilino de VPS es el hardware. Los metadatos de integridad deben ser expuestos por el dispositivo, y un disco virtual normalmente no los expone.

ls /sys/block/vda/integrity/

En la mayoría de los discos VPS, eso devuelve No such file or directory, porque la capa de bloques solo crea el directorio integrity cuando el dispositivo registra soporte de integridad. Ese error es la respuesta normal en este caso, no un fallo. Si desea saber qué es realmente su disco antes de seguir leyendo sobre funciones de almacenamiento, comprobar si el disco del VPS es realmente NVMe es lo primero, y la diferencia entre NVMe y un SSD SATA en un VPS explica por qué la respuesta cambia sus resultados.

Btrfs recibe correcciones para la amplificación de copy-on-write bajo presión de memoria, además de un cambio que acelera el borrado del primer extent en un rango rastreado, reportando un 10% más de rendimiento en la carga de trabajo de muestra que menciona la integración. Su operación de apagado ya no está marcada como experimental. XFS mejora el vaciado de rangos de ceros y la búsqueda mediante iomap, y añade un puntero de escritura a la geometría de grupos en tiempo real, lo cual es la base para dispositivos zonificados. NTFS es una reescritura completa en esta versión, con soporte total de escritura y una conversión a iomap, lo cual es relevante si alguna vez monta una imagen de disco de una máquina Windows en su servidor.

Otros elementos de almacenamiento menores que conviene conocer: ublk, el controlador de bloques en espacio de usuario, obtuvo I/O de copia cero; io_uring obtuvo comandos de paso a través (passthrough) SCSI; el soporte para unidades de autocifrado SED-OPAL obtuvo el comando STACK_RESET y el modo de usuario único extendido; hay un nuevo controlador de caracteres fs-dax para dispositivos de acceso directo; y el VFS amplió inode->i_ino de unsigned long a u64, lo que elimina un límite de número de inodo en compilaciones de 32 bits. En cuanto a sistemas de archivos de red, el servidor NFS en el kernel ahora puede firmar sus manejadores de archivos mediante una opción de montaje sign_fh, y el cliente CIFS aprendió O_TMPFILE.

Redes: arrendamiento de colas y sus beneficios para contenedores

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 en un dispositivo de red físico y actuar como su proxy. El objetivo de esto son los contenedores. Hasta ahora, un contenedor que requiriera 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) debía recibir acceso a casi todo el dispositivo. Con una cola arrendada, el contenedor obtiene una cola de hardware, ejecuta AF_XDP y proveedores de memoria a velocidad nativa, mientras el host conserva el resto de la NIC. Esta funcionalidad se integra junto al soporte de AF_XDP en la ruta de copia cero de io_uring.

En el ámbito convencional, los sockets en sockfs ahora aceptan user.* atributos extendidos. Un socket AF_UNIX basado en rutas ya heredaba el soporte de xattr del sistema de archivos subyacente, pero un socket que residía únicamente en sockfs carecía de él. Ahora, un proceso puede etiquetar un socket y un programa eBPF puede filtrar basándose en esa etiqueta.

Se han realizado dos eliminaciones. UDP-Lite ha sido eliminado al no encontrar usuarios. IPv6 ya no puede compilarse como un módulo cargable: si necesita IPv6, debe compilarse de forma integrada. Este segundo cambio es invisible en cualquier kernel de distribución, ya que las distribuciones de servidor comunes ya incluyen IPv6 compilado de forma nativa.

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

La reestructuración del swap alcanza su tercera fase, la cual elimina el mapa de swap estático. El contador de swap ahora reside directamente en la tabla de swap. El ahorro reportado es de aproximadamente el 30% de los metadatos de swap estáticos; esta es memoria que el kernel mantiene en proporción al tamaño de su dispositivo de swap, independientemente de si hay datos intercambiados o no. En términos absolutos, esto es poco en un archivo de swap pequeño, pero aumenta según el swap que usted configure.

MGLRU (multi-generational least recently used, el algoritmo más reciente de recuperación de páginas) ahora puede verificar el flag de páginas jóvenes por lotes en lugar de una página a la 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 es más efectivo donde el costo por página es mayor, razón por la cual ese número proviene de una máquina Arm grande. Si usted utiliza un VPS Arm en lugar de uno x86, este es el cambio de la versión 7.1 que probablemente notará en sus propias mediciones, aunque no a esa escala en sistemas de dos o cuatro núcleos.

También se incluye: las transferencias desde cgroups de memoria en proceso de eliminación han desaparecido, khugepaged realiza escaneos con menor uso de CPU y el árbol maple recibió una refactorización importante en el manejo de sus nodos grandes. Ninguno de estos elementos requiere configuración por su parte. Son mejoras que usted notará como una ligera reducción en el tiempo de sistema.

Planificadores: subplanificadores de sched_ext y FRED activado por defecto

sched_ext, la clase de planificador extensible que permite escribir un planificador de CPU como un programa BPF y cargarlo en tiempo de ejecución, llegó en la versión 6.12. La versión 7.1 añade la estructura central para los subplanificadores, de modo que un grupo de control pueda eventualmente ejecutarse bajo su propio planificador. Lea esa frase con atención. La implementación no está terminada en la 7.1 y, en particular, falta la ruta de encolado, por lo que se trata de una base para una versión posterior y no de algo que pueda activar hoy mismo.

Intel FRED (flexible return and event delivery) está ahora activado por defecto en el hardware que lo soporta. FRED reemplaza la ruta de entrega de eventos heredada de x86 por una más limpia, y ha estado presente en el kernel desde la versión 6.9 detrás del argumento de arranque fred=on. Activarlo por defecto es una declaración de que el hardware comercial ha sido probado lo suficiente. Las mediciones publicadas hasta ahora, en el rango del 4% al 7% en cargas de trabajo con uso intensivo de E/S, provienen de pruebas de Phoronix en silicio de cliente, así que no cuente con ello en un servidor hasta que haya medido su propia carga de trabajo.

La ejecución mediante proxy obtuvo la migración de donantes para potenciar al propietario de un bloqueo remoto, EEVDF recibió correcciones relacionadas con el retardo negativo y el núcleo del temporizador de alta resolución fue reescrito sustancialmente. Estos son cambios de calidad de latencia que ningún archivo de configuración expone.

Nuevos controles de procesos y contenedores en clone3()

Se añadieron tres flags a clone3(), cada una de las cuales cierra una brecha que los supervisores han gestionado manualmente durante años. CLONE_AUTOREAP hace que el proceso hijo se recoja a sí mismo al finalizar, por lo que nunca se convierte en un proceso zombi a la espera de un padre que quizás nunca llame a wait(). CLONE_NNP establece no_new_privs en el hijo en el momento de la creación, lo que cierra el intervalo entre el clone y el momento en que el hijo establece la flag por sí mismo. CLONE_PIDFD_AUTOKILL vincula el tiempo de vida del hijo al pidfd devuelto al padre: al cerrar el pidfd, el hijo es eliminado, de modo que un supervisor que muere no puede dejar procesos huérfanos en ejecución.

Los espacios de nombres de montaje (mount namespaces) recibieron el mismo tratamiento. CLONE_EMPTY_MNTNS para clone3() y UNSHARE_EMPTY_MNTNS para unshare() crean un espacio de nombres de montaje vacío, en lugar de la copia completa habitual de los montajes del padre que un entorno de ejecución (runtime) debe desmontar posteriormente. FSMOUNT_NAMESPACE permite que fsmount() coloque un sistema de archivos directamente en un nuevo espacio de nombres. Los entornos de ejecución de contenedores han ensamblado esto manualmente durante una década; realizarlo en una sola llamada significa que un entorno de ejecución ya no comienza desde un espacio de nombres lleno de los montajes del host.

En el ámbito de la virtualización, guest_memfd ahora es compatible con userfaultfd, por lo que un hipervisor puede gestionar los fallos de página del invitado desde el espacio de usuario. KVM protegido en Arm obtuvo soporte para memoria anónima, el cual la propia fusión describe como no apto para producción.

¿Cuándo llega 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, ya que Fedora rebasea su kernel a nuevas líneas estables dentro de una misma versión. Arch y openSUSE Tumbleweed lo tienen por la misma razón. Esas son máquinas para realizar pruebas, no máquinas para ejecutar sus servicios.

Todo lo demás espera, y la espera es intencionada. Debian 13 se lanzó con 6.12 y permanece en 6.12 durante toda la vida útil de la versión, con correcciones adaptadas (backported) a ella. RHEL 10 se lanzó con 6.12.0 y hace lo mismo. Ubuntu 26.04 LTS se lanzó con 7.0 en abril de 2026. Ubuntu 24.04 LTS cuenta con una pila de habilitación de hardware (HWE), la cual extrae un kernel más reciente de versiones posteriores de Ubuntu hacia la LTS; dicha pila se encuentra en 6.17 desde la versión de mantenimiento 24.04.4, y está programada para pasar a 7.0 con la 24.04.5 el 27 de agosto de 2026.

Aquí está el punto en el que la gente se equivoca. Una pila HWE salta al kernel que incluya la versión intermedia más reciente, por lo que puede omitir una línea upstream por completo. La 7.0 está en una versión Ubuntu LTS. Es posible que la 7.1 nunca sea la base de una, porque la versión intermedia posterior incluirá una línea más reciente. Lo que llega a su LTS desde la 7.1 son las correcciones, adaptadas a la línea en la que usted se encuentre. Las funcionalidades, en su mayoría, no se incluyen.

Si desea un kernel más reciente en un servidor estable, las rutas soportadas 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

Tras el reinicio, verifique qué kernel se ha cargado realmente:

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

uname -r debería mostrar ahora la nueva línea, y dpkg -l muestra todas las imágenes de kernel instaladas. Si uname -r muestra la versión antigua mientras que dpkg -l lista la nueva, el paquete se instaló pero el valor predeterminado del cargador de arranque no cambió: revise las entradas del menú de GRUB. Si /var/run/reboot-required existe, significa que un paquete actualizó el kernel y no se ha reiniciado el sistema desde entonces, lo cual es la razón más común por la que un servidor parcheado sigue ejecutando código vulnerable.

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

No, y la razón no es la precaución por sí misma. Un kernel de distribución es un contrato de soporte. Canonical, Red Hat, SUSE y Debian aplican parches de seguridad a su versión estable y los prueban con el espacio de usuario que distribuyen junto a él. Un kernel principal (mainline) proveniente de un repositorio de terceros o compilado manualmente le ofrece nuevas funciones, pero elimina ese trabajo de mantenimiento, ya que nadie aplicará parches de seguridad a su compilación. Usted se convierte en el responsable del mantenimiento de su kernel.

Las excepciones son reales pero limitadas: hardware que el kernel antiguo no puede gestionar, o una mejora de rendimiento que ha medido en su propia carga de trabajo y que desea lo suficiente como para asumir las consecuencias. En un VPS, el primer caso casi nunca aplica, ya que el hardware que usted ve es virtual. Para todo lo demás, mantenga el kernel de la distribución actualizado y reinicie cuando se le solicite. Si ya tiene planeada una actualización de la distribución, pasar de Ubuntu 24.04 a 26.04 le llevará de la versión 6.8 a la 7.0 en un solo paso, lo cual representa un salto mayor que cualquier paquete de kernel individual que pueda instalar.

FAQ

¿Cómo verifico qué kernel de Linux está ejecutando mi VPS?

Ejecute uname -r. Esto imprimirá algo similar a 6.8.0-79-generic. El número antes del primer guion es la línea upstream sobre la que se basa su distribución, y todo lo que sigue es el número de compilación propio de la distribución, el cual incluye correcciones retroportadas (backported). Luego, ejecute systemd-detect-virt. Si imprime lxc o openvz, usted está en un entorno de virtualización de contenedores, comparte el kernel del host y no puede cambiarlo. Si imprime kvm, usted arranca su propia imagen de kernel y es responsable de realizar las actualizaciones.

¿Es Linux 7.1 un kernel de soporte a largo plazo (LTS)?

No. A fecha de 11 de agosto de 2026, las líneas de soporte a largo plazo listadas en kernel.org son 6.18, 6.12, 6.6, 6.1, 5.15 y 5.10; la versión 7.1 no se encuentra entre ellas. Es una versión estable normal y su línea estable se abandona poco después de que aparece la siguiente versión mainline. Si desea un kernel con años de correcciones acumuladas y años de soporte por delante, eso es precisamente lo que ya ofrece el kernel de su distribución.

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

Probablemente nunca como versión predeterminada. Debian 13 permanece en 6.12 durante toda la vida útil de la versión, y RHEL 10 permanece en 6.12.0. Ubuntu 26.04 LTS incluyó la versión 7.0, y el stack de habilitación de hardware (HWE) de Ubuntu salta al kernel que incluya la versión intermedia más reciente, por lo que puede omitir una línea upstream por completo. Está programado que Ubuntu 24.04 LTS mueva su kernel HWE a la versión 7.0 con el lanzamiento de punto 24.04.5 el 27 de agosto de 2026. Las correcciones de la versión 7.1 le llegarán como backports en una línea más antigua. Las nuevas funcionalidades, por lo general, no lo harán.

¿Qué es lo que realmente importa de Linux 7.1 en un servidor virtual privado?

Cuatro puntos. El arrendamiento de colas de hardware (hardware queue leasing) permite que un contenedor utilice una cola de NIC real para AF_XDP a velocidad nativa. La tercera fase de la reestructuración del swap elimina el mapa de swap estático y reduce los metadatos que el kernel mantiene para su dispositivo de swap en un 30% reportado. MGLRU puede verificar los flags de "young" de las páginas por lotes, con la mayor ganancia publicada en servidores Arm de muchos núcleos. Y clone3() obtuvo CLONE_AUTOREAP, CLONE_NNP y CLONE_PIDFD_AUTOKILL, que hacen que la supervisión de procesos hijos sea más segura. También se implementó la información de protección T10 a nivel de sistema de archivos, pero un disco virtual rara vez expone los metadatos de integridad necesarios para ello.

¿Actualizar mi kernel romperá mi VPS?

Los fallos comunes ocurren durante el arranque. Un /boot completo hace que update-initramfs falle con No space left on device durante la instalación, dejando el paquete configurado a medias: limpie los kernels antiguos con sudo apt autoremove --purge y luego reinstale. Los módulos fuera del árbol (out-of-tree) compilados para el kernel antiguo dejan de cargarse, por lo que cualquier componente gestionado por DKMS debe recompilarse; un fallo en la recompilación es silencioso hasta que el módulo falta en tiempo de ejecución. Y si uname -r sigue reportando la versión antigua después de un reinicio mientras dpkg -l lista la nueva imagen, la instalación no se rompió: el valor predeterminado del gestor de arranque no se actualizó.