We have updated vRanger to the latest version (5.5) and we have a problem with the Quest Catalog Service.

After i updated vRanger the catalog service didnt started.

When i try to start the service i got the following error:

"Windows could not start the Quest Catalog Service on local computer. Error 1053: The service did not respond to start or control request in a timely fashion."

In the eventlog i see following message:

"A timeout was reached (393216 milliseconds) while waiting for the Quest Catalog Service service to connect."

and

"The Quest Catalog Service service failed to start due to the following error:

The service did not respond to the start or control request in a timely fashion."

I have already checked the database user accounts und rights but everything is correct.

I start the service with a local account who has administartor rights.

For the vRanger and Catalog DB we use a external MSSQL database.

We use the same hardware and software on 3 other sites and there we do not have this problem.

After downgrading upgrading from vSphere ESX4.1u2 to ESXi 5.0 we get a performance problems and snapshot problems all over the place.

A lot of VM now needs now some more time for creating a snapshot and vRanger Pro only waits up to 5min and than mark the backup task as failed. If the snapshot creation finishing a short time later this ends in an unwanted Snap which isnt automaticly deleted. Similar problem we have with a few custom quiescing scripts which needs more than 5min do to their job.

We are also ineffected that on a few VMs always two snapshots are created at the same time which ends up that vRanger cant use CBT when performing a LAN-FREE Backup. This problems also exists when performing a snap with quiescing in the vSphere Client. Looks like a VMware problem and a case was opened. But i already hear about this problem from a Quest SE earlier this year.

So.... how can i increase the timeout period for the vranger service?

For all who downgrading upgrading from vSphere 4 to 5 it would be wise to just to upgrade your smallest cluster first or just a few hosts and see what your vRanger 5.3 says. This environment has backuped 120 VMs every day with a success rate of >99%. After upgrading 2/3 of the (13)Hosts the rate drops down to 70% at a first try and the backup window isnt long enough anymore. Largest job of 65 VMs finished in 499min when use the old COS and with LAN-FREE we are down to 926min with 14 failures (after tweaking).

Problems we seen:

- VA Appliance cant be shutdown over vsphere Client (VMware Tools are installed)

- Double Snapsthots

- Snapshots leave behind

- Timeout problems, Failed to create vRanger snapshot, API Call Failure,  Error Message: Die zugrunde liegende Verbindung wurde geschlossen: Eine Verbindung, deren Aufrechterhaltung erwartet wurde, ist vom Server geschlossen worden.. , Error Message: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt., Error Message: Unable to continue Differential backup; the vRanger snapshot was not found. Error Message: RETRY timedout operation timed out [at xtimedwait:416], Error Message: Der Index lag außerhalb des Bereichs. Er muss nicht negativ und kleiner als die Auflistung sein.Parametername: index

- Duration period of running jobs are resetet when performing some work in vRanger (i deleted a batch of non-working Replication jobs). The task now shows a higher runtime than the job.

- Transport mode is not editable (modify is greyed out) so old replication jobs have to recreate

- LAN Mode is "slow" compared to COS and our Server, which use a older Quad Core XEON, is now CPU bound when reaching ~70MB/s incomming traffic and runing up to 10 task in parallel.

- The Name "VA-HotAdd" is not the right term because the work is not performing by the VAs and you have to install the vRanger in a single VM. So scaling looks limited to a single installation and depending of the enviroment the Backup is on wrong site when having a two production site. Otherwise you have to  presenting all LUNs to the Host which holds the vRanger VM.

Regards

Joerg

We are regulalry seeing this failure message and once it hits then all following backups fail (obviously). I'm guessing it's associated with the metadata.exe processes being stuck as I can guarantee I will see many of these whenever we see the failure message.

I'm at the point now where I have to reboot every other night to ensure success, which is crazy I'm sure you will agree. Does anyone have any idea when this will ever be resolved. This has got worse since upgrading to 5.5.

Thanks for any suggestions or pointers.

Hello,

how could I get a list of the members in a backupgroup?

