Video Screencast Help

Drives are showing in AVR control on media server

Created: 11 Oct 2012 • Updated: 17 Oct 2012 | 5 comments
This issue has been solved. See solution.

I have newly configured a media server. But drive are showing in AVR mode. We have other media servers in the environment they all are working good with ACS server.

Things i checked.

Robtes error:
  1)  ACS 0
  2)  none/quit
Enter choice: 1

Robot selected: ACS(0)   ACSLS host = singacsls-nb, SSI socket = 13741

Invoking robotic test utility:
/usr/openv/volmgr/bin/acstest -rn 0 -r singacsls-nb -s 13741

acs_response() failed
Unable to obtain Query Server acknowledge response, ACS status = 72, STATUS_PENDING
Robotic test utility /usr/openv/volmgr/bin/acstest
returned abnormal exit status (1).


acssel deamon log_error:

09-25-2012 12:26:02 SSI[0]:
[csi_rpccall.c:548] ONC RPC: csi_rpccall(): status:STATUS_NI_FAILURE; failed: clntudp_create()
RPC UDP client connection failed, RPC: Program not registered
Remote Internet address:, Port: 0;

acstest error:  No error returns.

     [40]> acstest -r singacsls-nb
SSI socket not specified... trying default (13741)


Below are primary and secondary(backup) network. of media server

    [41]> ifconfig
bond0     Link encap:Ethernet  HWaddr D0:67:E5:ED:E2:5B
          inet addr:  Bcast:  Mask:
          RX packets:3404743 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34051 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:678901632 (647.4 MiB)  TX bytes:21082053 (20.1 MiB)

bond1     Link encap:Ethernet  HWaddr D0:67:E5:ED:E2:61
          inet addr:  Bcast:  Mask:
          RX packets:1045 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22498 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:286396 (279.6 KiB)  TX bytes:1530838 (1.4 MiB)

***************************************tpconfig out put *********************************************

     [42]> tpconfig -d
Id  DriveName           Type   Residence
      Drive Path                                                       Status
0   sldrive0012          hcart2 ACS(0)  ACS=0, LSM=0, PANEL=1, DRIVE=2
      /dev/nst0                                                        UP
1   sldrive0315          hcart2 ACS(0)  ACS=0, LSM=3, PANEL=1, DRIVE=5
      /dev/nst4                                                        UP
2   sldrive0312          hcart2 ACS(0)  ACS=0, LSM=3, PANEL=1, DRIVE=2
      /dev/nst3                                                        UP
3   sldrive0013          hcart2 ACS(0)  ACS=0, LSM=0, PANEL=1, DRIVE=3
      /dev/nst2                                                        UP
4   sldrive0313          hcart2 ACS(0)  ACS=0, LSM=3, PANEL=1, DRIVE=3
      /dev/nst1                                                        UP

Currently defined robotics are:
  ACS(0)     ACSLS server = singacsls-nb

EMM Server = gnbm03-nb

***********************************************vmoprcmd ********************************

Drv Type   Control  User      Label  RecMID  ExtMID  Ready   Wr.Enbl.  ReqId
  0 hcart2   AVR                -                     No       -         0
  1 hcart2   AVR               Yes   SG1913  SG1913   Yes     Yes        0
  2 hcart2   AVR                -                     No       -         0
  3 hcart2   AVR                -                     No       -         0
  4 hcart2   AVR               Yes   SG2042  SG2042   Yes     Yes        0

                             ADDITIONAL DRIVE STATUS

Drv DriveName            Shared    Assigned        Comment
  0 sldrive0012           Yes      -
  1 sldrive0315           Yes      sgsinrlpbul04-n
  2 sldrive0312           Yes      -
  3 sldrive0013           Yes      -
  4 sldrive0313           Yes      sgsinrlpbul04-n

*********************************************services are up*********************************

MM Processes
root     14463     1  0 00:38 ?        00:00:00 vmd
root     14605     1  0 00:38 ?        00:00:00 acssel -s 13740
root     14609     1  0 00:38 ?        00:00:00 acsssi 13741
root     14889     1  0 01:48 ?        00:00:00 ltid
root     14895 14889  0 01:48 ?        00:00:00 acsd
root     14941 14889  0 01:48 ?        00:00:00 avrd
root     16805 16454  0 04:00 pts/7    00:00:00 acstest -r singacsls-nb
root     16813 14895  0 04:01 ?        00:00:00 acsd

Shared Symantec Processes
root      5368     1  0 Oct10 ?        00:00:00 /opt/VRTSpbx/bin/pbx_exchange

************************Media server red hat********************************************

Linux sgsinrlpbul9 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

Master server version is 7.0.1

Media server version is 6.5.6


     [50]> more vm.conf

Really appriciate if someone can help me on this.

Comments 5 CommentsJump to latest comment

Marianne's picture

You need another vm.conf entry:

ACS_SSI_HOSTNAME = sgsinrlpbul9-nb

Extract from :

The errors above indicate that NetBackup is able to reach the ACSLS server with a status request, but the ACSLS server is unable to respond.

By default, the IP address sent to the ACSLS as part of the packet STATUS request is that of the primary hostname of the media server, i.e. the hostname given by uname -a. This error occurs when the ACSLS cannot resolve reverse name or is configured (via routing) to only reach a secondary interface on the media server.
If the issue is failure to do reserve name lookup, add the media server's IP to the domain name service (DNS) reverse tables or to the ACSLS /etc/hosts file.
If the ACSLS server cannot route to the media server's hostname, override the default behavior by using "ACS_SSI_HOSTNAME = <hostname>" in the /usr/openv/volmgr/vm.conf file where the value for <hostname> is a hostname associated with an IP address the ACSLS can reach on the media server.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Manumohan's picture

Hi Marianne,

Thx for replying quickly..

i will give a try and come back..

Marianne's picture

Nothing like our own bad experiences.... 
The same issue turned a 4-hour migration into addtitional 3 hours of scratching, searching, trying everything under the sun... until we eventually found the above TN....

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Yasuhisa Ishikawa's picture


Please mark Marianne's post as a solution.

Authorized Symantec Consultant(ASC) Data Protection in Tokyo, Japan