xCAT/xcat-core
2
0
Fork 0
mirror of https://github.com/xcat2/xcat-core.git synced 2025-06-22 14:05:32 +00:00
Code Issues Releases Wiki Activity

Merge branch 'master' into mvlan

Browse Source
This commit is contained in:
cxhong
2017-06-06 15:41:10 -04:00
committed by GitHub
parent dbf52b4be7 d1b1773902
commit 36fbee6d92
181 changed files with 5495 additions and 2166 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
.mailmap Normal file
View File

@ -0,0 +1,69 @@
BAI Yuan <bybai@cn.ibm.com>
Bruce Potter <bp@us.ibm.com>
CAO Li <caoli@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
CAO Meng Meng <bjcaomm@cn.ibm.com>
CAO Meng Meng <caomengmeng@users.noreply.github.com>
CAO Meng Meng <caomengmeng_1011@sina.com>
Casandra Qiu <cxhong@us.ibm.com> <abcdqiu@gmail.com>
Casandra Qiu <cxhong@us.ibm.com>
CHENG Long <chenglch@cn.ibm.com>
CHU De Gao <degaochu@cn.ibm.com> <chudegao@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
CHU De Gao <degaochu@cn.ibm.com>
CHU De Gao <degaochu@cn.ibm.com> <degaochu@ibm.com.cn>
GAO Feng <gfgaogf@cn.ibm.com>
GAO Ling <linggao@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
GAO Ling <linggao@us.ibm.com>
GONG Jie <gongjie@cn.ibm.com>
GONG Jie <gongjie@cn.ibm.com> <gongjie.jie@gmail.com>
GONG Jie <gongjie@cn.ibm.com> <gongjie@linux.vnet.ibm.com>
HU Wei Hua <huweihua@cn.ibm.com>
Jarrod Johnson <jarrod.b.johnson@gmail.com>
Jarrod Johnson <jbjohnso@us.ibm.com>
Jarrod Johnson <jjohnson2@buildabear.labs.lenovo.com>
Jarrod Johnson <jjohnson2@lenovo.com>
JIN Jie Hua <jinjhua@cn.ibm.com>
JIN Jie Hua <jjhua@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
LI Guang Cheng <liguangc@cn.ibm.com>
LI Guang Cheng <liguangc@cn.ibm.com> <ligc@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
LI Guang Cheng <liguangc@cn.ibm.com> <ligc@cn.ibm.com>
LI Ting Ting <litingt@cn.ibm.com>
Linda O. Mellor <mellor@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
Linda O. Mellor <mellor@us.ibm.com>
Lissa Valletta <lissav@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
Lissa Valletta <lissav@us.ibm.com>
Mark Gurevich <gurevich@us.ibm.com>
Mark Gurevich <gurevich@us.ibm.com> <gurevich@c910loginx01.(none)>
Norm Nott <nott@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
Norm Nott <nott@us.ibm.com>
Patrick Lundgren <plundgr@us.ibm.com>
Patrick Lundgren <plundgr@us.ibm.com> <pdlun92@gmail.com>
Patrick Lundgren <plundgr@us.ibm.com> <plundgr@c910loginx01.(none)>
SUN Jing <sjing@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
SUN Jing <sjing@cn.ibm.com>
Victor Hu <vhu@us.ibm.com>
Victor Hu <vhu@us.ibm.com> <vhu@victorvm7.pok.ibm.com>
Victor Hu <vhu@us.ibm.com> <whowutwut@gmail.com>
WANG Hua Zhong <wanghuaz@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
WANG Hua Zhong <wanghuaz@cn.ibm.com>
WANG Jun Xia <junxiaw@cn.ibm.com>
WANG Xiao Peng <wxp@cn.ibm.com>
WANG Xiao Peng <wxp@cn.ibm.com> <daniceexi@163.com>
WANG Xiao Peng <wxp@cn.ibm.com> <daniceexi@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
WANG Xiao Peng <wxp@cn.ibm.com> <daniceexi@users.noreply.github.com>
WANG Xiao Peng <wxp@cn.ibm.com> <root@idplex02.(none)>
WU Xian <xwuxwu@cn.ibm.com>
XU Bin <bxuxa@cn.ibm.com>
XU Bin <bxuxa@cn.ibm.com> <robin.hsu@163.com>
XU Qing <qxuqxu@cn.ibm.com>
XU Qing <qxuqxu@cn.ibm.com> <xq2005@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
XU Wei <xwbj@cn.ibm.com>
YANG Peng <ypbj@cn.ibm.com>
YANG Song <yangsbj@cn.ibm.com>
YANG Song <yangsbj@cn.ibm.com> <immarvin@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
YANG Song <yangsbj@cn.ibm.com> <immarvin@users.noreply.github.com>
YANG Song <yangsbj@cn.ibm.com> <yangsbj@cn.ibm.comq>
YIN Le <yinle@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>
YIN Le <yinle@cn.ibm.com>
ZHAO Er Tao <ertaozh@cn.ibm.com>
ZHAO Er Tao <ertaozh@cn.ibm.com> <ertaozh@cn.ibm.comls>
ZHAO Er Tao <ertaozh@cn.ibm.com> <zhaoertao@8638fb3e-16cb-4fca-ae20-7b5d299a9bcd>

7
README.rst
View File

@ -8,7 +8,7 @@ Documentation
xCAT documentation is available at: http://xcat-docs.readthedocs.io/en/latest/
|docs_latest| |docs_2133| |docs_2132| |docs_2131| |docs_2130| |docs_212| |docs_211|
|docs_latest| |docs_2134| |docs_2133| |docs_2132| |docs_2131| |docs_2130| |docs_212|
Open Source License
-------------------
@ -22,6 +22,11 @@ Developers
Developers and prospective contributors are encouraged to read the `Developers Guide <http://xcat-docs.readthedocs.io/en/latest/developers/>`_
In particular the `GitHub <http://xcat-docs.readthedocs.io/en/latest/developers/github/>`_ related subsection.
.. |docs_2134| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.4
:alt: 2.13.4 documentation status
:scale: 100%
:target: http://xcat-docs.readthedocs.io/en/2.13.4/
.. |docs_2133| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.3
:alt: 2.13.3 documentation status
:scale: 100%

2
Version
View File

@ -1 +1 @@
2.13.4
2.13.5

5
docs/README.md
View File

