Server Monitor and Local Lights Out Management for XServe

By Matthew Savage

I haven’t been able to find this documented anywhere – but it is possible I haven’t looked hard enough…

We recently had an issue with one of the XServe units we were using for a Final Cut library setup we were working on. The problem, in short, was that when you powered the server on it would scream like a banshee continuously – i.e. the fans were going nuts.

Originally we thought this was ‘usual’, I had heard other 1U form factor units spin their fans somewhat high previously (Dell backup units anyone?), but once we powered down this machine there was a resounding quietness even though the other servers were running.

This warranted a look at the Server Monitor to see what the fans were doing – but it wasn’t as simple as just plugging in the server’s IP address.

Server Monitor uses the Lights Out Management (LOM) to get info on the health of the servers. This is a piece of management hardware which piggy backs on the servers NICs to provide access to information and some functionality (such as forcing reboots etc) even when the server in the software level is inaccessible.

The address of the LOM interfaces need to be different from the regular NIC configuration, otherwise the network gets confused and weird things happen. Configuration is as simple as opening Server Monitor, choosing the Server menu and then choosing Configure local server – then plug in the information, click OK and its set.

What isn’t so obvious though is how to use Server Monitor on the local machine. I initially put in the LOM IP address which I had configured – 10.10.0.101. It sat there for a minute, thought about it, and then came up with ‘CANNOT_LOAD_BUNDLE_ERR’. Descriptive – no?? After a bit of digging I found a suggestion to use the loopback address – 127.0.0.1 – and after slapping my self on the forehead for not considering this first I put the address in, authenticated, and boom, server status came up!

So what was the cause of the screaming fans? The intake fans on CPU2 were not running, and as a result the other fans were compensating to ensure proper airflow through the cooling ducts. A quick ten minute job to swap out the blower module and power it back on, and the server room was a much quieter place.

I have to say, I’m pretty impressed with the Apple hardware :)

  • Ensure IP for local access is 127.0.0.1
This entry was written by Matthew Savage, posted on August 27, 2009 at 3:49 am, filed under Home, IT Consulting and tagged , , , , , , , . Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL.
  • http://openid.shawnkoppenhoefer.com/ Koppenhoefer

    Hello… and thanks for your post!

    While our LOM on localhost works fine, we are still getting the CANNOT_LOAD_BUNDLE_ERR that you describe when using Server Monitor remotely. Were you ever able to do that, and did you have to do anything special?

    I'm having these troubles on an early2009 Xserve (our other Xserve is early 2008 and works fine) under 10.6.4. Doing “sudo changeip -checkhostname” gives correct answers, doing LOM to localhost on that machines works fine, and yes, we have a unique IP dedicated to the LOM. Do you have any other ideas?

    One curious observation that I've made is that when connected as localhost, in Configure Local Machine, it doesn't seem to matter what I put in as a username and password; The one that counts seems to be the local admin user with his password (idem from remote btw).

    cheers,
    Shawn

  • Anonymous

    Hi Shawn, I’m not sure what is exactly happening here but it seems like its still attributed to a communications problem.

    After some brief research I can tell you that the LOM is based on IPMI (http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface) and there is a command line tool which might be helpful for diagnosing your issue (ipmitool). You could also run Wireshark and watching for UDP data on port 623, plus check to make sure your firewall isn’t causing any issues (though, as this is handled by its own processor, and not part of the system kernel it shouldn’t be affected by this…).

    Hope this helps.