Hello Michael,

Thank you for your quick answer.

We just defined a new normalization that leads to a highest adapter ID of 4999 (with 999 LPARs in the Power System !!!).

So we are far away from 65536 which is the highest LPAR-ID admitted.

What do you think about that value and the impacts on PowerVM memory consumption ?

Thanks in advance

Best Regards

Pierre

My recommendation is to make all VIOS similar to other VIOS and all VIOC similar to other VIOC (i.e. partitions that are clients of the VIOS) as similar as possible.

Do not misunderstand me - a VIOS and a VIOC are very different, so they will be different. However, all the VIOS should have the same layout including virtual slot numbers for what they serve. And VIOC should all have the nearly the same output when using the lsconf command.

The concept of using a formula that used the partion ID number to determine a slot number was popular in 2005 and 2006 due to a white paper and a education exercise that used that "method" as a way to explain the different roles of VIOS and VIOC. Unfortunately, too many people thought that this is the best practice.

The basic problem is one you have already implied - the virtual slot numbers get very extreme - and surprisingly - this has adversely affected performance.

If you are using 10 VIOS I would first try to develop a model such that any VIOS looks the same logically to clients. It's functional difference would be it's physical adapters, e.g.. Unless you are configuring all VIOS to be physically equivalent - then you need a model where the logical layout clarifies what function they are performing.

The methaphor I like to use, especially for clients, is putting a PC together on an assembly line. The ethernet is always at the same location, hard drive is always at the same location - so that I can just examine any assembled PC and know just by looking at it if it is a standard PC, or something specialized.

In short, with massive virtualization - and it sounds like you are going that way - standardization is your friend.

If you care to share more about what your goals are, I may be able to be more specific. In any case, what you are proposing is no longer considered "best practice".

Hello,

We plan to install 5 dual-VIOS systems (10 VIOS in total) on our brand new P795 system.
At this time, we set the adapter ID by using the VIOS order number and Lpar-id (example VIOS No 1 & LPAR-ID 55 ==> VFC Adapter 155).

With the new configuration, this could lead to very high adapter ID's.

Has anybody an experience with such a configuration ?
Which normalization did you define ?

Thanks in advance

Pierre

We are very sorry for the total loss of sound and vision during our program
on the afternoon of June 9th - we hope it didn't spoil your enjoyment too much  

At first it appeared we were the subject of some sort of bot-launched DoS attack,
with access to other websites on this server being blocked out by all the rootvg
traffic load - so the plug was pulled while we investigated that.

Our automatic "blockip" process will have blocked IP addresses that continued
to attempt connections, and we have now also manually and permanently blocked
those addresses that were just racking up the timeouts in the logs previously.  

It seems now that it was some kind of issue with the forum software and browsers
where windows on this site had been left open - mostly "keepalive" traffic every
20 minutes from each of over a thousand IPs at the time. 

SO PLEASE CLOSE YOUR BROWSER WINDOW/TAB WHEN YOU'RE DONE !

Thanks! Looks like I have homework 

Well, firstly I should say that I did not plan to use exactly version 3.
I just wanted to be able to set some custom values ​​for the threshold values of some parameters for monitoring.
Therefore, the solution that was found does not use SNMP v3 in its pure form, just usage of compatibility with v1 and v2c which was provided in v3.
The entire setup procedure described here:
http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.commadmn%2Fdoc%2Fcommadmndita%2Fsnmpv1_daemon_config.htm

my snmpdv3.conf

and in the file aixmibd.conf I set the desired values ​​of certain parameters.
(agentAccess=1, pollInterval=5, etc)

That's all.

would be wonderful if you provided some extra details about how you got this working - without divulging any security sensitive information of course!

Will certainly help me better understand the new world of snmpv3! 

Certainly. Not only "can", but obliged inherently )))

Seems I found a way how to set desired thresholds values/send traps. Not exactly what I looked for, but close enough. Most parameters which I would like to track is controlled  via aixmibd subagent. After some minor changes of the files aixmibd.conf and snmpdv3.conf I was able to obtain alerts on the monitoring server side.

The snmpd daemon can send traps. For items not in the standard MIB-2 and/or standard traps normally a smux addition is used.
I do not know net-snmp (will google in a moment) so I cannot say how AIX is (dis)similiar, but I know AIX snmp does send traps.

Note: my experience is mainly on snmpv1 and snmpv2 - so a bit of research is needed. (For snmpv1 the file /etc/snmpd.conf explains 'trap' very well.

It looks as if 'trap' is renamed 'notify' in snmpv3. As a starting point for further research look at the files in /usr/samples/snmpdv3.

Hope this helps!

Hello.

Is there way to tune standard snmpdv3 daemon in AIX 6.1 to send traps on system events, just as it is implemented in a net-snmp.
Unfortunately neither the documentation nor the internet I could not to find definite answer.
The only thing that I realized there is several standard events (coldStart, warmStart, etc) on which traps generated.
But it is unclear what can I  do in case when  I need to keep track of value of arbitrary OID ( hrProcessorLoad for example)