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:
- Comprimir un dispositivo de bloque qcow2 (disco VM)
- Hacer un disco más pequeño
- Montaje de imagen gparted, disco antiguo y nuevo
- Preparándose para arrancar el sistema operativo
- 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:
Inicie la VM y vea la pantalla de inicio de GParted:
Seleccione el primer elemento y siga las instrucciones en la pantalla. Normalmente presiono enter hasta el final.
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:
cambie al segundo disco / dev / vdb y cree la tabla de particiones:
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 :
El resultado final será:
Presiona Aplicar y espera a que se complete el resultado:
Como resultado:
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 :
vamos a blkid para asegurarnos de que el UUID de las particiones ha cambiado
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.
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.
- VM Windows, virt-sparsify . , , ( blkid), Windows , . ( ) fixmbr + rebuildbcd. — man
- — 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.