NetXMS Support Forum

Are you upgrading via GUI, or via https://www.netxms.org/documentation/adminguide/upgrade.html#centralized-agent-upgrade ?
If it's GUI, can you record a video to see at what stage the installation is failing?

libvirt claims that it can connect to vcencter, not only particular ESXi servers.

Here's a video that seems to be explaining how this is done: https://www.youtube.com/watch?v=n3XJ0X1l9DU

libvirt is specified in dependencies of netxms-agent-vmgr, so will get installed automatically when you instal netxms-agent-vmgr package.

Currently there's a bug in the agent that first ssh request since agent start produced that.
You can track resolution of that issue here: https://track.radensolutions.com/issue/NX-1852

Yes, it's a bug. Created https://track.radensolutions.com/issue/NX-1854 for that.

This is error in a script of a Service Check object. 321 in the name of the script is the ID of that service check.
You'll find that service check, if you enter #321 into the filter in object tree. Check the script there.

Ok, can set DebugLevel=7 in agent configuration file and show an extract from agent log file when the SSH command is executed.

Also, you can use nxget command - it requests data from the agent, e.g.:
nxget 127.0.0.1 "SSH.Command(host,user,password,ls)"

The could be an issue that first SSH.Command since agent start is failing (https://track.radensolutions.com/issue/NX-1852), but is should start working when polled again.

Regarding the timestamps in the future - there are basically a few scenarios how that could happened:
- time has jumped on netxms server into the future and then back (so some values have recorded with future times during that time)
- more probably - time problem on some agent with cache mode = on
- not sure, but probably - time problem on netxms agent running in proxy mode
Monitoring time on all agents is advised.

For the links on the map - does the object with ID=842468 exist? (you can search for ID in object tree with # prefix, e.g. #842468)

We will add checking for this situation to nxdbmgr. You can track the progress in this issue: https://track.radensolutions.com/issue/NX-1851

libvirt is not well supported on Windows and only old version is available.
I'd advise to use a separate linux system with netxms agent and libvirt.

Absolutely, please check NetXMS docs on that: https://www.netxms.org/documentation/adminguide/ssh-monitoring.html
Make sure you add ssh.nsm subagent to the configuratio file of netxms agent running on your netxms server and restart the agent afterwards.

Just tried compiling 3.3.285 on a fresh Centos 8.1

I had to install the following dependencies:
yum install make gcc-c++ openssl-devel libcurl-devel libssh-devel pcre-devel libpq-devel


Have not figured out what package to install for mosquitto, so disabled it in confgiure:
./configure --with-server --with-pgsql --with-agent --disable-mqtt


Please check if you have all dependencies installed and try again.

If it's still in that condition, can you run this script to get thread statuses:
https://github.com/netxms/netxms/blob/master/tools/capture_netxmsd_threads.sh

Please run it twice with about 1 minute interval and attach the files it creates in /tmp.
The script requires gdb to be installed.

Not sure, if that approach would suit your situation, but here's an alternative

DCI object has attribute lastPollTime. That's the time stamp of last time that DCI got data. You can read this value in transformation script of your "primary" DCI. When delayed data would be coming to the server, this attribute will show correct timestamp of each incoming datapoint.

The idea is that you can configure your "secondary" DCIs as push DCIs. And implement the logic in the transformation script of the "primary" DCI.

E.g. if a new hour has started, you can calculate the average of the "primary" DCI and push it to the "secondary". Some more logic requred to do it only once - you can use a custom attribute and store last time there.