In a conversation with cwalters he said:
ok here's the deal, qcow2 is a thin-provisioned disk format, fedora uses 40GB by default for vagrant
that's defined here: https://pagure.io/releng/blob/master/f/scripts/build-cloud-images#_68
now where's that 3GB coming from? here: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base-vagrant.ks
that includes https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n46
that's outside the VM
now inside, cloud-init normally starts and uses "growpart" early on boot
except in vagrant, it's disabled because hardcoded ssh keys and stuff
so typing: growpart /dev/vda 1
then resize2fs /dev/vda1
i'd say this is really a fedora build system bug - the kickstart should match the qcow2
it's a one liner fix to spin-kickstarts
So while his commands work I couldn't find a way to get them in early enough to solve my disk space usage problems. But something is wrong when vagrant+libvirt images are only 3G and don't auto-grow, for sure.
I ran into this problem, and fortunately these commands worked for me.
Holy wow, you can resize a filesystem while it's mounted these days?! We truly live in the future!
Hey eparis. I think this was an issue for F22 because the --grow line wasn't in the kickstart for F22:
[root@f22tunir ~]# cat /etc/redhat-release
Fedora release 22 (Twenty Two)
[root@f22tunir ~]# cat /root/anaconda-ks.cfg | grep -P "^part"
part / --fstype="ext4" --size=3000
The part line  in the kickstart now properly uses --grow to grow the partition to full disk size. The filesystem for /dev/vda1 is 40G for the most recent F23 nightly .
So this issue is fixed for F23.
to comment on this ticket.