The doubt about the OPR status under the vmoprcmd devmon output

OPR means that the drive is in "operator" control. You can load and unload tapes by hand.
If the drive is a standalone drive, it is the correct status
If the drive is part of a library, then there is a problem with the library or with netbackup configuration.

You can start a drive with OPR mode, if you want to use this drive manually, whatever the reason

Set the drive down, and then up ... it should come out of OPR mode.

AVR is different - if a drive is standalone / not in a robot it should be in AVR mode.

If a drive is robotic, it should be in TLD or ACS mode, depending on the robot type.  If a TLD drive goes to AVR mode, and, that drive is on the robot control host then it's almost certain that the connection to the library has been lost, any other drives in that robot will also show as AVR.  Any shared drives on 'remote' media servers will also show AVR.

If a shared drive on a media server, where the media server is NOT the robot control hosts goes to AVR, but the same drives are still TLD on the robot control host itself, then there is a comms issue between the remote media server and the RCH - specifically, tldcd on the remote media cannot communicate with tldcd on the RCH.

ACS is a bit different, as there is no robot control host, instead each media server communicates to the acs server which is 3rd party (Oracle), and takes the place of a robot control host.  Here, if drives that were ACS goto AVR, then communication has been lost to the ACS server and multiple media servers may or may not be affected depending on the cause.

There are other reasons robotic drives can goto AVR mode, but the the above is by far the most common.

Could it be more details for such scenario with some problematic TL or wrong configuration .... ？

1) Does it mean that there is no other way to reset the OPR status from the NBU layer ？
2) What is the difference between the OPR and AVR status under the robotic controlled ？

It is a bit strange that neither restart the ltid nor directly up the TD can eliminate the OPR status.
Or maybe it should firstly down the OPR TD ... ？

The most pivotal problem is why sometimes one TD under the same good robotic control would inexplicably become OPR status.
In other words, what the trigger condition should be,  so that the ltid process would automatically put the TD status into OPR ... ？

Not always the same ...

Here is the complete volmgr debug logs for this OPR issue....
But it seems that there is almost no any significant information ...

18:02:26.313 [32708] <2> vnet_same_host_and_update: [vnet_addrinfo.c:3021] Comparing name1:[jcbak] name2:[jcbak]
18:02:26.313 [32708] <4> get_emm_server_info: EMM server = jcbak; EMM port = 1556
18:02:26.335 [32708] <2> get_master_server_name: Master server name = jcbak
18:02:46.610 [471] <4> vmoprcmd: INITIATING
18:02:46.636 [471] <2> vmoprcmd: argv[0] = vmoprcmd
18:02:46.636 [471] <2> vmoprcmd: argv[1] = -h
18:02:46.636 [471] <2> vmoprcmd: argv[2] = jcsjdb3
18:02:46.636 [471] <2> vmoprcmd: argv[3] = -up
18:02:46.636 [471] <2> vmoprcmd: argv[4] = 9
18:02:46.636 [471] <2> vmdb_start_oprd: received request to start oprd, nosig = yes
18:02:46.636 [471] <2> vnet_same_host_and_update: [vnet_addrinfo.c:3021] Comparing name1:[jcsjdb3] name2:[localhost]
18:02:46.637 [471] <2> vnet_sortaddrs: [vnet_addrinfo.c:4170] sorted addrs: 1 0x1

OK, I think the best way forward on this, now the logs are in place is to set a cronjob that runs vmoprcmd to a file every 30 mins. eg vmoprcmd >/tmp/vm_out_$(date '+%Y-%m-%d_%H:%M').txt

Then, when you notice a drive in OPR, you can see within 30 mins when this changed, and thus get the relevant log file, and the vmoprcmd output file + the one before the change.

I ran a quick test today, and looking on a VTL when I set the drive manually to OPR, no scsi commands were sent that I could see, so it's totally a NetBackup 'thing', not hardware (I think).

Surely,  it must be a logical status of TDs only in the NBU layer !

BTW,  no any significant information from my above attachment of the voldbg logs ...... ?