VM RCVRY FAILS VMDK iSCSI Mapping (VMX) and VMDK Content

[CCastellanos]

FINDINGS

PRODuction VM (MAILNODE02) and VEEAM v9U1: One with multiple vHDD (x19), distributed across 3 SCSI Controllers (0,1,2). Each vHDD (VMDK) sits on its own dedicated datastore. Given this datstore isolation the VMDK name can at times be the same (no conflict as full path is different, see MAILNODE02.vmdk)

THE PROBLEM is that during a RECOVERY OPERATION (IR for this study) VEEAM fails at various layers:
- It does not map the vHDD iSCSI exaclty as in PROD (VMX File)
- VMDK File Decriptor points to both the wrong EXTENT (-flat) file and CHANGE TRAKING (-ctk) file.

Based on file nomemclature sequence and VMDK decriptor patterns we feel the issue's origin is in the alorigthm that calculates the vHDD to iSCSI mapping and the creation of needed new VMDK files content (remember, we are going from multiple dedicated datastores to a single VEEAM REPO NFS shared datastore).
*ONCE WE MODIFIED THE VMX AND EACH DAMAGED VMDK FILE THE VM TURNED ON PROPERLY.

PS: Notice that when VEEAM recovers this VM all vHDD are presented from a single REPO based NFS datastore (Perhaps VEEAM should emulate this datastore mapping behaviour)

FULL PUBLICATION: https://docs.google.com/a/goodwillny.or ... _U/pubhtml

Has this been reported before or is it possible it is a new glitch?
REPORTED UNDER Case #01873408

[foggy]

Hi Carlos, unfortunately, I cannot see the publication (access issue). Are you trying to restore VM that was backed up using storage snapshot? If yes, applying v9 Update 2 and running the backup again will probably help to address this issue.

[CCastellanos]

Thanks foggy, I will try your suggestion. I am getting the impression that if either the restore process includes emulating production datastore environment or the algorithm to handle the re-mapping/renaming of VMDKs and files was changed then it will still be an inherent problem.

I will also upload images of the report I created.

[CCastellanos]

Hi foggy please see public link for the document below.

https://drive.google.com/open?id=0B68P2 ... 3p0WDFlRjA

[foggy]

It is not clear from this files whether you're using backup from storage snapshots or not.