QEMU/KVM Resize of qcow2 Image Not Achieving Goal.

Hi, I have a tumbleweed VM under QEMU/KVM. I used a conservative disk size of 8GB when I first created the VM.

It’s last and current update is 20211202.

anon@linux-titj:~> cat /etc/os-release 
NAME="openSUSE Tumbleweed"
# VERSION="20211202"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20211202"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20211202"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed"
anon@linux-titj:~>

In doing an update today it seems I have run out of VM disk space for ‘zypper dup’ to download some 2400 packages. So I resized the qcow2 image to 15GB using qemu-img tool and fdisk as per this video -

https://www.youtube.com/watch?v=N7wvqHvmSN8

That is -

sudo qemu-img resize /data/chris/libvirt/images/tumbleweed-Finance.qcow2 15G
Image resized.

Now the disk size according to lsblk is

anon@linux-titj:~> lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sr0     11:0    1 1024M  0 rom  
vda    253:0    0   15G  0 disk 
├─vda1 253:1    0  500M  0 part /boot/efi
└─vda2 253:2    0 14.5G  0 part /srv
                                /boot/grub2/x86_64-efi
                                /var
                                /opt
                                /usr/local
                                /tmp
                                /home
                                /root
                                /boot/grub2/i386-pc
                                /


Looks good but ‘zypper dup’ still fails. However, df -h shows me that the disk hasn’t increased size.

anon@linux-titj:~> df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        969M     0  969M   0% /dev
tmpfs           982M     0  982M   0% /dev/shm
tmpfs           393M  6.3M  387M   2% /run
/dev/vda2       7.6G  6.7G   15M 100% /
/dev/vda2       7.6G  6.7G   15M 100% /boot/grub2/i386-pc
/dev/vda2       7.6G  6.7G   15M 100% /root
/dev/vda2       7.6G  6.7G   15M 100% /home
/dev/vda2       7.6G  6.7G   15M 100% /tmp
/dev/vda2       7.6G  6.7G   15M 100% /usr/local
/dev/vda2       7.6G  6.7G   15M 100% /opt
/dev/vda2       7.6G  6.7G   15M 100% /var
/dev/vda2       7.6G  6.7G   15M 100% /boot/grub2/x86_64-efi
/dev/vda2       7.6G  6.7G   15M 100% /srv
/dev/vda1       500M  5.1M  495M   2% /boot/efi
tmpfs           197M   72K  197M   1% /run/user/1000
anon@linux-titj:~>

I don’t understand why df -h and lsblk differ in results.

However, the qcow2 image itself is still ~8GB on the host

chris@asus-roc:/data/chris/libvirt/images> ls -lh /data/chris/libvirt/images/*-Fin*
-rw------- 1 qemu qemu 7.6G Mar  4 15:24 /data/chris/libvirt/images/tumbleweed-Finance.qcow2


I can’t figure out why the disk resize doesn’t appear to work as expected.

Help?

Thanks.

Filesystem size is fixed on creation. You need to resize filesystem as well.

btrfs filesystem resize max /

Please try to understand the difference between the box/container/volume and it’s contents.

The latter is in this case a file system, which is a rather organized thingy. Has inodes all over the space, chains of used and free space back- and forward. And that organized structure must be expanded to fill the space available.

https://en.opensuse.org/SDB%3ABasics_of_partitions,_filesystems,_mount_points

Your host uses btrfs. Always display file system usage as follows:

**erlangen:~ #** btrfs filesystem usage -T / 
Overall: 
    Device size:                   1.82TiB 
    Device allocated:            407.07GiB 
    Device unallocated:            1.42TiB 
    Device missing:                  0.00B 
    Used:                        388.56GiB 
    Free (estimated):              1.44TiB      (min: 743.78GiB) 
    Free (statfs, df):             1.44TiB 
    Data ratio:                       1.00 
    Metadata ratio:                   2.00 
    Global reserve:              512.00MiB      (used: 0.00B) 
    Multiple profiles:                  no 

                  Data      Metadata System               
Id Path           single    DUP      DUP      Unallocated 
-- -------------- --------- -------- -------- ----------- 
 1 /dev/nvme0n1p2 401.01GiB  6.00GiB 64.00MiB     1.42TiB 
-- -------------- --------- -------- -------- ----------- 
   Total          401.01GiB  3.00GiB 32.00MiB     1.42TiB 
   Used           384.95GiB  1.81GiB 64.00KiB             
**erlangen:~ #**

Thank you, that fixed it.

anon@linux-titj:~> sudo !!
sudo btrfs filesystem usage -T /
[sudo] password for root: 
Overall:
    Device size:          14.51GiB
    Device allocated:           9.51GiB
    Device unallocated:           5.00GiB
    Device missing:             0.00B
    Used:               6.76GiB
    Free (estimated):           6.96GiB    (min: 4.46GiB)
    Free (statfs, df):           6.96GiB
    Data ratio:                  1.00
    Metadata ratio:              2.00
    Global reserve:          19.78MiB    (used: 0.00B)
    Multiple profiles:                no

             Data    Metadata  System              
Id Path      single  DUP       DUP      Unallocated
-- --------- ------- --------- -------- -----------
 1 /dev/vda2 8.27GiB   1.22GiB 16.00MiB     5.00GiB
-- --------- ------- --------- -------- -----------
   Total     8.27GiB 626.94MiB  8.00MiB     5.00GiB
   Used      6.31GiB 234.45MiB 16.00KiB            
anon@linux-titj:~>

hcvv Please try to understand the difference between the box/container/volume and it’s contents.

The latter is in this case a file system, which is a rather organized thingy. Has inodes all over the space, chains of used and free space back- and forward. And that organized structure must be expanded to fill the space available.

https://en.opensuse.org/SDB%3ABasics…,_mount_points

Thanks. I’ll have a read of that this weekend.