@ -2,11 +2,6 @@
The latest docs are here: http://xcat-docs.readthedocs.io/en/latest/
Status:
[![Documentation Status](http://readthedocs.org/projects/xcat-docs/badge/?version=latest)](http://xcat-docs.readthedocs.io/en/latest/?badge=latest)
[![Documentation Status](http://readthedocs.org/projects/xcat-docs/badge/?version=2.11)](http://xcat-docs.readthedocs.io/en/2.11/?badge=2.11)
The documentation project is written in restructured text (.rst) using Sphinx and hosted on ReadTheDocs.
## Building Documentation

2
docs/source/advanced/cluster_maintenance/compute_node/changing_hostname_ip.rst
View File

@ -25,7 +25,7 @@ Remove Old Provision Environment
Change Definition
-----------------
#. Change netwoks table definitions ::
#. Change networks table definitions ::
lsdef -t network -l

4
docs/source/advanced/cluster_maintenance/compute_node/replace/openpower.rst
View File

@ -1,10 +1,10 @@
OpenPower Nodes
OpenPOWER Nodes
===============
When compute nodes are physically replaced in the frame, leverage xCAT to re-discover the compute nodes. The following guide can be used for:
* IBM OpenPower S822LC for HPC
* IBM OpenPOWER S822LC for HPC
#. Identify the machine(s) to be replaced: ``frame10cn02``.

2
docs/source/advanced/domain_name_resolution/domain_name_resolution.rst
View File

@ -480,6 +480,6 @@ Sample table contents: ::
Limited support for user application networks
---------------------------------------------
In some cases you may have additional user application networks in your site that are not specifically used for cluster management.If desired you can create xCAT network definitions for these networks.This not only provides a convenient way to keep track of the network details but the information can also be used to help set up name resolution for these networks on the cluster nodes.When you add a network definition that includes a **"domain"** value then that domain is automatically included the xCAT name resolution set up. This will enable the nodes to be able to resolve hostnames from the other domains.
In some cases you may have additional user application networks in your site that are not specifically used for cluster management. If desired you can create xCAT network definitions for these networks. This not only provides a convenient way to keep track of the network details but the information can also be used to help set up name resolution for these networks on the cluster nodes. When you add a network definition that includes a **"domain"** value then that domain is automatically included the xCAT name resolution set up. This will enable the nodes to be able to resolve hostnames from the other domains.
For example, when you run ``makedhcp -n`` it will list all domains defined in the xCAT **"site"** definition and xCAT **"network"** definitions in the **"option domain-search"** entry of the shared-network stanza in the dhcp configuration file. This will cause dhcp to put these domains in the compute nodes' **/etc/resolv.conf** file every time it gets a dhcp lease.

2
docs/source/advanced/gpu/nvidia/osimage/index.rst
View File

@ -1,7 +1,7 @@
Create osimage definitions
==========================
Generate ``osimage`` definitions to provison the compute nodes with the NVIDIA CUDA toolkit installed.
Generate ``osimage`` definitions to provision the compute nodes with the NVIDIA CUDA toolkit installed.
.. toctree::
:maxdepth: 2

4
docs/source/advanced/hamn/high_available_management_node.rst
View File

@ -13,7 +13,7 @@ The data synchronization is important for any high availability configuration. W
* The configuration files for the services that are required by xCAT, like named, DHCP, apache, nfs, ssh, etc.
* The operating systems images repository and users customization data repository, the ``/install`` directory contains these repositories in most cases.
There are a lot of ways for data synchronization, but considering the specific xCAT HAMN requirements, only several of the data synchronziation options are practical for xCAT HAMN.
There are a lot of ways for data synchronization, but considering the specific xCAT HAMN requirements, only several of the data synchronization options are practical for xCAT HAMN.
**1\. Move physical disks between the two management nodes**: if we could physically move the hard disks from the failed management node to the backup management node, and bring up the backup management node, then both the operating system and xCAT data will be identical between the new management node and the failed management node. RAID1 or disk mirroring could be used to avoid the disk be a single point of failure.
@ -40,7 +40,7 @@ The configuration for the high availability applications is usually complex, it
**3\. Maintenance effort**
The automatic failover brings in several high availability applications, after the initial configuration is done, additional maintenance effort will be needed. For example, taking care of the high availability applications during cluster update, the updates for the high availability applications themselves, trouble shooting any problems with the high availability applications. A simple question may be able to help you to decide: could you get technical support if some of the high availability applications run into problems? All software has bugs.
The automatic failover brings in several high availability applications, after the initial configuration is done, additional maintenance effort will be needed. For example, taking care of the high availability applications during cluster update, the updates for the high availability applications themselves, troubleshooting any problems with the high availability applications. A simple question may be able to help you to decide: could you get technical support if some of the high availability applications run into problems? All software has bugs.
Configuration Options
=====================

20
docs/source/advanced/hamn/setup_ha_mgmt_node_with_drbd_pacemaker_corosync.rst
View File

@ -31,7 +31,7 @@ Configuration Requirements
#. Since the management node needs to provide IP services through broadcast such as DHCP to the compute nodes, the primary management node and standby management node should be in the same subnet to ensure the network services will work correctly after failover.
#. Network connections between the two management nodes: there are several networks defined in the general cluster configuration strucutre, like cluster network, management network and service network; the two management nodes should be in all of these networks(if exist at all). Besides that, it is recommended, though not strictly required, to use a direct, back-to-back, Gigabit Ethernet or higher bandwidth connection for the DRBD, Pacemaker and Corosync communication between the two management nodes. If the connection is run over switches, use of redundant components and the bonding driver (in active-backup mode) is recommended.
#. Network connections between the two management nodes: there are several networks defined in the general cluster configuration structure, like cluster network, management network and service network; the two management nodes should be in all of these networks(if exist at all). Besides that, it is recommended, though not strictly required, to use a direct, back-to-back, Gigabit Ethernet or higher bandwidth connection for the DRBD, Pacemaker and Corosync communication between the two management nodes. If the connection is run over switches, use of redundant components and the bonding driver (in active-backup mode) is recommended.
``Note``: A crossover Ethernet cable is required to setup the direct, back-to-back, Ethernet connection between the two management nodes, but with most of the current hardware, a normal Ethernet cable can also work, the Ethernet adapters will internally handle the crossover bit. Hard disk for DRBD: DRBD device can be setup on a partition of the disk that the operating system runs on, but it is recommended to use a separate standalone disk or RAID/Multipath disk for DRBD configuration.
@ -63,7 +63,7 @@ You have several options to get the RPM packages for ``DRBD``, ``drbdlinks``, ``
#. Compile from source code: if none of the options work for some specific applications, you will have to compile RPMs from the source code. You can compile these packages on one of the management node or on a separate build machine with the same arch and operating system with the management nodes. Here are the instructions for compiling the RPM packages from source code:
Before compiling the RPM packages, you need to install some compling tools like gcc, make, glibc, rpm-build. ::
Before compiling the RPM packages, you need to install some compiling tools like gcc, make, glibc, rpm-build. ::
yum groupinstall "Development tools"
yum install libxslt libxslt-devel
@ -402,13 +402,13 @@ Configure DRBD
[>....................] sync'ed: 0.5% (101932/102400)M
finish: 2:29:06 speed: 11,644 (11,444) K/sec
If a direct, back-to-back Gigabyte Ethernet connection is setup between the two management nodes and you are unhappy with the syncronization speed, it is possible to speed up the initial synchronization through some tunable parameters in DRBD. This setting is not permanent, and will not be retained after boot. For details, see http://www.drbd.org/users-guide-emb/s-configure-sync-rate.html. ::
If a direct, back-to-back Gigabyte Ethernet connection is setup between the two management nodes and you are unhappy with the synchronization speed, it is possible to speed up the initial synchronization through some tunable parameters in DRBD. This setting is not permanent, and will not be retained after boot. For details, see http://www.drbd.org/users-guide-emb/s-configure-sync-rate.html. ::
drbdadm disk-options --resync-rate=110M xCAT
#. Create file system on DRBD device and mount the file system
Even while the DRBD sync is taking place, you can go ahead and create a filesystem on the DRBD device, but it is recommended to wait for the inital full synchronization is finished before creating the file system.
Even while the DRBD sync is taking place, you can go ahead and create a filesystem on the DRBD device, but it is recommended to wait for the initial full synchronization is finished before creating the file system.
After the initial full synchronization is finished, you can take the DRBD device as a normal disk partition to create file system and mount it to some directory. The DRDB device name is set in the ``/etc/drbd.d/xcat.res`` created in the previous step. In this doc, the DRBD device name is ``/dev/drbd1``. ::
@ -964,7 +964,7 @@ At this point, the HA MN Setup is complete, and customer workloads and system ad
Failover
========
There are two kinds of failover, planned failover and unplanned failover. The planned failover can be useful for updating the management nodes or any scheduled maintainance activities; the unplanned failover covers the unexpected hardware or software failures.
There are two kinds of failover, planned failover and unplanned failover. The planned failover can be useful for updating the management nodes or any scheduled maintenance activities; the unplanned failover covers the unexpected hardware or software failures.
In a planned failover, you can do necessary cleanup work on the previous primary management node before failover to the previous standby management node. In a unplanned failover, the previous management node probably is not functioning at all, you can simply shutdown the system.
@ -1009,7 +1009,7 @@ To avoid this, run the following command to set the autostart for the corosync s
Backup working Pacemaker configuration (Optional)
=================================================
It is a good practice to backup the working ``pacemaker`` configuration, the backup could be in both plain text format or XML format, the plain text is more easily editable and can be modified and used chunk by chunk, the xml can be used to do a full replacement restore. It will be very useful to make such a backup everytime before you make a change.
It is a good practice to backup the working ``pacemaker`` configuration, the backup could be in both plain text format or XML format, the plain text is more easily editable and can be modified and used chunk by chunk, the xml can be used to do a full replacement restore. It will be very useful to make such a backup every time before you make a change.
To backup in the plain text format, run the following command: ::
@ -1182,7 +1182,7 @@ Trouble shooting and debug tips
Disable HA MN
=============
For whatever reason, the user might want to disable HA MN, here is the procedur of disabling HA MN:
For whatever reason, the user might want to disable HA MN, here is the procedure of disabling HA MN:
* Shut down standby management node
@ -1245,7 +1245,7 @@ Finally we commit the changes that are in xcat_cfg into the live system: ::
pcs cluster push cib xcat_cfg
We then need to make sure that the ``/xCATdrbd/etc/drbdlinks.xCAT.conf`` file has the systemimager portion uncommented, and re-do the initialisation of drbdlinks as they have been done earlier in the documentation
We then need to make sure that the ``/xCATdrbd/etc/drbdlinks.xCAT.conf`` file has the systemimager portion uncommented, and re-do the initialization of drbdlinks as they have been done earlier in the documentation
Appendix A
==========
@ -1428,7 +1428,7 @@ Finally we commit the changes that are in xcat_cfg into the live system: ::
pcs cluster cib-push xcat_cfg
Once the changes have been commited, we can view the config, by running the command below: ::
Once the changes have been committed, we can view the config, by running the command below: ::
pcs config
@ -1640,7 +1640,7 @@ Finally we commit the changes that are in xcat_cfg into the live system: ::
pcs cluster cib-push xcat_cfg
Once the changes have been commited, we can view the config, by running the command below: ::
Once the changes have been committed, we can view the config, by running the command below: ::
pcs config

10
docs/source/advanced/hamn/setup_ha_mgmt_node_with_shared_data.rst
View File

@ -18,9 +18,9 @@ The nfs service on the primary management node or the primary management node it
What is Shared Data
====================
The term ``Shared Data`` means that the two management nodes use a single copy of xCAT data, no matter which management node is the primary MN, the cluster management capability is running on top of the single data copy. The acess to the data could be done through various ways like shared storage, NAS, NFS, samba etc. Based on the protocol being used, the data might be accessable only on one management node at a time or be accessable on both management nodes in parellel. If the data could only be accessed from one management node, the failover process need to take care of the data access transition; if the data could be accessed on both management nodes, the failover does not need to consider the data access transition, it usually means the failover process could be faster.
The term ``Shared Data`` means that the two management nodes use a single copy of xCAT data, no matter which management node is the primary MN, the cluster management capability is running on top of the single data copy. The access to the data could be done through various ways like shared storage, NAS, NFS, samba etc. Based on the protocol being used, the data might be accessible only on one management node at a time or be accessible on both management nodes in parallel. If the data could only be accessed from one management node, the failover process need to take care of the data access transition; if the data could be accessed on both management nodes, the failover does not need to consider the data access transition, it usually means the failover process could be faster.
``Warning``: Running database through network file system has a lot of potential problems and is not practical, however, most of the database system provides database replication feature that can be used to synronize the database between the two management nodes
``Warning``: Running database through network file system has a lot of potential problems and is not practical, however, most of the database system provides database replication feature that can be used to synchronize the database between the two management nodes
Configuration Requirements
==========================
@ -248,7 +248,7 @@ Besides the files mentioned above, there may be some additional customization fi
``Note``:
If the IBM HPC software stack is configured in your environment, execute additional steps required to copy additional data or configuration files for HAMN setup.
The dhcpsd.cnf should be syncronized between the primary management node and standby management node only when the DHCP configuration on the two management nodes are exactly the same.
The dhcpsd.cnf should be synchronized between the primary management node and standby management node only when the DHCP configuration on the two management nodes are exactly the same.
Cluster Maintenance Considerations
==================================
@ -268,7 +268,7 @@ At this point, the HA MN Setup is complete, and customer workloads and system ad
Failover
========
There are two kinds of failover, planned failover and unplanned failover. The planned failover can be useful for updating the management nodes or any scheduled maintainance activities; the unplanned failover covers the unexpected hardware or software failures.
There are two kinds of failover, planned failover and unplanned failover. The planned failover can be useful for updating the management nodes or any scheduled maintenance activities; the unplanned failover covers the unexpected hardware or software failures.
In a planned failover, you can do necessary cleanup work on the previous primary management node before failover to the previous standby management node. In a unplanned failover, the previous management node probably is not functioning at all, you can simply shutdown the system.
@ -367,7 +367,7 @@ On the new primary management node:
**DNS**: run ``makedns``. Verify dns services working for node resolution. Make sure the line ``nameserver=<virtual ip>`` is in ``/etc/resolv.conf``.
**DHCP**: if the dhcpd.leases is not syncronized between the primary management node and standby management node, run ``makedhcp -a`` to setup the DHCP leases. Verify dhcp is operational.
**DHCP**: if the dhcpd.leases is not synchronized between the primary management node and standby management node, run ``makedhcp -a`` to setup the DHCP leases. Verify dhcp is operational.
**conserver**: run makeconservercf. This will recreate the ``/etc/conserver.cf`` config files for all the nodes.

2
docs/source/advanced/hierarchy/appendix/appendix_b_diagnostics.rst
View File

@ -15,4 +15,4 @@ Appendix B: Diagnostics
* **Errors running hierarchical commands such as xdsh** -- xCAT has a number of commands that run hierarchically. That is, the commands are sent from xcatd on the management node to the correct service node xcatd, which in turn processes the command and sends the results back to xcatd on the management node. If a hierarchical command such as xcatd fails with something like "Error: Permission denied for request", check ``/var/log/messages`` on the management node for errors. One error might be "Request matched no policy rule". This may mean you will need to add policy table entries for your xCAT management node and service node.
* **/install is not mounted on service node from managemen mode** -- If service node does not have ``/install`` directory mounted from management node, run ``lsdef -t site clustersite -i installloc`` and verify ``installloc="/install"``
* **/install is not mounted on service node from management mode** -- If service node does not have ``/install`` directory mounted from management node, run ``lsdef -t site clustersite -i installloc`` and verify ``installloc="/install"``

2
docs/source/advanced/hierarchy/databases/postgres_configure.rst
View File

@ -33,4 +33,4 @@ Restart PostgreSQL after editing the file: ::
For more information about changing the ``pg_hab.conf`` file and ``postgresql.conf`` files, see the following documentation:
`Setup the PostgreSQL Configuraion Files <https://sourceforge.net/p/xcat/wiki/Setting_Up_PostgreSQL_as_the_xCAT_DB/#setup-the-postgresql-configuration-files>`_
`Setup the PostgreSQL Configuration Files <https://sourceforge.net/p/xcat/wiki/Setting_Up_PostgreSQL_as_the_xCAT_DB/#setup-the-postgresql-configuration-files>`_

2
docs/source/advanced/hierarchy/define_service_node.rst
View File

@ -179,7 +179,7 @@ compute node is rebooted or the compute node is explicitly moved to another SN
using the `snmove <http://localhost/fake_todo>`_ command.
To use Service Node pools, you need to architect your network such that all of
the compute nodes and service nodes in a partcular pool are on the same flat
the compute nodes and service nodes in a particular pool are on the same flat
network. If you don't want the management node to respond to manage some of
the compute nodes, it shouldn't be on that same flat network. The
site, dhcpinterfaces attribute should be set such that the SNs' DHCP daemon

2
docs/source/advanced/kit/custom/build/createkit.rst
View File

@ -112,7 +112,7 @@ minor version can be support following format: ::
**kitpackage** --- This stanza defines Kit Package (ie. RPM). There can be zero or more kitpackage stanzas. For multiple package supports, need to
#. Define one kitpackage section per supported OS. or
#. Define one kitpacakge stanza which contains multiple kitrepoid lines. For the RPM packages, users need to responsible for createing an RPM spec file that can run on multiple OSes.
#. Define one kitpacakge stanza which contains multiple kitrepoid lines. For the RPM packages, users need to responsible for creating an RPM spec file that can run on multiple OSes.
::

4
docs/source/advanced/kit/custom/introduction.rst
View File

@ -49,7 +49,7 @@ Kit Framework
With time, the implementation of the xCAT Software Kit support may change.
In order to process a kit successfully, the kit must be conpatiable with the level of xCAT code that was used to build the kit. The xCAT kit commands and software kits contain the framework version and compatiable supported versions.
In order to process a kit successfully, the kit must be compatible with the level of xCAT code that was used to build the kit. The xCAT kit commands and software kits contain the framework version and compatible supported versions.
To view the framework version, use the ``-v | --version`` option on :doc:`addkit </guides/admin-guides/references/man1/addkit.1>` ::
@ -59,7 +59,7 @@ To view the framework version, use the ``-v | --version`` option on :doc:`addkit
compatible_frameworks = 0,1,2
If the commands in the xCAT installation is not compatiable with the Software Kit obtained, update xCAT to a more recent release.
If the commands in the xCAT installation is not compatible with the Software Kit obtained, update xCAT to a more recent release.
.. [#] PCM is IBM Platform Cluster Manager

4
docs/source/advanced/kit/custom/using/addkitcomp.rst
View File

@ -14,7 +14,7 @@ To check if a kitcomponent is valid for an existing OS image definition run the
chkkitcomp -i <osimage> <kitcompname>
If the kit component is compatible then add the kitcomponent to the OS image defintion using the addkitcomp command. ::
If the kit component is compatible then add the kitcomponent to the OS image definition using the addkitcomp command. ::
addkitcomp -a -i <osimage> <kitcompname>
@ -34,7 +34,7 @@ The contents of the kit component may be listed by using the lskitcomponent comm
Adding Multiple Versions of the Same Kit Component to an OS Image Definition
`````````````````````````````````````````````````````````````````````````````
xCAT allows to have multiple versions/releases of a product software kit available in the cluster. Typically, different OS image definitions corresponding to the different versions/releases of a product software stack. However, in some instances, may need mulitple versions/releases of the same product available within a single OS image. This is only feasible if the software product supports the install of multiple versions or releases of its product within an OS image.
xCAT allows to have multiple versions/releases of a product software kit available in the cluster. Typically, different OS image definitions corresponding to the different versions/releases of a product software stack. However, in some instances, may need multiple versions/releases of the same product available within a single OS image. This is only feasible if the software product supports the install of multiple versions or releases of its product within an OS image.
Currently, it is not possible to install multiple versions of a product into an OS image using xCAT commands. xCAT uses yum on RedHat and zypper on SLES to install product rpms. These package managers do not provide an interface to install different versions of the same package, and will always force an upgrade of the package. We are investigating different ways to accomplish this function for future xCAT releases.

4
docs/source/advanced/kit/hpc/quickstart.rst
View File

@ -77,7 +77,7 @@ The following software kits will be used to install the IBM HPC software stack o
The ESSL software kit has an *external dependency* to the ``libxlf`` which is provided in the XLF software kit. Since it's already added in the above step, there is no action needed here.
If CUDA toolkit is being used, ESSL has a runtime dependency on the CUDA rpms. The adminstrator needs to create the repository for the CUDA 7.5 toolkit or a runtime error will occur when provisioning the node. See the :doc:`/advanced/gpu/nvidia/repo/index` section for more details about setting up the CUDA repository on the xCAT management node. ::
If CUDA toolkit is being used, ESSL has a runtime dependency on the CUDA rpms. The administrator needs to create the repository for the CUDA 7.5 toolkit or a runtime error will occur when provisioning the node. See the :doc:`/advanced/gpu/nvidia/repo/index` section for more details about setting up the CUDA repository on the xCAT management node. ::
#
# Assuming that the cuda repo has been configured at:
@ -101,7 +101,7 @@ The following software kits will be used to install the IBM HPC software stack o
addkitcomp -a -i rhels7.2-ppc64le-install-compute \
essl-computenode-3264rtecuda-5.4.0-0-rhels-7.2-ppc64le
If the system doesn't have GPU and the CUDA toolkit is not needed, the adminstrator should not add the following kit components that requires the CUDA packages: ``essl-loginnode-5.4.0-0-rhels-7.2-ppc64le``, ``essl-computenode-3264rte-5.4.0-0-rhels-7.2-ppc64le`` and ``essl-computenode-3264rtecuda-5.4.0-0-rhels-7.2-ppc64le``. Check the ESSL installation guide: http://www.ibm.com/support/knowledgecenter/SSFHY8_5.4.0/com.ibm.cluster.essl.v5r4.essl300.doc/am5il_xcatinstall.htm
If the system doesn't have GPU and the CUDA toolkit is not needed, the administrator should not add the following kit components that requires the CUDA packages: ``essl-loginnode-5.4.0-0-rhels-7.2-ppc64le``, ``essl-computenode-3264rte-5.4.0-0-rhels-7.2-ppc64le`` and ``essl-computenode-3264rtecuda-5.4.0-0-rhels-7.2-ppc64le``. Check the ESSL installation guide: http://www.ibm.com/support/knowledgecenter/SSFHY8_5.4.0/com.ibm.cluster.essl.v5r4.essl300.doc/am5il_xcatinstall.htm
#. Add the **Parallel ESSL** kitcomponents to osimage.

2
docs/source/advanced/mixed_cluster/building_stateless_images.rst
View File

@ -1,7 +1,7 @@
Building Stateless/Diskless Images
==================================
A **stateless**, or **diskless**, provisioned nodes is one where the operating system image is deployed and loaded into memory. The Operating System (OS) does not store its files directly onto persistent storage (i.e hard disk drive, shared drive, usb, etc) and so subsequent rebooting of the machine results in loss of any state changes that happened while the machine was running.
A **stateless**, or **diskless**, provisioned nodes is one where the operating system image is deployed and loaded into memory. The Operating System (OS) does not store its files directly onto persistent storage (i.e. hard disk drive, shared drive, usb, etc) and so subsequent rebooting of the machine results in loss of any state changes that happened while the machine was running.
To deploy stateless compute nodes, you must first create a stateless image. The "netboot" osimages created from ``copycds`` in the **osimage** table are sample osimage definitions that can be used for deploying stateless nodes.

2
docs/source/advanced/networks/infiniband/firmware_updates.rst
View File

@ -21,7 +21,7 @@ Burn new firmware on each ibaX: ::
mstflint -d 0002:01:00.0 -i <image location> b
Note: if this is a PureFlex MezzanineP adapater then you must select the correct image for each ibaX device. Note the difference in the firmware image at end of filename: _0.bin (iba0/iba2) & _1.bin (iba1/iba3)
Note: if this is a PureFlex MezzanineP adapter then you must select the correct image for each ibaX device. Note the difference in the firmware image at end of filename: _0.bin (iba0/iba2) & _1.bin (iba1/iba3)
Verify download successful: ::

2
docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2.rst
View File

@ -1,7 +1,7 @@
Mellanox OFED Installation Script
=================================
Mellanox provides a tested and packaged version of the OpenFabrics Enterprise Distribution (OFED) driver, named Mellanox OFED (MLNX_OFED). To assist with the installation of the MLNX_OFED driver, xCAT provids a sample postscript: ``mlnxofed_ib_install.v2``.
Mellanox provides a tested and packaged version of the OpenFabrics Enterprise Distribution (OFED) driver, named Mellanox OFED (MLNX_OFED). To assist with the installation of the MLNX_OFED driver, xCAT provides a sample postscript: ``mlnxofed_ib_install.v2``.
.. toctree::
:maxdepth: 2

4
docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskful.rst
View File

@ -18,7 +18,7 @@ Diskful Installation
chdef -t node -o <node_name> \
-p postscripts="mlnxofed_ib_install -p /install/<path-to>/<MLNX_OFED_LINUX.iso>"
**[kernel mismatch issue]** The Mellanox OFED ISO is built againt a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. ::
**[kernel mismatch issue]** The Mellanox OFED ISO is built against a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. ::
chdef -t node -o <node_name> \
-p postscripts="mlnxofed_ib_install -p /install/<path-to>/<MLNX_OFED_LINUX.iso> \
@ -42,4 +42,4 @@ Diskful Installation
* Verify that the Mellanox IB drivers are located at: ``/lib/modules/<kernel_version>/extra/``
* Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter.
* Use the ``ibv_devinfo`` command to obtain information about the InfiniBand adapter.

4
docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskless.rst
View File

@ -28,7 +28,7 @@ Diskless Installation
*Note: The $1 is a argument that is passed to the the postinstall script at runtime.*
**[kernel mismatch issue]** The Mellanox OFED ISO is built againt a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. ::
**[kernel mismatch issue]** The Mellanox OFED ISO is built against a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. ::
/install/postscripts/mlnxofed_ib_install \
-p /install/<path-to>/<MLNX_OFED_LINUX.iso> -m --add-kernel-support -end- \
@ -62,4 +62,4 @@ Diskless Installation
* Verify that the Mellanox IB drivers are located at: ``/lib/modules/<kernel_version>/extra/``
* Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter.
* Use the ``ibv_devinfo`` command to obtain information about the InfiniBand adapter.

2
docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_preparation.rst
View File

@ -22,7 +22,7 @@ The ``mlnxofed_ib_install.v2`` is a sample script intended to assist with the in
# ensure the script has execute permission
chmod +x /install/postscripts/mlnxofed_ib_install
#. Familarize the options available for the xCAT ``mlnxofed_ib_install`` script.
#. Familiarize the options available for the xCAT ``mlnxofed_ib_install`` script.
+---------+------------------+----------------------------------------------------------+
| Option | Required | Description |

2
docs/source/advanced/networks/infiniband/mlnxofed_ib_verified_scenario_matrix.rst
View File

@ -1,7 +1,7 @@
MLNX_OFED Support Matrix
========================
The following ISO images and attributs have been verified by the xCAT Team.
The following ISO images and attributes have been verified by the xCAT Team.
**RedHat Enterprise Linux**

2
docs/source/advanced/networks/infiniband/switch_configuration.rst
View File

@ -66,7 +66,7 @@ Then run the following: ::
Setup syslog on the Switch
--------------------------
Use the following command to consolidate the syslog to the Management Node or Service Nodes, where ip is the addess of the MN or SN as known by the switch. ::
Use the following command to consolidate the syslog to the Management Node or Service Nodes, where ip is the address of the MN or SN as known by the switch. ::
rspconfig mswitch logdest=<ip>

4
docs/source/advanced/networks/onie_switches/os_cumulus/install.rst
View File

@ -12,7 +12,7 @@ xCAT provides support for detecting and installing the Cumulus Linux OS into ONI
The mac address of the switch management port is required for xCAT to configure the DHCP information and send over the OS to install on the switch.
**[small clusters]** If you know the mac address of the management port on the switch, create the pre-defined switch defintion providing the mac address. ::
**[small clusters]** If you know the mac address of the management port on the switch, create the pre-defined switch definition providing the mac address. ::
mkdef frame01sw1 --template onieswitch arch=armv71 \
ip=192.168.1.1 mac="aa:bb:cc:dd:ee:ff"
@ -32,7 +32,7 @@ xCAT provides support for detecting and installing the Cumulus Linux OS into ONI
ip=192.168.4.1 switch=coresw1 switchport=4
...
#. Leverage ``switchdiscover`` over the DHCP range to automatically detect the MAC address and write them into the predefined swtiches above. ::
#. Leverage ``switchdiscover`` over the DHCP range to automatically detect the MAC address and write them into the predefined switches above. ::
switchdiscover --range <IP range>

2
docs/source/advanced/networks/switchdiscover/switch_based_switch_discovery.rst
View File

@ -155,7 +155,7 @@ These two config files are located in the **/opt/xcat/share/xcat/scripts** direc
Switch Status
~~~~~~~~~~~~~
During the switch-based switch discovery process, there are four states displayed. User may only see **switch_configed** status on node definition if discovery process succefully finished.
During the switch-based switch discovery process, there are four states displayed. User may only see **switch_configed** status on node definition if discovery process successfully finished.
**Matched** --- Discovered switch is matched to predefine switch, **otherinterfaces** attribute is updated to dhcp IP address, and mac address, **switch type** and **usercomment** also updated with vendor information for the predefined switch.

4
docs/source/advanced/networks/vlan/vlan.rst
View File

@ -206,7 +206,7 @@ There is no need to specify -i flag for removing nodes from a vlan.
Remove a VLAN
-------------
The **rmvlan** command removes the given vlan ID from the cluster. It removes the vlan id from all the swithces involved, deconfigures the nodes so that vlan adaptor (tag) will be remved, cleans up /etc/hosts, DNS and database tables for the given vlan.
The **rmvlan** command removes the given vlan ID from the cluster. It removes the vlan id from all the switches involved, deconfigures the nodes so that vlan adaptor (tag) will be removed, cleans up /etc/hosts, DNS and database tables for the given vlan.
For example: ::
@ -215,7 +215,7 @@ For example: ::
VLAN Security
-------------
To make the vlan more secure, the root guard and the bpdu guard are enabled for each ports within the vlan by **mkvlan** and **chvlan** commands. This way it guards the topology changes on the switch by the hackers who hack the STP. However, when the vlan is removed by the **rmvlan** and the **chvlan (-d)** commands, the root guard and the bpdu guard are not disabled because the code cannot tell if the guards were enabled by the admin or not. If you want to remove the gurads after the vlan is removed, you need to use the switch command line interface to do so. Refer to the documents for the switch command line interfaces for details.
To make the vlan more secure, the root guard and the bpdu guard are enabled for each ports within the vlan by **mkvlan** and **chvlan** commands. This way it guards the topology changes on the switch by the hackers who hack the STP. However, when the vlan is removed by the **rmvlan** and the **chvlan (-d)** commands, the root guard and the bpdu guard are not disabled because the code cannot tell if the guards were enabled by the admin or not. If you want to remove the guards after the vlan is removed, you need to use the switch command line interface to do so. Refer to the documents for the switch command line interfaces for details.
Limitation
----------

2
docs/source/advanced/probe/osdeploy.rst
View File

@ -76,7 +76,7 @@ When all the nodes complete provisioning, the probe will exit and display output
All nodes provisioned successfully [ OK ]
If there is something wrong when provisioning, this probe will exit when timeout is reachedd or ``Ctrl+C`` is pressed by user. The maximum time can be set by using ``-t`` as below(default 30 minutes) ::
If there is something wrong when provisioning, this probe will exit when timeout is reached or ``Ctrl+C`` is pressed by user. The maximum time can be set by using ``-t`` as below(default 30 minutes) ::
xcatprobe osdeploy -n cn1 -t 30

2
docs/source/advanced/raid/hardware_raid.rst
View File

@ -18,7 +18,7 @@ Following sections show how to use ``diskdiscover`` and ``configraid``, we assum
Discovering disk devices
------------------------
Command ``diskdiscover`` scans disk devices, it can get the overview of disks and RAID arrays information from compute node; The outputs contain useful information for ``configraid`` to configure RAID arrays, user can get ``pci_id``, ``pci_slot_name``, ``disk names``, ``RAID arrays`` and other informations from the outputs. It should be ran in xcat genesis system. It can be executed without input parameter or with pci_id, pci_id includes PCI vendor and device ID. For example, power8 SAS adapter pci_id is ``1014:034a``, ``1014`` is vendor info, ``034a`` is PCI-E IPR SAS Adapter, more info about pci_id refer to ``http://pci-ids.ucw.cz/read/PC/1014/``.
Command ``diskdiscover`` scans disk devices, it can get the overview of disks and RAID arrays information from compute node; The outputs contain useful information for ``configraid`` to configure RAID arrays, user can get ``pci_id``, ``pci_slot_name``, ``disk names``, ``RAID arrays`` and other information from the outputs. It should be ran in xcat genesis system. It can be executed without input parameter or with pci_id, pci_id includes PCI vendor and device ID. For example, power8 SAS adapter pci_id is ``1014:034a``, ``1014`` is vendor info, ``034a`` is PCI-E IPR SAS Adapter, more info about pci_id refer to ``http://pci-ids.ucw.cz/read/PC/1014/``.
Here are steps to use ``diskdiscover``:

144
docs/source/advanced/restapi/restapi_resource/restapi_reference.rst
View File

@ -15,7 +15,7 @@ POST - Create a token.
**Example:**
Aquire a token for user 'root'. ::
Acquire a token for user 'root'. ::
#curl -X POST -k 'https://127.0.0.1/xcatws/tokens?userName=root&userPW=cluster&pretty=1' -H Content-Type:application/json --data '{"userName":"root","userPW":"cluster"}'
@ -62,8 +62,8 @@ Get all the node names from xCAT database. ::
[URI:/nodes/{noderange}] - The node resource
--------------------------------------------
GET - Get all the attibutes for the node {noderange}.
`````````````````````````````````````````````````````
GET - Get all the attributes for the node {noderange}.
``````````````````````````````````````````````````````
The keyword ALLRESOURCES can be used as {noderange} which means to get node attributes for all the nodes.
@ -75,7 +75,7 @@ Refer to the man page: :doc:`lsdef </guides/admin-guides/references/man1/lsdef.1
**Example:**
Get all the attibutes for node 'node1'. ::
Get all the attributes for node 'node1'. ::
#curl -X GET -k 'https://127.0.0.1/xcatws/nodes/node1?userName=root&userPW=cluster&pretty=1'
@ -90,8 +90,8 @@ Get all the attibutes for node 'node1'. ::
}
}
PUT - Change the attibutes for the node {noderange}.
````````````````````````````````````````````````````
PUT - Change the attributes for the node {noderange}.
`````````````````````````````````````````````````````
Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1>`
@ -101,7 +101,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -122,7 +122,7 @@ Refer to the man page: :doc:`mkdef </guides/admin-guides/references/man1/mkdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -138,7 +138,7 @@ Refer to the man page: :doc:`rmdef </guides/admin-guides/references/man1/rmdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -184,7 +184,7 @@ Refer to the man page: :doc:`makehosts </guides/admin-guides/references/man8/mak
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -204,7 +204,7 @@ Refer to the man page: :doc:`makedns </guides/admin-guides/references/man8/maked
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -219,7 +219,7 @@ Refer to the man page: :doc:`makedns </guides/admin-guides/references/man8/maked
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -237,7 +237,7 @@ Refer to the man page: :doc:`makedhcp </guides/admin-guides/references/man8/make
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -252,7 +252,7 @@ Refer to the man page: :doc:`makedhcp </guides/admin-guides/references/man8/make
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -356,7 +356,7 @@ Refer to the man page: :doc:`rpower </guides/admin-guides/references/man1/rpower
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -401,7 +401,7 @@ Refer to the man page: :doc:`renergy </guides/admin-guides/references/man1/rener
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -469,7 +469,7 @@ Refer to the man page: :doc:`rspconfig </guides/admin-guides/references/man1/rsp
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -512,7 +512,7 @@ Refer to the man page: :doc:`rsetboot </guides/admin-guides/references/man1/rset
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -555,7 +555,7 @@ Refer to the man page: :doc:`nodeset </guides/admin-guides/references/man1/nimno
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -566,7 +566,7 @@ Set the next boot state for the node1. ::
[URI:/nodes/{noderange}/vitals] - The vitals resources for the node {noderange}
-------------------------------------------------------------------------------
GET - Get all the vitals attibutes.
GET - Get all the vitals attributes.
```````````````````````````````````
Refer to the man page: :doc:`rvitals </guides/admin-guides/references/man1/rvitals.1>`
@ -597,7 +597,7 @@ Get all the vitails attributes for the node1. ::
[URI:/nodes/{noderange}/vitals/{temp|voltage|wattage|fanspeed|power|leds...}] - The specific vital attributes for the node {noderange}
--------------------------------------------------------------------------------------------------------------------------------------
GET - Get the specific vitals attibutes.
GET - Get the specific vitals attributes.
````````````````````````````````````````
Refer to the man page: :doc:`rvitals </guides/admin-guides/references/man1/rvitals.1>`
@ -628,7 +628,7 @@ Get the 'fanspeed' vitals attribute. ::
[URI:/nodes/{noderange}/inventory] - The inventory attributes for the node {noderange}
--------------------------------------------------------------------------------------
GET - Get all the inventory attibutes.
GET - Get all the inventory attributes.
``````````````````````````````````````
Refer to the man page: :doc:`rinv </guides/admin-guides/references/man1/rinv.1>`
@ -659,7 +659,7 @@ Get all the inventory attributes for node1. ::
[URI:/nodes/{noderange}/inventory/{pci|model...}] - The specific inventory attributes for the node {noderange}
--------------------------------------------------------------------------------------------------------------
GET - Get the specific inventory attibutes.
GET - Get the specific inventory attributes.
```````````````````````````````````````````
Refer to the man page: :doc:`rinv </guides/admin-guides/references/man1/rinv.1>`
@ -714,7 +714,7 @@ Refer to the man page: :doc:`reventlog </guides/admin-guides/references/man1/rev
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -745,7 +745,7 @@ Refer to the man page: :doc:`rbeacon </guides/admin-guides/references/man1/rbeac
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -918,7 +918,7 @@ Refer to the man page: :doc:`xdcp </guides/admin-guides/references/man1/xdcp.1>`
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -947,7 +947,7 @@ Refer to the man page: :doc:`chvm </guides/admin-guides/references/man1/chvm.1>`
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example1:**
@ -982,7 +982,7 @@ Refer to the man page: :doc:`mkvm </guides/admin-guides/references/man1/mkvm.1>`
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1003,7 +1003,7 @@ Refer to the man page: :doc:`rmvm </guides/admin-guides/references/man1/rmvm.1>`
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1112,7 +1112,7 @@ Refer to the man page: :doc:`copycds </guides/admin-guides/references/man8/copyc
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example1:**
@ -1129,7 +1129,7 @@ Create osimage resources based on an xCAT image or configuration file ::
[URI:/osimages/{imgname}] - The osimage resource
------------------------------------------------
GET - Get all the attibutes for the osimage {imgname}.
GET - Get all the attributes for the osimage {imgname}.
``````````````````````````````````````````````````````
The keyword ALLRESOURCES can be used as {imgname} which means to get image attributes for all the osimages.
@ -1162,7 +1162,7 @@ Get the attributes for the specified osimage. ::
}
}
PUT - Change the attibutes for the osimage {imgname}.
PUT - Change the attributes for the osimage {imgname}.
`````````````````````````````````````````````````````
Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1>`
@ -1173,7 +1173,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1192,7 +1192,7 @@ Refer to the man page: :doc:`mkdef </guides/admin-guides/references/man1/mkdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1207,7 +1207,7 @@ Refer to the man page: :doc:`rmdef </guides/admin-guides/references/man1/rmdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1257,7 +1257,7 @@ Refer to the man page: :doc:` </guides/admin-guides/references/>`
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example1:**
@ -1284,7 +1284,7 @@ Refer to the man page: :doc:`rmimage </guides/admin-guides/references/man1/rmima
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1336,7 +1336,7 @@ Refer to the man page: :doc:`makenetworks </guides/admin-guides/references/man8/
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1347,7 +1347,7 @@ Create the networks resources base on the network configuration on xCAT MN. ::
[URI:/networks/{netname}] - The network resource
------------------------------------------------
GET - Get all the attibutes for the network {netname}.
GET - Get all the attributes for the network {netname}.
``````````````````````````````````````````````````````
The keyword ALLRESOURCES can be used as {netname} which means to get network attributes for all the networks.
@ -1360,7 +1360,7 @@ Refer to the man page: :doc:`lsdef </guides/admin-guides/references/man1/lsdef.1
**Example:**
Get all the attibutes for network 'network1'. ::
Get all the attributes for network 'network1'. ::
#curl -X GET -k 'https://127.0.0.1/xcatws/networks/network1?userName=root&userPW=cluster&pretty=1'
{
@ -1374,7 +1374,7 @@ Get all the attibutes for network 'network1'. ::
}
}
PUT - Change the attibutes for the network {netname}.
PUT - Change the attributes for the network {netname}.
`````````````````````````````````````````````````````
Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1>`
@ -1385,7 +1385,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1404,7 +1404,7 @@ Refer to the man page: :doc:`mkdef </guides/admin-guides/references/man1/mkdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1419,7 +1419,7 @@ Refer to the man page: :doc:`rmdef </guides/admin-guides/references/man1/rmdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1487,7 +1487,7 @@ Get all the policy objects. ::
[URI:/policy/{policy_priority}] - The policy resource
-----------------------------------------------------
GET - Get all the attibutes for a policy {policy_priority}.
GET - Get all the attributes for a policy {policy_priority}.
```````````````````````````````````````````````````````````
It will display all the policy attributes for one policy resource.
@ -1512,7 +1512,7 @@ Get all the attribute for policy 1. ::
}
}
PUT - Change the attibutes for the policy {policy_priority}.
PUT - Change the attributes for the policy {policy_priority}.
````````````````````````````````````````````````````````````
It will change one or more attributes for a policy.
@ -1525,7 +1525,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1547,7 +1547,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1564,7 +1564,7 @@ Refer to the man page: :doc:`rmdef </guides/admin-guides/references/man1/rmdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1637,7 +1637,7 @@ Get all the group names from xCAT database. ::
[URI:/groups/{groupname}] - The group resource
----------------------------------------------
GET - Get all the attibutes for the group {groupname}.
GET - Get all the attributes for the group {groupname}.
``````````````````````````````````````````````````````
Refer to the man page: :doc:`lsdef </guides/admin-guides/references/man1/lsdef.1>`
@ -1648,7 +1648,7 @@ Refer to the man page: :doc:`lsdef </guides/admin-guides/references/man1/lsdef.1
**Example:**
Get all the attibutes for group 'all'. ::
Get all the attributes for group 'all'. ::
#curl -X GET -k 'https://127.0.0.1/xcatws/groups/all?userName=root&userPW=cluster&pretty=1'
{
@ -1657,7 +1657,7 @@ Get all the attibutes for group 'all'. ::
}
}
PUT - Change the attibutes for the group {groupname}.
PUT - Change the attributes for the group {groupname}.
`````````````````````````````````````````````````````
Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1>`
@ -1668,7 +1668,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1776,7 +1776,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1793,7 +1793,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1816,7 +1816,7 @@ Refer to the man page: :doc:`makedns </guides/admin-guides/references/man8/maked
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1834,7 +1834,7 @@ Refer to the man page: :doc:`makedhcp </guides/admin-guides/references/man8/make
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1852,7 +1852,7 @@ Refer to the man page: :doc:`makehosts </guides/admin-guides/references/man8/mak
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -1954,7 +1954,7 @@ URI list which can be used to create, query, change table entries.
For a large number of nodes, this API call can be faster than using the corresponding nodes resource. The disadvantage is that you need to know the table names the attributes are stored in.
GET - Get attibutes of tables for a noderange.
GET - Get attributes of tables for a noderange.
``````````````````````````````````````````````
**Returns:**
@ -2025,7 +2025,7 @@ Get all the columns from tables nodetype and noderes for node1 and node2. ::
]
}
PUT - Change the node table attibutes for {noderange}.
PUT - Change the node table attributes for {noderange}.
``````````````````````````````````````````````````````
**Parameters:**
@ -2034,7 +2034,7 @@ PUT - Change the node table attibutes for {noderange}.
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -2047,7 +2047,7 @@ Change the nodetype.arch and noderes.netboot attributes for nodes node1,node2. :
For a large number of nodes, this API call can be faster than using the corresponding nodes resource. The disadvantage is that you need to know the table names the attributes are stored in.
GET - Get table attibutes for a noderange.
GET - Get table attributes for a noderange.
``````````````````````````````````````````
**Returns:**
@ -2078,7 +2078,7 @@ Get OS and ARCH attributes from nodetype table for node1 and node2. ::
[URI:/tables/{tablelist}/rows] - The non-node table resource
------------------------------------------------------------
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, polciy, etc.
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, policy, etc.
GET - Get all rows from non-node tables.
````````````````````````````````````````
@ -2115,11 +2115,11 @@ Get all rows from networks table. ::
[URI:/tables/{tablelist}/rows/{keys}] - The non-node table rows resource
------------------------------------------------------------------------
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, polciy, etc.
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, policy, etc.
{keys} should be the name=value pairs which are used to search table. e.g. {keys} should be [net=192.168.1.0,mask=255.255.255.0] for networks table query since the net and mask are the keys of networks table.
GET - Get attibutes for rows from non-node tables.
GET - Get attributes for rows from non-node tables.
``````````````````````````````````````````````````
**Returns:**
@ -2146,8 +2146,8 @@ Get row which net=192.168.1.0,mask=255.255.255.0 from networks table. ::
]
}
PUT - Change the non-node table attibutes for the row that matches the {keys}.
``````````````````````````````````````````````````````````````````````````````
PUT - Change the non-node table attributes for the row that matches the {keys}.
```````````````````````````````````````````````````````````````````````````````
**Parameters:**
@ -2155,7 +2155,7 @@ PUT - Change the non-node table attibutes for the row that matches the {keys}.
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -2168,7 +2168,7 @@ DELETE - Delete rows from a non-node table that have the attribute values specif
**Returns:**
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
**Example:**
@ -2179,10 +2179,10 @@ Delete a route row which routename=privnet in the routes table. ::
[URI:/tables/{tablelist}/rows/{keys}/{attrlist}] - The non-node table attributes resource
-----------------------------------------------------------------------------------------
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, polciy, etc.
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, policy, etc.
GET - Get specific attibutes for rows from non-node tables.
```````````````````````````````````````````````````````````
GET - Get specific attributes for rows from non-node tables.
````````````````````````````````````````````````````````````
**Returns:**

