Comment 29 for bug 1681839

Thanks++
Now that I had (new) steps to recreate I could work on those.
I wondered if an LVM is really strictly needed - which would also easen the initialization.
So I simplified it to.

$ apt install uvtool-libvirt
$ uvt-simplestreams-libvirt sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=xenial
$ uvt-kvm create xsnaptest arch=amd64 release=xenial label=daily
# depending on your apparmor config you might want to add something like this TEMPORARY to /etc/apparmor.d/abstractions/libvirt-qemu '/var/lib/uvtool/libvirt/images/* rwk,'
$ virsh snapshot-create-as --domain xsnaptest --diskspec vda,file=/var/lib/libvirt/images/xsnaptest-snapshot.qcow2,snapshot=external --disk-only --atomic

I started a loop which on one side dirtied the snapshot and on the other pivoted it.
# make dirty:
$ while /bin/true; do uvt-kvm ssh --insecure xsnaptest "dd if=/dev/urandom of=file.txt count=4096 bs=1M"; done
# snapshot, wait and pivot blockcommit
$ while virsh blockcommit xsnaptest vda --active --verbose --pivot --wait; do rm /var/lib/libvirt/images/xsnaptest-snapshot.qcow2; sleep 2s; virsh snapshot-create-as --domain xsnaptest --diskspec vda,file=/var/lib/libvirt/images/xsnaptest-snapshot.qcow2,snapshot=external --disk-only --atomic; sleep $(( RANDOM % 30 ))s; ll -h /var/lib/libvirt/images/xsnaptest-snapshot.qcow2; done

The snapshots to commit were about 200M to 6.9G, but none triggered the issue (about 40 tries in the loop).
So maybe really it only happens (much more likely) when the original backing to write back is an LVM.
Glad you found that for your test to become a reliable reproducer.