Comment 7 for bug 1974100

I've come up with a more minimal test that doesn't require the whole GNS3 infrastructure.

1. Create a one-line 'meta-data' file:

{instance-id: ubuntu, local-hostname: ubuntu}

2. Create the following 'user-data' file:

#cloud-config
hostname: ubuntu
network:
  config: disabled
resize_rootfs: noblock
users:
  - name: ubuntu
    plain_text_passwd: foobar
    lock_passwd: false
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL

3. Build a CIDATA image acceptable to cloud-init:

genisoimage -input-charset utf-8 -o cloudinit.iso -l -relaxed-filenames -V cidata -graft-points meta-data user-data

4. With a copy of Ubuntu's cloudimg in the current directory, create a 1 TB thin provisioned disk:

qemu-img create -f qcow2 -b ubuntu-20.04-server-cloudimg-amd64.img test.qcow2 1T

5. Start qemu with a VNC server on whatever port you'd like (you must be in group kvm):

qemu-system-x86_64 -enable-kvm -cdrom cloudinit.iso -drive file=test.qcow2,if=ide,media=disk,discard=on -m 4G -vnc 0.0.0.0:88 -net none

I can change ide to virtio, but if I change it to scsi it either hangs during boot (Ubuntu 18 host) or complains "machine type does not support if=scsi,bus=0,unit=0" (Ubuntu 20 host).

I can do the following to get scsi:

qemu-system-x86_64 -enable-kvm -cdrom cloudinit.iso -device virtio-scsi-pci,id=scsi -drive file=test.qcow2,id=root-img,if=none,discard=on -device scsi-hd,drive=root-img -m 4G -vnc 0.0.0.0:88 -net none

For any drive type, you start it running, let it sit there at a boot prompt, and watch the size of test.qcow2. The bad behavior is that it grows into the 30-40 GB range.

On a Ubuntu 18 host, I see the bad behavior for drive types ide and virtio. scsi seems to be OK.

On an Ubuntu 20 host, I only see the bad behavior for drive type ide. virtio and scsi seem OK.