2
docs/source/advanced/sysclone/sysclone.rst
View File

@ -220,4 +220,4 @@ If you install systemimager RPMs on CentOS 6.5 node using **yum**, you may exper
Kernel panic at times when install target node with rhels7.0 in Power 7 server
``````````````````````````````````````````````````````````````````````````````
When you clone rhels7.0 image to target node which is Power 7 server lpar, you may hit Kernel panic problem at times after boot loader grub2 download kernel and initrd. This is an known issue but without a resulution. For now, we recommend you try again.
When you clone rhels7.0 image to target node which is Power 7 server lpar, you may hit Kernel panic problem at times after boot loader grub2 download kernel and initrd. This is an known issue but without a resolution. For now, we recommend you try again.

2
docs/source/advanced/zones/overview.rst
View File

@ -11,7 +11,7 @@ The new support only addresses the way we generate and distribute root's ssh RSA
In the past, the setup allowed compute nodes to be able to ssh to the SN's without a password. Using zones, will no longer allow this to happen. Using zones only allows compute nodes to ssh without password to compute node, unless you add the service node into the zone which is not considered a good idea.
But add service node into a zone is not a good idea. Beacuse:
But add service node into a zone is not a good idea. Because:
* IF you put the service node in a zone, it will no longer be able to ssh to the other servicenodes with being prompted for a password.
* Allowing the compute node to ssh to the service node, could allow the service node to be compromised, by anyone who gained access to the compute node.

