VMware Cloud Community
pkirklewski
Enthusiast
Enthusiast
Jump to solution

vmware disk file corrupted

Hi

I turned off my VM (which was working perfectly fine for ages) and it won't start again.

It complained "File ".

I remember (few months ago) having problems with snapshot's and free space in datastore1. I removed some snapshots manualy since it was impossible to do that the standard way ou to lack of space.

Now I'm sure that this problem has something to do with the snapshot's removal several moths ago.

Here is my vmx file and attached what I can see in the datastore - please help.

.encoding = "UTF-8"

config.version = "8"

virtualHW.version = "7"

pciBridge0.present = "TRUE"

pciBridge4.present = "TRUE"

pciBridge4.virtualDev = "pcieRootPort"

pciBridge4.functions = "8"

pciBridge5.present = "TRUE"

pciBridge5.virtualDev = "pcieRootPort"

pciBridge5.functions = "8"

pciBridge6.present = "TRUE"

pciBridge6.virtualDev = "pcieRootPort"

pciBridge6.functions = "8"

pciBridge7.present = "TRUE"

pciBridge7.virtualDev = "pcieRootPort"

pciBridge7.functions = "8"

vmci0.present = "TRUE"

nvram = "hermes.nvram"

deploymentPlatform = "windows"

virtualHW.productCompatibility = "hosted"

unity.customColor = "|23C0C0C0"

tools.upgrade.policy = "useGlobal"

powerType.powerOff = "soft"

powerType.powerOn = "default"

powerType.suspend = "hard"

powerType.reset = "soft"

displayName = "hermes"

extendedConfigFile = "hermes.vmxf"

floppy0.present = "TRUE"

scsi0.present = "TRUE"

scsi0.sharedBus = "none"

scsi0.virtualDev = "lsilogic"

memsize = "384"

scsi0:0.present = "TRUE"

scsi0:0.fileName = "hermes-000001.vmdk"

scsi0:0.deviceType = "scsi-hardDisk"

ide1:0.present = "TRUE"

ide1:0.clientDevice = "FALSE"

ide1:0.deviceType = "atapi-cdrom"

ide1:0.startConnected = "FALSE"

floppy0.startConnected = "FALSE"

floppy0.clientDevice = "TRUE"

ethernet0.present = "TRUE"

ethernet0.virtualDev = "e1000"

ethernet0.networkName = "VM Network"

ethernet0.addressType = "generated"

guestOSAltName = "Red Hat Enterprise Linux 5 (64-bit)"

guestOS = "rhel5-64"

uuid.location = "56 4d 4d 39 b5 6b 9c 0b-5d 83 b2 f1 12 af 0a a4"

uuid.bios = "56 4d 4d 39 b5 6b 9c 0b-5d 83 b2 f1 12 af 0a a4"

vc.uuid = "52 a3 db 73 d6 e9 c9 34-56 c6 a5 5c 4f 95 1a 06"

floppy0.fileName = "/dev/fd0"

ethernet0.generatedAddress = "00:0c:29:af:0a:a4"

tools.syncTime = "FALSE"

cleanShutdown = "FALSE"

replay.supported = "TRUE"

#sched.swap.derivedName = "/vmfs/volumes/4a703db6-9dfc91ee-8b40-0024e8671406/hermes/hermes-83d6a231.vswp"

scsi0:0.redo = ""

vmotion.checkpointFBSize = "4194304"

pciBridge0.pciSlotNumber = "17"

pciBridge4.pciSlotNumber = "21"

pciBridge5.pciSlotNumber = "22"

pciBridge6.pciSlotNumber = "23"

pciBridge7.pciSlotNumber = "24"

scsi0.pciSlotNumber = "16"

ethernet0.pciSlotNumber = "32"

vmci0.pciSlotNumber = "33"

ethernet0.generatedAddressOffset = "0"

vmci0.id = "313461412"

hostCPUID.0 = "0000000d756e65476c65746e49656e69"

guestCPUID.0 = "0000000d756e65476c65746e49656e69"

userCPUID.0 = "0000000d756e65476c65746e49656e69"

hostCPUID.1 = "0001067a00040800040ce3bdbfebfbff"

guestCPUID.1 = "0001067a00010800800822010febfbff"

userCPUID.1 = "0001067a00040800000822010febfbff"

hostCPUID.80000001 = "00000000000000000000000120100800"

guestCPUID.80000001 = "00000000000000000000000120100800"

userCPUID.80000001 = "00000000000000000000000120100800"

evcCompatibilityMode = "FALSE"

ide1:0.fileName = "/vmfs/devices/genscsi/mpx.vmhba0:C0:T1:L0"

checkpoint.vmState.readOnly = "FALSE"

checkpoint.vmState = ""

Reply
0 Kudos
42 Replies
pkirklewski
Enthusiast
Enthusiast
Jump to solution

I will not touch the machine again unless u say so.

I didn't change anything though.

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

every failed starting attempt makes recovery more tricky ...

anyway - attached you find edited vmdk-files and the vmx.

