Назад | Перейти на главную страницу

QEMU - неверный реальный размер диска виртуального диска

df и ls сообщать о разных размерах на моем хост-компьютере из-за разницы между выделенным размером и объемом пространства, которое фактически используется в файловой системе EXT4. Проблема в том, что оба сообщают неправильный размер. qemu-img также не сообщает фактическое пространство, используемое в файловой системе гостя (также EXT4).

На хосте:

# qemu-img info sdb.raw
image: sdb.raw
file format: raw
virtual size: 2.0T (2173253451776 bytes)
disk size: 1.9T

# ls -larth sdb.raw 
-rw-r--r-- 1 hypervisor hypervisor 2.0T Mar  6 13:47 sdb.raw

# du -sh sdb.raw 
1.9T   sdb.raw

# fdisk -l sdb.raw 
Disk sdb.raw: 2 TiB, 2173253451776 bytes, 4244635648 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: gpt
Disk identifier: E6242A7E-1253-E74A-9389-68654A21E4F4

Device     Start        End    Sectors Size Type
sdb.raw1    2048 4244635614 4244633567   2T Linux filesystem

На гостевой (/ dev / vdb1):

# df -h
Filesystem      Size  Used Avail Use% Mounted on
dev              32G     0   32G   0% /dev
run              32G  496K   32G   1% /run
/dev/vda2       220G  100G  111G  48% /
tmpfs            32G     0   32G   0% /dev/shm
tmpfs            32G     0   32G   0% /sys/fs/cgroup
tmpfs            32G   26M   32G   1% /tmp
/dev/vdb1       2.0T  761G  1.2T  41% /root
tmpfs           6.3G     0  6.3G   0% /run/user/1002

Как видите, я использую только 761G в гостевой системе, и еще доступно 1,2T. Несмотря на это, qemu-img говорит, что использую 1.9T. В чем причина? Есть способ исправить это? Я хотел бы увидеть фактическое используемое пространство на хост-машине. Я знаю, что это возможно, потому что он работал правильно до того, как я заполнил sdb.raw с данными - qemu сообщил правильный размер диска, основанный на пространстве, используемом внутри диска. К сожалению, сработало только одно - когда постепенно увеличивалась занимаемая площадь. После того, как я удалил некоторые файлы и уменьшил используемое пространство с 1,9 ТБ до 761 ГБ, размер, указанный в qemu-img на меньшее значение не изменилось, осталось 1,9T.

qemu-img и du оба сообщают фактическое выделенное пространство с точки зрения хозяина. Они не могут знать / понять, действительно ли гостевая ОС использует это пространство или, как в вашем случае, оно было освобождено пользователем.

Чтобы сообщить хозяину, что у вашего гостя много свободного места, вам необходимо fstrim ваша гостевая файловая система и вы должны быть уверены, что стек вашего qemu / гостевого блочного устройства правильно передается вниз TRIM/discard Запросы. Для этого вам необходимо:

  • используйте драйвер блочного устройства qemu с поддержкой TRIM / discard. Примеры таких приводов: virtio-scsi, scsi и sata/ahci. Все эти драйверы выставляют блочные устройства с помощью классического /dev/sd[abcd...] номенклатура. С другой стороны, похоже, что ваш гость использует простой virtio водитель (с /dev/vd[abcd...] имена), что делает не поддержка TRIM / Discard. Вы можете проверить, не поддерживает ли ваш драйвер поддержку, выполнив lsblk -D;

  • включить относительный домен libvirt discard=unmap вариант;

Наконец, ваш хост должен использовать файловую систему с hole_punching поддерживает как ext4 (который вы используете), так и xfs.

Ты можешь читать Вот для получения дополнительной информации.

Если все предпосылки верны, выдача fstrim <mount_point> внутри вашего гостя также автоматически освободит неиспользуемое пространство на хосте. Обязательно поймите, что логический / кажущийся размер файла останется неизменным (то есть: он будет показывать 2,0 ТБ после fstrim), но используя qemu-img или du покажет истинный (меньший) размер выделенного файла.

Если предварительные условия не выполнены, вам необходимо автономно сжать файл изображения с помощью virt-sparsify или qemu-img convert после очистки гостевого свободного места нулями (например: dd if=/dev/zero of=bigfile bs=1M count=<almost_all_free_space>; rm bigfile).

Убедитесь, что вы понимаете, что означают вышеуказанные шаги: любая ошибка может безвозвратно повредить ваш файл изображения. И убедитесь, что у вас есть надежная резервная копия, прежде чем пытаться выполнять какие-либо операции с файлом образа диска! *

Это ожидаемое поведение. Как вы писали, «после того, как я удалил некоторые файлы и уменьшил используемое пространство с 1.9T до 761G» - необработанный виртуальный образ не может «собирать мусор» автоматически, и реальное пространство останется записанным и выделенным даже для удаленных файлов. Обходной путь - выполнить (двойное) преобразование raw> qcow2 (> raw).

Более подробно объяснено здесь - https://balau82.wordpress.com/2011/05/08/qemu-raw-images-real-size/ и тут - https://techpiezo.com/tech-insights/raw-vs-qcow2-disk-images-in-qemu-kvm/