We recently installed a new Satellite 6.1 server on VMWare to replace our older physical Satellite server. On our VMWare engineer’s recommendation we configure the VM with 2 cores and 8GB of RAM, a bit under what RedHat calls for. This is from the Red Hat Satellite 6.1 Installation Guide:
Red Hat Satellite requires a networked base system with the following minimum specifications:
The latest version of Red Hat Enterprise Linux 6 Server or 7 Server
A minimum of two CPU cores, but four CPU cores are recommended.
A minimum of 12 GB memory but ideally 16 GB of memory for each instance of Satellite. A minimum of 4 GB of swap space is recommended.
If you manage your own SAN, you’ll eventually be asked questions like “Why are some of my databases slow?”, “Why do we periodically have performance problems?” or “Do we have a hot LUN?”. Modern arrays have real-time performance monitoring, but not all of them have historical data so you can see if there’s a periodic performance issue or if the current performance is out of the ordinary. There are vendor supplied products and lots of third party products that let you gather performance statistics, but they’re usually pretty expensive. If you just need to gather and report on the performance data for IBM V7000, SVC, or DS8000 storage, there is a great FREE product call Stor2RRD.
I recently had someone ask me how to rezise a LUN in RHEL without rebooting. The “go-to” method for this admin was to reboot! This is easily accomplished in AIX with “chvg -g”, but how to do this in Linux wasn’t so obvious.
In my example, I’m using LUNs from a SAN attached XIV storage array, using dm-multipath for multipathing and then LVM for carving up the filesystems. After the LUN is resized on the storage array (96Gb to 176GB in my case), we have to scan for changes on the SCSI bus. I’m assuming you have the sg3_utils package installed to get the scsi-rescan command. The simplest thing is to just rescan them all, though you can do them individually if you want:
Last year I budgeted for 3 P740C model’s to replace 3 P6 550 models that were getting long in the tooth. Because of the long lead time in our budget process and the continued downward pressure from IBM on their pricing, I was able to purchase 4 P7+ 740D models. That is a big win for us.
After implementing new 7042-CR7 model HMCs (which I recommend everyone upgrade to) and powering on our first box, I noticed that the latest HMC code reports the server has a Power7 and not a Power7+. The Power7 chip has been out for nearly a year, and the HMC has been through several updates since then, so why does it not show Power7+ the way it did for Power6+? Here’s what the screen looks like:
I recently setup a backup process to dump a MySQL database to a file for backup. With this database, our DBA group has been using the ‘root’ account setup the by software vendor for administration. This server is used for internal system administration and sending performance data off to our software vendor. So, other than being bad form to use the ‘root’ ID, there’s probably no regulatory responsibility to use user or role specific IDs.
I recently put up a test Splunk server to act as a central syslog repository, one of the issues in our security audits. There are some “open” projects to do this, but Splunk has a lot of features and is “pretty” compared to some of the open alternatives. Getting data from our Linux hosts was a snap, but data from our AIX hosts has a few minor annoyances. Fortunately, we were able to overcome them.
I ran into an interesting problem recently. A de-duplicated pool containing TDP for Oracle backups was consuming much more space than would otherwise be indicated. Here’s what the occupancy looked like:
Node Name Storage Number of Logical
Pool Name Files Space
---------- ---------- ----------- -----------
CERN_ORA_ADMIN CERNERDISK 810 31,600.95
CERN_ORA_BUILD CERNERDISK 1,189 74,594.84
CERN_ORA_CERT CERNERDISK 402 3,876,363.50
CERN_ORA_TEST CERNERDISK 905 7,658,362.00
LAW_ORA_PROD CERNERDISK 1,424 544,896.19
OEM_ORA_RAM CERNERDISK 2,186 524,795.31
That works out to about 12.7 TB. And, here’s what the storage usage looked like:
I’ve been running the XIVGui on a Windows7 VM so that I have it available from anywhere. That does work, but then I have to launch an rdesktop session, login, then launch the XIVGui, and login again. I finally got tired of the extra steps and decided to load the XIVGui when I upgraded to Fedora 16. I considered making an RPM, but I’m sure IBM would frown on redistributing their code. These manual steps work great on Fedora 16, should work fine on Fedora 15. I haven’t tested it with RHEL or other versions.
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: