I'm not sure I understand your point, but neither Virtual size nor Actual size has anything to do with "used size".
Virtual size = the size you chose at VM creation, i.e. this is the capacity of the drive.
Actual size = how much
host disk space has been allocated so far. If this equals virtual size then it's most usually because you created a fixed size disk - but the graphic above says otherwise, so the other reason is because every sector on the drive has now been written to. Usually you'd have to have done something unexpected like run a disk surface test for this to happen.
Used size = how much data the guest OS reports as being
currently stored on the disk, this number is not relevant to VirtualBox or to either of the above numbers, and is especially irrelevant if you selected a fixed size disk. For a dynamic disk all VirtualBox knows is how many sectors have been written to.
If you have accidentally made the disk grow to max size (e.g. with that surface write test) then you can fix it by compacting the disk. The easiest way would be using
CloneVDI. Be sure to set the "Keep UUID" checkbox so that the compacted clone will be a direct replacement after it's renamed.
Edit.
DANGER DANGER. One obstacle I've just noticed is that the VDI seems to be a "difference disk", i.e. it isn't a stand alone disk. Given the VDI name this must be a linked clone. It looks like you maxed out the original VDI size (or it's a fixed size disk) and
then you created the linked clone presented above. You can't compact a linked clone or the original VM it's based on, and you can't compact fixed size disks. You'll need to turn both clones into stand alone VMs (by cloning) in order to sort this mess out.