VM acts like it is snapshotted and will not remove

Hi sorry for long comments below...

(server names have been changed)

I have a Windows 2003 VM on a ESX cluster that acts like it is snapshotted but it shouldn't have any active snapshots at all.

I had snapshotted this VM on 18/06/08 and later that same day I had committed the snapshot and rebooted the VM with no problem.

At the time I confirmed that the three HDD were pointing to their proper LUNS and not to delta vmdk or 00000x.vmdk files.

This morning the VM could not be remoted into via RDP or console.

Server performance tab in VI Client stopped responding 9:17am 25/06/08.

Performance stats were not changing on ESX host (esxhost1).

Tried reset in VI client - it timed out.

Could not shutdown in VI client due to "another operation in progress"

Next I SSH into esxhost1, located VM process and killed it via "kill -15 ".

Confirmed that the VM had powered off in VI Client.

In VI client, I then powered up MyVM .

It powered on new ESX host (esxhost2).

I was able to console into it ok.

I saw an error at boot concerning small paging file but it should be fine as it was built as per these specs:




C:\ 15GB (OS LUN) VM Config files stored on this LUN too



Files are stored on shared storage visible to all ESX hosts.

Then I noticed its drives are configured in VI client as if it was snapshotted...

i.e. all three drives located on the OS LUN and pointing to:

HDD#1 scsi (0:0) 15GB (OS LUN) MyVM/MyVM-000004.vmdk

HDD#2 scsi (0:1) 15GB (OS LUN) MyVM/MyVM-000005.vmdk

HDD#3 scsi (0:2) 15GB (OS LUN) MyVM/MyVM-000006.vmdk

There is 80GB free on OS LUN (phew)

No current snapshots are listed in snapshot manager.

It's acting a bit like a sticky snapshot so the usual fix is to take a quick snapshot, then remove all snapshots.

This is having no effect - either from service console or VI client.

I've checked the contects of the VM directory on storage and it looks odd.


-rw------- 1 root root 956301312 Jun 18 12:28 MyVM-000001-delta.vmdk

-rw------- 1 root root 231 Jun 18 10:58 MyVM-000001.vmdk

-rw------- 1 root root 33554432 Jun 18 12:28 MyVM-000002-delta.vmdk

-rw------- 1 root root 293 Jun 18 11:11 MyVM-000002.vmdk

-rw------- 1 root root 83886080 Jun 18 12:28 MyVM-000003-delta.vmdk

-rw------- 1 root root 294 Jun 18 11:17 MyVM-000003.vmdk

-rw------- 1 root root 7751073792 Jun 25 10:35 MyVM-000004-delta.vmdk

-rw------- 1 root root 257 Jun 25 11:24 MyVM-000004.vmdk

-rw------- 1 root root 704643072 Jun 25 10:35 MyVM-000005-delta.vmdk

-rw------- 1 root root 257 Jun 25 11:24 MyVM-000005.vmdk

-rw------- 1 root root 637534208 Jun 25 10:35 MyVM-000006-delta.vmdk

-rw------- 1 root root 257 Jun 25 11:24 MyVM-000006.vmdk

-rw-rr 1 root root 37 Feb 25 22:47 MyVM-6f8e4081.hlog

-rw------- 1 root root 16097922048 Jun 18 10:58 MyVM-flat.vmdk

-rw------- 1 root root 8664 Jun 25 10:35 MyVM.nvram

-rw------- 1 root root 343 Feb 29 17:06 MyVM.vmdk

-rw------- 1 root root 1191 Jun 25 11:24 MyVM.vmsd

-rwx------ 1 root root 1872 Jun 25 11:24 MyVM.vmx

-rw------- 1 root root 255 Jun 25 10:35 MyVM.vmxf

-rw-rr 1 root root 5491 Feb 26 08:20 vmware-15.log

-rw-rr 1 root root 97553 Jun 18 12:28 vmware-16.log

-rw-rr 1 root root 5491 Feb 26 11:56 vmware-17.log

