xCAT/xcat-core
2
0
Fork 0
mirror of https://github.com/xcat2/xcat-core.git synced 2026-01-07 17:02:34 +00:00
Code Issues Releases Wiki Activity

Merge branch 'master' of github.com:xcat2/xcat-core

Browse Source
This commit is contained in:
Jarrod Johnson
2016-10-31 10:10:42 -04:00
parent 444d223c88 596af4c440
commit d8610f2135
198 changed files with 2658 additions and 1326 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
buildcore.sh
View File

@@ -67,14 +67,14 @@ if [ -z "$UP" ]; then
fi
# These are the rpms that should be built for each kind of xcat build
ALLBUILD="perl-xCAT xCAT-client xCAT-server xCAT-test xCAT-buildkit xCAT xCATsn xCAT-genesis-scripts xCAT-SoftLayer xCAT-vlan xCAT-confluent xCAT-probe"
ALLBUILD="perl-xCAT xCAT-client xCAT-server xCAT-test xCAT-buildkit xCAT xCATsn xCAT-genesis-scripts xCAT-SoftLayer xCAT-vlan xCAT-confluent xCAT-probe xCAT-csm"
ZVMBUILD="perl-xCAT xCAT-server xCAT-UI"
ZVMLINK="xCAT-client xCAT xCATsn"
# xCAT and xCATsn have PCM specific configuration - conserver-xcat, syslinux-xcat
# xCAT-server has PCM specific configuration - RESTAPI(perl-JSON)
# xCAT-client has PCM specific configuration - getxcatdocs(perl-JSON)
PCMBUILD="xCAT xCAT-server xCAT-client xCATsn"
PCMLINK="perl-xCAT xCAT-buildkit xCAT-genesis-scripts-x86_64 xCAT-genesis-scripts-ppc64 xCAT-vlan"
PCMLINK="perl-xCAT xCAT-buildkit xCAT-genesis-scripts-x86_64 xCAT-genesis-scripts-ppc64 xCAT-vlan xCAT-probe"
# Note: for FSM, the FlexCAT rpm is built separately from gsa/git
FSMBUILD="perl-xCAT xCAT-client xCAT-server"
FSMLINK=""
@@ -299,7 +299,7 @@ if [ "$OSNAME" = "AIX" ]; then
fi
# Build the rest of the noarch rpms
for rpmname in xCAT-client xCAT-server xCAT-IBMhpc xCAT-rmc xCAT-UI xCAT-test xCAT-buildkit xCAT-SoftLayer xCAT-vlan xCAT-confluent xCAT-probe; do
for rpmname in xCAT-client xCAT-server xCAT-IBMhpc xCAT-rmc xCAT-UI xCAT-test xCAT-buildkit xCAT-SoftLayer xCAT-vlan xCAT-confluent xCAT-probe xCAT-csm; do
if [[ " $EMBEDBUILD " != *\ $rpmname\ * ]]; then continue; fi
if [ "$OSNAME" = "AIX" -a "$rpmname" = "xCAT-buildkit" ]; then continue; fi # do not build xCAT-buildkit on aix
if [ "$OSNAME" = "AIX" -a "$rpmname" = "xCAT-SoftLayer" ]; then continue; fi # do not build xCAT-softlayer on aix

2
docs/source/advanced/chain/chain_table.rst
View File

@@ -7,7 +7,7 @@ The chain table (``tabdump chain``) is an xCAT database table that holds the cha
* currchain
* chain
To know how are those three attributes used, pls reference the picture:
To know how are those three attributes used, reference the picture:
.. image:: chain_tasks_logic.png

2
docs/source/advanced/chain/chain_tasks.rst
View File

@@ -25,7 +25,7 @@ The ``image.tgz`` **must** have the following properties:
* Created using the ``tar zcvf`` command
* The tarball must include a ``runme.sh`` script to initiate the execution of the runimage
To create your own image, please reference :ref:`creating image for runimage <create_image_for_runimage>`.
To create your own image, reference :ref:`creating image for runimage <create_image_for_runimage>`.
**Tip**: You could try to run ``wget http://<IP of xCAT Management Node>/<dir>/image.tgz`` manually to make sure the path has been set correctly.

4
docs/source/advanced/cluster_maintenance/service_node/changing_hostname_ip.rst
View File

@@ -36,11 +36,11 @@ Database Connection Changes
Granting or revoking access privilege in the database for the service node.
* For mysql, please refer to :ref:`grante_revoke_mysql_access_label`.
* For mysql, refer to :ref:`grante_revoke_mysql_access_label`.
.. There is no procedure in old document on sourceforge for postgress to
grant or revoke the access privilege for service node.
* For postgress, please refer to `TODO <https://localhost/todo>`_.
* For postgress, refer to `TODO <https://localhost/todo>`_.
Update Provision Environment on Service Node
--------------------------------------------

3
docs/source/advanced/confluent/server/confluent_server.rst
View File

@@ -56,8 +56,7 @@ The following example describes the steps for **rhels7.1** on **ppc64le**::
cd confluent-dep-rh7-ppc64le/
./mklocalrepo.sh
**Note:** If the OS/architecture you are looking for is not provided under confluent-dep,
please send an email to the xcat-user mailing list: xcat-user@lists.sourceforge.net
**Note:** If the OS/architecture you are looking for is not provided under confluent-dep, send an email to the xcat-user mailing list: xcat-user@lists.sourceforge.net
Install

4
docs/source/advanced/docker/docker_registry.rst
View File

@@ -5,7 +5,7 @@ Docker Registry is a stateless, highly scalable server side application that sto
This document describes how to set up a local private docker registry on Ubuntu 15.04 on x86_64.
**Note:** Please ensure that docker registry is not already set up on this docker host.
**Note:** Ensure that docker registry is not already set up on this docker host.
Setting Up Docker Host
----------------------
@@ -17,7 +17,7 @@ Setting Up Docker Registry Manually
Docker registry needed to be set up on xCAT's MN.
This section describes two methods of setting up docker registry manullay.
This section describes two methods of setting up docker registry manually.
First, create some folders where files for this tutorial will live. ::

6
docs/source/advanced/docker/dockerized_xcat/dockerized_xcat.rst
View File

@@ -24,7 +24,7 @@ By pulling xCAT Docker image and running xCAT Docker image in a container, you g
xCAT Docker images
------------------
xCAT shippes 2 Docker images for Docker host with different architecture:
xCAT ships 2 Docker images for Docker host with different architecture:
* "xcat/xcat-ubuntu-x86_64": run on x86_64 Docker host
* "xcat/xcat-ubuntu-ppc64le": run on ppc64le Docker host
@@ -81,12 +81,12 @@ Once you attach or ssh to the container, you will find that xCAT is running and
Currently, since xCAT can only generate the diskless osimages of Linux distributions with the same OS version and architecture with xCAT MN. If you need to provision diskless osimages besides ubuntu x86_64 with xCAT running in the Docker, you can use ``imgexport`` and ``imgimport`` to import the diskless osimages generated before.
If you start up the xCAT Docker container by following the steps described in sections above strictly, without specifying "--dns=IP_ADDRESS...", "--dns-search=DOMAIN...", or "--dns-opt=OPTION..." options, Docker uses the /etc/resolv.conf of the host machine (where the docker daemon runs). Any DNS problem inside container, please make sure the DNS server on the Docker host works well.
If you start up the xCAT Docker container by following the steps described in sections above strictly, without specifying "--dns=IP_ADDRESS...", "--dns-search=DOMAIN...", or "--dns-opt=OPTION..." options, Docker uses the /etc/resolv.conf of the host machine (where the docker daemon runs). Any DNS problem inside container, make sure the DNS server on the Docker host works well.
Save and Restore xCAT data
----------------------------
According to the policy of Docker, Docker image should only be the service deployment unit, it is not recommended to save data in Docker image. Docker uses "Data Volume" to save persisent data inside container, which can be simply taken as a shared directory between Docker host and Docker container.
According to the policy of Docker, Docker image should only be the service deployment unit, it is not recommended to save data in Docker image. Docker uses "Data Volume" to save persistent data inside container, which can be simply taken as a shared directory between Docker host and Docker container.
For dockerized xCAT, there are 3 volumes recommended to save and restore xCAT user data.

2
docs/source/advanced/docker/dockerized_xcat/run_xcat_in_docker_native.rst
View File

@@ -69,7 +69,7 @@ Now run the xCAT Docker container with the Docker image "xcat/xcat-ubuntu-x86_64
* use ``--privileged=true`` to give extended privileges to this container
* use ``--hostname`` to specify the hostname of the container, which is available inside the container
* use ``--name`` to assign a name to the container, this name can be used to manipulate the container on Docker host
* use ``--add-host="xcatmn.clusers.com xcatmn:10.5.107.101"`` to write the ``/etc/hosts`` entries of Docker container inside container. Since xCAT use the FQDN(Fully Qualified Domain Name) to determine the cluster domain on startup, please make sure the format to be "<FQDN> <hostname>: <IP Address>", otherwise, you need to set the cluster domain with ``chdef -t site -o clustersite domain="clusters.com"`` inside the container manually
* use ``--add-host="xcatmn.clusers.com xcatmn:10.5.107.101"`` to write the ``/etc/hosts`` entries of Docker container inside container. Since xCAT use the FQDN(Fully Qualified Domain Name) to determine the cluster domain on startup, make sure the format to be "<FQDN> <hostname>: <IP Address>", otherwise, you need to set the cluster domain with ``chdef -t site -o clustersite domain="clusters.com"`` inside the container manually
* use ``--volume /docker/xcatdata/:/install`` to mount a pre-created "/docker/xcatdata" directory on Docker host to "/install" directory inside container as a data volume. This is optional, it is mandatory if you want to backup and restore xCAT data.
* use ``--net=mgtnet`` to connect the container to the Docker network "mgtnet"
* use ``--ip=10.5.107.101`` to specify the IP address of the xCAT Docker container

2
docs/source/advanced/docker/dockerized_xcat/setup_docker_host.rst
View File

@@ -4,7 +4,7 @@ Setup Docker host
Install Docker Engine
---------------------
The Docker host to run xCAT Docker image should be a baremental or virtual server with Docker v1.10 or above installed. For the details on system requirements and Docker installation, please refer to `Docker Installation Docs <https://docs.docker.com/engine/installation/>`_.
The Docker host to run xCAT Docker image should be a baremental or virtual server with Docker v1.10 or above installed. For the details on system requirements and Docker installation, refer to `Docker Installation Docs <https://docs.docker.com/engine/installation/>`_.
**Note:**

2
docs/source/advanced/docker/lifecycle_management.rst
View File

@@ -3,7 +3,7 @@ Docker life-cycle management in xCAT
The Docker linux container technology is currently very popular. xCAT can help managing Docker containers. xCAT, as a system management tool has the natural advantage for supporting multiple operating systems, multiple architectures and large scale clusters.
This document describes how to use xCAT for docker management, from Docker Host setup to docker container operationis.
This document describes how to use xCAT for docker management, from Docker Host setup to docker container operations.
**Note:** The document was verified with **Docker Version 1.10, 1.11** and **Docker API version 1.22.** The Docker Host was verified on **ubuntu14.04.3 x86_64**, **ubuntu15.10 x86_64**, **ubuntu16.04 x86_64** and **ubuntu16.04 ppc64el**.

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

