## Introduction

This document describes the steps required to migrate an existing Opsview Monitor 5.4.2 Virtual Appliance (VA) system to Opsview Monitor 6.3.x VA.

Existing Opsview 5.4 slaves will be re-purposed to be Opsview 6.3 collectors.

We will be using Opsview Deploy to setup and configure the new environment.

New, randomly generated credentials will be used on the new system. However, the security wallet key will be migrated so existing secure data will be used.

Through the process described here, the Opsview 5.4.2 slaves will be upgraded into 6.3 Collectors. The upgraded Collectors will no longer be able to communicate with the old 5.4.2 master. If you would like to have the two systems running in parallel, please provision new servers for the purpose of acting as the new collectors.

### Limitations

• Databases must use the default names, ie: opsview, runtime, odw, dashboard.

## Summary of Process

• Pre-migration validation - to check for known issues that can impact the migration

• Deploy new 6.3.x VA system

• Move opsview_core_secure_wallet_key_hash: 'KEY' from old server to new server

• Migrate data from old database to new database server

• Migrate data from old timeseries server (InfluxDB or RRD) to new timeseries server

• Convert old slaves to new collectors

• Apply changes and start monitoring in 6.3!

• Other migration tasks

In this document, we will use the following hostnames:

There will be an outage to monitoring while this migration is in progress.

## Summary of Differences

The main differences are:

• Opsview Deploy will be used to manage the entire, distributed Opsview system

• The file system location has changed from `/usr/local/nagios` and `/usr/local/opsview-web` to `/opt/opsview/coreutils` and `/opt/opsview/webapp` respectively

• All files are owned by root, readable by opsview user and run as opsview user

• Slaves will become Collectors

• New, randomly generated credentials will be used for database connections + the authtkt

## Prerequisites

### Activation Key

Ensure you have an activation key for your new system - contact Opsview Support if you have any issues.

### Hardware

As existing 5.4 slaves will be converted to be 6.3 collectors, ensure they meet minimum hardware specs for collectors.

Check [Hardware Requirements - needs review](🔗) when sizing your new Opsview 6.3 Collectors

### Opsview Deploy

### Network Connectivity

Due to the new architecture, different network ports will be required from Orchestrator to Collectors. Ensure these are setup before continuing as documented on [Managing Collector Servers](🔗).

During this process, you will need the following network connectivity:

Please read the [List of Ports](🔗) used by Opsview Monitor.

### SNMP Configuration

As 5.4 slaves will be converted to 6.3 collectors and SNMP configuration will be managed by Opsview Deploy, backup your existing SNMP configuration so that you can refer back to it. See SNMP Configuration further down this page for the list of files to backup.

## Pre-Migration Validation

Opsview Monitor makes an assumption about which host within the database is the Master server. To confirm all is okay before you begin the migration, run the following command as the `nagios` user on `oldmasterserver`

You should get back output similar to the following:

If you get no output then please contact [Support](🔗) for assistance.

## Disable the 5.x repositories

To prevent a conflict with older versions of packages, please ensure you have disabled or removed all Opsview repository configuration for version 5.x before starting the 6.3 installation.

On Ubuntu and Debian, check for lines containing `downloads.opsview.com` in `/etc/apt/sources.list` and each file in `/etc/apt/sources.list.d`, and comment them out or remove the file. On Centos, RHEL and OEL, check for sections containing `downloads.opsview.com` in all files in `/etc/yum.repos.d`, and set `enabled = 0` or remove the file.

## Deploy New Opsview 6.3

On `newmasterserver`, follow instructions for configuring a new 6.3 system as per [Virtual Appliance](🔗).

On the `newmasterserver`, to keep your encrypted data from oldmasterserver, edit file `/opt/opsview/deploy/etc/user_secrets.yml` add the following line. (Replace KEY with the contents of `/usr/local/nagios/etc/sw.key` from `oldmasterserver`. (**NOTE**: The "_hash" is important!))

As root on `newmasterserver`, stop all services.

Remove existing security wallets keys

For the following files on `oldmasterserver`, copy across any configuration into Opsview Deploy on `newmasterserver` so your system can be setup similarly:

Any changes made to `/usr/local/opsview-web/opsview_web_local.yml` must be put into the deploy configuration files. For example, to set up LDAP or AD integration, see the [LDAP configuration](🔗) page.

On the `newmasterserver` edit file `/opt/opsview/deploy/etc/user_vars-appliance.yml` Within this file add the following lines. Change the purchased modules you have currently installed on your oldmasterserver from False to True.

On the `newmasterserver` run the following command to drop the Opsview databases

The following command should be run on the `newmasterserver`, this will remove some of the existing Opsview packages (ignore any warnings).

Now run the following commands (each command should complete `successful` before moving onto the next)

Start each process and confirm they all start

## Migrate Existing Database to New Database Server

As the `root` user on `oldmasterserver`:

Wait till all processes are "Not monitored".

