QEMU/KVM Resize of qcow2 Image Not Achieving Goal.

English Virtualization
1

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.

2

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

btrfs filesystem resize max /
3

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

4

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:~ #**
5

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.