Hi All,

I need to move only one VM-BackUp from old Repository to another Repository, that allready created and contained some VM-Backaps. How can I do it?

I've just found, how to move whole Repository with all VM- BackUps to the new one https://support.quest.com/SolutionDetail.aspx?id=SOL76842

but it's not what I exactly need -(

did somebody faced this issue?

Thanks in Advance!

I was looking for a solution with the minimum impact and the following one seems to be working pretty well.

First of all, this is not an official approach, Developers are working on this feature and sooner or later we will see it in the product.

This is a SQL script that modifies Ranger stored procedure (vz__SavePointSelectByTemplateIDAndVmUuidAndIsDeleted). It exploits one of the Full-backup triggers, VM disk size change to be exact. Sounds scary, right? No actual changes are made to either VM or DB:

• script submits ‘forged’ parameter if specific conditions are met,
• Ranger bites,
• script reverts changes.

What are the conditions when the script ‘forges’ parameter? Here they are: 

1. Job is defined as Differential or Incremental.
2. forcedFull tag is defined in the job description field and Job start time matches day of the week defined in the tag.
3. At least 1 savepoint for a given VM included in the job template exists and threshold defined in the job configuration is not met. (If threshold is met the script lets Ranger do its job and create Full SP.)

Instructions:

1. Run (once) forcedFull_01.sql script against Ranger DB
2. Modify Job Description to define day of the week when you would like Ranger to run Full backup. Format is <forcedFull = day_of_the_week> (e.g. <forcedFull = Sunday>)
3. Let scheduled job run.

If you don’t like the script and want to roll back:

To revert and use standard procedure re-run following script:

Filename:     CreateCustomStoredProcedures.sql

Location:      x:\Program Files (x86)\Quest Software\vRanger\Service\vRangerProDBUpgradeScripts

In the attached word document you can find diagrams and notes for 2 standard scenarios.

I have tested this script against non-English installation. Here are details:

Ranger is installed on Server 2008R2 Spanish edition:

1. Ranger DB is attached to included English version of SQL Express. You need to use forcedFull format described above.

2. Ranger DB is attached to Spanish version of SQL Express (separate installation). Day of the week should be in Spanish, e.g. <forcedFull = domingo>.

This post is open for vote, questions and comments.

Hello all,

I'm trying to use PS command line to add replication jobs, not having much luck. Has anyone gotten this working?

I've set my $vm to my vmguest and $vmhost to ESXHost.

Here's my command line that is failing with error:

CMD>

Add-ReplicationJobTemplate -JobName DR_RepJob_$vm -JobEntity $vm -TargetHost $vmhost -ReplicateName $vm"_DR" -Type Differential -targetDatastores DS_Dataxxx, DS_Dataxxx -PrimaryDatastore DS_dataxxx -targetnetworks dvPortGroup_xxxx -flags CheckDestinationFreeSpace, UseCompression

error "Unable to AddReplicationJob: {0}Object reference not set to an instance of an object"

Additionally, can someone point me to full documentation of CMDLETS? the get-help seems rather slim with information. I'd like to add the -JobSchedule parameter too but so far have not found any documentation for using it?

Thanks

Hi All -

Been poking around the documentation and these forums and haven't been able to find out of vRanger 6.x supports the vCenter VA.  Looking to move to the vCenter VA for one of our smaller setups and obviously need to ensure we can continue to do backups..

Any help would be appreciated.  Thanks!

-Craig

Hi everybody,

I've got one question with no answer from Quest Software...

Here is my configuration :

2 x ESXi 5 with VMware Essential Plus Acceleration Kit

1 x physical vRanger Server 5.2 with vCenter 5 Server.

San configuration : my physical vRanger can see all VMware Datastore Luns in windows disk manager (diskpart with automount disable and automount scrub).

vRanger configuration : VDDK SAN transport for lan free backup and lan backup if lanfree failed.

My problem :

I can't backup my VMs with LAN-free :

Lan Backup is ok.

