- 6.1.1 Compute Node Boot Sequence Interrupted by LSI Bios Battery Error
- 6.1.2 Reboot From Oracle Linux Prompt May Cause Management Node to Hang
- 6.1.3 Interruption of iSCSI Connectivity Leads to LUNs Remaining in Standby
- 6.1.4 ILOM Service Processor Clocks Are Out-of-Sync
- 6.1.5 ILOM Firmware Does Not Allow Loopback SSH Access
This section describes hardware-related limitations and workarounds.
When a compute node is powered off for an extended period of time, a week or longer, the LSI BIOS may stop because of a battery error, waiting for the user to press a key in order to continue.
Workaround: Wait for approximately 10 minutes to confirm that the compute node is stuck in boot. Use the Reprovision button in the Oracle Private Cloud Appliance Dashboard to reboot the server and restart the provisioning process.
Bug 16985965
When the reboot command is issued from the Oracle Linux command line on a management node, the operating system could hang during boot. Recovery requires manual intervention through the server ILOM.
Workaround: When the
management node hangs during (re-)boot, log in to the ILOM and
run these two commands in succession: stop -f
/SYS
and start /SYS
. The
management node should reboot normally.
Bug 28871758
If network connectivity between compute nodes and their LUNs is disrupted, it may occur that one or more compute nodes mark one or more iSCSI LUNs as being in standby state. The system cannot automatically recover from this state without operations requiring downtime, such as rebooting VMs or even rebooting compute nodes. The standby LUNs are caused by the specific methods that the Linux kernel and the ZFS Storage Appliance use to handle failover of LUN paths.
Workaround: As the root cause has been identified, an update of the ZFS Storage Appliance firmware is being developed and tested. Until the new firmware is released, customers who have run into issues with missing LUN paths and standby LUNs, are advised not to upgrade Oracle Private Cloud Appliance. The new firmware is likely to be released independently, not as part of the Oracle Private Cloud Appliance Controller Software ISO.
Bug 24522087
Most Oracle Private Cloud Appliance components are equipped with an Oracle Integrated Lights Out Manager (ILOM). Each ILOM Service Processor (SP) contains its own clock, which is synchronized with the operating system (OS) clock before it leaves the factory. However, when new expansion nodes are installed or when parts in a component have been repaired or replaced, SP clocks could be out-of-sync. The problem may also be the result of a configuration error or normal clock drift.
If necessary, the SP clock can be synchronized manually. There is no need to continually update the hardware clock, because it only serves as a reference point for the host OS. Once the systems are up and running the OS obtains the correct time through NTP.
Workaround: After configuring the NTP server in the Oracle Private Cloud Appliance Dashboard, synchronize the ILOM SPs with the OS clock. The easiest way is to log into the host and run this command: hwclock --systohc.
Bug 17664050
In Oracle Integrated Lights Out Manager (ILOM) firmware releases newer than 3.2.4, the
service processor configuration contains a field, called
allowed_services
, to control which services
are permitted on an interface. By default, SSH is not
permitted on the loopback interface. However, Oracle Enterprise Manager uses this
mechanism to register Oracle Private Cloud Appliance management nodes.
Therefore, SSH must be enabled manually if the ILOM version is
newer than 3.2.4.
Workaround: On management
nodes running an ILOM version more recent than 3.2.4, make
sure that SSH is included in the
allowed_services
field of the network
configuration. Log into the ILOM CLI through the
NETMGT
Ethernet port and enter the
following commands:
-> cd /SP/network/interconnect -> set hostmanaged=false -> set allowed_services=fault-transport,ipmi,snmp,ssh -> set hostmanaged=true
Bug 26953763