KB labels

Ticket Product Version

Ticket Category

Ticket Assignee

Hot Fixes

Published Fixes
Your Arcserve Support User Profile
First Name:
Last Name:
Customer Type:


Time zone:

arcserve-KB : RHA | Unable to check HyperV state: Application specific integrity testing is failed

Last Update: 2016-11-17 16:46:11 UTC
Description:  You have an assured recovery (AR) test failing for your hyper-v scenario with the above message.  Your AR tests may or may not have previously worked.  

Solution:  You should first see why RHA is reporting AR is failing by checking the replica server's RHA logs.  In the 64 bit program files install directory (program files\ca\arcserve rha\engine\log) inside the log folder open the ws_rep.log file from the time the AR test failed.  In this case we saw the following info: 

'(9/9/2016 4:43:28 PM) Failed to turn on vm, error messages: 'ReplicaVM' failed to start. (Virtual machine ID 6279F150-C352-4EFC-9EA1-ED39844455F), error code: 32768.

(9/9/2016 4:43:38 PM) error->turn on vm failed!

(9/9/2016 4:43:38 PM) error->turn on vm failed!
(9/9/2016 4:43:38 PM) error->Failed to AR prepare!
(9/9/2016 4:43:38 PM) error->AR Testing for application [HyperV] failed. Reason: Application specific integrity testing is failed.
(9/9/2016 4:43:38 PM) Notifying scenario 1252151892, host 2; message id: ER00431, message: Integrity Testing on Replica ReplicaVM is unsuccessful'

In the above section of replica engine logs the important part is the error returned from hyper-v when we failed to start the replica VM, 'error code: 32768'.  After looking this error up online search results indicate 32768 for hyper-v means the VM is paused.  In this case we need to find out from hyper-v why its pausing the VM instead of booting it.

Because RHA isn't telling us clearly why it failed to bring the VM online we must now check the hyper-v logs to see if there is an indication why the VM won't boot.

On the replica hyper-v host open Windows event viewer from the admin tools menu.  In the left pane expand 'applications and services logs', then Microsoft, then Windows, then go down to the 'Hyper-v-Worker' and click on the admin log.

In the admin logs for hyper-v we found every time RHA did AR it received the errors 3030 and 12140.  We looked the errors up and found they mean the following:
3030 = Not enough resource… Memory or processor
12140 = The locale specific resource for the desired message is not present

Both of these errors indicate the VM couldn't come online because it didn't have the resources (ram or CPU) available. 
The master VM uses 28 gigs of ram, the physical replica hyper-v host has 32 gigs of ram and this VM is the only 1 on the replica.  When we first checked in task manager on the replica hyper-v host it showed 27.5 gigs 'free' from the 32.  This means the server is already in a state where it doesn't have enough ram to bring this VM online.  
We went into the hyper-v console on the replica and changed the VM to use 26 gigs of ram, it then booted just fine. 
Currently the hyper-v scenario does not let you configure the ram/cpu so AR will always want to bring the replica VM up with 28 gigs of ram.  In this case to make AR work again it would be necessary to either add ram to the replica or lower the amount of ram the master VM has assigned so RHA will bring the replica VM up with less ram. 
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request