The issue here is that the image download takes a significant amount of time (anecdotally, 30-60 seconds). The image itself is of a 14 GB disk. But, per @jcs, if we could initially make the image's disk only as big as necessary (2 GB?) and then dynamically expand it at run-time using Vagrant, we could see a nice performance improvement.
However, once Vagrant expands the disk, something (the guest?) will have to expand the partition and then the guest will have to expand the file system. Some guests, like OpenBSD, do not have great support for this. Others, like NetBSD and FreeBSD, do.
Vagrant: expand "disk."
Expand partition.
Guest: Expand file system.
The other point to keep in mind is that this will have the most impact from having a one-partition disk, so that all the "file systems" can make use of the new space. So, this will require some changes to the Packer HCL files to adjust their installation layout.
The issue here is that the image download takes a significant amount of time (anecdotally, 30-60 seconds). The image itself is of a 14 GB disk. But, per @jcs, if we could initially make the image's disk only as big as necessary (2 GB?) and then dynamically expand it at run-time using Vagrant, we could see a nice performance improvement.
Fortunately, Vagrant and Virtualbox have (experimental) support for this: https://www.vagrantup.com/docs/disks.
However, once Vagrant expands the disk, something (the guest?) will have to expand the partition and then the guest will have to expand the file system. Some guests, like OpenBSD, do not have great support for this. Others, like NetBSD and FreeBSD, do.
The other point to keep in mind is that this will have the most impact from having a one-partition disk, so that all the "file systems" can make use of the new space. So, this will require some changes to the Packer HCL files to adjust their installation layout.