For VCB to be able to read via SAN - then all SAN based LUNs (which contain the ESX datastores) that are visible to your ESX host/farm also need to be visible to your VCB server.
At our site we use NetApp block FC storage for the ESX LUNs, and so our NetApp iGroup contains the WWPNs of all ESX hosts and VCB servers - and of course the VCB HBAs are zoned to the same ports on the back of the NetApp filer heads, i.e. the same ports as the ESX hosts are zoned to.
If you have never before zoned and presented the ESX LUNs to the VCB - then before you do this, you need to make sure that the Windows O/S will *not* claim the LUNs as its own:
...and then reboot - before you present LUNs.
The "disable" stops Windows from labelling the LUNs and SCSI persistent locking them.
The "scrub" clears any previous record of claimed LUNs.
You do not have to mount the LUNs in Windows - in fact you shouldn't - yes, you'll see them in Logical Disk Manager - just leave them alone - the "vcbmounter.exe" task that NetBackup runs will take care of things.
I have heard that multi-pathing the VCB is not supported. So, if you have two fabrics - then disable one of the HBA ports on your VCB server. Still zone both, and still add both VCB HBA ports to your storage host groups - but just enable the one from the VCB - this way you'll be able to manually failover quickly if the active HBA/port/fabric/SANswitch/SFP were to fail.
I read these documents but neither say that I need/do not need to run the "automount disable" as was necessary using VCB (thanks for that info sdw303). I would think it would be a good idea to run the "automount disable" on the VMWare backup host (Windows NBU media server) so that the VMWare datastore drives don't get mounted as a Windows disk.
I think Wrobbins is right as it pulls it directly from vcentre with no more staging needed.
I definately agree any shared luns should have automount disabled so definately do this if you are exposing your luns to multiple hosts.