Restore from Nimble snapshot fails

[ckbrou]

Case # 02129187
I have been spinning my wheels with vmware support for about a week and moving forward slowly but surely with Veeam support. Time to see if the community can provide any insight.

We recently migrated from a NetApp to Nimble storage array. Veeam and Nimble integration seemed to be functioning well. The array connects in Veeam, I can see the snapshots, and backups are working well using the storage snapshots. But when I try to do a restore from Nimble snapshot it fails while trying to resignature the snapshot data store. See job log: http://imgur.com/bX3kBdd

I do have somewhat of a non-traditional topology and wonder if it could be causing issues.


I am attaching a crude diagram of our vmware / UCS / Nimble / Veeam topology. Here: http://imgur.com/a/eKkhX

Some quick highlights
•Production iSCSI traffic is connected directly to Cisco UCS 10 Gbe appliance ports (118 and 119 subnets)
•iSCSI traffic never traverses the TOR 3850 switch (118 and 119 are not even defined there)
•The Physical Veeam backup server is connected directly to the Nimble array via a 1Gb link using the 120 subnet. This traffic also never touches the TOR switch and 120 is not defined there.
•There is a dedicated iSCSI nic on the Veeam backup server with a 120 subnet IP address.

This works well for backups using Nimble integration and direct SAN mode. When the backup takes place all works as expected. It triggers the Nimble storage snapshot and backup traffic traverses that dedicated backup traffic connection between the Veeam server and Nimble array.


I wonder though if this topology is creating an issue during the restore. Is it possible that Veeam is telling vmware to mount the snapshot using the 120 subnet or the corresponding discovery IP for that subnet? I have been digging through vmware and Veeam logs and just can’t seem to find those details.

[ckbrou]

Finally figured this out! All issues were caused by having port binding enabled in vmware while having multiple iSCSI subnets.

https://kb.vmware.com/selfservice/micro ... Id=2038869

According to vmware, this is a major configuration issue but it only showed itself during the Veeam restore. Once we remove all port binding from the host all started working as expected.