Proxmox: Guía de actualización in-place 8 a 9 sin pérdida de VMs

July 13, 2026 • Saul Ojeda • 1115 words • 6 min

La documentación oficial de Proxmox puede generar confusión respecto a la pérdida de datos al migrar de la versión 8 a la 9. Es necesario aclarar que la pérdida total de datos en los discos locales solo ocurre si se opta por una instalación limpia desde un archivo ISO. Si se administra la infraestructura correctamente, el salto de versión mayor se debe realizar mediante un in-place upgrade utilizando el gestor de paquetes de Debian.

Este método actualiza el sistema operativo base y el entorno de virtualización sin modificar ni formatear los volúmenes lógicos (LVM) o particiones (ext4) donde residen los discos de las máquinas virtuales.

Sin embargo, ejecutar este proceso sin un respaldo reciente en Proxmox Backup Server (PBS) es una negligencia técnica. El proceso in-place no formatea los discos, pero una interrupción en el dist-upgrade por fallas de red o dependencias puede dejar el nodo inoperable.

Consideraciones Previas

Acceso a consola: No dependas exclusivamente de una sesión SSH. Durante la actualización, los servicios de red y los módulos de autenticación (PAM) se reiniciarán. Si tus nodos cuentan con protección mediante Duo MFA, la sesión SSH puede cerrarse abruptamente, dejándote sin acceso al prompt interactivo. Utiliza IPMI, iKVM o un multiplexor de terminal como tmux.
Almacenamiento: Verifica tener al menos 5 GB de espacio libre en la partición raíz.

Procedimiento de Actualización

1. Actualización base del entorno actual. El nodo debe encontrarse en la última versión menor de Proxmox VE 8 antes de iniciar la migración.

# Update current repository metadata
apt update

# Upgrade all current packages to their latest PVE 8 versions
apt dist-upgrade -y

2. Validación del sistema. Proxmox incluye un script de diagnóstico para detectar configuraciones incompatibles previas a la migración.

# Run the pre-upgrade checklist script
pve8to9 --full

Se debe resolver cualquier advertencia catalogada como FAIL antes de avanzar al siguiente paso. Los fallos más comunes detectados en este punto y sus soluciones son:

2.1. Conflicto con el meta-paquete systemd-boot

El script arrojará un error si detecta el paquete genérico de Debian systemd-boot. Proxmox utiliza su propia lógica mediante proxmox-boot-tool para gestionar el arranque. Este meta-paquete genera conflictos de dependencias durante el upgrade mayor y debe ser removido. Su eliminación no afectará el arranque actual del servidor, ya que solo se retira el paquete de seguimiento de Debian.

# Remove the conflicting Debian meta-package
apt remove systemd-boot

2.2. Depreciación del privilegio VM.Monitor

En la versión 9, el permiso VM.Monitor se elimina debido a su ambigüedad y se divide en componentes más específicos. Si el script detecta un rol personalizado que utilice este privilegio, bloqueará el proceso. La solución requiere modificarlo desde la interfaz web:

Navegar a Datacenter > Permissions > Roles.
Seleccionar y editar el rol personalizado afectado.
Desmarcar la casilla VM.Monitor y guardar los cambios.
Si el rol se utilizaba para tareas de supervisión o métricas, se puede sustituir por Sys.Audit o los nuevos permisos de la familia VM.GuestAgent.*.

2.3. Actualización de microcódigo de CPU (Advertencia)

Aunque se presenta como un WARN y no impide continuar con la actualización, es una buena práctica de infraestructura aplicar los parches de seguridad y estabilidad del procesador antes del cambio de versión operativa.

# Install the microcode package for hardware security patches
apt update && apt install intel-microcode

Por defecto, el sistema base de Proxmox (Debian) solo habilita repositorios de código abierto. Si al intentar instalar el paquete recibes el error Package 'intel-microcode' has no installation candidate, debes habilitar los componentes privativos:

