Reducción de la imagen qcow2 en Libvirt KVM

¿Alguna vez ha reducido el tamaño de la imagen de disco qcow2 utilizada en las máquinas virtuales KVM-QEMU? Como sabes, el proceso de aumentar el tamaño de una imagen es bastante simple y rápido, pero ¿qué pasa con la reducción?



En este artículo, le contaré sobre la situación en la que necesita reducir la imagen qcow2 de la máquina virtual KVM lo más rápido posible.



Formato de dispositivo de bloque - qcow2



Pero, sin embargo, este esquema se puede hacer con imágenes en bruto, basta con convertirlo a qcow2. En general, las instrucciones serán relevantes para todo lo que se convierta a qcow2.



Una forma sencilla de encoger el disco en KVM es la siguiente:



  1. Comprimir un dispositivo de bloque qcow2 (disco VM)
  2. Hacer un disco más pequeño
  3. Montaje de imagen gparted, disco antiguo y nuevo
  4. Preparándose para arrancar el sistema operativo
  5. Especificaciones de la máquina virtual y host:


Anfitrión: CentOS 7 + QEMU 2.12 + LIBVIRT 4.5.0 + Kernel UEK5 v. 4.14

VM: CentOS 7 + HDD de 80GB + Kernel estándar v. 3.10

Una máquina virtual CentOS 7 con una imagen de disco duro de 80 GB, ocupada en realidad por 20 GB y físicamente 80 GB, actuará como donante. Lo reduciremos a 40GB.



¿Cuál es la diferencia entre el tamaño de la imagen, el tamaño real y el físico?

Digamos que la imagen de qcow2 es de 80 gb y lo sabemos. Durante la operación, la imagen se atascó con datos, se eliminaron algunos datos. En términos generales, debido a las peculiaridades del proceso de grabación y borrado de datos, para el SO, los datos borrados no parecen existir, pero quedan grabados en la imagen hasta que son sobrescritos por otros datos. En consecuencia, incluso en el sistema operativo verá 20 GB de datos realmente ocupados, el host KVM mostrará una imagen tan maravillosa (usamos la utilidad qemu-img para obtener información):



qemu-img info qcow2_image.img
image: qcow2_image.img
file format: qcow2
virtual size: 80G (85899345920 bytes)
disk size: 80G
cluster_size: 65536
Format specific information:
compat: 0.10
refcount bits: 16


Puede ver que tamaño virtual = tamaño del disco, así como du -sh de la imagen mostrará que ocupa 80G reales:



du -sh qcow2_image.img
80G    qcow2_image.img


Y dado que necesitamos reducir el tamaño de la imagen a 40 GB, comencemos el proceso.



Etapa 1 - Comprimir el dispositivo de bloque (imagen)



Antes de comenzar el procedimiento para reducir el disco, debe asegurarse de que el espacio ocupado dentro del sistema operativo sea menor que el volumen al que se reducirá el disco de una forma u otra.



df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        80G   18G   63G  22% /


Como podemos ver, 18GB están ocupados, que es menos de 40GB. Apague la VM con el comando



shutdown -h now


Y vaya a la máquina host, verifique:



  • cuanto toma la imagen físicamente
  • cuanto realmente


# qemu-img info qcow_shrink
image: qcow_shrink
file format: qcow2
virtual size: 80G (85899345920 bytes)
disk size: 80G
cluster_size: 65536
Format specific information:
    compat: 0.10
    refcount bits: 16
# virt-df -h qcow_shrink
du -sh Filesystem                                Size       Used  Available  Use%
qcow_shrink:/dev/sda1                     488M       101M       351M   21%
qcow_shrink:/dev/sda2                      79G        17G        62G   22%
# du -sh qcow_shrink
80G     qcow_shrink


Para comprimir la imagen, necesitamos una utilidad simple llamada virt-sparsify . Asegúrese de que la VM no esté funcionando y ejecute el comando en el directorio junto con la imagen del disco (Nota importante: antes de iniciar virt-sparsify , asegúrese de que haya suficiente espacio libre en / tmp y en el almacenamiento de imágenes para realizar la operación)



virt-sparsify qcow_shrink qcow_shrink-new


La finalización satisfactoria de la operación dará como resultado el siguiente resultado:



[   0.0] Create overlay file in /tmp to protect source disk
[   0.1] Examine source disk
[   1.2] Fill free space in /dev/sda1 with zero
[   1.5] Fill free space in /dev/sda2 with zero
 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
[  72.5] Copy to destination and make sparse
[  81.9] Sparsify operation completed with no errors.
virt-sparsify: Before deleting the old disk, carefully check that the
target disk boots and works correctly.


Luego intercambiamos el disco (movemos qcow_shrink a algún lado, por ejemplo qcow_shrink-old , y qcow_shrink-new en su lugar - qcow_shrink ).



mv qcow_shrink qcow_shrink-old && mv qcow_shrink-new qcow_shrink


Iniciamos la VM. Si todo empieza, apagamos la VM y seguimos trabajando.



Etapa 2: crea un disco más pequeño



Un procedimiento simple con un solo comando:



qemu-img create -f qcow2 -o preallocation=metadata qcow_shrinked 40G


qcow_shrinked - nuevo nombre de imagen

40G - nuevo tamaño



Etapa 3 - conectando gparted



Dado que a veces los administradores prefieren formas más fáciles de resolver el problema, la pandereta se deja de lado (kpartx) e ISO y VNC entran en su lugar. Afortunadamente, no es muy difícil conectarlo en KVM.



Que hacemos:



  • Conecte la imagen ISO GParted
  • Conectar qcow2_shrinked a VM
  • Inicie VM, arranque desde ISO


