Possible Seeding / Duplicate VMDK issue

[Bunce]

Just a quick question:

Can Veeam handle a VM with multiple VMDK's, where two VMDK's may reside on different LUN's and hence have the same file name (auto-assigned by vSphere)?

I'm getting an error when trying to do an initial replication to removable storage on a new replication job, and wondering if its because its trying to write two files of the same name to the external drive..

Replicating object '[ADL-LUN02-TIER1-SASR05] ADL-FPS01/ADL-FPS01.vmdk'
BackupDiskFull failed
Client error: Failed to open VDDK disk [[ADL-LUN02-TIER1-SASR05] ADL-FPS01/ADL-FPS01.vmdk] ( is read-only mode - [true] )
Failed to open VMDK.
Logon attempt with parameters [VC/ESX: [adl-vc01.xxx.xxx.au];Port: 443;Login: [xxx\svcvbr];VMX Spec: [moref=vm-14271];Snapshot mor: [snapshot-18864];Transports: [hotadd]] failed because of the following errors:

Server error: End of file

Gathering the relevant details now to submit a query to support (5.01).

Backup jobs on this VM work fine, so logon credential error above appears to be misleading.

If the filename is the cause, what would the ramifications on previous and future jobs if I rename one of the VMDK's..

Would it be possible for Veeam to use some type of VMDK identifier when writing the replicated disks as opposed to the vmdk names? Actually, I'm guessing not as we wouldn't be able to bring up the VM quickly since the vmdk references in the vmx file would be invalid.

Perhaps a pre-job check for duplicate names is worth considering?

Cheers,
Andrew

[Gostev]

This is known virtual appliance mode limitation (documented in FAQ), so there is no sense to email support with that. vStorage API in hot add mode does not support processing VMs having disks with similar names. We cannot do anything about this from our side, until VMware fixes this issue...

[Bunce]

I had checked the release notes (given its the official documentation) and didn't see anything.

I'm not sure its actually a VMWare issue per se. They only need to identify the VM's uniquely, which by definition is <Storage Location>+<VMDK Name>, in addition to an internal identiier. Its Veeam which is not including the <Storage Location> part of the identifier, and doesn't allow selection of per-vmdk storage desinations for replication. That said, vSphere could perhaps offer a property where the user can select the VMDK name at time of creation to ensure uniqueness.

Anyway - the key question is how will existing backup jobs be effected if I change the VMDK filename? Will Veeam it consider it a new disk, and therefore need to go through the process of re-initialising CBT etc?

A

[Gostev]

I'm not sure its actually a VMWare issue per se.

You can be sure, because it is documented in the vStorage API release notes as known issue

I have not personally tested how VMware CBT or Veeam jobs will react to changing the name of the disk. To be on the safe side, it would be best to initiate full backup on the jobs containing VM in question after rename.

[Bunce]

Interesting...

From VDR 1.2 Release notes enhancements:

* Windows FLR Fails To Mount Multiple Disks With The Same Name
It is possible to back up a virtual machine with multiple disks with the same name. In such a case, each disk is associated with a vmdk located on a different datastore. when attempting to mount such disks through the Windows FLR client, only one of the virtual disks was mounted. This has been fixed and all disks will now be mounted.