Decreasing the disk size of a VM

[Jiger]

I have Windows 10 Home as host and Windows XP pro as guest. My question: is there a simple way to decrease the VM disk size?

[mpack]

The best solution is to reduce the partition size, not the disk size. Reducing the partition size (e.g. using GParted) prevents the guest OS from writing to unpartitioned areas.

[socratis]

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.

Are you saying that simply running the GParted LiveCD would take care of all of those things in one go? I got to test it, because I've been giving the wrong advice so far! Or actually the most convoluted advice...

[Martin]

The 'classical way' would be to just add a new smaller virtual disk to your VM, then boot it with an ISO of a disk cloning tool of your choice to transfer the data and after that remove the old too big virtual disk.

[socratis]

Just for completion, there's also a not-so-risk-free option, which I haven't tried (neither I'm planning on it):

• 
  VBoxManage clonemedium <uuid|inputfile> <uuid|outputfile> --existing

From the User Manual, ch. 8.24 VBoxManage clonemedium you can see the following (emphasis mine):

--existing Perform the clone operation to an already existing destination medium. Only the portion of the source medium which fits into the destination medium is copied. This means if the destination medium is smaller than the source only a part of it is copied, and if the destination medium is larger than the source the remaining part of the destination medium is unchanged.

Which could translate to, if the data is in the "front" part of the HD (after a defragmantation perhaps?), then the 'clonemedium' option could potentially/perhaps/maybe work?

[mpack]

That would be extremely dangerous, since I would not expect to noob to know whether the guest OS has written to upper blocks or not. Lots of modern filesystems hide things in upper regions of the disk (e.g. Windows dynamic disk, and GPT). I also don't see the point in trying risky solutions after a risk free solution was already given.

[Jiger]

When trying to run Gparted from boot, I get the following error message: Input/output error during read on /dev/sdc
What is done incorrectly here?

[socratis]

With the amount of information given? Not even Pythia in Delphi could risk in predicting what's going on in your system...

• "/dev/sdc" looks like the 3rd disk on your setup. Do you really have 3 hard drives in your VM?
• "input/output error" is self explanatory I believe, something is failing to read/write to that device.

Unless we see a ZIPPED VBox.log from a complete VM session, and/or the recipe of the VM (the <VM>.vbox file) we really can't tell.

BTW, I thought that this was a hypothetical question. Your original question (Increasing the disk size of a VM) was about increasing the VDI size. What happened? You increased it too much, or is this an educational/learning question?

[Jiger]

Thanks, I simply forgot to disconnect a captured external disk.

The background is as follows: After having successfully increased the disk, we realized that there was a very voluminous program, that we didn+t want to have in the VM anymore. After having uninstalled that program, we simply changed our mind and realized that a more realistic strategy was to reduce the original VM disk.

When running GParted, I found that it simply wasn´t possible to reduce the disk by mouse drawing from the right to the left and changing the figures in the table wasn´t possible either as the alternative reducing figures was shaded.

What has been done incorrectly?

[socratis]

What has been done incorrectly?

Nope. GParted can't simply work in all cases. It simply isn't something that can be done the same way as increasing the disk size. Decreasing has always the potential of destroying data. That's why it's not considered an inherently safe operation.

You could create a new smaller VDI, format it and then "clone" the contents of your large VDI to the smaller one. I've used in the past the free edition of a program called EaseUS Partition Master, with excellent results. There might be a lot more out there, do your homework...

[mpack]

When running GParted, I found that it simply wasn´t possible to reduce the disk by mouse drawing from the right to the left.

Strange, I understood that to be precisely how one would do it, except of course that you should be reducing a PARTITION size, not a disk size. GParted has no idea that disk sizes can change - it's designed for physical media.

It's my understanding that GParted does have the ability to move files around inside a recognized partition filesystem in order to free up trailing blocks/clusters. It can then modify the partition size.

[Jiger]

Well, trying to do my homework gave me the experience that installation of EaseUS Partition Manager lead to an unavoidable installation of Avast Antivirus, which I consider to be a poison. Good to have a functioning Backup but back to square one now.
Could you please inform me how you create a new smaller VDI and format it....

[mpack]

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.

[Jiger]

GParted again, I tried this program once more and of course it is a partiton that can be changed, there is no other alternative. AND it seemed to work now! In the guest the system disk is reduced according to our wish, but in the host the disk is as big as before. The idea was of course to save some space on the host. How could this be done?

[mpack]

You don't care about the logical size of a dynamic disk unless you already filled the drive and therefore maxed out the host allocation. Reducing the partition size ensures that the guest OS is now incapable of filling up the drive.