Actualizar de Proxmox 4 a Proxmox 5, Debian 8 Jessie a Debian 9 Stretch

Si recientemente has actualizado tu Proxmox 4 habrás visto el mensaje "Support for Proxmox VE 4.4
ends on June 30, 2018". Así que ha llegado el momento de actualizar a la última versión Proxmox 5.

Este artículo está basado en la fuente principal en la web de www.proxmox.com en su wiki de soporte: https://pve.proxmox.com/wiki/Upgrade_from_4.x_to_5.0 consúltalo para más ayuda.

En términos generales, existen dos posibilidades para pasar de Proxmox 4 a Proxmox 5.

1. La primera opción es realizar una nueva instalación en hardware nuevo para posteriormente restauración de máquinas virtuales desde la copia de seguridad. 
2. La segunda opción es realizar una actualización en a través de apt, paso a paso.

En cualquier caso, será necesario que vacíes la memoria caché del navegador después de la actualización y vuelvas a cargar la página de la GUI o existe la posibilidad de que veas muchas fallas.

Seguramente si utilizas tu servidor de virtualización Proxmox como laboratorio de pruebas como lo hago yo, es muy probable que no tengas disponible nuevo hardware para realizar una nueva instalación y realizar una migración de todas las máquinas virtualizadas.

Así pues en nuestro caso vamos a poner en practica la opción de actualizar; nos disponemos a actualizar Proxmox desde el repositorio de APT. Vamos a aclarar que esta actualización en Debian de proxmox va asociada a la versión de Debian que corremos. Proxmox 4 está asociado a la versión Debian 8 (Jessie) mientras que Proxmox 5 está asociado a la versión Debian 9 (Stretch), por tanto principalmente lo que haremos para hacer la actualización de Proxmox es una actualización de repositorios para utilizar la última versión de Debian  9 (Stretch). 

IMPORTANTE: Tal y como especifican en el manual oficial de Proxmox; debes saber antes de comenzar si usa ceph, actualice su clúster Ceph a la versión Luminous antes de actualizar, siguiendo el artículo Ceph Jewel to Luminous.

Antes de actualizar

Principalmente nos tenemos que asegurar antes de actualizar de cumplir los siguientes puntos:

• Tenemos copia de seguridad de todas las máquinas virtuales.
• Todo el sistema está funcionando correctamente. 
• Todas las máquinas virtuales están correctamente apagadas. 
• Asegurarnos de estar en la última versión (Proxmox 4.4) antes de iniciar el proceso de actualización a Proxmox 5, para ello ejecutar: 
• apt-get update && apt-get dist-upgrade
• Mi ultima recomendación personal es reiniciar el sistema con todas las máquinas sin iniciar (start on boot OFF).

Comenzamos la actualización: 

Los pasos para la actualización sin pocos y simples como puedes ver. 

1. Cambiar en nuestro sources.list de nombre de versión, cambiando de jessie a stretch. Puede que no estemos utilizando el nombre de la versión en nuestro sources.list asegúrate. 

sed -i 's/jessie/stretch/g' /etc/apt/sources.list

1.1. Igualmente hay que cambiar el nombre de la versión en nuestro fichero pve-enterprise.list, en mi caso tenía el repositorio de Proxmox en el propio sources.list, puesto que este Proxmox venía de una versión anterior donde el repositorio simplemente se añadía en el sources.list principal.

sed -i 's/jessie/stretch/g' /etc/apt/sources.list.d/pve-enterprise.list

2. Actualizar nuestra lista de repositorios con la actual Stretch.

apt-get update

3. Descargar e instalar las nuevas versiones de paquetes.

apt-get dist-upgrade

Este último paso en el proceso de actualización será el más largo y también dependerá mucho de nuestra linea de acceso a internet. Puesto que tiene que descargar todos los paquetes necesarios para la actualización y posteriormente desempaquetarlos e instalarlos.