My vRanger Server is not a VM so i don't need the hot-add function.

Authentication is ok to vCenter Server and ESXi host (with root account).

Does anyone have an idea ??

Thanks,

Regards.

KB 96837: Does vRanger 5.4/5.5 and 6 support ESXi 5.1?

New versions of ESXi/vSphere are usually supported within 60-90 days after its release.

vSphere 5.1 was released september 11th so I really expect that Quest releases a vRanger update with 5.1 support in a week or so!

I like vRanger apart from the slow GUI but the slow support for new versions of vSphere has really got me thinking if Quest/Dell spend enough resources on developing vRanger.

I'm sure that many customers are in a similar situation and wants the answer to the following questions:

When will vRanger support vSphere 5.1?

Once; vRanger was the leader in the backup VM market; what will you do to reclaim that spot?

Good day folks,

We currently have vRanger 5.0.0.19238 installed and working as expected in our environment. We want to move to vRanger 6.x and in doing so we are going to start with a fresh server, database install, configuration, repositories and implementing the vRanger Virtual Appliances. We are aware the license file needs upgraded to work with the new vRanger.

We are wondering if we can run both vRangers connecting to the same hosts but backing up different VMs to transition from 5.0.0 to 6.x?

I am trying to replicate a VM called TEST from one ESXi to a another, however the job fails. Did anyone succeed in replicating a VM in vRanger 5.2? I know that they just added the capability to do this with ESXi in this version. Here is some information on my environment:
- ESXi 4.1 U1 on the hosts

- vCenter 4.1 U1 Essentials Plus

- vRanger Pro 5.2

- virtual appliances are vzva 1.1.3

I followed all the instructions in the documentation but yet it fails. For specfics look at the log bellow:

[2011-07-22 13:22:09.332]: -------------------------------------------------------

[2011-07-22 13:22:09.367]: vRanger Backup & Replication - v5.2.0.22058

[2011-07-22 13:22:09.370]: Selected Options: Check destination for free space. | Update notes with the latest replication results. | Selected ReplicationTechnologyType: Differential Replication | Mapped Networks: [Mapped networks: Source Key 4000 -> NetworkName:VM Network] | Mapped Disks: [Mapped disks: Source Key 2000 -> DatastoreUuid:4e25924b-b004fc3e-2028-001e0bcd6f14]

[2011-07-22 13:22:09.372]: -------------------------------------------------------

[2011-07-22 13:22:09.758]: Loading latest data for virtual machine host 192.164.80.71.

[2011-07-22 13:22:19.427]: Host 192.164.80.71 found: Version 4.1.0

[2011-07-22 13:22:19.432]: Searching host for virtual machine data for Uuid: 564de945-7733-498a-9fbf-56fffc2de484.

[2011-07-22 13:22:19.435]: Found virtual machine data for TEST [vmx-07].

[2011-07-22 13:22:19.438]: VirtualMachine:TEST | Uuid:564de945-7733-498a-9fbf-56fffc2de484 | Vc: 127.0.0.1, Host: 192.164.80.71

[2011-07-22 13:22:19.441]: Loading latest data for virtual machine host 192.164.80.72.

[2011-07-22 13:22:19.749]: Host 192.164.80.72 found: Version 4.1.0

[2011-07-22 13:22:19.751]: Loading latest data for virtual machine host 192.164.80.71.

[2011-07-22 13:22:20.030]: Host 192.164.80.71 found: Version 4.1.0

[2011-07-22 13:22:20.032]: Searching host for virtual machine data for Uuid: 423d626d-e92c-af14-f6f7-508513b11067.

[2011-07-22 13:22:20.034]: Found virtual machine data for vRanger VA on 71 [vmx-04].

[2011-07-22 13:22:20.035]: VirtualMachine:vRanger VA on 71 | Uuid:423d626d-e92c-af14-f6f7-508513b11067 | Vc: 127.0.0.1, Host: 192.164.80.71

[2011-07-22 13:22:23.628]: Loading latest data for virtual machine host 192.164.80.72.