@@ -101,7 +101,7 @@ You must set the **forwarders** attribute in the xCAT cluster **site** definitio
An xCAT **network** definition must be defined for each management network used in the cluster. The **net** and **mask** attributes will be used by the ``makedns`` command.
A network **domain** and **nameservers** value must be provided either in the network definiton corresponding to the nodes or in the site definition.
A network **domain** and **nameservers** value must be provided either in the network definition corresponding to the nodes or in the site definition.
For example, if the cluster domain is **mycluster.com**, the IP address of the management node, (as known by the cluster nodes), is **100.0.0.41** and the site DNS servers are **50.1.2.254,50.1.3.254** then you would run the following command. ::
@@ -249,7 +249,7 @@ To use this support you must set one or more of the following node definition at
The additional NIC information may be set by directly editing the xCAT **nics** table or by using the **xCAT *defs** commands to modify the node definitions.
The details for how to add the additional information is described below. As you will see, entering this
information manually can be tedious and error prone. This support is primarily targetted to be used in
information manually can be tedious and error prone. This support is primarily targeted to be used in
conjunction with other IBM products that have tools to fill in this information in an automated way.
Managing additional interface information using the **xCAT *defs** commands
@@ -269,7 +269,7 @@ For example, the expanded format for the **nicips** and **nichostnamesuffixes**
nicips.eth1=10.1.1.6
nichostnamesuffixes.eth1=-eth1
If we assume that your xCAT node name is **compute02** then this would mean that you have an additonal interface **("eth1")** and that the hostname and IP address are **compute02-eth1** and **10.1.1.6**.
If we assume that your xCAT node name is **compute02** then this would mean that you have an additional interface **("eth1")** and that the hostname and IP address are **compute02-eth1** and **10.1.1.6**.
A "|" delimiter is used to specify multiple values for an interface. For example: ::
@@ -285,7 +285,7 @@ For the **nicaliases** attribute a list of additional aliases may be provided. :
This indicates that the **compute02-eth1** hostname would get the additional two aliases, alias1 alias2, included in the **/etc/hosts** file, (when using the ``makehosts`` command).
The second line indicates that **compute02-eth2** would get the additonal alias **alias3** and that **compute02-eth-lab** would get **alias4**
The second line indicates that **compute02-eth2** would get the additional alias **alias3** and that **compute02-eth-lab** would get **alias4**
Setting individual nic attribute values
'''''''''''''''''''''''''''''''''''''''

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

@@ -13,15 +13,15 @@ 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 syncronization, but considering the specific xCAT HAMN requirements, only several of the data syncronziation 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 synchronziation 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.
**2\. Shared data**: the two management nodes use the 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 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.
**2\. Shared data**: the two management nodes use the 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.
**3\. Mirroring**: each of the management node has its own copy of the xCAT data, and the two copies of data are syncronized through mirroring mechanism. DRBD is used widely in the high availability configuration scenarios, to provide data replication by mirroring a whole block device via network. If we put all the important data for xCAT onto the DRBD devices, then it could assure the data is synchronized between the two management nodes. Some parallel file system also provides capability to mirror data through network.
**3\. Mirroring**: each of the management node has its own copy of the xCAT data, and the two copies of data are synchronized through mirroring mechanism. DRBD is used widely in the high availability configuration scenarios, to provide data replication by mirroring a whole block device via network. If we put all the important data for xCAT onto the DRBD devices, then it could assure the data is synchronized between the two management nodes. Some parallel file system also provides capability to mirror data through network.
Manual vs. Automatic Failover
-----------------------------
@@ -36,7 +36,7 @@ From xCAT perspective, if the management node needs to provide network services
**2\. Configuration complexity**
The configuration for the high availability applications is usually complex, it may take a long time to configure, debug and stablize the high availability configuration.
The configuration for the high availability applications is usually complex, it may take a long time to configure, debug and stabilize the high availability configuration.
**3\. Maintenance effort**

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

@@ -1,12 +1,12 @@
High Avaiability
================
High Availability
=================
The xCAT management node plays an important role in the cluster, if the management node is down for whatever reason, the administrators will lose the management capability for the whole cluster, until the management node is back up and running. In some configuration, like the Linux nfs-based statelite in a non-hierarchy cluster, the compute nodes may not be able to run at all without the management node. So, it is important to consider the high availability for the management node.
The xCAT management node plays an important role in the cluster, if the management node is down for whatever reason, the administrators will lose the management capability for the whole cluster, until the management node is back up and running. In some configurations, like the Linux NFSROOT-based statelite in a non-hierarchy cluster, the compute nodes may not be able to run at all without the management node. So, it is important to consider the high availability for the management node.
The goal of the HAMN(High Availability Management Node) configuration is, when the primary xCAT management node fails, the standby management node can take over the role of the management node, either through automatic failover or through manual procedure performed by the administrator, and thus avoid long periods of time during which your cluster does not have active cluster management function available.
The goal of the HAMN (High Availability Management Node) configuration is, when the primary xCAT management node fails, the standby management node can take over the role of the management node, either through automatic failover or through manual procedure performed by the administrator, and thus avoid long periods of time during which your cluster does not have active cluster management function available.
The following pages describes ways to configure the xCAT Management Node for High Availbility.
The following pages describes ways to configure the xCAT Management Node for High Availability.
.. toctree::
:maxdepth: 2

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

@@ -149,7 +149,7 @@ So, in this documentation, we will setup xCAT on both management nodes before we
chdef -t site nameservers=10.1.0.1
chdef -t network 10_1_0_0-255_255_255_0 tftpserver=10.1.0.1
#. Install and configure MySQL. MySQL will be used as the xCAT database system, please refer to the doc [ **todo** Setting_Up_MySQL_as_the_xCAT_DB].
#. Install and configure MySQL. MySQL will be used as the xCAT database system, refer to the doc [ **todo** Setting_Up_MySQL_as_the_xCAT_DB].
Verify xcat is running on MySQL by running: ::
@@ -219,7 +219,7 @@ Setup xCAT on the Standby Management Node
#. Install xCAT. The procedure described in :doc:`xCAT Install Guide <../../guides/install-guides/index>` should be used for the xCAT setup on the standby management node.
#. Install and configure MySQL. MySQL will be used as the xCAT database system, please refer to the doc [Setting_Up_MySQL_as_the_xCAT_DB].
#. Install and configure MySQL. MySQL will be used as the xCAT database system, refer to the doc [Setting_Up_MySQL_as_the_xCAT_DB].
Verify xcat is running on MySQL by running: ::
@@ -689,7 +689,7 @@ Configure Pacemaker
All the cluster resources are managed by Pacemaker, here is an example ``pacemaker`` configuration that has been used by different HA MN customers. You might need to do some minor modifications based on your cluster configuration.
Please be aware that you need to apply ALL the configuration at once. You cannot pick and choose which pieces to put in, and you cannot put some in now, and some later. Don't execute individual commands, but use crm configure edit instead. ::
Be aware that you need to apply ALL the configuration at once. You cannot pick and choose which pieces to put in, and you cannot put some in now, and some later. Don't execute individual commands, but use crm configure edit instead. ::
node x3550m4n01
node x3550m4n02
@@ -1043,7 +1043,7 @@ Add a crontab entry to check the differences
0 6 * * * /sbin/drbdadm verify all
Please note that this process will take a few hours. You could schedule it at a time when it can be expected to run when things are relatively idle. You might choose to only run it once a week, but nightly seems to be a nice choice as well. You should only put this cron job on one side or the other of the DRBD mirror . not both.
Note that this process will take a few hours. You could schedule it at a time when it can be expected to run when things are relatively idle. You might choose to only run it once a week, but nightly seems to be a nice choice as well. You should only put this cron job on one side or the other of the DRBD mirror . not both.
Correcting the differences automatically
----------------------------------------

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

@@ -408,7 +408,7 @@ The operating system is installed on the internal disks.
#. Connect the shared disk to both management nodes
To verify the shared disks are connected correctly, run the sginfo command on both management nodes and look for the same serial number in the output. Please be aware that the sginfo command may not be installed by default on Linux, the sginfo command is shipped with package sg3_utils, you can manually install the package sg3_utils on both management nodes.
To verify the shared disks are connected correctly, run the sginfo command on both management nodes and look for the same serial number in the output. Be aware that the sginfo command may not be installed by default on Linux, the sginfo command is shipped with package sg3_utils, you can manually install the package sg3_utils on both management nodes.
Once the sginfo command is installed, run sginfo -l command on both management nodes to list all the known SCSI disks, for example, enter: ::

2
docs/source/advanced/hamn/setup_xcat_high_available_management_node_in_softlayer.rst
View File

@@ -329,7 +329,7 @@ Install corosync and pacemaker on both rhmn2 and rhmn1
Customize corosync/pacemaker configuration for xCAT
------------------------------------------------------
Please be aware that you need to apply ALL the configuration at once. You cannot pick and choose which pieces to put in, and you cannot put some in now, and some later. Don't execute individual commands, but use crm configure edit instead.
Be aware that you need to apply ALL the configuration at once. You cannot pick and choose which pieces to put in, and you cannot put some in now, and some later. Don't execute individual commands, but use crm configure edit instead.
Check that both rhmn2 and chetha are standby state now: ::

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

@@ -16,7 +16,7 @@ Appendix B: Diagnostics
* **otherpkgs(including xCAT rpms) installation failed on the SN** --The OS
repository is not created on the SN. When the "yum" command is processing
the dependency, the rpm packages (including expect, nmap, and httpd, etc)
required by xCATsn can't be found. In this case, please check whether the
required by xCATsn can't be found. In this case, check whether the
``/install/postscripts/repos/<osver>/<arch>/`` directory exists on the MN.
If it is not on the MN, you need to re-run the "copycds" command, and there
will be some file created under the

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

@@ -12,7 +12,7 @@ If you no longer want to use MySQL/MariaDB to maintain ``xcatdb``, and like to s
XCATBYPASS=1 restorexCATdb -p ~/xcat-dbback
* Change to PostgreSQL, please following documentation: :doc:`/advanced/hierarchy/databases/postgres_install`
* Change to PostgreSQL, following documentation: :doc:`/advanced/hierarchy/databases/postgres_install`
* Change back to default xCAT database, SQLite (**Note**: xCAT Hierarchy cluster will no longer work)

2
docs/source/advanced/hierarchy/provision/diskless_sn.rst
View File

@@ -1,7 +1,7 @@
Diskless (Stateless) Installation
=================================
**Note: The stateless Service Node is not supported in ubuntu hierarchy cluster. For ubuntu, please skip this section.**
**Note: The stateless Service Node is not supported in ubuntu hierarchy cluster. For ubuntu, skip this section.**
If you want, your Service Nodes can be stateless (diskless). The Service Node
must contain not only the OS, but also the xCAT software and its dependencies.

1
docs/source/advanced/index.rst
View File

@@ -16,6 +16,7 @@ Advanced Topics
mixed_cluster/index.rst
networks/index.rst
ports/xcat_ports.rst
probe/index.rst
raid/index.rst
restapi/index.rst
security/index.rst

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

@@ -63,4 +63,4 @@ If the kit does contain a deployment parameter file, the contents of the file wi
addkitcomp -i <image> <kitcomponent name>
vi /install/osimages/<image>/kits/KIT_DEPLOY_PARAMS.otherpkgs.pkglist
NOTE: Please be sure to know how changing any kit deployment parameters will impact the install of the product into the OS image. Many parameters include settings for automatic license acceptance and other controls to ensure proper unattended installs into a diskless image or remote installs into a diskful node. Changing these values will cause problems with genimage, updatenode, and other xCAT deployment commands.
NOTE: Be sure to know how changing any kit deployment parameters will impact the install of the product into the OS image. Many parameters include settings for automatic license acceptance and other controls to ensure proper unattended installs into a diskless image or remote installs into a diskful node. Changing these values will cause problems with genimage, updatenode, and other xCAT deployment commands.

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

@@ -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``. Please 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 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
#. Add the **Parallel ESSL** kitcomponents to osimage.

2
docs/source/advanced/kit/index.rst
View File

@@ -5,7 +5,7 @@ xCAT supports a unique software bundling concept called **software kits**. Soft
Prebuilt software kits are available as a tar file which can be downloaded and then added to the xCAT installation. After the kits are added to xCAT, kit components are then added to specific xCAT osimages to automatically install the software bundled with the kit during OS deployment. In some instances, software kits may be provided as partial kits. Partial kits need additional effort to complete the kit before it can be used by xCAT.
Software kits are supported for both diskful and diskless image provisionig.
Software kits are supported for both diskful and diskless image provisioning.
.. toctree::
:maxdepth: 2

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

@@ -5,9 +5,9 @@ A **stateless**, or **diskless**, provisioned nodes is one where the operating s
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.
In a homogenous cluster, the management node is the same hardware architecture and running the same Operating System (OS) as the compute nodes, so ``genimage`` can directly be executed from the management node.
In a homogeneous cluster, the management node is the same hardware architecture and running the same Operating System (OS) as the compute nodes, so ``genimage`` can directly be executed from the management node.
The issues arises in a heterogenous cluster, where the management node is running a different level operating system *or* hardware architecture as the compute nodes in which to deploy the image. The ``genimage`` command that builds stateless images depends on various utilities provided by the base operating system and needs to be run on a node with the same hardware architecture and *major* Operating System release as the nodes that will be booted from the image.
The issues arises in a heterogeneous cluster, where the management node is running a different level operating system *or* hardware architecture as the compute nodes in which to deploy the image. The ``genimage`` command that builds stateless images depends on various utilities provided by the base operating system and needs to be run on a node with the same hardware architecture and *major* Operating System release as the nodes that will be booted from the image.
Same Operating System, Different Architecture
---------------------------------------------
@@ -27,7 +27,7 @@ The following describes creating stateless images of the same Operating System,
lsdef -t osimage -z rhels6.3-x86_64-netboot-compute | sed 's/^[^ ]\+:/mycomputeimage:/' | mkdef -z
#. To obtain the ``genimage`` command to execte on ``n01``, execute the ``genimage`` command with the ``--dryrun`` option: ::
#. To obtain the ``genimage`` command to execute on ``n01``, execute the ``genimage`` command with the ``--dryrun`` option: ::
genimage --dryrun mycomputeimage

12
docs/source/advanced/networks/ethernet_switches/ethernet_switches.rst
View File

@@ -1,7 +1,7 @@
Configure Ethernet Switches
---------------------------
It is recommended that spanning tree be set in the switches to portfast or edge-port for faster boot performance. Please see the relevant switch documentation as to how to configure this item.
It is recommended that spanning tree be set in the switches to portfast or edge-port for faster boot performance. See the relevant switch documentation as to how to configure this item.
It is recommended that lldp protocol in the switches is enabled to collect the switch and port information for compute node during discovery process.
@@ -71,9 +71,9 @@ Running Remote Commands in Parallel
You can use xdsh to run parallel commands on Ethernet switches. The following shows how to configure xCAT to run xdsh on the switches:
**[Note]**:Configure the switch to allow **ssh** or **telnet**. This varies for switch to switch. Please refer to the switch command references to find out how to do it.
**[Note]**:Configure the switch to allow **ssh** or **telnet**. This varies for switch to switch. Refer to the switch command references to find out how to do it.
Add the switch in xCAT DB. Please refer to the "Discovering Switches" section if you want xCAT to discover and define the switches for you. ::
Add the switch in xCAT DB. Refer to the "Discovering Switches" section if you want xCAT to discover and define the switches for you. ::
mkdef bntc125 groups=switch mgt=switch ip=10.4.25.1 nodetype=switch switchtype=BNT
@@ -97,9 +97,9 @@ Set the ssh or telnet username an d password. ::
xdsh bntc125 --devicetype EthSwitch::BNT "enable;configure terminal;vlan 3;end;show vlan"
Please note that you can run multiple switch commands, they are separated by comma.
Note that you can run multiple switch commands, they are separated by comma.
Please also note that --devicetype is used here. xCAT supports the following switch types out of the box: ::
Also note that --devicetype is used here. xCAT supports the following switch types out of the box: ::
* BNT
* Cisco
@@ -178,7 +178,7 @@ The new configuration file will look like this: ::
For **BNT** switches, the **command-to-set-term-length-to-0** is **terminal-length 0**.
Please make sure to add a semi-colon at the end of the "pre-command" line.
Make sure to add a semi-colon at the end of the "pre-command" line.
Then you can run the xdsh like this: ::

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

@@ -5,7 +5,7 @@ Firmware Updates
Adapter Firmware Update
-----------------------
Please download the OFED IB adapter firmware from the Mellanox site `http://www.mellanox.com/page/firmware_table_IBM <http://www.mellanox.com/page/firmware_table_IBM>`_ .
Download the OFED IB adapter firmware from the Mellanox site `http://www.mellanox.com/page/firmware_table_IBM <http://www.mellanox.com/page/firmware_table_IBM>`_ .
Obtain device id: ::

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

@@ -72,7 +72,7 @@ Use the following command to consolidate the syslog to the Management Node or Se
Configure xdsh for Mellanox Switch
----------------------------------
To run xdsh commands to the Mellanox Switch, you must use the --devicetype input flag to xdsh. In addition, for xCAT versions less than 2.8, you must add a configuration file, please see `Setup ssh connection to the Mellanox Switch`_ section.
To run xdsh commands to the Mellanox Switch, you must use the --devicetype input flag to xdsh. In addition, for xCAT versions less than 2.8, you must add a configuration file, see `Setup ssh connection to the Mellanox Switch`_ section.
For the Mellanox Switch the ``--devicetype`` is ``IBSwitch::Mellanox``. See :doc:`xdsh man page </guides/admin-guides/references/man1/xdsh.1>` for details.

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

@@ -8,7 +8,7 @@ Pre-requirement
In order to do switch-based switch discovery, the admin
1. Needs to manually setup and configure core-switch, SNMP v3 needs to be enabled in order for xCAT access to it. **username** and **userpassword** attributes are for the remote login. It can be for **ssh** or **telnet**. If it is for **telnet**, please set protocol to “telnet”. If the **username** is blank, the **username** and **password** will be retrieved from the passwd table with “switch” as the key. SNMP attributes will used for SNMPv3 communication. **nodetype** has to be set to "switch" to differentiate between switch-based node discovery or switch-based switch discovery. Refer to switches table attributes. Example of core-switch definition:
1. Needs to manually setup and configure core-switch, SNMP v3 needs to be enabled in order for xCAT access to it. **username** and **userpassword** attributes are for the remote login. It can be for **ssh** or **telnet**. If it is for **telnet**, set protocol to “telnet”. If the **username** is blank, the **username** and **password** will be retrieved from the passwd table with “switch” as the key. SNMP attributes will used for SNMPv3 communication. **nodetype** has to be set to "switch" to differentiate between switch-based node discovery or switch-based switch discovery. Refer to switches table attributes. Example of core-switch definition:
::

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

@@ -37,5 +37,5 @@ The discovery process works with the following four kind of switches: ::
BNT
Juniper
The ``switchdiscover`` command can display the output in xml format, stanza forma and normal list format. Please see the man pages for this command for details.
The ``switchdiscover`` command can display the output in xml format, stanza forma and normal list format. See the man pages for this command for details.

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

@@ -53,7 +53,7 @@ For example: ::
This means port 42 of switch1 is connected to port 50 of switch2. And switch1 can be accessed using SNMP version 3 and switch 2 can be accessed using SNMP version 2.
Note: The **username** and the **password** on the switches table are NOT the same as SSH user name and password. You have to configure SNMP on the switch for these parameters and then fill up this table. Please use **tabdump switches -d** command to find out the meaning of each column.
Note: The **username** and the **password** on the switches table are NOT the same as SSH user name and password. You have to configure SNMP on the switch for these parameters and then fill up this table. Use **tabdump switches -d** command to find out the meaning of each column.
**2. Populate the switch table**
@@ -80,7 +80,7 @@ The interface eth1 is for the application network on node1, node2 and node3. Not
**3. Configure the switch for SNMP access**
Please make sure that the MN can access the switch using SNMP and the switch is configured such that it has SNMP read and write permissions.
Make sure that the MN can access the switch using SNMP and the switch is configured such that it has SNMP read and write permissions.
You can use **snmpwalk/snmpget** and **snmpset** commands on the mn to check. These commands are from **net-snmp-utils** rpm.
@@ -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. Please 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 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.
Limitation
----------

5
docs/source/advanced/probe/detect_dhcpd.rst Normal file
View File

@@ -0,0 +1,5 @@
detect_dhcpd
============
**detect_dhcp** can be used to detect the dhcp server in a network for a specific mac address.

5
docs/source/advanced/probe/discovery.rst Normal file
View File

@@ -0,0 +1,5 @@
discovery
=========
**discovery** can be used to probe the discovery process, including pre-check for required configuration and realtime monitor of discovery process.

3
docs/source/advanced/probe/image.rst Normal file
View File

@@ -0,0 +1,3 @@
image
=====

27
docs/source/advanced/probe/index.rst Normal file
View File

@@ -0,0 +1,27 @@
xCAT probe
==========
To help identify some of the common issues with xCAT, a new tool suite is now available **xCAT probe**.
You can use ``xcatprobe -l`` to list all valid subcommands, output will be as below ::
# xcatprobe -l
osdeploy Probe operating system provision process. Supports two modes - 'Realtime monitor' and 'Replay history'.
xcatmn After xcat installation, use this command to check if xcat has been installed correctly and is
ready for use. Before using this command, install 'tftp', 'nslookup' and 'wget' commands.
switch-macmap To retrieve MAC address mapping for the specified switch, or all the switches defined in
'switches' table in xCAT db.
......
.. toctree::
:maxdepth: 2
xcatmn.rst
detect_dhcpd.rst
image.rst
osdeploy.rst
discovery.rst
switch-macmap.rst
nodecheck.rst
osimagecheck.rst

2
docs/source/advanced/probe/nodecheck.rst Normal file
View File

@@ -0,0 +1,2 @@
nodecheck
=========

99
docs/source/advanced/probe/osdeploy.rst Normal file
View File

@@ -0,0 +1,99 @@
osdeploy
========
**osdeploy** operating system provision process. Supports two modes - 'Realtime monitor' and 'Replay history'.
Realtime monitor: This is a default. This tool with monitor provision state of the node. Trigger 'Realtime monitor' before rebooting target node to do provisioning.
Replay history: Used after provisioning is finished to probe the previously completed provisioning.
**Note**: Currently, hierarchical structure is not supported.
Usage
-----
::
xcatprobe osdeploy -h
xcatprobe osdeploy -n <node_range> [-t <max_waiting_time>] [-V]
xcatprobe osdeploy -n <node_range> -r <xxhxxm> [-V]
Options:
* **-n**: The range of nodes to be monitored or replayed.
* **-r**: Trigger 'Replay history' mode. Follow the duration of rolling back. Units are 'h' (hour) or 'm' (minute). If unit is not specified, hour will be used by default.
* **-t**: The maximum time to wait when doing monitor, unit is minutes. default is 60.
* **-V**: Output more information.
``-r`` means replay history of OS provision, if no ``-r`` means to do realtime monitor.
Realtime monitor
----------------
To monitor OS provisioning in real time, open at least 2 terminal windows. One to run ``osdeploy`` probe: ::
xcatprobe osdeploy -n cn1 [-V]
After some pre-checks, the probe will wait for provisioning information, similar to output below: ::
# xcatprobe osdeploy -n c910f03c17k20
The install NIC in current server is enp0s1 [INFO]
All nodes which will be deployed are valid [ OK ]
-------------------------------------------------------------
Start capturing every message during OS provision process......
-------------------------------------------------------------
Open second terminal window to run provisioning: ::
nodeset cn1 osimage=<osimage>
rpower cn1 boot
When all the nodes complete provisioning, the probe will exit and display output similar to: ::
# xcatprobe osdeploy -n c910f03c17k20
The install NIC in current server is enp0s1 [INFO]
All nodes which will be deployed are valid [ OK ]
-------------------------------------------------------------
Start capturing every message during OS provision process......
-------------------------------------------------------------
[c910f03c17k20] Use command rinstall to reboot node c910f03c17k20
[c910f03c17k20] Node status is changed to powering-on
[c910f03c17k20] Receive DHCPDISCOVER via enp0s1
[c910f03c17k20] Send DHCPOFFER on 10.3.17.20 back to 42:d0:0a:03:11:14 via enp0s1
[c910f03c17k20] DHCPREQUEST for 10.3.17.20 (10.3.5.4) from 42:d0:0a:03:11:14 via enp0s1
[c910f03c17k20] Send DHCPACK on 10.3.17.20 back to 42:d0:0a:03:11:14 via enp0s1
[c910f03c17k20] Via TFTP download /boot/grub2/grub2-c910f03c17k20
[c910f03c17k20] Via TFTP download /boot/grub2/powerpc-ieee1275/normal.mod
......
[c910f03c17k20] Postscript: otherpkgs exited with code 0
[c910f03c17k20] Node status is changed to booted
[c910f03c17k20] done
[c910f03c17k20] provision completed.(c910f03c17k20)
[c910f03c17k20] provision completed [ OK ]
All nodes specified to monitor, have finished OS provision process [ OK ]
==================osdeploy_probe_report=================
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) ::
xcatprobe osdeploy -n cn1 -t 30
Replay history
--------------
To replay history of OS provision from 1 hour 20 minutes ago, use command as ::
xcatprobe osdeploy -n cn1 -r 1h20m
Outout will be similar to: ::
# xcatprobe osdeploy -n c910f03c17k20
The install NIC in current server is enp0s1 [INFO]
All nodes which will be deployed are valid [ OK ]
Start to scan logs which are later than *********, waiting for a while.............
==================osdeploy_probe_report=================
All nodes provisioned successfully [ OK ]

2
docs/source/advanced/probe/osimagecheck.rst Normal file
View File

@@ -0,0 +1,2 @@
osimagecheck
============

3
docs/source/advanced/probe/switch-macmap.rst Normal file
View File

@@ -0,0 +1,3 @@
switch-macmap
=============

56
docs/source/advanced/probe/xcatmn.rst Normal file
View File

@@ -0,0 +1,56 @@
xcatmn
======
**xcatmn** can be used to check if xcat has been installed correctly and is ready for use.
**Note**: For several check items(eg. tftp service, dns service, http service), 'tftp', 'nslookup' and 'wget' are need. If not installed, a warning message will be displayed..
Command is as below ::
xcatprobe xcatmn -i <install_nic> [-V]
* **-i**: [Required] Specify the network interface name of provision network on management node.
* **-V**: Output more information for debug.
For example, run command on Management Node ::
xcatprobe xcatmn -i eth0
Output will be similar to: ::
# xcatprobe xcatmn -i eth0
[MN]: Sub process 'xcatd: SSL listener' is running [ OK ]
[MN]: Sub process 'xcatd: DB Access' is running [ OK ]
[MN]: Sub process 'xcatd: UDP listener' is running [ OK ]
[MN]: Sub process 'xcatd: install monitor' is running [ OK ]
[MN]: Sub process 'xcatd: Discovery worker' is running [ OK ]
[MN]: Sub process 'xcatd: Command log writer' is running [ OK ]
[MN]: xcatd is listening on port 3001 [ OK ]
[MN]: xcatd is listening on port 3002 [ OK ]
[MN]: 'lsxcatd -a' works [ OK ]
[MN]: The value of 'master' in 'site' table is an IP address [ OK ]
[MN]: NIC enp0s1 exists on current server [ OK ]
[MN]: Get IP address of NIC eth0 [ OK ]
[MN]: The IP *.*.*.* of eth0 equals the value of 'master' in 'site' table [ OK ]
[MN]: IP *.*.*.* of NIC eth0 is a static IP on current server [ OK ]
[MN]: *.*.*.* belongs to one of networks defined in 'networks' table [ OK ]
[MN]: There is domain definition in 'site' table [ OK ]
[MN]: There is a configuration in 'passwd' table for 'system' for node provisioning [ OK ]
[MN]: There is /install directory on current server [ OK ]
[MN]: There is /tftpboot directory on current server [ OK ]
[MN]: The free space of '/' is less than 12 G [ OK ]
[MN]: SELinux is disabled on current server [ OK ]
[MN]: Firewall is closed on current server [ OK ]
[MN]: HTTP service is ready on *.*.*.* [ OK ]
[MN]: TFTP service is ready on *.*.*.* [ OK ]
[MN]: DNS server is ready on *.*.*.* [ OK ]
[MN]: The size of /var/lib/dhcpd/dhcpd.leases is less than 100M [ OK ]
[MN]: DHCP service is ready on *.*.*.* [ OK ]
======================do summary=====================
[MN]: Check on MN PASS. [ OK ]
**[MN]** means that the verification is performed on the Management Node. Overall status of ``PASS`` or ``FAILED`` will be displayed after all items are verified..
Service Nodes are checked automatically for hierarchical clusters.
For Service Nodes, the output will contain ``[SN:nodename]`` to distinguish different Service Nodes.

12
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 vender and device ID. For example, power8 SAS adapter pci_id is ``1014:034a``, ``1014`` is vender 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 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/``.
Here are steps to use ``diskdiscover``:
@@ -70,19 +70,19 @@ Here are the input parameters introduction:
#. **delete_raid** : List raid arrays which should be removed.
* If its value is all, all raid arrays detected should be deleted.
* If its value is a list of raid array names, these raid arrays will be deleted. Raid array names should be seperated by ``#``.
* If its value is a list of raid array names, these raid arrays will be deleted. Raid array names should be separated by ``#``.
* If its value is null or there is no delete_raid, no raid array will be deleted.
* If there is no delete_raid, the default value is null.
#. **stripe_size** : It is optional used when creating RAID arrays. If stripe size is not specified, it will default to the recommended stripe size for the selected RAID level.
#. **create_raid** : To create a raid array, add a line beginning with create_raid, all attributes keys and values are seperated by ``#``. The formats are as followings:
#. **create_raid** : To create a raid array, add a line beginning with create_raid, all attributes keys and values are separated by ``#``. The formats are as followings:
* ``rl`` means RAID level, RAID level can be any supported RAID level for the given adapter, such as 0, 10, 5, 6. ``rl`` is a mandatory attribute for every create_raid. Supported RAID level is depend on pysical server's RAID adapter.
* ``rl`` means RAID level, RAID level can be any supported RAID level for the given adapter, such as 0, 10, 5, 6. ``rl`` is a mandatory attribute for every create_raid. Supported RAID level is depend on physical server's RAID adapter.
* User can select disks based on following attributes value. User can find these value based on ``diskdiscover`` outputs as above section described.
a. ``pci_id`` is PCI vender and device ID.
a. ``pci_id`` is PCI vendor and device ID.
b. ``pci_slot_name`` is the specified PCI location. If using ``pci_slot_name``, this RAID array will be created using disks from it.
c. ``disk_names`` is a list of advanced format disk names. If using ``disk_names``, this RAID array will be created using these disks.
@@ -139,7 +139,7 @@ Configuring RAID manually in xcat genesis system shell
xdsh cn1 'configraid delete_raid=all create_raid="rl#0|pci_id#1014:034a|disk_num#2"'
Monitoring and debuging RAID configration process
Monitoring and debuging RAID configuration process
''''''''''''''''''''''''''''''''''''''''''''''''''
#. Creating some RAID level arrays take very long time, for example, If user creates RAID 10, it will cost tens of minutes or hours. During this period, you can use xCAT xdsh command to monitor the progress of raid configuration. ::

2
docs/source/advanced/restapi/restapi_setup/restapi_setup.rst
View File

@@ -44,7 +44,7 @@ Enabling the certificate functionality of https server is useful for the Rest AP
The certificate for xcatd has already been generated when installing xCAT, it can be reused by the https server. To enable the server certificate authentication, the hostname of xCAT MN must be a fully qualified domain name (FQDN). The REST API client also must use this FQDN when accessing the https server. If the hostname of the xCAT MN is not a FQDN, you need to change the hostname first.
Typically the hostname of the xCAT MN is initially set to the NIC which faces to the cluster (usually an internal/private NIC). If you want to enable the REST API for public client, please set the hostname of xCAT MN to one of the public NIC.
Typically the hostname of the xCAT MN is initially set to the NIC which faces to the cluster (usually an internal/private NIC). If you want to enable the REST API for public client, set the hostname of xCAT MN to one of the public NIC.
To change the hostname, edit /etc/sysconfig/network (RHEL) or /etc/HOSTNAME (SLES) and run: ::

14
docs/source/advanced/security/security.rst
View File

@@ -1,7 +1,7 @@
Transmission Channel
--------------------
The xCAT daemon uses SSL to only allow authorized users to run xCAT commands. All xCAT commands are initiated as an xCAT **client**, even when run commands from the xCAT management node. This **client** opens an SSL socket to the xCAT daemon, sends the command and receives responses through this one socket. xCAT has configured the certificate for root, if you nee to authorize other users, please refer to below section.
The xCAT daemon uses SSL to only allow authorized users to run xCAT commands. All xCAT commands are initiated as an xCAT **client**, even when run commands from the xCAT management node. This **client** opens an SSL socket to the xCAT daemon, sends the command and receives responses through this one socket. xCAT has configured the certificate for root, if you nee to authorize other users, refer to the section below.
Create SSL Certificate So That User Can Be Authenticated By xCAT
@@ -25,7 +25,7 @@ This will create the following files in the <username> 's ``$HOME/.xcat`` direct
Commands Access Control
-----------------------
Except SSL channel, xCAT only authorize root on the management node to run **xCAT** commands by default. But xCAT can be configured to allow both **non-root users** and **remote users** to run limited xCAT commands. For remote users, we mean the users who triggers the xCAT commands from other nodes and not have to login to the management node. xCAT uses the **policy** table to control who has authority to run specific xCAT commands. For a full explanation of the **policy** table, please refer to :doc:`policy </guides/admin-guides/references/man5/policy.5>` man page.
Except SSL channel, xCAT only authorize root on the management node to run **xCAT** commands by default. But xCAT can be configured to allow both **non-root users** and **remote users** to run limited xCAT commands. For remote users, we mean the users who triggers the xCAT commands from other nodes and not have to login to the management node. xCAT uses the **policy** table to control who has authority to run specific xCAT commands. For a full explanation of the **policy** table, refer to :doc:`policy </guides/admin-guides/references/man5/policy.5>` man page.
Granting Users xCAT Privileges
@@ -74,7 +74,7 @@ Below are the steps of how to set up a login node.
1. Install the xCAT client
In order to avoid stucking in dependence problem in different distro. We recommand to create repository first by referring to below links.
In order to avoid dependency problems on different distros, we recommend creating repository first by referring to links below.
* :doc:`Configure xCAT Software Repository in RHEL</guides/install-guides/yum/configure_xcat>`
@@ -111,11 +111,11 @@ Below are the steps of how to set up a login node.
The remote not-root user still needs to set up the credentials for communication with management node. By running the ``/opt/xcat/share/xcat/scripts/setup-local-client.sh <username>`` command as root in management node, the credentials are generated in <username>'s ``$HOME/.xcat`` directory in management node. These credential files must be copied to the <username>'s ``$HOME/.xcat`` directory on the login node. **Note**: After ``scp``, in the login node, you must make sure the owner of the credentials is <username>.
Setup your ``policy`` table on the managment node with the permissions that you would like the non-root id to have.
Setup your ``policy`` table on the management node with the permissions that you would like the non-root id to have.
At this time, the non-root id should be able to execute any commands that have been set in the ``policy`` table from the Login Node.
If any remote shell commmands (psh,xdsh) are needed, then you need to follow `Extra Setup For Remote Commands`_.
If any remote shell commands (psh,xdsh) are needed, then you need to follow `Extra Setup For Remote Commands`_.
Auditing
@@ -142,7 +142,7 @@ Password Management
xCAT is required to store passwords for various logons so that the application can login to the devices without having to prompt for a password. The issue is how to securely store these passwords.
Currently xCAT stores passwords in ``passwd`` table. You can store them as plaintext, you also can store them as MD5 ciphertext.
Currently xCAT stores passwords in ``passwd`` table. You can store them as plain text, you can also store them as MD5 ciphertext.
Here is an example about how to store a MD5 encrypted password for root in ``passwd`` table. ::
@@ -178,5 +178,5 @@ This setting of site.sshbetweennodes will only enable root ssh between nodes of
Secure Zones
````````````
You can set up multiple zones in an xCAT cluster. A node in the zone can ssh without password to any other node in the zone, but not to nodes in other zones. Please refer :doc:`Zones </advanced/zones/index>` for more information.
You can set up multiple zones in an xCAT cluster. A node in the zone can ssh without password to any other node in the zone, but not to nodes in other zones. Refer to :doc:`Zones </advanced/zones/index>` for more information.

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

@@ -40,7 +40,7 @@ This document describes how to install and configure a template node (called gol
Prepare the xCAT Management Node for Support Sysclone
`````````````````````````````````````````````````````
How to configure xCAT management node please refer to section :ref:`install_guides`
To configure xCAT management node refer to section :ref:`install_guides`
For support Sysclone, we need to install some extra rpms on management node and the golden client.
@@ -93,7 +93,7 @@ Install and Configure the Golden Client
The Golden Client acts as a regular node for xCAT, just have some extra rpms to support clone. When you deploy golden client with xCAT, you just need to add a few additional definitions to the image which will be used to deploy golden client.
For information of how to install a regular node, please refer to section :ref:`Diskful Installation <diskful_installation>`
For information of how to install a regular node, refer to section :ref:`Diskful Installation <diskful_installation>`
For support clone, add 'otherpkglist' and 'otherpkgdir' attributes to the image definition which will be used to deploy golden client, then deploy golden client as normal. then the golden client will have extra rpms to support clone. If you have deployed your golden client already, using 'updatenode' command to push these extra rpms to golden client. CentOS share the same pkglist file with RHEL. For example:
@@ -121,7 +121,7 @@ For support clone, add 'otherpkglist' and 'otherpkgdir' attributes to the image
chdef -t osimage -o <osimage-name> -p otherpkgdir=/install/post/otherpkgs/rhels6.3/ppc64
updatenode <golden-cilent> -S
*[Note]: If you install systemimager RPMs on CentOS 6.5 node by above steps, you maybe hit failure. this is a known issue because some defect of CentOS6.5 itself. Please refer to known issue section for help.*
*[Note]: If you install systemimager RPMs on CentOS 6.5 node by above steps, you maybe hit failure. this is a known issue because some defect of CentOS6.5 itself. Refer to known issue section for help.*
Capture Image from Golden Client
````````````````````````````````
@@ -159,7 +159,7 @@ If, at a later time, you need to make changes to the golden client (install new
**[Limitation]**: In xcat2.8.5, this feature has limitation in RHEL and CentOS. when your delta changes related bootloader, it would encounter error. This issue will be fixed in xcat higher version. So up to now, in RHEL and CentOS, this feature just update files not related bootloader.
Update delta changes please follow below steps:
Update delta changes follow below steps:
1. Make changes to your golden node (install new rpms, change config files, etc.).
@@ -199,7 +199,7 @@ Known Issue
Can not install systemimager RPMs in CentOS6.5 by yum
``````````````````````````````````````````````````````
If you install systemimager RPMs on CentOS 6.5 node by yum, you maybe hit failure because some defect of CentOS6.5 itself. So please copy related RPMs to CentOS 6.5 node and install them by hand.
If you install systemimager RPMs on CentOS 6.5 node using yum, you may experience some problems due to CentOS6.5 itself. If that happens, copy related RPMs to CentOS 6.5 node and install them by hand.
* **On management node**::

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

@@ -12,7 +12,7 @@ Clone the xCAT project from `GitHub <https://github.com/xcat2/xcat-core>`_::
xcat-deps
---------
The ``xcat-deps`` package is currently owned and maintained by the core development on our internal servers. Please use the packages created at: http://xcat.org/download.html#xcat-dep
The ``xcat-deps`` package is currently owned and maintained by the core development on our internal servers. Use the packages created at: http://xcat.org/download.html#xcat-dep
man pages

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

@@ -161,7 +161,7 @@ Add links to refer other web page is a very common way in writting document, it
Add OS or ARCH Specific Contents
--------------------------------
When writing a common xCAT doc, we always encounter the case that certain small part of content needs to be OS or ARCH specific. In this case, please use the following format to add specific branches.
When writing a common xCAT doc, we always encounter the case that certain small part of content needs to be OS or ARCH specific. In this case, use the following format to add specific branches.
The keyword in the **[]** can be an OS name or ARCH name, or any name which can distinguish the content from other part.

2
docs/source/developers/license/index.rst
View File

@@ -3,7 +3,7 @@ Contributor and Maintainer Agreements
We welcome developers willing to contribute to the xCAT project to help make it better.
Please follow the guidelines below.
Follow the guidelines below.
.. toctree::
:maxdepth: 1

2
docs/source/developers/license/xcat_corporate_contributor_license_agreement.rst
View File

@@ -7,7 +7,7 @@ In order to clarify the intellectual property license granted with Contributions
This version of the Agreement allows an entity (the "Corporation") to submit Contributions to the xCAT Community, to authorize Contributions submitted by its designated employees to the xCAT Community, and to grant copyright and patent licenses thereto.
If you have not already done so, please complete and sign, then scan and email a PDF file of this Agreement to: **xcat-legal@lists.sourceforge.net**. Please read this document carefully before signing and keep a copy for your records.
If you have not already done so, complete and sign, then scan and email a PDF file of this Agreement to: **xcat-legal@lists.sourceforge.net**. Read this document carefully before signing and keep a copy for your records.
Corporation name: ___________________________________________________

2
docs/source/developers/license/xcat_individual_contributor_license_agreement.rst
View File

@@ -5,7 +5,7 @@ The xCAT Community Individual Contributor License Agreement ("Agreement")
In order to clarify the intellectual property license granted with Contributions from any person or entity made for the benefit of the xCAT Community, a Contributor License Agreement ("CLA") must be on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the xCAT Community and its users; it does not change your rights to use your own Contributions for any other purpose.
If you have not already done so, please complete and sign, then scan and email a PDF file of this Agreement to: **xcat-legal@lists.sourceforge.net**.
If you have not already done so, complete and sign, then scan and email a PDF file of this Agreement to: **xcat-legal@lists.sourceforge.net**.

10
docs/source/guides/admin-guides/basic_concepts/global_cfg/index.rst
View File

@@ -1,9 +1,9 @@
Global Configuration
====================
All the xCAT global configurations are stored in site table, xCAT Admin can adjust the configuration by modifing the site attibute with ``tabedit``.
All the xCAT global configurations are stored in site table, xCAT Admin can adjust the configuration by modifying the site attribute with ``tabedit``.
This section only presents some key global configurations, for the complete reference on the xCAT global configurations, please refer to the ``tabdump -d site``.
This section only presents some key global configurations, for the complete reference on the xCAT global configurations, refer to the ``tabdump -d site``.
Database Attributes
@@ -71,7 +71,7 @@ Install/Deployment Attributes
The local directory name used to hold the node deployment packages.
* runbootscripts:
If set to ``yes`` the scripts listed in the postbootscripts attribute in the osimage and postscripts tables will be run during each reboot of stateful (diskful) nodes. This attribute has no effect on stateless nodes. Please run the following command after you change the value of this attribute ::
If set to ``yes`` the scripts listed in the postbootscripts attribute in the osimage and postscripts tables will be run during each reboot of stateful (diskful) nodes. This attribute has no effect on stateless nodes. Run the following command after you change the value of this attribute ::
updatenode <nodes> -P setuppostbootscripts
@@ -83,9 +83,9 @@ Install/Deployment Attributes
'0': disable debug mode
'1': enable basic debug mode
'2': enalbe expert debug mode
'2': enable expert debug mode
For the details on 'basic debug mode' and 'expert debug mode', please refer to xCAT documentation.
For the details on 'basic debug mode' and 'expert debug mode', refer to xCAT documentation.
Remoteshell Attributes

2
docs/source/guides/admin-guides/basic_concepts/network_planning/index.rst
View File

@@ -19,7 +19,7 @@ For a cluster, several networks are necessary to enable the cluster management a
* DHCP(Dynamic Host Configuration Protocol)
The dhcp server, usually the management node or service node, privides the dhcp service for the entire cluster.
The dhcp server, usually the management node or service node, provides the dhcp service for the entire cluster.
* TFTP(Trivial File Transfer Protocol)

2
docs/source/guides/admin-guides/basic_concepts/network_planning/xcat_net_planning.rst
View File

@@ -54,7 +54,7 @@ It is important to note that some HA-related software like DRDB, Pacemaker, and
HA Service Nodes
````````````````
When you have NFS-based diskless (statelite) nodes, there is sometimes the motivation make the NFS serving highly available among all of the service nodes. This is not recommended because it is a very complex configuration. In our opinion, the complexity of this setup can nullify much of the availibility you hope to gain. If you need your compute nodes to be highly available, you should strongly consider stateful or stateless nodes.
When you have NFS-based diskless (statelite) nodes, there is sometimes the motivation make the NFS serving highly available among all of the service nodes. This is not recommended because it is a very complex configuration. In our opinion, the complexity of this setup can nullify much of the availability you hope to gain. If you need your compute nodes to be highly available, you should strongly consider stateful or stateless nodes.
If you still have reasons to pursue HA service nodes:

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

@@ -1,7 +1,7 @@
xCAT Cluster OS Running Type
============================
Whether a node is a pyhsical server or a virtual machine, it needs to run an Operating System to support user applications. Generally, the OS is installed in the hard disk of the compute node. But xCAT also support the type that running OS in the RAM.
Whether a node is a physical server or a virtual machine, it needs to run an Operating System to support user applications. Generally, the OS is installed in the hard disk of the compute node. But xCAT also support the type that running OS in the RAM.
This section gives the pros and cons of each OS running type, and describes the cluster characteristics that will impact from each.
@@ -32,7 +32,7 @@ Nodes boot from a RAMdisk OS image downloaded from the xCAT mgmt node or service
You can't use a large image with many different applications in the image for varied users, because it uses too much of the node's memory to store the ramdisk. (To mitigate this disadvantage, you can put your large application binaries and libraries in shared storage to reduce the ramdisk size. This requires some manual configuration of the image).
Each node can also have a local "scratch" disk for ``swap``, ``/tmp``, ``/var``, ``log`` files, dumps, etc. The purpose of the scratch disk is to provide a location for files that are written to by the node that can become quite large or for files that you don't want to disappear when the node reboots. There should be nothing put on the scratch disk that represents the node's "state", so that if the disk fails you can simply replace it and reboot the node. A scratch disk would typically be used for situations like: job scheduling preemption is required (which needs a lot of swap space), the applications write large temp files, or you want to keep gpfs log or trace files persistently. (As a partial alternative to using the scratch disk, customers can choose to put ``/tmp`` ``/var/tmp``, and log files (except GPFS logs files) in GPFS, but must be willing to accept the dependency on GPFS). This can be done by enabling the 'localdisk' support. For the details, please refer to the section [TODO Enabling the localdisk Option].
Each node can also have a local "scratch" disk for ``swap``, ``/tmp``, ``/var``, ``log`` files, dumps, etc. The purpose of the scratch disk is to provide a location for files that are written to by the node that can become quite large or for files that you don't want to disappear when the node reboots. There should be nothing put on the scratch disk that represents the node's "state", so that if the disk fails you can simply replace it and reboot the node. A scratch disk would typically be used for situations like: job scheduling preemption is required (which needs a lot of swap space), the applications write large temp files, or you want to keep gpfs log or trace files persistently. (As a partial alternative to using the scratch disk, customers can choose to put ``/tmp`` ``/var/tmp``, and log files (except GPFS logs files) in GPFS, but must be willing to accept the dependency on GPFS). This can be done by enabling the 'localdisk' support. For the details, refer to the section [TODO Enabling the localdisk Option].
OSimage Definition

2
docs/source/guides/admin-guides/basic_concepts/xcat_db/index.rst
View File

@@ -40,7 +40,7 @@ For a complete reference, see the man page for xcatdb: ``man xcatdb``.
**Manipulate xCAT Database Tables**
xCAT offers 5 commands to manipulate the databse tables:
xCAT offers 5 commands to manipulate the database tables:
* ``tabdump``

6
docs/source/guides/admin-guides/basic_concepts/xcat_db/regexp_db.rst
View File

@@ -26,7 +26,7 @@ Another example is if "node1" is assigned the IP address "10.0.0.1", node2 is as
#node,ip,hostnames,otherinterfaces,comments,disable
"compute","|node(\d+)|10.0.0.($1+0)|",,,,
In this example, the regular expression in the ``ip`` attribute uses ``|`` to separate the 1st and 2nd part. This means that xCAT will allow arithmetic operations in the 2nd part. In the 1st part, ``(\d+)``, will match the number part of the node name and put that in a variable called ``$1``. The 2nd part is what value to give the ``ip`` attribute. In this case it will set it to the string "10.0.0." and the number that is in ``$1``. (Zero is added to ``$1`` just to remove any leading zeroes.)
In this example, the regular expression in the ``ip`` attribute uses ``|`` to separate the 1st and 2nd part. This means that xCAT will allow arithmetic operations in the 2nd part. In the 1st part, ``(\d+)``, will match the number part of the node name and put that in a variable called ``$1``. The 2nd part is what value to give the ``ip`` attribute. In this case it will set it to the string "10.0.0." and the number that is in ``$1``. (Zero is added to ``$1`` just to remove any leading zeros.)
A more involved example is with the ``vm`` table. If your kvm nodes have node names c01f01x01v01, c01f02x03v04, etc., and the kvm host names are c01f01x01, c01f02x03, etc., then you might have an ``vm`` table like ::
@@ -45,14 +45,14 @@ Before you panic, let me explain each column:
``|\D+(\d+)\D+(\d+)\D+(\d+)\D+(\d+)|dir:///install/vms/vm($4+0)|``
This item is similar to the one above. This substituion pattern will produce the value for the 5th column (a list of storage files or devices to be used). Because this row was the match for "c01f02x03v04", the produced value is "dir:///install/vms/vm4".
This item is similar to the one above. This substitution pattern will produce the value for the 5th column (a list of storage files or devices to be used). Because this row was the match for "c01f02x03v04", the produced value is "dir:///install/vms/vm4".
Just as the explained above, when the node definition "c01f02x03v04" is created with ::
# mkdef -t node -o c01f02x03v04 groups=kvms
1 object definitions have been created or modified.
The generated node deinition is ::
The generated node definition is ::
# lsdef c01f02x03v04
Object name: c01f02x03v04

2
docs/source/guides/admin-guides/basic_concepts/xcat_object/index.rst
View File

@@ -67,7 +67,7 @@ You can get the detail description of each object by ``man <object type>`` e.g.
* **group Object**
**group** is an object which includes multiple **node object**. When you set **group** attribute for a **node object** to a group name like **x86_64**, the group **x86_64** is automatically genereated and the node is assigned to the group.
**group** is an object which includes multiple **node object**. When you set **group** attribute for a **node object** to a group name like **x86_64**, the group **x86_64** is automatically generated and the node is assigned to the group.
The benefits of using **group object**:

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

@@ -18,15 +18,15 @@ The paralell compression tool ``pigz`` can be enabled by installing ``pigz`` pac
EPEL has an ``epel-release`` package that includes gpg keys for package signing and repository information. Installing this package for your Enterprise Linux version should allow you to use normal tools such as ``yum`` to install packages and their dependencies.
Please refer to the http://fedoraproject.org/wiki/EPEL for more details on EPEL
Refer to the http://fedoraproject.org/wiki/EPEL for more details on EPEL
1) Enabling the ``pigz`` in ``genimage`` (only supported in RHELS6 or above)
``pigz`` should be installed in the diskless rootimg. Please 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.
``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``
``pigz`` should be installed on the management server. Please download ``pigz`` package from https://dl.fedoraproject.org/pub/epel/ , then install the ``pigz`` with ``yum`` or ``rpm``.
``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``.
* **[UBUNTU]**

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

@@ -33,7 +33,7 @@ If you have newer updates to some of your operating system packages that you wou
createrepo .
chdef -t osimage <os>-<arch>-<inst_type>-<profile> pkgdir=/install/<os>/<arch>,/install/osupdates/<os>/<arch>
Note:If the objective node is not installed by xCAT,please make sure the correct osimage pkgdir attribute so that you could get the correct repository data.
Note:If the objective node is not installed by xCAT, make sure the correct osimage pkgdir attribute so that you could get the correct repository data.
.. _File-Format-for-pkglist-label:

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

@@ -72,7 +72,7 @@ Here is partition definition file example for RedHat LVM partition in IBM Power
.. BEGIN_partition_definition_file_example_RedHat_RAID1_for_IBM_Power_machines
Partition definition file example for RedHat RAID1 please refer to :doc:`Configure RAID before Deploy OS </guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/raid_cfg>`
To partition definition file example for RedHat RAID1 refer to :doc:`Configure RAID before Deploy OS </guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/raid_cfg>`
.. END_partition_definition_file_example_RedHat_RAID1_for_IBM_Power_machines
@@ -287,7 +287,7 @@ Here is partition definition file example for SLES standard partition in ppc64 m
.. BEGIN_partition_definition_file_example_SLES_RAID1
Partition definition file example for SLES RAID1 please refer to `Configure RAID before Deploy OS <http://xcat-docs.readthedocs.org/en/latest/guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/raid_cfg.html>`_
To partition definition file example for SLES RAID1 refer to `Configure RAID before Deploy OS <http://xcat-docs.readthedocs.org/en/latest/guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/raid_cfg.html>`_
.. END_partition_definition_file_example_SLES_RAID1

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

@@ -150,7 +150,7 @@ Currently, only NFS is supported for the setup of kdump.
If the dump attribute is not set, the kdump service will not be enabled.
Please make sure the NFS remote path(nfs://<nfs_server_ip>/<kdump_path>) is exported and it is read-writeable to the node where kdump service is enabled.
Make sure the NFS remote path(nfs://<nfs_server_ip>/<kdump_path>) is exported and it is read-writeable to the node where kdump service is enabled.
How to trigger kernel panic on Linux
------------------------------------

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

@@ -104,7 +104,7 @@ Skip this section if you want to use the image as is.
* Modify .pkglist file to add or remove packges that are from the os distro
* Modify .otherpkgs.pkglist to add or remove packages from other sources. Please refer to ``Using_Updatenode`` for details
* Modify .otherpkgs.pkglist to add or remove packages from other sources. Refer to ``Using_Updatenode`` for details
* For diskful, modify the .tmpl file to change the kickstart/autoyast configuration

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

@@ -109,7 +109,7 @@ To create the virtual machine "vm1" with 20G hard disk on a hypervisor directory
mkvm vm1 -s 20G
When "vm1" is created successfully, a VM hard disk file with a name like "vm1.sda.qcow2" will be found in the location specified by **vmstorage**. What's more, the **mac** attribute of "vm1" is set automatically, please check it with: ::
When "vm1" is created successfully, a VM hard disk file with a name like "vm1.sda.qcow2" will be found in the location specified by **vmstorage**. What's more, the **mac** attribute of "vm1" is set automatically, check it with: ::
lsdef vm1 -i mac
@@ -132,7 +132,7 @@ or running the following command on the kvm hypervisor "kvmhost1" ::
Monitoring the Virtual Machine
``````````````````````````````
When the VM has been created and powered on, please choose one of the following methods to monitor and access it.
When the VM has been created and powered on, choose one of the following methods to monitor and access it.
* Open the console on kvm hypervisor: ::

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

@@ -29,7 +29,7 @@ Installing Additional OS Distro Packages
For packages from the OS distro, add the new package names (without the version number) in the .pkglist file. If you have newer updates to some of your operating system packages that you would like to apply to your OS image, you can place them in another directory, and add that directory to your osimage pkgdir attribute. How to add additional OS distro packages, go to :ref:`Install-Additional-OS-Packages-label`
Note:If the objective node is not installed by xCAT, please make sure the correct osimage pkgdir attribute so that you could get the correct repository data.
Note:If the objective node is not installed by xCAT, make sure the correct osimage pkgdir attribute so that you could get the correct repository data.
Install Additional non-OS Packages
``````````````````````````````````
@@ -132,8 +132,8 @@ Linux: xdsh <noderange> -e /install/postscripts/xcatdsklspost -m <server> <scrip
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. Please 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. Please make sure /tmp and /xcatpost have enough space to hold the rpms and please 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. Please 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, please make sure all the necessary depended rpms are copied in the same source directory.
* 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.
* 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/discovery_using_defined.rst
View File

@@ -69,8 +69,6 @@ The BMC IP address is obtained by the open range dhcp server and the plan in thi
mgt=ipmi
mtm=8247-22L
serial=10112CA
nodetype=mp
hwtype=bmc
#. Edit the ``predefined.stanzas`` file and change the discovered nodes to the intended ``hostname`` and ``IP address``.
@@ -87,7 +85,7 @@ The BMC IP address is obtained by the open range dhcp server and the plan in thi
ip=10.1.2.1
#. Remove ``nodetype`` and ``hwtype`` from ``predefined.stanza`` file based on the MTMS mapping.
#. Remove ``nodetype`` and ``hwtype`` if defined in the ``predefined.stanza``.
#. Repeat for additional nodes in the ``predefined.stanza`` file based on the MTMS mapping.

2
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/pbmc_discovery.rst
View File

@@ -22,7 +22,7 @@ The discovered PBMC node will be like this::
postscripts=syslog,remoteshell,syncfiles
serial=10112CA
**Note**: Pls note that the PBMC node is just used to control the physical during hardware discovery process, it will be deleted after the correct server node object is found.
**Note**: Note that the PBMC node is just used to control the physical during hardware discovery process, it will be deleted after the correct server node object is found.
Start discovery process
-----------------------

2
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/seq_discovery.rst
View File

@@ -26,7 +26,7 @@ Set the target `osimage` into the chain table to automatically provision the ope
chdef cn1 -p chain="osimage=<osimage_name>"
For more information about chain, please refer to :doc:`Chain <../../../../../advanced/chain/index>`
For more information about chain, refer to :doc:`Chain <../../../../../advanced/chain/index>`
Initialize the discovery process
````````````````````````````````

2
docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/switch_discovery.rst
View File

@@ -62,7 +62,7 @@ Set the target `osimage` into the chain table to automatically provision the ope
chdef cn1 -p chain="osimage=<osimage_name>"
For more information about chain, please refer to :doc:`Chain <../../../../../advanced/chain/index>`
For more information about chain, refer to :doc:`Chain <../../../../../advanced/chain/index>`
Add cn1 into DNS::

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

@@ -14,7 +14,7 @@ With xCAT, the end user can turn the beacon light on or off with the commands sh
rbeacon cn1 on
rbeacon cn1 off
Please notice, the current state of the beacon light can not be inquery remotely. As a workaround, one can always use the ``rbeacon`` command to turn all the beacon lights in one frame off, and then turn a particular beancon light on. ::
The current state of the beacon light can not be queried remotely. As a workaround, one can always use the ``rbeacon`` command to turn all the beacon lights in one frame off, and then turn a particular beacon light on. ::
rbeacon a_group_of_cn off
rbeacon cn5 on
@@ -35,7 +35,7 @@ Or do a hardware reset, run ::
rpower cn1 reset
Get the current rpower state of a machine, please refer to the example below. ::
Get the current rpower state of a machine, refer to the example below. ::
# rpower cn1 state
cn1: Running
@@ -80,16 +80,16 @@ To get all the hardware information, which including the model type, serial numb
rinv cn1 all
As an example, in order to get only the information of firmware version, the follwing command can be used. ::
As an example, in order to get only the information of firmware version, the following command can be used. ::
rinv cn1 firm
Remote Hardware Vitals
``````````````````````
Collect runtime information from running physical machine is also a big requirement for real life system administrators. This kind of information includes, temperature of CPU, internal voltage of paricular socket, wattage with workload, speed of cooling fan, et al.
Collect runtime information from running physical machine is also a big requirement for real life system administrators. This kind of information includes, temperature of CPU, internal voltage of particular socket, wattage with workload, speed of cooling fan, et al.
In order to get such information, please use ``rvitals`` command. Please also notice, this kind of information various among different model types of the machine. Thus, please check the actual output of the ``rvitals`` command against your machine, to verify which kinds of information can be get. The information may change due to the firmware updating of the machine. ::
In order to get such information, use ``rvitals`` command. This kind of information varies among different model types of the machine. Thus, check the actual output of the ``rvitals`` command against your machine, to verify which kinds of information can be extracted. The information may change after the firmware update of the machine. ::
rvitals cn1 all
@@ -115,7 +115,7 @@ Update node firmware to the version of the HPM file
Configures Nodes' Service Processors
````````````````````````````````````
Here comes the command, ``rspconfig``. It is used to configure the service processor of a physical machine. On a OpenPower system, the service processor is the BMC, Baseboard Management Controller. Various variables can be set through the command. But, please also notice, the actual configuration may change among different machine-model types.
Here comes the command, ``rspconfig``. It is used to configure the service processor of a physical machine. On a OpenPower system, the service processor is the BMC, Baseboard Management Controller. Various variables can be set through the command. Also notice, the actual configuration may change among different machine-model types.
Examples

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

@@ -28,7 +28,7 @@ rpower fails with "Error: internal error Process exited while reading console lo
Then restart the NFS services and try to power on the VM again...
**Note**: For stateless hypervisor, please purge the VM by ``rmvm -p vm1``, reboot the hypervisor and then create the VM.
**Note**: For stateless hypervisor, purge the VM by ``rmvm -p vm1``, reboot the hypervisor and then create the VM.
rpower fails with "Error: internal error: process exited while connecting to monitor qemu: Permission denied"
-------------------------------------------------------------------------------------------------------------
@@ -77,7 +77,7 @@ Error: Cannot communicate via libvirt to kvmhost1
The kvm related commands complain "Error: Cannot communicate via libvirt to kvmhost1"
**Solution**:
Usually caused by incorrect ssh configuration between xCAT management node and hypervisor. Please make sure it is possible to access the hypervisor from management node via ssh without password.
Usually caused by incorrect ssh configuration between xCAT management node and hypervisor. Make sure it is possible to access the hypervisor from management node via ssh without password.
Fail to ping the installed VM
@@ -89,7 +89,7 @@ Fail to ping the installed VM
ADDRCONF(NETDEV_UP): eth0 link is not ready.
**Solutoin**:
Usually caused by the incorrect VM NIC model. Please try the following steps to specify "virtio": ::
Usually caused by the incorrect VM NIC model. Try the following steps to specify "virtio": ::
rmvm vm1
chdef vm1 vmnicnicmodel=virtio

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

@@ -3,4 +3,4 @@ x86_64
This section is not available at this time.
Please refer to `xCAT Documentation <https://sourceforge.net/p/xcat/wiki/XCAT_Documentation/>`_ on SourceForge for information on System X servers.
Refer to `xCAT Documentation <https://sourceforge.net/p/xcat/wiki/XCAT_Documentation/>`_ on SourceForge for information on System X servers.

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

@@ -47,7 +47,7 @@ OPTIONS
\ **-n|-**\ **-nodes**\ The nodes or groups to be added or removed. It takes the noderange format. Please check the man page for noderange for details.
\ **-n|-**\ **-nodes**\ The nodes or groups to be added or removed. It takes the noderange format. Check the man page for noderange for details.

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

@@ -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, please 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 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.
@@ -838,7 +838,7 @@ The resource information after modification is similar to:
lpar1: 128.
Note: The physical I/O resources specified with \ *add_physlots*\ will be appended to the specified partition. The physical I/O resources which are not specified but belonged to the partition will not be removed. For more information about \ *add_physlots*\ , please refer to lsvm(1)|lsvm.1.
Note: The physical I/O resources specified with \ *add_physlots*\ will be appended to the specified partition. The physical I/O resources which are not specified but belonged to the partition will not be removed. For more information about \ *add_physlots*\ , refer to lsvm(1)|lsvm.1.
VMware/KVM specific:

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. Please use \ **-**\ **-interactive**\ flag if you want the yum/zypper command to prompt you for the answers.
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.
If \ **-**\ **-onlyinitrd**\ is specified, genimage only regenerates the initrd for a stateless image to be used for a diskless install.

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

@@ -86,7 +86,7 @@ Display MAC only. The default is to write the first valid adapter MAC to the xCA
\ **-D**\
Perform discovery for mac address. By default, it will run ping test to test the connection between adapter and xCAT management node. Use '--noping' can skip the ping test to save time. Please be aware that in this way, the lpars will be reset.
Perform discovery for mac address. By default, it will run ping test to test the connection between adapter and xCAT management node. Use '--noping' can skip the ping test to save time. Be aware that in this way, the lpars will be reset.
\ **-f**\

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

@@ -39,7 +39,7 @@ The \ **diskless**\ type:
The attributes of osimage will be used to capture and prepare the root image. The \ **osver**\ , \ **arch**\ and \ **profile**\ attributes for the stateless/statelite image to be created are duplicated from the \ **node**\ 's attribute. If the \ **-p|-**\ **-profile**\ \ *profile*\ option is specified, the image will be created under "/<\ *installroot*\ >/netboot/<osver>/<arch>/<\ *profile*\ >/rootimg".
The default files/directories excluded in the image are specified by /opt/xcat/share/xcat/netboot/<os>/<\ *profile*\ >.<osver>.<arch>.imgcapture.exlist; also, you can put your customized file (<\ *profile*\ >.<osver>.<arch>.imgcapture.exlist) to /install/custom/netboot/<osplatform>. The directories in the default \ *.imgcapture.exlist*\ file are necessary to capture image from the diskful Linux node managed by xCAT, please don't remove it.
The default files/directories excluded in the image are specified by /opt/xcat/share/xcat/netboot/<os>/<\ *profile*\ >.<osver>.<arch>.imgcapture.exlist; also, you can put your customized file (<\ *profile*\ >.<osver>.<arch>.imgcapture.exlist) to /install/custom/netboot/<osplatform>. The directories in the default \ *.imgcapture.exlist*\ file are necessary to capture the image from the diskful Linux node managed by xCAT, don't remove it.
The image captured will be extracted into the /<\ *installroot*\ >/netboot/<\ **osver**\ >/<\ **arch**\ >/<\ **profile**\ >/rootimg directory.

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

@@ -31,7 +31,7 @@ DESCRIPTION
***********
The lsslp command discovers selected service types using the -s flag. All service types are returned if the -s flag is not specified. If a specific IP address is not specified using the -i flag, the request is sent out all available network adapters. The optional -r, -x, -z and --vpdtable flags format the output. If you can't receive all the hardware, please use -T to increase the waiting time.
The lsslp command discovers selected service types using the -s flag. All service types are returned if the -s flag is not specified. If a specific IP address is not specified using the -i flag, the request is sent out all available network adapters. The optional -r, -x, -z and --vpdtable flags format the output. If you can't receive all the hardware, use -T to increase the waiting time.
NOTE: SLP broadcast requests will propagate only within the subnet of the network adapter broadcast IPs specified by the -i flag.
@@ -41,7 +41,7 @@ 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). Please do not use noderange with the flag -s.
\ **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.
\ **-i**\ IP(s) the command will send out (defaults to all available adapters).
@@ -75,7 +75,7 @@ OPTIONS
\ **-z**\ Stanza formated output.
\ **-I**\ Give the warning message for the nodes in database which have no SLP responses. Please 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 noly can be used after the database migration finished successfully.
************
@@ -298,7 +298,7 @@ Output is similar to:
bpa 9458-100 BPCF017 B-0 40.17.0.2 f17c00bpcb_a
8. To find the nodes within the user specified. Please make sure the noderange input have been defined in xCAT database.
8. To find the nodes within the user specified. Make sure the noderange input have been defined in xCAT database.
.. code-block:: perl

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

@@ -32,7 +32,7 @@ By default, it sets up the NTP server for xCAT management node. If -a flag is sp
\ *site.ntpservers*\ -- the NTP servers for the service node and compute node to sync with. The keyword <xcatmaster> means that the node's NTP server is the node that is managing it (either its service node or the management node).
To setup NTP on the compute node, please add \ **setupntp**\ postscript to the \ *postscripts*\ table and run \ *updatenode node -P setupntp*\ command.
To setup NTP on the compute node, add \ **setupntp**\ postscript to the \ *postscripts*\ table and run \ *updatenode node -P setupntp*\ command.
*******

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

@@ -54,7 +54,7 @@ OPTIONS
\ **dockerflag**\
A JSON string which will be used as parameters to create a docker. Please reference https://docs.docker.com/engine/reference/api/docker_remote_api_v1.22/ for more information about which parameters can be specified.
A JSON string which will be used as parameters to create a docker. Reference https://docs.docker.com/engine/reference/api/docker_remote_api_v1.22/ for more information about which parameters can be specified.
Some useful flags are:

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

@@ -61,7 +61,7 @@ You can use the force option to reinitialize a node if it already has resources
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. Please 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 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.
*******

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

@@ -66,7 +66,7 @@ For example:
This command will automatically configure the cross-over ports if the given nodes are on different switches.
For added security, the root guard and bpdu guard will be enabled for the ports in this vlan. However, the guards will not be disabled if the ports are removed from the vlan using chvlan or rmvlan commands. To disable them, you need to use the switch command line interface. Please refer to the switch command line interface manual to see how to disable the root guard and bpdu guard for a port.
For added security, the root guard and bpdu guard will be enabled for the ports in this vlan. However, the guards will not be disabled if the ports are removed from the vlan using chvlan or rmvlan commands. To disable them, you need to use the switch command line interface. Refer to the switch command line interface manual to see how to disable the root guard and bpdu guard for a port.
**********
@@ -83,7 +83,7 @@ OPTIONS
\ **-n|-**\ **-nodes**\ The nodes or groups to be included in the vlan. It can be stand alone nodes or KVM guests. It takes the noderange format. Please check the man page for noderange for details.
\ **-n|-**\ **-nodes**\ The nodes or groups to be included in the vlan. It can be stand alone nodes or KVM guests. It takes the noderange format. Check the man page for noderange for details.
@@ -137,7 +137,7 @@ To start, the xCAT switches and switches table needs to be filled with switch an
"node3","switch1","12",,"primary:eth0",,
"node3","switch2","3",,"eth1",,
Please note that the interface value for the management (primary) network can be empty, the word "primary" or "primary:ethx". For other networks, the interface attribute must be specified.
Note that the interface value for the management (primary) network can be empty, the word "primary" or "primary:ethx". For other networks, the interface attribute must be specified.
The following is an example of the switches table

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

@@ -85,9 +85,9 @@ The first form of \ **mkvm**\ command creates new partition(s) with the same pr
The second form of this command duplicates all the partitions from the source specified by \ *profile*\ to the destination specified by \ *destcec*\ . The source and destination CECs can be managed by different HMCs.
Please make sure the nodes in the \ *noderange*\ is defined in the \ *nodelist*\ table and the \ *mgt*\ is set to 'hmc' in the \ *nodehm*\ table before running this command.
Make sure the nodes in the \ *noderange*\ is defined in the \ *nodelist*\ table and the \ *mgt*\ is set to 'hmc' in the \ *nodehm*\ table before running this command.
Please note that the \ **mkvm**\ command currently only supports creating standard LPARs, not virtual LPARs working with VIOS server.
Note that the \ **mkvm**\ command currently only supports creating standard LPARs, not virtual LPARs working with VIOS server.
For PPC (using Direct FSP Management) specific:

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

@@ -41,7 +41,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.
\ *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 ...*\ Please 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 possbile setting keys for a plug-in module.
*******

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

@@ -75,7 +75,7 @@ EXAMPLES
monrm gangliamon
Please note that gangliamon must have been registered in the xCAT \ *monitoring*\ table. For a list of registered plug-in modules, use command \ **monls**\ .
Note that gangliamon must have been registered in the xCAT \ *monitoring*\ table. For a list of registered plug-in modules, use command \ **monls**\ .
*****

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

@@ -79,7 +79,7 @@ EXAMPLES
monstop gangliamon
Please note that gangliamon must have been registered in the xCAT \ *monitoring*\ table. For a list of registered plug-in modules, use command \ *monls*\ .
Note that gangliamon must have been registered in the xCAT \ *monitoring*\ table. For a list of registered plug-in modules, use command \ *monls*\ .
*****

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

@@ -64,7 +64,7 @@ This command will also create a NIM script resource to enable the xCAT support f
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. Please 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 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.
*******

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

@@ -31,12 +31,9 @@ DESCRIPTION
***********
Packs the stateless image from the chroot file system into a file system to be
sent to the node for a diskless install.
The install dir is setup by using "installdir" attribute set in the site table.
The nodetype table "profile" attribute for the node should reflect the profile of the install image.
Packs the stateless image from the chroot file system into a file to be sent to the node for a diskless boot.
This command will get all the necessary os image definition files from the \ *osimage*\ and \ *linuximage*\ tables.
Note: For an osimage that is deployed on a cluster, running packimage will overwrite the existing rootimage file and be unavailable to the compute nodes while the command executes.
**********
@@ -44,7 +41,7 @@ PARAMETERS
**********
\ *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.
\ *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.
*******
@@ -76,7 +73,7 @@ EXAMPLES
********
1. To pack the osimage rhels7.1-x86_64-netboot-compute:
1. To pack the osimage 'rhels7.1-x86_64-netboot-compute':
.. code-block:: perl
@@ -84,7 +81,7 @@ EXAMPLES
packimage rhels7.1-x86_64-netboot-compute
2. To pack the osimage rhels7.1-x86_64-netboot-compute with "tar" to archive and "pigz" to compress:
2. To pack the osimage 'rhels7.1-x86_64-netboot-compute' with "tar" to archive and "pigz" to compress:
.. code-block:: perl

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

@@ -73,7 +73,7 @@ PPC (with HMC) specific:
========================
The \ **rflash**\ command uses the \ **xdsh**\ command to connect to the HMC controlling the given managed system and perform the updates. Before run \ **rflash**\ , please use \ **rspconfig**\ to check if the related HMC ssh is enabled. If enable a HMC ssh connection, please use \ **rspconfig**\ comamnd.
The \ **rflash**\ command uses the \ **xdsh**\ command to connect to the HMC controlling the given managed system and perform the updates. Before running \ **rflash**\ , use \ **rspconfig**\ to check if the related HMC ssh is enabled. To enable a HMC ssh connection, use \ **rspconfig**\ comamnd.
\ **Warning!**\ This command may take considerable time to complete, depending on the number of systems being updated and the workload on the target HMC. In particular, power subsystem updates may take an hour or more if there are many attached managed systems.
@@ -91,7 +91,7 @@ Any previously activated code on the affected systems will be automatically acce
\ **IMPORTANT!**\ If the power subsystem is recycled, all of its attached managed systems will be recycled.
If it outputs \ **"Timeout waiting for prompt"**\ during the upgrade, please set the \ **"ppctimeout"**\ larger in the \ **site**\ table. After the upgrade, remeber to change it back. If run the \ **"rflash"**\ command on an AIX management node, need to make sure the value of \ **"useSSHonAIX"**\ is \ **"yes"**\ in the site table.
If it outputs \ **"Timeout waiting for prompt"**\ during the upgrade, set the \ **"ppctimeout"**\ larger in the \ **site**\ table. After the upgrade, remeber to change it back. If run the \ **"rflash"**\ command on an AIX management node, need to make sure the value of \ **"useSSHonAIX"**\ is \ **"yes"**\ in the site table.
PPC (using Direct FSP Management) specific:

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

@@ -33,7 +33,7 @@ DESCRIPTION
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.
For added security, the root guard and bpdu guard were enabled for the ports in this vlan by mkvlan and chvlan commands. However, the guards will not be disabled by this command. To disable them, you need to use the switch command line interface. Please refer to the switch command line interface manual to see how to disable the root guard and bpdu guard for a port.
For added security, the root guard and bpdu guard were enabled for the ports in this vlan by mkvlan and chvlan commands. However, the guards will not be disabled by this command. To disable them, you need to use the switch command line interface. Refer to the switch command line interface manual to see how to disable the root guard and bpdu guard for a port.
**********

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

@@ -200,7 +200,7 @@ OPTIONS
Don't try to run \ **wake**\ against the 'on' state node, it would cause the node gets to 'off' state.
For some of xCAT hardware such as NeXtScale, it may need to enable S3 before using \ **wake**\ . The following steps can be used to enable S3. Please reference pasu(1)|pasu.1 for "pasu" usage.
For some of xCAT hardware such as NeXtScale, it may need to enable S3 before using \ **wake**\ . The following steps can be used to enable S3. Reference pasu(1)|pasu.1 for "pasu" usage.
.. code-block:: perl

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

@@ -28,8 +28,8 @@ FSP/LPAR (with HMC) specific:
\ **rvitals**\ \ *noderange*\ {\ **temp | voltage | lcds | all**\ }
CEC/LPAR/Frame (using Direct FSP Management ) specific:
=======================================================
CEC/LPAR/Frame (using Direct FSP Management) specific:
======================================================
\ **rvitals**\ \ *noderange*\ {\ **rackenv | lcds | all**\ } [\ **-V**\ | \ **-**\ **-verbose**\ ]
@@ -56,6 +56,13 @@ BMC specific:
\ **rvitals**\ \ *noderange*\ {\ **temp | voltage | wattage | fanspeed | power | leds | all**\ }
OpenPOWER server specific:
==========================
\ **rvitals**\ \ *noderange*\ {\ **temp | voltage | wattage | fanspeed | power | leds | all**\ }
*******************
\ **Description**\

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

@@ -167,8 +167,8 @@ Command Protocol can be used. See man \ **xdsh**\ for more details.
xCAT ships some default configuration files
for Ethernet switches and and IB switches under
\ */opt/xcat/share/xcat/devicetype*\ directory. If you want to overwrite
any of the configuration files, please copy it to \ */var/opt/xcat/*\
directory and cutomize it.
any of the configuration files, copy them to \ */var/opt/xcat/*\
directory and cutomize.
For example, \ *base/IBSwitch/Qlogic/config*\ is the configuration
file location if devicetype is specified as IBSwitch::Qlogic.
xCAT will first search config file using \ */var/opt/xcat/*\ as the base.

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

@@ -29,9 +29,9 @@ The switchdiscover command scans the subnets and discovers all the swithches on
To view all the switches defined in the xCAT databasee use \ **lsdef -w "nodetype=switch"**\ command.
For lldp method, please make sure that lldpd package is installed and lldpd is running on the xCAT management node. lldpd comes from xcat-dep packge or you can get it from http://vincentbernat.github.io/lldpd/installation.html.
For lldp method, make sure that lldpd package is installed and lldpd is running on the xCAT management node. lldpd comes from xcat-dep packge or you can get it from http://vincentbernat.github.io/lldpd/installation.html.
For snmp method, please make sure that snmpwalk command is installed and snmp is enabled for switches. To install snmpwalk, "yum install net-snmp-utils" for redhat and sles, "apt-get install snmp" for Ubuntu.
For snmp method, make sure that snmpwalk command is installed and snmp is enabled for switches. To install snmpwalk, "yum install net-snmp-utils" for redhat and sles, "apt-get install snmp" for Ubuntu.
*******

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

@@ -234,8 +234,8 @@ running commands, are terminated (SIGTERM).
xCAT ships some default configuration files
for Ethernet switches and and IB switches under
\ */opt/xcat/share/xcat/devicetype*\ directory. If you want to overwrite
any of the configuration files, please copy it to \ */var/opt/xcat/*\
directory and cutomize it.
any of the configuration files, copy them to \ */var/opt/xcat/*\
directory and cutomize.
For example, \ *base/IBSwitch/Qlogic/config*\ is the configuration
file location if devicetype is specified as IBSwitch::Qlogic.
xCAT will first search config file using \ */var/opt/xcat/*\ as the base.

24
docs/source/guides/admin-guides/references/man3/noderange.3.rst
View File

@@ -191,28 +191,20 @@ In plain English, a node or group name is in \ **xCAT Node Name Format**\ i
from the begining there are:
\*
one or more alpha characters of any case and any number of "-" in any combination
\* one or more alpha characters of any case and any number of "-" in any combination
\*
followed by one or more numbers
\* followed by one or more numbers
\*
then optionally followed by one alpha character of any case or "-"
\* then optionally followed by one alpha character of any case or "-"
\*
followed by any combination of case mixed alphanumerics and "-"
\* followed by any combination of case mixed alphanumerics and "-"
\ **noderange**\ supports node/group names in \ *any*\ format. \ **xCAT Node Name Format**\ is

1
docs/source/guides/admin-guides/references/man5/linuximage.5.rst
View File

@@ -96,6 +96,7 @@ linuximage Attributes:
IMG_ARCH(The architecture of the osimage, such as "ppc64le","x86_64"),
IMG_NAME(The name of the osimage, such as "rhels7.3-ppc64le-netboot-compute"),
IMG_OSVER(The os release of the osimage, such as "rhels7.3","sles11.4"),
IMG_KERNELVERSION(the "kernelver" attribute of the osimage),
IMG_PROFILE(the profile of the osimage, such as "service","compute"),
IMG_PKGLIST(the "pkglist" attribute of the osimage),
IMG_PKGDIR(the "pkgdir" attribute of the osimage),

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

@@ -57,11 +57,11 @@ litefile Attributes:
tmpfs - It is the default option if you leave the options column blank. 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. Please 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. Please do not use it for one directory.
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.

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

@@ -50,7 +50,7 @@ nodelist Attributes:
\ **status**\
The current status of this node. This attribute will be set by xCAT software. Valid values: defined, booting, netbooting, booted, discovering, configuring, installing, alive, standingby, powering-off, unreachable. If blank, defined is assumed. The possible status change sequences are: For installation: defined->[discovering]->[configuring]->[standingby]->installing->booting->booted->[alive], For diskless deployment: defined->[discovering]->[configuring]->[standingby]->netbooting->booted->[alive], For booting: [alive/unreachable]->booting->[alive], For powering off: [alive]->powering-off->[unreachable], For monitoring: alive->unreachable. Discovering and configuring are for x Series discovery process. Alive and unreachable are set only when there is a monitoring plug-in start monitor the node status for xCAT. Please note that the status values will not reflect the real node status if you change the state of the node from outside of xCAT (i.e. power off the node using HMC GUI).
The current status of this node. This attribute will be set by xCAT software. Valid values: defined, booting, netbooting, booted, discovering, configuring, installing, alive, standingby, powering-off, unreachable. If blank, defined is assumed. The possible status change sequences are: For installation: defined->[discovering]->[configuring]->[standingby]->installing->booting->booted->[alive], For diskless deployment: defined->[discovering]->[configuring]->[standingby]->netbooting->booted->[alive], For booting: [alive/unreachable]->booting->[alive], For powering off: [alive]->powering-off->[unreachable], For monitoring: alive->unreachable. Discovering and configuring are for x Series discovery process. Alive and unreachable are set only when there is a monitoring plug-in start monitor the node status for xCAT. Note that the status values will not reflect the real node status if you change the state of the node from outside of xCAT (i.e. power off the node using HMC GUI).

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

@@ -274,7 +274,7 @@ site Attributes:
runbootscripts: If set to 'yes' the scripts listed in the postbootscripts
attribute in the osimage and postscripts tables will be run during
each reboot of stateful (diskful) nodes. This attribute has no
effect on stateless and statelite nodes. Please run the following
effect on stateless and statelite nodes. Run the following
command after you change the value of this attribute:
'updatenode <nodes> -P setuppostbootscripts'
@@ -309,7 +309,7 @@ site Attributes:
'1': enable basic debug mode
'2': enable expert debug mode
For the details on 'basic debug mode' and 'expert debug mode',
please refer to xCAT documentation.
refer to xCAT documentation.
--------------------
REMOTESHELL ATTRIBUTES

6
docs/source/guides/admin-guides/references/man5/switches.5.rst
View File

@@ -74,19 +74,19 @@ switches Attributes:
\ **linkports**\
The ports that connect to other switches. Currently, this column is only used by vlan configuration. The format is: "port_number:switch,port_number:switch...". Please refer to the switch table for details on how to specify the port numbers.
The ports that connect to other switches. Currently, this column is only used by vlan configuration. The format is: "port_number:switch,port_number:switch...". Refer to the switch table for details on how to specify the port numbers.
\ **sshusername**\
The remote login user name. It can be for ssh or telnet. If it is for telnet, please set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.
The remote login user name. It can be for ssh or telnet. If it is for telnet, set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.
\ **sshpassword**\
The remote login password. It can be for ssh or telnet. If it is for telnet, please set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.
The remote login password. It can be for ssh or telnet. If it is for telnet, set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.

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

@@ -197,7 +197,7 @@ vm Attributes:
\ **physlots**\
Specify the physical slots drc index that will assigned to the partition, the delimiter is ',', and the drc index must started with '0x'. For more details, please reference to manpage of 'lsvm'.
Specify the physical slots drc index that will assigned to the partition, the delimiter is ',', and the drc index must started with '0x'. For more details, reference manpage for 'lsvm'.

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

@@ -425,7 +425,7 @@ group Attributes:
\ **linkports**\ (switches.linkports)
The ports that connect to other switches. Currently, this column is only used by vlan configuration. The format is: "port_number:switch,port_number:switch...". Please refer to the switch table for details on how to specify the port numbers.
The ports that connect to other switches. Currently, this column is only used by vlan configuration. The format is: "port_number:switch,port_number:switch...". Refer to the switch table for details on how to specify the port numbers.
@@ -745,7 +745,7 @@ group Attributes:
or
The remote login password. It can be for ssh or telnet. If it is for telnet, please set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.
The remote login password. It can be for ssh or telnet. If it is for telnet, set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.
@@ -1148,7 +1148,7 @@ group Attributes:
or
The remote login user name. It can be for ssh or telnet. If it is for telnet, please set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.
The remote login user name. It can be for ssh or telnet. If it is for telnet, set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.
@@ -1226,7 +1226,7 @@ group Attributes:
\ **vmphyslots**\ (vm.physlots)
Specify the physical slots drc index that will assigned to the partition, the delimiter is ',', and the drc index must started with '0x'. For more details, please reference to manpage of 'lsvm'.
Specify the physical slots drc index that will assigned to the partition, the delimiter is ',', and the drc index must started with '0x'. For more details, reference manpage for 'lsvm'.

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