A tale of trying to run the HP BladeSystem Power Sizer

Normally when I want to evaluate the power that a server will pull from the grid, I just check its specifications and I'm done with it. Yesterday I needed to measure the power requirements of a C3000 chassis we're going to install in a data center downtown. It hasn't been that trivial.

Here is the scoop: I'll tell you how right away how much power a C3000 consumes.

• It has a maximum of 6 power supplies, each rated at 1200W.
• Since this is a 3+3 configuration of redundant power, this means that the total it can consume is 1200W * 3, which makes 3600W.
• At 240V, 3600W gives out 15 amperes.
• Done.

While this is possibly not the best way to calculate how much power it requires, doing otherwise is not very easy. The quickspecs detail every possible configuration but are shy on the exact consumption. 6.2A per power supply is mentioned at the end. So okay, we're at 18.6 amperes then.

Then there is the tool named "HP BladeSystem Power Sizer" that looked promising. I could not have been more wrong.

I expected a nice web-based application or, at worst, an Excel spreadsheet (Google docs would have been way cool). But of course, no, no, no, no, no, no! HP made a stand-alone software to do this. I don't see that much anymore, especially for such a purpose. Maybe it has nice bells and whistles that the programmers didn't know how to develop using AJAX, because they're stuck in limbo in a brave .NET world? Perhaps. How could I know? I haven't even been able to make it run!

For a vendor to release stand-alone software like this in 2009 is an excellent way to loose sales. Writing short-sighted Javascript too, by the way. Here's why:

1. Many corporate PCs are locked and users do not have administrator privileges, it's my case here. The Power Sizer is a full-blown InstallShield-packaged setup program, and it fails with an error if you're not an admin. Okay, so I ask an admin to install it.

2. Then I'm welcomed with a dialog that asks me to input my name, company, and e-mail address. It's definitely going to send this back to HP. Why not doing a web-based interface then? No privacy policy info can be seen anywhere (looks like it was at the end of the long EULA I blood-signed when I installed earlier).

3. And, at the end of it all, I get greeted by this:


As you see, this is a white window, with useless menus at the top which don't do anything except offer me the choice of leaving or changing my profile information and an about box.

Boy, does a tool like this suck. Not only does it run only on Windows (GNU/Linux users, scram!), but it requires administrator privileges to install (users with locked PCs, scram!), and according to the EULA, it sends back to HP what you're doing with it (privacy advocates, scram!). And finally, it doesn't even work (customers who made it here, scram!).

Back to the calculator to chew up the power requirements, I guess.

vgimport with persistent DSFs

When upgrading a server from 11.23 to 11.31 using a cold-install, the procedure to migrate your VGs and filesystems boils down to this:

1. vgexport -s -p -m vg_name.map vg_name
2. Keep a backup copy of the fstab
3. Reinstall
4. vgimport -N -s -m vg_name.map vg_name
5. Put back the filesystems in fstab, create the directories and mount

Pretty straightforward, huh?

System administrators familiar with vgexport/vgimport will notice the new -N option which, according to the man page does this:

 -N             Configure the volume group by populating
                persistent device special files in the /etc/lvmtab
                or /etc/lvmtab_p file, corresponding to the volume
                group, vg_name.  (See intro(7) for information
                about device special files.) This option can only
                be used with -s option.  If vgimport is invoked
                without a -N option, legacy device special files
                will be used to populate the /etc/lvmtab or
                /etc/lvmtab_p file.

                This option may become obsolete in future
                releases.

What this option does, is importing your imported VGs with persisten DSFs. If you don't do this, they will be imported using the legacy DSFs, and if you're on a SAN this means that PVLinks will still be used. I think that the storage stack on 11.31 is smart enough to apply multipathing in the background to legacy DSFs but it's much cleaner to use the persistent DSFs right away.
O./

Even though I'm not fond of RSP, it *does* work

