greetings ,
my name is shadi from jordan , my problem is big my job at risk :smileysilly: i need any help and full support ,
problem :
one of vm is crush and give me error from normal to invalid and the vm name is change now i read some topic tha problem is recreate a missing Virtual Machine Disk Descriptor File and its qork and vm is up and work fine but its old version before import data like 6 month ago and i have snap its new i want to add it i take the snap like 1 and half month from now .
thank you
Welcome to the Community,
you hopefully shut down the VM immediately after you discovered the old state!? The longer it runs in this state, the higher are chances for data corruption!
One quick question in advance, do you have a current backup?
To find out what can be done, shut down the VM (unless already done) and provide the following:
Please compress/zip the files, and attach the resulting .zip archive to a reply post.
Note: Please make sure that the .vmx, and .log filesdon't contain usernames, or passwords (e.g. in the Annotations)
André
Greetings ,
its happen when i shutdown the physical server to upgrade ram when i turn server on i saw one of machine is down and cant power on and as isaid then name of host was change with long random name with status change from normal to invalid and i check the data from storge that all config file and other file is missing just 2 file was in folder the extcation is vmdk (HR System_0-000001-delta.vmdk size is 9gb)(HR System_0-flat.vmdk size is 200 gb ) , so i google it some of topic say unregisry the machine and create new one and put vmdk back by click exitting hhd so i did it but is not apper shown so i read topic called Recreating a missing virtual machine disk descriptor file (1002511) so i did it and the vm is work and online again but age of vm 5 month ago database is empty
i will send you all photo in attached file
please if u can help me before sunday and you can remote access to see and do some troubleshooting by using anydesk or teamviewer or else please try connect me in whatsapp 00962795608606
From what you describe, I assume that the missing files got deleted earlier, i.e. not at the time when you shut down the host. The metadata files are usually kept in memory, so that the VM can run even without them on disk. Anyway, what's important are the flat, and delta .vmdk files, which you still have.
One quick question though. Did you backup the .vmdk files before or after you recreated the missing descriptor file(s), and powered on the VM? In case you did the backup prior to powering on the VM, we may be able to recover it without data loss, or corruption.
What basically needs to be done is to create descriptor files for both. the flat, and the delta file. Then chain these files correctly, and attach the snapshot file to the VM.
So with the current information you gave so far, please provide the following:
André
good day
as i say before with friends help i recovery the flat vmdk but with old metadata before any new datase in server now we try to chain the sanp(delta) with flat but still dont work
please provide me with
1 - repair tools to check delta file if curpted and how to fix it
2 - how to meage flat with delta to one vm with clone way and comand , i dont have appliance server but i can insatll it if it nessary
3- can i extract data from delta
4 - can i but delta in new flat vm
Best Reagrds ,
Please provide the information I asked for in my previous reply.
This information is needed to determine how to proceed.
André
You can try below VMware kb article to re-create missing descriptor file for Flat and delta vmdk.
Recreating a missing virtual machine disk descriptor file (for corresponding Flat.vmdk)
Recreating a missing virtual disk (VMDK) descriptor file for delta disks
NOTE:Make sure you take a backup of the VM folder before try above mentioned KB article.
This is to make sure you have the original file (VM file like vmx, vmdk, etc)and we do not make it worse by following the above procedure.
If you found this or any other answer helpful, please consider the use of the Correct or Helpful to award points.
Best Regards,
Deepak Koshal
CNE|CLA|CWMA|VCP4|VCP5|CCAH
If you want to repair a bad delta do NOT try to run vmware-vdiskmanager.exe -R name-delta.vmdk.
It will fail always.
Instead you must give the descriptorfile for the delta as argument.
This will also fail if the referenced basedisk is not present.
Feel free to call via skype if necessary ...
Ulli
the free disk space on the datastore is : 257 GB .
the time when you backed up the .vmdk files is : before .
size in bytes for the .vmdk files is : (HR System_0-flat = 214,748,364,800) and (HR System_0-000001-delta = 9,294,991,360) .
after i did all this step still i need to merage delta file and flat and chain them togther with CID how i can do it and i read some topic say if delta file more than 2gb it will not work
the time when you backed up the .vmdk files is : before .
That's good. In this case we should be able to fix the issue without data loss, or corruption.
I've attached a .zip archive with the descriptor .vmdk files for your flat, and delta files, as well as a configuration (.vmx), and a snapshot descriptor (.vmsd) file.
What I actually don't know, is whether the virtual disk has been thin, or thick provisioned. In case it's a thick provisioned virtual disk, then you need to delete
ddb.thinProvisioned = "1"
from the "HR System_0.vmdk". You also need to remove this line, if you are going to use the virtual disk on your PC, i.e. in VMware Workstation.
Steps to do (assuming you are working on the ESXi host):
If everything works as expected, and you are seeing the current data you may consider to delete the snapshots from the Snapshot Manager.
André
Hi Andre
while you were writing your last reply we already were in a remote session fixing the problem.
Sorry for your wasted efforts - case has beeen solved without any dataloss .
A final checkdisk is still required - but the lost database is present, readable and uptodate.
The VM will be discarded now and so no further actions on this VM are necessary.
Ulli
Sorry for your wasted efforts - case has beeen solved without any dataloss .
No need to apologize. What counts is that the issue could be solved. Well done (as expected).
André