xCAT/xcat-core
2
0
Fork 0
mirror of https://github.com/xcat2/xcat-core.git synced 2025-06-15 10:50:28 +00:00
Code Issues Releases Wiki Activity

Merge branch 'master' into ZVM_XCAT_DEV

Browse Source
This commit is contained in:
Chuck Brazie
2017-06-12 08:07:38 -04:00
committed by GitHub
parent a93190189e cd1ad380d0
commit e8aa65e5fe
270 changed files with 4366 additions and 2093 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

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

176
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,8 +566,8 @@ 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,8 +597,8 @@ 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,8 +628,8 @@ 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,8 +659,8 @@ 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,8 +1129,8 @@ 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,8 +1162,8 @@ 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,8 +1347,8 @@ 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,8 +1374,8 @@ 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,8 +1487,8 @@ 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,8 +1512,8 @@ 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,8 +1637,8 @@ 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,8 +1657,8 @@ 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,8 +1954,8 @@ 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,8 +2025,8 @@ 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,8 +2047,8 @@ 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,12 +2115,12 @@ 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.

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

@ -24,8 +24,8 @@ 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.

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

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

@ -1,11 +1,11 @@
IBM Power LE / OpenPOWER
IBM POWER LE / OpenPOWER
=========================
Most of the content is general information for xCAT, the focus and examples are for management of IBM OpenPower servers.
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**]
IBM OpenPOWER Servers
* based on POWER8 Processor Technology is IPMI managed
* based on POWER9 Processor Technology is OpenBMC managed [**Alpha**]
.. toctree::

6
docs/source/guides/admin-guides/manage_clusters/ppc64le/management/basic/rcons.rst
View File