[2011-07-22 13:22:23.923]: Host 192.164.80.72 found: Version 4.1.0

[2011-07-22 13:22:23.925]: Searching host for virtual machine data for Uuid: 423dfb28-608e-491d-0376-19638d2fb7ae.

[2011-07-22 13:22:23.928]: Found virtual machine data for vRanger VA on 72 [vmx-04].

[2011-07-22 13:22:23.930]: VirtualMachine:vRanger VA on 72 | Uuid:423dfb28-608e-491d-0376-19638d2fb7ae | Vc: 127.0.0.1, Host: 192.164.80.72

[2011-07-22 13:22:23.979]: Could not find target virtual machine by UUID [423d0c06-d1df-03c5-8a3e-61624c5dc422].

[2011-07-22 13:22:23.992]: Unable to use transport ServiceConsole as the source host is an ESXi host.

[2011-07-22 13:23:06.194]: Loading virtual machine 'TEST' information completed.

[2011-07-22 13:23:06.204]: Checking to see if host 192.164.80.71 is in maintenance mode completed.

[2011-07-22 13:23:06.209]: Checking to see if host 192.164.80.72 is in maintenance mode completed.

[2011-07-22 13:23:06.279]: Loading virtual machine 'TEST' information completed.

[2011-07-22 13:23:06.307]: Checking minimum space needed on host 192.164.80.72 completed.

[2011-07-22 13:23:08.709]: Creating a snapshot for vRanger completed.

[2011-07-22 13:23:11.791]: Loading virtual machine 'TEST_Replica' information completed.

[2011-07-22 13:23:11.798]: Creating virtual machine 'TEST_Replica' completed.

[2011-07-22 13:23:12.993]: Creating a snapshot for vRanger completed.

[2011-07-22 13:23:13.091]: Loading virtual machine 'TEST_Replica' information completed.

[2011-07-22 13:23:13.104]: Attempting to replicate files with transport VirtualApplianceHotAdd

[2011-07-22 13:23:34.053]: Preparing mappings for device 2000 completed.

[2011-07-22 13:23:55.819]: Processing binaries on 192.164.80.72 completed.

[2011-07-22 13:24:41.018]: Replicating TEST from 192.164.80.71 to 192.164.80.72 completed.

[2011-07-22 13:25:13.841]: An exception occurred while attempting to replicate files with transport VirtualApplianceHotAdd, retrying with transport VirtualApplianceNetwork

[2011-07-22 13:25:15.409]: Reverting snapshot for TEST_Replica completed.

[2011-07-22 13:25:15.413]: Attempting to replicate files with transport VirtualApplianceNetwork

[2011-07-22 13:25:36.302]: Preparing mappings for device 2000 completed.

[2011-07-22 13:25:37.313]: Processing binaries on 192.164.80.72 completed.

[2011-07-22 13:26:01.606]: Replicating TEST from 192.164.80.71 to 192.164.80.72 completed.

[2011-07-22 13:26:48.302]: Reverting snapshot for TEST_Replica completed.

[2011-07-22 13:26:51.059]: Removing snapshot for vRanger completed.

[2011-07-22 13:26:51.479]: Removing snapshot for vRanger completed.

[2011-07-22 13:26:51.666]: Loading virtual machine 'TEST_Replica' information completed.

[2011-07-22 13:26:51.685]: Updating CID mapping for VM TEST_Replica completed.

[2011-07-22 13:26:51.766]: An internal error occurred during execution, please contact Vizioncore support if the error persists.  Error Message: 3201 - can't open [datastore1] TEST/TEST.vmdk

The errors I see are: "An exception occurred while attempting to replicate files with transport VirtualApplianceHotAdd, retrying with transport VirtualApplianceNetwork" and "An internal error occurred during execution, please contact Vizioncore support if the error persists.  Error Message: 3201 - can't open [datastore1] TEST/TEST.vmdk ".

Any ideas why these errors pop up? Thanks in advance for helping.

-AMC

Hi All,