Then, take a backup of all your databases on `oldmasterserver`, make sure to include any extra databases you may have (for example, include jasperserver if it exists). This will create a full database export.(update PASSWORD based on the mysql root user's password):

**Note:** Backing up the system can take some time, depending on the size of your databases.

On `oldmasterserver`, copy over the database dump to the newmasterserve using such tools as scp, ie

Then on `newmasterserver`, run as the root user:

On `newmasterserver`, run as the `root` user:

On `newmasterserver`, run as the `opsview` user:

Within the Opsview UI you should now see all of your hosts from your oldmasterserver.

## Migrate Timeseries Data to New Timeseries Server

The next instructions depend on which technology your current Timeseries Server is based on, either InfluxDB or RRD.

### RRD Based Graphing Data

If you use RRD, transfer the `/usr/local/nagios/installer/rrd_converter` script to `/tmp` on the `oldmasterserver`, then as root, run:

This will produce a rrd_converter.tar.gz file in /tmp.

To transfer this file to the newmasterserver, run the following (after updating USER and `newmasterserver` appropriately):

Then on `newmasterserver` as root, run:

### InfluxDB Based Graphing Data

If you use InfluxDB, on `oldmasterserver` as `root`, run the following commands to backup InfluxDB data:

Then run the following (after updating USER and `newmasterserver` appropriately):

On `newmasterserver` as `root`, stop all timeseries daemons:

Then on `newmasterserver`, you need to install InfluxDB. Follow instructions at https://docs.influxdata.com/influxdb/v1.7/introduction/installation/. InfluxDB should be running at the end of this.

Import the new data:

Note: If you get a message about skipping the "_internal" database, this is normal and can be ignored, e.g.:

Finally, restart timeseries daemons:

If you do not have any collectors in your system for this migration then after the below Opspack step, you may now start Opsview

### Install Newer Opspacks

New, non-conflicting Opspacks will be installed as part of an Opsview installation. If you want to use the latest 6.3 configuration, the command below will force the Opspacks to be installed.

On `newmasterserver` as `opsview` user, run:

## Convert Old Slaves to New Collectors

On `newmasterserver` as `root`, update the opsview_deploy.yml file with the new collectors. For example:

Then run opsview-deploy to setup these collectors:

After this, your Opsview 5.4 Slaves will be converted to 6.3 Collectors and will be automatically added in the system and listed in the Unregistered Collectors grid.

To assign the collectors to a cluster, in the web user interface, go to `Configuration > System > Monitoring Collectors` to view the collectors:

You can then register them to the existing clusters:

You may need to remove your previous hosts defined in Opsview that were your old slaves.

### Temporarily Turn Off Notifications

There will likely be some configuration changes that need to be made to get all of the migrated service checks working, so notifications should be silenced temporarily to avoid spamming all your users.

In the web user interface, go to `Configuration > My System > Options` and set `Notifications` to `Disabled`.

## Apply Changes and Start Monitoring

In the web user interface, go to `Configuration > System > Apply Changes`.

This will start monitoring with the migrated configuration database.

## Other Data to Copy

### Environmental Modifications

If your Opsview 5 master server has any special setup for monitoring, these will need to be setup on your new collectors. This could include things like:

• dependency libraries required for monitoring (eg: Oracle client libraries, VMware SDK)

• ssh keys used by check_by_ssh to remote hosts

• firewall configurations to allow master or slave to connect to remote hosts

• locally installed plugins that are not shipped in the product (see below for more details)

### Opsview Web UI - Dashboard Process Maps

If you have any Dashboard Process Maps, these need to be transferred and moved to the new location.

On `oldmasterserver` as the nagios user:

On `newmasterserver` as the opsview user:

Test by checking the process maps in dashboard are loaded correctly.

(NOTE: If you have seen a broken image before transferring the files over, it may be cached by the browser. You may need to clear browser cache and reload the page.)

### Opsview Web UI - Host Template Icons

If you have any Host Template icons, used by BSM components, these need to be transferred and moved to the new location.

On `oldmasterserver` as the nagios user:

On `newmasterserver` as the opsview user:

Test by checking the Host Templates list page, BSM View or BSM dashlets

### Opsview Autodiscovery Log Files

If you have historical Autodiscovery log files that you wish to retain, these need to be transferred and moved to the new location.

On `oldmasterserver` as the nagios user:

On `newmasterserver` as the opsview user:

### RSS/Atom Files

If you use the RSS Notification Method and want to retain the existing notifications, you will need to transfer them and move to the right location.

On `oldmasterserver` as the nagios user:

On `newserver` as the opsview user:

### Opsview Monitoring Plugins

Any custom plugins, event handlers or notification scripts will need to be transferred and moved to the new location:

You can use [this script](🔗) to check that all plugins, event handlers and notification scripts recorded in the database exist in the right place on the filesystem.

### LDAP Syncing

If you use opsview_sync_ldap, copy from `oldmasterserver` the file `/usr/local/nagios/etc/ldap` to `newmasterserver` at `/opt/opsview/coreutils/etc/ldap`. Ensure files are owned by opsview user.

### Opsview Configuration Database

We do not change your Opsview master configuration because you may have custom configuration changes. However, the old Opsview 5.X Host Templates are no longer relevant for Opsview 6.3, so you will need to manually remove the following Host Templates:

• Application - Opsview BSM

• Application - Opsview Common

• Application - Opsview Master

• Application - Opsview NetFlow Common

• Application - Opsview NetFlow Master

You will need to add the following Host Templates manually to the the hosts where those Opsview Components have been added (usually the Orchestrator server):

• Opsview - Component - Agent

• Opsview - Component - Autodiscovery Manager

• Opsview - Component - BSM

• Opsview - Component - DataStore

• Opsview - Component - Downtime Manager

• Opsview - Component - Executor

• Opsview - Component - Flow Collector

• Opsview - Component - Freshness Checker

• Opsview - Component - License Manager

• Opsview - Component - Load Balancer

• Opsview - Component - Machine Stats

• Opsview - Component - MessageQueue

• Opsview - Component - Notification Center

• Opsview - Component - Orchestrator

• Opsview - Component - Registry

• Opsview - Component - Results Dispatcher

• Opsview - Component - Results Flow

• Opsview - Component - Results Forwarder

• Opsview - Component - Results Live

• Opsview - Component - Results Performance

• Opsview - Component - Results Recent

• Opsview - Component - Results Sender

• Opsview - Component - Results SNMP

• Opsview - Component - Scheduler

• Opsview - Component - SNMP Traps

• Opsview - Component - SNMP Traps Collector

• Opsview - Component - SSH Tunnels

• Opsview - Component - State Changes

• Opsview - Component - TimeSeries

• Opsview - Component - TimeSeries Enqueuer

• Opsview - Component - Timeseries InfluxDB

• Opsview - Component - TimeSeries RRD

• Opsview - Component - Watchdog

• Opsview - Component - Web

### NetAudit

On `oldmasterserver` as the opsview user:

On `newmasterserver` as the opsview user:

Test by looking at the history of the NetAudit hosts.

Test when a change is made on the router.

### Reporting Module

On `newmasterserver` as root user, stop Reporting Module:

On `oldmasterserver`, take a backup of your jasperserver database and transfer to `newmasterserver` server:

On `newmasterserver`, restore the database:

On `newmasterserver` as root user, run the upgrade and start the Reporting Module:

In the Reporting Module UI, you will need to reconfigure the ODW datasource connection, as it should now point to `newmasterserver`.

Test with a few reports.

### Network Analyzer

For each Flow Collector in 5.4 (which can be the master or any slave nodes), you will need to copy the historical data. Instructions below for the master, but similar steps will need to be done for each old slave/new collector.

For the master, on `oldmasterserver` as `root` user, run:

On `newmasterserver` as `root` user, run:

Network devices will need to be reconfigured to send their Flow data to the new master and/or collectors.

### Service Desk Connector

Due to path and user changes, will need to manually configure service desk configurations. See [Service Desk Connector](🔗) documentation.

### SMS Module

This is not supported out of the box in this version of the product. Please contact the [Opsview Customer Success Team](🔗).

### SNMP Trap MIBS

If you have any specific MIBs for translating incoming SNMP Traps, these need to exist in the new location for every snmptrapscollector in each cluster that is monitoring incoming traps. Note that in distributed system this will be on every collector and the new master. For the collectors this will happen automatically as part of the stage "Convert Old Slaves to New Collectors", however for the master a manual step will be needed if you want to monitor incoming traps from hosts residing in the Master Monitoring cluster.

On `oldmasterserver` as the `nagios` user:

On `newmasterserver` as the `opsview` user:

Test by sending a trap to the master from a host that it is in its cluster and check that it arrives as a result for the host in the Navigator screen. You can also add the "SNMP Trap - Alert on any trap" service check to the host if it has not got any trap handlers. With the service check added to the host, you can use SNMP Tracing to capture and read any trap that is getting sent from that host.

### SNMP Polling MIBS

If you have any specific MIBs for translating OIDs for check_snmp plugin executions, these need to exist in the /usr/share/snmp/mibs/ or /usr/share/mibs/ location for the orchestrator to use in the newmasterserver. All OIDs specified in opsview of the form of "<MIB module>::<OID Value>" need to get translated during an opsview reload into their number form using the standard MIBs in /usr/share/snmp/mibs and /usr/share/mibs to translate them. You should ensure that all your MIBs are transferred from the old folders to the newmasterserver.

On `oldmasterserver` as the `root` user:

On `newmasterserver` as the `root` user:

### SNMP Configuration

Ansible will setup default configuration for SNMP on the newmasterserver and all collectors. It overwrites the following files:

• /etc/default/snmpd #[Debi,Ubun]

• /etc/snmp/snmpd.conf #[Debi,Ubun]

• /etc/snmp/snmptrapd.conf #[Debi,Ubun]

• /etc/sysconfig/snmpd #[Cent,Rhel]

• /etc/sysconfig/snmptrapd #[Cent,Rhel]

• /etc/snmp/snmpd.conf #[Cent,Rhel]

Edit these files and merge any custom changes you need for your environment.

NOTE: As these files are managed by Opsview Deploy, they will be overwritten the next time `opsview-deploy` is run, so you will need to merge any changes back in again.