When does VMware Data Recovery use network based copy instead of SCSI Hot-Add?

Purpose

This article identifies the conditions in which network based copy is used instead of SCSI hot-add when performing a backup using VDR.

Resolution

VMware Data Recovery (VDR) attempts to use SCSI hot-add first. If that fails, VDR automatically falls back to a network based copy. There are several conditions under which SCSI hot-add is known to fail:

• The virtual machine being backed up has IDE disks. SCSI hot-add does not work with IDE disks.
• The datastore hosting one or more of the virtual machine's disks is not accessible to the ESXi/ESX host running the VDR Appliance.
• The VMware Data Recovery Appliance runs out of free Virtual SCSI slots. The appliance supports up to 4 SCSI controllers. Each controller can support 15 SCSI devices. This allows for 60 SCSI disks being attached. The appliance uses one of those slots for its boot disk and one for each VMDK-based Deduplication Store. You can add SCSI controllers as needed.
• The VMware Data Recovery Appliance is configured with Virtual SCSI Controllers other than "LSI Logic Parallel". Hot adding virtual disks to the appliance is supported only with the "LSI Logic Parallel" virtual SCSI controller.
• The configuration file /var/vmware/datarecovery/datarecovery.ini contains the option DisableHotaddCopy=1. For more information, see VMware Data Recovery: Enabling verbose logging and datarecovery.ini options (1013175).
• There is a limitation with mismatched block size. Hot-add cannot be used if the VMFS block size of the datastore containing the virtual machine folder for the target virtual machine does not match the VMFS block size of the datastore containing the proxy virtual machine. For example, if you back up a virtual disk on a datastore with 1 MB blocks, the proxy must also be on a datastore with 1 MB blocks. For related information, see Virtual Disk Transport Methods.

Note: There was an issue that unintentionally restricted backups for Essentials Plus. This issue is resolved with third-party backup products using VDDK 5.0 Update 1. This is also a known issue with vDR, and is being reviewed by VMware. This article will be updated as information becomes available.

Source:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012862