Si recientemente comentaba que había comprado un SSD para dedicarlo exclusivamente a máquinas virtuales, mientras movía imágenes qcow2 de mi antiguo almacenamiento al nuevo SSD me dió por revisar la ocupación real en disco de mis máquinas.
De un primer vistazo, esta es la situación:
Voy al directorio /virt/kvm/vms que es donde tengo las máquinas virtuales. Al listarlas, algo no cuadra ya que aparentemente la suma de la ocupación de todas ellas superaría el espacio en disco disponible:
Si lo comprobamos con la opción -s de ls podremos ver el espacio real ocupado (allocated)
-s, --size
print the allocated size of each file, in blocks
¿Qué tenemos en la primera columna? El espacio que en estos momentos ocupa en disco cada fichero. Resulta que dichos ficheros de imágenes son sparse files:
In computer science, a sparse file is a type of computer file that attempts to use file system space more efficiently when the file itself is partially empty. This is achieved by writing brief information (metadata) representing the empty blocks to disk instead of the actual “empty” space which makes up the block, using less disk space. The full block size is written to disk as the actual size only when the block contains “real” (non-empty) data.
When reading sparse files, the file system transparently converts metadata representing empty blocks into “real” blocks filled with zero bytes at runtime. The application is unaware of this conversion.
Estos ficheros qcow2 por tanto irán reclamando el espacio en disco según lo vayan necesitando (thin provisioning). ¿El límite? Si bien podemos comprobarlo con ls como hemos visto anteriormente, lo suyo es tirar de la herramienta qemu-img que es específica para este tipo de almacenamiento de máquinas virtuales. Por ejemplo, hacemos qemu-img info MID_dockers.qcow2
Vemos claramente que disk size: 3.5G corresponde a la ocupación actual en disco y virtual size: 20G (21474836480 bytes) es la ocupación máxima que puede alcanzar.