Since the problem involves vRanger running out of addressible Virtual Memory on the vRanger machine, attempt to lessen the Virtual Memory load the application is placing on the machine at any given time.The following combined activities can help reduce the occurance of the issue.
- Amend the backup jobs to contain fewer VMs in each job. This can be done by setting up custom VM Backup Groups in vRanger (on the "My Inventory" screen), each of which would contain a smaller "chunk" of the VMs in the original backup job. Create new backup jobs for these that overlap as little as possible. This reduces the amount of VMs in "queued" status at any given time, lessening the Virtual Memory demands the vRanger machine must service.
- In vRanger, lessen the amount of concurrent backups that are processed. Go to Tools--->Options--->Configuration, and look at the settings. Change the "Maximum Tasks Running Locally" value to no more than "4", and the "Maximum Tasks Per Repository" setting to no more than "5". Lowering these values reduces the chances of the vRanger machine being overstressed by too much data being processed on it at any given time.
- If running several backup jobs that tend to "overlap" (i.e. the first job is not finished before the second is queued and run, etc.), increase the interval of time between these jobs to lessen the overlap.
Additionally, there is a .Net patch from Microsoft to address memory leaks in the .Net Framework. Follow this link to install (if not already installed on the vRanger machine):
http://support.microsoft.com/kb/981575
This KB was rolled up in SP1
Disabling the Quest Software metalocking feature for backups can help lower Virtual Memory usage as well:
- On the vRanger machine, browse to the install directory of vRanger.Then open the "Service" folder, and edit the file labeled "Vizioncore.vRanger.Service.exe".
- Find the line labeled "<add key="DisableVZMutexLock" value="False"/>
- Change the value labeled "False" to "True"
- Restart the three vRanger services in Windows (stop first in this order: vRanger FLR, vRanger API, vRanger Service, then start the services in the OPPOSITE order).
Alter the type of backups being performed (ESX only):
- If you have some problem backups that continue to show this behavior even after these suggested procedures, try using LAN-based, Direct-to-Target backups for these instead of SAN-based backups. The LAN-based backups do not exhibit the problem, so this could help stabilize the situation.