Introduction
The machine where Altair Monitor (formerly Runtime LicenseMonitor) runs is initially determined by where the 'lmmgr start' command was run, and the owner is the account that first ran the command.
This article discusses some of the information that you will need to gather to guide you, and how to make the change. (We may also refer to the system as LM for brevity).
Reconnaissance -- some info you will need, and why:
- Where is the VOV software installed -- fileserver or local disk?
If the software is installed on a fileserver, you can just mount it on the new machine. If the software is installed locally, you will need to copy or reinstall it. If you are using the SFD (Single-File Distributable), you will need the platform-specific one for the new host.
- Where is the Monitor configuration directory (.swd) located?
If it is on a local disk, you will need to copy it to the new machine. This directory is critical, because it contains your LM configuration, and all the primary data, in the form of the .chk, .den and other files.
- What are the database host, database path, and database port number?
If the database is on the local disk, you will need to copy the data directory to the new host. If it is on a separate host, the DB connection parameters can probably stay the same.
- What is the current LM owner account?
The LM owner account will need to be available on the new machine, either in the local files or through network name services.
- What is the current VOV version running Monitor? Any patches?
What are the LM host name, LM port number(s)?
Monitor can use up to three ports, the web-port, VOV-port, and if in use, a read-only port. You will need to be sure they are not in use on the new machine for other services.
- Is your Monitor instance using SSL?
If your instance is using SSL, you will need to re-generate a certificate for the new machine.
- If using SSL, using a CA certificate, or self-generated/signed?
If using a CA certificate, you may need to acquire a new one, depending on whether it is a wildcard cert that will also cover the new machine name.
- What is the license type: keyfile, RLM, RLM-single, number of users?
If your LM is using a node-locked form of licensing, you will need the license re-hosted to the ID of the new machine. If the license is RLM, you may not need a new one, if the current RLM license server machine will stay in service.
- What is the database Postgres version? Have you saved the DB password props?
The LM system uses three database roles: rtdausr, rtdamgr, and rtdasu. The passwords for these are stored as properties on object 1 in the vovserver. It is possible, but laborious, to set new ones, so it is wise to back these up to an alternate location. See below for how to do this.
- Have you saved 2016.09->2019.01 PR if you might need to revert?
The PR (persistent representation) file that stores the state of vovserver across shutdowns has added entries in 2019.01, that can not be read by 2016.09. If moving between these two versions, we recommend saving the PR file in case you need to revert.
- Where is the VOV software installed -- fileserver or local disk?
If the software is installed on a fileserver, you can just mount it on the new machine. If the software is installed locally, you will need to copy or reinstall it. If you are using the SFD (Single-File Distributable), you will need the platform-specific one for the new host.
- Where is the Monitor configuration directory (.swd) located?
If it is on a local disk, you will need to copy it to the new machine. This directory is critical, because it contains your LM configuration, and all the primary data, in the form of the .chk, .den, and other files.
- What are the database host, database path, and database port number?
If the database is on the local disk, you will need to copy the data directory to the new host. If it is on a separate host, the DB connection parameters can probably stay the same.
- What is the current LM owner account?
The LM owner account will need to be available on the new machine, either in the local files or through network name services.
- What is the current VOV version running Monitor? Any patches?
- What are the LM host name, LM port number(s)?
Monitor can use up to three ports, the web-port, VOV-port, and if in use, a read-only port. You will need to be sure they are not in use on the new machine for other services.
- Is your Monitor instance using SSL?
If your instance is using SSL, you will need to re-generate a certificate for the new machine.
- If using SSL, using a CA certificate, or self-generated/signed?
If using a CA certificate, you may need to acquire a new one, depending on whether it is a wildcard cert that will also cover the new machine name.
- What is the license type: keyfile, RLM, RLM-single, number of users?
If your LM is using a node-locked form of licensing, you will need the license re-hosted to the ID of the new machine. If the license is RLM, you may not need a new one, if the current RLM license server machine will stay in service.
- What is the database Postgres version?
- Have you saved the DB password props?
The LM system uses three database roles: rtdausr, rtdamgr, and rtdasu. The passwords for these are stored as properties on object 1 in the vovserver. It is possible, but laborious, to set new ones, so it is wise to back these up to an alternate location. See below for how to do this.
- Have you saved 2016.09->2019.01 PR if you might need to revert?
The PR (persistent representation) file that stores the state of vovserver across shutdowns has added entries in 2019.01, that can not be read by 2016.09. If moving between these two versions, we recommend saving the PR file in case you need to revert.
Proposed Change or Upgrade
- What will be the new VOV version?
- Same host/port/SSL?
- Same DB host and parameters?
- Same owner?
Making the Move
In the following command sequences, use the name of your LM project, if other than the default 'licmon'.
+ Back up the DB passwords:
% vovproject enable licmon
% cd `vovserverdir -p db`
% vovprop list 1 | grep SQL_ > dbcred.txt
% cat dbcred.txt (verify contents look OK)
% chmod go-rwx dbcred.txt (protect against snooping)
+ Save a recent PR file for LM running on 2016.09
+ get shell on LM host as LM owner with Altair cmds in the PATH
% vovproject enable licmon
% cd `vovserverdir -p trace.db`
% mkdir savepr201609
% cp -p pr.gz savepr201609/pr.gz
Case 1: All of LM on a single source machine
Prepare the destination machine and have it online on your network.
- Copy from the source machine, or install the version of Altair software to be used on the destination machine. Download from https://aap-files.pbsworks.com.
The default location for the .swd and the DB directory are inside the Altair installation hierarchy, at:
.../path-to-Altair/licmon/licmon.swd
.../path-to-Altair/
- Copy the 'licmon.swd' directory from the source to destination, e.g. using tar or rsync.
You can do the bulk of this while LM is live, then do a final update with rsync after shutting down LM.
- Copy the database directory.
Depending on your data size and network speed, this could take some time.
Copying the DB may also be done while LM is live, but unchecking the 'Enable Data Loader' item on the Admin->Database page in LM so that the DB files are not being constantly updated by new info.
- Shut down LM using 'lmmgr stop', then make a final rsync of the licmon.swd and database directories.
- Update the registry entry $VOVDIR/local/registry/<lm_owner>/licmon@old-host by editing the host name inside the file, and then renaming the file by replacing <old-host> with <new-host>.
- Get a shell on the new machine as the LM owner, and source the setup file to get Altair commands in the PATH
- Use 'vovproject list -l' and verify that the LM project shows the new host and correct new path to the licmon.swd directory.
- Start LM on the new host using 'lmmgr start'.
- Enable your LM project in your shell, and check that it is OK by 'vsi'.
- Check the database setup: 'vovdb_util showcfg'.
- If the config looks correct, start the DB by 'vovdb_util startdb -v'.