iperf woes

Yesterday I blogged about iperf, CentOS and monit. Well, it turns out it was a bit early to report success. Even with monit, iperf is inherently unstable on CentOS. Monit's log shows this:

[CET Dec 21 11:26:14] error    : 'iperf' process with pid 20557 is a zombie
[CET Dec 21 11:26:14] error    : 'iperf' failed, cannot open a connection to INET[127.0.0.1:5001] via TCP
[CET Dec 21 11:26:14] info     : 'iperf' trying to restart
[CET Dec 21 11:26:14] info     : 'iperf' stop: /etc/init.d/iperfd
[CET Dec 21 11:26:44] error    : 'iperf' failed to stop
[CET Dec 21 11:27:44] error    : 'iperf' process with pid 20557 is a zombie
[CET Dec 21 11:27:44] error    : 'iperf' failed, cannot open a connection to INET[127.0.0.1:5001] via TCP
[CET Dec 21 11:27:44] info     : 'iperf' trying to restart
[CET Dec 21 11:27:44] info     : 'iperf' stop: /etc/init.d/iperfd
[CET Dec 21 11:28:14] error    : 'iperf' failed to stop
[CET Dec 21 11:29:14] error    : 'iperf' process with pid 20557 is a zombie

And ps shows iperf is defunct. This is obviously a bad situation. When I run iperf without -D parameter, it responds one time and then shuts down. But I couldn't get this behaviour to work with iperfd and monit properly. For the record, I used "iperf version 2.0.4 (7 Apr 2008) pthreads".

So in the end I resorted to use iperf on a Windows box and run it as a service. So far there have been no problems.

CentOS, iperf and monit

I'm quite fond of FAN and so I have several CentOS-based Nagios systems to check various things. I recently needed to check the available bandwith between two servers, so I decided to use check_bandwidth which is based on iperf. So far so good.
Because I need to rely on iperf to be running on both ends, I ended up using monit.

"Monit can start a process if it does not run, restart a process if it does not respond and stop a process if it uses too much resources."

Greg from the brain dive was kind enough to post the steps to set up iperf and monit on CentOS here. These steps almost led me to success, I had to do a few extra steps to make it work:

chmod +x /etc/init.d/iperfd
add "set daemon 60" to /etc/monit.conf

I found monit a bit weird to debug, because it doesn't write anything to it's logfile. So to find out why it's dying, I ran it in foreground with "monit -vI" which gives nice diagnostic output.

XenServer and Dell OMSA

As I have written before, there is a way to install ans use Dell OpenManage Server Administrator on vanilla Citrix XenServer. I have got it running on three production servers for five months now without issues. One is a R710, the others are PowerEdge 2950.


I've had to update the firmware of one RAID controller in order for it to work with OMSA. This was tricky, as there is no support for doing this in Linux. So I've had to use a Windows live CD, and upgrade the firmware from there. Worked like a charm.

XenServer and Dell OMSA - addendum

As I've written here it is indeed possible to install Dell OMSA on a XenServer 5.6 host without DDK. I've taken a brand new Dell R710 machine and decided to give it a go.
After I followed the instrcutions I encountered some weird issues though. The OMSA Webinterface was buggy, and only a few sensors were available.

For instance

# omreport chassis temps
Error! No temperature probes found on this system.

certainly didn't seem right. After some googling I thought I found the cuplrit in missing modules, namely dcdbas and dcdipm. I found only dcdbas was present, but not loaded:

# modprobe -l -v|grep dcd
/lib/modules/2.6.27.42-0.1.1.xs5.6.0.44.111158xen/kernel/drivers/firmware/dcdbas.ko

Loading it didn't help though. After more googling I found that openipmi is required, but isn't being installed during the OMSA install. So I installed it, restarted all omsa services and everything works fine:

# omreport chassis temps
Temperature Probes Information

------------------------------------
Main System Chassis Temperatures: Ok
------------------------------------

Index : 0
Status : Ok
Probe Name : System Board Ambient Temp
Reading : 28.0 C
Minimum Warning Threshold : 8.0 C
Maximum Warning Threshold : 42.0 C
Minimum Failure Threshold : 3.0 C
Maximum Failure Threshold : 47.0 C

XenServer and Dell OMSA

So Citrix has finally seen the light and is no longer supporting OEM'd versions of XenServer. If you have Dell servers however, you might want to monitor them using OpenManage. While Dell supports a host of Linux distributions, XenServer per se (which is a stripped-down CentOS) isn't directly supported. There were a few hackish guides floating around the interpipes, but I didn't want to risk them on a production system.

Now this guy has found out how to install OMSA on XenServer 5.6 and lo and behold, there is no black magic involved. I can't wait to verify his claims. Now I'm off backing up my XenServers though ;)

Xen 4.0 on Debian Squeeze

After having used Citrix XenServer for a while, I wanted to set up and test vanilla Xen for some time now. Finally an opportunity arose, so here are my findings.

• Installing Xen 4.0 is easy
  
• The debian-xen kernel is no good

Turns out that it's missing the netbk module, without which networking and xen virtual machines don't work. And virtual machines without network - let's face it - are about as interesting as washing your feet whilst wearing boots.

Oracle Forms 6i vs. Oracle 11gR2

Oracle Forms 6i is a well known application, and despite it no longer being supported, it shares a huge user base. Most applications are so vast that it's simply not feasible to ever upgrade them. Instead some are being gradually replaced while others just drag on.

While Oracle Forms 6i client is of course supported even on Windows 7 and Server 2008, it is unclear whether it will be play nice with future Oracle database releases.

As Oracle datase 11gR2 has been released on Windows platforms too, I considered upgrading our old RDBMS to 11gR2. Of course we use Oracle Forms 6i client/server, which is only certified for Oracle 10gR1.

To my surprise, Oracle Forms 6i is able to connect to 11gR2 using username/password. When using Native Windows Authentication however, the client just freezes for a few seconds, then quits. I tried all patches, and even patched Oracle RSF to 8.0.6.3 - but the problem remained. It seems to be a fundemalten problem as the client is unable to connect to a 11gR2 database as soon as the parameter sqlnet.authentication_services includes NTS.

With 11gR1 however, everything's fine in this regard.