Omitiré cómo hacer esto de este artículo, ya que se asume que la persona que hace todo esto ya sabe cómo sucede, pero el resultado será el siguiente:



imagen



Inicie la VM y vea la pantalla de inicio de GParted:



imagen



Seleccione el primer elemento y siga las instrucciones en la pantalla. Normalmente presiono enter hasta el final.



imagen



Al ver GParted en sí, pongámonos a la acción. Verificamos rápidamente si / dev / vda tiene una tabla de particiones: msdos o gpt . Esto es importante:



imagen



cambie al segundo disco / dev / vdb y cree la tabla de particiones:



imagen



imagen



cuando cree la tabla, seleccione el tipo msdos como aprendimos anteriormente.



Luego vuelva a / dev / vday secuencialmente, desde los primeros discos, comenzamos a copiar particiones, cambiando entre vda y vdb :



imagen



El resultado final será:



imagen



Presiona Aplicar y espera a que se complete el resultado:



imagen



Como resultado:



imagen



Eso ya parece la verdad. Pero dado que hemos realizado algunas manipulaciones que llevarán a cambiar los UUID de los discos, es posible que no arranquemos en el sistema operativo. ¿Por qué? CentOS 7 usa UUID de disco en fstab, Grub2 usa UUID de disco, así que salte a la consola y haga magia negra.



Gparted funciona inicialmente como usuario, así que saltamos bajo root con el comando sudo su - root :



imagen



vamos a blkid para asegurarnos de que el UUID de las particiones ha cambiado



imagen



Se puede ver que el UUID vda1 = vdb1, pero para vdb2 ha cambiado. Está bien, puedes vivir con eso.



Monte vdb completamente, junto con la partición / boot, y monte algunas particiones para nuestra conveniencia.



mkdir vdb2
mount /dev/vdb2 vdb2
mount /dev/vdb1 vdb2/boot
cd vdb2
mount --bind /dev dev
mount --bind /sys sys
mount --bind /proc proc
chroot .


Comencemos con fstab: dado que no es muy conveniente escribir el UUID en VNC, lo reemplazaremos con el nombre del dispositivo familiar.



imagen



Reemplazamos la línea con UUID = ... por, atención :



especificamos / dev / vdb2 , si no se planea desconectar el disco antiguo ,

especificamos / dev / vda2 , si el disco antiguo está desconectado



Como desconectamos el disco antiguo antes de cargar el SO, entonces escribimos / dev / vda2



Siguiente cambiemos el gestor de arranque, ponlo en orden. Supongamos que todo está en / boot / grub2, grub.cfg está en el mismo lugar, pero efi no (tabla msdos, que es efi :)):



grub2-install /dev/vdb
cd /boot/grub2
grub2-mkconfig -o grub.cfg


En esto, puede ser feliz por usted mismo y al deshabilitar gparted, inicie el sistema operativo.



Etapa 4: iniciar el sistema operativo



Antes de cargar el sistema operativo, todavía recomiendo desconectar el disco antiguo del servidor. Por lo tanto, en la etapa anterior, vda2 tenía que estar registrado en fstab, pero si eres un usuario atento de PC y no desconectaste nada, entonces no debería haber problemas. Con un disco antiguo, es muy probable que arranque desde él.



Durante el proceso de arranque, no surgieron problemas, el servidor arrancó como se esperaba. Revisemos esto:



[root@shrink ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        484M     0  484M   0% /dev
tmpfs           496M     0  496M   0% /dev/shm
tmpfs           496M  6.7M  489M   2% /run
tmpfs           496M     0  496M   0% /sys/fs/cgroup
/dev/vdb2        40G   18G   23G  44% /
/dev/vdb1       488M  101M  352M  23% /boot
tmpfs           100M     0  100M   0% /run/user/0

[root@shrink ~]# blkid
/dev/vda1: UUID="ea505196-32fb-4df6-8bed-0a0ab2d0b726" TYPE="ext4"
/dev/vda2: UUID="30ec1bc6-658f-4611-8708-5e3b7ebaa467" TYPE="xfs"
/dev/vdb1: UUID="ea505196-32fb-4df6-8bed-0a0ab2d0b726" TYPE="ext4"
/dev/vdb2: UUID="c8548834-272b-4331-a9bf-aa99fb41a434" TYPE="xfs"
/dev/sr0: UUID="2019-03-21-13-42-32-00" LABEL="GParted-live" TYPE="iso9660" PTTYPE="dos"


Vemos que se requieren / boot y /, de 40 GB de tamaño, el sistema operativo se está ejecutando. ¡Felicidad, no de otra manera!



Prima



Lo que tendrás que afrontar en algunas situaciones.



  1. VM Windows, virt-sparsify . , , ( blkid), Windows , . ( ) fixmbr + rebuildbcd. — man
  2. — xfs Superblock has unknown read-only compatible features (0x4) enabled. read-only, . :


Lo más probable es que cuando todo se hizo en gparted u otro entorno, la versión del kernel de este entorno era demasiado nueva, en la que xfs se modificó ligeramente, es decir, los metadatos y su versión difieren. Como resultado, xfs hecho en el nuevo kernel se convierte en una calabaza en el antiguo. Lo que hacemos es reiniciar en el rescate gparted, elevar la red en este entorno de rescate e instalar el kernel más reciente en el sistema operativo. Instalé 5.x en CentOS 7, tal vez 4.x sea suficiente, no lo he probado, pero al final todo funcionó. Además, sin ningún problema.



¡Eso es todo!



Como puede ver, no tiene nada de complicado. Por supuesto, puede usar LVM, resize2fs y otras cosas, pero aún así qcow2 se usa en otro lugar e incluso alguien lo necesita.



Si conoce un método aún más simple, escríbalo en los comentarios.



All Articles