Direct SAN not working for vsphere 6.0?

[danswartz]

My "production" host connects to SAN (SCST iSCSI) via 40gbe ptp link, as well as 1gbe link (not-preferred in vsphere software iSCSI path setup). Server 2008r2 proxy runs on same host. Direct san backup was working fine with vsphere 5.5. Last night I created a new 6.0 VCSA and decommissioned 5.5 VCSA. Also upgraded two vsphere hosts (one 'production' and one 'backup' [for clustering stuff]). Ever since then, direct san does not work. Ironically, I think I will get better performance from hot-add, since it can fetch the blocks via the 40gbe enet, but I'm OCD and would like to know why direct san is not working (as well as fear that I may have not set something up right.) I did a test job to back up only one VM to reduce size of logs to grovel through. Here is what I saw in one log:

Code: Select all

[18.06.2015 10:50:02] <01> Info     [ProxyDetector] Host storage 'VMware ESXi 6.0.0 build-2494585' has 2 luns
[18.06.2015 10:50:02] <01> Info     [ProxyDetector] Searching for VMFS LUN and volumes of the following datastores: ['ESOS ZFS Raid10']
[18.06.2015 10:50:02] <01> Info     [ProxyDetector] Datastore 'ESOS ZFS Raid10' lun was found, it uses vmfs
[18.06.2015 10:50:02] <01> Info     [ProxyDetector] VMFS LUNs: ['SCST_FIO Local SCSI Disk (eui.6666376632356635)'], NAS volumes: <no>
[18.06.2015 10:50:02] <01> Info     [ProxyDetector] Trying to detect source proxy modes for VM [Sophos UTM], forceNbd:False, has snapshots:True, disk types:[Scsi: True, Sata: False, Ide: False]
[18.06.2015 10:50:02] <01> Info     [ProxyDetector] Detecting storage access level for proxy [VMware Backup Proxy]
[18.06.2015 10:50:02] <01> Info         Testing proxy ip [10.0.0.13], netmask [255.255.255.0]
[18.06.2015 10:50:02] <01> Info             Testing host ip [10.0.0.4]
[18.06.2015 10:50:02] <01> Info             Host [This server] - IP address [10.0.0.13] is in the same subnet as host [10.0.0.4] IP [10.0.0.4]. Subnet mask [255.255.255.0].
[18.06.2015 10:50:02] <01> Info             Proxy [VMware Backup Proxy] - is in the same subnet as host [VMware ESXi 6.0.0 build-2494585]
[18.06.2015 10:50:02] <01> Info     [ProxyDetector] Proxy [VMware Backup Proxy]: Detecting san access level
[18.06.2015 10:50:02] <01> Info     [ProxyDetector] Proxy [VMware Backup Proxy]: disks ['6000C298767CA7A9EDCF98E0083B9C74566972747561','6366306363323838766565616D20','6366306363323838766565616D20']
[18.06.2015 10:50:02] <01> Info     [ProxyDetector] Proxy [VMware Backup Proxy]: No disks are are accessible through san but can failover to network
[18.06.2015 10:50:02] <01> Info     [ProxyDetector] Detected san storage access level for proxy [VMware Backup Proxy] - [SameSubnetwork]
[18.06.2015 10:50:02] <01> Info     [ProxyDetector] Detected mode [nbd] for proxy [VMware Backup Proxy]

It doesn't tell me where to find out *why* they are not accessible through san. Any tips of where to look? Thanks!

p.s. forgot to mention: I did in fact confirm that the LUN is visible (connected) in the proxy's iSCSI app, as well as showing as offline in the disk management snap-in.

[foggy]

Dan, are you at the latest Veeam B&R patch level?

Unfortunately, as some of you already know, VDDK 6.0 also brakes a few things with certain environment-specific bugs which we (or VMware, for that matter) were unable to catch in our test labs. Here is the summary of all issues:

1. VDDK 6.0 function crash in the Direct SAN processing mode when a backup proxy has multiple network interfaces with IPv6 enabled. Hot fix that patches the faulty VDDK function is already available from our support, and will be included in Update 2a (new build of Update 2).

[danswartz]

8.0.0.2021. I see 8.0.0.2030 is the latest. The proxy only has one interface, so it's surprising this would be the issue, but I will upgrade and post back my results...

[danswartz]

Upgraded to 8.0.0.2030. No joy...

[danswartz]

Should I open a case?

[foggy]

Yes, that would be the most effective way of addressing this issue.

[danswartz]

Will do...

[danswartz]

Case 00948895 opened.