Forum Discussion

Jason_Voyles's avatar
18 years ago

Vmglob -listall bug in Netbackup 6.0...

I need someone that has a similar configuration as us to run a command for testing something. I am tracing down an issue with Symantec Engineering pertaining to the 'vmglob -listall' command failing with 'unexpected data received (40)'. I think our issue may pertain to our configuration of the HA clustered master server with the two members having the same tape device configured on each node.

Does anyone out there have a configuration like this that you can test the 'vmglob -listall' command on? Thanks!

System Configuration:
Master server:
OS: 2 x Solaris 9 (patched).
Software: Netbackup Master server 6.0 MP3 COTS(common off the shelf) HA Clustered
Hardware: StorageTek tape silo with SAN attached fiber device (a single tape drive configured, same on each server). ACSLS Managed tape silo.

Media server:
OS: Solaris 9 (patched).
Software: Netbackup Media server 6.0 MP3
Hardware: Storage Tek tape silos with SAN fiber attached devices. ACSLS Managed.

2 Replies

Replies have been turned off for this discussion
  • I finally have an answer as to why our environments "vmglob -listall" command fails with an error code 40. It appears that there is an application bug that causes the vmglob command to fail when it tries to parse data from the EMM database.

    The command fails on is an string that is too long for it to parse. The failing character string is for the ACSLS "Serial number" filed. This bug does not knowingly affect the operation of NetBackup, however it does cause the vmglob -listall command to fail every time, until you remove the conflicting robot entry. The defined serial number is generally "ACS--" In our case it should be "ACS-0-hastring.na.xxxxx.com". The string is actually displayed in the EMM database data as "ACS-0-hastring.na.xxxxx.c" as it chops off the "om". The log that display the error are found in ../volmgr/debug/reqlib.log.

    15:08:56.000 <2> globdb_query: server returned: 0 ACS-0-hastring.na.xxxxx.c ROBOT0 icbsp master.na.xxxxx.com 0 -1 1 0 524288 *NULL* 0 *NULL* *NULL* *NULL* hastring.na.xxxxx.com -1 -1 -1 -1

    15:08:56.000 <2> string_to_globrecord: using server version: 45
    15:08:56.000 <16> string_to_globrecord: unexpected data received
    15:08:56.000 <16> string_to_globrecord: serial number = ACS-0-hastring.na.xxxxx.c
    15:08:56.000 <16> string_to_globrecord: dev name = ROBOT0
    15:08:56.000 <16> string_to_globrecord: host name = master
    15:08:56.000 <16> string_to_globrecord: vmdb host name = master.na.xxxxx.com
    15:08:56.000 <16> string_to_globrecord: wwid = *NULL*
    15:08:56.000 <16> string_to_globrecord: inquiry = *NULL*
    15:08:56.000 <16> string_to_globrecord: Library Name = *NULL*
    15:08:56.000 <16> string_to_globrecord: Vendor Drive Name = *NULL*
    15:08:56.000 <16> string_to_globrecord: robot control host = hastring.na.xxxxxx.com
    15:08:56.000 <16> get_glob_list: unable to list all globalDB entries: unexpected data received (40)

    The bug affects all ACSLS connected components with a FQDN hostname in the serial number field that is greater than 20 characters. It only affects NetBackup 6.0. I have only tested the bug under the MP3 code base. Netbackup Engineering Tier 4 "back line support" is now working to resolve the issue. I will update you once it has been resolved. Thanks.