decrease image disk size

[niki-on-github]

Would it also be possible to provide a 32g size image for libvirt freebsd13 vagrant boxes? Since your images are the only bsd images for libvirt I have found that are updated regularly.

It looks like the image size has been increased due to #93 a84979021bbedc441b2d9d30fbe9a68223d2c3ee.

But Increasing the size of an image is not a problem with a vagrant disksize + provision script (for libvirt provider) it would be better to provide a smaller image since I haven't found an automated method to make the image smaller again. If someone knows an automated method to reduce the image size I would be open for this solution. For my understanding it would theoretical require to run the following steps in an automated way:

• Start box and decrease partition size
• Stop box and decrease image size from host
• Start box and continue provisioning with vagrant

Providing a smaller default image looks like the better solution to me.

[ladar]

If you're using "sparse" disk images, then only the blocks used will be allocated on disk. You can also add this to the Vagrantfile:

    v.disk_driver :bus => 'scsi', :discard => 'ignore', :detect_zeroes => 'off', :io => 'threads', :cache => 'unsafe'

That will cause QEMU to free up disk space when a guest frees it. The lineage.tpl template in this repo has an example. You'll need a recent version of libvirt/qemu/vagrant/vagrant-libvirt for this to work, and it might still only work if the qcow2 file is on an SSD/NVME.

If that doesn't work you can use the zero fill method. Look at the zerodisk.sh script for an example, but if you fill the empty space with zeros, you can shutdown the box and use the qemu-img tool to shrink the qcow2 file.

If that doesn't work, you can edit the generic-libvirt.json file to use a smaller disk, and then run:

./robox.sh box generic-freebsd13-libvirt

To build an image with a smaller disk size. You could also set the disk size via the Vagrantfile bud you'd need to use Gparted, or some other tool to resize the disk partition table.

[niki-on-github]

Thank you for the detailed response it has helped me a lot.

[Reiner030]

But the main problem here still exists, that the VIRTUAL disksize is e.g. still 128 GB in size for generic/debian11 image which can't be decreased in size If i would have / have to use only one small 16 GB hyper-v instance.

Like initially written it's always a much smaller problem to increase than decrease a partition even I have found a longer solution for online shrinking of a root partition here: https://askubuntu.com/questions/24027/how-can-i-resize-an-ext-root-partition-at-runtime

So I am wondering why this issue was closed by roboxes team while referenced increase #93 issue is still opened... ???

Maybe there can be an easy solution for both sides by e.g.

• offering a huge and a small image version?
• offering the huge version but only with ext4 setup to e.g. 8GB which can be expanded easily by "resize2fs -M /dev/sda3" if needed - maybe by an updated vagrant-disksize or similar vagrant-roboxes-size plugin which supports this command in setup. It would be OK if the partition table is already 128GB in size with your disk_driver hint.

[ladar]

@Reiner030 issue #93 is open, because Inever went back and closed it once the issue was resolved. Usually I leave issues open for awhile because there is a lag between the fix (or potential) fix getting committed, then another delay for the next box rebuild, and then yet another delay between when the build finishes, and I verify everything worked. If any box configs fail (1-10 failures per build is common), there is another lag until I can resolve those issues and upload/release the box files and a user can reply that it fixes the issue in question.

As for your scenario, I think the larger default disk size seems to make more people happy, than the 32GB size, and then 64GB size we've used previously.

As for growing partitions, you need to keep in my we have close to 40 distros at this point, using a wide variety of filesystems, etc. Some distros make growing the partition easy. Some use LVM which also makes it easier to grow a disk. But there isn't a good "universal" solution for resizing. Booting something like gparted to resize the disk works well, and handle most common file system setups, but doesn't automate.

Vagrant has a lot of code for configuring elements like networking, etc, and can deal with the variations between hypervisors, and OSes. Getting vagrant to add support for re-sizing disks during provisions would be great. But it would also take a lot of work.

As for creating box variations. That is actually a little more reasonable, but still difficult. It would be nice if I could build variants, like a CLI box, and a GUI desktop box, and/or x86, 32 and 64 bits, and arm 32 and 64 bit variations, and stick them all in the same repo. Then let users users pick which variation when they goto to download. A process similar to how you pick from a list of available providers when downloading boxes currently. But as far as I know, there is no way of making that work. And I don't see vagrant adding it anytime soon, because there aren't many projects which could take advantage of it.

Setting up multiple repos is something I've tried to limit because it can be difficult for users understand the differences between different variations without making the box names long and cumbersome. That's why we upload the x86, 32 bit box versions to a completely different organization (generic-x32). But with 6 hypervisors, 68 distro+release variations, it's already getting large. A full robox build generates 758 box files (currently), if you include the Magma and Lineage variants. Multiple that by 2 for cli/desktop versions, and 2 (or 3) again for different disk sizes and it gets out of hand quickly if we have to use different repos for each.

As for your specific problem, you mentioned a 16GB hyperv. Just a guess, but if your running out of space (event when the box has less than 16GB of disk space in use), then it's because blocks aren't being unmapped when files are deleted. Getting this to work properly is tricky, and can depend on your hardware (for example some require an SSD or NVMe storage to work), your host OS, the hypervisor, and finally the guest OS/config. You might want to check your setup to see if this is working properly and adjust. I know that during the Hyper-V box build process most distros are unmapping blocks correctly. I think only a couple of the BSD distros don't handle this correctly. If you find a tweak that needs to be added to make it work let me know.

Finally, like I said, it seems that if you really need boxes with a small disk, then you might try building the box files yourself. Just checkout the repo, edit the disk size and run:

./robox.sh box generic-debian11-libvirt

To build. You can swap libvirt for hyperv if that's what you need, and your running inside WSL. If you want to use DOS, then the commands are:

SET VERSION=1.0.0
packer build -only=generic-debian11-hyperv generic-hyperv.json

Adjust accordingly.