Además durante el proceso de instalación algunos paquetes requieren de la intervención del usuario, para solicitar la confirmación de reinicio de algunos servicios esenciales para el sistema (ssh, postfix, ...) o para solicitar confirmación de instalación de los ficheros de configuración del desarrollador o bien mantener los existentes. 

IMPORTANTE: Actualizar desde terminal ssh

Si pretendes hacer la actualización desde un terminal ssh no ejecutes el comando "apt-get dist-upgrade" directamente en el terminal ssh. Podrías perder la conexión por cualquier motivo y no sabrás cómo/cuando terminó el proceso de actualización o si el proceso solicita de tu intervención, el proceso de actualización quedará paralizado y puede dejar el sistema en un estado inestable. 

Siempre que necesito ejecutar un proceso largo o con cierto nivel de riesgo para la estabilidad del sistema en mis sistemas, utilizo "screen". Este comando nos permite "virtualizar" un terminal que cuelga del raíz de procesos del sistema, es decir, pese a ejecutar screen desde un terminal ssh el proceso colgará fuera del proceso ssh y si perdemos la conexión nuestros procesos seguirán su curso y podremos volver a recuperarlos cuando lo necesitemos. 

Puedes visitar un artículo que escribí hace tiempo en este blog sobre screen, pero te dejo los comandos básicos de screen aquí como ayuda:

• Crear un terminal: screen -dmS ProcesoUpgrade
• Acceder al terminal con el nombre ProcesoUpgrade: screen -r ProcesoUpgrade
• Atajo de teclado para salir del terminal screen sin cerrar el proceso que hemos ejecutado: ctrl+a+d

Ampliar disco máquina virtual

Este es un pequeño manual que describe el procedimiento a seguir para ampliar el tamaño de un disco duro virtual. En mi caso he utilizado una máquina virtual KVM con un disco virtual de tipo ".qcow2". Depende del tipo de máquina virtual que utilices podrás aprovechar algunas partes de este manual.

1. Modificar tamaño de la imagen

En primer lugar tenemos que modificar la definición del fichero ".qcow2" para que tenga un tamaño mayor. Cuando se crea se define un tamaño y este será el tamaño máximo que tomará. Depende del sistema de virtualización que utilices te permitirá hacerlo desde el entorno de administración o no.

Por ejemplo Proxmox (versión 3.1) permite modificar el tamaño de las imágenes ".qcow2" de una forma muy sencilla; desde un botón "Resize disk", donde nos pregunta cuanto queremos ampliar el tamaño de la imagen.

Pero si no utilizas Proxmox, puedes utilizar la herramienta "qemu-img" para modificar el tamaño máximo de tu ".qcow2". Para modificar el tamaño aumentando en 10GB utiliza:

qemu-img resize fichero.qcow2 +10G

Para consultar el tamaño que tiene actualmente definido el fichero puedes utilizar el siguiente comando:

qemu-img info fichero.qcow2

2. Modificar tabla de particiones

Bien ahora nuestra máquina virtual ya tiene más capacidad, pero el sistema operativo que la gestiona aún no se ha enterado. Tenemos que modificar la tabla de particiones de nuestro disco para hacer que aumente el tamaño de la partición y así poder comenzar a utilizar este nuevo espacio.

Este tipo de operaciones sobre la tabla de particiones del disco, hay que hacerlas con el sistema de ficheros desmontado. Si estamos trabajando sobre el sistema de ficheros principal, será necesario arrancar con un CD Live (digo cd live, pero puede ser usb live) para poder trabajar con el sistema desmontado.

Existen muchas herramientas para la manipulación de tablas particiones de los discos desde sistemas "live", yo he utilizado clonezilla. Es un poco tosca y posiblemente nada amigable, pero una vez que sabes utilizar las herramientas básicas desde linea de comando no tendrás problemas con ninguna otra y podrás utilizarlas en cualquier sistema.

El disco que yo quería aumentar su tamaño era el disco principal y tenía; por un lado la partición principal del sistema y a continuación de esta una partición extendida que contenía la partición para swap. Y tras todas las particiones tenía el nuevo espacio libre sin definir.

