Last year in December, I updated the first customer from HPE Data Protector 9.04 to 9.05. Immediately after the first tests I noticed, that backups were made using the NBDSSL transport. I expected that the SAN transport would be used, because the prerequisites were met and it has worked until the update. I opened a case at the HPE support und I was advised to install the hotfix QCIM2A65619. With this hotfix, several files were replaced:
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\components\DpSessionLogger.dll
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\ViAPI.dll
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\vCloudAPI.dll
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\DPComServer.exe
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\components\vepalib_vmware.dll
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\vepa_util.exe
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\vepa_bar.exe
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\components\vepalib_vcd.dll
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\components\DPHostingEnvironmentComponent.dll
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\components\CDpDataMoverComponent.dll
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\components\vepalib_hyperv.dll
x8664\A.09.00\VEPA\DP_HOME_DIR\bin\components\DpBackendService.dll
x8664\A.09.00\VEPA\DP_HOME_DIR\lib\vddk
The hotfix solved the issue. And to be honest: I didn’t care why it has worked after applying the hotfix. I had the same issue at multiple customers and applying the hotfix solved the issue in each case.
Today, I was reading through the HPE Data Protector 9.06 Integration Guide and the HPE Data Protector 9.0x Virtualization Support Matrix and I stumbled over this table:
| Data Protector versions | VMware VDDK component | Supported backup / mount proxy operating systems |
| 9.00, 9.01 | VDDK 5.5.0 | Windows Server 2003 R2 (x64) Windows Server 2008, 2008 R2 (x64) Windows Server 2012 (x64) RHEL 5.9 (x64) RHEL 6.2, 6.3 (x64) SLES 10.4 (x64) SLES 11 (x64) |
| 9.02, 9.03 | VDDK 5.5.3 | Windows Server 2003 R2 (x64) Windows Server 2008, 2008 R2 (x64) Windows Server 2012 (x64) RHEL 5.9 (x64) RHEL 6.2, 6.3, 6.4 (x64) SLES 10.4 (x64) SLES 11 (x64) |
| 9.04 | VDDK 6.0 | Windows Server 2008 R2 (x64) Windows Server 2012, 2012 R2 (x64) RHEL 6.6, 7.0 (x64) SLES 11, 12 (x64) |
| 9.05 | VDDK 6.0 U1 | Windows Server 2008 R2 (x64) Windows Server 2012, 2012 R2 (x64) RHEL 6.6, 7.0 (x64) SLES 11, 12 (x64) |
| 9.06 | VDDK 6.0 U2 | Windows Server 2008 R2 (x64) Windows Server 2012, 2012 R2 (x64) RHEL 6.6, 7.0 (x64) SLES 11, 12 (x64) |
There was a footnote for VDDK 6.0 U1.
The VM backups does not use SAN transport mode on vSphere 5.1, 5.5 (and its updates) environment and falls back to NBDSSL/NBD. This is because of VDDK 6.0 U1 issue. For more information, see VMware Knowledge Base.
Ups… that’s my issue! The footnote inclued a link to VMware KB2135621 (Virtual Disk Development Kit 6.0 U1 Backup and Restore commands fail using SAN transport mode on ESXi 5.5.x hosts on both Windows and Linux proxies). Described symptoms:
- Virtual Disk Development Kit 6.0 Update 1 backup and restore commands fail using SAN transport mode on ESXi 5.5.x hosts.
- This issue occurs on both Windows and Linux proxies.
Yep, that’s my issue. The customers that were observing this issue were running vSphere 5.5, not 6.0. With this knowledge, I checked the version of the vixDiskLib.dll on one of the patched Data Protector hosts. And there it was:
The vixDiskLib.dll had the build version 6.0.0 build-2498720, which is the build version of the Virtual Disk Development Kit 6.0. So it seems, that the Data Protector hotfix QCIM2A65619 makes a downgrade of the VDDK that is used by Data Protector.
KB2135621 describes, that this issue is resolved in in VMware vCenter Server 6.0 Update 2. This also implies, that this is fixed for VDDK 6.0 U2 and therefore Data Protector 9.06.
I’m sorry Data Protector. It was not your fault!