virtualbox.org

Okay, I admit I screwed up. I created a VM with a dynamic-sized VDI that was too large for the physical disk it's on, causing the machine to fail when my physical disk reached full capacity.

I've read the tutorials on how to use zerofree and the compact function to reduce the size of the disk, but I don't want to have to keep doing this every few days. So what I think I need to do is clone the VDI to a smaller (also dynamic) one, then re-attach that to my machine in place of the old one. After using zerofree and compacting, the original VDI dropped to 23.3 GB in size (with a maximum size of 60GB). I created a second dynamic VDI with a maximum size of 40GB (on another physical disk, temporarily), then used "vboxmanage clonehd" with the --existing option to copy everything to that VDI. However, the new VDI came in at only 14GB, which immediately made me suspicious, and sure enough, my machine refused to boot with it when I shuffled things around.

Is there another way I should be doing this? Once I properly clone the HD (and then move it back to the original physical disk), do I need to do anything other than detach the old disk and attach the new one?

Thanks in advance,
Keith

Use gparted to shrink the size of the guest partition, Then use CloneVDI to compact the disk (this is much faster than zerofree+VBoxManage). The reduced partition size will stop the guest expanding too much again in future.

Or, you can shrink the partition and then use VBoxManage clonehd --existing" to a smaller VDI as you've outlined. A bit slower but it should still still work if you know what you're doing. The partition must be shrunk first however, otherwise it won't fit on the smaller VDI. Bear in mind that location of the partitions on the drive is also important (e.g. no good if the swap partition is off the end of the smaller drive!), and that some guests (e.g. Windows) sometimes store hidden data at the end of the drive, which of course will be lost.

ps. Compaction is a host optimization operation which frees up space on the host, not the guest. In particular this will not change the guests partition size - for that you must use gparted or some other partition management tool running inside the guest.

pps. Your diagnosis of why your procedure went wrong is almost certainly incorrect. Your problem was failing to understand that compacting the dynamic size of a disk doesn't change the contents or the location of those contents, so if some of those contents are off the end of the drive then you'll corrupt the filesystem - when you copy the filesystem image to a smaller drive - and that'll be why the clone didn't boot.

Ah, yes -- again, a silly oversight. The root partition itself on the guest is 60GB. I had forgotten to resize that, as well, which explains why data was lost in the clone. (Although I'm surprised the cloning operation returned success. I would think if not all data can be copied, it should at least report a warning, if not an outright failure.)

I'll try running gparted to resize the partition and give it another go. Thanks!

Keith S. wrote:Ah, yes -- again, a silly oversight. The root partition itself on the guest is 60GB. I had forgotten to resize that, as well, which explains why data was lost in the clone. (Although I'm surprised the cloning operation returned success. I would think if not all data can be copied, it should at least report a warning, if not an outright failure.)

VirtualBox doesn't know anything about guest OS data structures stored on the drive, which includes partition maps. The user manual tells you that the "clonehd --existing" function will skip data that can't fit on the smaller drive. This isn't an error, it's implicit in what you told it to do: copy 60GB drive image to 40GB drive inherently implies discarding 20GB's worth of disk sectors.

Technically speaking, yes. But that doesn't mean it's the ideal user experience. I can't imagine any use case where someone would want to throw away leftover data at the end of their disk, especially not having any way of knowing just what data that is. Empty, unallocated, or zeroed-out space, yes. Anything else -- it should warn you. I don't think that's too much to ask in the name of better usability.

The only way to get that kind of granularity is to do so from the guest. Even gparted can't tell what is on the partition and says so in a warning when you try to shrink the partition. These things are simulated and can be done even though on metal there is no way to shrink the disk size, but they all carry drastic consequences if you don't take care and even then it is risky.

Fair point; I was hoping that the cloning operation had the ability to parse the .vdi file enough to know where space was unallocated. This would be the obvious downside/risk given that it cannot, and, as I pointed out, it is certainly documented.

At the end of the day, after I ran gparted and repeated the rest of my steps (cloning to smaller dynamic drive), everything is working correctly now, and I no longer fear filling up my host's boot drive. So my earnest thanks to mpack for the guidance!