2
docs/source/developers/github/change_code.rst
View File

@ -24,7 +24,7 @@ It may take days before your pull request is properly reviewed and you want to k
Creating additional branches will allow you to work on different tasks/enhancements at the same time. You can easily manage your working changes between branches with ``git stash.``.
Commiting code and pushing to remote branch
Committing code and pushing to remote branch
-------------------------------------------
Once your code is ready....

2
docs/source/developers/github/forks.rst
View File

@ -41,7 +41,7 @@ Configure an ``upstream`` repository
$ git remote add upstream git@github.com:xcat2/xcat-core.git
View the configured reposotories: ::
View the configured repositories: ::
$ git remote -v
origin git@github.com:<userid>/xcat-core.git (fetch)

2
docs/source/developers/github/pull_request.rst
View File

@ -65,7 +65,7 @@ During the reviewing of your pull request, another pull request may be merged wh
$ git push origin <mybranch> -f
If all the conflicts are resolved, the pull request should automaically turn green again and is able to be merged automatically.
If all the conflicts are resolved, the pull request should automatically turn green again and is able to be merged automatically.
Reviewing Pull Requests as a Maintainer
---------------------------------------

2
docs/source/developers/guides/code/builds.rst
View File

@ -37,7 +37,7 @@ The following steps will help configure ``pod2rst`` and be able to generate the
make
make install
* **[as non-root]** Extrat and build the Perl module using PREFIX to specify a directory that you have write permission ::
* **[as non-root]** Extract and build the Perl module using PREFIX to specify a directory that you have write permission ::
mkdir ~/perllib
perl Makefile.PL PREFIX=~/perllib

6
docs/source/developers/guides/docs/doc_guidelines.rst
View File

@ -65,7 +65,7 @@ Enumerated List
Include another file
--------------------
To add contents of a document file inside another file, use ``.. include::``. This is usefull when a common information needs to be displayed in multiple files, whithout the use of a hyperlink.
To add contents of a document file inside another file, use ``.. include::``. This is useful when a common information needs to be displayed in multiple files, without the use of a hyperlink.
::
.. include:: config_common.rst
@ -76,14 +76,14 @@ To add contents of a document file inside another file, use ``.. include::``. Th
Index file
----------
Index.rst files contain the ``.. toctree::`` tag. Files listed under that tag will have links to them displayed in the left side navigation area. If a documentation file does not wish to be accessbile from the navigation area, do not list it under the ``.. toctree::``.
Index.rst files contain the ``.. toctree::`` tag. Files listed under that tag will have links to them displayed in the left side navigation area. If a documentation file does not wish to be accessible from the navigation area, do not list it under the ``.. toctree::``.
``Note:`` If a file is not listed under the ``.. toctree::`` it might generate a warning during the documentation build ``WARNING: document isn't included in any toctree``. To eliminate such warning, add the file to the ``exclude_patterns`` list in the ``docs/source/conf.py`` file. However, do not add a file to the ``exclude_patterns`` list if it contains a customized link target, such as ``.. _my_link_taget:``. This link target will not be visible to other files and a ``WARNING: undefined label:`` will be displayed during the documentation build.
Hyperlinks -> Internal Links -> External Links
----------------------------------------------
Add links to refer other web page is a very common way in writting document, it's very helpful to reduce the doc duplication and make docs easy to understand. Following are several ways to add a link in the xCAT documentation.
Add links to refer other web page is a very common way in writing document, it's very helpful to reduce the doc duplication and make docs easy to understand. Following are several ways to add a link in the xCAT documentation.
* **Add an Internal Link to ``Customized Link Target``**

4
docs/source/guides/admin-guides/basic_concepts/xcat_object/node.rst
View File

@ -6,7 +6,7 @@ Description
The definition of physical units in the cluster, such as lpar, virtual machine, frame, cec, hmc, switch.
Key Attrubutes
Key Attributes
--------------
* os:
@ -16,7 +16,7 @@ Key Attrubutes
The hardware architecture of this node. Valid values: x86_64, ppc64, x86, ia64.
* groups:
Usually, there are a set of nodes with some attributes in common, xCAT admin can define a node group containing these nodes, so that the management task can be issued against the group instead of individual nodes. A node can be a memeber of different groups, so the value of this attributes is a comma-delimited list of groups. At least one group is required to create a node. The new created group names should not be prefixed with "__" as this token has been preserverd as the internal group name.
Usually, there are a set of nodes with some attributes in common, xCAT admin can define a node group containing these nodes, so that the management task can be issued against the group instead of individual nodes. A node can be a member of different groups, so the value of this attributes is a comma-delimited list of groups. At least one group is required to create a node. The new created group names should not be prefixed with "__" as this token has been preserved as the internal group name.
* mgt:
The method to do general hardware management of the node. This attribute can be determined by the machine type of the node. Valid values: ipmi, blade, hmc, ivm, fsp, bpa, kvm, esx, rhevm.

6
docs/source/guides/admin-guides/manage_clusters/common/deployment/acc_initrd_rootimg_gen.rst
View File

@ -1,14 +1,14 @@
Accelerating the diskless initrd and rootimg generating
========================================================
Generating diskless initrd with ``genimage`` and compressed rootimg with ``packimage`` and ``liteimg`` is a time-comsuming process, it can be accelerated by enabling paralell compression tool ``pigz`` on the management node with multiple processors and cores. See :ref:`Appendix <pigz_example>` for an example on ``packimage`` performance optimized with ``pigz`` enabled.
Generating diskless initrd with ``genimage`` and compressed rootimg with ``packimage`` and ``liteimg`` is a time-consuming process, it can be accelerated by enabling parallel compression tool ``pigz`` on the management node with multiple processors and cores. See :ref:`Appendix <pigz_example>` for an example on ``packimage`` performance optimized with ``pigz`` enabled.
Enabling the ``pigz`` for diskless initrd and rootimg generating
----------------------------------------------------------------
The paralell compression tool ``pigz`` can be enabled by installing ``pigz`` package on the management server or diskless rootimg. Depending on the method of generating the initrd and compressed rootimg, the steps differ in different Linux distributions.
The parallel compression tool ``pigz`` can be enabled by installing ``pigz`` package on the management server or diskless rootimg. Depending on the method of generating the initrd and compressed rootimg, the steps differ in different Linux distributions.
* **[RHEL]**
@ -24,7 +24,7 @@ The paralell compression tool ``pigz`` can be enabled by installing ``pigz`` pac
``pigz`` should be installed in the diskless rootimg. Download ``pigz`` package from https://dl.fedoraproject.org/pub/epel/ , then customize the diskless osimage to install ``pigz`` as the additional packages, see :doc:`Install Additional Other Packages</guides/admin-guides/manage_clusters/ppc64le/diskless/customize_image/additional_pkg>` for more details.
2) Enabeling the ``pigz`` in ``packimage``
2) Enabling the ``pigz`` in ``packimage``
``pigz`` should be installed on the management server. Download ``pigz`` package from https://dl.fedoraproject.org/pub/epel/ , then install the ``pigz`` with ``yum`` or ``rpm``.

