Tuesday, June 23, 2009
I missed a lot of things. Version 8.0 is better integrated, actually easier to use for newcomers, and the graphs you can make are much more readable. Exit is the old "web forms" interface, everything is Java-based, and surprisingly, it works! While previous versions didn't allow you to easily print out graphs from the Java interface, this one has a handy Print function that will pop a standard browser with a nice looking graph you can print such as this one:
And take a look at the CPU gauge which has changed for the better:
There are some things that are less fun, though. For instance, while it used to be very easy to unselect metrics to be displayed in the graph in the previous version by simply clicking on them in the legend, this no longer works. You have to edit the graph and remove the manually, and it takes more effort. The older systemcoda.txt no longer works either to quickly add managed nodes - you need to import them using a tedious process, or edit and XML file directly, and restart OVPM each time you change it.
The graphic designer has also changed a lot its interface, so users who tediously migrated from Perfview to OVPM <=7.0 will again have to change the way they work. Considering it's a complex process, that's too bad.
Overall 8.0 is interesting if you're looking into making sexier graphs, but functionality might be a problem if you're used to the older versions. In my case, since I'm a casual user, I'm glad to have migrated to 8.0.
Monday, June 22, 2009
I presented on this subject at HPTF2009, and the slides are out on the session scheduler. For those who did not attend to the event, I have a copy of my presentation here: http://www.mayoxide.com/presentations/
If I had to do this all over again, you can be sure I would have presented with a subject on RSP this year. But abstracts are due in January, and it was too early back then to know if I would have enough dough to make a presentation on RSP for the HPTF. Perhaps for 2010? Maybe, if I can go once more. I've assisted to the event since 2006 and I'm not sure if my management will let me go again.
Saturday, June 20, 2009
Friday, June 12, 2009
This blog post will be the first part of a series that should span well until 2010. I have almost everything to upgrade, from low-life, disposable VMs to a cutting-edge Metrocluster. VM's are pretty straightforward to do, so today I'll start with vPars.
How do you update vPars to 5.xx / 11.31 without using update-ux?
The new 5.xx monitor series support mixed environments., so you need at least one vPar running 11.31, while the others can stick to 11.23. Here is the quickest way I found to do this.
1. Run "vparstatus -p partition -v" on each of your original vPars, and record all the information (especially boot disks)
2. Plan in advance what vparcreate syntax you'll need to do to recreate them. For example:
# vparcreate -p bonyeune -a cpu::1 -a mem::4096 -a io:1.0.4 \
3. Put your server un nPars mode, and reinstall your "master" vPar using your Golden Image. The "master" vpar is the one on which you will boot the new 5.x vpmon. Add to your new server package T1335DC, i.e. the product name of the 5.05 Virtual Partitions product. Once this is done, recreate all your vpars, including the master vpar, using vparcreate (don't forget the boot disks).
4. Reboot the server in vPars mode, and launch the 5.x vpmon manually. Then try booting all your vPars one by one, starting with the master which runs 11.31, then the others which should still be at 11.23.
5. You can then upgrade at your will the remaining vPars. How do I do this now? Using vpardbprofile(1m) which has been added in recent releases. Using vpardbprofile, you can emulate EFI's dbprofile function, which lets you boot on a cross-subnet Ignite server easily.
Wednesday, June 3, 2009
SAN arrays can be scrubbed independently (remember dilx?) but internal disks are more complicated to do. Many suggestions I've seen in the ITRC forums consist of logging into HP-UX, then wipe the disks using "dd /dev/zero" or similar tools. From my experience, this is risky. I used to do this over 10 years ago when decomissioning workstations, and the operating system eventually stopped working while the disks were scrubbing, leaving no proof that the they had indeed been wiped completely.
With a Proliant, no problem. Just boot up a Linux live CD such as System Rescue CD and it will come with a scrubber. Case closed. But with an Integrity server, it's more complicated as there aren't Linux live CDs available. Maybe with some elbow grease I could make one with CentOS but I don't know Linux enough to take on the challenge.
The Ignite-UX expert recovery mode
Ignite-UX comes with a rarely-used mode named "Expert Recovery" which puts on a RAM disk many tools you need to recover an unbootable system. Instead, we'll use the expert recovery shell to actually wipe out disks! While we could compile a statically-linked open source scrubbing tool such as diskscrub, to save time we'll bring in mediainit(1m) which, since the March 2009 release of 11.31, has a new scrubbing option. Since the man page does not describe precisely the algorithm used, I checked what mediainit actually writes, and from my findings, it follows the DoD 5520.22-M standard which consists of writing one character, the complement, then a random character. It should be enough for most people... but for classified stuff, nothing beats a drill press.
a/ Start by putting a working mediainit under /var/opt/ignite/scrub on your Ignite server. It has to come from a March 2009 11.31 release, as it's the earliest to support scrubbing. You'll also need to add the libpthread library since mediainit has a dependency on this library, and it's not included in the expert recovery environment.
ignite-server# mkdir /var/opt/ignite/scrub
ignite-server# cp /usr/bin/mediainit /var/opt/ignite/scrub
ignite-server# cp /usr/lib/hpux32/libpthread.so.1 /var/opt/ignite/scrub
b/ Ignite the server you want to wipe out. Igniting is beyond the scope of this howto, I personally use dbprofile and lanboot at the EFI to do this. If you are given choices between igniting 11.23 or 11.31, choose 11.31. Of course, if you're on a K class or some other older hardware that doesn't support 11.31, you're out of luck. Stop here, and try to compile diskscrub to add it to your 11.23 or 11.11 Ignite server.
Obtaining size of AUTO (226 bytes)
Downloading file AUTO (226 bytes)
1. target OS is B.11.23 IA
2. target OS is B.11.31 IA
3. Exit Boot Loader
Choose an operating system to install that your hardware supports: 2
c/ When you get to the Welcome to Ignite-UX screen, choose Run an Expert Recovery Shell. Configure your network and click OK. A RAM disk will be created, and some useful commands will be pulled from the Ignite Server. You'll be presented with a menu, where you must choose X - exit to shell.
HP-UX NETWORK SYSTEM RECOVERY
s. Search for a file
l. Load a file
r. Recover an unbootable HP-UX system
x. Exit to shell
This menu is for listing and loading the tools contained on the core media.
Once a tool is loaded, it may be run from the shell. Some tools require other
files to be present in order to successfully execute.
Select one of the above: x
Type 'menu' to return to the menu environment. Do not use 'exit'.
d/ mediainit and libpthread are missing from the environment, so they must be pulled from the Ignite server. To do this, we'll use tftp which is the protocol used to download software from the Ignite server.
First get mediainit and put it in /usr/bin:
# cd /usr/bin
# tftp ignite_server_ip_address
tftp> get /var/opt/ignite/scrub/mediainit
Received 88405 bytes in 0.0 seconds
# chmod 755 /usr/bin/mediainit
Then get libpthread.so.1 and put it in /usr/lib/hpux32:
# cd /usr/lib/hpux32
# tftp ignite_server_ip_address
tftp> get /var/opt/ignite/scrub/libpthread.so.1
Received 1521497 bytes in 0.6 seconds
e/ You're done! You now have downloaded a workable scrubber in the Expert Recovery Shell.
usage: mediainit [-vrn] [-f fmt_optn] [-i interleave] [-p partition_size] pathname
usage: mediainit -S [-t scrub_count] [-c scrub_character] special_file
f/ The last step is identifying your disk devices under /dev/rdsk, and wipe them using the -S option:
# /usr/bin/mediainit -S /dev/rdsk/c0t0d0
WARNING: You have invoked the disk scrub option.
Using this option will completely destroy the data
on the specified disk. All the signals except SIGINT(ctrl-c)
will be disabled during disk scrub.
Are you SURE you want to proceed? (y/n) y
Disk scrub:PASS 1
Disk scrub:PASS 2
Disk scrub:PASS 3
mediainit: Disk scrubbing successful
With these default options, mediainit will write these hex characters in order to follow the DoD spec: First '0x30', then '0x66' , finally '0xc6'. 66 is the complement of 30, while c6 is the "random" character which is actually hard coded in mediainit. It's actually more interesting to use -S alone rather than with the -c (scrub character) and -t (number of times to scrub) options since these two options do not alternate between different characters and you must reinvoke mediainit manually to change them.
Tuesday, June 2, 2009
Why would you want to do this? Here are some examples:
- Migrating devices from scsi to avio_stor, without rebooting the VM (assuming it has the avio drivers, of course)
- Switching from a datastore to another. For example, moving from a flat file to a raw disk
- Moving data from a RAID-5 volume to RAID-1
- Migrating from one disk array to another
Add your new raw device to your VM:
vmhost# hpvmmodify -P myvm -a disk:avio_stor::disk:/dev/rdisk/disk39
vmhost# hpvmstatus -P myvm
[Storage Interface Details]
Device Adaptor Bus Dev Ftn Tgt Lun Storage Device
======= ========== === === === === === ========= =========================
disk avio_stor 0 1 0 0 0 file /ivm/myvm/disk1.vm
disk avio_stor 0 1 0 3 0 lv /dev/vg_myvm/rlv_vgdata
disk avio_stor 0 1 0 4 0 disk /dev/rdisk/disk39
In the VM itself, make an ioscan to discover the new device
myvm# insf -eC disk # insf required only on 11iv2
myvm# ioscan -kfnC disk
Class I H/W Path Driver S/W State H/W Type Description
disk 0 0/0/1/0.0.0 sdisk CLAIMED DEVICE HP Virtual FileDisk
/dev/dsk/c0t0d0 /dev/dsk/c0t0d0s2 /dev/rdsk/c0t0d0 /dev/rdsk/c0t0d0s2
/dev/dsk/c0t0d0s1 /dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s1 /dev/rdsk/c0t0d0s3
disk 3 0/0/1/0.3.0 sdisk CLAIMED DEVICE HP Virtual LvDisk
disk 4 0/0/1/0.4.0 sdisk CLAIMED DEVICE HP Virtual Disk
See that new "Virtual Disk" device? Just pvcreate it and add it to your the VG on which you need to migrate data. Here I'm using legacy devices since my VM runs 11iv2, but you can do this with agile devices if you wish.
myvm# pvcreate /dev/rdsk/c0t4d0
myvm# vgextend /dev/vgdata /dev/dsk/c0t4d0
myvm# vgdisplay vgdata
--- Physical volumes ---
PV Name /dev/dsk/c0t3d0
PV Status available
Total PE 1249
Free PE 0
Proactive Polling On
PV Name /dev/dsk/c0t4d0
PV Status available
Total PE 1279
Free PE 1279
Proactive Polling On
Then, use pvmove to move your physical extents from one datastore to another using pvmove, as you would on a physical server.
myvm# pvmove /dev/dsk/c0t3d0 /dev/dsk/c0t4d0
Transferring logical extents of logical volume "/dev/vgdata/lv_mydata"...
Here, LVM will be moving LIVE all your data from c0t3d0 (an LVM datastore) to c0t4do (a raw disk datastore). The process can take a while, since it's going slow voluntarily to prevent the process from interfering with normal operations.
When it's over, remove the empty PV from the VG
myvm# vgreduce vgdata /dev/dsk/c0t3d0
myvm# pvremove /dev/rdsk/c0t3d0
myvm# rmsf -H 0/0/1/0.3.0
Then, remove it from the VM host:
vmhost# hpvmmodify -P my_vm -d disk:avio_stor::lv:/dev/vg99/rlv_vgdata
And you're done. You've just migrated storage live in your VM.
Monday, June 1, 2009
- If possible, start from scratch with a fresh CMS. SIM is easy to backup/restore so you won't loose any data.
- Don't be tempted to install anything else on the CMS.
- Use RSP 5.20, as 5.10 has a dumbed-down Software Manager that doesn't tell you what it's doing.
- If you have EVAs, reinstall the SMS from scratch too, with SmartStart or the Proliant Support Pack, and ensure that it has only the required software to manage the EVA and link it to RSP
- Proliants running Windows and ESX are easy to configure, just use the SMH to send traps the the CMS.
- As for HP-UX... well, while the CIM-related tools are not terrific, SFM itself is worse. I've had lots of problems with it. You've been warned.