Actualizaciones
Las actualizaciones de hv proceden de un repositorio de versiones de confianza. Cada Pool sigue un canal, normalmente stable; también se admiten candidate y dev. Si un administrador no fija un canal en la política de actualizaciones del Pool, el Pool sigue el canal con el que se instaló el Host (el campo channel de /etc/hv/repository.json, elegido al construir la ISO o en [updates] del instalador); prod.toml no tiene ajuste de canal. Antes de actualizar, revise notas de versión, copias verificadas, capacidad de evacuación y acceso a una consola del Host. Revertir una raíz no revierte bases de datos compartidas ni discos de VM.
Usar la documentación de la versión instalada
El manual de administración se instala con cada versión de hv. La sección Docs de la consola lo muestra en el idioma de la cuenta, inglés o español. Al actualizar hv también se actualiza el manual, de modo que corresponde a la versión instalada. El sitio web público muestra el manual de la versión más reciente. Use la copia instalada para administrar un sistema que todavía no se haya actualizado.
Antes de empezar, anote las versiones actual y de destino y lea las notas de esta última. Durante una actualización progresiva, los Hosts pueden ejecutar temporalmente versiones distintas. Compruebe la versión de cada Host antes de usar comandos locales de recuperación y conserve las notas de la versión que está aplicando hasta completar el proceso.
Revisar versiones disponibles
Abra Sistema, Actualizaciones y seleccione Comprobar ahora. Revise repositorio, canal, versión, verificación y Notas de la versión. Hosts muestra versiones en ejecución y preparadas, raíces y progreso; Historial registra actualizaciones progresivas. Actualizar necesita host.patch, normalmente disponible para administradores de flota.
La confianza se establece mediante el índice de canal firmado y el manifiesto de paquetes verificado. Que responda una URL HTTPS no basta. Puede rechazarse información antigua o repetida de un repositorio. No eluda un fallo de verificación copiando claves de firma arbitrarias al Host.
Distinguir actualización en caliente y de plataforma
hv determina el tipo para cada Host comparando la identidad de plataforma de la versión. Si coincide, puede actualizar los paquetes propios de hv en caliente. Si difiere o se desconoce, hace falta actualizar la plataforma.
| Tipo | Comportamiento |
|---|---|
| En caliente | Se sustituyen paquetes de hv y se reinician los servicios afectados. No se reinicia ni evacua el Host; las VM continúan. Las conexiones de gestión pueden necesitar reconectarse. |
| Plataforma | Se prepara la raíz A/B inactiva, se entra en mantenimiento, se evacúan las VM, se arranca la raíz de prueba, se verifica el Host y se sale de mantenimiento. |
Primero se procesan los Hosts que necesitan plataforma, con el coordinador primero entre ellos. Después se procesan los de actualización en caliente, dejando el coordinador para el final. Así el servicio de gestión se reinicia al terminar ese despliegue. Descargar y preparar corresponde a plataforma; para los Hosts en caliente no hay nada que preparar y se usa Aplicar.
Seleccione Aplicar, revise el tipo y elija Ahora, A una hora o En la ventana de mantenimiento. La ventana usa UTC. Se avanza Host a Host y se detiene ante un fallo. En un Pool de un solo Host hay que apagar las VM antes de actualizar plataforma, porque no existe destino de evacuación.
Por ejemplo, un Pool con hv-01 y hv-02 puede necesitar actualizar la plataforma mientras web-01 se ejecuta en hv-01. Compruebe que hv-02 puede recibir esa VM con sus discos y redes antes de aplicar la versión. Si no puede, resuelva el recurso que falta o acuerde una parada con el responsable de la aplicación. Programar la actualización no crea capacidad de evacuación.
Siga la secuencia en Hosts y el proceso en Historial. Si falla la evacuación de un Host, revise sus VM restantes antes de considerar un reinicio. Si falla después de reiniciar, use su consola y el estado de las raíces para determinar cuál está en ejecución. Reanude solo tras corregir la causa y repita las comprobaciones de la aplicación al terminar. La referencia de la CLI incluye los comandos locales de estado y reversión.
Configurar la política
Abra Política del Pool. Manual: comprobar y avisar es el valor predeterminado. Descargar y preparar automáticamente prepara plataforma. Aplicar automáticamente en la ventana de mantenimiento también la aplica cuando corresponde. Sin ventana, no se realiza la aplicación automática ordinaria.
La opción Actualizaciones en caliente también respeta la ventana por defecto. En cualquier momento permite desplegar fuera de ella cuando todo el trabajo pendiente es en caliente. Actualizaciones en caliente desde y Actualizaciones de plataforma desde permiten elegir fuentes de repositorio y canal distintas. Si una versión en caliente más nueva necesita una plataforma que algún Host no tiene, espera a que se actualice esta primero.
Añadir o cambiar un repositorio
Use Repositorios, Añadir repositorio para cambiar las fuentes. Antes de guardar, obtenga la huella de la clave raíz del editor por un canal independiente de confianza.
- Introduzca la URL HTTPS y seleccione Probar.
- Revise nombre del repositorio, número de serie y resultados de los canales.
- Si la confianza no deriva de un repositorio ya aceptado, compare la huella con el valor independiente del editor. Introduzca el valor verificado en Huella de la clave raíz.
- Marque Hacerlo el repositorio predeterminado solo si deben cambiar de origen los Pools que usan el predeterminado.
- Seleccione Guardar repositorio y revise Hosts que guardan su confianza.
Copiar la huella únicamente de la misma respuesta no confiable no constituye confirmación independiente. hv distribuye documento firmado y claves de versión a los Hosts. Cambiar el predeterminado exige que los afectados acepten la confianza; un fallo puede dejar el repositorio guardado sin hacerlo predeterminado. Lea el estado de cada Host y repita después de resolver la conectividad. Las claves anteriores se retiran tras la primera actualización progresiva correcta desde la fuente nueva. Use un repositorio HTTPS público; este procedimiento no admite credenciales de acceso al repositorio.
Verificar y recuperar
Revise el resultado final y, en cada Host, versión, servicios, pertenencia al Pool, SR y redes. Pruebe una VM tras actualizar plataforma. Reanudar repite desde el paso fallido una vez corregida su causa. Cancelar actualización progresiva impide que empiecen más Hosts, pero no deshace el paso activo ni saca de mantenimiento a un Host que ya esté en él.
Una raíz de prueba fallida puede volver a la confirmada. Un Host bloqueado puede necesitar apagar y encender desde la consola remota; no se garantiza recuperación automática de bloqueos. Revertir en la UI reinicia inmediatamente el Host sin migrar antes sus VM. Planifique su tratamiento antes de seleccionarlo.
Para recuperación local, hv-upgrade status muestra las raíces y hv-upgrade rollback --dry-run anticipa la reversión. hv-upgrade rollback cambia la selección del próximo arranque, pero no reinicia por sí mismo. Los fallos en caliente intentan restaurar los paquetes anteriores de la caché; compruebe si el resultado indica reversión o fallo. No borre bloqueos ni fuerce repetidamente una versión fallida. Preparar otra versión de plataforma puede sobrescribir la raíz anterior de recuperación.