VMDK mixup

[DVDWSN]

Hi,

I created a secondary harddrive volume for file storage on a Windows 2003 VM. I created in on a different datastore (datastore2) than the one that's storing the VM's primary harddrive volume, VMX and swapfile (datastore1).

This 2nd harddrive volume is about 150GB in size and works fine in the VM. The weird thing is on datastore2 the VMDK size is only 22GB (labeled Srv2003_1.vmdk) the other 128GB is stored on datastore1 in the VM folder with the other files and it's labeled Srv2003_1-000001.vmdk.

How did this happen? A snapshot? If so, why would it put the new VMDK segment on different datastore than the one the VMDK was on originally?

Is there a way to merge these two VMDK files? And more importantly, how can I stop this from happening again?

[rolohm]

To my knowledge snapshot files are always located in the VMs home directory. If you can find the snapshot in the snapshot manager and delete that snapshot, the files should merge and the remaining file end up where you expect it to be.

/R

[rolohm]

You seem to accidently have created a snapshot. Snapshot file are always (to my knowledge) placed in the VM's home directory. Try finding the snapshot in the snapshot manager and delete it. That should give you one correct sized file where you expect it to be.

/R

[DSTAVERT]

If this is a snapshot it will take considerable time (many hours) to merge since it is so large. Do the delete snapshot procedure on off hours.

[DVDWSN]

So are we sure this is caused by a snapshot? Usually when the vmdk gets split and named "blahblah-000001.vmdk", it's becuase of a snapshot, right?

So two questions:

1) Other than making the snapshots exclude this drive. Is there a way to make them store the VMDK segments with the original VMDK file?

2) Other than removing the snapshot that caused the split, is there another way to merge the files, or can I just move the VMDK segment to the proper datastore?

[jbogardus · Accepted solution]

It's very risky to do anything non-standard with you disk configurations and snapshots that is not supported through the GUI. The safest course of action is to simply delete/merge the snapshot as soon as possible. This will involve downtime for the size of the snapshot, but that can't be avoided in these situations once a snapshot exists. That's why I caution many people against the use of snapshots if they don't understand the impacts. If you take snapshots keep them for a very short time (this can be a couple days with low disk activity VMs). Have an understanding of the utilization of all disks in planning how long you can keep a snapshot. For high activity disks, set them as independent so when a VM is snapshot those high activity data disks are not. In the case of applying Windows security patches for example, you can snapshot the low activity C: drive, without having the snapshot apply to the data on the 😧 drive. This will provide you protection to roll back the patches in the C: drive if required, without affecting D:. The usefulness of snapshots apply much more to C: drives than whole VMs with large data drives in general.

[DSTAVERT]

There is no benefit to keeping the snapshots. They are causing performance issues and it will only get worse. The snapshot files just keep growing. It gets riskier and riskier to merge.

[DVDWSN]

Is what I did non-standard?

In the cSphere Client the Add Hardware wizard let me put the 2nd harddrive volume on the other datastore. So as far as I know it's supported. Despite that should I still not do it?

Still just wondering, is it possible to have the snapshot of a volume stored with the initial vmdk, instead of the main VM folder? Or is that how it always works?

[DSTAVERT]

I don't think you can split destinations for snapshots. Having disks on different datastores is fine. You just shouldn't have such a large snapshot.

[DSTAVERT]

The Srv2003_1-000001.vmdk is a snapshot file. When you create a snapshot the original Srv2003_1.vmdk is frozen and any changes to the disk are written to the snapshot file. Reading the disk means reading both the Srv2003_1-000001.vmdk and Srv2003_1.vmdk files.

[DSTAVERT]

http://kb.vmware.com/kb/1002929

[jbogardus]

No what you have done so far is OK. I'm just worried about non-standard things that may be tried to fix it in attempts to limit downtime or provide other changes that you feel provide a 'cleaner' configuration, but may create trouble later on. The best fix is simply to delete it with the GUI and prevent snapshots from getting so big in the future.

The following is some additional info on examples of 'non-standard' (meaning not in the GUI - if you look at the GUI at VMware Properties - Options tab the working directory is listed but not modifiable. I'd expect VMware doesn't want to encourage modifying it in the .vmx either due to some associated risks.) ways to change things that may be OK to try on non-critical VMs. This includes change the location that snapshots (and swap) are stored for the VM:

http://hyperinfo.wordpress.com/2008/06/12/troubleshooting-vmwareesx-snapshots/

[DVDWSN]

Ok, so, I removed the snapshot, and after a couple hours the vmdk's were merged back onto the correct datastrore!

Thanks guys.