Para aumentar el tamaño de la partición principal tenía que eliminar la partición extendida y así poder aumentar el tamaño a la partición principal sin pisar el espacio que ocupa la partición para la swap.

Con herramientas como gparted se puede directamente redimensionar el tamaño de una partición, pero en mi caso utilicé fdisk y éste no tiene un procedimiento directo para la redimensión de una partición, así que hay que hacerlo manualmente. Para hacer la redimensión de la partición principal hay que eliminarla. Sí, parece arriesgado y da algo de miedo hacerlo sobre un sistema en explotación, pero según he buscado por internet es el único modo. Así que con fdisk:

1. Borramos la partición principal.
2. Creamos una nueva partición que comienza donde la que hemos borrado y termina donde queramos.
3. Creamos la partición para swap.
4. Establecemos la marca de arranque si fuera necesario para la nueva partición principal.
5. Escribimos los cambios y salimos de fdisk.

http://vostorga.org/?p=42
https://wiki.debian.org/Swap

Proxmox 3.1 vncproxy [2/2]

Esta es la segunda parte de un articulo (Proxmox 3.1 vncproxy [1/2]) que he publicado para conectar con un cliente vnc a las pantallas de las máquinas virtuales que corren bajo proxmox.

Es posible que no sepas como publicar la pantalla de la máquina virtual desde linea de comandos. Si lo haces desde el cliente web, este se encarga de levantar el demonio vnc para que puedas ver la pantalla. Pero si queremos evitar utilizar el cliente web, tendremos que levantar nosotros el demonio para poder conectarnos.

Tenemos dos opciones. Vamos a ver en primer lugar la más simple, que únicamente necesitamos el ejecutar el comando:

nc -l -p 5900 -c "/usr/sbin/qm vncproxy 101"

Donde 5900 es el puerto donde se publicará el servidor de vnc (5900 es el puerto por defecto de vnc) y 101 es el identificador de la máquina virtual en proxmox.

Éste método es muy cómodo pero implica tener que ejecutar el comando cada vez que queramos hacer uso de la pantalla de la máquina virtual. Creo que esto debería ser lo más correcto y no dejar publicada la pantalla de la máquina virtual, porque pese a que este demonio de vnc nos solicita las credenciales del sistema para acceder a la máquina virtual, no deja de ser una vulnerabilidad dejar publicado un servicio que utilizaremos puntualmente.

La segunda opción está orientada a dejar publicado el servicio siempre en nuestro sistema. Pero para esto tendremos que instalar un servicio si no lo tenemos instalado. Para sistemas Debian el paquete se llama "openbsd-inetd", lo instalaremos con:

apt-get install openbsd-inetd 

Una vez instalado editaremos el fichero /etc/inetd.conf para añadir la linea:

5900 stream tcp nowait root /usr/sbin/qm qm vncproxy 101

Y solo nos falta reiniciar el servicio "/etc/init.d/openbsd-inetd restart" para poder disfrutar de la pantalla de nuestra máquina virtual siembre que queramos.

IMPORTANTE: Los clientes VNC tradicionales NO funcionan con este sistema. Lee el artículo Proxmox 3.1 vncproxy [1/2] para ver como conectar correctamente con la pantalla de la máquina virtual.

Proxmox 3.1 vncproxy [1/2]

Me he encontrado un el siguiente problema cuando intento conectar con las pantallas de máquinas virtuales de Proxmox sin utilizar su cliente web. El cliente web es muy cómodo, pero un poco molesto cuando quieres hacer una conexión rápida y no tienes el navegador correctamente configurado (plugin de java y java correctamente configurado).

Por esto estaba buscando la forma de establecer conexiones vnc con el demonio que levanta proxmox sin necesidad de utilizar el cliente web.

El primer problema que me encontré fue que los clientes vncviewer y  xtightvncviewer me devolvían el mismo error...

jmruiz@jmruizhome :~/$ vncviewer 192.168.1.1:5900
Connected to RFB server, using protocol version 3.8
Server did not offer supported security type

