W ferworze walki o lepsze (bo zautomatyzowane) jutro, zacząłem ćwiczyć automatyzację dla szybkiego tworzenia i odpalania wirtualnej maszynki w KVMie. Okazało się, że obraz z bazowej Fedory Cloud 34 jest nieco za mały pod niektóre potrzeby (5GB). Padło, leninowskie “co robić?”.
Najpierw sprawdźmy, ile ma nasza kopia z bazowego obrazu FC34:
# qemu-img info sbx1u130.qcow2
image: sbx1u130.qcow2
file format: qcow2
virtual size: 5 GiB (5368709120 bytes)
disk size: 4.11 GiB
cluster_size: 65536
Format specific information:
compat: 0.10
compression type: zlib
refcount bits: 16
No i ma, 5GB i nie chce więcej. No to nie bądźmy tacy i dorzućmy z dyszkę jeszcze:
# qemu-img resize sbx1u130.qcow2 +10G
Image resized.
I jak ma? Ma.
# qemu-img info sbx1u130.qcow2
image: sbx1u130.qcow2
file format: qcow2
virtual size: 15 GiB (16106127360 bytes)
disk size: 4.11 GiB
cluster_size: 65536
Format specific information:
compat: 0.10
compression type: zlib
refcount bits: 16
Dalej jednak coś nie tak.. Przestrzeń dyskowa powiększona, a co z systemem plików? Sprawdzam na vm-ce, a tam nadal root ma 4.9GB. No właśnie. Wpisuję virt- i tabulator, więc system wyrzuca mi ze 40 podpowiedzi komend zaczynających się na virt-... Najpierw wyłączamy vm-kę, następnie sprawdzamy system plików w obrazie:
# virt-filesystems -a sbx1u130.qcow2 -h --long
Name Type VFS Label Size Parent
/dev/sda1 filesystem ext4 - 4.9G -
Czyli, mamy tam w sumie jeden system plików, który trzeba powiększyć. man virt-resize wszystko pięknie wyjaśnia. RTFM wciąż ma przyszłość. Robimy sobie kopię obrazu sbx1u130.qcow2, która będzie naszym dyskiem źródłowym do powiększenia systemu plików i zapisaniu na naszym obrazie sbx1u130.qcow2. Pora na finał z, jak piszą autorzy podręcznika, most useful option: --expand:
# virt-resize --expand /dev/sda1 sbx1u130-orig.qcow2 sbx1u130.qcow2
[ 0.0] Examining sbx1u130-orig.qcow2
**********
Summary of changes:
/dev/sda1: This partition will be resized from 5.0G to 15.0G. The
filesystem ext4 on /dev/sda1 will be expanded using the ‘resize2fs’
method.
**********
[ 1.7] Setting up initial partition table on sbx1u130.qcow2
[ 2.3] Copying /dev/sda1
100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
[ 13.4] Expanding /dev/sda1 using the ‘resize2fs’ method
Resize operation completed with no errors. Before deleting the old disk,
carefully check that the resized disk boots and works correctly.
$ ssh test@sbx1u130
[test@sbx1u130 ~]$ sudo -s
[root@sbx1u130 test]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 783M 8.6M 775M 2% /run
/dev/vda1 15G 1.4G 13G 10% /
tmpfs 2.0G 0 2.0G 0% /tmp
tmpfs 392M 0 392M 0% /run/user/1000
(Aktualizacja - 12/12/2021) Niestety ten numer nie przechodzi z chmurowymi obrazami KVM dla Debiana, mającą osobną partycję startową po systemowej. Więc po komendzie virt-resize ta partycja zostaje co prawda automatycznie “przesunięta” o powiększoną przestrzeń, ale trzeba interaktywnie z pomocą virt-rescue zainstalować tam GRUBa. Więc całą automatykę Ansibla diabli biorą. Na razie nie mam pomysłu jak to obejść.