Fusion Source Files 4 times larger than VM content. Why?

[northtrader]

I'm running Fusion 2.0.5 on a 2.8Ghz Intel Core Duo iMac running OS 10.5.8. The operating system on the VM is XP Pro SP3. I'm trying to minimize the "memory footprint" of the VM and have "moved" the MyDocuments folder to point to a folder that is native on the MacOS (shared folder through Fusion). The MyDocuments contents total about 414MB. The only files resident on the VM are the operating system and the XP programs. All my user data is stored on the MacOS thru a shared folder in fusion. When I originally set up the VM I set it as a 40GB machine. At the time that I installed fusion and set up the VM I recall reading that, although the VM was set up at 40GB, the software would only create source files to "house" the actual data in the VM - meaning it wouldn't take up 40GB unless there was 40GB worth of data in the VM. I do not have any snapshots. With that background, here's the dilemma:

When I start the VM and "add up" the folder sizes through Windows Explorer, my data adds up to about 6.5GB. When I do a "properties" on the C: drive it indicates that there is 8.96GB of data on the drive. When I check the size of the VM on the MacOS it is a whopping 35.43GB and it appears to grow each time I launch and close the VM.

What kind of file system architecture is at play here?

Why are the VM source files 4 times the size of the "data" on the C: drive?

Why is the data indicated on the VM C: drive almost 2.5GB larger than the actual data in the VM?

How do I "shrink" the source files to accurately represent the quantity of the actual data in the VM?

I'm trying to optimize my backup scheme and want to make sure the size of the VM is minimized at all times.

Yes, I know about 'sparse bundles' and the fact that the new version allows you to split the source files into 2GB chunks. That's not the point of this post.

I want to know why the source files are several orders of magnitude larger than the actual data in the VM and how to shrink them back to accurately reflect the data in the VM. I would also like to keep the source files from self inflating - which they appear to do even when no data has been added to the VM. Any insight into this would be greatly appreciated.

[admin]

I recall reading that, although the VM was set up at 40GB, the software would only create source files to "house" the actual data in the VM - meaning it wouldn't take up 40GB unless there was 40GB worth of data in the VM.

That's not quite correct. Deleting files does not automatically free up space, so as you delete files the virtual disk will tend to take up more space than the contents (up to the limit of your virtual disk size). You can recover space by using Tools' shrink process.

See also : Disk Space

[northtrader]

etung,

Thanks for the insight and the tip on the Tools' shrink process. I ran the shrink process and 'recovered' about 24GB. The VM source files now occupy just over 10GB on the MacOS. Thanks again. I'll keep an eye on the size of the source files over the next couple of weeks to see what, if any, inflation takes place.

I'm still rather puzzled as to why the "properties" on the C: drive in the VM shows there is 8.9GB used when the totals of the file folder on the drive comes to quite a bit less. I checked the C: drive properties after the shrink process and it showed 8.9GB. I did a cursory addition of the total in the folders contained in the C: drive and it came to about 4.5GB. If you have any insight into the reason this still exists, I'd appreciate it.

[admin]

I checked the C: drive properties after the shrink process and it showed 8.9GB. I did a cursory addition of the total in the folders contained in the C: drive and it came to about 4.5GB.

Hidden or temporary files would be my guess. There's probably some Windows tool you can use to examine the filesystem, but I'm not that familiar with Windows so don't have suggestions.

[northtrader]

etung,

Wow! You're fast....

I'll take a look at this when I get back to the mac. I was wondering if the these hidden files were related to some VMWare overhead. I would expect VMWare to create some sort of overhead files in the VM but not 4GB worth. Is this a correct assumption; that Fusion creates some overhead files in the VM? If so, how much overhead is there?

Waldy

[admin]

I would expect VMWare to create some sort of overhead files in the VM

To my knowledge, we don't create any special overhead files. What you see in a virtual machine should be pretty much what you would see on a physical system.

[northtrader]

All right..... I ran the shrink function and now I have the following file sizes plus a new problem that may be related to the shrink function.....

The XP machine has files that total 7GB. The VMFusion source files for the XP machine take up 11GB on the mac hard drive. Hmmmm. What's the 4GB being used as?

That's not my biggest problem. I have 4 users on this mac. They used to be able to launch the Virtual XP Machine under their own login. Now I can't start the VM when I log in as them. Here's some details:

-The Virtual Machine package has it's content's permissions set so that everyone can read and write to it. I did this way back when I first installed the VM in 2008. (I had to do this when I first installed the VM so the other users could use the machine. It worked great)

-The users have Admin rights on the Mac

-The VM was shrunk on my login.

-I start the VM on the other users' logins and get the following message: File not found (name of VM).vmdk. I browse for the file and it's right there in the VM package. I select the file, hit "open" and nothing happens.

What's going on now? It appears that the "shrinking" process has disabled the VM for my other users?? How do I "re-enable" the VM for these users?

Waldy

ps. I have no snapshots on the VM. The only thing that changed since the VM worked with the other users is that I shrunk the VM.

[Entegy]

The program WinDirStat can give you a visual representation of your hard drive. Run this on your vm.

Also, the Disk Cleanup tool built into Windows might be able to help. Find this by right-clicking the C:\ Drive and choosing Properties and go to the Tools tab.

The final thing (and this is probably the killer) is that you left system restore on. Go Control Panel>System (change to classic view!) and go to the System Restore tab. Turn System Restore off and I'm willing to bet you'll magically gain your space back after you turn it off and hit OK. (Check the C:\ drive free space before and after this.

As for your permissions problems, the permissions were reset on the vmdk when you shrunk (because if my assumption is right, the shrinking process actually makes a new file). Use the Get Info window to give the appropriate permissions. If it's a split VMDK, you'll have to do this for each VMDK part in the package.

[northtrader]

Thanks a bunch Entegy!

The system restore was set to gobble up 4GB and turning it off salvaged about 1.1GB. The VM source files are now 9.9GB. Not a huge gain, but I can live with that for now.

Thanks for the heads up on the permissions being reset on the shrinking of the vmdk file. I reset the permissions of the whole package and everyone is smiling now ;-).

Waldy

[admin]

What's going on now? It appears that the "shrinking" process has disabled the VM for my other users?? How do I "re-enable" the VM for these users?

That shouldn't have happened; new vmdk files should get the same permissions as their vmx.

Can you open a terminal, go to the bundle directory containing your vmx and vmdk, and do

ls -al

then let me know what it says for the .vmx and .vmdk files? It should be "-rw-rw-rw" for vmdk, "-rwxrwxrwx" for vmx. You can send it to me directly if you prefer.