Limiting the Size of a Guest...

[VirtuallyCurious]

Okay, so @mpack had helped me before related to how my W7 guest keeps increasing in size... However since last post another 10 gigs has been added to it.

So what I did originally was copy a fresh install of W7 with VMware vCenter Converter Standalone. That created a VMDK file that I imported using VB... Originally it was about 30 gigs. Now even though things are seemingly okay with that, I'd like to know if there's a way to now stop that from happening and keep the VMDK consistent size wise.

Happy to give any additional information as well... Thanks again!

[BillG]

Not unless you never use it! It is the nature of Windows OSs to increase in size over time. The OS does not actively try to reclaim or reuse space which is no longer required.

[mpack]

However, as I have told the OP before, the size does not increase forever. It will eventually reach a stable size corresponding to your usage pattern. It is also physically constrained from growing larger than the maximum size selected when the VM was created.

[VirtuallyCurious]

Okay cool, just wanted to see if it was possible. And I hope so @mpack, as it's at 73 gigs and still growing! However don't forget I didn't create the VM through VB but used VMWare vCenter to essentially copy the host W7 OS and use the copy as the guest... I never had the option to set a size.

[mpack]

You can check the logical size of the disk in File | Virtual Media Manager. That is the capacity of the disk, which is also the largest it can grow.

There isn't two sides to this coin. A dynamic disk grows because you are writing new stuff to previously unused areas of the disk. If you don't think the growth matches what you deliberately do, then look to background processes that might touch the disk.

[VirtuallyCurious]

Now we're getting somewhere! The virtual size is 105 gigs which wouldn't you know it, is probably the number it'll keep growing to. That's the space allocated to the host's system drive, and obviously the vmware copied it to the letter for the guest. Honestly I didn't think it would actually use all that space, and it's nowhere near maxed out in the guest anyway... There's almost 40 gigs free of the 105 system drive.

Now correct me if I'm wrong, but I vaguely remember not having this issue when I installed W7 through the VB, as opposed to copying an existing setup. Either way, at least I have more information, but would still like to nip this in the bud... Which I imagine I have to do the next time I use the vmware to copy the the host for the VB guest.

[mpack]

No, how you installed the guest OS isn't relevant. All that matters is the usage pattern of yourself and the guest OS.

It's a simple matter of probability. Every time you write a sector to the drive, the VDI file grows, provided the sector hasn't been written to before. As the drive fills up, the odds that any sector has never been used before shrinks, hence the drive stops growing, or grows very slowly: and this is assuming that you are constantly writing data, which isn't true for most of us.

The only spanners in the works are background processes that continually write to the disk and which deliberately moved data around the disk (e.g. defraggers), but I've already told you twice before to look for these and turn them off, so presumably you did that.

[scottgus1]

I have read on the forum that if the disk is compacted (see Mpack's CloneVDI) then inside the guest OS the partition that wants to grow is shrunk, with unpartitioned space left over on the disk in the guest OS, the dynamic disk won't grow past the partitioned space in the guest OS.

Assume you make a 105GB virtual disk. It has 30GB data but has grown to 84GB through the operation of the OS. Clone & compact the disk, keeping the old UUID, and make the guest boot from the cloned disk. Now the guest is booting from a 30-ish GB virtual disk file for a moment. Go into the OS's disk manager (or boot from a disk partition editor ISO) and shrink the main partition that wants to eventually fill up the whole disk. Say you could shrink 50GB and still leave some GB for the OS to use. Leave the freshly unpartioned 50GB alone. Now the disk will no longer grow to the 105GB but will stop increasing at the size it would grow to if the shrunk partition was filled. In this 50GB-shrink example it should stop increasing at 65GB (105 - 50 = 65), even though the original size of the disk file is set to 105GB.

This all assumes that snapshots are not being used.

If you cannot shrink the partition because you can't get the in-guest-OS or ISO partition editor to work, there may be in-the-guest cloning backup software that can clone to a smaller drive. (Macrium Reflect does this for Windows guests and is free. Acronis probably does it too.) If you have to go this route, attach a new disk drive to your guest that is set to the desired smaller size. Note that you must have enough room to store the data on the large disk. Boot the guest and launch the backup cloning software in the guest. You may have to finagle partitions and read instructions, but you should be able to clone the larger booting disk to the smaller one if the small one has enough room. When the clone is complete, shut down the guest, disconnect the large drive and connect the clone in the large drive's place. I have done this in physical systems going from a large platter drive to a smaller SSD; it should work in a guest, too.

[mpack]

I have read on the forum that if the disk is compacted (see Mpack's CloneVDI) then inside the guest OS the partition that wants to grow is shrunk, with unpartitioned space left over on the disk in the guest OS, the dynamic disk won't grow past the partitioned space in the guest OS.

The order is slightly wrong there. The idea is that you shrink the partition first: but this is just a data structure change (moving a line on a map), it mostly doesn't physically change the disk, in fact the VDI probably gets larger in this step.

So, then you compact using CloneVDI. Blocks that are eliminated from now-unpartitioned areas can never be recreated, hence this effects a permanent change and limit to the size that the VDI can occupy.

This should not be taken as license for shrinking a drive down to less than its natural working size. All that will do is create a congested filesystem inside the guest, hurting performance. The whole idea is questionable IMHO, unless a huge mistake was made when selecting the original drive size.