The troubleshooting steps to be done for a CA ARCserve Central Virtual Standby Issue (Local Policy) is given below:
Virtual Standby Conversion job consists of the following phases:
- Creating Standby Virtual Machine (VM) container on the Hypervisor
- Uploading Metadata
- Transferring Data
- Creating Session Snapshot
- Creating Bootable Snapshot
1. You will find that the Virtual Conversion Job had failed as seen from the Virtual Standby console, you will need to troubleshoot on this.
Enable the D2D in Debug from the registry on the Source Node and the Monitor D2D node.
HKEY_LOCAL_MACHINE\SOFTWARE\CA\CA ARCserve D2D\Debug (DWORD)
Value : 1
Trigger a manual Virtual Standby Conversion job by pausing and resuming as seen in the screenshot below:
2. Observe this Virtual Standby Job and make a note of which phase it fails.
The webservice.log from the Source node and the Monitor node is the most important log to be referred for a Virtual Standby conversion job failing.
The webservice.log is found in the X:\Program Files\CA\ARCserve D2D\ Logs folder
3. From the webservice.log, if we find that the Virtual Conversion job failed to create the Standby VM container in the Hypervisor, then check for the events in the VMware or Microsoft Hypervisor. The common reasons for the Standby VM container not getting created will be due to permission related problem, which needs to be sorted out by the user.
Also refer KB Article https://arcserve.zendesk.com/hc/en-us/articles/202773755
4. If the Virtual Standby Conversion job fails during Uploading Meta data phase, do the following to narrow down the case.
Uploading meta data phase will copy the adrconfigure.xml and bitmap files from the Source Backup destination to the Hypervisor destination.
If the Hypervisor is Microsoft, try to copy these files manually to the location on the Hypervisor which is dedicated for storing the Standby Virtual Machines
If the Hypervisor is VMware, try to copy these files using the 'Upload' option from the Datastore that is dedicated for storing the Standby Virtual Machines.
If there is a bottleneck or delay in the above operation, remove this bottlneck and then attempt a manual Virtual Standby Conversion to check if it is successful.
If the manual copy of the meta data files is successfully complete, then do contact the CA Technical Support for further assistance.
5. If the Virtual Standby conversion job had failed in the remaining phases, you may check the webservice.log for the related error and the cause. A common troubleshooting step is given below which you may attempt based on your discretion.
You may want to clean up the Hypervisor destination of the Virtual Standby VMs and then start the Virtual Conversion Job from scratch. The following is to be done to achieve this:
(a) Unassign the nodes from the Virtual Standby Policy
(b) Delete the standby VM files from the disk on the Hypervisor
(c) Remove the Standby VM from the inventory of the Hypervisor
(d) Edit the Virtual Standby Policy, and provide a different VM Name Prefix than what was used before:
(e) Assign the nodes back to the Virtual Standby Policy
6. Step 5 should mostly get the Virtual Standby Conversion job run successfully.
In case you find the error '0x00000002 in the conversion log' then follow the KB article below:
If the above step does not resolve the failures, the do contact the CA Technical Support for further assistance. The logs required for diagnosis are the following:
- X:\Program Files\CA\ARCserve D2D\Logs from the Source node
- X:\Program Files\CA\ARCserve D2D\Logs from the Monitor node
If the source is a CA Central Host Based Backup node, then - X:\Program Files\CA\ARCserve D2D\Logs from the HBBU D2D Proxy