This documentation refers to a previously released version of BMC Discovery.
See the information on this topic for the latest version (11.2) or version 11.1.

Before you start your upgrade process, make sure you review and perform the following tasks:

Before you begin

Before you upgrade, make sure that:

  • If you are upgrading from version 10.1.x, recreate the filters in the CMDB Sync filter tab after upgrade and before CMDB synchronization can be used.
    The upgrade includes significant changes to CMDB synchronization. Many existing filters will not longer be compatible with the new filtering system. For more information see, CMDB synchronization filters.
  • If you have made changes to OS configuration files on the appliance, you must verify and reapply the changes as required post-upgrade.
    The changes that you made might have been overwritten by the upgrade process.
  • You backup your database because the upgrade BMC Discovery process performs an upgrade of the database.
    You can restore the backup to an appliance by running the pre-upgrade version.
  • You create necessary relationships between nodes.
    The upgrade involves model changes. Therefore you must verify and create additional relationship between nodes as required post-upgrade. This task may take some time. The system writes messages to the tw_svc_reasoning.log, using the phrase analysis.connection_linker.

Upgrade archive naming conventions

To help you locate the necessary files, the upgrade archives for BMC Discovery use the following file naming conventions. Product upgrades from BMC Discovery version 10 and later use a .tgz file extension. Previous versions used a .sh.gz extension and required manual verification using checksums. The compressed OS upgrade archive retains the .sh.gz file extension.

  • For product upgrades later than 10.0:
    ADDM_Upgrade_Vn_nnnnnn_ga.tgz
    Where Vn is the BMC Discovery version number to which you are upgrading to and nnnnnn is the build number.  
  • For OS upgrades:
    ADDM_OS_Upgrade_64_6.yy.mm.dd_nnnnnn_ga.sh.gz
    Where yy.mm.dd is the date of the last package update from Red Hat and nnnnnn is the build number.

Upgrade considerations

  • When you run the upgrade, the timezone you have specified will be overwritten and returned to Europe/London unless you have updated the variable ZONE in /etc/sysconfig/clock. See Localizing the appliance for information on how to do this.
  • You can re-run the upgrade if it is terminated or fails. Destructive actions are recorded and are skipped on subsequent upgrade runs. Consequently when an upgrade is re-run, it is usually significantly quicker. You are unlikely to need to run the upgrade more than once, as it would only be required if an upgrade fails. See also the tw_run_upgrade command to re-run an upgrade.
  • The synchronization mechanism has changed in 10.2 and later, to reduce the amount of querying performed on the CMDB. As a result it will be necessary to resynchronize a connection that existed prior to the upgrade. See Resyncing a CMDB Connection for more information.
  • Where an upgrade makes changes to syncmapping files (see Default CDM Mapping and Syncmapping block), the initial CMDB syncs after upgrade might result in longer reconciliation times. Examples of such changes are key changes or attribute changes on a CMDB CI.
  • The location used by the upgrade for temporary files must be readable by the tideway user. The default location (which will be created if it does not exist) is /usr/tideway/tmp, and can be changed using the command line option --tmpdir.
  • Where SQL and JDBC credentials are in use, their existing properties files continue to be used and updated properties files are installed but not used. Where such credentials are unused, the old properties files are replaced with the latest.
  • In BMC Discovery 11.0, where an external CI with no kind is promoted to shared or contained is synchronized, its key is updated incorrectly. This has been fixed in 11.0.00.3. When upgrading from an earlier release of BMC Discovery version 11.0, you will see some churn in the CMDB as CIs with incorrect keys are deleted and replaced by CIs with correctly generated keys. This is most frequently seen for BMC_SoftwareServer CIs that are shared between other BMC_SoftwareServer CIs.
  • If you are a user with consolidating appliances,

     For users with consolidating appliances

    Version 9.x and 10.x scanning appliances can consolidate to version 11.0 consolidating appliances. However, version 11.0 scanners cannot consolidate to earlier consolidating appliances. Once you have upgraded your consolidating appliances, you can then upgrade scanning appliances as required. You must upgrade all your appliance eventually.

     

Approach to upgrading

When a system uses consolidation, BMC recommends the following approach in upgrading BMC Discovery:

  1. Stop discovery on scanning appliances.
  2. Ensure that all consolidation operations are complete.
  3. Stop discovery on consolidating appliances.
  4. Upgrade consolidating appliances.
  5. Restart discovery on the consolidating appliances.
  6. Upgrade scanning appliances as required.

  7. Restart discovery on the scanning appliances.

 

 

 

 

 

 

 

 

 

 

Was this page helpful? Yes No Submitting... Thank you
  • No labels

2 Comments

  1. For the OS upgrades seems to be either a typo in the documentation or the file name in EPD portal is wrong

    The downloaded file from EPD is called:

    o ADDM_OS_Upgrade_64_6.16.02.16_585356_ga.gz

    The described filename in docs is:

    o ADDM_OS_Upgrade_64_6.yy.mm.dd_nnnnnn_ga.sh.gz

    As you can see teh filename misses the extention of ".sh"

     

    On my system the prodes upgrade file was compleined. After remening the file 

    o from: ADDM_OS_Upgrade_64_6.16.02.16_585356_ga.gz

    o to:   ADDM_OS_Upgrade_64_6.16.02.16_585356_ga.sh.gz

    did resolve the issue.

    Now the question is, which side is wrong EPD or DOCS.

     

     

  2. I opened a ticket for the upgrade issue and also execute some test cases. Here I could configure out that the root cause is related to

    a) the method ADDM is checking both package files; only one is checked instead of two, and

    b) the Chrome browser is screwing up the file name to an unsupported format during the download.

    Therefore there is no need to change the documentation.


© Copyright 2017 BMC Software, Inc. © Copyright 2017 BladeLogic, Inc.

Legal notices

© Copyright 2017 BMC Software, Inc.
Legal notices