Size of Virtualbox VM .vdi file and shrinking it

Hello all,

my HA is running almost perfectly for many months now in Virtualbox. As many of you will know, the .vdi is ever increasing, especially when updates are incoming. My virtual disk is configured as 64Gb as SSD now, I already increased it from 32Gb. Just to give some numbers:
-) my Host OS is Ubuntu 20.04 it shows me a size of 44.0 Gb now
-) HA tells me 22% used 45.9Gb free (it obviously recognizes the full 64Gb is my guess)
-) my home-assistant_v2.db is approx 3.6Gb large. My recorder purge_keep_days = 60 days.

Now question to you is: how do you cope with this constant increasing of the .vdi? What is the best practice to shrink it from time to time? I am backing up my HA constantly, I know I can always start from scratch (but I’ve read a lot about backups not being fully restored etc., I want this as may last option.
Can Clonevdi cope with the free blocks in this HA.vdi? Using dd to fill empty blocks with zeros does work, filesystem is read-only for some reason. ‘Vboxmanage HA.vdi --compact’ does not work, it does not shrink the file a bit. So I am kind of stuck here.

Any suggestions are welcome, thank you,

Mario

fstrim /data” at root level ssh

This is tested in windows but should work in linux

VBoxManage storageattach ha1vm --storagectl "SATA" --port 0 --device 0 --nonrotational on --discard on

Controller needs to be named “SATA”

Hello,

I tried your second command (nonrotational was already on before via SSD-flag, I assume it is the same?).

Then, within the VM I tried ‘fstrim /’ (result: the discard operation is not supported’) and ‘fstrim /var’ (mountpoint for 99% of the space). Latter seems to be executed without error, but my .vdi is now 44.5Gb (perhaps due to addional backup during the night, not because of fstrim etc.).

Are there any other options? I am sure, thousands of users should have this problem,

thank you,

Mario.

Oh my, I did not follow your instructions correctly, it seems.

I have to ‘fstrim /mnt/data’ ! Then it works! It is shrunk to 16.7Gb (almost consistent with the 22%)!

Thank you, very much appreciated! I mark it solved,

Mario.

1 Like

Screenshot_20220918-121043_JuiceSSH

When trimming /var/lib/journal I found another 2.3Gb…

I just went through all mountpoints in lsblk, /mnt/data and /var/lib/journal (filesystem) will free the most,

Mario.