Monthly Archives: March 2013

HP MicroServer + RAC on Fedora 18

After upgrading my HP MicroServer with Remote Access Card from Fedora 17 to Fedora 18 (kernel-3.8.3-203.fc18) the RAC KVM console (remote and VGA) stopped to work with ‘out-of-range’ signal after:

[ 4.072580] [drm] Initialized drm 1.1.0 20060810
[ 4.104362] [drm] AST 1100 detected
[ 4.104500] [drm] dram 816000000 1 16 04000000
[ 4.104785] [TTM] Zone kernel: Available graphics memory: 2024944 kiB
[ 4.104913] [TTM] Initializing pool allocator
[ 4.105035] [TTM] Initializing DMA pool allocator
[ 10.522147] [sched_delayed] sched: RT throttling activated

The MicroServer RAC has an AST1100 video controller that currently doesn’t work very well with the Linux KMS (Kernel Mode Setting).

HP RAC KVM out of sync

 

So, to fix this issue you need to disable the KMS for the ast module:

  • Edit /etc/sysconfig/grub and at the end of the GRUB_CMDLINE_LINUX line add “ast.modeset=0 nomodeset
    GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=latarcyrheb-sun16 rd.luks=0 KEYTABLE=it LANG=en_US.UTF-8 ast.modeset=0 nomodeset quiet"
  • Update the grub2 configuration
    grub2-mkconfig -o /boot/grub2/grub.cfg

OPTIONAL

  • Create /etc/modprobe.d/ast.conf with
    options ast modeset=0
  • Update the initramfs with dracut
    dracut --force

The bug has been reported at RedHat Bugzilla bug #926064.

References:
modinfo ast:

filename:       /lib/modules/3.8.3-203.fc18.x86_64/kernel/drivers/gpu/drm/ast/ast.ko
license:        GPL and additional rights
description:    AST
author:         Dave Airlie
alias:          pci:v00001A03d00002010sv*sd*bc03sc*i*
alias:          pci:v00001A03d00002000sv*sd*bc03sc*i*
depends:        drm,drm_kms_helper,ttm,i2c-core,i2c-algo-bit
intree:         Y
vermagic:       3.8.3-203.fc18.x86_64 SMP mod_unload
parm:           modeset:Disable/Enable modesetting (int)

SNMP hell (part 1): proxy to multiple devices

Last week I started working on the @GEMwrld HPC cluster at the Eidgenössische Technische Hochschule Zürich (ETH). The first task was to implement a kind of system monitoring and resource profiling. We already have a centralized graphical web console, built upon Observium, that collect resources statistics from all of our servers; usually we use SNMP v2c and, just for a few cases, the munin-node daemon (more on this will be in the part 2).

On the ETH cluster we have full access to every node, but the only incoming connections allowed by the ETH firewall are the SSH sessions (on port 22), so there’s a first problem: how can we transport SNMP data from the agent to the poller?

The answer is easy: SSH tunnel! But: usually SNMP uses UDP protocol; making an UDP SSH tunnel is a bit painful. To workaround this issue we had simply used the TCP protocol for SNMP.

First of all you need an SSH tunnel. In this case the tunnel is made by the monitoring server:

ssh -N monitoring@serverip -L 16000:localhost:161

The 161 is the remote TCP port to be forwarded and 16000 is the local port.

To use SNMP on TCP you have to modify the net-snmp daemon (snmpd) command line parameters (and not the snmpd config file); just edit /etc/default/snmpd (on ubuntu/debian, for RHEL the path is /etc/sysconfig/snmpd) as following:

SNMPDOPTS='-LF 6 /var/log/snmpd.log -u snmp -g snmp -I -smux -p /var/run/snmpd.pid TCP:161'

The important part is ‘TCP:161’. This will bind snmpd on every interface and on the TCP port 161 (the default SNMP port).
On the poller side you will need to configure your monitoring system to poll localhost:16000 with tcp protocol. For Observium you can add the host with:

./addhost.php localhost  community v2c 16000 tcp

Now there’s another problem. The Zurich GEM cluster is made by eight nodes and I do not want to start an SSH tunnel on every node. Then my idea was to use a kind of proxy on the control node:

eth_snmp

net-snmp helped me with the snmpd proxy capabilities: http://www.net-snmp.org/wiki/index.php/Snmpd_proxy

Continue reading