I need to move only one VM-BackUp from old Repository to another Repository, that allready created and contained some VM-Backaps. How can I do it?

I've just found, how to move whole Repository with all VM- BackUps to the new one https://support.quest.com/SolutionDetail.aspx?id=SOL76842

but it's not what I exactly need -(

did somebody faced this issue?

Thanks in Advance!

KB 96837: Does vRanger 5.4/5.5 and 6 support ESXi 5.1?

New versions of ESXi/vSphere are usually supported within 60-90 days after its release.

vSphere 5.1 was released september 11th so I really expect that Quest releases a vRanger update with 5.1 support in a week or so!

I like vRanger apart from the slow GUI but the slow support for new versions of vSphere has really got me thinking if Quest/Dell spend enough resources on developing vRanger.

I'm sure that many customers are in a similar situation and wants the answer to the following questions:

When will vRanger support vSphere 5.1?

Once; vRanger was the leader in the backup VM market; what will you do to reclaim that spot?

Hi All,

I'm planning to backup/recover plan for vRanger server itself. Is my plan realistic ? And also after installing vRanger, I would like to change a host name and IP. Is it supported?

My plan is below:

At frist, I configure Master VM and install vRanger, If the trouble occurs in vRanger server, I will create the clone from Master VM. and I'll change the host name and IP of the clone VM. After this, I'll restore the vRanger DB from the vRanger DB backup.

Regards,

Sanae

Hey

I'm new to vRanger and atm I'm exploring the features/capabilities/GUI/etc.

So I successfully backd up a VM in my lab.

Then I deleted the VM and tried some restores but unfortunately it doesn’t work,

I always get the message in vCenter:

Reconfigure virtual machine

The device

or operation

specified at

index '9' is

not

supported

for the

existing

virtual

machine

1. platform.

vRanger tells me exactly the same.

vRanger tries to create the VM (VM shows up in vCenter for a second) and then I get this error and the VM disappears/gets deleted.

My setup:

vRanger 5.5 Build 25454

ESXi 5.1 Update 1 Build 768111

vCenter Server 5.0 Update 1 Build: 455964

I already tried to recreate the VM manually with similar hardware

hardware version 7

FreeBSD 64 bit

LSI Logical Parallel

E1000 NIC

1,6 GBRAM

2 sockets, 1 CPU per Socket

(That’s what I found in the config file backed up by vRanger)

But the errors is still the same.

Any suggestions where this error comes from?

It seems like a incompatible vhardware but the VM ran without problems before ...

By the way, is there a way to extract a vmdk file out of the vRanger .var files?

Regards

Patrick

Hello

Our vRanger 5.3 is backing up multiple VMs on multiple hosts without problems. Only one Linux VM on an ESXi 5.0 fails every time.

The messages in the log are:

[2012-02-22 09:10:49.425]: Gathering data for Srv03_Linux from API completed.

[2012-02-22 09:10:49.425]: Backup task will be attempted using a VDDK network connection.

[2012-02-22 09:54:26.269]: Backing up disk 'vix:r:192.168.145.51:902:[esx05_datastore2] Srv03_Linux/Srv03_Linux.vmdk:moref=vm-39253:snapshot-39727:3' completed.

[2012-02-22 09:54:28.675]: Checking and enforcing retention policy completed.

[2012-02-22 09:54:37.003]: Removing snapshot for vRanger completed.

[2012-02-22 09:54:43.769]: An internal error occurred during execution, please contact Quest support if the error persists.  Error Message: The database trasaction was rolled back.

The machine is copied over the network, but at the end something fails and the backup is deleted from the repository. I think the error message is misleading, as I have run SQL Profiler and could not see an SQL error.

Thank you very much for your help!

Hello,

When backup is finished, only one VM needs consolidation. The snapshot is not released and when i want to consolidate manualy there is a lock (mac adress is service console of the host) on unspecified filename.

The only possibility is to reboot the host where the VM is hosted.

Any ideas?

Thank you.

I've opened a support ticket to.