jmruiz@jmruizhome :~/$ xtightvncviewer 192.168.1.1:5900
Connected to RFB server, using protocol version 3.8
Server did not offer supported security type

Pero encontré un cliente que permitía conectar sin problemas http://tigervnc.org/.

Si tus problemas simplemente eran solucionar el error "Connected to RFB server, using protocol version 3.8" y "Server did not offer supported security type" ya has encotrado la solución. Descarga he instala tigervnc https://bintray.com/tigervnc/stable/tigervnc/1.3.1 y podrás conectar sin problemas.

Para la versión de linux ten cuidado donde lo descomprimes; el fichero contiene dos directorios "/etc" y "/usr", está preparado para instalar en la raíz del sistema y sobrescribir vncviewer y vncserver. Pero si únicamente vas a utilizar el cliente puedes descomprimir el contenido del fichero en un directorio (tar xvzf fichero.tgz -C directoriodestino) y ejecutar usr/bin/vncviewer y el cliente te solicitará el host para conectarse o bien pasar como argumento directamente el host "usr/bin/vncviewer 192.168.1.1:5900".

Una vez que establece la conexión el servidor nos solicita que confirmemos el certificado ssl (esto es lo que no tienen implementado los clientes vncviewer y  xtightvncviewer ) y nos solicita las credenciales de acceso.

Es muy importante que pongamos usuario@pam en lugar de usuario únicamente, hay que decirle al demonio vnc donde ha de buscar los usuarios para la autenticación. En caso de tener un LDAP con dominio, obviamente pondremos el dominio.

Y por fin tendremos conexión con la pantalla de nuestra máquina virtual. Yo no soy partidario de utilizar VNC para el trabajo diario, pero en ocasiones es necesario ver qué está pasando en la pantalla de la máquina virtual y es complicado verla de forma remota.

Por si alguien no sabe como publicar con vnc la pantalla de una máquina virtual proxmox os dejo el siguiente artículo donde explico como hacerlo. Proxmox 3.1 vncproxy [2/2]

Proxmox "Error: VM is locked (backup)"

Encontré este error "Error: VM is locked (backup)" en mi servidor de virtualización Proxmox; al intentar arrancar una de las máquinas virtuales. Realmente no había ningún backup en ejecución. La solución es bastante simple, con el siguiente comando:

qm unlock

Se desbloquea la máquina virtual y se puede ejecutar normalmente. El "vmid" es el número que identifica a la máquina virtual dentro del sistema.

Proxmox "The requested URL returned error: 401"

Como ya sabréis Proxmox ha dejado de ser gratuito, ahora si no estas suscrito, tienes que utilizar los repositorios de test, no recomendados para servidores en explotación. Pero no obstante yo tenía configurado el servidor de test en mi /etc/apt/sources.list y tenía este error al ejecutar un "aptitude update" o "apt-get update".

Err https://enterprise.proxmox.com wheezy/pve-enterprise amd64 Packages
  The requested URL returned error: 401
Ign https://enterprise.proxmox.com wheezy/pve-enterprise Translation-es_ES
Ign https://enterprise.proxmox.com wheezy/pve-enterprise Translation-es
Ign https://enterprise.proxmox.com wheezy/pve-enterprise Translation-en
94% [Trabajando]W: Se produjo un fallo al descargar https://enterprise.proxmox.com/debian/dists/wheezy/pve-enterprise/binary-amd64/Packages: The requested URL returned error: 401
E: Some index files failed to download. They have been ignored, or old ones used instead.
E: No se pudo reconstruir el almacén de paquetes

Al final el error está en la carga del fichero "/etc/apt/sources.list.d/pve-enterprise.list" por alguna razón ha cargado el repositorio enterprise y hay que comentarlo para evitar este error 401.

Simplemente comentamos la linea que aparece en el fichero "/etc/apt/sources.list.d/pve-enterprise.list" y volvemos a ejecutar el "update" y todo funcionará correctamente.

#deb https://enterprise.proxmox.com/debian wheezy pve-enterprise