Replace the one you have with the edited versions and rename the vmsd-file to vmsd-org.

Then try to launch the VM. If it does not come up - or comes up with wrong state of data - imediatly shut down the VM again and post latest vmware.log

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

will you be able to post results during next 15 minutes ? - otherwise you need to wait a few hours for plan B in case it is required

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

can't wait any longer - attached you find plan B - again replace all small vmdk and the vmx with the ones from the zip - remove vmsd file.

Studying your stuff I found another plan C but I guess its not very likely

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
pkirklewski
Enthusiast
Enthusiast
Jump to solution

The machine starts without complaining, olthough the operatig system breaks at some point - gives me a blank screen with a blinking cursor in the top left corner.

Is this the "wrong state of data" that you mentioned ?

If not then I boot it from Live CD and recover the files.

Or do yu want me to power it off and send the logs to you ?

Reply
0 Kudos
pkirklewski
Enthusiast
Enthusiast
Jump to solution

Mounted it from Live CD and the situation is exactly the same as when i mounted 00008.vmdk.

The files are cerated in September.

I will try the plan C.

Thanks anyway Smiley Happy

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Hmm - the blinking cursor maybe a result of the several failed attempts.

Recovering the files with a LiveCD is a very good idea - try this next.

Do not run checkdisk or defragmentation-tools while copying any files as you may still find out that you are dealing with old data.

If the data is old - we will try plan C - I am back in two hours - meanwhile attach latest vmware.log so i can see if the snapshot chain is healthy

see you later Ulli

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
pkirklewski
Enthusiast
Enthusiast
Jump to solution

Logs attached to the above host.

Thanks

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

? - i do not see any attachements ???

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
pkirklewski
Enthusiast
Enthusiast
Jump to solution

Plan a and plan b logs.

The situation is the same.

The system boots untill it's trying to load CUPS - than freezes.

The newest files are from the beggining of September.

Will wait

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

next comes plan C

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
pkirklewski
Enthusiast
Enthusiast
Jump to solution

Unfortunately error

I attached logs and the snapshot.

I just wonder why is this snapshot locked ? And where is the recent data ?

Is there any software that alows to brows the flat file ?

Regards

Peter

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Peter - do you have any lockfiles - or otherVMs accessing the same basedisk ? - linked clones maybe ?

If not is rebooting the host possible ?

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Peter - the data inside the basedisk is old - it was created when you first installed the guest upto the time you created the first snapshot.

Everything since then is inside the snapshots

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
pkirklewski
Enthusiast
Enthusiast
Jump to solution

I rebooted the phisical machine several times.

Does it mean that the data I was working with - was only there in RAM ?

Regards

Peter

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

? - the snapshots are represented by the *-00000X.vmdk files - so your data is in one of those snapshots.

In your case I really do not understand the history of the VM. Something happened to snapshot-000001.vmdk.

It looks like someone has edited this file manually and then started the VM with the wrong state.

This can result in a corrupt snapshot chain - like in your case.

If you had a NTFS-based VM I could extract some data from single snapshots but with Linux-VMs ... - I do not even know which filesystem you used ....

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
pkirklewski
Enthusiast
Enthusiast
Jump to solution

Hi

It was EXT3.

I expected the data to be inside snapshot 000008.

That's because the 000008-delta file is around 35GB in size and this is exactly how big the files were.

I was performing backup on this directory every day, that's why I know the size - unfortunately last Friday the backup did not go and then the server collapsed.

So I'm one day behind and some people here want to kill me for that Smiley Happy

The only snapshot that didn't work is 000001 - is it possible that the data is being kept in both 000001 and 000008 ?

Thank you for your help anyway.

Best regards

Peter

Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

old data is in 000001 , not so old data is in 000002, ... newest data is in 000008.

The big problem is this: lets say you have a database-file named bogus.db

If this file was created in 000008 and populated in 000008 you have a good chance to extract it.

If the file was created in 000001 and only the latest updates were made in 000008 you have pretty bad chances to recover it.

It is possible to extract data from orphaned snapshots - though several folks say it is impossible Smiley Wink

To do that you take the snapshot with the valueable data and fake a new basedisk for it - then you attach the snapshot to this faked basedisk and use a Knoppix for example to read the files.

This is not very reliable - files that are heavily fragmented may be lost .. the small files - written in one piece can be recovered with much better chances ....

Anyway - this procedure is somewhat tricky and needs a lot of experience.

Don't know if we can handle it via posting here ...

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
DSTAVERT
Immortal
Immortal
Jump to solution

The moral of the story here is "don't keep snapshots for extended periods of time". Take them for a specific purposes and commit them when done.

-- David -- VMware Communities Moderator
Reply
0 Kudos
continuum
Immortal
Immortal
Jump to solution

Isn't the moral of a story supposed to be given on the last line ? Smiley Wink

Personally I don't see a reason to give up at this stage - if the data is really so important

___________________________________

VMX-parameters- VMware-liveCD - VM-Sickbay


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos