Índice de contenidos
Claves de la noticia
- Cloud Hypervisor 54 acepta migraciones desde las dos versiones anteriores y recomienda avanzar por saltos incrementales.
- La garantía no incluye volver a una versión antigua ni elimina los requisitos del hardware y los dispositivos.
- El nuevo identificador de generación ayuda al kernel a renovar la aleatoriedad tras restaurar una máquina, pero las aplicaciones conservan responsabilidades propias.
Cloud Hypervisor ha publicado la versión 54 este 14 de octubre con una regla que facilita actualizar infraestructura sin apagar primero todas sus máquinas virtuales. La garantía cubre la llegada desde las dos versiones anteriores. Al cruzarla con la documentación de migración aparece un límite decisivo para planificar mantenimiento: el camino de ida queda definido, mientras la vuelta a una versión antigua sigue sin soporte oficial.
La garantía avanza en una sola dirección
El repositorio oficial registra la publicación a las 09:44 UTC. Cloud Hypervisor es un monitor de máquinas virtuales escrito en Rust, construido para cargas modernas de nube sobre KVM o Microsoft Hypervisor. Su README describe un diseño con poca emulación de hardware heredado y dispositivos paravirtualizados. La novedad interesa sobre todo a operadores que controlan ese componente, no implica que cualquier cliente de nube pueda activarla desde su panel.
La política n-2 significa que la versión 54 acepta migraciones desde 52 y 53. El proyecto admite que saltos mayores podrían funcionar, pero recomienda actualizaciones incrementales. La propuesta que documenta la política, presentada por Cyberus Technology, explica que la estrategia responde a su experiencia operando un clúster creciente. Es una decisión de compatibilidad mantenida por el proyecto, no una medición de disponibilidad de todos sus usuarios.
La consecuencia puede expresarse como una matriz pequeña. El destino determina qué versiones de origen quedan dentro de la promesa; cambiar el orden de las flechas cambia el compromiso.
| Ruta | Cobertura documental |
|---|---|
| 52 → 54 | Dentro de la garantía |
| 53 → 54 | Dentro de la garantía |
| 54 → 56 → 58 | Ejemplo de avance incremental recomendado |
| 54 → 52 | Vuelta a versión antigua sin soporte |
Una actualización con migración admitida no proporciona por sí sola un plan de reversión admitido. Esta es la conclusión que deja el cruce entre las notas y la guía versionada. Un operador necesita decidir antes qué hará si la aplicación falla en el destino, en vez de interpretar n-2 como compatibilidad simétrica entre cualquier par de versiones próximas.
El estado de la máquina conserva sus límites
La compatibilidad tampoco convierte automáticamente una máquina procedente de una versión antigua en usuaria de todas las funciones nuevas. La guía explica que las opciones nuevas de dispositivos o del monitor adoptan valores seguros o desactivados cuando llegan máquinas antiguas. El objetivo es conservar su funcionamiento; las capacidades nuevas se reservan a máquinas recién creadas.
Separar actualización del monitor y creación del invitado evita una expectativa equivocada: trasladar una carga existente puede facilitar el mantenimiento, pero no equivale a reconstruirla con otra configuración. Para comprobar una flota importan tanto la versión del proceso anfitrión como el estado que transporta cada máquina. La tabla anterior expresa compatibilidad de versiones, no certifica que todos los dispositivos conectados se puedan trasladar.
Los dispositivos físicos necesitan su propia ruta
La versión incorpora migración de dispositivos VFIO que ya sean migrables, como funciones virtuales ConnectX vinculadas al controlador mlx5_vfio_pci. El estado del dispositivo se transfiere con el invitado y se rastrea la memoria que escribe durante la operación. Se necesita iommufd activado en la plataforma y soporte de migración en el controlador anfitrión.
Las notas excluyen todavía los dispositivos VFIO situados detrás de una IOMMU virtual. Además, la emulación experimental ARM SMMUv3 admite asignación de dispositivos con requisitos propios, pero no soporta migración en vivo, restauración de instantáneas ni conexión en caliente. Por tanto, dos funciones que aparecen en el mismo lanzamiento no deben sumarse como si formaran una única capacidad ya disponible.
Para quienes administren infraestructura en España, esta distinción cambia la revisión previa: comprobar la versión compatible es solo la primera condición. Después hay que inventariar dispositivo, controlador, configuración de IOMMU y destino. Los documentos no acreditan que un proveedor español concreto haya adoptado la versión ni permiten prometer una duración de parada para sus servicios.
Restaurar una copia también restaura parte de su pasado
El identificador VM Generation ID añade otra protección operativa. Antes, máquinas restauradas desde una misma instantánea podían arrancar con el mismo estado del generador aleatorio y producir la misma salida de /dev/urandom hasta que se renovara su semilla. El cambio proporciona un identificador nuevo durante la restauración y la migración entrante para que un kernel con CONFIG_VMGENID pueda reaccionar.
La propuesta original incluye pruebas de regeneración del valor y de restauración con renovación del generador del invitado en ambas arquitecturas principales. En el arranque directo de AArch64 hace falta acpi=on. Esto respalda la función descrita, pero no acredita que todas las imágenes de sistema usadas por los operadores tengan la opción del kernel necesaria.
Las aplicaciones que inicializaron su propio generador conservan ese estado y deben obtener aleatoriedad nueva por su cuenta tras restaurar. Renovar el generador del kernel no renueva automáticamente el de cada aplicación. Conviene distinguir esta cuestión de otras protecciones, como las máquinas virtuales confidenciales descritas para procesar datos de gafas: aquí la novedad trata de continuidad del estado y aleatoriedad, no de quién puede leer la memoria.
El transporte requiere algo más que llegar al destino
La documentación diferencia migración por socket Unix en un mismo anfitrión y transporte TCP/TLS entre máquinas. En este último, el uso de TLS mutuo autentica ambos extremos y cifra los datos. La guía recomienda una autoridad de certificación dedicada porque el destino acepta certificados de cliente emitidos por ella. Si se omite TLS en ambos lados, el transporte queda sin cifrado y el receptor admite conexiones arbitrarias.
La versión 54 también permite cancelar una migración en curso, por ejemplo si no converge o carga demasiado la red. La máquina continúa en el origen; tras un fallo o cancelación, el monitor intenta recuperar su estado previo si aún no se ha trasladado al destino. La formulación importa: es un intento de recuperación bajo condiciones, no una garantía universal de reversión. El valor práctico del lanzamiento está en poder planificar rutas compatibles, observar su progreso y preservar un plan de contingencia que cubra lo que la compatibilidad no promete.
Imagen: Tecnología Today, imagen conceptual generada con IA.
