When building a virtualization lab system, I’ve found that I want static IPs assigned to my guests. You could just assign static IPs in the guest OS, but then you should document what IPs are in use for what hosts. It would be easier to just assign static IP entries in the DHCP server. There doesn’t seem to be a straight-forward way to get this done.
What I’ve found works is to destroy the network, edit it directly, and then restart it.
The client OS level field in TSM for most operating systems is pretty straightforward. On Linux, it’s the kernel version, HP-UX and AIX show a recognizable OS level. For windows the OS level is more cryptic. Here is a list of the OS levels:
||Client OS Level
|Windows NT 4.0
|Windows Server 2003
|Windows Server 2008
As usual, I’m late to the party. I was at the Power Systems Technical University in San Antonio several years ago (an awesome venue), and there was a session on the new AIXPert feature of AIX 6.1 (later back-ported to 5.3). At the time I though it was clunky and wasn’t too excited about it.
OK, I’m Converted. I Like AIXPert full post
(980 words, estimated 3:55 mins reading time)
After installing the IBM License Metric Tool, you might see:
Essential periodic calculations did not occur when expected. The last day processed is Apr 25, 2011 while it should be Apr 29, 2011.
By default the tool processes the data collected 2 days prior, so you’ll see the specified dates are a few days old. IBM wants you to collect a bunch of data, and open a ticket, but you may be able to correct this yourself. In CODIF8140E Essential periodic calculations did not occur when expected
IBM tells you that it’s probable that the TLMSRV user doesn’t have the correct privileges to the database, and to turn on debugging and send the logs to IBM. At the bottom of the page, it tells you what is actually needed:
Direct CREATETAB authority = YES
Direct BINDADD authority = YES
Direct CONNECT authority = YES
By default ILMT, and WebSphere in general, asks you for a password when running srvstop.sh if security is enabled. That’s nice if you don’t trust your users. But, if you have a secured system you may not want to have to lookup the userid the once or twice a year you bring down WebSphere.
On a new install of ILMT, with the bundled WebSphere server, all you have to do is edit the soap.client.props file:
I’ve recently found some of our systems have corrupt smit screens when looking at printer queue characteristics. When looking at any options under “smit chpq” for some of the printers, we got:
1800-109 There are currently no additional
SMIT screen entries available for this
item. This item may require installation of
additional software before it can be accessed.
The message clearly points to missing filesets. But printers.rte, bos.rte.printers, and the printer device filesets ( like printers.hplj-4si.rte) were all installed and up to date. The problem is that the ODM stanzas for the printers aren’t correct. The queue subsystem looks a files under /var/spool/lpd/pio/@local to do the printing, but smit looks in the ODM.
Smit 1800-109 Error With Printers full post
(160 words, estimated 38 secs reading time)
UPDATE: I got some feedback that some people are not clear on creating multiple schedulers, so I’m updating this post.
Since I wrote about doing TSM Full-VM Image Backups With VStore API I’ve done more testing, and have put it into “production” with our smaller VMWare cluster. This cluster is managed by one department inside IT. It has some VMs used by customers inside the enterprise, some VMs used for development or testing, and some VMs used by the group inside IS. Now that I’m ready to put VMWare backups into practice, I need to schedule the backups. And, I got some great feedback on the first post, so I thought I would follow it up.
Scheduling TSM VMware Backups full post
(956 words, 1 image, estimated 3:49 mins reading time)
I had a recent discussion with a teammate about VMWare datastores. We are using thin provisioning on a ESXi 4.1 installation backed by IBM XIV storage.
In our previous installation we ran ESX 3.X backed by DS4000 disk. What we found out is that VMs grow like weeds and our datastores quickly filled up. This admin just resized the datastores and we went on our way. A technical VMWare rep afterward mentioned that while it is supported, adding extents to VMFS datastores isn’t necessarily best practice.
VMWare Datastore Sizing and Locking full post
(930 words, estimated 3:43 mins reading time)
As a request from one of our VMWare admins, I’ve started testing the VMWare image backups. In the past, we’ve installed the regular backup/archive client on each VMWare guest OS. This has let us standardize our install regardless of if it’s a virtual or physical server. This doesn’t allow you to take a full snapshot of a VM, instead you have to rely on your baremetal recover procedures just as if it was a physical server.
Unfortunately, an application admin messed up a server, almost beyond repair. If the VMWare admins had been made aware of the work, they could have generated a snapshot just before the work started, and recovering would have been quick and simple.
TSM Full-VM Image Backup With VStore API full post
(1207 words, 5 images, estimated 4:50 mins reading time)
Here’s a simple thing that I ran across. I have a vendor that recommended that I set the Maximum memory in my LPARs to the system maximum. That way you never have to reboot to increase the maximum memory in that LPAR. I found out later that setting your LPARs memory to the system maximum makes the hypervisor allocate more memory for overhead.
LPAR Memory Overhead full post
(165 words, estimated 40 secs reading time)