2
docs/source/guides/admin-guides/manage_clusters/common/deployment/additionalpkg/nonubuntu_os_other_pkg.rst
View File

@ -70,7 +70,7 @@ These are described in more details in the following sections.
RPM Names
'''''''''
A simple otherpkgs.pkglist file just contains the the name of the rpm file without the version numbers.
A simple otherpkgs.pkglist file just contains the name of the rpm file without the version numbers.
For example, if you put the following three rpms under **/install/post/otherpkgs/<os>/<arch>/** directory, ::

2
docs/source/guides/admin-guides/manage_clusters/common/deployment/additionalpkg/nonubuntu_os_pkg.rst
View File

@ -51,7 +51,7 @@ These are described in more details in the following sections.
RPM Names
''''''''''
A simple .pkglist file just contains the the name of the rpm file without the version numbers.
A simple .pkglist file just contains the name of the rpm file without the version numbers.
For example ::

4
docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_second_adapter.rst
View File

@ -1,7 +1,7 @@
Configure Additional Network Interfaces - confignics
====================================================
The **nics** table and the **confignics** postscript can be used to automatically configure additional network interfaces (mutltiple ethernets adapters, InfiniBand, etc) on the nodes as they are being deployed.
The **nics** table and the **confignics** postscript can be used to automatically configure additional network interfaces (multiple ethernets adapters, InfiniBand, etc) on the nodes as they are being deployed.
The way the confignics postscript decides what IP address to give the secondary adapter is by checking the nics table, in which the nic configuration information is stored.
@ -78,7 +78,7 @@ By default, confignics does not configure the install nic. if need, using flag "
chdef cn1 -p prostscripts="confignics -s"
Option "-s" writes the install nic's information into configuration file for persistance. All install nic's data defined in nics table will be written also.
Option "-s" writes the install nic's information into configuration file for persistence. All install nic's data defined in nics table will be written also.
Add network object into the networks table

2
docs/source/guides/admin-guides/manage_clusters/common/deployment/deploy_os.rst
View File

@ -11,7 +11,7 @@ There are more attributes of nodeset used for some specific purpose or specific
* **runcmd**: This instructs the node to boot to the xCAT nbfs environment and proceed to configure BMC for basic remote access. This causes the IP, netmask, gateway, username, and password to be programmed according to the configuration table.
* **shell**: This instructs the node to boot to the xCAT genesis environment, and present a shell prompt on console. The node will also be able to be sshed into and have utilities such as wget, tftp, scp, nfs, and cifs. It will have storage drivers available for many common systems.
Choose such additional attribute of nodeset according to your requirement, if want to get more informantion about nodeset, refer to nodeset's man page.
Choose such additional attribute of nodeset according to your requirement, if want to get more information about nodeset, refer to nodeset's man page.
Start the OS Deployment
=======================

2
docs/source/guides/admin-guides/manage_clusters/common/deployment/enable_kdump.rst
View File

@ -38,7 +38,7 @@ In above example, pkglist file is /opt/xcat/share/xcat/netboot/rh/compute.rhels7
Setup pkglist
-------------
Before setting up kdump,the approprite rpms should be added to the pkglist file.Here is the rpm packages list which needs to be added to pkglist file for kdump for different OS.
Before setting up kdump, the appropriate rpms should be added to the pkglist file.Here is the rpm packages list which needs to be added to pkglist file for kdump for different OS.
* **[RHEL]** ::

6
docs/source/guides/admin-guides/manage_clusters/common/deployment/generate_img.rst
View File

@ -1,7 +1,7 @@
Generate Diskless Image
=======================
The ``copycds`` command copies the contents of the Linux media to ``/install/<os>/<arch>`` so that it will be available for installing nodes or creating diskless images. After executing ``copycds``, there are serveral ``osimage`` definitions created by default. Run ``tabdump osimage`` to view these images: ::
The ``copycds`` command copies the contents of the Linux media to ``/install/<os>/<arch>`` so that it will be available for installing nodes or creating diskless images. After executing ``copycds``, there are several ``osimage`` definitions created by default. Run ``tabdump osimage`` to view these images: ::
tabdump osimage
@ -18,7 +18,7 @@ The ``netboot-compute`` is the default **diskless** osimage created rhels7.1 ppc
Before packing the diskless image, you have the opportunity to change any files in the image by changing to the ``rootimgdir`` and making modifications. (e.g. ``/install/netboot/rhels7.1/ppc64le/compute/rootimg``).
However it's recommended that all changes to the image are made via post install scripts so that it's easily repeatable.Although, instead, we recommend that you make all changes to the image via your postinstall script, so that it is repeatable. Refer to :doc:`/guides/admin-guides/manage_clusters/ppc64le/diskless/customize_image/pre_post_script` for more details.
However it's recommended that all changes to the image are made via post install scripts so that it's easily repeatable. Although, instead, we recommend that you make all changes to the image via your postinstall script, so that it is repeatable. Refer to :doc:`/guides/admin-guides/manage_clusters/ppc64le/diskless/customize_image/pre_post_script` for more details.
Pack Diskless Image
@ -102,7 +102,7 @@ Skip this section if you want to use the image as is.
1, The use can modify the image to fit his/her own need. The following can be modified.
* Modify .pkglist file to add or remove packges that are from the os distro
* Modify .pkglist file to add or remove packages that are from the os distro
* Modify .otherpkgs.pkglist to add or remove packages from other sources. Refer to ``Using_Updatenode`` for details

2
docs/source/guides/admin-guides/manage_clusters/common/deployment/prepostscripts/postinstall_script.rst
View File

