 |
|
HMC Version 7 and Your Browser of Choice
The documentation for HMC Version 7 says that the web browsers supported are Microsoft Internet Explorer 6.0 and later, as well as Firefox 1.5.0.6 and later. While many users have no trouble with Internet Explorer 7.0, others have reported problems. What makes the difference? Sometimes its Java code, and sometimes its the browser settings.
For example, a customer recently reported trouble with IE 7 after he updated Java to jre 1.6.0_05 from jre 1.6.0_03. Previously, IE 7 had worked fine.
IBM support usually will make a best-effort attempt to resolve your browser compatibility problems. But in the case above, the problem wasn't the HMC code or even IE 7 itself, since it had worked with an earlier level of Java. By being conservative in upgrading browser and Java code, you may avoid slipping into an unsupported condition.
What are the requirements for browser support?
1. HTML 2.0, JavaScript 1.0, Java Virtual Machine (JVM), and support for cookies. (If necessary, contact support personnel to see if your browser is configured for a Java Virtual Machine.)
2. The browser must use HTTP 1.1 protocol; if a proxy server is used, HTTP 1.1 must be enabled for the proxy server. (In Internet Explorer, see the Advanced tab under Internet Options)
3. For Firefox 2.0, make sure the JavaScript option to raise or lower windows and move or resize existing windows is enabled. To enable this option, go to the Content tab in the browser’s Options dialog, click Advanced... next to the Enable JavaScript option, then select Raise or lower windows and Move or resize existing windows options, then click OK to enable. These features allow you to switch easily between HMC tasks and to resize the task window.
Categories
: [ HMC ]
Mar 21 2008, 04:23:03 PM EDT
Permalink
|
|
Ordering the Correct HMC Model
Be sure you order the correct Hardware Management Console to match the code you plan to run.
The 7042 machine type is for HMCs running Version 7. This Licensed Internal Code is a requirement for managing POWER6 servers, such as the 9117-MMA. However, it will also support POWER5 and POWER5+ managed servers.
The 7310 machine type is for HMCs running Version 6. You cannot manage a POWER6 server using this HMC code. It is for POWER5 and POWER5+ managed servers only.
Many 7310 HMCs can be upgraded in the field to support HMC V7 Release 3 code. However, the reverse is not true. IBM does not support changing a 7042 HMC to support HMC V6 Licensed Internal Code. Attempting to load HMC V6 LIC on a 7042 will produce an error message and the installation will be blocked.
In current models, the only difference between the two machines is a feature code that specifies which code to install. The hardware is identical. Feature code #0961 drives shipment of HMC Version 6 with the HMC. Feature code #0962 drives shipment of HMC Version 7.
To avoid delays, be sure you know which HMC code environment you want before ordering your HMC.
Categories
: [ HMC | POWER5 | POWER6 ]
Jan 21 2008, 05:33:37 PM EST
Permalink
|
|
Configuring AIX SAN Boot
Configuring MPIO for the Virtual Client, describes how to set up Multi-Path I/O boot disks for AIX clients of the virtual I/O server. There some considerations for booting off the SAN.
The "pro's" include:
- IBM supported configuration
- Flexibility
The "con's" include:
|
|
Sizing Replacement Servers
I use the following formula to size the minimum number of cores on replacement servers. The formula is based on "used" performance on the installed servers matching "used" performance on the replacement server.
c2 = (u1)(c1)(p1) / (u2)(p2)
Where
c1 = # cores on the installed server
p1 = "performance per core" of the installed server
u1 = % utilization of the installed server
c2 = # cores on the replacement server
p2 = "performance per core" of the replacement server
u2 = % utilization of the replacement server
If consolidating multiple stand-alone servers to micropartitions, sum the replacement cores (c2) required for all the stand-alone servers.
The “performance per core” should be based on a relevant benchmark for your workload. The preferred metric is your application‘s benchmark. In absence of that information, pick an industry benchmark that approximates your work load. Historical and current benchmarks for AIX servers can be found at
http://www-03.ibm.com/systems/p/hardware/system_perf.html
In all cases, you should size for the peak utilization during your peak processing period (daily, “month end“, “seasonal peak“, etc). If the replacement server uses micropartitions, use the aggregate peak utilization. (Note: Servers peak at different times, so the aggregate peak is not the same as the sum of the individual peaks.) A good tool for determining the aggregate peak utilization is Steve Atkin‘s “NMON Consolidator Tool”:
http://www-941.haw.ibm.com/collaboration/wiki/display/WikiPtype/nmonconsolidator
Choosing the CPU “% utilization“ for the replacement server depends on whether its using LPARs or micropartitions. Here are my guidelines for the minimum sizing, with my standard disclaimer: “Your results may vary. Use your best judgement.”
LPARs, Stand-alone Servers, Capped Micropartitions
Size for the peak processing period. Target the replacement server for 90–100%. If peak processing unknown, size the replacement server for an average 30% utilization. Round up to the nearest core.
Uncapped Micropartitions
Size replacement server for the aggregate peak of the installed servers. There is some overhead associated with micropartitioning, so size the replacement server for 80–90% utilization during the aggregate peak..
If aggregate peak is unknown, size the replacement server for the average utilization of the installed servers. Target the replacement server for 50%-70% utilization so it has spare capacity for the peaks.
Round up the shared pool to the nearest core.
Final comment. Micropartitioning has two at least two sizing advantages. Typically it requires half the CPUs as LPARs. And sizing micropartitions is more forgiving. If you size incorrectly, its easy to move resources to where its needed. My experience is that I oversize half the micropartitions and undersize the other half. On the average, the sizing is OK.
Oct 01 2007, 07:24:39 PM EDT
Permalink
|
|
New HACMP Support Announcements
HACMP recently announced support for the following:
SVC 4.1
SVC 4.2
VIOS 1.4 Support
Click on the above linked text for full support details.
Sep 18 2007, 05:42:07 PM EDT
Permalink
|
|
pGraph Freeware Tool for Creating Performance Graphs
Federico Vagnini has written pGraph, an excellent "freeware" tool for viewing AIX and Linux. performance graphs. The viewer works with multiple input formats, including
* nmon (either on AIX and on Linux)
- vmstat -t on AIX
- topasout (AIX's continuous performance data collector)
- topasout on AIX
- iostat -alDT on AIX
- HMC‘s data collection extracted using lslparutil command
- Workload Partition data collected on AIX6 (currently tested only on Open Beta)
You can download pGraph from http://www-941.ibm.com/collaboration/wiki/display/WikiPtype/Performance+Graph+Viewer
One way to run the program is from a DOS window on your PC. They syntax I use is
java -jar pGraph.jar
Then choose the file.
Aug 21 2007, 04:02:42 PM EDT
Permalink
|
|
AIX, Linux, System p University - Discount to PowerAIX Members
The AIX, Linux, System p Technical University will be held October 1-5 in San Antonio, Texas. The sessions are now available at http://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=page&c=a0004782
You can register at http://www.ibm.com/training/us/conf
There is a 10% discount available to PowerAIX members. (You can join for free at http://www.poweraix.org)
Apply for the discount at enrollment as follows.
Enroll at http://www.ibm.com/training/us/conf and follow these steps:
Choose the IBM System p, AIX and Linux Technical University
Under the “Next Step“ section, click on “Conference Registration”
Complete the appropriate fields on the enrollment form
Under the “Financial Information“ section, choose your method of payment and enter Promotion Code: “P2U”. YOU MUST ENTER THIS CODE TO RECEIVE THE 10% DISCOUNT
When complete, click "Submit" at the bottom of the form.
Jul 22 2007, 12:17:50 AM EDT
Permalink
|
|
Workaround If Auto Negotiation Fails
Performance concerns on the Hardware Management Console sometimes point to a misconfiguration of the network adapters.
In most cases, configuring eth0 and eth1 as either private or open networks using auto negotiation results in no problems whatsoever. But on occasion, the ability of the Ethernet card to correctly negotiate full duplex with a particular switch or router appears to fail and the adapter comes up in half duplex mode. If the switch really is configured for full duplex, the switch may be reporting a problem (or it may go unnoticed) and network traffic on the HMC will slow. Obviously, this can have negative consequences for the performance of the HMC.
A workaround for this problem is to manually turn off auto negotiation on the adapter and set it to full duplex. The ethtool command on the HMC can be used to execute this two-step workaround. However, the command can only be issued by root. This means the administrator will need to bypass the restricted shell:
1. Login to the HMC command line interface using the hscpe userid and password
2. Obtain the serial number of the HMC using the lshmc -v command (look in the SE field)
3. Call the IBM Hardware Held Desk and provide the HMC serial number in order to obtain a temporary pesh (Product Engineering Shell) password
4. Logged in as hscpe, enter the command pesh
5. When prompted, enter the pesh password suppled by the Help Desk
6. Enter the command, su -
7. Enter the root password when prompted
Once you are logged in as root, you can use the following ethtool command.
1. Enter ethtool ethN for the adapter (N) you want to look at, and you'll see it's present settings
2. Turn off auto negotiation by issuing the command ethtool -s ethN autoneg off
3. Manually set the adapter to full duplex with ethtool -s ethN duplex full
4. Check your work with ethtool ethN
5. DO NOT reboot the HMC.
The setting will be changed to full duplex until the next reboot, at which time the default settings (e.g., auto negotiation) will be restored and the problem may resurface, requiring you to repeat the process.
It's important to note that this does not occur uniformly across the board with all switches or routers. Therefore, this workaround may not be needed. But you should be aware of this workaround, and that this problem is under active investigation by IBM.
Categories
: [ Adapter | HMC | TCP/IP ]
Jul 19 2007, 01:48:51 PM EDT
Permalink
|
|
|
| S | M | T | W | T | F | S | | | | | | | | 1 | | 2 | 3 | 4 | 5 | 6 | 7 | 8 | | 9 | 10 | 11 | 12 | 13 | 14 | 15 | | 16 | 17 | 18 | 19 | 20 | 21 | 22 | | 23 | 24 | 25 | 26 | 27 | 28 | 29 | | 30 | 31 | | | | | | | Today |
|
AIXpert
