VMware Communities

Defragment does not check space free in target location (not following NTFS junctions)

I have just noticed that the VMWare Workstation (v6.5.5) defragment utility only appears to check the disk space free at the location it believes to be the root of where you virtual disk file is located.

The following was observed under Windows 7 (x64) enterprise, running VMWare Workstation v6.5.5 (all of this refers to the physical machine)

1. NTFS allows you to mount a drive in an empty folder

2. Boot drive C:\ has 60 GB free

3. Larger 1TB drive (with 500GB free) is mounted on the folder C:\Drives\WD1T

4. VM Files are located in C:\Drives\WD1T\Virtual Machines

(I then use a junction to point 'C:\Virtual Machines' at that location, but for the purposes of this test, I used the full path/location)

5. I have a WindowsXP VM with an 80GB virtual disk file.

In VMWare Workstation 'Virtual Machine Settings, when the hard disk is selected from the devices list, reports that the 'capacity' System Free figure is 60GB.

Attempting to defragment the virtual disk file using the 'Utilities' button & selecting the defragment option reports that there is not enough space on the drive.

Trying to run VMWare-Vdiskmanager from the commandline of the virtual disk file reports a rather lengthy error stating that it could not write the file as the disk was full (??)

Hoewever, then do the following:-

1. Open a command prompt & use the SUBST command to create a virtual drive letter for a folder

SUBST X: C:\Drives\WD1T

2. Run VMWare Workstation & open the VM from X:\Virtual Machines

3. 'System free' now reports 500GB free & will allow you to defragment.

4. Running vmware-vdiskmanager to defragment x:\Virtual machines\myvm\myvm.vmdk succeeds.

From the above it would appear therefore that VMWare is simply checking the root folder of the path where the virtual disk file is located, rather than the space available in the target location.

The Windows call GetDiskFreeSpaceExwill return the correct figure, if given the full path.

0 Kudos
0 Replies