@ -40,7 +40,7 @@ The ``postinstall`` scripts are executed in step b).
Do ``postinstall`` scripts execute in chroot mode under ``rootimgdir`` directory?
`````````````````````````````````````````````````````````````````````````````````
No. Unlike postscripts and postbootscripts, the ``postinstall`` scripts are run in non-chroot environment, directly on the management node. In the postinstall scripts, all the paths of the directories and files are based on ``/`` of the managememnt node. To reference inside the ``rootimgdir``, use the ``$IMG_ROOTIMGDIR`` environment variable, exported by ``genimage``.
No. Unlike postscripts and postbootscripts, the ``postinstall`` scripts are run in non-chroot environment, directly on the management node. In the postinstall scripts, all the paths of the directories and files are based on ``/`` of the management node. To reference inside the ``rootimgdir``, use the ``$IMG_ROOTIMGDIR`` environment variable, exported by ``genimage``.
What are some of the environment variables available to my customized ``postinstall`` scripts?
``````````````````````````````````````````````````````````````````````````````````````````````

6
docs/source/guides/admin-guides/manage_clusters/common/deployment/raid_cfg.rst
View File

@ -185,7 +185,7 @@ Here is the RAID1 partitioning section in service.raid1.sles11.tmpl: ::
The samples above created one 24MB PReP partition on each disk, one 2GB mirrored swap partition and one mirrored ``/`` partition uses all the disk space. If you want to use different partitioning scheme in your cluster, modify this RAID1 section in the autoyast template file accordingly.
Since the PReP partition can not be mirrored between the two disks, some additional postinstall commands should be run to make the second disk bootable, here the the commands needed to make the second disk bootable: ::
Since the PReP partition can not be mirrored between the two disks, some additional postinstall commands should be run to make the second disk bootable, here the commands needed to make the second disk bootable: ::
# Set the second disk to be bootable for RAID1 setup
parted -s /dev/sdb mkfs 1 fat16
@ -230,7 +230,7 @@ The command mdadm can query the detailed configuration for the RAID partitions:
Disk Replacement Procedure
--------------------------
If any one disk fails in the RAID1 arrary, do not panic. Follow the procedure listed below to replace the failed disk and you will be fine.
If any one disk fails in the RAID1 array, do not panic. Follow the procedure listed below to replace the failed disk and you will be fine.
Faulty disks should appear marked with an (F) if you look at ``/proc/mdstat``: ::
@ -250,7 +250,7 @@ Faulty disks should appear marked with an (F) if you look at ``/proc/mdstat``: :
We can see that the first disk is broken because all the RAID partitions on this disk are marked as (F).
Remove the failed disk from RAID arrary
Remove the failed disk from RAID array
---------------------------------------
``mdadm`` is the command that can be used to query and manage the RAID arrays on Linux. To remove the failed disk from RAID array, use the command: ::

4
docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_overview.rst
View File

@ -3,7 +3,7 @@ Overview
Synchronizing (sync) files to the nodes is a feature of xCAT used to distribute specific files from the management node to the new-deploying or deployed nodes.
This function is supported for diskful or RAMdisk-based diskless nodes.Generally, the specific files are usually the system configuration files for the nodes in the **/etc/directory**, like **/etc/hosts**, **/etc/resolve.conf**; it also could be the application programs configuration files for the nodes. The advantages of this function are: it can parallel sync files to the nodes or nodegroup for the installed nodes; it can automatically sync files to the newly-installing node after the installation. Additionally, this feature also supports the flexible format to define the synced files in a configuration file, called **'synclist'**.
This function is supported for diskful or RAMdisk-based diskless nodes. Generally, the specific files are usually the system configuration files for the nodes in the **/etc/directory**, like **/etc/hosts**, **/etc/resolve.conf**; it also could be the application programs configuration files for the nodes. The advantages of this function are: it can parallel sync files to the nodes or nodegroup for the installed nodes; it can automatically sync files to the newly-installing node after the installation. Additionally, this feature also supports the flexible format to define the synced files in a configuration file, called **'synclist'**.
The synclist file can be a common one for a group of nodes using the same profile or osimage, or can be the special one for a particular node. Since the location of the synclist file will be used to find the synclist file, the common synclist should be put in a given location for Linux nodes or specified by the osimage.
@ -17,7 +17,7 @@ For a new-installing nodes, the Syncing File action will be triggered when perfo
The postscript **'syncfiles'** is located in the **/install/postscripts/**. When running, it sends a message to the xcatd on the management node or service node, then the xcatd figures out the corresponding synclist file for the node and calls the ``xdcp`` command to sync files in the synclist to the node.
**If installing nodes in a hierarchical configuration, you must sync the Service Nodes first to make sure they are updated. The compute nodes will be sync'd from their service nodes.You can use the** ``updatenode <computenodes> -f`` **command to sync all the service nodes for range of compute nodes provided.**
**If installing nodes in a hierarchical configuration, you must sync the Service Nodes first to make sure they are updated. The compute nodes will be sync'd from their service nodes. You can use the** ``updatenode <computenodes> -f`` **command to sync all the service nodes for range of compute nodes provided.**
For an installed nodes, the Syncing File action happens when performing the ``updatenode -F`` or ``xdcp -F synclist`` command to update a nodes. If performing the ``updatenode -F``, it figures out the location of the synclist files for all the nodes and classify the nodes which using same synclist file and then calls the ``xdcp -F synclist`` to sync files to the nodes.

2
docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_synclist_file.rst
View File

@ -97,7 +97,7 @@ Note: From xCAT 2.9.2 on AIX and from xCAT 2.12 on Linux, xCAT support a new for
file -> (noderange for permitted nodes) file
The noderange would have several format. Following examples show that /etc/hosts file is synced to the nodes which is specifed before the file name ::
The noderange would have several format. Following examples show that /etc/hosts file is synced to the nodes which is specified before the file name ::
/etc/hosts -> (node1,node2) /etc/hosts # The /etc/hosts file is synced to node1 and node2
/etc/hosts -> (node1-node4) /etc/hosts # The /etc/hosts file is synced to node1,node2,node3 and node4

4
docs/source/guides/admin-guides/manage_clusters/common/deployment/trim_diskless_rootimg.rst
View File

@ -51,7 +51,7 @@ The content above presents some syntax supported in exlist file:
+./usr/share/locale/C*
It is useful to include files following an exclude entry to qiuckly remove a larger set of files using a wildcard and then adding back the few necessary files using the + sign. In the above example, all the files and sub-directories matching the pattern ``/usr/share/locale/C*`` will be included in the ``rootimg.gz`` file.
It is useful to include files following an exclude entry to quickly remove a larger set of files using a wildcard and then adding back the few necessary files using the + sign. In the above example, all the files and sub-directories matching the pattern ``/usr/share/locale/C*`` will be included in the ``rootimg.gz`` file.
Customize the ``exlist`` file and the osimage definition
@ -77,4 +77,4 @@ If you want to customize the osimage ``sles12.1-ppc64le-netboot-compute`` with y
.. [1] The ``exlist`` file entry should not end with a slash ``/``, For example, this entry will never match anything: ``./usr/lib/perl[0-9]/[0-9.]*/ppc64le-linux-thread-multi/Encode/``.
.. [2] Pattern match test applies to the whole file name,starting from one of the start points specified in the ``exlist`` file entry. The regex syntax should comply with the regex syntax of system command ``find -path``, refer to its doc for details.
.. [2] Pattern match test applies to the whole file name, starting from one of the start points specified in the ``exlist`` file entry. The regex syntax should comply with the regex syntax of system command ``find -path``, refer to its doc for details.

4
docs/source/guides/admin-guides/manage_clusters/common/kvm/manage_vm.rst
View File

@ -2,7 +2,7 @@ Manage Virtual Machine (VM)
============================
Now the MowerKVM hypervisor "kvmhost1" is ready, this section introduces the VM management in xCAT, including examples on how to create,remove and clone VMs.
Now the MowerKVM hypervisor "kvmhost1" is ready, this section introduces the VM management in xCAT, including examples on how to create, remove and clone VMs.
Create Virtual Machine
----------------------
@ -117,7 +117,7 @@ Now a VM "vm1" is created, it can be provisioned like any other nodes in xCAT. T
rpower vm1 on
If "vm1" is powered on successfully, the VM status can be obtained by running the following command on management node ::
If "vm1" is powered on successfully, the VM status can be obtained by running the following command on management node ::
rpower vm1 status

2
docs/source/guides/admin-guides/manage_clusters/common/updatenode.rst
View File

@ -134,6 +134,6 @@ where <scripts> is a comma separated postscript like ospkgs,otherpkgs etc.
* wget is used in xcatdsklspost/xcataixpost to get all the postscripts from the <server> to the node. You can check /tmp/wget.log file on the node to see if wget was successful or not. You need to make sure the /xcatpost directory has enough space to hold the postscripts.
* A file called /xcatpost/mypostscript (Linux) is created on the node which contains the environmental variables and scripts to be run. Make sure this file exists and it contains correct info. You can also run this file on the node manually to debug.
* For ospkgs/otherpkgs, if /install is not mounted on the <server>, it will download all the rpms from the <server> to the node using wget. Make sure /tmp and /xcatpost have enough space to hold the rpms and check /tmp/wget.log for errors.
* For ospkgs/otherpkgs, If zypper or yum is installed on the node, it will be used the command to install the rpms. Make sure to run createrepo on the source direcory on the <server> every time a rpm is added or removed. Otherwise, the rpm command will be used, in this case, make sure all the necessary depended rpms are copied in the same source directory.
* For ospkgs/otherpkgs, If zypper or yum is installed on the node, it will be used the command to install the rpms. Make sure to run createrepo on the source directory on the <server> every time a rpm is added or removed. Otherwise, the rpm command will be used, in this case, make sure all the necessary depended rpms are copied in the same source directory.
* You can append -x on the first line of ospkgs/otherpkgs to get more debug info.

1
docs/source/guides/admin-guides/manage_clusters/index.rst
View File

@ -11,4 +11,3 @@ The sections are organized based on hardware architecture.
ppc64le/index.rst
x86_64/index.rst
openbmc/index.rst

9
docs/source/guides/admin-guides/manage_clusters/openbmc/configure.rst
View File

@ -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

11
docs/source/guides/admin-guides/manage_clusters/openbmc/index.rst
View File

@ -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

60
docs/source/guides/admin-guides/manage_clusters/openbmc/openbmc.rst
View File

@ -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

29
docs/source/guides/admin-guides/manage_clusters/ppc64le/configure/password.rst
View File

@ -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``

4
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/mtms/index.rst
View File

@ -3,12 +3,12 @@ MTMS-based Discovery
MTMS stands for **M**\ achine **T**\ ype/\ **M**\ odel and **S**\ erial. This is one way to uniquely identify each physical server.
MTMS-based hardware discovery assumes the administator has the model type and serial number information for the physical servers and a plan for mapping the servers to intended hostname/IP addresses.
MTMS-based hardware discovery assumes the administrator has the model type and serial number information for the physical servers and a plan for mapping the servers to intended hostname/IP addresses.
**Overview**
#. Automatically search and collect MTMS information from the servers
#. Write **discovered-bmc-nodes** to xCAT (recommened to set different BMC IP address)
#. Write **discovered-bmc-nodes** to xCAT (recommended to set different BMC IP address)
#. Create **predefined-compute-nodes** to xCAT providing additional properties
#. Power on the nodes which triggers xCAT hardware discovery engine

11
docs/source/guides/admin-guides/manage_clusters/ppc64le/index.rst
View File

@ -1,8 +1,11 @@
IBM Power LE / OpenPOWER
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

124
docs/source/guides/admin-guides/manage_clusters/ppc64le/management.rst
View File

@ -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

10
docs/source/guides/admin-guides/manage_clusters/ppc64le/management/advanced/index.rst Normal file
View File

@ -0,0 +1,10 @@
Advanced Operations
===================
.. toctree::
:maxdepth: 2
rinv.rst
rvitals.rst
rflash.rst
rspconfig.rst

15
docs/source/guides/admin-guides/manage_clusters/ppc64le/management/advanced/rflash.rst Normal file
View File

@ -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

15
docs/source/guides/admin-guides/manage_clusters/ppc64le/management/advanced/rinv.rst Normal file
View File

@ -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

10
docs/source/guides/admin-guides/manage_clusters/ppc64le/management/advanced/rspconfig.rst Normal file
View File

@ -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

15
docs/source/guides/admin-guides/manage_clusters/ppc64le/management/advanced/rvitals.rst Normal file
View File

@ -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

9
docs/source/guides/admin-guides/manage_clusters/ppc64le/management/basic/index.rst Normal file
View File

@ -0,0 +1,9 @@
Basic Operations
================
.. toctree::
:maxdepth: 2
rbeacon.rst
rpower.rst
rcons.rst

9
docs/source/guides/admin-guides/manage_clusters/ppc64le/management/basic/rbeacon.rst Normal file
View File

@ -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``

53
docs/source/guides/admin-guides/manage_clusters/ppc64le/management/basic/rcons.rst Normal file
View File

@ -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.

15
docs/source/guides/admin-guides/manage_clusters/ppc64le/management/basic/rpower.rst Normal file
View 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``

8
docs/source/guides/admin-guides/manage_clusters/ppc64le/management/index.rst Normal file
View File

@ -0,0 +1,8 @@
Hardware Management
===================
.. toctree::
:maxdepth: 2
basic/index.rst
advanced/index.rst

4
docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/config_statelite.rst
View File

@ -20,7 +20,7 @@ The litefile table specifies the directories and files on the statelite nodes th
#. The third column in the litefile table specifies options for the directory or file:
#. tmpfs - It provides a file or directory for the node to use when booting, its permission will be the same as the original version on the server. In most cases, it is read-write; however, on the next statelite boot, the original version of the file or directory on the server will be used, it means it is non-persistent. This option can be performed on files and directories.
#. rw - Same as Above.Its name "rw" does NOT mean it always be read-write, even in most cases it is read-write. Do not confuse it with the "rw" permission in the file system.
#. rw - Same as above. Its name "rw" does NOT mean it always be read-write, even in most cases it is read-write. Do not confuse it with the "rw" permission in the file system.
#. persistent - It provides a mounted file or directory that is copied to the xCAT persistent location and then over-mounted on the local file or directory. Anything written to that file or directory is preserved. It means, if the file/directory does not exist at first, it will be copied to the persistent location. Next time the file/directory in the persistent location will be used. The file/directory will be persistent across reboots. Its permission will be the same as the original one in the statelite location. It requires the statelite table to be filled out with a spot for persistent statelite. This option can be performed on files and directories.
#. con - The contents of the pathname are concatenated to the contents of the existing file. For this directive the searching in the litetree hierarchy does not stop when the first match is found. All files found in the hierarchy will be concatenated to the file when found. The permission of the file will be "-rw-r--r--", which means it is read-write for the root user, but readonly for the others. It is non-persistent, when the node reboots, all changes to the file will be lost. It can only be performed on files. Do not use it for one directory.
#. ro - The file/directory will be overmounted read-only on the local file/directory. It will be located in the directory hierarchy specified in the litetree table. Changes made to this file or directory on the server will be immediately seen in this file/directory on the node. This option requires that the file/directory to be mounted must be available in one of the entries in the litetree table. This option can be performed on files and directories.
@ -133,5 +133,5 @@ noderes
``noderes.nfsserver`` attribute can be set for the NFSroot server. If this is not set, then the default is the Management Node.
``noderes.nfsdir`` can be set. If this is not set, the the default is ``/install``
``noderes.nfsdir`` can be set. If this is not set, the default is ``/install``

2
docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/FAQ.rst
View File

@ -88,7 +88,7 @@ Fail to ping the installed VM
ADDRCONF(NETDEV_UP): eth0 link is not ready.
**Solutoin**:
**Solution**:
Usually caused by the incorrect VM NIC model. Try the following steps to specify "virtio": ::
rmvm vm1

4
docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/hypervisorKVM.rst
View File

@ -16,7 +16,7 @@ Provision Hypervisor
#. Customize the hypervisor node definition to create network bridge
xCAT ships a postscript **xHRM** to create a network bridge on kvm host during installation/netbooting. Specify the **xHRM** with appropriate parameters in **postscripts** attibute. For example:
xCAT ships a postscript **xHRM** to create a network bridge on kvm host during installation/netbooting. Specify the **xHRM** with appropriate parameters in **postscripts** attribute. For example:
* To create a bridge named 'br0' against the installation network device specified by **installnic**: ::
@ -68,7 +68,7 @@ If the hypervisor is provisioned successfully according to the steps described a
br0 8000.000000000000 no eth0
If the network bridge is not created or configured successfully, run "xHRM" with **updatenode** on managememt node to create it manually:::
If the network bridge is not created or configured successfully, run "xHRM" with **updatenode** on management node to create it manually:::
updatenode kvmhost1 -P "xHRM bridgeprereq eth0:br0"

2
docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/kvmMN.rst
View File

@ -15,7 +15,7 @@ Please make sure the following packages have been installed on the management no
Set Up the kvm storage directory on the management node(optional)
-----------------------------------------------------------------
It is a recommended configuration to create a shared file system for virtual machines hosting. The shared file system, usually on a SAN, NAS or GPFS, is shared among KVM hypevisors, which simplifies VM migration from one hypervisor to another with xCAT.
It is a recommended configuration to create a shared file system for virtual machines hosting. The shared file system, usually on a SAN, NAS or GPFS, is shared among KVM hypervisors, which simplifies VM migration from one hypervisor to another with xCAT.
The easiest shared file system is ``/install`` directory on the management node, it can be shared among hypervisors via NFS. Please refer to the following steps :

2
docs/source/guides/admin-guides/references/man1/makentp.1.rst
View File

@ -43,7 +43,7 @@ OPTIONS
\ **-a|-**\ **-all**\
Setup NTP servers for both management node and the service node.
Setup NTP servers for both management node and the service node. If management node has SLES installed and used as \ *ntpservers*\ , it is recommanded to use the \ **setupntp**\ postscript to set up NTP server for service nodes.

13
docs/source/guides/admin-guides/references/man1/rinv.1.rst
View File

@ -28,11 +28,18 @@ BMC/MPA specific:
\ **rinv**\ \ *noderange*\ {\ **pci | model | serial | asset | vpd | mprom | deviceid | guid | firm | diag | dimm | bios | mparom | mac | all**\ }
OpenPOWER server specific:
==========================
OpenPOWER (using ipmi) server specific:
=======================================
\ **rinv**\ \ *noderange*\ {\ **model | serial | deviceid | uuid | guid | vpd | mprom | firm | all**\ }
\ **rinv**\ \ *noderange*\ [\ **model | serial | deviceid | uuid | guid | vpd | mprom | firm | all**\ ]
OpenPOWER (using openbmc) server specific:
==========================================
\ **rinv**\ \ *noderange*\ [\ **model | serial | deviceid | uuid | guid | vpd | mprom | firm | cpu | dimm | all**\ ]
PPC (with HMC) specific:

30
docs/source/guides/admin-guides/references/man1/rpower.1.rst
View File

@ -23,8 +23,8 @@ SYNOPSIS
\ **rpower**\ [\ **-h | -**\ **-help | -v | -**\ **-version**\ ]
BMC (using IPMI) specific:
==========================
BMC (using IPMI):
=================
\ **rpower**\ \ *noderange*\ [\ **on | off | softoff | reset | boot | stat | state | status | wake | suspend**\ [\ **-w**\ \ *timeout*\ ] [\ **-o**\ ] [\ **-r**\ ]]
@ -32,8 +32,17 @@ BMC (using IPMI) specific:
\ **rpower**\ \ *noderange*\ [\ **pduon | pduoff | pdustat | pdureset**\ ]
OpenBMC specific:
=================
OpenPOWER BMC (using IPMI):
===========================
\ **rpower**\ \ *noderange*\ [\ **on | off | reset | boot | stat | state | status**\ ]
\ **rpower**\ \ *noderange*\ [\ **pduon | pduoff | pdustat | pdureset**\ ]
OpenPOWER OpenBMC:
==================
\ **rpower**\ \ *noderange*\ [\ **off | on | reset | boot | stat | state | status**\ ]
@ -97,6 +106,13 @@ Blade specific:
\ **rpower**\ \ *noderange*\ [\ **cycle | softoff**\ ]
Lenovo High-Density Server specific:
====================================
\ **rpower**\ \ *noderange*\ [\ **on | off | reset | boot | reseat**\ ]
zVM specific:
=============
@ -270,6 +286,12 @@ OPTIONS
\ **reseat**\
For Lenovo high-density servers, simulates unplugging and replugging the node into the chassis.
\ **of**\
Boot the node to open firmware console mode.

9
docs/source/guides/admin-guides/references/man1/rspconfig.1.rst
View File

@ -38,11 +38,18 @@ BMC specific:
=============
\ **rspconfig**\ \ *noderange*\ {\ **vlan | ip | netmask | gateway | backupgateway | garp**\ }
\ **rspconfig**\ \ *noderange*\ {\ **ip | netmask | gateway | backupgateway | garp | vlan**\ }
\ **rspconfig**\ \ *noderange*\ \ **garp**\ =\ *time*\
OpenBMC specific:
=================
\ **rspconfig**\ \ *noderange*\ {\ **ip | netmask | gateway | vlan**\ }
MPA specific:
=============

25
docs/source/guides/admin-guides/references/man1/rvitals.1.rst
View File

@ -56,11 +56,18 @@ BMC specific:
\ **rvitals**\ \ *noderange*\ {\ **temp | voltage | wattage | fanspeed | power | leds | all**\ }
OpenPOWER server specific:
OpenPOWER (IPMI) specific:
==========================
\ **rvitals**\ \ *noderange*\ {\ **temp | voltage | wattage | fanspeed | power | leds | all**\ }
\ **rvitals**\ \ *noderange*\ [\ **temp | voltage | wattage | fanspeed | power | leds | chassis | all**\ ]
OpenPOWER (OpenBMC) specific:
=============================
\ **rvitals**\ \ *noderange*\ [\ **temp | voltage | wattage | fanspeed | power | altitude | all**\ ]
@ -69,7 +76,7 @@ OpenPOWER server specific:
*******************
\ **rvitals**\ retrieves hardware vital information from the on-board Service
\ **rvitals**\ Retrieves hardware vital information from the on-board Service
Processor for a single or range of nodes and groups.
@ -133,6 +140,18 @@ Processor for a single or range of nodes and groups.
\ **chassis**\
Retrieves chassis status.
\ **altitude**\
Retrieves altitude related attributes.
\ **power**\
Retrieves power status.

213
docs/source/guides/admin-guides/references/man1/xcatperftest.1.rst Normal file
View File

@ -0,0 +1,213 @@
##############
xcatperftest.1
##############
.. highlight:: perl
****
NAME
****
\ **xcatperftest**\ - Run xCAT command performance baseline testing on fake nodes.
********
SYNOPSIS
********
\ **xcatperftest**\ [\ **-?|-h**\ ]
[\ **PERF_DRYRUN**\ =y] [\ **PERF_NOCREATE**\ =y] \ **xcatperftest**\ <total> [\ *command-list-file*\ ]
***********
DESCRIPTION
***********
The xcatperftest command runs commandes defined in a command list file and get their execution response time baseline for performance purpose.
The xcatperftest command is part of the xCAT package xCAT-test, and you can run it standalone or leverage it to build up your automation test cases.
Any commands could be defined in the command list file, however, it is recommended that the one-time initial configuration are well prepared prior to run xcatperftest command.
For example, the network object, osdistor and osimage image objects.
Follow the below steps to run xcatperftest command:
1, Install xCAT-test on a xCAT management nodes.
2, Prepare a command list in which the commands are what you want to messure.
3, Prepare the initial configuration based on the command list to make sure all commands could be executed in techinal.
4, Run xcatperftest with the total fake nodes number and the above command list file.
Node: It is suggested to run the command in background as it normally takes long time to finish all the performanc testing with large amount of fake nodes.
*******
OPTIONS
*******
\ **-?|-h**\
Display usage message.
<command-list-file>
Specifies the command list file with full-path. xCAT supports an example command file: /opt/xcat/share/xcat/tools/autotest/perfcmds.lst
<total>
Total number of fake nodes will be defined during the testing.
************
RETURN VALUE
************
0 The command completed successfully.
1 An error has occurred.
*****************
COMMAND LIST FILE
*****************
The command list file is in flat text format, the testing framework will parse the file line by line, here is an example of the commannd list file:
.. code-block:: perl
#SERIES# 1,50,100,250,500,1000,2500,5000
mkdef -z -f < #STANZ#
lsdef #NODES#
makehosts #NODES#
makedns -n #NODES#
makedhcp #NODES#
makeknownhosts #NODES#
nodech #NODES# groups,=group1
nodels #NODES# noderes
nodeset #NODES# osimage=rhels7.3-GA-ppc64le-install-compute
chdef -t node -o #NODES# postscripts="fake" profile="install" netboot="grub2"
rmdef -t node #PERFGRP#
mkdef -z < #STANZ#
noderm #PERFGRP#
\ **Note**\ : Each line defines one command, and the commands dependency should be handled by the line order.
If you define a node range series line (started with #SERIES#) in this file, xcatperftest will run the command for each node range defined in series line.
\ **#SERIES#**\ To define a node range series, and the series should be an comma split incremental number sequence.
\ **#STANZ#**\ It will be replaced with real stanz file path when this command line runs.
\ **#NODES#**\ It will be replaced with real node range defined in #SERIES# line when this command line runs. If no series line, the node group will be used.
\ **#PERFGRP#**\ It will be replaced with node group when this command line runs.
********************
ENVIRONMENT VARIABLE
********************
The xcatperftest command supports be customized by some environment variables.
\ **FAKE_NODE_PREFIX**\
Optional, the prefix of the fake compute node name. By default, the value is 'fake'
\ **FAKE_NODE_GROUP**\
# Optional, the group name of all the fake compute nodes. By default, the value is 'perftest'
\ **FAKE_NETWORK_PRO**\
Mandatory, the Provision network for all the fake compute nodes. By default, the value is '192.168'.
It must be a string like 'A.B', and be matched with \`tabdump networks\`
\ **FAKE_NETWORK_BMC**\
Mandatory, the BMC network for all the fake compute nodes. By default, the value is '192.168'. Note: It could not be the same subnet as 'FAKE_NETWORK_PRO'
It must be a string like 'A.B' and no need to be defined in 'networks' table.
\ **PERF_NODETEMPL**\
Optional, The node template name used for generating fake nodes. By default, it will be auto-detected according to the current arch.
\ **PERF_DRYRUN**\
Optional, Indicate no real commands will be executed if the environment variable is set.
\ **PERF_NOCREATE**\
Optional, Indicate no new fake nodes will be created if the environment variable is set.
********
EXAMPLES
********
1.
To run the performance testing for the commands defined in /tmp/cmd.lst on 5000 fake nodes:
.. code-block:: perl
xcatperftest 5000 /tmp/cmd.lst
2.
To generate an xCAT node object stanz file for 10000 nodes in subnet 10.100.0.0:
.. code-block:: perl
FAKE_NETWORK_PRO=10.100 FAKE_NETWORK_BMC=10.200 xcatperftest 10000
3.
To run the performance testing for the commands defined in /opt/xcat/share/xcat/tools/autotest/perfcmds.lst on 5000 existing fake nodes:
.. code-block:: perl
PERF_NOCREATE=y xcatperftest 5000 /opt/xcat/share/xcat/tools/autotest/perfcmds.lst
*****
FILES
*****
/opt/xcat/bin/xcatperftest
/opt/xcat/share/xcat/tools/autotest/perfcmds.lst

2
docs/source/guides/admin-guides/references/man5/networks.5.rst
View File

@ -138,7 +138,7 @@ networks Attributes:
\ **mtu**\
The default MTU for the network
The default MTU for the network, If multiple networks are applied to the same nic on the SN and/or CN, the MTU shall be the same for those networks.

16
docs/source/guides/admin-guides/references/man5/openbmc.5.rst
View File

@ -19,7 +19,7 @@ SYNOPSIS
********
\ **openbmc Attributes:**\ \ *node*\ , \ *bmc*\ , \ *username*\ , \ *password*\ , \ *comments*\ , \ *disable*\
\ **openbmc Attributes:**\ \ *node*\ , \ *bmc*\ , \ *consport*\ , \ *taggedvlan*\ , \ *username*\ , \ *password*\ , \ *comments*\ , \ *disable*\
***********
@ -27,7 +27,7 @@ DESCRIPTION
***********
Setting for nodes that are controlled by an on-board OpenBmc.
Setting for nodes that are controlled by an on-board OpenBMC.
*******************
@ -48,6 +48,18 @@ openbmc Attributes:
\ **consport**\
The console port for OpenBMC.
\ **taggedvlan**\
bmcsetup script will configure the network interface of the BMC to be tagged to the VLAN specified.
\ **username**\
The BMC userid.

4
docs/source/guides/admin-guides/references/man5/postscripts.5.rst
View File

@ -44,13 +44,13 @@ postscripts Attributes:
\ **postscripts**\
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute.
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute. Please note that the postscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postscripts" attribute of a node with "chdef -m" command
\ **postbootscripts**\
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list.
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. Please note that the postbootscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postbootscripts" attribute of a node with "chdef -m" command

2
docs/source/guides/admin-guides/references/man5/xcatdb.5.rst
View File

@ -567,7 +567,7 @@ notification(5)|notification.5
openbmc(5)|openbmc.5
Setting for nodes that are controlled by an on-board OpenBmc.
Setting for nodes that are controlled by an on-board OpenBMC.

18
docs/source/guides/admin-guides/references/man7/group.7.rst
View File

@ -19,7 +19,7 @@ SYNOPSIS
********
\ **group Attributes:**\ \ *addkcmdline*\ , \ *arch*\ , \ *authdomain*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groupname*\ , \ *grouptype*\ , \ *hcp*\ , \ *height*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *machinetype*\ , \ *membergroups*\ , \ *members*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *modelnum*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *outlet*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *pdu*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *serial*\ , \ *serialflow*\ , \ *serialnum*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *wherevals*\ , \ *xcatmaster*\
\ **group Attributes:**\ \ *addkcmdline*\ , \ *arch*\ , \ *authdomain*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *consport*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groupname*\ , \ *grouptype*\ , \ *hcp*\ , \ *height*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *machinetype*\ , \ *membergroups*\ , \ *members*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *modelnum*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *outlet*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *pdu*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *serial*\ , \ *serialflow*\ , \ *serialnum*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *wherevals*\ , \ *xcatmaster*\
***********
@ -133,7 +133,11 @@ group Attributes:
\ **bmcvlantag**\ (ipmi.taggedvlan)
\ **bmcvlantag**\ (ipmi.taggedvlan, openbmc.taggedvlan)
bmcsetup script will configure the network interface of the BMC to be tagged to the VLAN specified.
or
bmcsetup script will configure the network interface of the BMC to be tagged to the VLAN specified.
@ -193,6 +197,12 @@ group Attributes:
\ **consport**\ (openbmc.consport)
The console port for OpenBMC.
\ **cpucount**\ (hwinv.cpucount)
The number of cpus for the node.
@ -791,13 +801,13 @@ group Attributes:
\ **postbootscripts**\ (postscripts.postbootscripts)
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list.
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. Please note that the postbootscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postbootscripts" attribute of a node with "chdef -m" command
\ **postscripts**\ (postscripts.postscripts)
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute.
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute. Please note that the postscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postscripts" attribute of a node with "chdef -m" command

2
docs/source/guides/admin-guides/references/man7/network.7.rst
View File

@ -89,7 +89,7 @@ network Attributes:
\ **mtu**\ (networks.mtu)
The default MTU for the network
The default MTU for the network, If multiple networks are applied to the same nic on the SN and/or CN, the MTU shall be the same for those networks.

18
docs/source/guides/admin-guides/references/man7/node.7.rst
View File

@ -19,7 +19,7 @@ SYNOPSIS
********
\ **node Attributes:**\ \ *addkcmdline*\ , \ *appstatus*\ , \ *appstatustime*\ , \ *arch*\ , \ *authdomain*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groups*\ , \ *hcp*\ , \ *height*\ , \ *hidden*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *machinetype*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *modelnum*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *node*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *outlet*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *pdu*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *primarysn*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *serial*\ , \ *serialflow*\ , \ *serialnum*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *status*\ , \ *statustime*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *updatestatus*\ , \ *updatestatustime*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *xcatmaster*\ , \ *zonename*\
\ **node Attributes:**\ \ *addkcmdline*\ , \ *appstatus*\ , \ *appstatustime*\ , \ *arch*\ , \ *authdomain*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *consport*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groups*\ , \ *hcp*\ , \ *height*\ , \ *hidden*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *machinetype*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *modelnum*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *node*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *outlet*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *pdu*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *primarysn*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *serial*\ , \ *serialflow*\ , \ *serialnum*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *status*\ , \ *statustime*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *updatestatus*\ , \ *updatestatustime*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *xcatmaster*\ , \ *zonename*\
***********
@ -145,7 +145,11 @@ node Attributes:
\ **bmcvlantag**\ (ipmi.taggedvlan)
\ **bmcvlantag**\ (ipmi.taggedvlan, openbmc.taggedvlan)
bmcsetup script will configure the network interface of the BMC to be tagged to the VLAN specified.
or
bmcsetup script will configure the network interface of the BMC to be tagged to the VLAN specified.
@ -205,6 +209,12 @@ node Attributes:
\ **consport**\ (openbmc.consport)
The console port for OpenBMC.
\ **cpucount**\ (hwinv.cpucount)
The number of cpus for the node.
@ -797,13 +807,13 @@ node Attributes:
\ **postbootscripts**\ (postscripts.postbootscripts)
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list.
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. Please note that the postbootscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postbootscripts" attribute of a node with "chdef -m" command
\ **postscripts**\ (postscripts.postscripts)
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute.
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute. Please note that the postscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postscripts" attribute of a node with "chdef -m" command

8
docs/source/guides/admin-guides/references/man8/makeknownhosts.8.rst
View File

@ -19,7 +19,7 @@ SYNOPSIS
********
\ **makeknownhosts**\ \ *noderange*\ [\ **-r | -**\ **-remove**\ ] [\ **-V | -**\ **-verbose**\ ]
\ **makeknownhosts**\ \ *noderange*\ [\ **-r | -d | -**\ **-remove**\ ] [\ **-V | -**\ **-verbose**\ ]
\ **makeknownhosts**\ [\ **-h | -**\ **-help**\ ]
@ -53,7 +53,7 @@ OPTIONS
\ **-r|-**\ **-remove**\
\ **-r| -d| -**\ **-remove**\
Only removes the entries for the nodes from the known_hosts file.
@ -98,6 +98,10 @@ EXAMPLES
To remove the known_hosts entry for node02
.. code-block:: perl
makeknownhosts node02 -r
or
makeknownhosts node02 -d

4
docs/source/guides/install-guides/common_sections.rst
View File

@ -37,11 +37,11 @@ xCAT consists of two software packages: ``xcat-core`` and ``xcat-dep``
* **Latest Release (Stable) Builds**
*This is the latest GA (Generally Availability) build that has been tested throughly*
*This is the latest GA (Generally Availability) build that has been tested thoroughly*
* **Latest Snapshot Builds**
*This is the latest snapshot of the GA version build that may contain bug fixes but has not yet been tested throughly*
*This is the latest snapshot of the GA version build that may contain bug fixes but has not yet been tested thoroughly*
* **Development Builds**

2
docs/source/guides/install-guides/maintenance/uninstall_xcat.rst
View File

@ -58,7 +58,7 @@ Remove xCAT Files
dpkg -l | awk '/xcat/ { print $2 }'
If you want to remove more cleanly, the list bleow maybe helpful. Listed are the packages of xcat installation tarball. Some RPMs may not to be installed in a specific environment.
If you want to remove more cleanly, the list below maybe helpful. Listed are the packages of xcat installation tarball. Some RPMs may not to be installed in a specific environment.
* XCAT Core Packages list (xcat-core):

2
docs/source/overview/differentiators.rst
View File

@ -18,7 +18,7 @@ Differentiators
IBM Power, IBM Power LE, x86_64
* Support Multiple Virtulization Infrastructures
* Support Multiple Virtualization Infrastructures
IBM PowerKVM, KVM, IBM zVM, ESXI, XEN

22
docs/source/overview/xcat2_release.rst
View File

@ -14,11 +14,19 @@ xCAT 2.13.x
|xCAT |New OS |New |New Feature |
|Version | |Hardware | |
+=================================+===============+=============+==================================+
|| xCAT 2.13.3 |- RHEL 6.9 | |- rpower for OpenBMC(experimental)|
|| 2017/4/7 | | |- Add -C for rmdef to run nodeset |
|| | | | nodeset offline |
| `2.13.3 Release Notes <https:// | | | |
| github.com/xcat2/xcat-core/wiki | | | |
|| xCAT 2.13.4 |- RHV 4.1 | |- OpenBMC support(experimental): |
|| 2017/5/19 | | | |
|| | | | rinv |
| `2.13.4 Release Notes <https:// | | | rinstall |
| github.com/xcat2/xcat-core/wiki | | | bmcdiscover |
| /XCAT_2.13.4_Release_Notes>`_ | | | |
| | | | |
+---------------------------------+---------------+-------------+----------------------------------+
|| xCAT 2.13.3 |- RHEL 6.9 | |- OpenBMC support(experimental): |
|| 2017/4/14 | | | |
|| | | | rpower rcons |
| `2.13.3 Release Notes <https:// | | |- Add -C for rmdef to run |
| github.com/xcat2/xcat-core/wiki | | | `nodeset offline` |
| /XCAT_2.13.3_Release_Notes>`_ | | | |
| | | | |
+---------------------------------+---------------+-------------+----------------------------------+
@ -63,7 +71,7 @@ xCAT 2.12.x
| | | | |
+---------------------------------+---------------+-------------+----------------------------------+
|| xCAT 2.12.3 | | |- GitHub Issues resolved |
|| 2016/09/30 | | |- rinv options for OpenPower |
|| 2016/09/30 | | |- rinv options for OpenPOWER |
|| | | |- switch based switch discovery |
| `2.12.3 Release Notes <https:// | | |- additional options added to |
| github.com/xcat2/xcat-core/wiki | | | xcatprobe command |
@ -116,7 +124,7 @@ xCAT 2.11.x
|| 2015/12/11 |- UBT 14.4.3 LE|- S822LC(GTA)|- Infiniband for OpenPOWER |
|| |- UBT 15.10 LE |- S812LC |- SW KIT support for OpenPOWER |
| `2.11 Release Notes <https:// |- PowerKVM 3.1 |- NeuCloud OP|- renergy command for OpenPOWER |
| github.com/xcat2/xcat-core/ | |- ZoomNet RP |- rflash command for OpenPower |
| github.com/xcat2/xcat-core/ | |- ZoomNet RP |- rflash command for OpenPOWER |
| wiki/XCAT_2.11_Release_Notes>`_ | | |- Add xCAT Troubleshooting Log |
| | | |- xCAT Log Classification |
| | | |- RAID Configuration |

34
perl-xCAT/xCAT/DBobjUtils.pm
View File

@ -675,6 +675,7 @@ sub setobjdefs
# update the tables a row at a time
foreach my $objname (keys %objhash) {
my $obj_need_update = 0;
# get attr=val that are set in the DB ??
my $type = $objhash{$objname}{objtype};
@ -1023,6 +1024,7 @@ sub setobjdefs
$rsp->{data}->[0] =
"access_tabentry \'$this_attr->{access_tabentry}\' is not valid.";
xCAT::MsgUtils->message("E", $rsp, $::callback);
$objhash{$objname}{error} = 1;
next;
}
$lookup_table = $tabentry{'lookup_table'};
@ -1075,19 +1077,26 @@ sub setobjdefs
split(/$delim/, $DBattrvals{$objname}{$attr_name});
my @minusList = split(/$delim/, $objhash{$objname}{$attr_name});
my $operation_failed = 0;
foreach my $em (@minusList) {
if (!(grep { $_ eq $em } @currentList)) {
if (($::opt_t eq 'group') && ($DBattrvals{$objname}{'grouptype'} ne 'dynamic')) {
my $rsp;
$rsp->{data}->[0] = "$objname is not a member of \'$em\'.";
xCAT::MsgUtils->message("W", $rsp, $::callback);
xCAT::MsgUtils->message("E", $rsp, $::callback);
$operation_failed = 1;
} else {
my $rsp;
$rsp->{data}->[0] = "$em is not in the attribute of \'$attr_name\' for the \'$objname\' definition.";
xCAT::MsgUtils->message("W", $rsp, $::callback);
xCAT::MsgUtils->message("E", $rsp, $::callback);
$operation_failed = 1;
}
}
}
if ($operation_failed) {
$objhash{$objname}{error} = 1;
next;
}
# make a new list without the one specified
my $first = 1;
@ -1106,6 +1115,12 @@ sub setobjdefs
}
$val = $newlist;
}
else {
my $rsp;
$rsp->{data}->[0] = "No value got for attribute \'$attr_name\' for the \'$objname\' definition.";
xCAT::MsgUtils->message("E", $rsp, $::callback);
next;
}
} else {
@ -1118,10 +1133,13 @@ sub setobjdefs
# the key is 'tabattrs'
$allupdates{$lookup_table}{$objname}{$attr_name}{'tabattrs'}{$::tabattr} = $val;
$setattrs = 1;
$obj_need_update = 1;
push(@setattrlist, $attr_name);
} # end - foreach attribute
if ($obj_need_update) {
$objhash{$objname}{updated} = 1;
}
my $rsp;
foreach my $att (keys %$invalidattr) {
@ -2503,6 +2521,7 @@ sub judge_node
nicsattr value, like niccsips=eth0!1.1.1.1|2.1.1.1,eth1!3.1.1.1|4.1.1.1
node name, like frame10node10
nicnames: only return the value for specific nics, like "eth0,eth1"
is_group: bool value indicates whether the type of object is group
Returns:
expanded format, like:
nicsips.eth0=1.1.1.1|2.1.1.1
@ -2524,8 +2543,7 @@ sub expandnicsattr()
if (($nicstr) && ($nicstr =~ /xCAT::/)) {
$nicstr = shift;
}
my $node = shift;
my $nicnames = shift;
my ($node, $nicnames, $is_group) = @_;
my $ret;
$nicstr =~ /^(.*?)=(.*?)$/;
@ -2574,8 +2592,10 @@ sub expandnicsattr()
}
}
}
$nicv[1]= xCAT::Table::transRegexAttrs($node, $nicv[1]);
# print group attributes in original format
if (!$is_group) {
$nicv[1]= xCAT::Table::transRegexAttrs($node, $nicv[1]);
}
# ignore the line that does not have nicname or value
if ($nicv[0] && $nicv[1]) {
$ret .= " $nicattr.$nicv[0]=$nicv[1]\n";

1
perl-xCAT/xCAT/FSPvitals.pm
View File

@ -375,7 +375,6 @@ sub rackenv {
push @result, [ $name, $td, $Rc ];
if (!exists($request->{verbose})) {
#if( $td =~ /^Rack altitude in meters/ ) {
if ($td =~ /^BPA-B total output in watts/) {
last;
}

61
perl-xCAT/xCAT/MsgUtils.pm
View File

@ -16,6 +16,7 @@ use xCAT::Utils;
#use locale;
use Socket;
use File::Path;
use constant PERF_LOG => "/var/log/xcat/perf.log";
$::NOK = -1;
$::OK = 0;
@ -823,5 +824,65 @@ sub trace() {
}
}
#------------------------------------------------------------------
=head3 _perf_log
Libary function to write the perf log. Do not use it directly.
=cut
#-----------------------------------------------------------------
sub _perf_log
{
my $type = shift;
my $msg = shift;
my $fh;
my $ret = open($fh, '>>', PERF_LOG);
if (!$ret) {
xCAT::MsgUtils->message("S", "Open perf log file error: $!");
}
my $line = localtime()."\t$type\t$msg\n";
print $fh $line;
close $fh;
}
#------------------------------------------------------------------
=head3 perf_log_info
Trace information for perf
Argument:
$msg (trace message)
=cut
#-----------------------------------------------------------------
sub perf_log_info
{
shift;
my $msg = shift;
_perf_log('info', $msg);
}
#------------------------------------------------------------------
=head3 perf_log_process
Trace process information for perf
Arguments:
$process_type (immediate, plugin, etc)
$req (xcat reqeust)
$msg (additional message, optional)
=cut
#-----------------------------------------------------------------
sub perf_log_process
{
shift;
my ($process_type, $req, $msg, $pid) = @_;
if (defined($req)) {
my $command = $req->{command}->[0];
_perf_log($process_type, "$$\t$command\t$msg");
} else {
_perf_log($process_type, "$pid\t$msg");
}
}
1;

217
perl-xCAT/xCAT/NetworkUtils.pm
View File

@ -19,8 +19,7 @@ use File::Path;
use Math::BigInt;
use Socket;
use xCAT::GlobalDef;
#use Data::Dumper;
use Sys::Hostname;
use strict;
use warnings "all";
my $socket6support = eval { require Socket6 };
@ -229,6 +228,9 @@ sub gethostname()
hostname
Optional:
GetNumber=>1 (return the address as a BigInt instead of readable string)
GetAllAddresses=>1 (return the )
OnlyV6=>1 ()
OnlyV4=> ()
Returns: ip address
Globals:
cache: %::hostiphash
@ -270,69 +272,117 @@ sub getipaddr
# #pass in an ip and only want an ip??
# return $iporhost;
#}
my $isip=0;
if ($iporhost and ($iporhost =~ /\d+\.\d+\.\d+\.\d+/) || ($iporhost =~ /:/)){
$isip=1;
}
#print "============================\n";
#print Dumper(\%::hostiphash);
#print "\n";
#print Dumper(\%extraarguments);
#print "\n";
#print "iporhost=$iporhost";
#print "\n";
#print "============================\n";
#cache, do not lookup DNS each time
if ($::hostiphash and defined($::hostiphash{$iporhost}) && $::hostiphash{$iporhost})
if (
((not $extraarguments{OnlyV6}) and (not $extraarguments{GetAllAddresses})) and defined($::hostiphash{$iporhost}) and $::hostiphash{$iporhost})
{
return $::hostiphash{$iporhost};
if($extraarguments{GetNumber} ) {
if($::hostiphash{$iporhost}{Number}){
#print "YYYYYYYYYY GetNumber Cache Hit!!!YYYYYYYYY\n";
return $::hostiphash{$iporhost}{Number};
}
} elsif($::hostiphash{$iporhost}{hostip}) {
#print "YYYYYYYYYY dns Cache Hit!!!YYYYYYYYY\n";
return $::hostiphash{$iporhost}{hostip};
}
}
if ($socket6support) # the getaddrinfo and getnameinfo supports both IPv4 and IPv6
{
my @returns;
my $reqfamily = AF_UNSPEC;
if ($extraarguments{OnlyV6}) {
$reqfamily = AF_INET6;
} elsif ($extraarguments{OnlyV4}) {
$reqfamily = AF_INET;
}
my @addrinfo;
if($isip) {
@addrinfo=Socket6::getaddrinfo($iporhost, 0, $reqfamily, SOCK_STREAM, 6,Socket6::AI_NUMERICHOST());
}else{
@addrinfo=Socket6::getaddrinfo($iporhost, 0, $reqfamily, SOCK_STREAM, 6);
}
my ($family, $socket, $protocol, $ip, $name) = splice(@addrinfo, 0, 5);
unless($reqfamily == AF_INET6){
if($isip){
if($name){
$::hostiphash{$iporhost}{hostip}=$name;
}
}elsif($ip){
$::hostiphash{$iporhost}{hostip}=$ip;
}
}
while ($ip)
{
if ($extraarguments{GetNumber}) { #return a BigInt for compare, e.g. for comparing ip addresses for determining if they are in a common network or range
my $ip = (Socket6::getnameinfo($ip, Socket6::NI_NUMERICHOST()))[0];
my $bignumber = Math::BigInt->new(0);
foreach (unpack("N*", Socket6::inet_pton($family, $ip))) { #if ipv4, loop will iterate once, for v6, will go 4 times
$bignumber->blsft(32);
$bignumber->badd($_);
}
push(@returns, $bignumber);
$::hostiphash{$iporhost}{Number}=$returns[0];
} else {
push @returns, (Socket6::getnameinfo($ip, Socket6::NI_NUMERICHOST()))[0];
$::hostiphash{$iporhost}{hostip}=$returns[0];
}
if (scalar @addrinfo and $extraarguments{GetAllAddresses}) {
($family, $socket, $protocol, $ip, $name) = splice(@addrinfo, 0, 5);
} else {
$ip = 0;
}
}
unless ($extraarguments{GetAllAddresses}) {
return $returns[0];
}
return @returns;
}
else
{
if ($socket6support) # the getaddrinfo and getnameinfo supports both IPv4 and IPv6
{
my @returns;
my $reqfamily = AF_UNSPEC;
if ($extraarguments{OnlyV6}) {
$reqfamily = AF_INET6;
} elsif ($extraarguments{OnlyV4}) {
$reqfamily = AF_INET;
}
my @addrinfo = Socket6::getaddrinfo($iporhost, 0, $reqfamily, SOCK_STREAM, 6);
my ($family, $socket, $protocol, $ip, $name) = splice(@addrinfo, 0, 5);
while ($ip)
{
if ($extraarguments{GetNumber}) { #return a BigInt for compare, e.g. for comparing ip addresses for determining if they are in a common network or range
my $ip = (Socket6::getnameinfo($ip, Socket6::NI_NUMERICHOST()))[0];
my $bignumber = Math::BigInt->new(0);
foreach (unpack("N*", Socket6::inet_pton($family, $ip))) { #if ipv4, loop will iterate once, for v6, will go 4 times
$bignumber->blsft(32);
$bignumber->badd($_);
}
push(@returns, $bignumber);
} else {
push @returns, (Socket6::getnameinfo($ip, Socket6::NI_NUMERICHOST()))[0];
}
if (scalar @addrinfo and $extraarguments{GetAllAddresses}) {
($family, $socket, $protocol, $ip, $name) = splice(@addrinfo, 0, 5);
} else {
$ip = 0;
}
}
unless ($extraarguments{GetAllAddresses}) {
return $returns[0];
}
return @returns;
}
else
{
#return inet_ntoa(inet_aton($iporhost))
#TODO, what if no scoket6 support, but passing in a IPv6 hostname?
if ($iporhost =~ /:/) { #ipv6
return undef;
#return inet_ntoa(inet_aton($iporhost))
#TODO, what if no scoket6 support, but passing in a IPv6 hostname?
if ($iporhost =~ /:/) { #ipv6
return undef;
#die "Attempt to process IPv6 address, but system does not have requisite IPv6 perl support";
}
my $packed_ip;
$iporhost and $packed_ip = inet_aton($iporhost);
if (!$packed_ip)
{
return undef;
}
if ($extraarguments{GetNumber}) { #only 32 bits, no for loop needed.
return Math::BigInt->new(unpack("N*", $packed_ip));
}
return inet_ntoa($packed_ip);
#die "Attempt to process IPv6 address, but system does not have requisite IPv6 perl support";
}
my $packed_ip;
$iporhost and $packed_ip = inet_aton($iporhost);
if (!$packed_ip)
{
return undef;
}
my $myip=inet_ntoa($packed_ip);
unless($isip) {
$::hostiphash{$iporhost}{hostip}=$myip;
}
if ($extraarguments{GetNumber}) { #only 32 bits, no for loop needed.
my $number=Math::BigInt->new(unpack("N*", $packed_ip));
$::hostiphash{$iporhost}{Number}=$number;
return $number;
}
return $myip;
}
}
@ -417,7 +467,7 @@ sub linklocaladdr {
=cut
#-------------------------------------------------------------------------------
sub ishostinsubnet {
sub ishostinsubnet{
my ($class, $ip, $mask, $subnet) = @_;
#safe guard
@ -425,6 +475,40 @@ sub ishostinsubnet {
{
return 0;
}
my $maskType=0;
#CIDR notation supported
if ($subnet && ($subnet =~ /\//)) {
($subnet, $mask) = split /\//, $subnet, 2;
$subnet =~ s/\/.*$//;
$maskType=1;
}elsif ($mask) {
if ($mask =~ /\//) {
$mask =~ s/^\///;
$maskType=1;
} elsif($mask =~ /^0x/i ) {
$maskType=2;
}
}
my $ret=xCAT::NetworkUtils::isInSameSubnet( $ip, $subnet, $mask, $maskType);
if(defined $ret and $ret==1){
return 1;
}else{
return 0;
}
}
sub ishostinsubnet_orig {
my ($class, $ip, $mask, $subnet) = @_;
#safe guard
if (!defined($ip) || !defined($mask) || !defined($subnet))
{
return 0;
}
my $numbits = 32;
if ($ip =~ /:/) { #ipv6
$numbits = 128;
@ -1314,7 +1398,7 @@ sub formatNetmask
Returns:
1: they are in same subnet
2: not in same subnet
undef: not in same subnet
Globals:
none
@ -1853,16 +1937,13 @@ sub get_subnet_aix
sub determinehostname
{
my $hostname;
my $hostnamecmd = "/bin/hostname";
my @thostname = xCAT::Utils->runcmd($hostnamecmd, 0);
if ($::RUNCMD_RC != 0)
{ # could not get hostname
xCAT::MsgUtils->message("S",
"Error $::RUNCMD_RC from $hostnamecmd command\n");
exit $::RUNCMD_RC;
eval {
$hostname = hostname;
};
if($@){
xCAT::MsgUtils->message("S","Fail to get hostname: $@\n");
exit -1;
}
$hostname = $thostname[0];
#get all potentially valid abbreviations, and pick the one that is ok
#by 'noderange'
my @hostnamecandidates;

2
perl-xCAT/xCAT/ProfiledNodeUtils.pm
View File

@ -1365,7 +1365,7 @@ sub gen_chain_for_profiles {
#run bmcsetups.
#PowerNV nodes can't use 'runcmd=bmcsetup' to set BMC.
#But OpenPower need to support bmcsetup
#But OpenPOWER need to support bmcsetup
my $nodehmtab = xCAT::Table->new('nodehm');
my $comments = "";
my $nodehmtab_entry = $nodehmtab->getNodeAttribs($hwprofile, ['comments']);

11
perl-xCAT/xCAT/Schema.pm
View File

@ -446,7 +446,7 @@ passed as argument rather than by table value',
openbmc => {
cols => [qw(node bmc consport taggedvlan username password comments disable)],
keys => [qw(node)],
table_desc => 'Setting for nodes that are controlled by an on-board OpenBmc.',
table_desc => 'Setting for nodes that are controlled by an on-board OpenBMC.',
descriptions => {
node => 'The node name or group name.',
bmc => 'The hostname of the BMC adapter.',
@ -893,8 +893,8 @@ passed as argument rather than by table value',
table_desc => 'The scripts that should be run on each node after installation or diskless boot.',
descriptions => {
node => 'The node name or group name.',
postscripts => 'Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute.',
postbootscripts => 'Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list.',
postscripts => 'Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute. Please note that the postscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postscripts" attribute of a node with "chdef -m" command',
postbootscripts => 'Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. Please note that the postbootscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postbootscripts" attribute of a node with "chdef -m" command',
comments => 'Any user-written notes.',
disable => "Set to 'yes' or '1' to comment out this row.",
},
@ -2305,6 +2305,11 @@ my @nodeattrs = (
tabentry => 'mp.nodetype',
access_tabentry => 'mp.node=attr:node',
},
{ attr_name => 'hwtype',
only_if => 'mgt=openbmc',
tabentry => 'mp.nodetype',
access_tabentry => 'mp.node=attr:node',
},
{ attr_name => 'supernode',
tabentry => 'ppc.supernode',
access_tabentry => 'ppc.node=attr:node',

Some files were not shown because too many files have changed in this diff Show More