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 = ""
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
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
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 ?
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
Peter - do you have any lockfiles - or otherVMs accessing the same basedisk ? - linked clones maybe ?
If not is rebooting the host possible ?
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
? - 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 ....
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
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.
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
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 ...
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.
Isn't the moral of a story supposed to be given on the last line ?
Personally I don't see a reason to give up at this stage - if the data is really so important