De mi Manual de Proxmox VE 4.x: Solución de Problemas (P4)

Saludos nuevamente.

Todo parece indicar que las tareas que tenía pendientes para hacer desde hace rato se han juntado de golpe. ¿Acaso será algún tipo de capricho del azar? 🙂

Bueno, hoy vengo con otro problema que resolví en horas de la tarde, pero del mismo me percaté los días anteriores a la llegada del tristemente célebre huracán Matthew. ¿Cómo lo resolví? Acá les va el artículo:

P4.- Migración “a mano” de un disco duro virtual en formato QCOW2 a un volumen lógico LVM dentro del almacenamiento local de tipo LVM-Thin.

Situación:

Hace unos meses tuvimos la visita de unos compañeros de la empresa a la que tenemos contratado mantenimiento a los equipos, visita planificada, por supuesto. La misma me dejó un trago amargo, y fue que el micro de uno de mis nodos Proxmox VE pasó a mejor vida, lo cual provocó un verdadero dolor de cabeza para mí.

Ya después de una larga espera para que nos devolvieran el nuevo hardware, puse a funcionar nuevamente el nodo. Claro está que mantuve el disco duro del servidor (realmente es una PC de escritorio adaptada con buenas prestaciones) en mi poder durante todo ese tiempo de espera. Lo inicié y me tropecé con errores que, después de analizar en frío, me di cuenta de que la desesperación me jugó una mala pasada. ¿Cual? Bueno, que salvé las máquinas virtuales que tenía y reinstalé el nodo con la versión 4.3 recién descargada, para luego restaurar los entornos virtuales anteriormente respaldados; donde la cosa era extremadamente sencilla: activarle la virtualización nativa (Intel-VT) en el BIOS (sí, sí, me merezco la descarga y todo lo demás, pero ya el daño estaba hecho). 🙁

Problema:

Ya más calmado (en medio de la vorágine de trabajo) me percaté de algo que me llamó poderosamente la atención:

Estado del Almacenamiento Local Principal - Nodo

¿¡Cómo es que ya estoy usando un 65.51% de los 96 GB asignados al funcionamiento principal del nodo!? ¿¡61.82 GB ocupados de dos máquinas virtuales solamente!?

Ahí fue cuando me percaté que los discos duros virtuales de dichas máquinas son imágenes en formato qcow2. Así que, al restaurarlas, se guardaron en el almacenamiento local del nodo. El primer golpe recibido por parte del nuevo modelo de almacenamiento añadido a partir de la versión 4.2.

NOTA: Los que se han mantenido actualizando desde el repositorio (y, claro, asumiendo que iniciaron a partir de la versión 4.1), no se percatarán de este cambio. Esto es debido a que, una vez que el modelo básico de almacenamiento está establecido, no cambia; lo que se hace es añadir nuevos elementos al mismo, ya sean internos o externos.

Ahora el gran problema es el siguiente:

¿Cómo hago para “migrar” el disco duro de este formato a un volumen lógico en el LVM-Thin que viene configurado ya por defecto? 🙁

Solución:

Reza un viejo adagio que “si no tienes nada en ‘el saco’, no puedes pensar bien”, y es una gran verdad. Fui a almorzar (llenar el saco), y luego me dispuse a reposar (para pensar mejor). Ya ahí se me encendió el bombillo.

En el Anexo 2 de este manual se explica un método para redimensionar imágenes de discos duros virtuales mediante el CLI o Shell de Proxmox VE. De ahí solamente interesa la parte del montaje o conexión a la imagen de disco duro virtual específica utilizando un dispositivo NBD.

Tomando como ejemplo una máquina virtual que tengo, con ID 142 y donde se aloja un sensor AlienVault OSSIM, explicaré la secuencia de pasos:

1.- Apagar la VM que se pretende migrar

Con esto granatizamos que el disco duro virtual no se esté usando para evitar la pérdida de datos importantes.

2.- Conectar la imagen qcow2 a un dispositivo NBD

root@prx4:~# qemu-nbd -c /dev/nbd0 /var/lib/vz/images/142/vm-142-disk-1.qcow2

3.- Verificar que el contenido de la imagen virtual está correcto

Para ello basta con ejecutar fdisk -l o parted para chequear si se ve la tabla de particiones. Si se ejecuta el primero, pues, se verá la lista de todas las particiones definidas en todos los dispositivos de discos que tenga el equipo. La salida que interesa es la siguiente:

root@prx4:~# fdisk –l

(…)

Disk /dev/nbd0: 160 GiB, 171798691840 bytes, 335544320 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x945b7048

 

Device      Boot     Start       End   Sectors   Size Id Type

/dev/nbd0p1 *         2048 326109183 326107136 155.5G 83 Linux

/dev/nbd0p2      326111230 335542271   9431042   4.5G  5 Extended

/dev/nbd0p5      326111232 335542271   9431040   4.5G 82 Linux swap / Solaris

Como se ve, tiene la tabla de particiones creada por el instalador del appliance AlienVault OSSIM.

4.- Crear una nueva VM con las mismas características de la que se va a migrar

El hardware virtual de la VM a migrar se muestra en la siguiente imagen:

VM 142 - Opciones

Entonces la nueva máquina virtual tiene que ser idéntica a la que se pretende “copiar”, claro con la diferencia de que el disco duro ahora es un volumen lógico:

VM 143 - Opciones

Una vez creada, se puede ver que ahora existe un nuevo volumen lógico de 160 GB, claro está, sin espacio mapeado aún:

root@prx4:~# lvdisplay

(…)

  — Logical volume —

  LV Path                /dev/pve/vm-143-disk-1

  LV Name                vm-143-disk-1

  VG Name                pve

  LV UUID                5xMvdQ-H7QV-PbMl-S42n-4l3Q-MnbR-dBUsuc

  LV Write Access        read/write

  LV Creation host, time prx4, 2016-10-13 14:42:28 -0400

  LV Pool name           data

  LV Status              available

  # open                 0

  LV Size                160.00 GiB

  Mapped size            0.00%

  Current LE             40960

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  – currently set to     256

  Block device           251:6

Ya en este punto se tienen las condiciones necesarias para realizar el siguiente paso.

5.- Copia completa de los datos del dispositivo NBD montado al nuevo volumen lógico recién creado

Sí, el paso que ahora toca es la copia completa de los datos de un dispositivo a otro con el comando dd:

root@prx4:~# dd if=/dev/nbd0 of=/dev/pve/vm-143-disk-1

335544320+0 records in

335544320+0 records out

171798691840 bytes (172 GB) copied, 5467.38 s, 31.4 MB/s

Está demás decir que esto require de mucha paciencia, dado que es copiar una buena cantidad de datos de un dispositivo a otro.

Una vez terminado, ya se ve que el volumen lógico tiene el 100% del espacio mapeado:

root@prx4:~# lvdisplay

(…)

  — Logical volume —

  LV Path                /dev/pve/vm-143-disk-1

  LV Name                vm-143-disk-1

  VG Name                pve

  LV UUID                5xMvdQ-H7QV-PbMl-S42n-4l3Q-MnbR-dBUsuc

  LV Write Access        read/write

  LV Creation host, time prx4, 2016-10-13 14:42:28 -0400

  LV Pool name           data

  LV Status              available

  # open                 0

  LV Size                160.00 GiB

  Mapped size            100.00%

  Current LE             40960

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  – currently set to     256

  Block device           251:6

O sea, los 160GB ya utilizados en el LVM-Thin:

Estado del Almacenamiento LVM-Thin

Y si se desea ver el estado del particionado de los discos o particiones montadas, también hay sus cambios:

root@prx4:~# fdisk –l

(…)

Disk /dev/nbd0: 160 GiB, 171798691840 bytes, 335544320 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x945b7048

 

Device      Boot     Start       End   Sectors   Size Id Type

/dev/nbd0p1 *         2048 326109183 326107136 155.5G 83 Linux

/dev/nbd0p2      326111230 335542271   9431042   4.5G  5 Extended

/dev/nbd0p5      326111232 335542271   9431040   4.5G 82 Linux swap / Solaris

 

Disk /dev/mapper/pve-vm–143–disk–1: 160 GiB, 171798691840 bytes, 335544320 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 524288 bytes / 524288 bytes

Disklabel type: dos

Disk identifier: 0x945b7048

 

Device                             Boot     Start       End   Sectors   Size Id Type

/dev/mapper/pve-vm–143–disk–1p1 *         2048 326109183 326107136 155.5G 83 Linux

/dev/mapper/pve-vm–143–disk–1p2      326111230 335542271   9431042   4.5G  5 Extended

/dev/mapper/pve-vm–143–disk–1p5      326111232 335542271   9431040   4.5G 82 Linux swap / Solaris

 

Partition 3 does not start on physical sector boundary.

6.- Encender la nueva VM

Felizmente se ve cómo inicia la nueva VM sin problemas hasta que pone el prompt de inicio de sesión:

VM 143 - Consola

Aunque también se puede ver el estado de funcionamiento del sensor en el Servidor USM de AlienVault al cual le tributa los datos que va recogiendo.

7.- Desconectar el dispositivo NBD y desactivar el módulo del kernel NBD

Finalmente toca el turno de “recoger la casa”, en otras palabras, de desconectar el dispositivo NBD asociado al disco virtual original para que no se quede abierto innecesariamente, y luego, descargar el módulo del kernel NBD cargado previamente:

root@prx4:~# qemu-nbd –disconnect /dev/nbd0

/dev/nbd0 disconnected

root@prx4:~# modprobe -rv nbd

rmmod nbd

root@prx4:~#

Y con esta secuencia de pasos se pudo resolver el problema planteado. Claro está que puede que no sea una solución óptima, pero fue la que dio, al menos, un resultado palpable. 🙂

Estado del Almacenamiento Local Principal despues del cambio - Nodo

P.D.: Simultáneamente estoy llevando a la práctica un nuevo proyecto de modificación del cortafuegos de mis nodos basada enteramente en grupos de seguridad (basado en la configuración de un colega administrador de una de las empresas que atiendo), dejando la posibilidad de establecer reglas de cortafuegos sueltas para situaciones específicas. En cuanto lo termine y pase exitosamente el período de prueba, crearé el manual asociado. 🙂

One Comment

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *