Please copy all six file to another container or folder
Create new vm and don't assign new hdd.
Attached the existing files which you have left
In you scenario. You have to attach "VAPWUXFP01_1-000002-delta.vmdk" file to the VM because this is latest snapshot file which was running on your server.
Please let me know in case if you have any questions.
Please mark the answer
Or attach "VAPWUXFP01_1-000002-delta.vmdk" to you existing running VM and fetch the data (need to copy all the vmdk files to the VM folder which you have)
In case if you are creating new VM, first OS should install and attach existing left over files to fetch the data, best option is recover from the backup.
- Highest delta file doesnt indicated that this is the most current VM state. Most likely it is.. but you always have to check the descriptor file and the parent ID
If the vmx is present and you wanna check:
grep vmdk *.vmx
and it will tell you which vdisk delta the VM is currently using. You also can take a look to the timestamp and maybe with some guessing you can identify the order because there old vmdk are not updateting anymore.
One and only safe way is to open the descriptor and check the parentID.
- You havent told us which ESXi version your using or more important which GUI tool. Because i remember to the old days that vSphere Client only display the parent vDisk and never the snapshot one which makes it impossible to use the GUI when working with a snapshots!
- Most important now... since you have bootet the VM from the old parent vDisk the snapshot chain isnt right any more. Even if you add the latest snapshot delta as current vDisk you will get an error about there was a modification of existing vdisks. You have correct an ID in all 3 descriptor files to tell the VM that the chain is consistent. This ID is updates with every powering On of a VM.
Welcome to the Community,
you hopefully powered off the VM immediately after discovering that it showed old data !!! If not, do it now.
The longer the VM runs, the more modifications, which results in a higher risk of data corruption, or loss.
Please attach the three descriptor .vmdk files (the ones without flat, or delta in their names), along with the newly created configuration (.vmx) file to a reply post.
The correct snapshot chain in this case is:
VAPWUXFP01_1-000001.vmdk -> VAPWUXFP01_1-000002.vmdk -> VAPWUXFP01_1.vmdk
Depending on the snapshot sizes, and for how long the VM has been powered on with the incorrect snapshot chain, you may see more or less corruption.
What you may do now is:
- power off the VM (unless not already done)
- unregister the VM from the inventory (Caution: do NOT delete it from the disk)
- edit VAPWUXFP01.vmx, and change the virtual disk's name (likely disk 2) to "VAPWUXFP01_1-000001.vmdk"
- upload the attached descriptor .vmdk files to the VM's folder
- register the VM to the inventory (rigth click its .vmx file in the datastore browser)
- create a new snapshot to have a way back to the current state in case it is necessary
- power on the VM
At that point you should be able to see (and backup) your current files.
However, due to the issue you should at least run chkdsk to verify/fix logical disk errors, if you want to continue using the virtual disk.
VAPWUXFP01.zip 1.3 K
I have lost the original VM, including the .vmx file
Left only the six files mentioned.
In your initial post you wrote:
I create a new VM and attached file VAPWUXFP01_1.vmdk, but I only see old data dated 2015 or earlier.
So what you may do is to modify this VM's settings, by following the steps I mentioned.
You try to boot the VM all by itself ?
That makes no sense.
Looks like the original boot vmdk is lost - judging from the name of the vmdk files you still have.
This vmdk will not boot - best you can acchieve is to read the data from a LiveCD or second best from a helper VM.
Make sure to create another snapshot first to protect the content of the existing snapshot.