Edita el archivo de repositorios base:
```
nano /etc/apt/sources.list
```

Añade non-free y non-free-firmware al final de las líneas correspondientes a Debian. El archivo debe quedar así:

deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware

Actualiza los índices de paquetes e instala el microcódigo:

# Update package indexes and install the Intel microcode firmware
apt update && apt install intel-microcode -y

Una vez solventados los puntos anteriores, se debe ejecutar nuevamente el comando de diagnóstico hasta asegurar que el indicador final de FAILURES marque cero.

3. Modificación y limpieza de repositorios

Se deben apuntar las listas de paquetes hacia la nueva distribución base de Debian (Trixie). Además, es crucial eliminar repositorios comerciales si no se cuenta con licencia, y actualizar las fuentes de almacenamiento distribuido (Ceph) a su versión correspondiente (Squid).

3.1. Actualizar repositorios base de Debian

# Update base Debian repositories from bookworm to trixie
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

3.2. Actualizar el repositorio de Proxmox El siguiente ejemplo asume el uso del repositorio gratuito (`pve-no-subscription`).

# Update Proxmox repositories for no-subscription environments
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-install-repo.list

3.3. Eliminar repositorios incompatibles o comerciales

Si tienes habilitado el repositorio Enterprise sin una suscripción activa, el gestor de paquetes arrojará errores 401 que bloquearán la actualización. Del mismo modo, debes eliminar repositorios de prueba (pvetest) si están habilitados y apuntando a la versión anterior.

# Remove the enterprise repository list to prevent 401 Unauthorized errors
rm -f /etc/apt/sources.list.d/pve-enterprise.list
rm -f /etc/apt/sources.list.d/pve-enterprise.sources

# Remove beta/test repositories if present
rm -f /etc/apt/sources.list.d/pvetest-for-beta.list

3.4. Actualizar el repositorio de Ceph (Si aplica). Si tu nodo tiene instalado Ceph, debes actualizar su repositorio a la versión compatible con Proxmox 9 (Ceph Squid) sobre Trixie. Mantener el repositorio viejo de Ceph-Reef causará conflictos graves de dependencias.

# Point Ceph to the Squid release for Debian Trixie (no-subscription)
echo "deb http://download.proxmox.com/debian/ceph-squid trixie no-subscription" > /etc/apt/sources.list.d/ceph.list

4. Ejecución del Upgrade Mayor. Durante la descarga e instalación de la nueva versión, el sistema solicitará confirmación para sobrescribir archivos de configuración (como `grub`, `sshd` o `interfaces`). La práctica estándar es conservar la configuración actual (opción ‘N’ o ‘O’) para evitar la pérdida de conectividad.

# Fetch new repository metadata for Debian Trixie
apt update

# Perform the major distribution upgrade
apt dist-upgrade

5. Reinicio del hipervisor. Una vez que el gestor de paquetes finalice sin errores, se debe reiniciar el servidor para aplicar el nuevo kernel de Linux y levantar los servicios actualizados.

# Reboot the node to apply kernel and service changes
reboot

Al finalizar el reinicio, el nodo operará sobre la nueva versión mayor. Los archivos de definición en /etc/pve/qemu-server/ y los discos de almacenamiento local permanecerán inalterados.

Conclusión

Realizar una actualización in-place de Proxmox VE de la versión 8 a la 9 es un procedimiento sumamente eficiente que evita reinstalaciones innecesarias y protege la persistencia de las máquinas virtuales y contenedores. Sin embargo, su éxito radica en la minuciosidad de la preparación: la ejecución del script de diagnóstico pve8to9, la resolución de todos los conflictos y dependencias previos (como systemd-boot y privilegios depreciados) y, por encima de todo, la existencia de respaldos robustos y actualizados. Siguiendo estos pasos metódicamente, la transición de la infraestructura se completa sin contratiempos.