Unable to find matching device for LVID

[nholman]

Hi all

I am currently battling with a backup that will not work. it is just backing up 2 servers (exchange cas/mbx) and have utilised the SAN based snapshot backup feature as we have a lefthand SAN.
When it reaches a particular hard drive (#3) on the mbx vm it immediatley fails with the following error:
Processing 'servername' Error: Client error: Unable to find matching device for LVID '{4d528e58-7c87-a522-c63b-f4ce46a55c08}'

It backs up the first 2 drives without issue.
The virtual disk it is failing on is in a different storagelun/datastore to the vm and other hard disks - that is all i can see that is differnet about this vm.
The backup proxy is using direct san access and all the luns are connected in iscsi initiator and with automount disabled.

This error has also occured on another vm we have with a vritual disk attached pointing to a different lun/datastore. It seems to be any vm with an additional vritual disk pointing to a different datastore to the vm is failing with that error.

[foggy]

Nick, this is covered in the release notes document:

Veeam Explorer for SAN Snapshots, Backup from SAN Snapshots
• Virtual machines with virtual disk files located on different SAN LUN are not supported.

Thanks.

[nholman]

so the vms vmdk and associated virtual hard disk vmdk's have to all be contained on the same datastore (stored with the vm) ?

[foggy]

I've just talked to QC guys, according to them this should actually work. As long as VM disks are stored on one or several datastores located on the supported storages, it should be successfully backed up. The mentioned release notes statement applies to Veeam Explorer for SAN Snapshots only and should be corrected (as only disks residing on the same datastore with vmx file will be available upon restore from SAN snapshots via Instant Recovery and Windows/Linux FLR).

That said, it would be much appreciated if you could open a case and provide logs to our technical support so they could look a bit deeper into the possible reasons of the job failure in your case. Thanks!

[nholman]

thanks ive opened a case on this #00482495

[foggy]

Nick, your help is much appreciated. After investigating your logs, R&D has confirmed the issue that is scheduled to be fixed in one of the future product updates. The observed behavior can show up in cases where VM snapshot is not stored on the same datastore, where the VM disk itself is stored. Since you're on vSphere 4.1, by default all snapshots are stored in the VM's home directory, next to the VMX file, including the failing disk that is stored on another datastore.

As a workaround, you can remove existing VM snapshots, if this is acceptable.

[nholman]

Hi Foggy

Dont quite get what you mean by the workaround?

[foggy]

To avoid job failure during backup of this VM, you can remove its snapshots.

[nholman]

sorry but i dont understand because the snapshots are removed from the vmfs datastore once it takes a storage snapshot?

[foggy]

Does this VM have existing snapshots (not the temporary ones created during backup)?

[nholman]

no none at all

[foggy]

Sorry for confusion. It is a temporary VM snapshot, created on a different datastore than the disk itself resides on, that affects the backup process. So currently there seems to be no workaround for your particular case (vSphere 4.1, VM disks on different datastores).

[nholman]

OK. That leaves me in a bit of a rock and a hard place situation to be honest.

[foggy]

Do you have the ability to back those VMs up in a separate job using VMware snapshots until the hotfix addressing this issue is released?