This morning, a cache battery in one of our EVAs failed at 10h58 AM. At 11h20, the response center called me back to confirm the event (I hadn't read all my mails yet and was not even aware of it by then). I didn't even have mention the part number or the site address. We got in touch with a field engineer by noon.

That's the kind of event where of having invested so much time, and so much energy, in making RSP work pays off.

The ISEE EOL e-mail. Or is is AOL? Or LOL?

I got this e-mail today from the Insight Remote Support Team announcing the demise of ISEE:


Did you notice the image has been scaled down? And that the text in it is more readable than this blog post? This is because, my friends, the desk jockey who typed up that e-mail thought that using a 36 point font would gather my attention. How pathetic. It looks like a junk mail sent from @aol.com in the early 2000s. It's so unreadable that I threw it away, laughing. As my blog readers know already, I'm fully aware that ISEE is going away.

To help me appreciate HP further, did you know that I've been trying for 6 weeks now to get Licenses in Command View 7 format? This is becoming an interesting developing story. I'll soon write about this, and will give out how many people up the HP ladder had to be bothered so that I could get these fucking licenses. Help rebuild the U.S. economy: Ask for CV 7 licenses!

HP-UX IP Filters for SIM and RSP/IRS

Here is what I think are the best filters you can configure in IP Filter when you want an HP-UX server to be monitored by SIM and RSP/IRS:

# Ports required for System Insight Manager / IRS
block return-rst in log quick proto tcp from 1.2.3.4/32 to any head 10
  pass in quick proto tcp from 1.2.3.4/32 to any port = wbem-http  flags S keep state keep frags group 10
  pass in quick proto tcp from 1.2.3.4/32 to any port = wbem-https flags S keep state keep frags group 10
  pass in quick proto tcp from 1.2.3.4/32 to any port = 2381       flags S keep state keep frags group 10
  pass in quick proto tcp from 1.2.3.4/32 to any port = 2301       flags S keep state keep frags group 10
  pass in quick proto tcp from 1.2.3.4/32 to any port = 22         flags S keep state keep frags group 10
block return-icmp(port-unr) in log quick proto udp from 1.2.3.4/32 to any

Replace 1.2.3.4 with the IP address of your CMS.

The rules are set up as a group, to optimize filter processing: any TCP packet that comes in from the CMS goes in group 10, where the filter tries to match it with group 10's rules.

If the TCP packet originating from the CMS is trying to reach the WBEM Services, The System Management Homepage or the SSH port, it goes through. In all other cases, we're a good IP citizen here, as anything that does not match these rules will be sent back a TCP reset (return-rst) instead of seeing its packet dropped. This accelerates the scanning from SIM, and also fixes a problem with WEBES that can hang for a while when it has to deal with dropped packets. We also return an ICMP port unregistered for each UDP packet, since no service at all listens on UDP (not even SNMP).

The 2GB limit of lp

I just noticed here a thread in the ITRC forums about someone who's trying to lp a file bigger than 2GBytes:
http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1354026

I'm not surprised it doesn't work. Who could possibly have imagined at Berkeley in, say, 1985, that someone would actually want to print 2 gigs of data?

Although I'm sure there is a valid need for this, man, this makes me realize that times have changed. When I started high school, complete PC games used to fit on a 360k floppy! And they were fun!

Time to convert all these legacy tools to 64 bits. And yes, that includes biff, roff and ex.

One liner: Compare kernel parameters between 11iv2 et 11iv3

When upgrading from 11iv2 to 11iv3, you might be required to check your kernel settings to be sure they are still appropriate. I don't know if update-ux retains kernel settings since I prefer cold installs, but this one liner should help you. Simply redirect the output of kctune to kctune.11iv2 before the upgrade, keep the file, then do the same with kctune.11iv3 once you've upgraded and run this to compare the two files:

cat kctune.11iv2 || while read param value crap
do
  grep -E "^${param}" kctune.11iv3 || read param2 value2 crap2
  if [ ! "${param2}" = "" -a ! "${value}" = "${value2}" ]
  then
     echo "11iv2: ${param} ${value}"
     echo "11iv3: ${param2} ${value2}"
     echo
  fi
done

The double-pipes should be replaced with pipes (blogspot doesn't seem to let me paste pipes here)