-rw-rr 1 root root 61441 Jun 18 15:55 vmware-18.log

-rw-rr 1 root root 28602 Jun 25 10:19 vmware-19.log

-rw-rr 1 root root 29918 Jun 25 10:27 vmware-20.log

-rw-rr 1 root root 135876 Jun 25 10:35 vmware.log

It looks like the snapshot files from last week are still there as well. I'm not sure.

I'd really like to get this server up again and not acting like it is snapshotted without losing data.

Does anyone have any suggestions?

Many thanks!

P.S. dates are correct, I am in a different timezone Smiley Happy

0 Kudos
4 Replies

It sounds like the vmx file might reflect something other than the actual state of your VM. You could check out the vmx file, and edit if confident. Maybe create a new VM using the same vmdk files, or try unregistering the VM and re-registering?


0 Kudos

Editting vmx files... I've never done it and will have a look around.

Here are the contents of MyVM.vmx


config.version = "8"

virtualHW.version = "4"

floppy0.present = "false"

nvram = "MyVM.nvram"

powerType.powerOff = "default"

powerType.powerOn = "default"

powerType.suspend = "default"

powerType.reset = "default"

displayName = "MyVM"

extendedConfigFile = "MyVM.vmxf"

scsi0.present = "true"

scsi0.sharedBus = "none"

scsi0.virtualDev = "lsilogic"

memsize = "2048"

scsi0:0.present = "true"

scsi0:0.fileName = "MyVM-000004.vmdk"

scsi0:0.deviceType = "scsi-hardDisk"

ide0:0.present = "false"

ide0:0.fileName = "/dev/cdrom"

ide0:0.deviceType = "atapi-cdrom"

ide0:0.startConnected = "false"

ethernet0.present = "true"

ethernet0.wakeOnPcktRcv = "false"

ethernet0.networkName = "JDC"

ethernet0.addressType = "vpx"

ethernet0.generatedAddress = "00:50:56:98:7d:14"

guestOS = "winnetstandard"

uuid.bios = "50 18 f2 40 ea 44 ff 60-54 ba 56 3d 26 8d bd e6"

log.fileName = "vmware.log"

sched.cpu.min = "0"

sched.cpu.units = "mhz"

sched.cpu.shares = "normal"

sched.mem.minsize = "0"

sched.mem.shares = "normal"

toolScripts.afterPowerOn = "true"

toolScripts.afterResume = "true"

toolScripts.beforeSuspend = "true"

toolScripts.beforePowerOff = "true"

scsi0:0.redo = ""

tools.syncTime = "FALSE" = "7201"

scsi0:1.present = "true"

scsi0:1.fileName = "MyVM-000005.vmdk"

scsi0:1.deviceType = "scsi-hardDisk"

scsi0:2.present = "true"

scsi0:2.fileName = "MyVM-000006.vmdk"

scsi0:2.deviceType = "scsi-hardDisk"

annotation = "Yada yada yada prod server. Owner = xyz (IP=x.x.x.x)"

0 Kudos

So from your vmx file it says that you have 3 vmdks files: MyVM-000004.vmdk, MyVM-000005.vmdk, and MyVM-000006.vmdk. No mention of any other vmdk files. So perhaps now you could try unregistering the VM from VC server. In this way it'll clear entires for the VM from the VC database. Then re-register it. If that doesn't work I'd try to make a new VM with the vmdk files and see how that goes....



I've marked it as a helpful response.

Un-registering and re-registering had no big effect.

What I had to do was remove the VM from inventory and clone the vmdk files using vmkfstools -i.

Then create a new VM, remove its intital system drive, and attach the cloned vmdk disk files.

This brought back the OS partition ok but the data partition kept coming back as a copy of the OS partition.

(GiGo effect I think. before any cloning was attempted by myself, the original "snapshot" Data partition became for some reason a copy of the OS partition when the snapshot was committed. Mystery as to how or why.)

I had to restore the data from a backup.

0 Kudos