virtualbox.org

So the rest of the disk can be used by the host?

Yes. If you shrink it with the "VBoxManage modifymedium <VDI> --compact", or if you use CloneVDI.

Compacting with VBoxManage will do nothing much because it only ever works if you first use zerofree/sdelete to zero out unused sectors: and zerofree/sdelete cannot access unpartitioned areas of the disk.

The compact option in CloneVDI will work (CloneVDI does recognize that unpartitioned areas can be discarded), however if the sectors in question have never been written to then there are no used sectors for it to recover.

mpack wrote:Compacting with VBoxManage will do nothing much because it only ever works if you first use zerofree/sdelete to zero out unused sectors

That's why I already stated in my first post, that I had a more "convoluted" solution in mind for that specific case (shrinking the partition):

socratis wrote:mpack, I had a more "convoluted" solution in mind, where you'd run a defragmenter on the guest, then "zerofree" (or actually "sdelete -z" for Windows), then "VBoxManage modifymedium <VDI> --compact", and then run the GParted LiveCD to shrink the partition.

>There's no magic to it. Just pick a VM that will be the guinea pig for this procedure, and add a new drive to the existing controller.

Could you please expand this explanation somewhat... I really can´t understand how to go on.

VM Settings » Storage » select the HD controller on the left hand side » press the "+" with the HD icon.

>There's no magic to it. Just pick a VM that will be the guinea pig for this procedure, and add a new drive to the existing controller. You don't need to format the drive - the disk imaging tool you use will take care of that.

Well, the difficulty was not to add a new disk with the size the we wanted, but how should we go on in order to transfer the disk content from the bigger file to the smaller?

Jiger,
I think you've missed the point. You're not going to transfer anything. You're simply going to shrink the partition. No one can write after that to the unused partition, making it "uninhabitable".

Take a look at viewtopic.php?f=3&t=86347. It includes "pictures" and explanations...

Well, Sokratis, you are back in what I understand as method 2 : shrinkimg the partition. (Why would I need a new disk in the existing controller?)
But mpack is, again according to my understanding, on another stratetrgy, method 1: which he describes as "no magic to it. Just pick a VM that will be the guinea pig for this procedure, and add a new drive to the existing controller."

I used CloneVDI including the compact alternative, which made the disk as small as we wanted. My question: How could I have the VM to use this file instead of the original one or simply how to go on with method 1?

You remove the old disk from the SATA controller, and you add the new one.
It would help you if you didn't delete the old one immediately, only after testing the new one.
It would help you in the long run, if you moved the new VDI to the same location as the old one. Good housekeeping.

After having tried to remove the old file from the SATA controller and then tried to add the new one, I get the following errror message: How do I test the new VDI and still have the old VMDK in the same location?

It´s not possible (as far as I can see) to test the new vdi-file while the old vmdk-file is left in the host folder. These are the points:

1. Use GParted or MiniTool Partiton Wizard to decrease the vmdk-partition.
2. Use CloneVDI to clone the old vmdk-file, keep settings but compact the new file.
3. Release and then remove the old vmdk-file (Virtual Media Manager).
4. Add the new vdi-file as an IDE Primary Master.
5. Restart,

I used the program DiskGenius to clone the used partion of the original vmdk-disk to the earlier created NewVirtualDisk. That worked fine and the result was a file quite smaller than the virtual disk above. I added that file to IDE Primary Master and restarted. This worked perfectly!!

THIS ISSUE IS FINALLY SOLVED!!

This thread can be closed now.