News:

We really need your input in this questionnaire

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Anders

#1
Feature Requests / Re: Rack - Blade Centers
October 25, 2016, 11:23:11 PM
Hi,

Sorry for reviving this old post, but I sure would also like to see this feature implemented.
In my situation, we instead have a bunch of Supermicro Twin-servers which are 4x servers in 2U.

One way to maybe solve this issue could be to add an option to create a "Chassi" in the Object tree and then add the option to add Node(s) to a Chassi.
The Chassi should be able to be assigned to a Rack and specified how many rack-units in size it is.
In that way the Rack-picture would know how many Nodes are assigned to the chassi, its unit-size and rack-location and then the picture could be rendered based on that information.

I've attached a illustration of how a 10-node blade (with one faulty node) could be presented to the end user.

Regards,
// Anders
#2
Hi Tatjana,

Thanks but it really doesn't solve my problem. I was looking for a way to override the executing parameters in the init-script without having to modify the actual init-script, simply because the /etc/init.d/nxagentd gets overwritten each time you upgrade the agent software (considering I have about 80 machines, that creates allot of undesirable work each upgrade).

But I think I've found a working solution to my problem. The great people developing NetXMS has used the standard debian/ubuntu init-script which automatically loads and overrides init-script variables from: /etc/default/nxagentd... so basically if anyone else has the same needs as me, they can simply execute the following command to get an parameter override that doesn't get overwritten:

echo "DAEMON_ARGS=\"-d -c /etc/netxms/nxagentd.conf\"" > /etc/default/nxagentd

I suppose this means that my feature request has already been fulfilled :)
#3
Hi,

I most often monitor Ubuntu Linux installations and tend to keep my: nxagentd.conf configuration file, scripts etc. under the path: /etc/netxms. By default the init-file for the netxms-agent looks for the configuration file under: /etc/nxagentd.conf.

I'd like to have a default property file under: /etc/default/netxms-agent (or /etc/default/nxagentd) where I can override startup options without having to modify the original init-file (/etc/init.d/nxagentd), specially as it gets overwritten every time there is a new release of the agent.

Thanks for a fantastic product!

Anders
#4
General Support / Re: FreeIpmi integration
January 10, 2014, 09:24:31 AM
This would be a nice feature, most of our machines are IPMI-capable.
#5
Quote from: Alex Kirhenshtein on November 19, 2013, 04:10:40 PM
Could you please try this version: https://www.dropbox.com/s/wmwq997zlny55nk/nxmc-1.2.10.dmg?
This build is signed with proper keys from Apple, so it should work properly with Gatekeeper enabled.
Please note: it's built from from latest sources and incompatible with 1.2.9, so don't overwrite your existing app.

I can confirm that this version starts without any issues when the setting for "Allow apps downloaded from" is set to: "Mac App store and identified developers" under Security & Privacy.
#6
If you really need NetXMS Console version 1.2.9 a temporary solution could be to:

1. Download https://www.netxms.org/download/nxmc/nxmc-1.2.9-macosx-cocoa-x64.tar.gz and extract the tar-archive.
2. Open a Terminal and navigate to the extracted folder.
3. Make the "nxmc" program executable. chmod +x nxmc.app/Contents/MacOS/nxmc
4. It should now be possible to start the application.
#7
I have the exact same symptom as saa85 on my Mac.

I have tried it on a 10.8.5 and today with 10.9. Same problem.
#8
Hi,

I'd like to suggest that the nxpush command gets included in the netxms-agent deb-package, or made available in a optional netxms-util deb-package.

Currently the nxpush command doesn't seem to be included in neither netxms-agent, netxms-base or the netxms-server debs.

Regards

Anders
#9
General Support / Re: Monitor qemu-kvm processes
March 26, 2013, 09:14:06 AM
Hi mrugani,

This sounds more of an Qemu related question than NetXMS related, but I'll give it a try.

Are you using some sort of management wrapper such as: libvirt (virsh) or similar to manage your virtual machines? or are you using the native Qemu-monitor to migrate your virtual machines?
#10
General Support / Re: OSX Netxms Console 1.2.6
March 06, 2013, 12:40:21 AM
Works now, I've also been waiting for this :)
#11
General Support / Re: Ignore interface polling
March 06, 2013, 12:30:11 AM
Thanks, but isn't there a way to prevent NetXMS server to retrieve the interface list for newly added nodes?

My node for example has > 1000 interfaces named eth0, if I try to unmanage all of those, my interfaces freezes and it doesn't really solve my problem. I'd like to reducing the amount of interfaces under the node and if possible, just allow one main interface with the "default" ip-address.
#12
General Support / Ignore interface polling
March 04, 2013, 09:11:17 PM
Hi,

I have a Linux machine with *allot* of logical interfaces, it's probably > 1000. As you can imagen it often freezes the NetXMS Console UI and creates scenarios where the NetXMS Console crashes when trying to browse the node.

Is it possible to somehow limit the amount of polled interfaces?

Thanks in advance

Anders
#13
Hi,

Did this fix make it into 1.2.5?

Regards

Anders
#14
General Support / Re: Monitor qemu-kvm processes
January 04, 2013, 07:01:41 PM
Great news, thank you Victor! Does the Process.Count() work in a similar way?

Btw, what is the most up to date source for reference information for all supported attributes for a command such as: Process.Count() or Process.CPUTime() ? I haven't been able to find any related information in the wiki.
#15
General Support / Re: Custom Schedule query
January 04, 2013, 03:34:17 PM
I'd guess that the custom scheduler doesn't affect/work on the average PING-agent(?).

An alternative solution could be to write a filter script in the Event Processing Policy that only allows alarms between 9am and 5/6pm. Then you wouldn't lose the statistics.