Comments
-
Hi, are those volumes created but just not assigned to any pool? Asking as we have this fixed recetnly. Do you see volume graphs? Do you see other graphs like pools etc?
-
exactly 6.3 is that border where it does not work. No way, sorry. We do not want to invest our time into support of such old stuff.
-
It looks like old firmware level, 6.x. We do not support it.
-
Hi, it is ok, more has not been implemented in that version. More coming soon in 5.00 http://www.lpar2rrd.com/note500.htm?4.6.20 you can see it already on the demo site: http://demo.lpar2rrd.com/?menu=97e27dd&tab=0
-
place 5 in this line at the end in etc/storage-list.cfg dvp500001:SWIZ:dvp500001::::5
-
Hi, this output: cd /home/stor2rrd/stor2rrd grep ":SWIZ:" etc/storage-list.cfg grep SAMPLE etc/stor2rrd.cfg
-
I understand what your team wants, but I am still not convinced if such trend helps them anyhow. Well, let us check how complicated it would be, when it is quite easy (what I am think) then we will go for it even in coming 5.00. We will see if we manage it as a lot of work actually around before the release. I will let you…
-
it would not be hard but it does not make sense fo me. trending MAX might be a lot misleading as one even short (1min) peak during the day can affect trend a lot.
-
no, only 5 minutes is supported for VNX. It is fixed, no matter what you set up in config files. http://www.stor2rrd.com/sample_rate.htm?1.4.16
-
yes, it is like that: HUS-VM-alias01:VSPG:10.xx.xx.xx:lpar2rrd:xxxxx:/etc/horcm2.conf:1024:10:5
-
it is wrong. You have assigned naviseccli user credentials under root, but you have to do it under lpar2rrd. This one will not work: su - lpar2rrd /opt/Navisphere/bin/naviseccli -h 192.168.1.2 getsptime As fix repeat this under lpar2rrd (from manual): $ /opt/Navisphere/bin/naviseccli -addusersecurity -scope 1 -password…
-
ok, this is not posible now. It will be in new 5.00. It is already implemented there.
-
yes, there is general paging rule for that in etc/alert.cfg #SWAP:server:lpar name:swapping in kB/sec::peek time in min:alert repeat time in min:email group #======================================================================================================================== SWAP:.*:.*:10:::support@lpar2rrd.com Anyway…
-
it should work, try to repeat the procedure, looks like wrong key you have pasted ls -l ~/.ssh/id_rsa.pub scp ~/.ssh/id_rsa.pub superuser@<storage IP>:/tmp/123tmp ssh superuser@<storage IP> "svctask chuser -keyfile /tmp/123tmp lpar2rrd" ssh lpar2rrd@<storage IP> "lscurrentuser"
-
have you copied even the private key? you have to copy over whole .ssh directory and keep file rights (lpar2rrd owner and 600 for most of files include .ssh dir)
-
Hi, cmd is wrong, in the manual is only general example, use it like that (replace IP with your hostanme/IP) scp ~/.ssh/id_rsa.pub superuser@10.1.0.25:/tmp/123
-
Hi, no, use the one you have already generated.
-
Hi, I do not uderstand the question. If there is a limit per jobs in a subsystem then it has nothing with threads. Each job can create as many threads as it needs. We do not have metric "jobs per subsystems".
-
I do not think that it is about data, I think that only presentation might be wrong. Has taht happen for all tren graphs? try to upgrade to the latest rrdtool version
-
basically this is something what does rrdtool directly, it is not about us. I do not see such problem in our env with rrdtool 1.4.7 http://demo.lpar2rrd.com/?menu=5b013b3&tab=0
-
/var/tmp is not really necessary but it could be included. There is just a timestaps for already collected nmon data. If it is not there it will be recreated.
-
what is your rrdtool version? rrdtool -v
-
for application of changes is necessary to force web refresh ./load.sh html Ctrl-F5 in the GUI If nothing then this info 1. product version 2. cd /home/stor2rrd/stor2rrd grep WIN1_B tmp/menu.txt
-
How do you have set "Include graphs" parameter in alerting options? http://demo.stor2rrd.com/?menu=f7b60b4&tab=2
-
little bug, it does not have to generate an email alert every time. It is already fixed in coming release 1.40
-
sticky bit on fcstat might remove some OS upgrade/patching. We have already experienced several times.
-
rpm -qa| grep lpar2rrd is the agetn runing under root or lpar2rrd (or any other user) If it is not under root then su - <lpar2rrd user> fcstat fcs0 | grep Bytes
-
Are there fcs adapters? Is that AIX? lsdev -C | grep fcs fcstat fcs0| grep Bytes
-
Hi, this info from the agent side: tail -1 /var/tmp/lpar2rrd*txt tail /var/tmp/lpare2rrd*err
-
Hi, this is a bug fixed in 1.35-1 version. Upgrade to that (it is the latest version available), it will fix it definitelly.
Howdy, Stranger!