As a VADP compliant application, Veeam Backup & Replication leverages VDDK libraries to interact with VMware vSphere environments to request VM snapshots, extract data from ESXi, and other operations. Depending on the version you are using, you are effectively running different versions of VDDK. Sometimes it’s important to know which one, to be sure if an unexpected behaviour is a known issues of that version or not.
VDDK versions in Veeam
Starting from Veeam Backup & Replication 7 Patch 2 (also called R2, I admit this numbering created a little confusion), the official support for vSphere 5.5 was added. This one was an important milestone not just for the support of this major release from VMware, but also because Veeam decided to run two versions of the VDDK framework in the software. At first, this may sounds strange, but it makes sense if you follow me.
The biggest news of vSphere 5.5 and its VDDK 5.5 was the switch from a 32bit to a 64bit architecture. One of the immediate consequence was the need to deploy 64bit operating systems to run Veeam Proxies, in order to be able to run Veeam against vSphere 5.5. But, to stay on the safe side, Veeam is also using VDDK 5.0, and everytime a new activity is started, VDDK 5.5 is only leveraged when there’s a vSphere 5.5 to connect to, otherwise VDDK 5.0 is still used. This helps using the most stable and “appropriate” VDDK in regards to a given version of vSphere, while the new 64bit VDDK libraries become more mature.
You can clearly see this by crwaling a little bit into the Veeam installation: by going into C:\Program Files (x86)\Veeam\Backup Transport\, you will notice two folders, x86 and x64, each holding the corresponding VDDK libraries versions.
But there’s more. As any software, VDDK has bugs and known issues, and VMware go fixing them by releasing new versions of the VDDK framework. As an example, when VDDK 5.5 can out (so, in 5.5.0), there was this bug when backing up vmdk at 2TB or larger with HotAdd. The same bug was solved in VDDK 5.5.1 few months later, so customers running the updated version of the framework would have the issue solved. But, VDDK is executed at the client side, and the client side is the backup software, so Veeam in our case. Together with the patches, Veeam from time to time also releases updated versions of the VDDK framework, so the question could now be: which VDDK version is shipped with a given build of Veeam Backup & Replication? And how can I check it?
Checking the version is pretty easy: simply open both subfolders of C:\Program Files (x86)\Veeam\Backup Transport\, look for VMware DLLs like vixDiskLib.dll anc check its details, you will see something like this:
If you do not have all the different versions of Veeam at your disposal to check, here is the complete list starting from Veeam 7 Patch 2 (the first supporting vSphere 5.5):
VBR 7.0 p2 (7.0.0.771) – 13 november 2013
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.0 build 614080
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_5_5 = 5.5.0 build 1284542
VBR 7.0 p3 (7.0.0.839) – 13 February 2014
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.0 build 614080
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_5_5 = 5.5.0 build 1284542
VBR 7.0 p4 (7.0.0.871) – 5 June 2014
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.0 build 614080
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_5_5 = 5.5.1 build 1601882
VBR 8.0 (8.0.0.817) – 6 November 2014
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.4 build 1890768
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_5_5 = 5.5.2 build 1890828
VBR 8.0 p1 (8.0.0.917) – 25 December 2014
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.4 build 1890768
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_5_5 = 5.5.2 build 1890828
VBR 8.0 p2 (8.0.0.2021) – 28 April 2015
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.4 build 1890768
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_0 = 6.0.0 build 2498720 (used for vSphere 6.0 and 5.5)
UPDATE: Update2 for version 8 introduced VDDK 6.0 that superseeded VDDK 5.5. vSphere 6.0 and 5.5 are now supported by VDDK 6.0. ESXi 5.1 and older are processed using VDDK 5.0.
VBR 8.0 U3 (8.0.0.2084) – 8 October 2015
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.4 build 1890768
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_5_5 = 5.5.2 build 1890828
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_0 = 6.0.0 build 2498720
VBR 9.0 (9.0.0.902) – 12 January 2016
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.4 build 1890768
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_0 = 6.0.0 build 2498720
VBR 9.0 U1 (9.0.0.1491) – 24 March 2016
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.4 build 1890768
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_0 = 6.0.0 build 2498720
VBR 9.0 U2 (9.0.0.1715) – 22 July 2016
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.4 build 1890768
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_0 = 6.0.0 build 2498720
VBR 9.5 (9.5.0.711) – 16 November 2016
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.4 build 1890768
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_0 = 6.0.2 build 3566099
VBR 9.5 U1 (9.5.0.823) – 20 January 2017
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.4 build 1890768
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_0 = 6.0.2 build 3566099
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_5 = 6.5.0 build 4604867
VBR 9.5 U2 (9.5.0.1038) –
C:\Program Files (x86)\Veeam\Backup Transport\x86\vddk_5_0 = 5.0.4 build 1890768
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_0 = 6.0.2 build 3566099
C:\Program Files (x86)\Veeam\Backup Transport\x64\vddk_6_5 = 6.5.0 build 4604867
So, in my example before, in order to avoid the HotAdd bug, you should use at least Veeam Backup & Replication 7.0 Patch 4. And in general, this is another good reason for keeping your Veeam installation always up to date. As you can see, different versions have different support VDDK libraries; the general rule is that Veeam uses the latest available version for a given edition, so that new bugs introduced by newer versions will not affect previous versions. vSphere 5.x for example will always be processed using 5.0.4 libraries, regardless which new VDDK is available for newer versions. This guarantees the best stability of VDDK operations.