evgeniymx Nov 1 2020 at 17:57

Уменьшаем qcow2 образ в Libvirt KVM

6 min

19K

Configuring Linux*Virtualization*

Comments 19

malykhin Nov 1 2020 at 21:44

Я не совсем пойму, а что мешает использовать resize2fs для qcow2?

evgeniymx Nov 2 2020 at 00:05

Ничего! Проблема в том, что shrink раздела невозможен без предварительного сжатия qcow2. Но libvirt не даст сделать shrink, если внутри образа есть разделы объемом большим, чем новый объем образа. В общем замкнутый круг получается. В любом случае перед уменьшением образа нужно будет уменьшить размер раздела. Но с xfs у меня плохо получалось это сделать, а вот ext2/3/4 вроде как можно нарезать новыми кусками. Но эта инструкция более универсальна и подходит для всех фс, и к resize2fs прибегать не надо.

malykhin Nov 2 2020 at 00:19

Ну логично, XFS не умеет уменьшаться — там только переливать данные на новый раздел.
А Ext4 вполне себе умеет, и после resize2fs можно спокойно уменьшать размер раздела (или логического тома lvm). Обычный раздел уменьшается в fdisk путем удаления и создания с новым размером (данные не теряются, но все и везде рекомендуют делать бэкап). В lvm делается lvresize. Главное с новым размером не ошибиться (особенно с единицами измерения), чтобы размер раздела случаем не стал меньше, чем размер ФС.

Ну а переливать данные в случае XFS будет проще, если подключить образ qcow2 с помощью qemu-nbd — тогда он появится в системе как диск /dev/nbdX — и с ним можно работать как с обычным диском (fdisk, dd, mount и т.п.)

evgeniymx Nov 2 2020 at 00:28

Да, всё верно, тот же fdisk с ext спокойно справляется с уменьшением разделов, удалил/создал/сохранил, главное не ошибиться с секторами. Но опять же, ситуация не универсальная, а цель статьи как раз в общем алгоритме для разных фс.

edo1h Nov 2 2020 at 02:25

Проблема в том, что shrink раздела невозможен без предварительного сжатия qcow2

можете пояснить?

evgeniymx Nov 2 2020 at 10:18

Немного некорректно сказал — без sparse, т.е. без освобождения места на хосте. В начале статьи я описал этот нюанс

edo1h Nov 3 2020 at 06:02

странно, какое дело gparted до того как qemu хранит образ диска?

evgeniymx Nov 3 2020 at 09:58

никакого, однако без sparse есть вероятность потерять данные во время уменьшения

edo1h Nov 5 2020 at 05:33

мне это утверждение кажется необоснованным

Zhyvotvoe Nov 2 2020 at 00:05

Не читал, но осуждаю.:) Шутка. Пол-года назад собирал в сети по крупицам инфу, когда надо было proxmox-виртуалку с 2Тб qcow2 диском прегнать в hyper-v, с уменьшением диска в 4 раза.

evgeniymx Nov 2 2020 at 00:11

С инфой про уменьшение всё довольно сложно, увеличить диск это вообще легко — увеличил qcow2, увечил разделы, в RO запустил resize2fs и загрузился — всё готово.

lost55 Nov 2 2020 at 01:46

ммм, внутри виртуалки
dd if=/dev/zero of=/zerofile
sync
rm /zerofile
снаружи виртуалки (виртуалка выключена)
sudo fallocate -d file.img
работает на vdi,qcow2если оня хранятся на ext4 итп ФС.

далее,
sudo losetup --show -Pvf ./file.img для raw образа, не забываем losetup -d /dev/loopN в конце.
и для qcow2
sudo modprobe nbd max_part=63
sudo qemu-nbd -c /dev/nbd0 file.qcow2
sudo partprobe /dev/nbd0
// тут творим с разделами что хотим.
sudo qemu-nbd -d /dev/nbd0

Если уменьшить раздел, то даже текущий образ уменьшать не понадобится, тк «хвост» будет почти нулевого размера.
зы, это всё не для продакшена. Только для домашних поделок, тк фактически работает «на живую».

bergentroll Nov 18 2020 at 12:39

Ещё бы снапшоты в процессе конвертации не терялись.

evgeniymx Nov 18 2020 at 12:39

Скажу больше — их надо удалить при конвертации :(

bergentroll Nov 18 2020 at 13:33

Зачем? Не поленился проверить — со напшотами и без после конвертации образ 1-в-1. (Я про внутренние снапшоты.)

evgeniymx Nov 18 2020 at 15:47

Да, я понимаю. Но лучше их иногда удалить, у меня бывали ситуации с проблемами диска, когда ОС переставала бутаться после манипуляций с образом внутри которого есть снэпшоты. Особенно частое явление, например, VMmanager (продукт для хостеров и организации VDS на KVM), очень не любит образы с снепшотами во время переноса между серверами. Поэтому вошло в привычку снепшоты удалять, проблем потом бывало меньше — да и объективно видно сколько пространства занимает образ. Но если снэпшоты критически нужны при ресайзе диска, то это отличная тема для исследования)

charliez Nov 19 2022 at 01:07

Не знаю как это было в 2020 году, но сейчас virt-sparsify имеет --in-place аргумент без всех этих танцев с gparted :)

evgeniymx Nov 20 2022 at 06:32

Танцы с gparted нужны, чтобы уменьшить размер раздела. Virt-sparsify не уменьшает разделы, не увеличивает их, а работает с файловым образом - тримит его, грубо говоря.

--in-place просто избавляет от необходимости писать во второй файл, имея х2 свободного пространства в рабочей фс. И то, есть нюансы.

charliez Nov 20 2022 at 09:47

А, я по диагонали прочитал, сорри :)

Ресайзю вниз qcow2 как-то так (внутри только один раздел ext4):

скажем, диск 40 гб, ресайзим до 30 гб:

# modprobe nbd
# qemu-nbd --connect /dev/nbd1 --aio=native --format=qcow2 --cache=none disk.qcow2
# mount /dev/nbd1p1 /mnt
# e4defrag /dev/nbd1p1
# umount /mnt
# fsck -f -y /dev/nbd1p1
# resize2fs /dev/nbd1p1 28G (на пару гигов меньше, тупо чтоб не париться с высчитыванием точных размеров партиции - дальше все выровняется до 30гб)

создаём скрипт в котором ресайзим физическую партицию в 29GB (28+1)

#! /bin/bash
/sbin/parted /dev/nbd1 ---pretend-input-tty <<EOF
resizepart
1
29000
Yes
quit
EOF

выполняем скрипт.

# qemu-nbd -d /dev/nbd1
# qemu-img resize --shrink disk.qcow2 30G
# qemu-nbd -c /dev/nbd1 disk.qcow2
# /sbin/parted -s /dev/nbd1 "resizepart 1 -1" quit
# fsck -f -y /dev/nbd1p1
# resize2fs /dev/nbd1p1

# qemu-nbd -d /dev/nbd1

Show the best of all time