mirror of
https://github.com/xcat2/xcat-core.git
synced 2025-06-16 11:20:32 +00:00
Merge pull request #3015 from whowutwut/remove_openbmc_doc
Remove documentation for OpenBMC under Manage Cluster
This commit is contained in:
Mark Gurevich
GitHub
@ -11,4 +11,3 @@ The sections are organized based on hardware architecture.
|
||||
|
||||
ppc64le/index.rst
|
||||
x86_64/index.rst
|
||||
openbmc/index.rst
|
||||
|
||||
@ -1,9 +0,0 @@
|
||||
Configure passwords
|
||||
===================
|
||||
|
||||
Configure the passwords for Management modules of the compute nodes.
|
||||
|
||||
* For OpenBMC managed systems: ::
|
||||
|
||||
chtab key=openbmc passwd.username=root passwd.password=0penBMC
|
||||
|
||||
@ -1,11 +0,0 @@
|
||||
OpenPOWER (OpenBMC managed)
|
||||
===========================
|
||||
|
||||
The following sections document the procedures in managing OpenPOWER servers in an xCAT cluster.
|
||||
OpenPower servers are machines that use IBM Power Architecture and are **OpenBMC** managed.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
configure.rst
|
||||
openbmc.rst
|
||||
@ -1,60 +0,0 @@
|
||||
Manually Define Nodes
|
||||
=====================
|
||||
|
||||
If admin knows the detailed information of the physical server, ``mkdef`` command can be used to manually define it into xCAT database.
|
||||
|
||||
In this document, the following configuration is used as an example
|
||||
|
||||
Compute Node info::
|
||||
|
||||
CN Hostname: cn1
|
||||
BMC Address: 50.0.101.1
|
||||
OpenBMC username: root
|
||||
OpenBMC Password: 0penBMC
|
||||
|
||||
Run ``mkdef`` command to define the node: ::
|
||||
|
||||
mkdef -t node cn1 groups=openbmc,all mgt=openbmc cons=openbmc bmc=50.0.101.1 bmcusername=root bmcpassword=0penBmc
|
||||
|
||||
The manually defined node will be ::
|
||||
|
||||
# lsdef cn1
|
||||
Object name: cn1
|
||||
bmc=50.0.101.1
|
||||
bmcpassword=0penBmc
|
||||
bmcusername=root
|
||||
cons=openbmc
|
||||
groups=openbmc,all
|
||||
mgt=openbmc
|
||||
postbootscripts=otherpkgs
|
||||
postscripts=syslog,remoteshell,syncfiles
|
||||
|
||||
Hardware Management
|
||||
===================
|
||||
|
||||
Remote Power Control
|
||||
````````````````````
|
||||
|
||||
``rpower`` command can be used to control the power of a remote physical machine. ::
|
||||
|
||||
rpower cn1 on
|
||||
rpower cn1 off
|
||||
rpower cn1 boot
|
||||
rpower cn1 reset
|
||||
|
||||
To get the current rpower state of a machine: ::
|
||||
|
||||
# rpower cn1 state
|
||||
cn1: on
|
||||
|
||||
Remote Console
|
||||
``````````````
|
||||
|
||||
``rcons`` command can be used to get command line remote console.
|
||||
|
||||
#. Make sure the ``conserver`` is configured by running ``makeconservercf cn1``.
|
||||
|
||||
#. Start command line remote console: ::
|
||||
|
||||
rcons cn1
|
||||
|
||||
@ -3,46 +3,45 @@ Configure passwords
|
||||
|
||||
#. Configure the system password for the ``root`` user on the compute nodes.
|
||||
|
||||
* Set using the :doc:`chtab </guides/admin-guides/references/man8/chtab.8>` command: (**Recommended**) ::
|
||||
* Set using the :doc:`chtab </guides/admin-guides/references/man8/chtab.8>` command: ::
|
||||
|
||||
chtab key=system passwd.username=root passwd.password=abc123
|
||||
chtab key=system passwd.username=root passwd.password=abc123
|
||||
|
||||
To encrypt the password using ``openssl``, use the following command: ::
|
||||
To encrypt the password using ``openssl``, use the following command: ::
|
||||
|
||||
chtab key=system passwd.username=root passwd.password=`openssl passwd -1 abc123`
|
||||
|
||||
* Directly edit the passwd table using the :doc:`tabedit </guides/admin-guides/references/man8/tabedit.8>` command.
|
||||
chtab key=system passwd.username=root passwd.password=`openssl passwd -1 abc123`
|
||||
|
||||
|
||||
#. Configure the passwords for Management modules of the compute nodes.
|
||||
|
||||
* For OpenBMC managed systems: ::
|
||||
|
||||
chtab key=openbmc passwd.username=root passwd.password=0penBmc
|
||||
|
||||
* For IPMI/BMC managed systems: ::
|
||||
|
||||
chtab key=ipmi passwd.username=USERID passwd.password=PASSW0RD
|
||||
chtab key=ipmi passwd.username=ADMIN passwd.password=admin
|
||||
|
||||
* For HMC managed systems: ::
|
||||
|
||||
chtab key=hmc passwd.username=hscroot passwd.password=abc123
|
||||
|
||||
The username and password for the HMC can be assigned directly to the HMC node object definition in xCAT. This is needed when the HMC username/password is different for each HMC. ::
|
||||
|
||||
mkdef -t node -o hmc1 groups=hmc,all nodetype=ppc hwtype=hmc mgt=hmc \
|
||||
username=hscroot password=hmcPassw0rd
|
||||
If the username/password is different for multiple HMCs, set the ``username`` and ``password`` attribute for each HMC node object in xCAT
|
||||
|
||||
* For Blade managed systems: ::
|
||||
|
||||
chtab key=blade passwd.username=USERID passwd.password=PASSW0RD
|
||||
|
||||
* For FSP/BPA (Flexible Service Processor/Bulk Power Assembly), if the passwords are set to the factory defaults, you must change them before running and commands to them. ::
|
||||
* For FSP/BPA (Flexible Service Processor/Bulk Power Assembly) the factory default passwords must be changed before running commands against them. ::
|
||||
|
||||
rspconfig frame general_passwd=general,<newpassword>
|
||||
rspconfig frame admin_passwd=admin,<newpassword>
|
||||
rspconfig frame HMC_passwd=,<newpassword>
|
||||
|
||||
|
||||
#. If the REST API is being used configure a user and set a policy rule in xCAT.
|
||||
#. If using the xCAT REST API
|
||||
|
||||
#. Create a non root user that will be used to make the REST API calls. ::
|
||||
#. Create a non-root user that will be used to make the REST API calls. ::
|
||||
|
||||
useradd xcatws
|
||||
passwd xcatws # set the password
|
||||
@ -56,4 +55,4 @@ Configure passwords
|
||||
mkdef -t policy 6 name=xcatws rule=allow
|
||||
|
||||
|
||||
When making calls to the xCAT REST API, pass in the credentials using the following attributes: ``userName`` and ``userPW``
|
||||
When making calls to the xCAT REST API, pass in the credentials using the following attributes: ``userName`` and ``userPW``
|
||||
|
||||
@ -1,8 +1,11 @@
|
||||
IBM Power LE / OpenPOWER
|
||||
=========================
|
||||
|
||||
The following sections documents the procedures in managing IBM Power LE (Little Endian) / OpenPOWER servers in an xCAT cluster.
|
||||
These are machines use the IBM Power Architecture and is **IPMI** managed.
|
||||
Most of the content is general information for xCAT, the focus and examples are for management of IBM OpenPower servers.
|
||||
|
||||
IBM OpenPower Servers
|
||||
* based on Power8 Processor Technology is IPMI managed
|
||||
* based on Power9 Processor Technology is OpenBmc managed [**Alpha**]
|
||||
|
||||
|
||||
.. toctree::
|
||||
@ -10,7 +13,7 @@ These are machines use the IBM Power Architecture and is **IPMI** managed.
|
||||
|
||||
configure/index.rst
|
||||
discovery/index.rst
|
||||
management.rst
|
||||
management/index.rst
|
||||
diskful/index.rst
|
||||
diskless/index.rst
|
||||
statelite/index.rst
|
||||
|
||||
@ -1,124 +0,0 @@
|
||||
Hardware Management
|
||||
===================
|
||||
|
||||
Basic Operation
|
||||
---------------
|
||||
|
||||
The Beacon Light
|
||||
````````````````
|
||||
|
||||
Most of modern enterprise level server machines have LEDs installed on their front panel and/or rear panel, which are called beacon lights. When this light has been turned on, the system administrator can use this light to indicate one physical machine out of a bunch of enclosures in a server frame. It makes life easier.
|
||||
|
||||
With xCAT, the end user can turn the beacon light on or off with the commands show below. ::
|
||||
|
||||
rbeacon cn1 on
|
||||
rbeacon cn1 off
|
||||
|
||||
The current state of the beacon light can not be queried remotely. As a workaround, one can always use the ``rbeacon`` command to turn all the beacon lights in one frame off, and then turn a particular beacon light on. ::
|
||||
|
||||
rbeacon a_group_of_cn off
|
||||
rbeacon cn5 on
|
||||
|
||||
Remote Power Control
|
||||
````````````````````
|
||||
|
||||
The next important thing is to control the power of a remote physical machine. For this purpose, ``rpower`` command is involved. ::
|
||||
|
||||
rpower cn1 on
|
||||
rpower cn1 off
|
||||
|
||||
In order to reboot a remote physical machine, run ::
|
||||
|
||||
rpower cn1 boot
|
||||
|
||||
Or do a hardware reset, run ::
|
||||
|
||||
rpower cn1 reset
|
||||
|
||||
Get the current rpower state of a machine, refer to the example below. ::
|
||||
|
||||
# rpower cn1 state
|
||||
cn1: Running
|
||||
|
||||
Remote Console
|
||||
``````````````
|
||||
|
||||
Most enterprise level servers do not have video adapters installed with the machine. Meaning, the end user can not connect a monitor to the machine and get display output. In most cases, the console can be viewed using the serial port or LAN port, through Serial-over-LAN. Serial cable or network cable are used to get a command line interface of the machine. From there, the end user can get the basic machine booting information, firmware settings interface, local command line console, etc.
|
||||
|
||||
In order to get the command line console remotely. xCAT provides the ``rcons`` command.
|
||||
|
||||
#. Make sure the ``conserver`` is configured by running ``makeconservercf``.
|
||||
|
||||
#. Check if the ``conserver`` is up and running ::
|
||||
|
||||
ps ax | grep conserver
|
||||
|
||||
#. If ``conserver`` is not running, start ::
|
||||
|
||||
[sysvinit] service conserver start
|
||||
[systemd] systemctl start conserver.service
|
||||
|
||||
or restart, if changes to the configuration were made ::
|
||||
|
||||
[sysvinit] service conserver restart
|
||||
[systemd] systemctl restart conserver.service
|
||||
|
||||
|
||||
#. After that, you can get the command line console for a specific machine with the ``rcons`` command ::
|
||||
|
||||
rcons cn1
|
||||
|
||||
Advanced operation
|
||||
------------------
|
||||
|
||||
Remote Hardware Inventory
|
||||
`````````````````````````
|
||||
|
||||
When you have a lot of physical machines in one place, the most important thing is identify which is which. Mapping the model type and/or serial number of a machine with its host name. Command ``rinv`` is involved in such a situation. With this command, most of the important information to distinct one machine from all the others can be obtained remotely.
|
||||
|
||||
To get all the hardware information, which including the model type, serial number, firmware version, detail configuration, et al. ::
|
||||
|
||||
rinv cn1 all
|
||||
|
||||
As an example, in order to get only the information of firmware version, the following command can be used. ::
|
||||
|
||||
rinv cn1 firm
|
||||
|
||||
Remote Hardware Vitals
|
||||
``````````````````````
|
||||
|
||||
Collect runtime information from running physical machine is also a big requirement for real life system administrators. This kind of information includes, temperature of CPU, internal voltage of particular socket, wattage with workload, speed of cooling fan, et al.
|
||||
|
||||
In order to get such information, use ``rvitals`` command. This kind of information varies among different model types of the machine. Thus, check the actual output of the ``rvitals`` command against your machine, to verify which kinds of information can be extracted. The information may change after the firmware update of the machine. ::
|
||||
|
||||
rvitals cn1 all
|
||||
|
||||
As an example, get only the temperature information of a particular machine. ::
|
||||
|
||||
rvitals cn1 temp
|
||||
|
||||
Firmware Updating
|
||||
`````````````````
|
||||
|
||||
For OpenPOWER machines, use the ``rflash`` command to update firmware.
|
||||
|
||||
Check firmware version of the node and the HPM file: ::
|
||||
|
||||
rflash cn1 -c /firmware/8335_810.1543.20151021b_update.hpm
|
||||
|
||||
Update node firmware to the version of the HPM file
|
||||
|
||||
::
|
||||
|
||||
rflash cn1 /firmware/8335_810.1543.20151021b_update.hpm
|
||||
|
||||
Configures Nodes' Service Processors
|
||||
````````````````````````````````````
|
||||
|
||||
Here comes the command, ``rspconfig``. It is used to configure the service processor of a physical machine. On a OpenPower system, the service processor is the BMC, Baseboard Management Controller. Various variables can be set through the command. Also notice, the actual configuration may change among different machine-model types.
|
||||
|
||||
Examples
|
||||
|
||||
To turn on SNMP alerts for cn5: ::
|
||||
|
||||
rspconfig cn5 alert=on
|
||||
@ -0,0 +1,10 @@
|
||||
Advanced Operations
|
||||
===================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
rinv.rst
|
||||
rvitals.rst
|
||||
rflash.rst
|
||||
rspconfig.rst
|
||||
@ -0,0 +1,15 @@
|
||||
``rflash`` - Remote Firmware Flashing
|
||||
=====================================
|
||||
|
||||
See :doc:`rflash manpage </guides/admin-guides/references/man1/rflash.1>` for more information.
|
||||
|
||||
The ``rflash`` command is provided to assist the system administrator in updating firmware.
|
||||
|
||||
To check the current firmware version on the node's BMC and the HPM file: ::
|
||||
|
||||
rflash <noderange> -c /firmware/8335_810.1543.20151021b_update.hpm
|
||||
|
||||
To update the firmware on the node's BMC to version in the HPM file: ::
|
||||
|
||||
rflash <noderange> /firmware/8335_810.1543.20151021b_update.hpm
|
||||
|
||||
@ -0,0 +1,15 @@
|
||||
``rinv`` - Remote Hardware Inventory
|
||||
====================================
|
||||
|
||||
See :doc:`rinv manpage </guides/admin-guides/references/man1/rinv.1>` for more information.
|
||||
|
||||
Use ``rinv`` command to remotely obtain inventory information of a physical machine. This will help to distinguish one machine from another and aid in mapping the model type and/or serial number of a machine with its host name.
|
||||
|
||||
To get all the hardware information for node ``cn1``: ::
|
||||
|
||||
rinv cn1 all
|
||||
|
||||
To get just the firmware information for ``cn1``: ::
|
||||
|
||||
rinv cn1 firm
|
||||
|
||||
@ -0,0 +1,10 @@
|
||||
``rspconfig`` - Remote Configuration of Service Processors
|
||||
==========================================================
|
||||
|
||||
See :doc:`rspconfig manpage </guides/admin-guides/references/man1/rspconfig.1>` for more information.
|
||||
|
||||
The ``rspconfig`` command can be used to configure the service processor, or Baseboard Management Controller (BMC), of a physical machine.
|
||||
|
||||
For example, to turn on SNMP alerts for node ``cn5``: ::
|
||||
|
||||
rspconfig cn5 alert=on
|
||||
@ -0,0 +1,15 @@
|
||||
``rvitals`` - Remote Hardware Vitals
|
||||
====================================
|
||||
|
||||
See :doc:`rvitals manpage </guides/admin-guides/references/man1/rvitals.1>` for more information.
|
||||
|
||||
Collecting runtime information from a running physical machine is an important part of system administration. Data can be obtained from the service processor including temperature, voltage, cooling fans, etc.
|
||||
|
||||
Use the ``rvitals`` command to obtain this information. ::
|
||||
|
||||
rvitals <noderange> all
|
||||
|
||||
To only get the temperature information of machines in a particular noderange: ::
|
||||
|
||||
rvitals <noderange> temp
|
||||
|
||||
@ -0,0 +1,9 @@
|
||||
Basic Operations
|
||||
================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
rbeacon.rst
|
||||
rpower.rst
|
||||
rcons.rst
|
||||
@ -0,0 +1,9 @@
|
||||
``rbeacon`` - Beacon Light
|
||||
==========================
|
||||
|
||||
See :doc:`rbeacon manpage </guides/admin-guides/references/man1/rbeacon.1>` for more information.
|
||||
|
||||
|
||||
Most enterprise level servers have LEDs on their front and/or rear panels, one of which is a beacon light. If turned on, this light can assist the system administrator in locating one physical machine in the cluster.
|
||||
|
||||
Using xCAT, administrators can turn on and off the beacon light using: ``rbeacon <node> on|off``
|
||||
@ -0,0 +1,53 @@
|
||||
``rcons`` - Remote Console
|
||||
==========================
|
||||
|
||||
See :doc:`rcons manpage </guides/admin-guides/references/man1/rcons.1>` for more information.
|
||||
|
||||
Most enterprise servers do not have video adapters installed with the machine and often do not provide a method for attaching a physical monitor/keyboard/mouse to get the display output. For this purpose xCAT can assist the system administrator to view the console over a "Serial-over-LAN" (SOL) connection through the BMC.
|
||||
|
||||
Configure the correct console management by modifying the node definition:
|
||||
|
||||
* For OpenPower, **IPMI** managed server: ::
|
||||
|
||||
chdef -t node -o <noderange> cons=ipmi
|
||||
|
||||
* For OpenPower, **OpenBMC** managed servers: ::
|
||||
|
||||
chdef -t node -o <noderange> cons=openbmc
|
||||
|
||||
Open a console to ``compute1``: ::
|
||||
|
||||
rcons compute1
|
||||
|
||||
**Note:** The keystroke ``ctrl+e c .`` will disconnect you from the console.
|
||||
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
General
|
||||
```````
|
||||
|
||||
The xCAT ``rcons`` command relies on conserver (http://www.conserver.com/). The ``conserver`` package should have been installed with xCAT as it's part of the xCAT dependency package. If you are having problems seeing the console, try the following.
|
||||
|
||||
#. Make sure ``conserver`` is configured by running ``makeconservercf``.
|
||||
|
||||
#. Check if ``conserver`` is up and running ::
|
||||
|
||||
[sysvinit] service conserver status
|
||||
[systemd] systemctl status conserver.service
|
||||
|
||||
#. If ``conserver`` is not running, start the service using: ::
|
||||
|
||||
[sysvinit] service conserver start
|
||||
[systemd] systemctl start conserver.service
|
||||
|
||||
#. After this, try invoking the console again: ``rcons <node>``
|
||||
|
||||
|
||||
OpenBMC Specific
|
||||
```````````````
|
||||
|
||||
#. For OpenBMC managed servers, the root user must be able to ssh passwordless to the BMC for the ``rcons`` function to work.
|
||||
|
||||
Copy the ``/root/.ssh/id_rsa.pub`` public key to the BMC's ``~/.ssh/authorized_keys`` file.
|
||||
@ -0,0 +1,15 @@
|
||||
``rpower`` - Remote Power Control
|
||||
=================================
|
||||
|
||||
See :doc:`rpower manpage </guides/admin-guides/references/man1/rpower.1>` for more information.
|
||||
|
||||
Use the ``rpower`` command to remotely power on and off a single server or a range of servers. ::
|
||||
|
||||
rpower <noderange> on
|
||||
rpower <noderange> off
|
||||
|
||||
Other actions include:
|
||||
|
||||
* To get the current power state of a server: ``rpower <noderange> state``
|
||||
* To boot/reboot a server: ``rpower <noderange> boot``
|
||||
* To hardware reset a server: ``rpower <noderange> reset``
|
||||
@ -0,0 +1,8 @@
|
||||
Hardware Management
|
||||
===================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
basic/index.rst
|
||||
advanced/index.rst
|
||||
Reference in New Issue
Block a user