Information About XCP 1101 Firmware

C H A P T E R 2

This chapter covers updates to XCP firmware in this release as well as other notable changes.

Note - This release is an update of the XCP 1100 firmware. For more information about the XCP 1100 release, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers Product Notes for XCP Version 1100.

What’s New in This Release

The XCP 1101 firmware now supports the M3000 server with 2.86 GHz processors.

This XCP 1101 release introduces support for a new Capacity on Demand (COD) permit delivery system. See Capacity on Demand (COD).

Upgrading and Downgrading XCP

Upgrading to This Release

For information about upgrading your firmware, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.

Note - After upgrading XCP firmware, use the rebootxscf(8) command to reset the XSCF.

Updating the OpenBoot PROM Firmware

To complete updating the OpenBoot PROM (OBP) firmware in the target domain, restart the domain as soon as possible after completing the update.

Upgrading From a Version Earlier Than XCP 1050

If you are currently running a version earlier than XCP 1050, you cannot directly upgrade to this XCP release. You must first upgrade to an interim version of XCP (between 1050 and 1070, inclusive). Contact your Oracle representative for access to older XCP releases.

Note - Use the deleteuser(8) command to delete any accounts named admin prior to updating to XCP 1050 or later. The admin account name is reserved starting in XCP 1050.

Domain Restart Required After Certain Type of XCP Upgrade

On a domain that has been in operation during an update from an XCP version between XCP 1050 and 1070 (inclusive), when you perform dynamic reconfiguration (DR) to add or replace the SPARC64 VII processors, you need to update the OpenBoot PROM firmware. The OpenBoot PROM firmware is updated as you update the XCP and restart the domain. For this reason, restart all the domains after you update the firmware to the latest XCP release, regardless of whether you added or replaced the SPARC64 VII processors.

Downgrading XCP Firmware

Downgrading your XCP firmware to an earlier release would remove improvements and corrections provided in the latest release and could lead to a system failure due to mismatched dependencies. However, if you must downgrade your XCP release, execute the following command afterward to clear old-style audit logs:

XSCF> restoredefaults -c xscfu

XCP Functionality Issues and Limitations

This section describes known XCP firmware issues.

Note - Do not use the Service Processor (SP) as the Network Time Protocol (NTP) server. Using an independent NTP server provides optimal reliability in maintaining consistent time on the SP and the domains. For more information about NTP, see the Sun Blueprint document, Using NTP to Control and Synchronize System Clocks: http://www.sun.com/blueprints/0701/NTP.pdf

TABLE 2-1 XCP Functionality Issues and Limitations
M3000	M4000/M5000	M8000/M9000	Issue
o	o	o	You cannot use the following user account names, as they are reserved for system use: `adm`, `admin`, `apache`, `bin`, `daemon`, `default`, `ldap`, `nobody`, `ntp`, `operator`, `proxyuser`, `root`, `rpc`, `rpcuser`, and `sshd`. See Remote Initial Login
o	o	o	An XSCF user account user name cannot match an LDAP user name, and an XSCF user account number (UID) cannot match an LDAP UID number.
o	o	o	When you import XCP or update the firmware using the XSCF, you might see Web session ID errors displayed on the web browser. When you specify the timeout period as over 30 minutes in the Autologout setting, Internal Server Errors might be displayed. To reconnect to the XSCF Web, close the current browser and open the new browser.
o	o	o	Before using the XSCF Web, disable pop-up blocking and remove any plug-ins such as the search tool installed with the browser.
o	o	o	XSCF-LAN is compliant with auto-negotiation. Set the network device that connects with XSCF-LAN to the auto-negotiation mode. Otherwise when you connect the XSCF-LAN and the network device (fixed to the full-duplex mode, according to the IEEE 802.3 rule) the XSCF-LAN communicates in half-duplex mode and network communication speed might slow down or communication errors might occur.
	o	o	For this XCP release, the XSCF browser user interface (XSCF Web) does not support the External I/O Expansion Unit Manager feature.
	o	o	Due to DR and ZFS file system interoperability issues, M4000/M5000 servers are shipped pre-installed using the UFS file system. See CR 6522017 in TABLE 3-2.
o	o	o	The XCP 1093 release was the first XCP release to support a domain running Oracle Solaris 10 9/10 with the processor groups observability feature enabled. Please refer to Oracle Solaris 10 9/10 OS Product Notes for more information.

XCP Known Issues (CRs) and Workarounds

This section lists significant CRs and, if available, suggested workarounds,

TABLE 2-2 XCP Issues and Workarounds
CR ID	M3000	M4000/ M5000	M8000/ M9000	Description	Workaround
7009084	o	o	o	If `setpasswordpolicy` `-r` is set to 0, existing XCSF users are unable to change their password and get the error message, `password: Operation failed`	Do not execute the command: `setpasswordpolicy` `-r 0` See the entry for this command in TABLE 3-9.
7012224	o	o	o	On occasion, messages similar to the following might appear on the domain console during OS reboot or shutdown: Nov 30 16:56:36 sca-m5k-3-a ip: ipsec_check_inbound_policy: Policy Failure for the incoming packet (not secure); Source 192.168.224.001, Destination 192.168.224.002. Such messages from the OS are informational only. You can safely ignore them.	Ignore the alarms.
7018644	o	o		Faults marked as REPAIRED/RESOLVED on a domain are resent to the XSCF each time the domain is rebooted or the XSCF is rebooted. If the XSCF is not replaced, this is not a problem and no new fault is generated. However, if the XSCF on M4000/M5000 servers or the MBU on M3000 servers is replaced, a new fault for the resolved problem might be generated.	When a new fault is generated after the XSCF or MBU is replaced, check the `solaris -u uid` in `fmdump -V` output to determine if the fault is genuine.
7020161	o			In M3000 servers with SPARC64 VII+ (2.86 GHz processors), `Permitted AC power consumption` is shown as 470W. The correct value is 505W.	There is no workaround.