Recreate .vmx and vmdk discriptor file and merge snapshots

[Sensei30]

Hi all,

I am running ESXi 5.0 and I'm missing the vmx and descriptor file of a particular VM.

The machine is running fine untill I shut it down. After shutting down I will not be able to restart it before I have recreated the descriptor file and created a new .vmx.

The only files which are in the VM folder are:

-rw-------    1 root     root        23152713728 Sep 19 22:43 TS1-000001-delta.vmdk

-rw-------    1 root     root                  0 Sep 19 22:14 TS1-b4014f27.vswp

-rw-------    1 root     root        80530636800 Sep 19 22:38 TS1-flat.vmdk

-rw-------    1 root     root        20166422528 Sep 19 22:14 TS1_1-000001-delta.vmdk

-rw-------    1 root     root       107374182400 Sep 19 23:03 TS1_1-flat.vmdk

-rw-------    1 root     root                  0 Sep 19 22:09 vmx-TS1-3019984679-2.vswp

I was able to recreate the disk descriptor file and mount it to a new created VM with the same specs as the old one.

It will boot, the only problem is that the disk does not contain the last data of the snapshot. So it is pretty useless now.

So my question is: Which step do I have to follow (and at what moment) for merging the snapshot disk with it's parent?

I have a backup of the unmodified vmdk's and the snapshot files listed above.

I hope that someone can point me in the right direction.

Thanks in advance.

Used sources: Missing vmx and vmware.log file and VMware KB:    Recreating a missing virtual machine disk descriptor file

 

[a_p_]

Welcome to the Community,

snapshots are used in chains, i.e. you need to recreate the snapshot chain for each of the two virtual disks (see attached .vmdk files) and make sure that the .vmx file points to the latest snapshots.

An easy way to recover would be to create a new VM with the current VM's name "TS1" and two virtual disks (the size of the virtual disks doesn't really matter) and create a snapshot. Then replace the new VM's .vmdk files with the descriptor files in the attachment of this post, and the backed up delta/flat .vmdk files.

If you want to do this differently - i.e. with manually editing the VM's .vmx file - make sure you relaod the configuration after editing the file (seehttp://kb.vmware.com/kb/1026043)

André

[Sensei30]

Hi, thank you for your quick reply.

For keeping the post short, I renamed the virtual disk names in this post.

Actually they are named like this:

Windows Server 2008R2 (HTH) TS1-000001-delta.vmdk

Windows Server 2008R2 (HTH) TS1-b4014f27.vswp

Windows Server 2008R2 (HTH) TS1-flat.vmdk

Windows Server 2008R2 (HTH) TS1_1-000001-delta.vmdk

Windows Server 2008R2 (HTH) TS1_1-flat.vmdk

vmx-Windows Server 2008R2 (HTH) TS1-3019984679-2.vswp

It also does not correspondents with the virtual machine name because we renamed it in a later stage (that is were the confusion started and we deleted the folder with the old name where the log files and vmx was still there.

Can I just rename your posted files to the above names and follow the procedure you described?

Thanks in advance.

PS. can I delete the .vswp files?

[a_p_]

Yes, you can certainly rename the files, but you also need to replace the file names within the files accordingly.

André

[Sensei30]

Hi, I followed your procedure and now the the VM settings shows the wrong size of the disk 40GB instead of 75GB and 40GB instead of 100GB

So the size of the new (temporary) disks does matter? In your description you said it doesn't.

Do have to start over or can I change that somewhere?

The server is booting anyway but is unresponsive... :smileysad:

Thanks so far.

regards,

[Sensei30]

I recreated a new VM with the correct disk sizes and replaced the vmdk's with the ones created in the previous steps.

Server is booting, the settings shows the correct disk sizes. Windows still unresponsive. I think that it is another issue.

Thank you very much for your help.

Best regards,

[a_p_]

The incorrectly displayed disk sizes might have been an issue with refreshing/reloading the VM (e.g. remove from/add to the inventory). Anyway, when you say unresponsive, do you mean that nothing happens (i.e. the VM doesn't even boot), or is it Windows which is unresponsive after booting? Please explain. If it is Windows, try to boot into Safe Mode to see whether this helps.

André

[Sensei30]

Hi there,

Windows was booting, but in the stage "applying computer settings" it looked like it was freezing. I just had to wait a very long time.

The problem was that Windows lost the trust relationship with the domain controller. That's why it took a long time to apply computer settings from GPO's, etc.

After disjoining en rejoining to the domain, everything was working correctly.

Thanks for your help, you've saved my day (and my mood)!

BR.

[Sensei30]

Hi,

If I want to do the same trick for another VM on the same host, do I have to change more values besides the disk name in the descriptor files you've posted?

The 2 disks are 500GB each.

I think I have to change the RW value to 1048576000

But do I have to change for example the CID value? Does this have to be unique in the vmware environment? And the UUID? etc

Thanks in advance.

BR,

[a_p_]

What you need to do - besides changing the file names - is to modify the size values. For the base virtual disk's .vmdk file these are the number of blocks as well as the C/S/H values. For the snapshot's .vmdk file it's the number of blocks. For the proper chaining it's important to set the correct "parentFileNameHint" and to make sure that the "parentCID" matches the value of the parent virtual disks's "CID". Unless I'm mistaken this can be any 8-digit hex value between "00000001" and "ffffffd", doesn't have to be unique in the environment, and is only used to ensure the integrity of the chain. You can create the .vmdk descriptor files without a "UUID" and/or "longContentId".

To get the required values, either create a dummy (thin) virtual disk as mentioned in the KB, or use the VMDK Stub File Generator that you can find at e.g. Internet Archive Wayback Machine

One more hint. If there are multiple snapshots, it's important to chain them in the correct order, which cannot necessarily be derived from the file names of the delta files. It's more the timestamps which may help determine the proper order in such cases.

André

[Sensei30]

Thanks! worked like a charm

BR