@ -7,11 +7,11 @@ Most enterprise servers do not have video adapters installed with the machine an
Configure the correct console management by modifying the node definition:
* For OpenPower, **IPMI** managed server: ::
* For OpenPOWER, **IPMI** managed server: ::
chdef -t node -o <noderange> cons=ipmi
* For OpenPower, **OpenBMC** managed servers: ::
* For OpenPOWER, **OpenBMC** managed servers: ::
chdef -t node -o <noderange> cons=openbmc
@ -46,7 +46,7 @@ The xCAT ``rcons`` command relies on conserver (http://www.conserver.com/). The
OpenBMC Specific
```````````````
````````````````
#. For OpenBMC managed servers, the root user must be able to ssh passwordless to the BMC for the ``rcons`` function to work.

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 :

4
docs/source/guides/admin-guides/references/man1/bmcdiscover.1.rst
View File

@ -35,7 +35,7 @@ DESCRIPTION
***********
The \ **bmcdiscover**\ command will discover Baseboard Management Controllers (BMCs) using a scan mathod.
The \ **bmcdiscover**\ command will discover Baseboard Management Controllers (BMCs) using a scan method.
The command uses \ **nmap**\ to scan active nodes over a specified IP range. The IP range format should be a format that is acceptable by \ **nmap**\ .
@ -52,7 +52,7 @@ OPTIONS
\ **-**\ **-range**\
Specify one or more IP ranges acceptable to nmap. IP rance can be hostnames, IP addresses, networks, etc. A single IP address (10.1.2.3) or an IP range (10.1.2.0/24) can be specified. If the range is very large, the \ **bmcdiscover**\ command may take a long time to return.
Specify one or more IP ranges acceptable to nmap. IP range can be hostnames, IP addresses, networks, etc. A single IP address (10.1.2.3) or an IP range (10.1.2.0/24) can be specified. If the range is very large, the \ **bmcdiscover**\ command may take a long time to return.

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

@ -98,7 +98,7 @@ OPTIONS
be owned by vdsm:kvm.
\ **localfs**\ : "/data/images/rhev" is set by default.
\ **virtsd.host**\ - A host must be specified for a storage doamin as SPM
\ **virtsd.host**\ - A host must be specified for a storage domain as SPM
(Storage Pool Manager) when initialize the storage domain. The role of SPM
may be migrated to other host by rhev-m during the running of the datacenter
(For example, when the current SPM encountered issue or going to maintenance

6
docs/source/guides/admin-guides/references/man1/chvm.1.rst
View File

@ -151,7 +151,7 @@ PPC (using Direct FSP Management) specific:
For Power 755(use option \ *--p775*\ to specify):
chvm could be used to change the octant configuration values for generating LPARs. chvm is designed to set the Octant configure value to split the CPU and memory for partitions, and set Octant Memory interleaving value. The chvm will only set the pending attributes value. After chvm, the CEC needs to be rebooted manually for the pending values to be enabled. Before reboot the cec, the administrator can use chvm to change the partition plan. If the the partition needs I/O slots, the administrator should use chvm to assign the I/O slots.
chvm could be used to change the octant configuration values for generating LPARs. chvm is designed to set the Octant configure value to split the CPU and memory for partitions, and set Octant Memory interleaving value. The chvm will only set the pending attributes value. After chvm, the CEC needs to be rebooted manually for the pending values to be enabled. Before reboot the cec, the administrator can use chvm to change the partition plan. If the partition needs I/O slots, the administrator should use chvm to assign the I/O slots.
chvm is also designed to assign the I/O slots to the new LPAR. Both the current IO owning lpar and the new IO owning lpar must be powered off before an IO assignment. Otherwise, if the I/O slot is belonged to an Lpar and the LPAR is power on, the command will return an error when trying to assign that slot to a different lpar.
@ -166,7 +166,7 @@ zVM specific:
=============
The chvm command modifes the virtual machine's configuration specified in noderange.
The chvm command modifies the virtual machine's configuration specified in noderange.
@ -336,7 +336,7 @@ VMware/KVM specific:
\ **-**\ **-resize**\ \ *disk*\ =\ *size*\
Change the size of the Hard disk. The disk in \ *qcow2*\ format can not be set to less than it's current size. The disk in \ *raw*\ format can be resized smaller, use caution. Multiple disks can be resized by using comma separated \ *disk*\ \ **=**\ \ *size*\ pairs. The disks are specified by SCSI id. Size defaults to GB.
Change the size of the Hard disk. The disk in \ *qcow2*\ format can not be set to less than its current size. The disk in \ *raw*\ format can be resized smaller, use caution. Multiple disks can be resized by using comma separated \ *disk*\ \ **=**\ \ *size*\ pairs. The disks are specified by SCSI id. Size defaults to GB.

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

@ -29,7 +29,7 @@ DESCRIPTION
***********
The csm2xcat command must be run on the Management Server of the CSM system that you want to migrate to xCAT. The commmand will build two xCAT stanza files that can update the xCAT database with the chdef command.
The csm2xcat command must be run on the Management Server of the CSM system that you want to migrate to xCAT. The command will build two xCAT stanza files that can update the xCAT database with the chdef command.
Copy the csm2xcat command to the CSM Management Server. Run the command, indicating where you want your stanza files saved with the \ **-**\ **-dir**\ parameter. Check the stanza files to see if the information is what you want put in the xCAT database. Copy the two stanza files: node.stanza, device.stanza back to your xCAT Management node, and run the chdef command to input into the xCAT database.

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

@ -46,7 +46,7 @@ For full information on the setup of DB2, see Setting_Up_DB2_as_the_xCAT_DB.
When running of db2sqlsetup on the MN:
One password must be supplied for the setup, a password for the xcatdb unix id which will be used as the DB2 instance id and database name. The password will be prompted for interactively or can be input with the XCATDB2PW environment variable.
The script will create the xcat database instance (xcatdb) in the /var/lib/db2 directory unless overriden by setting the site.databaseloc attribute. This attribute should not be set to the directory that is defined in the installloc attribute and it is recommended that the databaseloc be a new filesystem dedicated to the DB2 database, especially in very large clusters.
The script will create the xcat database instance (xcatdb) in the /var/lib/db2 directory unless overridden by setting the site.databaseloc attribute. This attribute should not be set to the directory that is defined in the installloc attribute and it is recommended that the databaseloc be a new filesystem dedicated to the DB2 database, especially in very large clusters.
When running db2sqlseutp on the SN:
Not only will the password for the DB2 instance Id be prompted for and must match the one on the Management Node; but also the hostname or ip address of the Management Node as known by the Service Node must be supplied , unless the XCATDB2SERVER environment variable is set.

4
docs/source/guides/admin-guides/references/man1/dumpxCATdb.1.rst
View File

@ -35,7 +35,7 @@ If not using the binary dump option (-b), then the dumpxCATdb command creates .c
Supports using XCAT_SKIPTABLES env variable to provide a list of skip tables.
The command will never backup TEAL or ISNM tables, except isnm_config. To dump TEAL tables use the documented process for TEAL. For ISNM use tabdump, after using tabprune to get to prune unnecessary records.
If using the binary dump option for the DB2 or postgreSQL database, then the routine will use the Database provide utilites for backup of the entire database.
If using the binary dump option for the DB2 or postgreSQL database, then the routine will use the Database provide utilities for backup of the entire database.
*******
@ -49,7 +49,7 @@ OPTIONS
\ **-V**\ Verbose.
\ **-a**\ All,without this flag the eventlog and auditlog will be skipped.
\ **-a**\ All, without this flag the eventlog and auditlog will be skipped.
\ **-b**\ This flag is only used for the DB2 or postgreSQL database. The routine will use the database backup utilities to create a binary backup of the entire database. Note to use this backup on DB2, you will have first had to modify the logging of the database and have taken an offline initial backup. Refer to the xCAT DB2 documentation for more instructions.

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

@ -46,7 +46,7 @@ for stateless: \ **packimage**\
for statelite: \ **liteimg**\
Besides prompting for some paramter values, the \ **genimage**\ command takes default guesses for the parameters not specified or not defined in the \ *osimage*\ and \ *linuximage*\ tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Use \ **-**\ **-interactive**\ flag if you want the yum/zypper command to prompt you for the answers.
Besides prompting for some parameter values, the \ **genimage**\ command takes default guesses for the parameters not specified or not defined in the \ *osimage*\ and \ *linuximage*\ tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Use \ **-**\ **-interactive**\ flag if you want the yum/zypper command to prompt you for the answers.
If \ **-**\ **-onlyinitrd**\ is specified, genimage only regenerates the initrd for a stateless image to be used for a diskless install.

6
docs/source/guides/admin-guides/references/man1/geninitrd.1.rst
View File

@ -43,7 +43,7 @@ If the initrd has been rebuilt by geninitrd, when run nodeset, the \ *--noupdate
should be used to skip the rebuilding of initrd to improve the performance.
Three attributes of osimage object can be used to specify the Driver RPM location and Driver names
for injecting new drviers to initrd.
for injecting new drivers to initrd.
\ **netdrivers**\ - comma separated driver names that need to be injected to the initrd.
The postfix '.ko' can be ignored. The netdrivers attribute must be set to specify the new driver list.
@ -65,7 +65,7 @@ this command is used to generate the initrd from the rootimg which generated by
So the 'genimage' must be run once before running the geninitrd command.
Two attributes of osimage object can be used to specify the Driver RPM location and Driver names
for injecting new drviers to initrd.
for injecting new drivers to initrd.
\ **netdrivers**\ - comma separated driver names that need to be injected to the initrd.
The postfix '.ko' can be ignored. The netdrivers attribute must be set to specify the new driver list.
@ -79,7 +79,7 @@ Parameters
**********
\ *imagename*\ specifies the name of an os image definition to be used. The specification for the image is storted in the \ *osimage*\ table and \ *linuximage*\ table.
\ *imagename*\ specifies the name of an os image definition to be used. The specification for the image is stored in the \ *osimage*\ table and \ *linuximage*\ table.
\ **-**\ **-ignorekernelchk**\

4
docs/source/guides/admin-guides/references/man1/getadapter.1.rst
View File

@ -35,8 +35,8 @@ Traditionally, network interfaces in Linux are enumerated as eth[0123...], but t
\ **getadapter**\ For each node within the <noderange>, follows below scheme:
If the target node is scaned for the first time, \ **getadapter**\ will trigger genesis to collect information then save the information at the \ **nicsadapter**\ column of nics table.
If the target node has ever been scaned, \ **getadapter**\ will use the information from nics table first.
If the target node is scanned for the first time, \ **getadapter**\ will trigger genesis to collect information then save the information at the \ **nicsadapter**\ column of nics table.
If the target node has ever been scanned, \ **getadapter**\ will use the information from nics table first.
If user hopes to scan the adapter information for the node but these information already exist, \ **-f**\ option can be used to start rescan process.
\ **getadapter**\ tries to collect more information for the target network device, but doesn't guarantee collect same much information for every network device.

12
docs/source/guides/admin-guides/references/man1/getmacs.1.rst
View File

@ -51,12 +51,12 @@ DESCRIPTION
The getmacs command collects MAC address from a single or range of nodes.
Note that on AIX systems, the returned MAC address is not colon-seperated (for example 8ee2245cf004), while on Linux systems the MAC address is colon-seperated (for example 8e:e2:24:5c:f0:04).
Note that on AIX systems, the returned MAC address is not colon-separated (for example 8ee2245cf004), while on Linux systems the MAC address is colon-separated (for example 8e:e2:24:5c:f0:04).
If no ping test performed, getmacs writes the first adapter MAC to the xCAT database. If ping test performed, getmacs will write the first successfully pinged MAC to xCAT database.
For PPC (using Direct FSP Management) specific:
Note: If network adapters are physically assigned to LPARs, getmacs cannot read the MAC addresses unless perform \ **Discovery**\ with option "\ **-D**\ ", since there is no HMC command to read them and getmacs has to login to open formware. And if the LPARs has never been activated before, getmacs need to be performed with the option "\ **-D**\ " to get theirs MAC addresses.
Note: If network adapters are physically assigned to LPARs, getmacs cannot read the MAC addresses unless perform \ **Discovery**\ with option "\ **-D**\ ", since there is no HMC command to read them and getmacs has to login to open firmware. And if the LPARs has never been activated before, getmacs need to be performed with the option "\ **-D**\ " to get theirs MAC addresses.
For PPC (using HMC) specific:
@ -74,7 +74,7 @@ OPTIONS
\ **-**\ **-arp**\
Read MAC address with ARP protocal.
Read MAC address with ARP protocol.
\ **-C**\
@ -90,7 +90,7 @@ Perform discovery for mac address. By default, it will run ping test to test th
\ **-f**\
Force immediate shutdown of the partition.This flag must be used with -D flag.
Force immediate shutdown of the partition. This flag must be used with -D flag.
\ **-F**\
@ -118,7 +118,7 @@ Read MAC address when the lpar is in openfirmware state. This option mush be us
\ **-S**\
The IP address of the machine to ping. The default is to read from xCAT databse if no \ **-S**\ specified.
The IP address of the machine to ping. The default is to read from xCAT database if no \ **-S**\ specified.
\ **-v**\
@ -167,7 +167,7 @@ Output is similar to:
ent U78A1.001.99203B5-P1-T6 00145eb55788 /lhea@23c00614/ethernet@23e00514 unsuccessful physical
2. To retrieve the MAC address with ARP protocal:
2. To retrieve the MAC address with ARP protocol:
.. code-block:: perl

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

@ -33,7 +33,7 @@ This tool will build a directory of files, one for each defined
nodegroup in xCAT. The file will be named the nodegroup name and
contain a list of nodes that belong to the nodegroup.
The file can be used as input to the AIX dsh command.
The purpose of this tool is to allow backward compatiblity with scripts
The purpose of this tool is to allow backward compatibility with scripts
that were created using the AIX or CSM dsh command
Reference: man dsh.

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

@ -61,7 +61,7 @@ For statelite:
where x is the name of the profile.
Any files specified by the \ **-e**\ flag will also be exported. If \ **-p**\ flag is specified, the names of the postscripts and the postbootscripts for the given node will be exported. The postscripts themsleves need to be manualy exported using \ **-e**\ flag.
Any files specified by the \ **-e**\ flag will also be exported. If \ **-p**\ flag is specified, the names of the postscripts and the postbootscripts for the given node will be exported. The postscripts themselves need to be manualy exported using \ **-e**\ flag.
For statelite, the litefile table settings for the image will also be exported. The litetree and statelite tables are not exported.

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

@ -69,7 +69,7 @@ If \ **-p**\ flag is specified, the \ *postscripts*\ table will be updated wit
If \ **-f**\ flag is not specified, all the files will be copied to the same directories as the source. If it is specified, the old profile name x will be changed to the new and the files will be copied to the appropriate directores for the new profiles. For example, \ */opt/xcat/share/xcat/netboot/sles/x.pkglist*\ will be copied to \ */install/custom/netboot/sles/compute_new.pkglist*\ and \ */install/netboot/sles11/ppc64/x/kernel*\ will be copied to \ */install/netboot/sles11/ppc64/compute_new/kernel*\ . This flag is commonly used when you want to copy the image on the same xCAT mn so you can make modification on the new one.
After this command, you can run the \ **nodeset**\ command and then start deploying the nodes. You can also choose to modify the files and run the following commands before the node depolyment.
After this command, you can run the \ **nodeset**\ command and then start deploying the nodes. You can also choose to modify the files and run the following commands before the node deployment.
For stateful:
nodeset

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

@ -63,7 +63,7 @@ PARAMETERS
**********
\ *imagename*\ specifies the name of a os image definition to be used. The specification for the image is storted in the \ *osimage*\ table and \ *linuximage*\ table.
\ *imagename*\ specifies the name of a os image definition to be used. The specification for the image is stored in the \ *osimage*\ table and \ *linuximage*\ table.
*******

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

@ -38,7 +38,7 @@ There are several concepts to support the HX5 multiple blades combination:
\ **Complex**\ : Multiple blades which combined by a scalability card is a complex.
\ **Parition**\ : A logic concept which containing part of the \ **Blade slot node**\ in a complex. Each partition can map to a system to install Operating System. Each partition could have 1HX5, 1HX5+1MD or 2HX5+2MD. (MD is the Memory Drawer)
\ **Partition**\ : A logic concept which containing part of the \ **Blade slot node**\ in a complex. Each partition can map to a system to install Operating System. Each partition could have 1HX5, 1HX5+1MD or 2HX5+2MD. (MD is the Memory Drawer)
\ **Blade slot node**\ : The physical blade which installed in the slot of a chassis. It can be a HX5 or MD.

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

@ -89,7 +89,7 @@ OPTIONS
</data>
Each <kitinfo> tag contains info for a group of kit compoonents belonging to the same kit. The info inside <kitinfo> is structured as follows:
Each <kitinfo> tag contains info for a group of kit components belonging to the same kit. The info inside <kitinfo> is structured as follows:
.. code-block:: perl

14
docs/source/guides/admin-guides/references/man1/lsslp.1.rst
View File

@ -41,13 +41,13 @@ OPTIONS
*******
\ **noderange**\ The nodes which the user want to discover. If the user specify the noderange, lsslp will just return the nodes in the node range. Which means it will help to add the new nodes to the xCAT database without modifying the existed definitions. But the nodes' name specified in noderange should be defined in database in advance. The specified nodes' type can be frame/cec/hmc/fsp/bpa. If the it is frame or cec, lsslp will list the bpa or fsp nodes within the nodes(bap for frame, fsp for cec). Do not use noderange with the flag -s.
\ **noderange**\ The nodes which the user wants to discover. If the user specifies the noderange, lsslp will just return the nodes in the node range. Which means it will help to add the new nodes to the xCAT database without modifying the existed definitions. But the nodes' name specified in noderange should be defined in database in advance. The specified nodes' type can be frame/cec/hmc/fsp/bpa. If the it is frame or cec, lsslp will list the bpa or fsp nodes within the nodes(bap for frame, fsp for cec). Do not use noderange with the flag -s.
\ **-i**\ IP(s) the command will send out (defaults to all available adapters).
\ **-h**\ Display usage message.
\ **-n**\ Only display and write the newly discovered hardwares.
\ **-n**\ Only display and write the newly discovered hardware.
\ **-u**\ Do unicast to a specified IP range. Must be used with \ **-s**\ and \ **-**\ **-range**\ . The \ **-u**\ flag is not supported on AIX.
@ -55,15 +55,15 @@ OPTIONS
\ **-r**\ Display Raw SLP response.
\ **-C**\ The number of the expected responses specified by the user. When using this flag, lsslp will not return until the it has found all the nodes or time out. The default max time is 3 secondes. The user can use -T flag the specify the time they want to use. A short time will limite the time costing, while a long time will help to find all the nodes.
\ **-C**\ The number of the expected responses specified by the user. When using this flag, lsslp will not return until the it has found all the nodes or time out. The default max time is 3 seconds. The user can use -T flag the specify the time they want to use. A short time will limit the time costing, while a long time will help to find all the nodes.
\ **-T**\ The number in seconds to limite the time costing of lsslp.
\ **-T**\ The number in seconds to limit the time of lsslp.
\ **-s**\ Service type interested in discovering.
\ **-t**\ Number or service-request attempts.
\ **-**\ **-vpdtable**\ Output the SLP response in vpdtable formatting. Easy for writting data to vpd table.
\ **-**\ **-vpdtable**\ Output the SLP response in vpdtable formatting. Easy for writing data to vpd table.
\ **-v**\ Command Version.
@ -73,9 +73,9 @@ OPTIONS
\ **-x**\ XML format.
\ **-z**\ Stanza formated output.
\ **-z**\ Stanza formatted output.
\ **-I**\ Give the warning message for the nodes in database which have no SLP responses. Note that this flag noly can be used after the database migration finished successfully.
\ **-I**\ Give the warning message for the nodes in database which have no SLP responses. Note that this flag can only be used after the database migration finished successfully.
************

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

@ -29,7 +29,7 @@ DESCRIPTION
***********
The \ **lstree**\ command can display the tree of service node hierarchy for the xCAT nodes which have service node defined or which are service nodes, display the tree of hardware hierarchy only for the physical objects, display the tree of VM hierarchy for the xCAT nodes which are virtual machines or which are the hosts of virtual machines. If a noderange is specified, only show the part of the hierarchy that involves those nodes. For ZVM, we only support to disply VM hierarchy. By default, lstree will show both the hardware hierarchy and the VM hierarchy for all the nodes.
The \ **lstree**\ command can display the tree of service node hierarchy for the xCAT nodes which have service node defined or which are service nodes, display the tree of hardware hierarchy only for the physical objects, display the tree of VM hierarchy for the xCAT nodes which are virtual machines or which are the hosts of virtual machines. If a noderange is specified, only show the part of the hierarchy that involves those nodes. For ZVM, we only support to display VM hierarchy. By default, lstree will show both the hardware hierarchy and the VM hierarchy for all the nodes.
*******

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

@ -360,7 +360,7 @@ Output is similar to:
Available BSR array: 256
Note: The lines listed in "All Physical I/O info" section represent all the physical I/O resource information. The format is like "owner_lparid,slot_id,physical resource name,drc_index,slot_class_code(class discription)". The 'drc index' is short for Dynamic Resource Configuration Index, it uniquely indicates a physical I/O resource in a normal power machine.
Note: The lines listed in "All Physical I/O info" section represent all the physical I/O resource information. The format is like "owner_lparid,slot_id,physical resource name,drc_index,slot_class_code(class description)". The 'drc index' is short for Dynamic Resource Configuration Index, it uniquely indicates a physical I/O resource in a normal power machine.
9. For DFM-managed partition on normal power machine, list out the detailed information:

4
docs/source/guides/admin-guides/references/man1/mkdef.1.rst
View File

@ -84,7 +84,7 @@ OPTIONS
\ **-**\ **-template**\ \ *template-object-name*\
Name of the xCAT shipped object definition template or an existing object, from which the new object definition will be created. The newly created object will inherit the attributes of the template definition unless the attribute is specified in the arguments of \ **mkdef**\ command. If there are a template and an existing object with the same name \ *template-object-name*\ , the tempalte object takes precedence over the existing object. For the details of xCAT shipped object definition templates, refer to the manpage of \ **-**\ **-template**\ option in lsdef(1)|lsdef.1.
Name of the xCAT shipped object definition template or an existing object, from which the new object definition will be created. The newly created object will inherit the attributes of the template definition unless the attribute is specified in the arguments of \ **mkdef**\ command. If there are a template and an existing object with the same name \ *template-object-name*\ , the template object takes precedence over the existing object. For the details of xCAT shipped object definition templates, refer to the manpage of \ **-**\ **-template**\ option in lsdef(1)|lsdef.1.
@ -96,7 +96,7 @@ OPTIONS
\ **-w**\ \ *attr==val*\ \ **-w**\ \ *attr=~val*\ ...
Use one or multiple -w flags to specify the selection string that can be used to select objects. The operators ==, !=, =~ and !~ are available. For mkdef commmand, the -w flag only makes sense for creating dynamic node group. Use the help option to get a list of valid attributes for each object type.
Use one or multiple -w flags to specify the selection string that can be used to select objects. The operators ==, !=, =~ and !~ are available. For mkdef command, the -w flag only makes sense for creating dynamic node group. Use the help option to get a list of valid attributes for each object type.
Operator descriptions:
== Select nodes where the attribute value is exactly this value.

4
docs/source/guides/admin-guides/references/man1/mkdocker.1.rst
View File

@ -137,7 +137,7 @@ Output is similar to:
host01c01: Pull image ubuntu start
host01c01: Pull image ubuntu done
host01c01: Remove default network connection
host01c01: Connecting customzied network 'mynet0'
host01c01: Connecting customized network 'mynet0'
host01c01: success
@ -155,7 +155,7 @@ Output is similar to:
.. code-block:: perl
host01c01: Remove default network connection
host01c01: Connecting customzied network 'mynet0'
host01c01: Connecting customized network 'mynet0'
host01c01: success

6
docs/source/guides/admin-guides/references/man1/mkdsklsnode.1.rst
View File

@ -38,7 +38,7 @@ This command will also create a NIM resolv_conf resource to be used when install
The "domain" and "nameservers" attributes can be set in either the xCAT "network" definition used by the nodes or in the xCAT cluster "site" definition. The setting in the "network" definition will take priority.
The "search" field of the resolv.conf file will contain a list all the domains
listed in the xCAT network definitions and the xCAT site definiton.
listed in the xCAT network definitions and the xCAT site definition.
The "nameservers" value can either be set to a specific IP address or the "<xcatmaster>" key word. The "<xcatmaster>" key word means that the value of the "xcatmaster" attribute of the node definition will be used in the /etc/resolv.conf file. (I.e. The name of the install server as known by the node.)
@ -57,11 +57,11 @@ You can use the "-n" option of the mkdsklsnode command to create and initialize
\ **Note:**\ When using the "-n" option make sure that the new osimage you specify and all the NIM resources that are used are different than what are currently being used on the nodes. The NIM resources should not be shared between the old osimage and the new osimage.
You can use the force option to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinititializing. Use this option with caution since reinitializing a node will stop the node if it is currently running.
You can use the force option to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinitializing. Use this option with caution since reinitializing a node will stop the node if it is currently running.
After the mkdsklsnode command completes you can use the \ **lsnim**\ command to check the NIM node definition to see if it is ready for booting the node. ("lsnim -l <nim_node_name>").
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **mkdsklsnode**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts dirctory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **mkdsklsnode**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **mkdsklsnode**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *diskless:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current current nodeset action, in this case "diskless". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes.
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **mkdsklsnode**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts directory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **mkdsklsnode**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **mkdsklsnode**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *diskless:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "diskless". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at a time. If it is not specified, the script will be invoked once for all the nodes.
*******

12
docs/source/guides/admin-guides/references/man1/mknimimage.1.rst
View File

@ -43,7 +43,7 @@ When creating a mksysb image definition you must specify either the "-n" or the
When creating a diskless osimage definition you also have the option of automatically updating the NIM SPOT resource. You can have additional software installed or you can have configuration files added or updated. To have software installed you must provide either the names of NIM installp_bundle resources or fileset names on the command line using the "attr=val" option. You may also supply the installp flags, RPM flags, emgr flags to use when installing the software.
To have configuration files updated you must provide the full path name of a "synclists" file which contains the the list of actual files to update. The xCAT osimage definition that is created will contain the installp_bundle, otherpkgs, and synclists files that are provided on the command line.
To have configuration files updated you must provide the full path name of a "synclists" file which contains the list of actual files to update. The xCAT osimage definition that is created will contain the installp_bundle, otherpkgs, and synclists files that are provided on the command line.
\ **Updating an existing xCAT osimage**\
@ -69,7 +69,7 @@ You can use the "-i" and "-p" options to copy an existing diskless osimage. To
- any other resources (or attributes) included in the original osimage will be included in the new osimage definition.
- if the "-p" option is specified then the original NIM lpp_source resource will be copied to a new location and redfined to NIM. (The default would be to use the original lpp_source - to save file system space.)
- if the "-p" option is specified then the original NIM lpp_source resource will be copied to a new location and redefined to NIM. (The default would be to use the original lpp_source - to save file system space.)
\ **Additional information**\
@ -85,7 +85,7 @@ To list a NIM resource definition use the AIX \ **lsnim**\ command ("lsnim -l <
To check the validity of a SPOT or lpp_source resource use the AIX \ **nim**\ command ("nim -o check <resourec-name>").
To remove specific NIM resource definitons use the AIX \ **nim**\ command. ("nim -o remove <resource-name>").
To remove specific NIM resource definitions use the AIX \ **nim**\ command. ("nim -o remove <resource-name>").
*******
@ -255,7 +255,7 @@ OPTIONS
Note that you may specify multiple "script", "otherpkgs", and "installp_bundle" resources by using a comma seperated list. (ex. "script=ascript,bscript"). RPM names may be included in the "otherpkgs" list by using a "R:" prefix(ex. "R:whatever.rpm"). epkg (AIX interim fix package) file names may be included in the "otherpkgs" using the 'E:' prefix. (ex. "otherpkgs=E:IZ38930TL0.120304.epkg.Z").
Note that you may specify multiple "script", "otherpkgs", and "installp_bundle" resources by using a comma separated list. (ex. "script=ascript,bscript"). RPM names may be included in the "otherpkgs" list by using a "R:" prefix(ex. "R:whatever.rpm"). epkg (AIX interim fix package) file names may be included in the "otherpkgs" using the 'E:' prefix. (ex. "otherpkgs=E:IZ38930TL0.120304.epkg.Z").
@ -267,7 +267,7 @@ OPTIONS
\ **-c|-**\ **-completeosimage**\
Complete the creation of the osimage definition passed in on the command line. This option will use any additonal values passed in on the command line and/or it will attempt to create required resources in order to complete the definition of the xCAT osimage. For example, if the osimage definition is missing a spot or shared_root resource the command will create those resources and add them to the osimage definition.
Complete the creation of the osimage definition passed in on the command line. This option will use any additional values passed in on the command line and/or it will attempt to create required resources in order to complete the definition of the xCAT osimage. For example, if the osimage definition is missing a spot or shared_root resource the command will create those resources and add them to the osimage definition.
@ -492,7 +492,7 @@ The xCAT osimage definition created by this command will include the "otherpkgs"
mknimimage -u 61dskls installp_bundle=bndres1,bndres2 installp_flags="-agcQX"
Note that when "installp_bundle", "otherpkgs", or "synclists" values are specified with the "-u" option then the xCAT osimage definiton is not used or updated.
Note that when "installp_bundle", "otherpkgs", or "synclists" values are specified with the "-u" option then the xCAT osimage definition is not used or updated.
13) Update an existing image to support NFSv4. Also specify verbose messages.

6
docs/source/guides/admin-guides/references/man1/mkvm.1.rst
View File

@ -148,7 +148,7 @@ OPTIONS
\ **vmcpus=**\ \ *value*\ \ **vmmemory=**\ \ *value*\ \ **vmphyslots=**\ \ *value*\ \ **vmothersetting=**\ \ *value*\ \ **vmnics=**\ \ *value*\ \ **vmstorage=**\ \ *value*\ [\ **-**\ **-vios**\ ]
To specify the parameters which are used to create a partition. The \ *vmcpus*\ , \ *vmmemory*\ are necessay, and the value specified with this command have a more high priority. If the value of any of the three options is not specified, the corresponding value specified for the node object will be used. If any of the three attributes is neither specified with this command nor specified with the node object, error information will be returned. To reference to lsvm(1)|lsvm.1 for more information about 'drc_index' for \ *vmphyslots*\ .
To specify the parameters which are used to create a partition. The \ *vmcpus*\ , \ *vmmemory*\ are necessary, and the value specified with this command have a more high priority. If the value of any of the three options is not specified, the corresponding value specified for the node object will be used. If any of the three attributes is neither specified with this command nor specified with the node object, error information will be returned. To reference to lsvm(1)|lsvm.1 for more information about 'drc_index' for \ *vmphyslots*\ .
The option \ *vios*\ is used to specify the partition that will be created is a VIOS partition. If specified, the value for \ *vmstorage*\ shall be number which indicate the number of vSCSI server adapter will be created, and if no value specified for \ *vmphyslots*\ , all the physical slot of the power machine will be asigned to VIOS partition. If not specified, it shall be in form of \ *vios_name:server_slotid*\ to specify the vios and the virtual slot id of the vSCSI server adapter that will be connected from the Logical partition.
@ -392,7 +392,7 @@ First, define a node object:
mkdef -t node -o lpar1 mgt=fsp cons=fsp nodetype=ppc,osi id=1 hcp=cec parent=cec hwtype=lpar groups=lpar,all
Then, create the partion on the specified cec.
Then, create the partition on the specified cec.
.. code-block:: perl
@ -515,7 +515,7 @@ The output is similar to:
mkvm viosnode vmcpus=1/4/16 vmmemory=1G/4G/32G vmphyslots=0x21010201,0x21010200 vmnics=vlan1 vmstorage=5 --vios
The resouces for the node is similar to:
The resources for the node is similar to:
.. code-block:: perl

4
docs/source/guides/admin-guides/references/man1/monadd.1.rst
View File

@ -39,9 +39,9 @@ Parameters
**********
\ *name*\ is the name of the monitoring plug-in module. For example, if the the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used.
\ *name*\ is the name of the monitoring plug-in module. For example, if the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used.
\ *settings*\ is the monitoring plug-in specific settings. It is used to customize the behavior of the plug-in or configure the 3rd party software. Format: \ *-s key-value -s key=value ...*\ Note that the square brackets are needed here. Use \ *monls name -d*\ command to look for the possbile setting keys for a plug-in module.
\ *settings*\ is the monitoring plug-in specific settings. It is used to customize the behavior of the plug-in or configure the 3rd party software. Format: \ *-s key-value -s key=value ...*\ Note that the square brackets are needed here. Use \ *monls name -d*\ command to look for the possible setting keys for a plug-in module.
*******

4
docs/source/guides/admin-guides/references/man1/moncfg.1.rst
View File

@ -31,7 +31,7 @@ DESCRIPTION
***********
This command is used to configure a 3rd party monitoring software to monitor the xCAT cluster. For example, it modifies the configration file for the monitoring software so that the nodes can be included in the monitoring domain. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified, though the configuration of the nodes is usually performed during the node deployment stage.
This command is used to configure a 3rd party monitoring software to monitor the xCAT cluster. For example, it modifies the configuration file for the monitoring software so that the nodes can be included in the monitoring domain. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified, though the configuration of the nodes is usually performed during the node deployment stage.
**********
@ -39,7 +39,7 @@ Parameters
**********
\ *name*\ is the name of the monitoring plug-in module. For example, if the the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used.
\ *name*\ is the name of the monitoring plug-in module. For example, if the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used.
\ *noderange*\ specifies the nodes to be monitored. If omitted, all nodes will be monitored.

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

@ -31,7 +31,7 @@ DESCRIPTION
***********
This command is used to deconfigure a 3rd party monitoring software from monitoring the xCAT cluster. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified. The deconfigration operation will remove the nodes from the 3rd party software's monitoring domain.
This command is used to deconfigure a 3rd party monitoring software from monitoring the xCAT cluster. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified. The deconfiguration operation will remove the nodes from the 3rd party software's monitoring domain.
**********

8
docs/source/guides/admin-guides/references/man1/monls.1.rst
View File

@ -33,7 +33,7 @@ DESCRIPTION
***********
This command is used to list the status, desctiption, the configuration scripts and the settings of one or all of the monitoring plug-in modules.
This command is used to list the status, description, the configuration scripts and the settings of one or all of the monitoring plug-in modules.
**********
@ -49,9 +49,9 @@ OPTIONS
*******
\ **-a | -**\ **-all**\ Searches the \ *XCATROOT/lib/perl/xCAT_monitoring*\ directory and reports all the monitoring plug-in modules. If nothing is specified, the list is read from the \ *monitoring*\ tabel.
\ **-a | -**\ **-all**\ Searches the \ *XCATROOT/lib/perl/xCAT_monitoring*\ directory and reports all the monitoring plug-in modules. If nothing is specified, the list is read from the \ *monitoring*\ table.
\ **-d | -**\ **-description**\ Display the description of the plug-in modules. The description ususally contains the possible settings.
\ **-d | -**\ **-description**\ Display the description of the plug-in modules. The description usually contains the possible settings.
\ **-h | -**\ **-help**\ Display usage message.
@ -110,7 +110,7 @@ The output looks like this:
nagiosmon not-monitored
3. To list the status and the desciption for \ *snmpmon*\ module, enter:
3. To list the status and the description for \ *snmpmon*\ module, enter:
.. code-block:: perl

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

@ -59,7 +59,7 @@ OPTIONS
\ **-a**\ specifies a comma-separated list of attributes or metrics names. The default is all.
\ **-w**\ specify one or multiple selection string that can be used to select events. The operators ==, !=, =,!,>,<,>=,<= are available. Wildcards % and _ are supported in the pattern string. % allows you to match any string of any length(including zero length) and _ allows you to match on a single character. The valid attributes are eventtype, monitor, monnode, application, component, id, serverity, message, rawdata, comments. Valid severity are: Informational, Warning, Critical.
\ **-w**\ specify one or multiple selection string that can be used to select events. The operators ==, !=, =,!,>,<,>=,<= are available. Wildcards % and _ are supported in the pattern string. % allows you to match any string of any length(including zero length) and _ allows you to match on a single character. The valid attributes are eventtype, monitor, monnode, application, component, id, severity, message, rawdata, comments. Valid severity are: Informational, Warning, Critical.
Operator descriptions:

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

@ -39,7 +39,7 @@ PARAMETERS
**********
\ *name*\ is the name of the monitoring plug-in module. For example, if the the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ **monls -a**\ command to list all the monitoring plug-in modules that can be used.
\ *name*\ is the name of the monitoring plug-in module. For example, if the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ **monls -a**\ command to list all the monitoring plug-in modules that can be used.
\ *noderange*\ is the nodes to be monitored. If omitted, all nodes will be monitored.

4
docs/source/guides/admin-guides/references/man1/nimnodecust.1.rst
View File

@ -57,9 +57,9 @@ To create a NIM installp_bundle definition you can use the "nim -o define" opera
nim -o define -t installp_bundle -a server=master -a location=/install/nim/mypkgs.bnd mypackages
See the AIX documantation for more information on using installp_bundle files.
See the AIX documentation for more information on using installp_bundle files.
The xCAT nimnodecust command will automatically handle the distribution of the packages to AIX service nodes when using an xCAT hierachical environment.
The xCAT nimnodecust command will automatically handle the distribution of the packages to AIX service nodes when using an xCAT hierarchical environment.
*******

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

@ -33,7 +33,7 @@ This xCAT command can be used to initialize AIX/NIM standalone machines. Once th
If you are using xCAT service nodes the \ **nimnodeset**\ command will automatically determine the correct server(s) for the node and do the initialization on that server(s).
The osimage_name is the name of an xCAT osimage definition that contains the list of NIM resources to use when initializing the nodes. If the osimage_name is not provided on the command line the code checks the node definition for the value of the "provmethod" attribute (which is the name of an osimage definition). If the osimage_image is provided on the command line then the code will also set the "provmethod" attribute of the node definiions.
The osimage_name is the name of an xCAT osimage definition that contains the list of NIM resources to use when initializing the nodes. If the osimage_name is not provided on the command line the code checks the node definition for the value of the "provmethod" attribute (which is the name of an osimage definition). If the osimage_image is provided on the command line then the code will also set the "provmethod" attribute of the node definitions.
This command will also create a NIM resolv_conf resource to be used when installing the node. If a resolv_conf resource is not already included in the xCAT osimage definition and if the "domain" and "nameservers" values are set then a new
NIM resolv_conf resource will be created and allocated to the nodes.
@ -41,7 +41,7 @@ NIM resolv_conf resource will be created and allocated to the nodes.
The "domain" and "nameservers" attributes can be set in either the xCAT "network" definition used by the nodes or in the xCAT cluster "site" definition. The setting in the "network" definition will take priority.
The "search" field of the resolv.conf file will contain a list all the domains
listed in the xCAT network definitions and the xCAT site definiton.
listed in the xCAT network definitions and the xCAT site definition.
The "nameservers" value can either be set to a specific IP address or the "<xcatmaster>" key word. The "<xcatmaster>" key word means that the value of the "xcatmaster" attribute of the node definition will be used in the /etc/resolv.conf file. (I.e. The name of the install server as known by the node.)
@ -58,13 +58,13 @@ will be created.
You can specify additional attributes and values using the "attr=val" command line option. This information will be passed on to the underlying call to the NIM "nim -o bos_inst" command. See the NIM documentation for information on valid command line options for the nim command. The "attr" must correspond to a NIM attribute supported for the NIM "bos_inst" operation. Information provided by the "attr=val" option will take precedence over the information provided in the osimage definition.
The force option can be used to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinititializing.
The force option can be used to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinitializing.
This command will also create a NIM script resource to enable the xCAT support for user-provided customization scripts.
After the \ **nimnodeset**\ command completes you can use the \ **lsnim**\ command to check the NIM node definition to see if it is ready for booting the node. ("lsnim -l <nim_node_name>").
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **nimnodeset**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts dirctory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **nimnodeset**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **nimnodeset**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *standalone:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "standalone". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes.
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **nimnodeset**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts directory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **nimnodeset**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **nimnodeset**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *standalone:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "standalone". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes.
*******
@ -76,7 +76,7 @@ OPTIONS
\ *attr=val [attr=val ...]*\
Specifies one or more "attribute equals value" pairs, separated by spaces. Attr=
val pairs must be specified last on the command line. These are used to specify additional values that can be passed to the underlying NIM commands, ("nim -o bos_inst ..."). See the NIM documentation for valid "nim" command line options. Note that you may specify multiple "script" and "installp_bundle" values by using a comma seperated list. (ex. "script=ascript,bscript").
val pairs must be specified last on the command line. These are used to specify additional values that can be passed to the underlying NIM commands, ("nim -o bos_inst ..."). See the NIM documentation for valid "nim" command line options. Note that you may specify multiple "script" and "installp_bundle" values by using a comma separated list. (ex. "script=ascript,bscript").
@ -106,8 +106,7 @@ OPTIONS
\ **-l|-**\ **-location**\
The directory location to use when creating new NIM resolv_conf resources. The d
efault location is /install/nim.
The directory location to use when creating new NIM resolv_conf resources. The default location is /install/nim.

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

@ -61,7 +61,7 @@ RETURN VALUE
0 The command completed successfully.
1 An error has occured.
1 An error has occurred.
********

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

@ -63,7 +63,7 @@ RETURN VALUE
0 The command completed successfully.
1 An error has occured.
1 An error has occurred.
********

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

@ -79,7 +79,7 @@ RETURN VALUE
0 The command completed successfully.
1 An error has occured.
1 An error has occurred.
********

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

@ -114,7 +114,7 @@ RETURN VALUE
0 The command completed successfully.
1 An error has occured.
1 An error has occurred.
********

6
docs/source/guides/admin-guides/references/man1/nodediscoverstart.1.rst
View File

@ -59,7 +59,7 @@ When the nodes are discovered, PCM updates the affected configuration files on t
When you power on the nodes, they PXE boot and DHCP/TFTP/HTTP on the management node give each node the xCAT genesis boot image,
which inventories the node hardware and sends data to the management node. There, either the sequential discovery process or the
profile discovery process assigns node attributes and defines the node in the the database.
profile discovery process assigns node attributes and defines the node in the database.
*******
@ -127,7 +127,7 @@ OPTIONS
\ **chasiss=**\ \ *chassis-name*\
\ **chassis=**\ \ *chassis-name*\
Sets the chassis name that the Blade server or PureFlex blade is located in, for either the Sequential Discovery or Profile Discovery methods. This option is used for the Blade server and PureFlex system only. You cannot specify this option with the rack option.
@ -196,7 +196,7 @@ RETURN VALUE
0 The command completed successfully.
1 An error has occured.
1 An error has occurred.
********

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

@ -52,7 +52,7 @@ RETURN VALUE
0 The command completed successfully.
1 An error has occured.
1 An error has occurred.
********

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

@ -53,7 +53,7 @@ RETURN VALUE
0 The command completed successfully.
1 An error has occured.
1 An error has occurred.
********

14
docs/source/guides/admin-guides/references/man1/nodeimport.1.rst
View File

@ -29,7 +29,7 @@ DESCRIPTION
***********
The \ **nodeimport**\ command creates nodes by importing a hostinfo file which is following stanza format. In this hostinfo file, we can define node's hostname, ip, mac, switch name, switch port and host location infomation like rack, chassis, start unit, server height...etc
The \ **nodeimport**\ command creates nodes by importing a hostinfo file which is following stanza format. In this hostinfo file, we can define node's hostname, ip, mac, switch name, switch port and host location information like rack, chassis, start unit, server height...etc
After nodes imported, the configuration files related with these nodes will be updated automatically. For example: /etc/hosts, dns configuration, dhcp configuration. And the kits node plugins will also be triggered automatically to update kit related configuration/services.
@ -83,9 +83,9 @@ RETURN VALUE
0 The command completed successfully.
1 An error has occured while validating parameters.
1 An error has occurred while validating parameters.
2 An error has occured while parsing hostinfo file.
2 An error has occurred while parsing hostinfo file.
********
@ -143,7 +143,7 @@ To import nodes using a profile, follow the following steps:
# hostinfo end.
Another example of a node infomation file, a PureFlex X/P node defined:
Another example of a node information file, a PureFlex X/P node defined:
# hostinfo begin
# To define a PureFlex P/X node, chassis and slot id must be specified.
# The chassis must be a PureFlex chassis.
@ -191,7 +191,7 @@ Description: The name of the node, where __hostname__ is automatically generated
\ **mac=<mac-address**\ > This is a mandatory item.
Description: Specify the MAC address for the NIC used by the provisionging node, where <mac-address> is the NICs MAC address.
Description: Specify the MAC address for the NIC used by the provisioning node, where <mac-address> is the NICs MAC address.
\ **switches=<nic-name!switch-name!switch-port**\ > This is a mandatory item, when define switch, switchport and node nic name relationship.
@ -221,9 +221,9 @@ Description: Lists the IP address for each network interface configuration (NIC)
Description: node location info. Specify the rack name which this node will be placed into. If not specify this item, there will be no node location info set for this node. this item must be specified together with height + unit.
\ **chasiss=<chassis-name**\ > This is an optional item.
\ **chassis=<chassis-name**\ > This is an optional item.
Description: node location info, for blade(or PureFlex) only. Specify the chasiss name which this blade will be placed into. this item can not be specified together with rack.
Description: node location info, for blade(or PureFlex) only. Specify the chassis name which this blade will be placed into. this item can not be specified together with rack.
\ **height=<chassis-height**\ > This is an optional item.

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