virt-resize applied to Debian GNU/Linux cloud images

The Debian GNU/Linux cloud images can conveniently be used out of the box with the following:

$ wget -O debian.qcow2
$ virt-sysprep -a debian.qcow2 --run-command 'dpkg-reconfigure --frontend=noninteractive openssh-server' --ssh-inject debian:file:$HOME/.ssh/
$ virt-install --connect qemu:///system --boot hd --name debian --memory 1024 --vcpus 1 --cpu host --disk path=$(pwd)/debian.qcow2,bus=virtio,format=qcow2 --os-type=linux --os-variant=debian10 --graphics vnc --noautoconsole
$ virsh  --connect qemu:///system domifaddr debian
 Name       MAC address          Protocol     Address
 vnet0      52:54:00:3e:6f:1a    ipv4
$ ssh debian@ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       1.9G  1.3G  481M  73% /

However, 2GB for the root file system may not be enough: virt-resize and virt-rescue should be used to expand it.

The partitions of the Debian GNU/Linux cloud image are as follows:

$ sudo virt-filesystems --long --parts -h -a debian.qcow2
Name        Type       MBR  Size  Parent
/dev/sda1   partition  -    1,9G  /dev/sda
/dev/sda14  partition  -    3,0M  /dev/sda
/dev/sda15  partition  -    124M  /dev/sda

When resizing, partitions are shuffled because it is only possible to expand the last partition of the disk. And the partition we want to expand is the first one. Reason why /dev/sda1 is copied to /dev/sda3.

$ qemu-img create -f qcow2 -o preallocation=metadata mydebian.qcow2 5G
Formatting 'mydebian.qcow2', fmt=qcow2 size=5368709120 cluster_size=65536 preallocation=metadata lazy_refcounts=off refcount_bits=16
$ sudo virt-resize --expand /dev/sda1 debian.qcow2 mydebian.qcow2 
[   0.0] Examining debian.qcow2

Summary of changes:

/dev/sda14: This partition will be left alone.

/dev/sda15: This partition will be left alone.

/dev/sda1: This partition will be resized from 1.9G to 4.9G.  The 
filesystem ext4 on /dev/sda1 will be expanded using the ‘resize2fs’ 

[   3.8] Setting up initial partition table on mydebian.qcow2
[  15.3] Copying /dev/sda14
[  15.4] Copying /dev/sda15
[  15.6] Copying /dev/sda1
 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ --:--
[  19.2] Expanding /dev/sda1 (now /dev/sda3) 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.
$ sudo virt-filesystems --long --parts -h -a mydebian.qcow2 
Name       Type       MBR  Size  Parent
/dev/sda1  partition  -    3,0M  /dev/sda
/dev/sda2  partition  -    124M  /dev/sda
/dev/sda3  partition  -    4,9G  /dev/sda

As a consequence grub no longer knows how to boot the disk:

It needs to be re-installed with virt-rescue as follows:

$ sudo virt-rescue --connect qemu:///system -d mydebian -i
supermin: mounting /proc
supermin: ext2 mini initrd starting up: 5.1.20
Starting /init script ..
><rescue> chroot /sysroot
><rescue> grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
><rescue> df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       4.8G  773M  3.8G  17% /
/dev/sda2       124M  262K  124M   1% /boot/efi
/dev            361M     0  361M   0% /dev
shmfs           365M     0  365M   0% /dev/shm
><rescue> exit
virt-rescue: Syncing the disk now before exiting ...
[  121.165106] reboot: Restarting system