VMware Server 2.0 using almost twice the space it shoudl

Hi so I've had VMware server 2.0 running on a xp 64bit host system.  The virtual os is sbs2k3 R2 and I've noticed that there are a bunch of files taking up space that don't match my configuration I'd like some help figuring out which files belong to the virtual server and how I can clean up the remaining.
In the summary of the VM I get the following info as you can see when comparing this info with the info in the actual directory the sizes don't match at all and there are server huge extra files.  I matched up the filename clicking on the virtual disk and clicking edit.
The harddisks are the following order:
Hard Disk 1 SCSI 0:0: 60GB  C:\  actual name: SBSWIN2K3R2 VM_1.vmdk
Hard Disk 2 SCSI 0:1: 160GB  SBS2K3R2- Virtual Machine_3-000002.vmdk
Hard Disk 3 SCSI 0:2: 84GB  SBS2K3R2- Virtual Machine_2-000002.vmdk
Hard Disk 4 SCSI 0:3: 40GB  drive-000002.vmdk
Hard Disk 5 SCSI 0:4: 10GB  SBS2K3R2- Virtual Machine_4-000002.vmdk
Hard Disk 6 SCSI 0:5: 50GB  SBSWIN2K3R2 VM-000001.vmdk

The virtual machine name is SBSWIN2K3R2 VM

I thought some of the extra very large files were snapshots but when I go into snapshots it says there are none.  Just looking to free up a bunch of space thanks for your help.  I've done some digging around and haven't found anyone with a similar problem.  I also tried to see which files are locked when the VM is on figuring if they aren't locked I could delete them safely but that doesn't work all the files are locked even those with a modify date of 2 years ago?  I've attached a view of the directory.
 files in the VM directory
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

bgoeringConnect With a Mentor Commented:
the files with -00000# in the filename are snapshot files. You need to get rid of them. First you need some free space on your datastore volume. To do that make sure you have enought free space in your directory. To be safe make sure you have free space equal to twice the size of the base vmdk. For example your drive machine has several files.

drive.vmdk - descriptor file (small)
drive-flat.vmdk (base disk, about 40 GB)
dirive-000001.vmdk (snapshot, about 22 GB)
drive-000002.vmdk (snapshot, about 3 GB)

We want to get rid of the snapshots, when they are deleted (with changes committed) you will free up 25 GB (size of two snapshots added together) from your datastore. to do that free up about 80 GB (twice size of base volume) before you begin. You can copy files off to another disk if necessary in order to free up the space. Next look at snapshot manager, if you don't see any snapshots then create one. Last do a delete all - this will commit changes from snapshot 00001 to the flat file, then delete the 000001 file. Next it will apply changes from the 00002 and once applied delete that file.

Often you don't see snapshots in the snapshot manager because you have tried to delete them, and the delete process failed because of not enough free space, or because the process was interrupted before it completes. Is it possible this is what happened to you.

Not that it can take many hours to commit then delete a large snapshot file. Your SBS2k3R2 has base disks totalling in size about 300GB, ideally it would be best to have 600 GB free, but because of how these are processed when committing changes you might be able to get away with around 330 GB free (twice the size of largest disk).

So key points:
1. Make sure you have plenty of free space to merge snapshots
2. Be patient - it can take a very long time to merge large snapshots
3. Don't keep snapshots around for long, they are great to get a machine state before applying patches and such, but should be removed asap after you deem the patch to be a success. They are NOT a backup method.

The actual process for removing nested snapshots are that assuming 4 levels.
4 is merged into 3
3 is merged into 2
2 is merged into 1
1 is merged into base disk
1, 2, 3, and 4 are finally deleted.

So going back to the drive vm example
base - 40 GB
1       - 22 GB
2       - 3   GB
total  - 65 GB

Now when deleting, first pass 2 merged into 1
base - 40 GB
1       - 25 GB
2       - 3   GB
total  - 68 GB

next pass 1 merged into base (base disk doesn't grow)
base - 40 GB
1       - 25 GB
2       - 3   GB
total  - 68 GB

finally snaps are deleted so utilization is size of base disk, or 40 GB for this example

Good Luck
vmwarun - ArunCommented:
The best solution is to shutdown the SBS2K3 VM and then use vCenter Converter Standalone to convert the SBS2K3 VM to another drive (preferably a USB Drive or another partition on the same hard disk).

This will create a VM which needs the respective VMDKs for the VM to function properly.
Strider10Author Commented:
Thanks so that means the snap shots never got committed and they contain all the relevant data since the point they were taken.  Which is why the file size of the vmdk file doesn't match the file vmware says the virtual hard drive is using so just deleting the snap shots would remove all relevant changes from the point the snapshot is taken.  Would it all so be true that taking a new snapshot is going to take a long time and I should probably do this over the weekend?
Thanks again
Take Control of Web Hosting For Your Clients

As a web developer or IT admin, successfully managing multiple client accounts can be challenging. In this webinar we will look at the tools provided by Media Temple and Plesk to make managing your clients’ hosting easier.

Taking a new snapshot takes no time at all. When you take a snapshot it just freezes I/O to the previous level and creates a new file to accumulate changes.

However, committing the snapshots and deleting them can take a very long time. Especially as large as some of yours are.
Strider10Author Commented:
OK one more question for you upon reading further in the vmware manual since this is the free server version 2.0 it says it can only have one snap shot so when I go to take a snapshot does that means the existing large snapshot will be merged in with the vmdk file and an new 00003.vmdk snapshot file will be created.  I'm just concerned that we'll be down if I click take snapshot for many hours till the old one mergers?  Any experience with that I'm trying to test this on my laptop but vmware server is very slow.
Ouch - I forgot we were talking about Server 2.0 here - I mostly do ESX stuff any more. I have a VM Server 2.02 installation at the office I can run an experiment on tomorrow and see how it behaves.

Just curious - have you thought about the free ESXi to replace Server? I went that route for my home network about 2 years ago - had Server prior to that.
I ran a test - had an XP vm with about a 5.5 GB snapshot in xp-000001.vmdk so I created another one. It created about a 4 MB xp-000002.vmdk and took around 9 minutes to commit the xp-000001.vmdk to the base disk xp.vmdk, then it deleted the xp-000001.vmdk.

The vm was frozen and unresponsive for that 9 minute period. So I guess that in your case I would wait for the weekend before I tried deleting the snapshot as some of yours were quite large.

Hope this helps
Strider10Author Commented:
Very good feedback thanks for helping me work that one  out.
All Courses

From novice to tech pro — start learning today.