diff --git a/.mailmap b/.mailmap new file mode 100644 index 000000000..cc6d51051 --- /dev/null +++ b/.mailmap @@ -0,0 +1,69 @@ +BAI Yuan +Bruce Potter +CAO Li +CAO Meng Meng +CAO Meng Meng +CAO Meng Meng +Casandra Qiu +Casandra Qiu +CHENG Long +CHU De Gao +CHU De Gao +CHU De Gao +GAO Feng +GAO Ling +GAO Ling +GONG Jie +GONG Jie +GONG Jie +HU Wei Hua +Jarrod Johnson +Jarrod Johnson +Jarrod Johnson +Jarrod Johnson +JIN Jie Hua +JIN Jie Hua +LI Guang Cheng +LI Guang Cheng +LI Guang Cheng +LI Ting Ting +Linda O. Mellor +Linda O. Mellor +Lissa Valletta +Lissa Valletta +Mark Gurevich +Mark Gurevich +Norm Nott +Norm Nott +Patrick Lundgren +Patrick Lundgren +Patrick Lundgren +SUN Jing +SUN Jing +Victor Hu +Victor Hu +Victor Hu +WANG Hua Zhong +WANG Hua Zhong +WANG Jun Xia +WANG Xiao Peng +WANG Xiao Peng +WANG Xiao Peng +WANG Xiao Peng +WANG Xiao Peng +WU Xian +XU Bin +XU Bin +XU Qing +XU Qing +XU Wei +YANG Peng +YANG Song +YANG Song +YANG Song +YANG Song +YIN Le +YIN Le +ZHAO Er Tao +ZHAO Er Tao +ZHAO Er Tao diff --git a/README.rst b/README.rst index 2cb961dfd..1d9a9e0ca 100644 --- a/README.rst +++ b/README.rst @@ -8,7 +8,7 @@ Documentation xCAT documentation is available at: http://xcat-docs.readthedocs.io/en/latest/ -|docs_latest| |docs_2133| |docs_2132| |docs_2131| |docs_2130| |docs_212| |docs_211| +|docs_latest| |docs_2134| |docs_2133| |docs_2132| |docs_2131| |docs_2130| |docs_212| Open Source License ------------------- @@ -22,6 +22,11 @@ Developers Developers and prospective contributors are encouraged to read the `Developers Guide `_ In particular the `GitHub `_ related subsection. +.. |docs_2134| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.4 + :alt: 2.13.4 documentation status + :scale: 100% + :target: http://xcat-docs.readthedocs.io/en/2.13.4/ + .. |docs_2133| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.3 :alt: 2.13.3 documentation status :scale: 100% diff --git a/Version b/Version index 965a689ec..8bbab5627 100644 --- a/Version +++ b/Version @@ -1 +1 @@ -2.13.4 +2.13.5 diff --git a/docs/source/advanced/cluster_maintenance/compute_node/changing_hostname_ip.rst b/docs/source/advanced/cluster_maintenance/compute_node/changing_hostname_ip.rst index 544f577cd..10b7a69c1 100644 --- a/docs/source/advanced/cluster_maintenance/compute_node/changing_hostname_ip.rst +++ b/docs/source/advanced/cluster_maintenance/compute_node/changing_hostname_ip.rst @@ -25,7 +25,7 @@ Remove Old Provision Environment Change Definition ----------------- -#. Change netwoks table definitions :: +#. Change networks table definitions :: lsdef -t network -l diff --git a/docs/source/advanced/cluster_maintenance/compute_node/replace/openpower.rst b/docs/source/advanced/cluster_maintenance/compute_node/replace/openpower.rst index 6e17f9947..018de0672 100644 --- a/docs/source/advanced/cluster_maintenance/compute_node/replace/openpower.rst +++ b/docs/source/advanced/cluster_maintenance/compute_node/replace/openpower.rst @@ -1,10 +1,10 @@ -OpenPower Nodes +OpenPOWER Nodes =============== When compute nodes are physically replaced in the frame, leverage xCAT to re-discover the compute nodes. The following guide can be used for: - * IBM OpenPower S822LC for HPC + * IBM OpenPOWER S822LC for HPC #. Identify the machine(s) to be replaced: ``frame10cn02``. diff --git a/docs/source/advanced/domain_name_resolution/domain_name_resolution.rst b/docs/source/advanced/domain_name_resolution/domain_name_resolution.rst index 984bf79fe..7311f53ae 100644 --- a/docs/source/advanced/domain_name_resolution/domain_name_resolution.rst +++ b/docs/source/advanced/domain_name_resolution/domain_name_resolution.rst @@ -480,6 +480,6 @@ Sample table contents: :: Limited support for user application networks --------------------------------------------- -In some cases you may have additional user application networks in your site that are not specifically used for cluster management.If desired you can create xCAT network definitions for these networks.This not only provides a convenient way to keep track of the network details but the information can also be used to help set up name resolution for these networks on the cluster nodes.When you add a network definition that includes a **"domain"** value then that domain is automatically included the xCAT name resolution set up. This will enable the nodes to be able to resolve hostnames from the other domains. +In some cases you may have additional user application networks in your site that are not specifically used for cluster management. If desired you can create xCAT network definitions for these networks. This not only provides a convenient way to keep track of the network details but the information can also be used to help set up name resolution for these networks on the cluster nodes. When you add a network definition that includes a **"domain"** value then that domain is automatically included the xCAT name resolution set up. This will enable the nodes to be able to resolve hostnames from the other domains. For example, when you run ``makedhcp -n`` it will list all domains defined in the xCAT **"site"** definition and xCAT **"network"** definitions in the **"option domain-search"** entry of the shared-network stanza in the dhcp configuration file. This will cause dhcp to put these domains in the compute nodes' **/etc/resolv.conf** file every time it gets a dhcp lease. diff --git a/docs/source/advanced/gpu/nvidia/osimage/index.rst b/docs/source/advanced/gpu/nvidia/osimage/index.rst index 04d4af107..70a2aff30 100644 --- a/docs/source/advanced/gpu/nvidia/osimage/index.rst +++ b/docs/source/advanced/gpu/nvidia/osimage/index.rst @@ -1,7 +1,7 @@ Create osimage definitions ========================== -Generate ``osimage`` definitions to provison the compute nodes with the NVIDIA CUDA toolkit installed. +Generate ``osimage`` definitions to provision the compute nodes with the NVIDIA CUDA toolkit installed. .. toctree:: :maxdepth: 2 diff --git a/docs/source/advanced/hamn/high_available_management_node.rst b/docs/source/advanced/hamn/high_available_management_node.rst index da94390ae..ebd78cf57 100644 --- a/docs/source/advanced/hamn/high_available_management_node.rst +++ b/docs/source/advanced/hamn/high_available_management_node.rst @@ -13,7 +13,7 @@ The data synchronization is important for any high availability configuration. W * The configuration files for the services that are required by xCAT, like named, DHCP, apache, nfs, ssh, etc. * The operating systems images repository and users customization data repository, the ``/install`` directory contains these repositories in most cases. -There are a lot of ways for data synchronization, but considering the specific xCAT HAMN requirements, only several of the data synchronziation options are practical for xCAT HAMN. +There are a lot of ways for data synchronization, but considering the specific xCAT HAMN requirements, only several of the data synchronization options are practical for xCAT HAMN. **1\. Move physical disks between the two management nodes**: if we could physically move the hard disks from the failed management node to the backup management node, and bring up the backup management node, then both the operating system and xCAT data will be identical between the new management node and the failed management node. RAID1 or disk mirroring could be used to avoid the disk be a single point of failure. @@ -40,7 +40,7 @@ The configuration for the high availability applications is usually complex, it **3\. Maintenance effort** -The automatic failover brings in several high availability applications, after the initial configuration is done, additional maintenance effort will be needed. For example, taking care of the high availability applications during cluster update, the updates for the high availability applications themselves, trouble shooting any problems with the high availability applications. A simple question may be able to help you to decide: could you get technical support if some of the high availability applications run into problems? All software has bugs. +The automatic failover brings in several high availability applications, after the initial configuration is done, additional maintenance effort will be needed. For example, taking care of the high availability applications during cluster update, the updates for the high availability applications themselves, troubleshooting any problems with the high availability applications. A simple question may be able to help you to decide: could you get technical support if some of the high availability applications run into problems? All software has bugs. Configuration Options ===================== diff --git a/docs/source/advanced/hamn/setup_ha_mgmt_node_with_drbd_pacemaker_corosync.rst b/docs/source/advanced/hamn/setup_ha_mgmt_node_with_drbd_pacemaker_corosync.rst index 766580dad..91f9c6cd9 100644 --- a/docs/source/advanced/hamn/setup_ha_mgmt_node_with_drbd_pacemaker_corosync.rst +++ b/docs/source/advanced/hamn/setup_ha_mgmt_node_with_drbd_pacemaker_corosync.rst @@ -31,7 +31,7 @@ Configuration Requirements #. Since the management node needs to provide IP services through broadcast such as DHCP to the compute nodes, the primary management node and standby management node should be in the same subnet to ensure the network services will work correctly after failover. -#. Network connections between the two management nodes: there are several networks defined in the general cluster configuration strucutre, like cluster network, management network and service network; the two management nodes should be in all of these networks(if exist at all). Besides that, it is recommended, though not strictly required, to use a direct, back-to-back, Gigabit Ethernet or higher bandwidth connection for the DRBD, Pacemaker and Corosync communication between the two management nodes. If the connection is run over switches, use of redundant components and the bonding driver (in active-backup mode) is recommended. +#. Network connections between the two management nodes: there are several networks defined in the general cluster configuration structure, like cluster network, management network and service network; the two management nodes should be in all of these networks(if exist at all). Besides that, it is recommended, though not strictly required, to use a direct, back-to-back, Gigabit Ethernet or higher bandwidth connection for the DRBD, Pacemaker and Corosync communication between the two management nodes. If the connection is run over switches, use of redundant components and the bonding driver (in active-backup mode) is recommended. ``Note``: A crossover Ethernet cable is required to setup the direct, back-to-back, Ethernet connection between the two management nodes, but with most of the current hardware, a normal Ethernet cable can also work, the Ethernet adapters will internally handle the crossover bit. Hard disk for DRBD: DRBD device can be setup on a partition of the disk that the operating system runs on, but it is recommended to use a separate standalone disk or RAID/Multipath disk for DRBD configuration. @@ -63,7 +63,7 @@ You have several options to get the RPM packages for ``DRBD``, ``drbdlinks``, `` #. Compile from source code: if none of the options work for some specific applications, you will have to compile RPMs from the source code. You can compile these packages on one of the management node or on a separate build machine with the same arch and operating system with the management nodes. Here are the instructions for compiling the RPM packages from source code: -Before compiling the RPM packages, you need to install some compling tools like gcc, make, glibc, rpm-build. :: +Before compiling the RPM packages, you need to install some compiling tools like gcc, make, glibc, rpm-build. :: yum groupinstall "Development tools" yum install libxslt libxslt-devel @@ -402,13 +402,13 @@ Configure DRBD [>....................] sync'ed: 0.5% (101932/102400)M finish: 2:29:06 speed: 11,644 (11,444) K/sec - If a direct, back-to-back Gigabyte Ethernet connection is setup between the two management nodes and you are unhappy with the syncronization speed, it is possible to speed up the initial synchronization through some tunable parameters in DRBD. This setting is not permanent, and will not be retained after boot. For details, see http://www.drbd.org/users-guide-emb/s-configure-sync-rate.html. :: + If a direct, back-to-back Gigabyte Ethernet connection is setup between the two management nodes and you are unhappy with the synchronization speed, it is possible to speed up the initial synchronization through some tunable parameters in DRBD. This setting is not permanent, and will not be retained after boot. For details, see http://www.drbd.org/users-guide-emb/s-configure-sync-rate.html. :: drbdadm disk-options --resync-rate=110M xCAT #. Create file system on DRBD device and mount the file system - Even while the DRBD sync is taking place, you can go ahead and create a filesystem on the DRBD device, but it is recommended to wait for the inital full synchronization is finished before creating the file system. + Even while the DRBD sync is taking place, you can go ahead and create a filesystem on the DRBD device, but it is recommended to wait for the initial full synchronization is finished before creating the file system. After the initial full synchronization is finished, you can take the DRBD device as a normal disk partition to create file system and mount it to some directory. The DRDB device name is set in the ``/etc/drbd.d/xcat.res`` created in the previous step. In this doc, the DRBD device name is ``/dev/drbd1``. :: @@ -964,7 +964,7 @@ At this point, the HA MN Setup is complete, and customer workloads and system ad Failover ======== -There are two kinds of failover, planned failover and unplanned failover. The planned failover can be useful for updating the management nodes or any scheduled maintainance activities; the unplanned failover covers the unexpected hardware or software failures. +There are two kinds of failover, planned failover and unplanned failover. The planned failover can be useful for updating the management nodes or any scheduled maintenance activities; the unplanned failover covers the unexpected hardware or software failures. In a planned failover, you can do necessary cleanup work on the previous primary management node before failover to the previous standby management node. In a unplanned failover, the previous management node probably is not functioning at all, you can simply shutdown the system. @@ -1009,7 +1009,7 @@ To avoid this, run the following command to set the autostart for the corosync s Backup working Pacemaker configuration (Optional) ================================================= -It is a good practice to backup the working ``pacemaker`` configuration, the backup could be in both plain text format or XML format, the plain text is more easily editable and can be modified and used chunk by chunk, the xml can be used to do a full replacement restore. It will be very useful to make such a backup everytime before you make a change. +It is a good practice to backup the working ``pacemaker`` configuration, the backup could be in both plain text format or XML format, the plain text is more easily editable and can be modified and used chunk by chunk, the xml can be used to do a full replacement restore. It will be very useful to make such a backup every time before you make a change. To backup in the plain text format, run the following command: :: @@ -1182,7 +1182,7 @@ Trouble shooting and debug tips Disable HA MN ============= -For whatever reason, the user might want to disable HA MN, here is the procedur of disabling HA MN: +For whatever reason, the user might want to disable HA MN, here is the procedure of disabling HA MN: * Shut down standby management node @@ -1245,7 +1245,7 @@ Finally we commit the changes that are in xcat_cfg into the live system: :: pcs cluster push cib xcat_cfg -We then need to make sure that the ``/xCATdrbd/etc/drbdlinks.xCAT.conf`` file has the systemimager portion uncommented, and re-do the initialisation of drbdlinks as they have been done earlier in the documentation +We then need to make sure that the ``/xCATdrbd/etc/drbdlinks.xCAT.conf`` file has the systemimager portion uncommented, and re-do the initialization of drbdlinks as they have been done earlier in the documentation Appendix A ========== @@ -1428,7 +1428,7 @@ Finally we commit the changes that are in xcat_cfg into the live system: :: pcs cluster cib-push xcat_cfg -Once the changes have been commited, we can view the config, by running the command below: :: +Once the changes have been committed, we can view the config, by running the command below: :: pcs config @@ -1640,7 +1640,7 @@ Finally we commit the changes that are in xcat_cfg into the live system: :: pcs cluster cib-push xcat_cfg -Once the changes have been commited, we can view the config, by running the command below: :: +Once the changes have been committed, we can view the config, by running the command below: :: pcs config diff --git a/docs/source/advanced/hamn/setup_ha_mgmt_node_with_shared_data.rst b/docs/source/advanced/hamn/setup_ha_mgmt_node_with_shared_data.rst index 6a3e1b98a..3eff968e6 100644 --- a/docs/source/advanced/hamn/setup_ha_mgmt_node_with_shared_data.rst +++ b/docs/source/advanced/hamn/setup_ha_mgmt_node_with_shared_data.rst @@ -18,9 +18,9 @@ The nfs service on the primary management node or the primary management node it What is Shared Data ==================== -The term ``Shared Data`` means that the two management nodes use a single copy of xCAT data, no matter which management node is the primary MN, the cluster management capability is running on top of the single data copy. The acess to the data could be done through various ways like shared storage, NAS, NFS, samba etc. Based on the protocol being used, the data might be accessable only on one management node at a time or be accessable on both management nodes in parellel. If the data could only be accessed from one management node, the failover process need to take care of the data access transition; if the data could be accessed on both management nodes, the failover does not need to consider the data access transition, it usually means the failover process could be faster. +The term ``Shared Data`` means that the two management nodes use a single copy of xCAT data, no matter which management node is the primary MN, the cluster management capability is running on top of the single data copy. The access to the data could be done through various ways like shared storage, NAS, NFS, samba etc. Based on the protocol being used, the data might be accessible only on one management node at a time or be accessible on both management nodes in parallel. If the data could only be accessed from one management node, the failover process need to take care of the data access transition; if the data could be accessed on both management nodes, the failover does not need to consider the data access transition, it usually means the failover process could be faster. -``Warning``: Running database through network file system has a lot of potential problems and is not practical, however, most of the database system provides database replication feature that can be used to synronize the database between the two management nodes +``Warning``: Running database through network file system has a lot of potential problems and is not practical, however, most of the database system provides database replication feature that can be used to synchronize the database between the two management nodes Configuration Requirements ========================== @@ -248,7 +248,7 @@ Besides the files mentioned above, there may be some additional customization fi ``Note``: If the IBM HPC software stack is configured in your environment, execute additional steps required to copy additional data or configuration files for HAMN setup. -The dhcpsd.cnf should be syncronized between the primary management node and standby management node only when the DHCP configuration on the two management nodes are exactly the same. +The dhcpsd.cnf should be synchronized between the primary management node and standby management node only when the DHCP configuration on the two management nodes are exactly the same. Cluster Maintenance Considerations ================================== @@ -268,7 +268,7 @@ At this point, the HA MN Setup is complete, and customer workloads and system ad Failover ======== -There are two kinds of failover, planned failover and unplanned failover. The planned failover can be useful for updating the management nodes or any scheduled maintainance activities; the unplanned failover covers the unexpected hardware or software failures. +There are two kinds of failover, planned failover and unplanned failover. The planned failover can be useful for updating the management nodes or any scheduled maintenance activities; the unplanned failover covers the unexpected hardware or software failures. In a planned failover, you can do necessary cleanup work on the previous primary management node before failover to the previous standby management node. In a unplanned failover, the previous management node probably is not functioning at all, you can simply shutdown the system. @@ -367,7 +367,7 @@ On the new primary management node: **DNS**: run ``makedns``. Verify dns services working for node resolution. Make sure the line ``nameserver=`` is in ``/etc/resolv.conf``. - **DHCP**: if the dhcpd.leases is not syncronized between the primary management node and standby management node, run ``makedhcp -a`` to setup the DHCP leases. Verify dhcp is operational. + **DHCP**: if the dhcpd.leases is not synchronized between the primary management node and standby management node, run ``makedhcp -a`` to setup the DHCP leases. Verify dhcp is operational. **conserver**: run makeconservercf. This will recreate the ``/etc/conserver.cf`` config files for all the nodes. diff --git a/docs/source/advanced/hierarchy/appendix/appendix_b_diagnostics.rst b/docs/source/advanced/hierarchy/appendix/appendix_b_diagnostics.rst index d30fc59db..768395548 100644 --- a/docs/source/advanced/hierarchy/appendix/appendix_b_diagnostics.rst +++ b/docs/source/advanced/hierarchy/appendix/appendix_b_diagnostics.rst @@ -15,4 +15,4 @@ Appendix B: Diagnostics * **Errors running hierarchical commands such as xdsh** -- xCAT has a number of commands that run hierarchically. That is, the commands are sent from xcatd on the management node to the correct service node xcatd, which in turn processes the command and sends the results back to xcatd on the management node. If a hierarchical command such as xcatd fails with something like "Error: Permission denied for request", check ``/var/log/messages`` on the management node for errors. One error might be "Request matched no policy rule". This may mean you will need to add policy table entries for your xCAT management node and service node. -* **/install is not mounted on service node from managemen mode** -- If service node does not have ``/install`` directory mounted from management node, run ``lsdef -t site clustersite -i installloc`` and verify ``installloc="/install"`` +* **/install is not mounted on service node from management mode** -- If service node does not have ``/install`` directory mounted from management node, run ``lsdef -t site clustersite -i installloc`` and verify ``installloc="/install"`` diff --git a/docs/source/advanced/hierarchy/databases/postgres_configure.rst b/docs/source/advanced/hierarchy/databases/postgres_configure.rst index 52db88e00..039b6c001 100644 --- a/docs/source/advanced/hierarchy/databases/postgres_configure.rst +++ b/docs/source/advanced/hierarchy/databases/postgres_configure.rst @@ -33,4 +33,4 @@ Restart PostgreSQL after editing the file: :: For more information about changing the ``pg_hab.conf`` file and ``postgresql.conf`` files, see the following documentation: -`Setup the PostgreSQL Configuraion Files `_ +`Setup the PostgreSQL Configuration Files `_ diff --git a/docs/source/advanced/hierarchy/define_service_node.rst b/docs/source/advanced/hierarchy/define_service_node.rst index dba32462c..6c5b5b3ef 100644 --- a/docs/source/advanced/hierarchy/define_service_node.rst +++ b/docs/source/advanced/hierarchy/define_service_node.rst @@ -179,7 +179,7 @@ compute node is rebooted or the compute node is explicitly moved to another SN using the `snmove `_ command. To use Service Node pools, you need to architect your network such that all of -the compute nodes and service nodes in a partcular pool are on the same flat +the compute nodes and service nodes in a particular pool are on the same flat network. If you don't want the management node to respond to manage some of the compute nodes, it shouldn't be on that same flat network. The site, dhcpinterfaces attribute should be set such that the SNs' DHCP daemon diff --git a/docs/source/advanced/kit/custom/build/createkit.rst b/docs/source/advanced/kit/custom/build/createkit.rst index 4061fbef4..fbb0e6118 100644 --- a/docs/source/advanced/kit/custom/build/createkit.rst +++ b/docs/source/advanced/kit/custom/build/createkit.rst @@ -112,7 +112,7 @@ minor version can be support following format: :: **kitpackage** --- This stanza defines Kit Package (ie. RPM). There can be zero or more kitpackage stanzas. For multiple package supports, need to #. Define one kitpackage section per supported OS. or - #. Define one kitpacakge stanza which contains multiple kitrepoid lines. For the RPM packages, users need to responsible for createing an RPM spec file that can run on multiple OSes. + #. Define one kitpacakge stanza which contains multiple kitrepoid lines. For the RPM packages, users need to responsible for creating an RPM spec file that can run on multiple OSes. :: diff --git a/docs/source/advanced/kit/custom/introduction.rst b/docs/source/advanced/kit/custom/introduction.rst index 4c847687e..febb1dbde 100644 --- a/docs/source/advanced/kit/custom/introduction.rst +++ b/docs/source/advanced/kit/custom/introduction.rst @@ -49,7 +49,7 @@ Kit Framework With time, the implementation of the xCAT Software Kit support may change. -In order to process a kit successfully, the kit must be conpatiable with the level of xCAT code that was used to build the kit. The xCAT kit commands and software kits contain the framework version and compatiable supported versions. +In order to process a kit successfully, the kit must be compatible with the level of xCAT code that was used to build the kit. The xCAT kit commands and software kits contain the framework version and compatible supported versions. To view the framework version, use the ``-v | --version`` option on :doc:`addkit ` :: @@ -59,7 +59,7 @@ To view the framework version, use the ``-v | --version`` option on :doc:`addkit compatible_frameworks = 0,1,2 -If the commands in the xCAT installation is not compatiable with the Software Kit obtained, update xCAT to a more recent release. +If the commands in the xCAT installation is not compatible with the Software Kit obtained, update xCAT to a more recent release. .. [#] PCM is IBM Platform Cluster Manager diff --git a/docs/source/advanced/kit/custom/using/addkitcomp.rst b/docs/source/advanced/kit/custom/using/addkitcomp.rst index f716770b8..0c396cf4b 100644 --- a/docs/source/advanced/kit/custom/using/addkitcomp.rst +++ b/docs/source/advanced/kit/custom/using/addkitcomp.rst @@ -14,7 +14,7 @@ To check if a kitcomponent is valid for an existing OS image definition run the chkkitcomp -i -If the kit component is compatible then add the kitcomponent to the OS image defintion using the addkitcomp command. :: +If the kit component is compatible then add the kitcomponent to the OS image definition using the addkitcomp command. :: addkitcomp -a -i @@ -34,7 +34,7 @@ The contents of the kit component may be listed by using the lskitcomponent comm Adding Multiple Versions of the Same Kit Component to an OS Image Definition ````````````````````````````````````````````````````````````````````````````` -xCAT allows to have multiple versions/releases of a product software kit available in the cluster. Typically, different OS image definitions corresponding to the different versions/releases of a product software stack. However, in some instances, may need mulitple versions/releases of the same product available within a single OS image. This is only feasible if the software product supports the install of multiple versions or releases of its product within an OS image. +xCAT allows to have multiple versions/releases of a product software kit available in the cluster. Typically, different OS image definitions corresponding to the different versions/releases of a product software stack. However, in some instances, may need multiple versions/releases of the same product available within a single OS image. This is only feasible if the software product supports the install of multiple versions or releases of its product within an OS image. Currently, it is not possible to install multiple versions of a product into an OS image using xCAT commands. xCAT uses yum on RedHat and zypper on SLES to install product rpms. These package managers do not provide an interface to install different versions of the same package, and will always force an upgrade of the package. We are investigating different ways to accomplish this function for future xCAT releases. diff --git a/docs/source/advanced/kit/hpc/quickstart.rst b/docs/source/advanced/kit/hpc/quickstart.rst index d76814907..74b8d83e4 100644 --- a/docs/source/advanced/kit/hpc/quickstart.rst +++ b/docs/source/advanced/kit/hpc/quickstart.rst @@ -77,7 +77,7 @@ The following software kits will be used to install the IBM HPC software stack o The ESSL software kit has an *external dependency* to the ``libxlf`` which is provided in the XLF software kit. Since it's already added in the above step, there is no action needed here. - If CUDA toolkit is being used, ESSL has a runtime dependency on the CUDA rpms. The adminstrator needs to create the repository for the CUDA 7.5 toolkit or a runtime error will occur when provisioning the node. See the :doc:`/advanced/gpu/nvidia/repo/index` section for more details about setting up the CUDA repository on the xCAT management node. :: + If CUDA toolkit is being used, ESSL has a runtime dependency on the CUDA rpms. The administrator needs to create the repository for the CUDA 7.5 toolkit or a runtime error will occur when provisioning the node. See the :doc:`/advanced/gpu/nvidia/repo/index` section for more details about setting up the CUDA repository on the xCAT management node. :: # # Assuming that the cuda repo has been configured at: @@ -101,7 +101,7 @@ The following software kits will be used to install the IBM HPC software stack o addkitcomp -a -i rhels7.2-ppc64le-install-compute \ essl-computenode-3264rtecuda-5.4.0-0-rhels-7.2-ppc64le - If the system doesn't have GPU and the CUDA toolkit is not needed, the adminstrator should not add the following kit components that requires the CUDA packages: ``essl-loginnode-5.4.0-0-rhels-7.2-ppc64le``, ``essl-computenode-3264rte-5.4.0-0-rhels-7.2-ppc64le`` and ``essl-computenode-3264rtecuda-5.4.0-0-rhels-7.2-ppc64le``. Check the ESSL installation guide: http://www.ibm.com/support/knowledgecenter/SSFHY8_5.4.0/com.ibm.cluster.essl.v5r4.essl300.doc/am5il_xcatinstall.htm + If the system doesn't have GPU and the CUDA toolkit is not needed, the administrator should not add the following kit components that requires the CUDA packages: ``essl-loginnode-5.4.0-0-rhels-7.2-ppc64le``, ``essl-computenode-3264rte-5.4.0-0-rhels-7.2-ppc64le`` and ``essl-computenode-3264rtecuda-5.4.0-0-rhels-7.2-ppc64le``. Check the ESSL installation guide: http://www.ibm.com/support/knowledgecenter/SSFHY8_5.4.0/com.ibm.cluster.essl.v5r4.essl300.doc/am5il_xcatinstall.htm #. Add the **Parallel ESSL** kitcomponents to osimage. diff --git a/docs/source/advanced/mixed_cluster/building_stateless_images.rst b/docs/source/advanced/mixed_cluster/building_stateless_images.rst index 7d1145095..4c9f9a344 100644 --- a/docs/source/advanced/mixed_cluster/building_stateless_images.rst +++ b/docs/source/advanced/mixed_cluster/building_stateless_images.rst @@ -1,7 +1,7 @@ Building Stateless/Diskless Images ================================== -A **stateless**, or **diskless**, provisioned nodes is one where the operating system image is deployed and loaded into memory. The Operating System (OS) does not store its files directly onto persistent storage (i.e hard disk drive, shared drive, usb, etc) and so subsequent rebooting of the machine results in loss of any state changes that happened while the machine was running. +A **stateless**, or **diskless**, provisioned nodes is one where the operating system image is deployed and loaded into memory. The Operating System (OS) does not store its files directly onto persistent storage (i.e. hard disk drive, shared drive, usb, etc) and so subsequent rebooting of the machine results in loss of any state changes that happened while the machine was running. To deploy stateless compute nodes, you must first create a stateless image. The "netboot" osimages created from ``copycds`` in the **osimage** table are sample osimage definitions that can be used for deploying stateless nodes. diff --git a/docs/source/advanced/networks/infiniband/firmware_updates.rst b/docs/source/advanced/networks/infiniband/firmware_updates.rst index a963c3356..e3d5f6c59 100644 --- a/docs/source/advanced/networks/infiniband/firmware_updates.rst +++ b/docs/source/advanced/networks/infiniband/firmware_updates.rst @@ -21,7 +21,7 @@ Burn new firmware on each ibaX: :: mstflint -d 0002:01:00.0 -i b -Note: if this is a PureFlex MezzanineP adapater then you must select the correct image for each ibaX device. Note the difference in the firmware image at end of filename: _0.bin (iba0/iba2) & _1.bin (iba1/iba3) +Note: if this is a PureFlex MezzanineP adapter then you must select the correct image for each ibaX device. Note the difference in the firmware image at end of filename: _0.bin (iba0/iba2) & _1.bin (iba1/iba3) Verify download successful: :: diff --git a/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2.rst b/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2.rst index 5658f2d1b..8a3a5a75c 100644 --- a/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2.rst +++ b/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2.rst @@ -1,7 +1,7 @@ Mellanox OFED Installation Script ================================= -Mellanox provides a tested and packaged version of the OpenFabrics Enterprise Distribution (OFED) driver, named Mellanox OFED (MLNX_OFED). To assist with the installation of the MLNX_OFED driver, xCAT provids a sample postscript: ``mlnxofed_ib_install.v2``. +Mellanox provides a tested and packaged version of the OpenFabrics Enterprise Distribution (OFED) driver, named Mellanox OFED (MLNX_OFED). To assist with the installation of the MLNX_OFED driver, xCAT provides a sample postscript: ``mlnxofed_ib_install.v2``. .. toctree:: :maxdepth: 2 diff --git a/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskful.rst b/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskful.rst index 610dd6384..96f263e4a 100644 --- a/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskful.rst +++ b/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskful.rst @@ -18,7 +18,7 @@ Diskful Installation chdef -t node -o \ -p postscripts="mlnxofed_ib_install -p /install//" - **[kernel mismatch issue]** The Mellanox OFED ISO is built againt a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. :: + **[kernel mismatch issue]** The Mellanox OFED ISO is built against a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. :: chdef -t node -o \ -p postscripts="mlnxofed_ib_install -p /install// \ @@ -42,4 +42,4 @@ Diskful Installation * Verify that the Mellanox IB drivers are located at: ``/lib/modules//extra/`` - * Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter. + * Use the ``ibv_devinfo`` command to obtain information about the InfiniBand adapter. diff --git a/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskless.rst b/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskless.rst index 36af543e7..3af2cb177 100644 --- a/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskless.rst +++ b/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_diskless.rst @@ -28,7 +28,7 @@ Diskless Installation *Note: The $1 is a argument that is passed to the the postinstall script at runtime.* - **[kernel mismatch issue]** The Mellanox OFED ISO is built againt a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. :: + **[kernel mismatch issue]** The Mellanox OFED ISO is built against a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. :: /install/postscripts/mlnxofed_ib_install \ -p /install// -m --add-kernel-support -end- \ @@ -62,4 +62,4 @@ Diskless Installation * Verify that the Mellanox IB drivers are located at: ``/lib/modules//extra/`` - * Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter. + * Use the ``ibv_devinfo`` command to obtain information about the InfiniBand adapter. diff --git a/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_preparation.rst b/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_preparation.rst index 929bdf674..48e40f8a2 100644 --- a/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_preparation.rst +++ b/docs/source/advanced/networks/infiniband/mlnxofed_ib_install_v2_preparation.rst @@ -22,7 +22,7 @@ The ``mlnxofed_ib_install.v2`` is a sample script intended to assist with the in # ensure the script has execute permission chmod +x /install/postscripts/mlnxofed_ib_install -#. Familarize the options available for the xCAT ``mlnxofed_ib_install`` script. +#. Familiarize the options available for the xCAT ``mlnxofed_ib_install`` script. +---------+------------------+----------------------------------------------------------+ | Option | Required | Description | diff --git a/docs/source/advanced/networks/infiniband/mlnxofed_ib_verified_scenario_matrix.rst b/docs/source/advanced/networks/infiniband/mlnxofed_ib_verified_scenario_matrix.rst index fd9bfded6..9849d2091 100644 --- a/docs/source/advanced/networks/infiniband/mlnxofed_ib_verified_scenario_matrix.rst +++ b/docs/source/advanced/networks/infiniband/mlnxofed_ib_verified_scenario_matrix.rst @@ -1,7 +1,7 @@ MLNX_OFED Support Matrix ======================== -The following ISO images and attributs have been verified by the xCAT Team. +The following ISO images and attributes have been verified by the xCAT Team. **RedHat Enterprise Linux** diff --git a/docs/source/advanced/networks/infiniband/switch_configuration.rst b/docs/source/advanced/networks/infiniband/switch_configuration.rst index 58e50e0ad..ab6bdf5ae 100644 --- a/docs/source/advanced/networks/infiniband/switch_configuration.rst +++ b/docs/source/advanced/networks/infiniband/switch_configuration.rst @@ -66,7 +66,7 @@ Then run the following: :: Setup syslog on the Switch -------------------------- -Use the following command to consolidate the syslog to the Management Node or Service Nodes, where ip is the addess of the MN or SN as known by the switch. :: +Use the following command to consolidate the syslog to the Management Node or Service Nodes, where ip is the address of the MN or SN as known by the switch. :: rspconfig mswitch logdest= diff --git a/docs/source/advanced/networks/onie_switches/os_cumulus/install.rst b/docs/source/advanced/networks/onie_switches/os_cumulus/install.rst index 8fa31ee71..e0d132dfb 100644 --- a/docs/source/advanced/networks/onie_switches/os_cumulus/install.rst +++ b/docs/source/advanced/networks/onie_switches/os_cumulus/install.rst @@ -12,7 +12,7 @@ xCAT provides support for detecting and installing the Cumulus Linux OS into ONI The mac address of the switch management port is required for xCAT to configure the DHCP information and send over the OS to install on the switch. - **[small clusters]** If you know the mac address of the management port on the switch, create the pre-defined switch defintion providing the mac address. :: + **[small clusters]** If you know the mac address of the management port on the switch, create the pre-defined switch definition providing the mac address. :: mkdef frame01sw1 --template onieswitch arch=armv71 \ ip=192.168.1.1 mac="aa:bb:cc:dd:ee:ff" @@ -32,7 +32,7 @@ xCAT provides support for detecting and installing the Cumulus Linux OS into ONI ip=192.168.4.1 switch=coresw1 switchport=4 ... - #. Leverage ``switchdiscover`` over the DHCP range to automatically detect the MAC address and write them into the predefined swtiches above. :: + #. Leverage ``switchdiscover`` over the DHCP range to automatically detect the MAC address and write them into the predefined switches above. :: switchdiscover --range diff --git a/docs/source/advanced/networks/switchdiscover/switch_based_switch_discovery.rst b/docs/source/advanced/networks/switchdiscover/switch_based_switch_discovery.rst index d2b9df8b7..356132d7f 100644 --- a/docs/source/advanced/networks/switchdiscover/switch_based_switch_discovery.rst +++ b/docs/source/advanced/networks/switchdiscover/switch_based_switch_discovery.rst @@ -155,7 +155,7 @@ These two config files are located in the **/opt/xcat/share/xcat/scripts** direc Switch Status ~~~~~~~~~~~~~ -During the switch-based switch discovery process, there are four states displayed. User may only see **switch_configed** status on node definition if discovery process succefully finished. +During the switch-based switch discovery process, there are four states displayed. User may only see **switch_configed** status on node definition if discovery process successfully finished. **Matched** --- Discovered switch is matched to predefine switch, **otherinterfaces** attribute is updated to dhcp IP address, and mac address, **switch type** and **usercomment** also updated with vendor information for the predefined switch. diff --git a/docs/source/advanced/networks/vlan/vlan.rst b/docs/source/advanced/networks/vlan/vlan.rst index 0e3e3840c..813f2fc60 100644 --- a/docs/source/advanced/networks/vlan/vlan.rst +++ b/docs/source/advanced/networks/vlan/vlan.rst @@ -206,7 +206,7 @@ There is no need to specify -i flag for removing nodes from a vlan. Remove a VLAN ------------- -The **rmvlan** command removes the given vlan ID from the cluster. It removes the vlan id from all the swithces involved, deconfigures the nodes so that vlan adaptor (tag) will be remved, cleans up /etc/hosts, DNS and database tables for the given vlan. +The **rmvlan** command removes the given vlan ID from the cluster. It removes the vlan id from all the switches involved, deconfigures the nodes so that vlan adaptor (tag) will be removed, cleans up /etc/hosts, DNS and database tables for the given vlan. For example: :: @@ -215,7 +215,7 @@ For example: :: VLAN Security ------------- -To make the vlan more secure, the root guard and the bpdu guard are enabled for each ports within the vlan by **mkvlan** and **chvlan** commands. This way it guards the topology changes on the switch by the hackers who hack the STP. However, when the vlan is removed by the **rmvlan** and the **chvlan (-d)** commands, the root guard and the bpdu guard are not disabled because the code cannot tell if the guards were enabled by the admin or not. If you want to remove the gurads after the vlan is removed, you need to use the switch command line interface to do so. Refer to the documents for the switch command line interfaces for details. +To make the vlan more secure, the root guard and the bpdu guard are enabled for each ports within the vlan by **mkvlan** and **chvlan** commands. This way it guards the topology changes on the switch by the hackers who hack the STP. However, when the vlan is removed by the **rmvlan** and the **chvlan (-d)** commands, the root guard and the bpdu guard are not disabled because the code cannot tell if the guards were enabled by the admin or not. If you want to remove the guards after the vlan is removed, you need to use the switch command line interface to do so. Refer to the documents for the switch command line interfaces for details. Limitation ---------- diff --git a/docs/source/advanced/probe/osdeploy.rst b/docs/source/advanced/probe/osdeploy.rst index 546d33198..c9a36f2f1 100644 --- a/docs/source/advanced/probe/osdeploy.rst +++ b/docs/source/advanced/probe/osdeploy.rst @@ -76,7 +76,7 @@ When all the nodes complete provisioning, the probe will exit and display output All nodes provisioned successfully [ OK ] -If there is something wrong when provisioning, this probe will exit when timeout is reachedd or ``Ctrl+C`` is pressed by user. The maximum time can be set by using ``-t`` as below(default 30 minutes) :: +If there is something wrong when provisioning, this probe will exit when timeout is reached or ``Ctrl+C`` is pressed by user. The maximum time can be set by using ``-t`` as below(default 30 minutes) :: xcatprobe osdeploy -n cn1 -t 30 diff --git a/docs/source/advanced/raid/hardware_raid.rst b/docs/source/advanced/raid/hardware_raid.rst index d6e0f3c8e..915f2b241 100644 --- a/docs/source/advanced/raid/hardware_raid.rst +++ b/docs/source/advanced/raid/hardware_raid.rst @@ -18,7 +18,7 @@ Following sections show how to use ``diskdiscover`` and ``configraid``, we assum Discovering disk devices ------------------------ -Command ``diskdiscover`` scans disk devices, it can get the overview of disks and RAID arrays information from compute node; The outputs contain useful information for ``configraid`` to configure RAID arrays, user can get ``pci_id``, ``pci_slot_name``, ``disk names``, ``RAID arrays`` and other informations from the outputs. It should be ran in xcat genesis system. It can be executed without input parameter or with pci_id, pci_id includes PCI vendor and device ID. For example, power8 SAS adapter pci_id is ``1014:034a``, ``1014`` is vendor info, ``034a`` is PCI-E IPR SAS Adapter, more info about pci_id refer to ``http://pci-ids.ucw.cz/read/PC/1014/``. +Command ``diskdiscover`` scans disk devices, it can get the overview of disks and RAID arrays information from compute node; The outputs contain useful information for ``configraid`` to configure RAID arrays, user can get ``pci_id``, ``pci_slot_name``, ``disk names``, ``RAID arrays`` and other information from the outputs. It should be ran in xcat genesis system. It can be executed without input parameter or with pci_id, pci_id includes PCI vendor and device ID. For example, power8 SAS adapter pci_id is ``1014:034a``, ``1014`` is vendor info, ``034a`` is PCI-E IPR SAS Adapter, more info about pci_id refer to ``http://pci-ids.ucw.cz/read/PC/1014/``. Here are steps to use ``diskdiscover``: diff --git a/docs/source/advanced/restapi/restapi_resource/restapi_reference.rst b/docs/source/advanced/restapi/restapi_resource/restapi_reference.rst index 1953a18ba..d2cf1f937 100644 --- a/docs/source/advanced/restapi/restapi_resource/restapi_reference.rst +++ b/docs/source/advanced/restapi/restapi_resource/restapi_reference.rst @@ -15,7 +15,7 @@ POST - Create a token. **Example:** -Aquire a token for user 'root'. :: +Acquire a token for user 'root'. :: #curl -X POST -k 'https://127.0.0.1/xcatws/tokens?userName=root&userPW=cluster&pretty=1' -H Content-Type:application/json --data '{"userName":"root","userPW":"cluster"}' @@ -62,8 +62,8 @@ Get all the node names from xCAT database. :: [URI:/nodes/{noderange}] - The node resource -------------------------------------------- -GET - Get all the attibutes for the node {noderange}. -````````````````````````````````````````````````````` +GET - Get all the attributes for the node {noderange}. +`````````````````````````````````````````````````````` The keyword ALLRESOURCES can be used as {noderange} which means to get node attributes for all the nodes. @@ -75,7 +75,7 @@ Refer to the man page: :doc:`lsdef ` @@ -101,7 +101,7 @@ Refer to the man page: :doc:`chdef ` @@ -597,8 +597,8 @@ Get all the vitails attributes for the node1. :: [URI:/nodes/{noderange}/vitals/{temp|voltage|wattage|fanspeed|power|leds...}] - The specific vital attributes for the node {noderange} -------------------------------------------------------------------------------------------------------------------------------------- -GET - Get the specific vitals attibutes. -```````````````````````````````````````` +GET - Get the specific vitals attributes. +````````````````````````````````````````` Refer to the man page: :doc:`rvitals ` @@ -628,8 +628,8 @@ Get the 'fanspeed' vitals attribute. :: [URI:/nodes/{noderange}/inventory] - The inventory attributes for the node {noderange} -------------------------------------------------------------------------------------- -GET - Get all the inventory attibutes. -`````````````````````````````````````` +GET - Get all the inventory attributes. +``````````````````````````````````````` Refer to the man page: :doc:`rinv ` @@ -659,8 +659,8 @@ Get all the inventory attributes for node1. :: [URI:/nodes/{noderange}/inventory/{pci|model...}] - The specific inventory attributes for the node {noderange} -------------------------------------------------------------------------------------------------------------- -GET - Get the specific inventory attibutes. -``````````````````````````````````````````` +GET - Get the specific inventory attributes. +```````````````````````````````````````````` Refer to the man page: :doc:`rinv ` @@ -714,7 +714,7 @@ Refer to the man page: :doc:`reventlog ` **Returns:** -* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}. +* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}. **Example:** @@ -947,7 +947,7 @@ Refer to the man page: :doc:`chvm ` **Returns:** -* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}. +* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}. **Example1:** @@ -982,7 +982,7 @@ Refer to the man page: :doc:`mkvm ` **Returns:** -* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}. +* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}. **Example:** @@ -1003,7 +1003,7 @@ Refer to the man page: :doc:`rmvm ` **Returns:** -* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}. +* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}. **Example:** @@ -1112,7 +1112,7 @@ Refer to the man page: :doc:`copycds ` @@ -1173,7 +1173,7 @@ Refer to the man page: :doc:`chdef ` **Returns:** -* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}. +* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}. **Example1:** @@ -1284,7 +1284,7 @@ Refer to the man page: :doc:`rmimage ` @@ -1385,7 +1385,7 @@ Refer to the man page: :doc:`chdef ` @@ -1648,7 +1648,7 @@ Refer to the man page: :doc:`lsdef ` @@ -1668,7 +1668,7 @@ Refer to the man page: :doc:`chdef /xcat-core.git (fetch) diff --git a/docs/source/developers/github/pull_request.rst b/docs/source/developers/github/pull_request.rst index b5273cb26..80593db5e 100644 --- a/docs/source/developers/github/pull_request.rst +++ b/docs/source/developers/github/pull_request.rst @@ -65,7 +65,7 @@ During the reviewing of your pull request, another pull request may be merged wh $ git push origin -f -If all the conflicts are resolved, the pull request should automaically turn green again and is able to be merged automatically. +If all the conflicts are resolved, the pull request should automatically turn green again and is able to be merged automatically. Reviewing Pull Requests as a Maintainer --------------------------------------- diff --git a/docs/source/developers/guides/code/builds.rst b/docs/source/developers/guides/code/builds.rst index 7afb55b1b..28aba3d02 100644 --- a/docs/source/developers/guides/code/builds.rst +++ b/docs/source/developers/guides/code/builds.rst @@ -37,7 +37,7 @@ The following steps will help configure ``pod2rst`` and be able to generate the make make install - * **[as non-root]** Extrat and build the Perl module using PREFIX to specify a directory that you have write permission :: + * **[as non-root]** Extract and build the Perl module using PREFIX to specify a directory that you have write permission :: mkdir ~/perllib perl Makefile.PL PREFIX=~/perllib diff --git a/docs/source/developers/guides/docs/doc_guidelines.rst b/docs/source/developers/guides/docs/doc_guidelines.rst index 0a245fe01..4e13e7b1c 100644 --- a/docs/source/developers/guides/docs/doc_guidelines.rst +++ b/docs/source/developers/guides/docs/doc_guidelines.rst @@ -65,7 +65,7 @@ Enumerated List Include another file -------------------- -To add contents of a document file inside another file, use ``.. include::``. This is usefull when a common information needs to be displayed in multiple files, whithout the use of a hyperlink. +To add contents of a document file inside another file, use ``.. include::``. This is useful when a common information needs to be displayed in multiple files, without the use of a hyperlink. :: .. include:: config_common.rst @@ -76,14 +76,14 @@ To add contents of a document file inside another file, use ``.. include::``. Th Index file ---------- -Index.rst files contain the ``.. toctree::`` tag. Files listed under that tag will have links to them displayed in the left side navigation area. If a documentation file does not wish to be accessbile from the navigation area, do not list it under the ``.. toctree::``. +Index.rst files contain the ``.. toctree::`` tag. Files listed under that tag will have links to them displayed in the left side navigation area. If a documentation file does not wish to be accessible from the navigation area, do not list it under the ``.. toctree::``. ``Note:`` If a file is not listed under the ``.. toctree::`` it might generate a warning during the documentation build ``WARNING: document isn't included in any toctree``. To eliminate such warning, add the file to the ``exclude_patterns`` list in the ``docs/source/conf.py`` file. However, do not add a file to the ``exclude_patterns`` list if it contains a customized link target, such as ``.. _my_link_taget:``. This link target will not be visible to other files and a ``WARNING: undefined label:`` will be displayed during the documentation build. Hyperlinks -> Internal Links -> External Links ---------------------------------------------- -Add links to refer other web page is a very common way in writting document, it's very helpful to reduce the doc duplication and make docs easy to understand. Following are several ways to add a link in the xCAT documentation. +Add links to refer other web page is a very common way in writing document, it's very helpful to reduce the doc duplication and make docs easy to understand. Following are several ways to add a link in the xCAT documentation. * **Add an Internal Link to ``Customized Link Target``** diff --git a/docs/source/guides/admin-guides/basic_concepts/xcat_object/node.rst b/docs/source/guides/admin-guides/basic_concepts/xcat_object/node.rst index b8928ff7e..c94c576a2 100644 --- a/docs/source/guides/admin-guides/basic_concepts/xcat_object/node.rst +++ b/docs/source/guides/admin-guides/basic_concepts/xcat_object/node.rst @@ -6,7 +6,7 @@ Description The definition of physical units in the cluster, such as lpar, virtual machine, frame, cec, hmc, switch. -Key Attrubutes +Key Attributes -------------- * os: @@ -16,7 +16,7 @@ Key Attrubutes The hardware architecture of this node. Valid values: x86_64, ppc64, x86, ia64. * groups: - Usually, there are a set of nodes with some attributes in common, xCAT admin can define a node group containing these nodes, so that the management task can be issued against the group instead of individual nodes. A node can be a memeber of different groups, so the value of this attributes is a comma-delimited list of groups. At least one group is required to create a node. The new created group names should not be prefixed with "__" as this token has been preserverd as the internal group name. + Usually, there are a set of nodes with some attributes in common, xCAT admin can define a node group containing these nodes, so that the management task can be issued against the group instead of individual nodes. A node can be a member of different groups, so the value of this attributes is a comma-delimited list of groups. At least one group is required to create a node. The new created group names should not be prefixed with "__" as this token has been preserved as the internal group name. * mgt: The method to do general hardware management of the node. This attribute can be determined by the machine type of the node. Valid values: ipmi, blade, hmc, ivm, fsp, bpa, kvm, esx, rhevm. diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/acc_initrd_rootimg_gen.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/acc_initrd_rootimg_gen.rst index 273c6c13c..9cc18ec36 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/acc_initrd_rootimg_gen.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/acc_initrd_rootimg_gen.rst @@ -1,14 +1,14 @@ Accelerating the diskless initrd and rootimg generating ======================================================== -Generating diskless initrd with ``genimage`` and compressed rootimg with ``packimage`` and ``liteimg`` is a time-comsuming process, it can be accelerated by enabling paralell compression tool ``pigz`` on the management node with multiple processors and cores. See :ref:`Appendix ` for an example on ``packimage`` performance optimized with ``pigz`` enabled. +Generating diskless initrd with ``genimage`` and compressed rootimg with ``packimage`` and ``liteimg`` is a time-consuming process, it can be accelerated by enabling parallel compression tool ``pigz`` on the management node with multiple processors and cores. See :ref:`Appendix ` for an example on ``packimage`` performance optimized with ``pigz`` enabled. Enabling the ``pigz`` for diskless initrd and rootimg generating ---------------------------------------------------------------- -The paralell compression tool ``pigz`` can be enabled by installing ``pigz`` package on the management server or diskless rootimg. Depending on the method of generating the initrd and compressed rootimg, the steps differ in different Linux distributions. +The parallel compression tool ``pigz`` can be enabled by installing ``pigz`` package on the management server or diskless rootimg. Depending on the method of generating the initrd and compressed rootimg, the steps differ in different Linux distributions. * **[RHEL]** @@ -24,7 +24,7 @@ The paralell compression tool ``pigz`` can be enabled by installing ``pigz`` pac ``pigz`` should be installed in the diskless rootimg. Download ``pigz`` package from https://dl.fedoraproject.org/pub/epel/ , then customize the diskless osimage to install ``pigz`` as the additional packages, see :doc:`Install Additional Other Packages` for more details. - 2) Enabeling the ``pigz`` in ``packimage`` + 2) Enabling the ``pigz`` in ``packimage`` ``pigz`` should be installed on the management server. Download ``pigz`` package from https://dl.fedoraproject.org/pub/epel/ , then install the ``pigz`` with ``yum`` or ``rpm``. diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/additionalpkg/nonubuntu_os_other_pkg.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/additionalpkg/nonubuntu_os_other_pkg.rst index e6cc403e6..99d57a980 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/additionalpkg/nonubuntu_os_other_pkg.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/additionalpkg/nonubuntu_os_other_pkg.rst @@ -70,7 +70,7 @@ These are described in more details in the following sections. RPM Names ''''''''' -A simple otherpkgs.pkglist file just contains the the name of the rpm file without the version numbers. +A simple otherpkgs.pkglist file just contains the name of the rpm file without the version numbers. For example, if you put the following three rpms under **/install/post/otherpkgs///** directory, :: diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/additionalpkg/nonubuntu_os_pkg.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/additionalpkg/nonubuntu_os_pkg.rst index 77651f270..dcf8c350b 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/additionalpkg/nonubuntu_os_pkg.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/additionalpkg/nonubuntu_os_pkg.rst @@ -51,7 +51,7 @@ These are described in more details in the following sections. RPM Names '''''''''' -A simple .pkglist file just contains the the name of the rpm file without the version numbers. +A simple .pkglist file just contains the name of the rpm file without the version numbers. For example :: diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_second_adapter.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_second_adapter.rst index 492361fc5..ca1da9738 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_second_adapter.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_second_adapter.rst @@ -1,7 +1,7 @@ Configure Additional Network Interfaces - confignics ==================================================== -The **nics** table and the **confignics** postscript can be used to automatically configure additional network interfaces (mutltiple ethernets adapters, InfiniBand, etc) on the nodes as they are being deployed. +The **nics** table and the **confignics** postscript can be used to automatically configure additional network interfaces (multiple ethernets adapters, InfiniBand, etc) on the nodes as they are being deployed. The way the confignics postscript decides what IP address to give the secondary adapter is by checking the nics table, in which the nic configuration information is stored. @@ -78,7 +78,7 @@ By default, confignics does not configure the install nic. if need, using flag " chdef cn1 -p prostscripts="confignics -s" -Option "-s" writes the install nic's information into configuration file for persistance. All install nic's data defined in nics table will be written also. +Option "-s" writes the install nic's information into configuration file for persistence. All install nic's data defined in nics table will be written also. Add network object into the networks table diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/deploy_os.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/deploy_os.rst index bd7567600..4a358b41e 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/deploy_os.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/deploy_os.rst @@ -11,7 +11,7 @@ There are more attributes of nodeset used for some specific purpose or specific * **runcmd**: This instructs the node to boot to the xCAT nbfs environment and proceed to configure BMC for basic remote access. This causes the IP, netmask, gateway, username, and password to be programmed according to the configuration table. * **shell**: This instructs the node to boot to the xCAT genesis environment, and present a shell prompt on console. The node will also be able to be sshed into and have utilities such as wget, tftp, scp, nfs, and cifs. It will have storage drivers available for many common systems. -Choose such additional attribute of nodeset according to your requirement, if want to get more informantion about nodeset, refer to nodeset's man page. +Choose such additional attribute of nodeset according to your requirement, if want to get more information about nodeset, refer to nodeset's man page. Start the OS Deployment ======================= diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/enable_kdump.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/enable_kdump.rst index 85973cc1c..a6c0765d2 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/enable_kdump.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/enable_kdump.rst @@ -38,7 +38,7 @@ In above example, pkglist file is /opt/xcat/share/xcat/netboot/rh/compute.rhels7 Setup pkglist ------------- -Before setting up kdump,the approprite rpms should be added to the pkglist file.Here is the rpm packages list which needs to be added to pkglist file for kdump for different OS. +Before setting up kdump, the appropriate rpms should be added to the pkglist file.Here is the rpm packages list which needs to be added to pkglist file for kdump for different OS. * **[RHEL]** :: diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/generate_img.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/generate_img.rst index a5dcf5382..e5886603d 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/generate_img.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/generate_img.rst @@ -1,7 +1,7 @@ Generate Diskless Image ======================= -The ``copycds`` command copies the contents of the Linux media to ``/install//`` so that it will be available for installing nodes or creating diskless images. After executing ``copycds``, there are serveral ``osimage`` definitions created by default. Run ``tabdump osimage`` to view these images: :: +The ``copycds`` command copies the contents of the Linux media to ``/install//`` so that it will be available for installing nodes or creating diskless images. After executing ``copycds``, there are several ``osimage`` definitions created by default. Run ``tabdump osimage`` to view these images: :: tabdump osimage @@ -18,7 +18,7 @@ The ``netboot-compute`` is the default **diskless** osimage created rhels7.1 ppc Before packing the diskless image, you have the opportunity to change any files in the image by changing to the ``rootimgdir`` and making modifications. (e.g. ``/install/netboot/rhels7.1/ppc64le/compute/rootimg``). -However it's recommended that all changes to the image are made via post install scripts so that it's easily repeatable.Although, instead, we recommend that you make all changes to the image via your postinstall script, so that it is repeatable. Refer to :doc:`/guides/admin-guides/manage_clusters/ppc64le/diskless/customize_image/pre_post_script` for more details. +However it's recommended that all changes to the image are made via post install scripts so that it's easily repeatable. Although, instead, we recommend that you make all changes to the image via your postinstall script, so that it is repeatable. Refer to :doc:`/guides/admin-guides/manage_clusters/ppc64le/diskless/customize_image/pre_post_script` for more details. Pack Diskless Image @@ -102,7 +102,7 @@ Skip this section if you want to use the image as is. 1, The use can modify the image to fit his/her own need. The following can be modified. -* Modify .pkglist file to add or remove packges that are from the os distro +* Modify .pkglist file to add or remove packages that are from the os distro * Modify .otherpkgs.pkglist to add or remove packages from other sources. Refer to ``Using_Updatenode`` for details diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/prepostscripts/postinstall_script.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/prepostscripts/postinstall_script.rst index f212c8691..d3066b65c 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/prepostscripts/postinstall_script.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/prepostscripts/postinstall_script.rst @@ -40,7 +40,7 @@ The ``postinstall`` scripts are executed in step b). Do ``postinstall`` scripts execute in chroot mode under ``rootimgdir`` directory? ````````````````````````````````````````````````````````````````````````````````` -No. Unlike postscripts and postbootscripts, the ``postinstall`` scripts are run in non-chroot environment, directly on the management node. In the postinstall scripts, all the paths of the directories and files are based on ``/`` of the managememnt node. To reference inside the ``rootimgdir``, use the ``$IMG_ROOTIMGDIR`` environment variable, exported by ``genimage``. +No. Unlike postscripts and postbootscripts, the ``postinstall`` scripts are run in non-chroot environment, directly on the management node. In the postinstall scripts, all the paths of the directories and files are based on ``/`` of the management node. To reference inside the ``rootimgdir``, use the ``$IMG_ROOTIMGDIR`` environment variable, exported by ``genimage``. What are some of the environment variables available to my customized ``postinstall`` scripts? `````````````````````````````````````````````````````````````````````````````````````````````` diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/raid_cfg.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/raid_cfg.rst index 0acea9a4e..752f38412 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/raid_cfg.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/raid_cfg.rst @@ -185,7 +185,7 @@ Here is the RAID1 partitioning section in service.raid1.sles11.tmpl: :: The samples above created one 24MB PReP partition on each disk, one 2GB mirrored swap partition and one mirrored ``/`` partition uses all the disk space. If you want to use different partitioning scheme in your cluster, modify this RAID1 section in the autoyast template file accordingly. -Since the PReP partition can not be mirrored between the two disks, some additional postinstall commands should be run to make the second disk bootable, here the the commands needed to make the second disk bootable: :: +Since the PReP partition can not be mirrored between the two disks, some additional postinstall commands should be run to make the second disk bootable, here the commands needed to make the second disk bootable: :: # Set the second disk to be bootable for RAID1 setup parted -s /dev/sdb mkfs 1 fat16 @@ -230,7 +230,7 @@ The command mdadm can query the detailed configuration for the RAID partitions: Disk Replacement Procedure -------------------------- -If any one disk fails in the RAID1 arrary, do not panic. Follow the procedure listed below to replace the failed disk and you will be fine. +If any one disk fails in the RAID1 array, do not panic. Follow the procedure listed below to replace the failed disk and you will be fine. Faulty disks should appear marked with an (F) if you look at ``/proc/mdstat``: :: @@ -250,7 +250,7 @@ Faulty disks should appear marked with an (F) if you look at ``/proc/mdstat``: : We can see that the first disk is broken because all the RAID partitions on this disk are marked as (F). -Remove the failed disk from RAID arrary +Remove the failed disk from RAID array --------------------------------------- ``mdadm`` is the command that can be used to query and manage the RAID arrays on Linux. To remove the failed disk from RAID array, use the command: :: diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_overview.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_overview.rst index 4862d4ed8..d0d18af6f 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_overview.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_overview.rst @@ -3,7 +3,7 @@ Overview Synchronizing (sync) files to the nodes is a feature of xCAT used to distribute specific files from the management node to the new-deploying or deployed nodes. -This function is supported for diskful or RAMdisk-based diskless nodes.Generally, the specific files are usually the system configuration files for the nodes in the **/etc/directory**, like **/etc/hosts**, **/etc/resolve.conf**; it also could be the application programs configuration files for the nodes. The advantages of this function are: it can parallel sync files to the nodes or nodegroup for the installed nodes; it can automatically sync files to the newly-installing node after the installation. Additionally, this feature also supports the flexible format to define the synced files in a configuration file, called **'synclist'**. +This function is supported for diskful or RAMdisk-based diskless nodes. Generally, the specific files are usually the system configuration files for the nodes in the **/etc/directory**, like **/etc/hosts**, **/etc/resolve.conf**; it also could be the application programs configuration files for the nodes. The advantages of this function are: it can parallel sync files to the nodes or nodegroup for the installed nodes; it can automatically sync files to the newly-installing node after the installation. Additionally, this feature also supports the flexible format to define the synced files in a configuration file, called **'synclist'**. The synclist file can be a common one for a group of nodes using the same profile or osimage, or can be the special one for a particular node. Since the location of the synclist file will be used to find the synclist file, the common synclist should be put in a given location for Linux nodes or specified by the osimage. @@ -17,7 +17,7 @@ For a new-installing nodes, the Syncing File action will be triggered when perfo The postscript **'syncfiles'** is located in the **/install/postscripts/**. When running, it sends a message to the xcatd on the management node or service node, then the xcatd figures out the corresponding synclist file for the node and calls the ``xdcp`` command to sync files in the synclist to the node. -**If installing nodes in a hierarchical configuration, you must sync the Service Nodes first to make sure they are updated. The compute nodes will be sync'd from their service nodes.You can use the** ``updatenode -f`` **command to sync all the service nodes for range of compute nodes provided.** +**If installing nodes in a hierarchical configuration, you must sync the Service Nodes first to make sure they are updated. The compute nodes will be sync'd from their service nodes. You can use the** ``updatenode -f`` **command to sync all the service nodes for range of compute nodes provided.** For an installed nodes, the Syncing File action happens when performing the ``updatenode -F`` or ``xdcp -F synclist`` command to update a nodes. If performing the ``updatenode -F``, it figures out the location of the synclist files for all the nodes and classify the nodes which using same synclist file and then calls the ``xdcp -F synclist`` to sync files to the nodes. diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_synclist_file.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_synclist_file.rst index 6ce471eb3..9af8e913f 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_synclist_file.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_synclist_file.rst @@ -97,7 +97,7 @@ Note: From xCAT 2.9.2 on AIX and from xCAT 2.12 on Linux, xCAT support a new for file -> (noderange for permitted nodes) file -The noderange would have several format. Following examples show that /etc/hosts file is synced to the nodes which is specifed before the file name :: +The noderange would have several format. Following examples show that /etc/hosts file is synced to the nodes which is specified before the file name :: /etc/hosts -> (node1,node2) /etc/hosts # The /etc/hosts file is synced to node1 and node2 /etc/hosts -> (node1-node4) /etc/hosts # The /etc/hosts file is synced to node1,node2,node3 and node4 diff --git a/docs/source/guides/admin-guides/manage_clusters/common/deployment/trim_diskless_rootimg.rst b/docs/source/guides/admin-guides/manage_clusters/common/deployment/trim_diskless_rootimg.rst index 198ac04e8..e417ca402 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/deployment/trim_diskless_rootimg.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/deployment/trim_diskless_rootimg.rst @@ -51,7 +51,7 @@ The content above presents some syntax supported in exlist file: +./usr/share/locale/C* - It is useful to include files following an exclude entry to qiuckly remove a larger set of files using a wildcard and then adding back the few necessary files using the + sign. In the above example, all the files and sub-directories matching the pattern ``/usr/share/locale/C*`` will be included in the ``rootimg.gz`` file. + It is useful to include files following an exclude entry to quickly remove a larger set of files using a wildcard and then adding back the few necessary files using the + sign. In the above example, all the files and sub-directories matching the pattern ``/usr/share/locale/C*`` will be included in the ``rootimg.gz`` file. Customize the ``exlist`` file and the osimage definition @@ -77,4 +77,4 @@ If you want to customize the osimage ``sles12.1-ppc64le-netboot-compute`` with y .. [1] The ``exlist`` file entry should not end with a slash ``/``, For example, this entry will never match anything: ``./usr/lib/perl[0-9]/[0-9.]*/ppc64le-linux-thread-multi/Encode/``. -.. [2] Pattern match test applies to the whole file name,starting from one of the start points specified in the ``exlist`` file entry. The regex syntax should comply with the regex syntax of system command ``find -path``, refer to its doc for details. +.. [2] Pattern match test applies to the whole file name, starting from one of the start points specified in the ``exlist`` file entry. The regex syntax should comply with the regex syntax of system command ``find -path``, refer to its doc for details. diff --git a/docs/source/guides/admin-guides/manage_clusters/common/kvm/manage_vm.rst b/docs/source/guides/admin-guides/manage_clusters/common/kvm/manage_vm.rst index cc7a1fc49..f383e065d 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/kvm/manage_vm.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/kvm/manage_vm.rst @@ -2,7 +2,7 @@ Manage Virtual Machine (VM) ============================ -Now the MowerKVM hypervisor "kvmhost1" is ready, this section introduces the VM management in xCAT, including examples on how to create,remove and clone VMs. +Now the MowerKVM hypervisor "kvmhost1" is ready, this section introduces the VM management in xCAT, including examples on how to create, remove and clone VMs. Create Virtual Machine ---------------------- @@ -117,7 +117,7 @@ Now a VM "vm1" is created, it can be provisioned like any other nodes in xCAT. T rpower vm1 on -If "vm1" is powered on successfully, the VM status can be obtained by running the following command on management node :: +If "vm1" is powered on successfully, the VM status can be obtained by running the following command on management node :: rpower vm1 status diff --git a/docs/source/guides/admin-guides/manage_clusters/common/updatenode.rst b/docs/source/guides/admin-guides/manage_clusters/common/updatenode.rst index 67444a2cd..5a505a57b 100644 --- a/docs/source/guides/admin-guides/manage_clusters/common/updatenode.rst +++ b/docs/source/guides/admin-guides/manage_clusters/common/updatenode.rst @@ -134,6 +134,6 @@ where is a comma separated postscript like ospkgs,otherpkgs etc. * wget is used in xcatdsklspost/xcataixpost to get all the postscripts from the to the node. You can check /tmp/wget.log file on the node to see if wget was successful or not. You need to make sure the /xcatpost directory has enough space to hold the postscripts. * A file called /xcatpost/mypostscript (Linux) is created on the node which contains the environmental variables and scripts to be run. Make sure this file exists and it contains correct info. You can also run this file on the node manually to debug. * For ospkgs/otherpkgs, if /install is not mounted on the , it will download all the rpms from the 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 every time a rpm is added or removed. Otherwise, the rpm command will be used, in this case, make sure all the necessary depended rpms are copied in the same source directory. + * For ospkgs/otherpkgs, If zypper or yum is installed on the node, it will be used the command to install the rpms. Make sure to run createrepo on the source directory on the 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. diff --git a/docs/source/guides/admin-guides/manage_clusters/ppc64le/configure/networks.rst b/docs/source/guides/admin-guides/manage_clusters/ppc64le/configure/networks.rst index 3bacd82b5..7d10ecd29 100644 --- a/docs/source/guides/admin-guides/manage_clusters/ppc64le/configure/networks.rst +++ b/docs/source/guides/admin-guides/manage_clusters/ppc64le/configure/networks.rst @@ -45,6 +45,10 @@ Configure DHCP to listen on different network interfaces [**Optional**] To set "eth1" and "eth3" on the management node and "bond0" on all nodes in the nodegroup="service", set ``dhcpinterfaces`` using: :: + chdef -t site dhcpinterfaces="eth1,eth3;service|bond0" + + or, to explicitly identify the management node with hostname ``xcatmn``: :: + chdef -t site dhcpinterfaces="xcatmn|eth1,eth3;service|bond0" **noboot** diff --git a/docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/mtms/index.rst b/docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/mtms/index.rst index fde5e5254..c4c998c9e 100644 --- a/docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/mtms/index.rst +++ b/docs/source/guides/admin-guides/manage_clusters/ppc64le/discovery/mtms/index.rst @@ -3,12 +3,12 @@ MTMS-based Discovery MTMS stands for **M**\ achine **T**\ ype/\ **M**\ odel and **S**\ erial. This is one way to uniquely identify each physical server. -MTMS-based hardware discovery assumes the administator has the model type and serial number information for the physical servers and a plan for mapping the servers to intended hostname/IP addresses. +MTMS-based hardware discovery assumes the administrator has the model type and serial number information for the physical servers and a plan for mapping the servers to intended hostname/IP addresses. **Overview** #. Automatically search and collect MTMS information from the servers - #. Write **discovered-bmc-nodes** to xCAT (recommened to set different BMC IP address) + #. Write **discovered-bmc-nodes** to xCAT (recommended to set different BMC IP address) #. Create **predefined-compute-nodes** to xCAT providing additional properties #. Power on the nodes which triggers xCAT hardware discovery engine diff --git a/docs/source/guides/admin-guides/manage_clusters/ppc64le/index.rst b/docs/source/guides/admin-guides/manage_clusters/ppc64le/index.rst index 5923a32a5..9399c0405 100644 --- a/docs/source/guides/admin-guides/manage_clusters/ppc64le/index.rst +++ b/docs/source/guides/admin-guides/manage_clusters/ppc64le/index.rst @@ -1,11 +1,11 @@ -IBM Power LE / OpenPOWER +IBM POWER LE / OpenPOWER ========================= -Most of the content is general information for xCAT, the focus and examples are for management of IBM OpenPower servers. +Most of the content is general information for xCAT, the focus and examples are for management of IBM OpenPOWER servers. -IBM OpenPower Servers - * based on Power8 Processor Technology is IPMI managed - * based on Power9 Processor Technology is OpenBmc managed [**Alpha**] +IBM OpenPOWER Servers + * based on POWER8 Processor Technology is IPMI managed + * based on POWER9 Processor Technology is OpenBMC managed [**Alpha**] .. toctree:: diff --git a/docs/source/guides/admin-guides/manage_clusters/ppc64le/management/basic/rcons.rst b/docs/source/guides/admin-guides/manage_clusters/ppc64le/management/basic/rcons.rst index 531266228..396880103 100644 --- a/docs/source/guides/admin-guides/manage_clusters/ppc64le/management/basic/rcons.rst +++ b/docs/source/guides/admin-guides/manage_clusters/ppc64le/management/basic/rcons.rst @@ -7,11 +7,11 @@ Most enterprise servers do not have video adapters installed with the machine an Configure the correct console management by modifying the node definition: - * For OpenPower, **IPMI** managed server: :: + * For OpenPOWER, **IPMI** managed server: :: chdef -t node -o cons=ipmi - * For OpenPower, **OpenBMC** managed servers: :: + * For OpenPOWER, **OpenBMC** managed servers: :: chdef -t node -o cons=openbmc @@ -46,7 +46,7 @@ The xCAT ``rcons`` command relies on conserver (http://www.conserver.com/). The OpenBMC Specific -``````````````` +```````````````` #. For OpenBMC managed servers, the root user must be able to ssh passwordless to the BMC for the ``rcons`` function to work. diff --git a/docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/config_statelite.rst b/docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/config_statelite.rst index ce44725f0..0e66ab76d 100644 --- a/docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/config_statelite.rst +++ b/docs/source/guides/admin-guides/manage_clusters/ppc64le/statelite/config_statelite.rst @@ -20,7 +20,7 @@ The litefile table specifies the directories and files on the statelite nodes th #. The third column in the litefile table specifies options for the directory or file: #. tmpfs - It provides a file or directory for the node to use when booting, its permission will be the same as the original version on the server. In most cases, it is read-write; however, on the next statelite boot, the original version of the file or directory on the server will be used, it means it is non-persistent. This option can be performed on files and directories. - #. rw - Same as Above.Its name "rw" does NOT mean it always be read-write, even in most cases it is read-write. Do not confuse it with the "rw" permission in the file system. + #. rw - Same as above. Its name "rw" does NOT mean it always be read-write, even in most cases it is read-write. Do not confuse it with the "rw" permission in the file system. #. persistent - It provides a mounted file or directory that is copied to the xCAT persistent location and then over-mounted on the local file or directory. Anything written to that file or directory is preserved. It means, if the file/directory does not exist at first, it will be copied to the persistent location. Next time the file/directory in the persistent location will be used. The file/directory will be persistent across reboots. Its permission will be the same as the original one in the statelite location. It requires the statelite table to be filled out with a spot for persistent statelite. This option can be performed on files and directories. #. con - The contents of the pathname are concatenated to the contents of the existing file. For this directive the searching in the litetree hierarchy does not stop when the first match is found. All files found in the hierarchy will be concatenated to the file when found. The permission of the file will be "-rw-r--r--", which means it is read-write for the root user, but readonly for the others. It is non-persistent, when the node reboots, all changes to the file will be lost. It can only be performed on files. Do not use it for one directory. #. ro - The file/directory will be overmounted read-only on the local file/directory. It will be located in the directory hierarchy specified in the litetree table. Changes made to this file or directory on the server will be immediately seen in this file/directory on the node. This option requires that the file/directory to be mounted must be available in one of the entries in the litetree table. This option can be performed on files and directories. @@ -133,5 +133,5 @@ noderes ``noderes.nfsserver`` attribute can be set for the NFSroot server. If this is not set, then the default is the Management Node. -``noderes.nfsdir`` can be set. If this is not set, the the default is ``/install`` +``noderes.nfsdir`` can be set. If this is not set, the default is ``/install`` diff --git a/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/FAQ.rst b/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/FAQ.rst index 7a00d46e6..214c79607 100644 --- a/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/FAQ.rst +++ b/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/FAQ.rst @@ -88,7 +88,7 @@ Fail to ping the installed VM ADDRCONF(NETDEV_UP): eth0 link is not ready. - **Solutoin**: + **Solution**: Usually caused by the incorrect VM NIC model. Try the following steps to specify "virtio": :: rmvm vm1 diff --git a/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/hypervisorKVM.rst b/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/hypervisorKVM.rst index e4f0b0b14..63a2df528 100644 --- a/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/hypervisorKVM.rst +++ b/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/hypervisorKVM.rst @@ -16,7 +16,7 @@ Provision Hypervisor #. Customize the hypervisor node definition to create network bridge - xCAT ships a postscript **xHRM** to create a network bridge on kvm host during installation/netbooting. Specify the **xHRM** with appropriate parameters in **postscripts** attibute. For example: + xCAT ships a postscript **xHRM** to create a network bridge on kvm host during installation/netbooting. Specify the **xHRM** with appropriate parameters in **postscripts** attribute. For example: * To create a bridge named 'br0' against the installation network device specified by **installnic**: :: @@ -68,7 +68,7 @@ If the hypervisor is provisioned successfully according to the steps described a br0 8000.000000000000 no eth0 -If the network bridge is not created or configured successfully, run "xHRM" with **updatenode** on managememt node to create it manually::: +If the network bridge is not created or configured successfully, run "xHRM" with **updatenode** on management node to create it manually::: updatenode kvmhost1 -P "xHRM bridgeprereq eth0:br0" diff --git a/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/kvmMN.rst b/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/kvmMN.rst index 8b735a1f4..eb33072f8 100644 --- a/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/kvmMN.rst +++ b/docs/source/guides/admin-guides/manage_clusters/ppc64le/virtual_machines/kvmMN.rst @@ -15,7 +15,7 @@ Please make sure the following packages have been installed on the management no Set Up the kvm storage directory on the management node(optional) ----------------------------------------------------------------- -It is a recommended configuration to create a shared file system for virtual machines hosting. The shared file system, usually on a SAN, NAS or GPFS, is shared among KVM hypevisors, which simplifies VM migration from one hypervisor to another with xCAT. +It is a recommended configuration to create a shared file system for virtual machines hosting. The shared file system, usually on a SAN, NAS or GPFS, is shared among KVM hypervisors, which simplifies VM migration from one hypervisor to another with xCAT. The easiest shared file system is ``/install`` directory on the management node, it can be shared among hypervisors via NFS. Please refer to the following steps : diff --git a/docs/source/guides/admin-guides/references/man1/bmcdiscover.1.rst b/docs/source/guides/admin-guides/references/man1/bmcdiscover.1.rst index efe3bde5b..7173c39f5 100644 --- a/docs/source/guides/admin-guides/references/man1/bmcdiscover.1.rst +++ b/docs/source/guides/admin-guides/references/man1/bmcdiscover.1.rst @@ -35,7 +35,7 @@ DESCRIPTION *********** -The \ **bmcdiscover**\ command will discover Baseboard Management Controllers (BMCs) using a scan mathod. +The \ **bmcdiscover**\ command will discover Baseboard Management Controllers (BMCs) using a scan method. The command uses \ **nmap**\ to scan active nodes over a specified IP range. The IP range format should be a format that is acceptable by \ **nmap**\ . @@ -52,7 +52,7 @@ OPTIONS \ **-**\ **-range**\ - Specify one or more IP ranges acceptable to nmap. IP rance can be hostnames, IP addresses, networks, etc. A single IP address (10.1.2.3) or an IP range (10.1.2.0/24) can be specified. If the range is very large, the \ **bmcdiscover**\ command may take a long time to return. + Specify one or more IP ranges acceptable to nmap. IP range can be hostnames, IP addresses, networks, etc. A single IP address (10.1.2.3) or an IP range (10.1.2.0/24) can be specified. If the range is very large, the \ **bmcdiscover**\ command may take a long time to return. diff --git a/docs/source/guides/admin-guides/references/man1/cfgve.1.rst b/docs/source/guides/admin-guides/references/man1/cfgve.1.rst index 6de85a9fd..3c53d9b20 100644 --- a/docs/source/guides/admin-guides/references/man1/cfgve.1.rst +++ b/docs/source/guides/admin-guides/references/man1/cfgve.1.rst @@ -98,7 +98,7 @@ OPTIONS be owned by vdsm:kvm. \ **localfs**\ : "/data/images/rhev" is set by default. - \ **virtsd.host**\ - A host must be specified for a storage doamin as SPM + \ **virtsd.host**\ - A host must be specified for a storage domain as SPM (Storage Pool Manager) when initialize the storage domain. The role of SPM may be migrated to other host by rhev-m during the running of the datacenter (For example, when the current SPM encountered issue or going to maintenance diff --git a/docs/source/guides/admin-guides/references/man1/chvm.1.rst b/docs/source/guides/admin-guides/references/man1/chvm.1.rst index 01e9afc33..14b1f28ea 100644 --- a/docs/source/guides/admin-guides/references/man1/chvm.1.rst +++ b/docs/source/guides/admin-guides/references/man1/chvm.1.rst @@ -151,7 +151,7 @@ PPC (using Direct FSP Management) specific: For Power 755(use option \ *--p775*\ to specify): -chvm could be used to change the octant configuration values for generating LPARs. chvm is designed to set the Octant configure value to split the CPU and memory for partitions, and set Octant Memory interleaving value. The chvm will only set the pending attributes value. After chvm, the CEC needs to be rebooted manually for the pending values to be enabled. Before reboot the cec, the administrator can use chvm to change the partition plan. If the the partition needs I/O slots, the administrator should use chvm to assign the I/O slots. +chvm could be used to change the octant configuration values for generating LPARs. chvm is designed to set the Octant configure value to split the CPU and memory for partitions, and set Octant Memory interleaving value. The chvm will only set the pending attributes value. After chvm, the CEC needs to be rebooted manually for the pending values to be enabled. Before reboot the cec, the administrator can use chvm to change the partition plan. If the partition needs I/O slots, the administrator should use chvm to assign the I/O slots. chvm is also designed to assign the I/O slots to the new LPAR. Both the current IO owning lpar and the new IO owning lpar must be powered off before an IO assignment. Otherwise, if the I/O slot is belonged to an Lpar and the LPAR is power on, the command will return an error when trying to assign that slot to a different lpar. @@ -166,7 +166,7 @@ zVM specific: ============= -The chvm command modifes the virtual machine's configuration specified in noderange. +The chvm command modifies the virtual machine's configuration specified in noderange. @@ -336,7 +336,7 @@ VMware/KVM specific: \ **-**\ **-resize**\ \ *disk*\ =\ *size*\ - Change the size of the Hard disk. The disk in \ *qcow2*\ format can not be set to less than it's current size. The disk in \ *raw*\ format can be resized smaller, use caution. Multiple disks can be resized by using comma separated \ *disk*\ \ **=**\ \ *size*\ pairs. The disks are specified by SCSI id. Size defaults to GB. + Change the size of the Hard disk. The disk in \ *qcow2*\ format can not be set to less than its current size. The disk in \ *raw*\ format can be resized smaller, use caution. Multiple disks can be resized by using comma separated \ *disk*\ \ **=**\ \ *size*\ pairs. The disks are specified by SCSI id. Size defaults to GB. diff --git a/docs/source/guides/admin-guides/references/man1/csm2xcat.1.rst b/docs/source/guides/admin-guides/references/man1/csm2xcat.1.rst index f03df04a2..cd06071a9 100644 --- a/docs/source/guides/admin-guides/references/man1/csm2xcat.1.rst +++ b/docs/source/guides/admin-guides/references/man1/csm2xcat.1.rst @@ -29,7 +29,7 @@ DESCRIPTION *********** -The csm2xcat command must be run on the Management Server of the CSM system that you want to migrate to xCAT. The commmand will build two xCAT stanza files that can update the xCAT database with the chdef command. +The csm2xcat command must be run on the Management Server of the CSM system that you want to migrate to xCAT. The command will build two xCAT stanza files that can update the xCAT database with the chdef command. Copy the csm2xcat command to the CSM Management Server. Run the command, indicating where you want your stanza files saved with the \ **-**\ **-dir**\ parameter. Check the stanza files to see if the information is what you want put in the xCAT database. Copy the two stanza files: node.stanza, device.stanza back to your xCAT Management node, and run the chdef command to input into the xCAT database. diff --git a/docs/source/guides/admin-guides/references/man1/db2sqlsetup.1.rst b/docs/source/guides/admin-guides/references/man1/db2sqlsetup.1.rst index 96b2fad80..2ea1fed24 100644 --- a/docs/source/guides/admin-guides/references/man1/db2sqlsetup.1.rst +++ b/docs/source/guides/admin-guides/references/man1/db2sqlsetup.1.rst @@ -46,7 +46,7 @@ For full information on the setup of DB2, see Setting_Up_DB2_as_the_xCAT_DB. When running of db2sqlsetup on the MN: One password must be supplied for the setup, a password for the xcatdb unix id which will be used as the DB2 instance id and database name. The password will be prompted for interactively or can be input with the XCATDB2PW environment variable. -The script will create the xcat database instance (xcatdb) in the /var/lib/db2 directory unless overriden by setting the site.databaseloc attribute. This attribute should not be set to the directory that is defined in the installloc attribute and it is recommended that the databaseloc be a new filesystem dedicated to the DB2 database, especially in very large clusters. +The script will create the xcat database instance (xcatdb) in the /var/lib/db2 directory unless overridden by setting the site.databaseloc attribute. This attribute should not be set to the directory that is defined in the installloc attribute and it is recommended that the databaseloc be a new filesystem dedicated to the DB2 database, especially in very large clusters. When running db2sqlseutp on the SN: Not only will the password for the DB2 instance Id be prompted for and must match the one on the Management Node; but also the hostname or ip address of the Management Node as known by the Service Node must be supplied , unless the XCATDB2SERVER environment variable is set. diff --git a/docs/source/guides/admin-guides/references/man1/dumpxCATdb.1.rst b/docs/source/guides/admin-guides/references/man1/dumpxCATdb.1.rst index 8dcaedc47..af89c9fef 100644 --- a/docs/source/guides/admin-guides/references/man1/dumpxCATdb.1.rst +++ b/docs/source/guides/admin-guides/references/man1/dumpxCATdb.1.rst @@ -35,7 +35,7 @@ If not using the binary dump option (-b), then the dumpxCATdb command creates .c Supports using XCAT_SKIPTABLES env variable to provide a list of skip tables. The command will never backup TEAL or ISNM tables, except isnm_config. To dump TEAL tables use the documented process for TEAL. For ISNM use tabdump, after using tabprune to get to prune unnecessary records. -If using the binary dump option for the DB2 or postgreSQL database, then the routine will use the Database provide utilites for backup of the entire database. +If using the binary dump option for the DB2 or postgreSQL database, then the routine will use the Database provide utilities for backup of the entire database. ******* @@ -49,7 +49,7 @@ OPTIONS \ **-V**\ Verbose. -\ **-a**\ All,without this flag the eventlog and auditlog will be skipped. +\ **-a**\ All, without this flag the eventlog and auditlog will be skipped. \ **-b**\ This flag is only used for the DB2 or postgreSQL database. The routine will use the database backup utilities to create a binary backup of the entire database. Note to use this backup on DB2, you will have first had to modify the logging of the database and have taken an offline initial backup. Refer to the xCAT DB2 documentation for more instructions. diff --git a/docs/source/guides/admin-guides/references/man1/genimage.1.rst b/docs/source/guides/admin-guides/references/man1/genimage.1.rst index 6d0f8adfd..d28fd3880 100644 --- a/docs/source/guides/admin-guides/references/man1/genimage.1.rst +++ b/docs/source/guides/admin-guides/references/man1/genimage.1.rst @@ -46,7 +46,7 @@ for stateless: \ **packimage**\ for statelite: \ **liteimg**\ -Besides prompting for some paramter values, the \ **genimage**\ command takes default guesses for the parameters not specified or not defined in the \ *osimage*\ and \ *linuximage*\ tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Use \ **-**\ **-interactive**\ flag if you want the yum/zypper command to prompt you for the answers. +Besides prompting for some parameter values, the \ **genimage**\ command takes default guesses for the parameters not specified or not defined in the \ *osimage*\ and \ *linuximage*\ tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Use \ **-**\ **-interactive**\ flag if you want the yum/zypper command to prompt you for the answers. If \ **-**\ **-onlyinitrd**\ is specified, genimage only regenerates the initrd for a stateless image to be used for a diskless install. diff --git a/docs/source/guides/admin-guides/references/man1/geninitrd.1.rst b/docs/source/guides/admin-guides/references/man1/geninitrd.1.rst index ffac5dd95..881fff450 100644 --- a/docs/source/guides/admin-guides/references/man1/geninitrd.1.rst +++ b/docs/source/guides/admin-guides/references/man1/geninitrd.1.rst @@ -43,7 +43,7 @@ If the initrd has been rebuilt by geninitrd, when run nodeset, the \ *--noupdate should be used to skip the rebuilding of initrd to improve the performance. Three attributes of osimage object can be used to specify the Driver RPM location and Driver names -for injecting new drviers to initrd. +for injecting new drivers to initrd. \ **netdrivers**\ - comma separated driver names that need to be injected to the initrd. The postfix '.ko' can be ignored. The netdrivers attribute must be set to specify the new driver list. @@ -65,7 +65,7 @@ this command is used to generate the initrd from the rootimg which generated by So the 'genimage' must be run once before running the geninitrd command. Two attributes of osimage object can be used to specify the Driver RPM location and Driver names -for injecting new drviers to initrd. +for injecting new drivers to initrd. \ **netdrivers**\ - comma separated driver names that need to be injected to the initrd. The postfix '.ko' can be ignored. The netdrivers attribute must be set to specify the new driver list. @@ -79,7 +79,7 @@ Parameters ********** -\ *imagename*\ specifies the name of an os image definition to be used. The specification for the image is storted in the \ *osimage*\ table and \ *linuximage*\ table. +\ *imagename*\ specifies the name of an os image definition to be used. The specification for the image is stored in the \ *osimage*\ table and \ *linuximage*\ table. \ **-**\ **-ignorekernelchk**\ diff --git a/docs/source/guides/admin-guides/references/man1/getadapter.1.rst b/docs/source/guides/admin-guides/references/man1/getadapter.1.rst index 7bd216c97..316f4bcea 100644 --- a/docs/source/guides/admin-guides/references/man1/getadapter.1.rst +++ b/docs/source/guides/admin-guides/references/man1/getadapter.1.rst @@ -31,26 +31,52 @@ DESCRIPTION Traditionally, network interfaces in Linux are enumerated as eth[0123...], but these names do not necessarily correspond to actual labels on the chassis. \ **getadapter**\ help customer to get predictable network device name and some other network adapter information before provision or network configuration. -\ **getadapter**\ use genesis to collect network adapters information, so that mean it need to restart the target node. +\ **Since getadpter uses genesis to collect network adapters information, the target node will be restarted.**\ \ **getadapter**\ For each node within the , follows below scheme: -If the target node is scaned for the first time, \ **getadapter**\ will trigger genesis to collect information then save the information at the \ **nicsadapter**\ column of nics table. -If the target node has ever been scaned, \ **getadapter**\ will use the information from nics table first. +If the target node is scanned for the first time, \ **getadapter**\ will trigger genesis to collect information then save the information at the \ **nicsadapter**\ column of nics table. +If the target node has ever been scanned, \ **getadapter**\ will use the information from nics table first. If user hopes to scan the adapter information for the node but these information already exist, \ **-f**\ option can be used to start rescan process. \ **getadapter**\ tries to collect more information for the target network device, but doesn't guarantee collect same much information for every network device. -Below are the possible information can be collect up to now: + +****************************** +\ **Collected information:**\ +****************************** + + + \ **name**\ : the consistent name which can be used by confignic directly in operating system which follow the same naming scheme with rhels7 + + + \ **pci**\ : the pci location + + + \ **mac**\ : the MAC address + + + \ **candidatename**\ : All the names which satisfy predictable network device naming scheme. \ *(if xcat enhance confignic command later, user can use these names to configure their network adapter, even customize their name)*\ + + + \ **vender**\ : the vender of network device + + + \ **model**\ : the model of network device + + + \ **linkstate**\ : the link state of network device + + ******* OPTIONS ******* diff --git a/docs/source/guides/admin-guides/references/man1/getmacs.1.rst b/docs/source/guides/admin-guides/references/man1/getmacs.1.rst index 05bfd6ff0..a38bc1abf 100644 --- a/docs/source/guides/admin-guides/references/man1/getmacs.1.rst +++ b/docs/source/guides/admin-guides/references/man1/getmacs.1.rst @@ -51,12 +51,12 @@ DESCRIPTION The getmacs command collects MAC address from a single or range of nodes. -Note that on AIX systems, the returned MAC address is not colon-seperated (for example 8ee2245cf004), while on Linux systems the MAC address is colon-seperated (for example 8e:e2:24:5c:f0:04). +Note that on AIX systems, the returned MAC address is not colon-separated (for example 8ee2245cf004), while on Linux systems the MAC address is colon-separated (for example 8e:e2:24:5c:f0:04). If no ping test performed, getmacs writes the first adapter MAC to the xCAT database. If ping test performed, getmacs will write the first successfully pinged MAC to xCAT database. For PPC (using Direct FSP Management) specific: -Note: If network adapters are physically assigned to LPARs, getmacs cannot read the MAC addresses unless perform \ **Discovery**\ with option "\ **-D**\ ", since there is no HMC command to read them and getmacs has to login to open formware. And if the LPARs has never been activated before, getmacs need to be performed with the option "\ **-D**\ " to get theirs MAC addresses. +Note: If network adapters are physically assigned to LPARs, getmacs cannot read the MAC addresses unless perform \ **Discovery**\ with option "\ **-D**\ ", since there is no HMC command to read them and getmacs has to login to open firmware. And if the LPARs has never been activated before, getmacs need to be performed with the option "\ **-D**\ " to get theirs MAC addresses. For PPC (using HMC) specific: @@ -74,7 +74,7 @@ OPTIONS \ **-**\ **-arp**\ -Read MAC address with ARP protocal. +Read MAC address with ARP protocol. \ **-C**\ @@ -90,7 +90,7 @@ Perform discovery for mac address. By default, it will run ping test to test th \ **-f**\ -Force immediate shutdown of the partition.This flag must be used with -D flag. +Force immediate shutdown of the partition. This flag must be used with -D flag. \ **-F**\ @@ -118,7 +118,7 @@ Read MAC address when the lpar is in openfirmware state. This option mush be us \ **-S**\ -The IP address of the machine to ping. The default is to read from xCAT databse if no \ **-S**\ specified. +The IP address of the machine to ping. The default is to read from xCAT database if no \ **-S**\ specified. \ **-v**\ @@ -167,7 +167,7 @@ Output is similar to: ent U78A1.001.99203B5-P1-T6 00145eb55788 /lhea@23c00614/ethernet@23e00514 unsuccessful physical -2. To retrieve the MAC address with ARP protocal: +2. To retrieve the MAC address with ARP protocol: .. code-block:: perl diff --git a/docs/source/guides/admin-guides/references/man1/groupfiles4dsh.1.rst b/docs/source/guides/admin-guides/references/man1/groupfiles4dsh.1.rst index ea06cfd04..3a2675767 100644 --- a/docs/source/guides/admin-guides/references/man1/groupfiles4dsh.1.rst +++ b/docs/source/guides/admin-guides/references/man1/groupfiles4dsh.1.rst @@ -33,7 +33,7 @@ This tool will build a directory of files, one for each defined nodegroup in xCAT. The file will be named the nodegroup name and contain a list of nodes that belong to the nodegroup. The file can be used as input to the AIX dsh command. -The purpose of this tool is to allow backward compatiblity with scripts +The purpose of this tool is to allow backward compatibility with scripts that were created using the AIX or CSM dsh command Reference: man dsh. diff --git a/docs/source/guides/admin-guides/references/man1/imgexport.1.rst b/docs/source/guides/admin-guides/references/man1/imgexport.1.rst index 2e08a1b61..3626725f1 100644 --- a/docs/source/guides/admin-guides/references/man1/imgexport.1.rst +++ b/docs/source/guides/admin-guides/references/man1/imgexport.1.rst @@ -61,7 +61,7 @@ For statelite: where x is the name of the profile. -Any files specified by the \ **-e**\ flag will also be exported. If \ **-p**\ flag is specified, the names of the postscripts and the postbootscripts for the given node will be exported. The postscripts themsleves need to be manualy exported using \ **-e**\ flag. +Any files specified by the \ **-e**\ flag will also be exported. If \ **-p**\ flag is specified, the names of the postscripts and the postbootscripts for the given node will be exported. The postscripts themselves need to be manualy exported using \ **-e**\ flag. For statelite, the litefile table settings for the image will also be exported. The litetree and statelite tables are not exported. diff --git a/docs/source/guides/admin-guides/references/man1/imgimport.1.rst b/docs/source/guides/admin-guides/references/man1/imgimport.1.rst index e5e542f7c..6359d535d 100644 --- a/docs/source/guides/admin-guides/references/man1/imgimport.1.rst +++ b/docs/source/guides/admin-guides/references/man1/imgimport.1.rst @@ -69,7 +69,7 @@ If \ **-p**\ flag is specified, the \ *postscripts*\ table will be updated wit If \ **-f**\ flag is not specified, all the files will be copied to the same directories as the source. If it is specified, the old profile name x will be changed to the new and the files will be copied to the appropriate directores for the new profiles. For example, \ */opt/xcat/share/xcat/netboot/sles/x.pkglist*\ will be copied to \ */install/custom/netboot/sles/compute_new.pkglist*\ and \ */install/netboot/sles11/ppc64/x/kernel*\ will be copied to \ */install/netboot/sles11/ppc64/compute_new/kernel*\ . This flag is commonly used when you want to copy the image on the same xCAT mn so you can make modification on the new one. -After this command, you can run the \ **nodeset**\ command and then start deploying the nodes. You can also choose to modify the files and run the following commands before the node depolyment. +After this command, you can run the \ **nodeset**\ command and then start deploying the nodes. You can also choose to modify the files and run the following commands before the node deployment. For stateful: nodeset diff --git a/docs/source/guides/admin-guides/references/man1/liteimg.1.rst b/docs/source/guides/admin-guides/references/man1/liteimg.1.rst index ceaec142a..266f59b73 100644 --- a/docs/source/guides/admin-guides/references/man1/liteimg.1.rst +++ b/docs/source/guides/admin-guides/references/man1/liteimg.1.rst @@ -63,7 +63,7 @@ PARAMETERS ********** -\ *imagename*\ specifies the name of a os image definition to be used. The specification for the image is storted in the \ *osimage*\ table and \ *linuximage*\ table. +\ *imagename*\ specifies the name of a os image definition to be used. The specification for the image is stored in the \ *osimage*\ table and \ *linuximage*\ table. ******* diff --git a/docs/source/guides/admin-guides/references/man1/lsflexnode.1.rst b/docs/source/guides/admin-guides/references/man1/lsflexnode.1.rst index e3c553c2e..e72fc0ce0 100644 --- a/docs/source/guides/admin-guides/references/man1/lsflexnode.1.rst +++ b/docs/source/guides/admin-guides/references/man1/lsflexnode.1.rst @@ -38,7 +38,7 @@ There are several concepts to support the HX5 multiple blades combination: \ **Complex**\ : Multiple blades which combined by a scalability card is a complex. -\ **Parition**\ : A logic concept which containing part of the \ **Blade slot node**\ in a complex. Each partition can map to a system to install Operating System. Each partition could have 1HX5, 1HX5+1MD or 2HX5+2MD. (MD is the Memory Drawer) +\ **Partition**\ : A logic concept which containing part of the \ **Blade slot node**\ in a complex. Each partition can map to a system to install Operating System. Each partition could have 1HX5, 1HX5+1MD or 2HX5+2MD. (MD is the Memory Drawer) \ **Blade slot node**\ : The physical blade which installed in the slot of a chassis. It can be a HX5 or MD. diff --git a/docs/source/guides/admin-guides/references/man1/lskitcomp.1.rst b/docs/source/guides/admin-guides/references/man1/lskitcomp.1.rst index 81500f251..895a065e1 100644 --- a/docs/source/guides/admin-guides/references/man1/lskitcomp.1.rst +++ b/docs/source/guides/admin-guides/references/man1/lskitcomp.1.rst @@ -89,7 +89,7 @@ OPTIONS - Each tag contains info for a group of kit compoonents belonging to the same kit. The info inside is structured as follows: + Each tag contains info for a group of kit components belonging to the same kit. The info inside is structured as follows: .. code-block:: perl diff --git a/docs/source/guides/admin-guides/references/man1/lsslp.1.rst b/docs/source/guides/admin-guides/references/man1/lsslp.1.rst index 0d16d5f50..3c83cb355 100644 --- a/docs/source/guides/admin-guides/references/man1/lsslp.1.rst +++ b/docs/source/guides/admin-guides/references/man1/lsslp.1.rst @@ -41,13 +41,13 @@ OPTIONS ******* -\ **noderange**\ The nodes which the user want to discover. If the user specify the noderange, lsslp will just return the nodes in the node range. Which means it will help to add the new nodes to the xCAT database without modifying the existed definitions. But the nodes' name specified in noderange should be defined in database in advance. The specified nodes' type can be frame/cec/hmc/fsp/bpa. If the it is frame or cec, lsslp will list the bpa or fsp nodes within the nodes(bap for frame, fsp for cec). Do not use noderange with the flag -s. +\ **noderange**\ The nodes which the user wants to discover. If the user specifies the noderange, lsslp will just return the nodes in the node range. Which means it will help to add the new nodes to the xCAT database without modifying the existed definitions. But the nodes' name specified in noderange should be defined in database in advance. The specified nodes' type can be frame/cec/hmc/fsp/bpa. If the it is frame or cec, lsslp will list the bpa or fsp nodes within the nodes(bap for frame, fsp for cec). Do not use noderange with the flag -s. \ **-i**\ IP(s) the command will send out (defaults to all available adapters). \ **-h**\ Display usage message. -\ **-n**\ Only display and write the newly discovered hardwares. +\ **-n**\ Only display and write the newly discovered hardware. \ **-u**\ Do unicast to a specified IP range. Must be used with \ **-s**\ and \ **-**\ **-range**\ . The \ **-u**\ flag is not supported on AIX. @@ -55,15 +55,15 @@ OPTIONS \ **-r**\ Display Raw SLP response. -\ **-C**\ The number of the expected responses specified by the user. When using this flag, lsslp will not return until the it has found all the nodes or time out. The default max time is 3 secondes. The user can use -T flag the specify the time they want to use. A short time will limite the time costing, while a long time will help to find all the nodes. +\ **-C**\ The number of the expected responses specified by the user. When using this flag, lsslp will not return until the it has found all the nodes or time out. The default max time is 3 seconds. The user can use -T flag the specify the time they want to use. A short time will limit the time costing, while a long time will help to find all the nodes. -\ **-T**\ The number in seconds to limite the time costing of lsslp. +\ **-T**\ The number in seconds to limit the time of lsslp. \ **-s**\ Service type interested in discovering. \ **-t**\ Number or service-request attempts. -\ **-**\ **-vpdtable**\ Output the SLP response in vpdtable formatting. Easy for writting data to vpd table. +\ **-**\ **-vpdtable**\ Output the SLP response in vpdtable formatting. Easy for writing data to vpd table. \ **-v**\ Command Version. @@ -73,9 +73,9 @@ OPTIONS \ **-x**\ XML format. -\ **-z**\ Stanza formated output. +\ **-z**\ Stanza formatted output. -\ **-I**\ Give the warning message for the nodes in database which have no SLP responses. Note that this flag noly can be used after the database migration finished successfully. +\ **-I**\ Give the warning message for the nodes in database which have no SLP responses. Note that this flag can only be used after the database migration finished successfully. ************ diff --git a/docs/source/guides/admin-guides/references/man1/lstree.1.rst b/docs/source/guides/admin-guides/references/man1/lstree.1.rst index b4c58f176..e6a4eeddf 100644 --- a/docs/source/guides/admin-guides/references/man1/lstree.1.rst +++ b/docs/source/guides/admin-guides/references/man1/lstree.1.rst @@ -29,7 +29,7 @@ DESCRIPTION *********** -The \ **lstree**\ command can display the tree of service node hierarchy for the xCAT nodes which have service node defined or which are service nodes, display the tree of hardware hierarchy only for the physical objects, display the tree of VM hierarchy for the xCAT nodes which are virtual machines or which are the hosts of virtual machines. If a noderange is specified, only show the part of the hierarchy that involves those nodes. For ZVM, we only support to disply VM hierarchy. By default, lstree will show both the hardware hierarchy and the VM hierarchy for all the nodes. +The \ **lstree**\ command can display the tree of service node hierarchy for the xCAT nodes which have service node defined or which are service nodes, display the tree of hardware hierarchy only for the physical objects, display the tree of VM hierarchy for the xCAT nodes which are virtual machines or which are the hosts of virtual machines. If a noderange is specified, only show the part of the hierarchy that involves those nodes. For ZVM, we only support to display VM hierarchy. By default, lstree will show both the hardware hierarchy and the VM hierarchy for all the nodes. ******* diff --git a/docs/source/guides/admin-guides/references/man1/lsvm.1.rst b/docs/source/guides/admin-guides/references/man1/lsvm.1.rst index dc53a2c47..ad48cc0af 100644 --- a/docs/source/guides/admin-guides/references/man1/lsvm.1.rst +++ b/docs/source/guides/admin-guides/references/man1/lsvm.1.rst @@ -360,7 +360,7 @@ Output is similar to: Available BSR array: 256 -Note: The lines listed in "All Physical I/O info" section represent all the physical I/O resource information. The format is like "owner_lparid,slot_id,physical resource name,drc_index,slot_class_code(class discription)". The 'drc index' is short for Dynamic Resource Configuration Index, it uniquely indicates a physical I/O resource in a normal power machine. +Note: The lines listed in "All Physical I/O info" section represent all the physical I/O resource information. The format is like "owner_lparid,slot_id,physical resource name,drc_index,slot_class_code(class description)". The 'drc index' is short for Dynamic Resource Configuration Index, it uniquely indicates a physical I/O resource in a normal power machine. 9. For DFM-managed partition on normal power machine, list out the detailed information: diff --git a/docs/source/guides/admin-guides/references/man1/mkdef.1.rst b/docs/source/guides/admin-guides/references/man1/mkdef.1.rst index 41084a288..066084735 100644 --- a/docs/source/guides/admin-guides/references/man1/mkdef.1.rst +++ b/docs/source/guides/admin-guides/references/man1/mkdef.1.rst @@ -84,7 +84,7 @@ OPTIONS \ **-**\ **-template**\ \ *template-object-name*\ - Name of the xCAT shipped object definition template or an existing object, from which the new object definition will be created. The newly created object will inherit the attributes of the template definition unless the attribute is specified in the arguments of \ **mkdef**\ command. If there are a template and an existing object with the same name \ *template-object-name*\ , the tempalte object takes precedence over the existing object. For the details of xCAT shipped object definition templates, refer to the manpage of \ **-**\ **-template**\ option in lsdef(1)|lsdef.1. + Name of the xCAT shipped object definition template or an existing object, from which the new object definition will be created. The newly created object will inherit the attributes of the template definition unless the attribute is specified in the arguments of \ **mkdef**\ command. If there are a template and an existing object with the same name \ *template-object-name*\ , the template object takes precedence over the existing object. For the details of xCAT shipped object definition templates, refer to the manpage of \ **-**\ **-template**\ option in lsdef(1)|lsdef.1. @@ -96,7 +96,7 @@ OPTIONS \ **-w**\ \ *attr==val*\ \ **-w**\ \ *attr=~val*\ ... - Use one or multiple -w flags to specify the selection string that can be used to select objects. The operators ==, !=, =~ and !~ are available. For mkdef commmand, the -w flag only makes sense for creating dynamic node group. Use the help option to get a list of valid attributes for each object type. + Use one or multiple -w flags to specify the selection string that can be used to select objects. The operators ==, !=, =~ and !~ are available. For mkdef command, the -w flag only makes sense for creating dynamic node group. Use the help option to get a list of valid attributes for each object type. Operator descriptions: == Select nodes where the attribute value is exactly this value. diff --git a/docs/source/guides/admin-guides/references/man1/mkdocker.1.rst b/docs/source/guides/admin-guides/references/man1/mkdocker.1.rst index 87559be1c..f1e2d2e47 100644 --- a/docs/source/guides/admin-guides/references/man1/mkdocker.1.rst +++ b/docs/source/guides/admin-guides/references/man1/mkdocker.1.rst @@ -137,7 +137,7 @@ Output is similar to: host01c01: Pull image ubuntu start host01c01: Pull image ubuntu done host01c01: Remove default network connection - host01c01: Connecting customzied network 'mynet0' + host01c01: Connecting customized network 'mynet0' host01c01: success @@ -155,7 +155,7 @@ Output is similar to: .. code-block:: perl host01c01: Remove default network connection - host01c01: Connecting customzied network 'mynet0' + host01c01: Connecting customized network 'mynet0' host01c01: success diff --git a/docs/source/guides/admin-guides/references/man1/mkdsklsnode.1.rst b/docs/source/guides/admin-guides/references/man1/mkdsklsnode.1.rst index f1a4294e7..6968e6039 100644 --- a/docs/source/guides/admin-guides/references/man1/mkdsklsnode.1.rst +++ b/docs/source/guides/admin-guides/references/man1/mkdsklsnode.1.rst @@ -38,7 +38,7 @@ This command will also create a NIM resolv_conf resource to be used when install The "domain" and "nameservers" attributes can be set in either the xCAT "network" definition used by the nodes or in the xCAT cluster "site" definition. The setting in the "network" definition will take priority. The "search" field of the resolv.conf file will contain a list all the domains -listed in the xCAT network definitions and the xCAT site definiton. +listed in the xCAT network definitions and the xCAT site definition. The "nameservers" value can either be set to a specific IP address or the "" key word. The "" key word means that the value of the "xcatmaster" attribute of the node definition will be used in the /etc/resolv.conf file. (I.e. The name of the install server as known by the node.) @@ -57,11 +57,11 @@ You can use the "-n" option of the mkdsklsnode command to create and initialize \ **Note:**\ When using the "-n" option make sure that the new osimage you specify and all the NIM resources that are used are different than what are currently being used on the nodes. The NIM resources should not be shared between the old osimage and the new osimage. -You can use the force option to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinititializing. Use this option with caution since reinitializing a node will stop the node if it is currently running. +You can use the force option to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinitializing. Use this option with caution since reinitializing a node will stop the node if it is currently running. After the mkdsklsnode command completes you can use the \ **lsnim**\ command to check the NIM node definition to see if it is ready for booting the node. ("lsnim -l "). -You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **mkdsklsnode**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts dirctory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **mkdsklsnode**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **mkdsklsnode**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *diskless:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current current nodeset action, in this case "diskless". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes. +You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **mkdsklsnode**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts directory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **mkdsklsnode**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **mkdsklsnode**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *diskless:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "diskless". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at a time. If it is not specified, the script will be invoked once for all the nodes. ******* diff --git a/docs/source/guides/admin-guides/references/man1/mknimimage.1.rst b/docs/source/guides/admin-guides/references/man1/mknimimage.1.rst index 15d496c90..1d2985946 100644 --- a/docs/source/guides/admin-guides/references/man1/mknimimage.1.rst +++ b/docs/source/guides/admin-guides/references/man1/mknimimage.1.rst @@ -43,7 +43,7 @@ When creating a mksysb image definition you must specify either the "-n" or the When creating a diskless osimage definition you also have the option of automatically updating the NIM SPOT resource. You can have additional software installed or you can have configuration files added or updated. To have software installed you must provide either the names of NIM installp_bundle resources or fileset names on the command line using the "attr=val" option. You may also supply the installp flags, RPM flags, emgr flags to use when installing the software. -To have configuration files updated you must provide the full path name of a "synclists" file which contains the the list of actual files to update. The xCAT osimage definition that is created will contain the installp_bundle, otherpkgs, and synclists files that are provided on the command line. +To have configuration files updated you must provide the full path name of a "synclists" file which contains the list of actual files to update. The xCAT osimage definition that is created will contain the installp_bundle, otherpkgs, and synclists files that are provided on the command line. \ **Updating an existing xCAT osimage**\ @@ -69,7 +69,7 @@ You can use the "-i" and "-p" options to copy an existing diskless osimage. To - any other resources (or attributes) included in the original osimage will be included in the new osimage definition. -- if the "-p" option is specified then the original NIM lpp_source resource will be copied to a new location and redfined to NIM. (The default would be to use the original lpp_source - to save file system space.) +- if the "-p" option is specified then the original NIM lpp_source resource will be copied to a new location and redefined to NIM. (The default would be to use the original lpp_source - to save file system space.) \ **Additional information**\ @@ -85,7 +85,7 @@ To list a NIM resource definition use the AIX \ **lsnim**\ command ("lsnim -l < To check the validity of a SPOT or lpp_source resource use the AIX \ **nim**\ command ("nim -o check "). -To remove specific NIM resource definitons use the AIX \ **nim**\ command. ("nim -o remove "). +To remove specific NIM resource definitions use the AIX \ **nim**\ command. ("nim -o remove "). ******* @@ -255,7 +255,7 @@ OPTIONS - Note that you may specify multiple "script", "otherpkgs", and "installp_bundle" resources by using a comma seperated list. (ex. "script=ascript,bscript"). RPM names may be included in the "otherpkgs" list by using a "R:" prefix(ex. "R:whatever.rpm"). epkg (AIX interim fix package) file names may be included in the "otherpkgs" using the 'E:' prefix. (ex. "otherpkgs=E:IZ38930TL0.120304.epkg.Z"). + Note that you may specify multiple "script", "otherpkgs", and "installp_bundle" resources by using a comma separated list. (ex. "script=ascript,bscript"). RPM names may be included in the "otherpkgs" list by using a "R:" prefix(ex. "R:whatever.rpm"). epkg (AIX interim fix package) file names may be included in the "otherpkgs" using the 'E:' prefix. (ex. "otherpkgs=E:IZ38930TL0.120304.epkg.Z"). @@ -267,7 +267,7 @@ OPTIONS \ **-c|-**\ **-completeosimage**\ - Complete the creation of the osimage definition passed in on the command line. This option will use any additonal values passed in on the command line and/or it will attempt to create required resources in order to complete the definition of the xCAT osimage. For example, if the osimage definition is missing a spot or shared_root resource the command will create those resources and add them to the osimage definition. + Complete the creation of the osimage definition passed in on the command line. This option will use any additional values passed in on the command line and/or it will attempt to create required resources in order to complete the definition of the xCAT osimage. For example, if the osimage definition is missing a spot or shared_root resource the command will create those resources and add them to the osimage definition. @@ -492,7 +492,7 @@ The xCAT osimage definition created by this command will include the "otherpkgs" mknimimage -u 61dskls installp_bundle=bndres1,bndres2 installp_flags="-agcQX" -Note that when "installp_bundle", "otherpkgs", or "synclists" values are specified with the "-u" option then the xCAT osimage definiton is not used or updated. +Note that when "installp_bundle", "otherpkgs", or "synclists" values are specified with the "-u" option then the xCAT osimage definition is not used or updated. 13) Update an existing image to support NFSv4. Also specify verbose messages. diff --git a/docs/source/guides/admin-guides/references/man1/mkvm.1.rst b/docs/source/guides/admin-guides/references/man1/mkvm.1.rst index 753ddd42e..effaaa109 100644 --- a/docs/source/guides/admin-guides/references/man1/mkvm.1.rst +++ b/docs/source/guides/admin-guides/references/man1/mkvm.1.rst @@ -148,7 +148,7 @@ OPTIONS \ **vmcpus=**\ \ *value*\ \ **vmmemory=**\ \ *value*\ \ **vmphyslots=**\ \ *value*\ \ **vmothersetting=**\ \ *value*\ \ **vmnics=**\ \ *value*\ \ **vmstorage=**\ \ *value*\ [\ **-**\ **-vios**\ ] - To specify the parameters which are used to create a partition. The \ *vmcpus*\ , \ *vmmemory*\ are necessay, and the value specified with this command have a more high priority. If the value of any of the three options is not specified, the corresponding value specified for the node object will be used. If any of the three attributes is neither specified with this command nor specified with the node object, error information will be returned. To reference to lsvm(1)|lsvm.1 for more information about 'drc_index' for \ *vmphyslots*\ . + To specify the parameters which are used to create a partition. The \ *vmcpus*\ , \ *vmmemory*\ are necessary, and the value specified with this command have a more high priority. If the value of any of the three options is not specified, the corresponding value specified for the node object will be used. If any of the three attributes is neither specified with this command nor specified with the node object, error information will be returned. To reference to lsvm(1)|lsvm.1 for more information about 'drc_index' for \ *vmphyslots*\ . The option \ *vios*\ is used to specify the partition that will be created is a VIOS partition. If specified, the value for \ *vmstorage*\ shall be number which indicate the number of vSCSI server adapter will be created, and if no value specified for \ *vmphyslots*\ , all the physical slot of the power machine will be asigned to VIOS partition. If not specified, it shall be in form of \ *vios_name:server_slotid*\ to specify the vios and the virtual slot id of the vSCSI server adapter that will be connected from the Logical partition. @@ -392,7 +392,7 @@ First, define a node object: mkdef -t node -o lpar1 mgt=fsp cons=fsp nodetype=ppc,osi id=1 hcp=cec parent=cec hwtype=lpar groups=lpar,all -Then, create the partion on the specified cec. +Then, create the partition on the specified cec. .. code-block:: perl @@ -515,7 +515,7 @@ The output is similar to: mkvm viosnode vmcpus=1/4/16 vmmemory=1G/4G/32G vmphyslots=0x21010201,0x21010200 vmnics=vlan1 vmstorage=5 --vios -The resouces for the node is similar to: +The resources for the node is similar to: .. code-block:: perl diff --git a/docs/source/guides/admin-guides/references/man1/monadd.1.rst b/docs/source/guides/admin-guides/references/man1/monadd.1.rst index df2c69af8..bb8f629e8 100644 --- a/docs/source/guides/admin-guides/references/man1/monadd.1.rst +++ b/docs/source/guides/admin-guides/references/man1/monadd.1.rst @@ -39,9 +39,9 @@ Parameters ********** -\ *name*\ is the name of the monitoring plug-in module. For example, if the the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used. +\ *name*\ is the name of the monitoring plug-in module. For example, if the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used. -\ *settings*\ is the monitoring plug-in specific settings. It is used to customize the behavior of the plug-in or configure the 3rd party software. Format: \ *-s key-value -s key=value ...*\ Note that the square brackets are needed here. Use \ *monls name -d*\ command to look for the possbile setting keys for a plug-in module. +\ *settings*\ is the monitoring plug-in specific settings. It is used to customize the behavior of the plug-in or configure the 3rd party software. Format: \ *-s key-value -s key=value ...*\ Note that the square brackets are needed here. Use \ *monls name -d*\ command to look for the possible setting keys for a plug-in module. ******* diff --git a/docs/source/guides/admin-guides/references/man1/moncfg.1.rst b/docs/source/guides/admin-guides/references/man1/moncfg.1.rst index febc5f32f..a7ac99ccd 100644 --- a/docs/source/guides/admin-guides/references/man1/moncfg.1.rst +++ b/docs/source/guides/admin-guides/references/man1/moncfg.1.rst @@ -31,7 +31,7 @@ DESCRIPTION *********** -This command is used to configure a 3rd party monitoring software to monitor the xCAT cluster. For example, it modifies the configration file for the monitoring software so that the nodes can be included in the monitoring domain. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified, though the configuration of the nodes is usually performed during the node deployment stage. +This command is used to configure a 3rd party monitoring software to monitor the xCAT cluster. For example, it modifies the configuration file for the monitoring software so that the nodes can be included in the monitoring domain. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified, though the configuration of the nodes is usually performed during the node deployment stage. ********** @@ -39,7 +39,7 @@ Parameters ********** -\ *name*\ is the name of the monitoring plug-in module. For example, if the the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used. +\ *name*\ is the name of the monitoring plug-in module. For example, if the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used. \ *noderange*\ specifies the nodes to be monitored. If omitted, all nodes will be monitored. diff --git a/docs/source/guides/admin-guides/references/man1/mondecfg.1.rst b/docs/source/guides/admin-guides/references/man1/mondecfg.1.rst index 1b6b8439b..eeb0dc747 100644 --- a/docs/source/guides/admin-guides/references/man1/mondecfg.1.rst +++ b/docs/source/guides/admin-guides/references/man1/mondecfg.1.rst @@ -31,7 +31,7 @@ DESCRIPTION *********** -This command is used to deconfigure a 3rd party monitoring software from monitoring the xCAT cluster. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified. The deconfigration operation will remove the nodes from the 3rd party software's monitoring domain. +This command is used to deconfigure a 3rd party monitoring software from monitoring the xCAT cluster. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified. The deconfiguration operation will remove the nodes from the 3rd party software's monitoring domain. ********** diff --git a/docs/source/guides/admin-guides/references/man1/monls.1.rst b/docs/source/guides/admin-guides/references/man1/monls.1.rst index 7f321d21b..f5241006d 100644 --- a/docs/source/guides/admin-guides/references/man1/monls.1.rst +++ b/docs/source/guides/admin-guides/references/man1/monls.1.rst @@ -33,7 +33,7 @@ DESCRIPTION *********** -This command is used to list the status, desctiption, the configuration scripts and the settings of one or all of the monitoring plug-in modules. +This command is used to list the status, description, the configuration scripts and the settings of one or all of the monitoring plug-in modules. ********** @@ -49,9 +49,9 @@ OPTIONS ******* -\ **-a | -**\ **-all**\ Searches the \ *XCATROOT/lib/perl/xCAT_monitoring*\ directory and reports all the monitoring plug-in modules. If nothing is specified, the list is read from the \ *monitoring*\ tabel. +\ **-a | -**\ **-all**\ Searches the \ *XCATROOT/lib/perl/xCAT_monitoring*\ directory and reports all the monitoring plug-in modules. If nothing is specified, the list is read from the \ *monitoring*\ table. -\ **-d | -**\ **-description**\ Display the description of the plug-in modules. The description ususally contains the possible settings. +\ **-d | -**\ **-description**\ Display the description of the plug-in modules. The description usually contains the possible settings. \ **-h | -**\ **-help**\ Display usage message. @@ -110,7 +110,7 @@ The output looks like this: nagiosmon not-monitored -3. To list the status and the desciption for \ *snmpmon*\ module, enter: +3. To list the status and the description for \ *snmpmon*\ module, enter: .. code-block:: perl diff --git a/docs/source/guides/admin-guides/references/man1/monshow.1.rst b/docs/source/guides/admin-guides/references/man1/monshow.1.rst index e711239b7..2c8ff130c 100644 --- a/docs/source/guides/admin-guides/references/man1/monshow.1.rst +++ b/docs/source/guides/admin-guides/references/man1/monshow.1.rst @@ -59,7 +59,7 @@ OPTIONS \ **-a**\ specifies a comma-separated list of attributes or metrics names. The default is all. -\ **-w**\ specify one or multiple selection string that can be used to select events. The operators ==, !=, =,!,>,<,>=,<= are available. Wildcards % and _ are supported in the pattern string. % allows you to match any string of any length(including zero length) and _ allows you to match on a single character. The valid attributes are eventtype, monitor, monnode, application, component, id, serverity, message, rawdata, comments. Valid severity are: Informational, Warning, Critical. +\ **-w**\ specify one or multiple selection string that can be used to select events. The operators ==, !=, =,!,>,<,>=,<= are available. Wildcards % and _ are supported in the pattern string. % allows you to match any string of any length(including zero length) and _ allows you to match on a single character. The valid attributes are eventtype, monitor, monnode, application, component, id, severity, message, rawdata, comments. Valid severity are: Informational, Warning, Critical. Operator descriptions: diff --git a/docs/source/guides/admin-guides/references/man1/monstart.1.rst b/docs/source/guides/admin-guides/references/man1/monstart.1.rst index 292c72265..1595b28b8 100644 --- a/docs/source/guides/admin-guides/references/man1/monstart.1.rst +++ b/docs/source/guides/admin-guides/references/man1/monstart.1.rst @@ -39,7 +39,7 @@ PARAMETERS ********** -\ *name*\ is the name of the monitoring plug-in module. For example, if the the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ **monls -a**\ command to list all the monitoring plug-in modules that can be used. +\ *name*\ is the name of the monitoring plug-in module. For example, if the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ **monls -a**\ command to list all the monitoring plug-in modules that can be used. \ *noderange*\ is the nodes to be monitored. If omitted, all nodes will be monitored. diff --git a/docs/source/guides/admin-guides/references/man1/nimnodecust.1.rst b/docs/source/guides/admin-guides/references/man1/nimnodecust.1.rst index 8a82dad79..1fd244764 100644 --- a/docs/source/guides/admin-guides/references/man1/nimnodecust.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nimnodecust.1.rst @@ -57,9 +57,9 @@ To create a NIM installp_bundle definition you can use the "nim -o define" opera nim -o define -t installp_bundle -a server=master -a location=/install/nim/mypkgs.bnd mypackages -See the AIX documantation for more information on using installp_bundle files. +See the AIX documentation for more information on using installp_bundle files. -The xCAT nimnodecust command will automatically handle the distribution of the packages to AIX service nodes when using an xCAT hierachical environment. +The xCAT nimnodecust command will automatically handle the distribution of the packages to AIX service nodes when using an xCAT hierarchical environment. ******* diff --git a/docs/source/guides/admin-guides/references/man1/nimnodeset.1.rst b/docs/source/guides/admin-guides/references/man1/nimnodeset.1.rst index 8c03d0fd7..5f3511342 100644 --- a/docs/source/guides/admin-guides/references/man1/nimnodeset.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nimnodeset.1.rst @@ -33,7 +33,7 @@ This xCAT command can be used to initialize AIX/NIM standalone machines. Once th If you are using xCAT service nodes the \ **nimnodeset**\ command will automatically determine the correct server(s) for the node and do the initialization on that server(s). -The osimage_name is the name of an xCAT osimage definition that contains the list of NIM resources to use when initializing the nodes. If the osimage_name is not provided on the command line the code checks the node definition for the value of the "provmethod" attribute (which is the name of an osimage definition). If the osimage_image is provided on the command line then the code will also set the "provmethod" attribute of the node definiions. +The osimage_name is the name of an xCAT osimage definition that contains the list of NIM resources to use when initializing the nodes. If the osimage_name is not provided on the command line the code checks the node definition for the value of the "provmethod" attribute (which is the name of an osimage definition). If the osimage_image is provided on the command line then the code will also set the "provmethod" attribute of the node definitions. This command will also create a NIM resolv_conf resource to be used when installing the node. If a resolv_conf resource is not already included in the xCAT osimage definition and if the "domain" and "nameservers" values are set then a new NIM resolv_conf resource will be created and allocated to the nodes. @@ -41,7 +41,7 @@ NIM resolv_conf resource will be created and allocated to the nodes. The "domain" and "nameservers" attributes can be set in either the xCAT "network" definition used by the nodes or in the xCAT cluster "site" definition. The setting in the "network" definition will take priority. The "search" field of the resolv.conf file will contain a list all the domains -listed in the xCAT network definitions and the xCAT site definiton. +listed in the xCAT network definitions and the xCAT site definition. The "nameservers" value can either be set to a specific IP address or the "" key word. The "" key word means that the value of the "xcatmaster" attribute of the node definition will be used in the /etc/resolv.conf file. (I.e. The name of the install server as known by the node.) @@ -58,13 +58,13 @@ will be created. You can specify additional attributes and values using the "attr=val" command line option. This information will be passed on to the underlying call to the NIM "nim -o bos_inst" command. See the NIM documentation for information on valid command line options for the nim command. The "attr" must correspond to a NIM attribute supported for the NIM "bos_inst" operation. Information provided by the "attr=val" option will take precedence over the information provided in the osimage definition. -The force option can be used to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinititializing. +The force option can be used to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinitializing. This command will also create a NIM script resource to enable the xCAT support for user-provided customization scripts. After the \ **nimnodeset**\ command completes you can use the \ **lsnim**\ command to check the NIM node definition to see if it is ready for booting the node. ("lsnim -l "). -You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **nimnodeset**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts dirctory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **nimnodeset**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **nimnodeset**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *standalone:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "standalone". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes. +You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **nimnodeset**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts directory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **nimnodeset**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **nimnodeset**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *standalone:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "standalone". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes. ******* @@ -76,7 +76,7 @@ OPTIONS \ *attr=val [attr=val ...]*\ Specifies one or more "attribute equals value" pairs, separated by spaces. Attr= - val pairs must be specified last on the command line. These are used to specify additional values that can be passed to the underlying NIM commands, ("nim -o bos_inst ..."). See the NIM documentation for valid "nim" command line options. Note that you may specify multiple "script" and "installp_bundle" values by using a comma seperated list. (ex. "script=ascript,bscript"). + val pairs must be specified last on the command line. These are used to specify additional values that can be passed to the underlying NIM commands, ("nim -o bos_inst ..."). See the NIM documentation for valid "nim" command line options. Note that you may specify multiple "script" and "installp_bundle" values by using a comma separated list. (ex. "script=ascript,bscript"). @@ -106,8 +106,7 @@ OPTIONS \ **-l|-**\ **-location**\ - The directory location to use when creating new NIM resolv_conf resources. The d - efault location is /install/nim. + The directory location to use when creating new NIM resolv_conf resources. The default location is /install/nim. diff --git a/docs/source/guides/admin-guides/references/man1/nodeaddunmged.1.rst b/docs/source/guides/admin-guides/references/man1/nodeaddunmged.1.rst index 2a7cd8d10..2ce52c742 100644 --- a/docs/source/guides/admin-guides/references/man1/nodeaddunmged.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nodeaddunmged.1.rst @@ -61,7 +61,7 @@ RETURN VALUE 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. ******** diff --git a/docs/source/guides/admin-guides/references/man1/nodechmac.1.rst b/docs/source/guides/admin-guides/references/man1/nodechmac.1.rst index d293bcaea..84a1dce0c 100644 --- a/docs/source/guides/admin-guides/references/man1/nodechmac.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nodechmac.1.rst @@ -63,7 +63,7 @@ RETURN VALUE 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. ******** diff --git a/docs/source/guides/admin-guides/references/man1/nodechprofile.1.rst b/docs/source/guides/admin-guides/references/man1/nodechprofile.1.rst index 1d02e020a..be6b5300e 100644 --- a/docs/source/guides/admin-guides/references/man1/nodechprofile.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nodechprofile.1.rst @@ -79,7 +79,7 @@ RETURN VALUE 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. ******** diff --git a/docs/source/guides/admin-guides/references/man1/nodediscoverls.1.rst b/docs/source/guides/admin-guides/references/man1/nodediscoverls.1.rst index b791d5180..8d1458b64 100644 --- a/docs/source/guides/admin-guides/references/man1/nodediscoverls.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nodediscoverls.1.rst @@ -114,7 +114,7 @@ RETURN VALUE 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. ******** diff --git a/docs/source/guides/admin-guides/references/man1/nodediscoverstart.1.rst b/docs/source/guides/admin-guides/references/man1/nodediscoverstart.1.rst index 35e01991d..2171f8da9 100644 --- a/docs/source/guides/admin-guides/references/man1/nodediscoverstart.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nodediscoverstart.1.rst @@ -59,7 +59,7 @@ When the nodes are discovered, PCM updates the affected configuration files on t When you power on the nodes, they PXE boot and DHCP/TFTP/HTTP on the management node give each node the xCAT genesis boot image, which inventories the node hardware and sends data to the management node. There, either the sequential discovery process or the -profile discovery process assigns node attributes and defines the node in the the database. +profile discovery process assigns node attributes and defines the node in the database. ******* @@ -127,7 +127,7 @@ OPTIONS -\ **chasiss=**\ \ *chassis-name*\ +\ **chassis=**\ \ *chassis-name*\ Sets the chassis name that the Blade server or PureFlex blade is located in, for either the Sequential Discovery or Profile Discovery methods. This option is used for the Blade server and PureFlex system only. You cannot specify this option with the rack option. @@ -196,7 +196,7 @@ RETURN VALUE 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. ******** diff --git a/docs/source/guides/admin-guides/references/man1/nodediscoverstatus.1.rst b/docs/source/guides/admin-guides/references/man1/nodediscoverstatus.1.rst index 279166e08..182800616 100644 --- a/docs/source/guides/admin-guides/references/man1/nodediscoverstatus.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nodediscoverstatus.1.rst @@ -52,7 +52,7 @@ RETURN VALUE 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. ******** diff --git a/docs/source/guides/admin-guides/references/man1/nodediscoverstop.1.rst b/docs/source/guides/admin-guides/references/man1/nodediscoverstop.1.rst index 92e5ce339..f95b1b43f 100644 --- a/docs/source/guides/admin-guides/references/man1/nodediscoverstop.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nodediscoverstop.1.rst @@ -53,7 +53,7 @@ RETURN VALUE 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. ******** diff --git a/docs/source/guides/admin-guides/references/man1/nodeimport.1.rst b/docs/source/guides/admin-guides/references/man1/nodeimport.1.rst index 27341b4e8..ccd2a8ab9 100644 --- a/docs/source/guides/admin-guides/references/man1/nodeimport.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nodeimport.1.rst @@ -29,7 +29,7 @@ DESCRIPTION *********** -The \ **nodeimport**\ command creates nodes by importing a hostinfo file which is following stanza format. In this hostinfo file, we can define node's hostname, ip, mac, switch name, switch port and host location infomation like rack, chassis, start unit, server height...etc +The \ **nodeimport**\ command creates nodes by importing a hostinfo file which is following stanza format. In this hostinfo file, we can define node's hostname, ip, mac, switch name, switch port and host location information like rack, chassis, start unit, server height...etc After nodes imported, the configuration files related with these nodes will be updated automatically. For example: /etc/hosts, dns configuration, dhcp configuration. And the kits node plugins will also be triggered automatically to update kit related configuration/services. @@ -83,9 +83,9 @@ RETURN VALUE 0 The command completed successfully. -1 An error has occured while validating parameters. +1 An error has occurred while validating parameters. -2 An error has occured while parsing hostinfo file. +2 An error has occurred while parsing hostinfo file. ******** @@ -143,7 +143,7 @@ To import nodes using a profile, follow the following steps: # hostinfo end. - Another example of a node infomation file, a PureFlex X/P node defined: + Another example of a node information file, a PureFlex X/P node defined: # hostinfo begin # To define a PureFlex P/X node, chassis and slot id must be specified. # The chassis must be a PureFlex chassis. @@ -191,7 +191,7 @@ Description: The name of the node, where __hostname__ is automatically generated \ **mac= This is a mandatory item. -Description: Specify the MAC address for the NIC used by the provisionging node, where is the NICs MAC address. +Description: Specify the MAC address for the NIC used by the provisioning node, where is the NICs MAC address. \ **switches= This is a mandatory item, when define switch, switchport and node nic name relationship. @@ -221,9 +221,9 @@ Description: Lists the IP address for each network interface configuration (NIC) Description: node location info. Specify the rack name which this node will be placed into. If not specify this item, there will be no node location info set for this node. this item must be specified together with height + unit. -\ **chasiss= This is an optional item. +\ **chassis= This is an optional item. -Description: node location info, for blade(or PureFlex) only. Specify the chasiss name which this blade will be placed into. this item can not be specified together with rack. +Description: node location info, for blade(or PureFlex) only. Specify the chassis name which this blade will be placed into. this item can not be specified together with rack. \ **height= This is an optional item. diff --git a/docs/source/guides/admin-guides/references/man1/nodels.1.rst b/docs/source/guides/admin-guides/references/man1/nodels.1.rst index 692331e73..395c72848 100644 --- a/docs/source/guides/admin-guides/references/man1/nodels.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nodels.1.rst @@ -109,7 +109,7 @@ OPTIONS \ **-b|-**\ **-blame**\ - For values inherited from groups, display which groups provided the inheritence + For values inherited from groups, display which groups provided the inheritance diff --git a/docs/source/guides/admin-guides/references/man1/nodepurge.1.rst b/docs/source/guides/admin-guides/references/man1/nodepurge.1.rst index c11871cdc..847eb6c7b 100644 --- a/docs/source/guides/admin-guides/references/man1/nodepurge.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nodepurge.1.rst @@ -59,7 +59,7 @@ RETURN VALUE 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. ******** diff --git a/docs/source/guides/admin-guides/references/man1/noderefresh.1.rst b/docs/source/guides/admin-guides/references/man1/noderefresh.1.rst index 5eabc41af..7f110d908 100644 --- a/docs/source/guides/admin-guides/references/man1/noderefresh.1.rst +++ b/docs/source/guides/admin-guides/references/man1/noderefresh.1.rst @@ -57,7 +57,7 @@ RETURN VALUE 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. ******** diff --git a/docs/source/guides/admin-guides/references/man1/nodestat.1.rst b/docs/source/guides/admin-guides/references/man1/nodestat.1.rst index f51b0d015..8d3afd684 100644 --- a/docs/source/guides/admin-guides/references/man1/nodestat.1.rst +++ b/docs/source/guides/admin-guides/references/man1/nodestat.1.rst @@ -63,7 +63,7 @@ Keywords to use: port -- the application daemon port number, if not specified, use internal list, then /etc/services. group -- the name of a node group that needs to get the application status from. If not specified, assume all the nodes in the nodelist table. To specify more than one groups, use group=a,group=b format. cmd -- the command that will be run locally on mn or sn. - lcmd -- the command that will be run the the mn only. + lcmd -- the command that will be run the mn only. dcmd -- the command that will be run distributed on the nodes using xdsh .... @@ -94,7 +94,7 @@ For the command specified by 'dcmd', no input is needed, the output can be a str \ **-m | -**\ **-usemon**\ - Uses the settings from the \ **monsetting**\ talbe to determine a list of applications that need to get status for. + Uses the settings from the \ **monsetting**\ table to determine a list of applications that need to get status for. diff --git a/docs/source/guides/admin-guides/references/man1/piflash.1.rst b/docs/source/guides/admin-guides/references/man1/piflash.1.rst new file mode 100644 index 000000000..1959a893e --- /dev/null +++ b/docs/source/guides/admin-guides/references/man1/piflash.1.rst @@ -0,0 +1,23 @@ + +######### +piflash.1 +######### + +.. highlight:: perl + + +******** +SYNOPSIS +******** + + +\ **piflash**\ -**\ **-package + + +*********** +DESCRIPTION +*********** + + +\ **piflash**\ Remotely applies firmware updates to servers. + diff --git a/docs/source/guides/admin-guides/references/man1/rflash.1.rst b/docs/source/guides/admin-guides/references/man1/rflash.1.rst index 47b35ae06..087047ab6 100644 --- a/docs/source/guides/admin-guides/references/man1/rflash.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rflash.1.rst @@ -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 running \ **rflash**\ , use \ **rspconfig**\ to check if the related HMC ssh is enabled. To enable a HMC ssh connection, 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**\ command. \ **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. @@ -83,7 +83,7 @@ The flash chip of a POWER5 and POWER6 managed system or power subsystem stores f The \ **-**\ **-commit**\ flag is used to write the contents of the temporary side of the flash to the permanent side. This flag should be used after updating code and verifying correct system operation. The \ **-**\ **-recover**\ flag is used to write the permanent side of the flash chip back to the temporary side. This flag should be used to recover from a corrupt flash operation, so that the previously running code can be restored. -\ **NOTE:**\ When the \ **-**\ **-commit**\ or \ **-**\ **-recover**\ two flags is used, the noderange \ **cannot**\ be BPA. It only \ **can**\ be CEC or LPAR ,and will take effect for \ **both**\ managed systems and power subsystems. +\ **NOTE:**\ When the \ **-**\ **-commit**\ or \ **-**\ **-recover**\ two flags is used, the noderange \ **cannot**\ be BPA. It only \ **can**\ be CEC or LPAR, and will take effect for \ **both**\ managed systems and power subsystems. xCAT recommends that you shutdown your Operating System images and power off your managed systems before applying disruptive updates to managed systems or power subsystems. @@ -104,7 +104,7 @@ The \ **deferred**\ option will load the new firmware into the T (temp) side, b In Direct FSP/BPA Management, there is \ **-d**\ \ *data_directory*\ option. The default value is /tmp. When doing firmware update, \ **rflash**\ will put some related data from rpm packages in directory, so the execution of \ **rflash**\ will require available disk space in for the command to properly execute: -For one GFW rpm package and one power code rpm package , if the GFW rpm package size is gfw_rpmsize, and the Power code rpm package size is power_rpmsize, it requires that the available disk space should be more than: 1.5\*gfw_rpmsize + 1.5\*power_rpmsize +For one GFW rpm package and one power code rpm package, if the GFW rpm package size is gfw_rpmsize, and the Power code rpm package size is power_rpmsize, it requires that the available disk space should be more than: 1.5\*gfw_rpmsize + 1.5\*power_rpmsize For Power 775, the \ **rflash**\ command takes effect on the primary and secondary FSPs or BPAs almost in parallel. @@ -115,7 +115,7 @@ NeXtScale FPC specific: ======================= -The command will update firmware for NeXtScale FPC when given an FPC node and the http information needed to access the firmware. The http imformation required includes both the MN IP address as well as the directory containing the firmware. It is recommended that the firmware be downloaded and placed in the /install directory structure as the xCAT MN /install directory is configured with the correct permissions for http. Refer to the doc to get more details: XCAT_NeXtScale_Clusters +The command will update firmware for NeXtScale FPC when given an FPC node and the http information needed to access the firmware. The http information required includes both the MN IP address as well as the directory containing the firmware. It is recommended that the firmware be downloaded and placed in the /install directory structure as the xCAT MN /install directory is configured with the correct permissions for http. Refer to the doc to get more details: XCAT_NeXtScale_Clusters OpenPOWER specific: @@ -140,7 +140,7 @@ The command will update firmware for OpenPOWER BMC when given an OpenPOWER node \ **-c|-**\ **-check**\ - Chech the firmware version of BMC and HPM file. + Check the firmware version of BMC and HPM file. @@ -209,7 +209,7 @@ The command will update firmware for OpenPOWER BMC when given an OpenPOWER node -1. To update only the power subsystem attached to a single HMC-attached pSeries CEC(cec_name), and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter: +1. To update only the power subsystem attached to a single HMC-attached pSeries CEC(cec_name), and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter: .. code-block:: perl @@ -219,7 +219,7 @@ The command will update firmware for OpenPOWER BMC when given an OpenPOWER node -2. To update only the power subsystem attached to a single HMC-attached pSeries node, and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter: +2. To update only the power subsystem attached to a single HMC-attached pSeries node, and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter: .. code-block:: perl @@ -239,7 +239,7 @@ The command will update firmware for OpenPOWER BMC when given an OpenPOWER node -4. To update the firmware on a NeXtScale FPC specify the FPC node name and the HTTP location of the file including the xCAT MN IP address and the directory on the xCAT MN containing the firmware as follows: +4. To update the firmware on a NeXtScale FPC specify the FPC node name and the HTTP location of the file including the xCAT MN IP address and the directory on the xCAT MN containing the firmware as follows: .. code-block:: perl diff --git a/docs/source/guides/admin-guides/references/man1/rinv.1.rst b/docs/source/guides/admin-guides/references/man1/rinv.1.rst index 9d44f4377..d760fc576 100644 --- a/docs/source/guides/admin-guides/references/man1/rinv.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rinv.1.rst @@ -25,21 +25,21 @@ BMC/MPA specific: ================= -\ **rinv**\ \ *noderange*\ {\ **pci | model | serial | asset | vpd | mprom | deviceid | guid | firm | diag | dimm | bios | mparom | mac | all**\ } +\ **rinv**\ \ *noderange*\ [\ **model | serial | asset | vpd | deviceid | guid | firm | dimm | mprom | all**\ ] -OpenPOWER (using ipmi) server specific: -======================================= +OpenPOWER (IPMI) server specific: +================================= -\ **rinv**\ \ *noderange*\ {\ **model | serial | deviceid | uuid | guid | vpd | mprom | firm | all**\ } +\ **rinv**\ \ *noderange*\ [\ **model | serial | deviceid | uuid | guid | vpd | mprom | firm | all**\ ] -OpenPOWER (using openbmc) server specific: -========================================== +OpenPOWER (OpenBMC) server specific: +==================================== -\ **rinv**\ \ *noderange*\ {\ **model | serial | deviceid | uuid | guid | vpd | mprom | firm | cpu | dimm | all**\ } +\ **rinv**\ \ *noderange*\ [\ **model | serial | firm | cpu | dimm | all**\ ] [\ **-V | -**\ **-verbose**\ ] PPC (with HMC) specific: @@ -114,10 +114,10 @@ zVM specific: ******************* -\ **rinv**\ retrieves hardware configuration information from the on-board +\ **rinv**\ retrieves hardware configuration information from the on-board Service Processor for a single or range of nodes and groups. -Calling \ **rinv**\ for VMware will display the UUID/GUID, nuumber of CPUs, amount of memory, the MAC address and a list of Hard disks. The output for each Hard disk includes the label, size and backing file location. +Calling \ **rinv**\ for VMware will display the UUID/GUID, number of CPUs, amount of memory, the MAC address and a list of Hard disks. The output for each Hard disk includes the label, size and backing file location. *************** @@ -126,12 +126,6 @@ Calling \ **rinv**\ for VMware will display the UUID/GUID, nuumber of CPUs, amo -\ **pci**\ - - Retrieves PCI bus information. - - - \ **bus**\ List all buses for each I/O slot. @@ -140,8 +134,7 @@ Calling \ **rinv**\ for VMware will display the UUID/GUID, nuumber of CPUs, amo \ **config**\ - Retrieves number of processors, speed, total memory, and DIMM - locations. + Retrieves number of processors, speed, total memory, and DIMM locations. @@ -177,7 +170,7 @@ Calling \ **rinv**\ for VMware will display the UUID/GUID, nuumber of CPUs, amo \ **asset**\ - Retrieves asset tag. Usually it's the MAC address of eth0. + Retrieves asset tag. Usually it's the MAC address of eth0. @@ -195,25 +188,31 @@ Calling \ **rinv**\ for VMware will display the UUID/GUID, nuumber of CPUs, amo \ **mprom**\ - Retrieves mprom firmware level + Retrieves mprom firmware level. + + + +\ **dimm**\ + + Retrieves dual in-line memory module information. \ **deviceid**\ - Retrieves device identification. Usually device, manufacturing and product ids. + Retrieves device identification. Usually device, manufacturing and product IDs. \ **uuid**\ - Retrieves the universally unique identifier + Retrieves the universally unique identifier. \ **guid**\ - Retrieves the global unique identifier + Retrieves the global unique identifier . @@ -235,6 +234,12 @@ Calling \ **rinv**\ for VMware will display the UUID/GUID, nuumber of CPUs, amo +\ **-V | -**\ **-verbose**\ + + Prints verbose output, if available. + + + \ **-t**\ Set the values in the vm table to what vCenter has for the indicated nodes. diff --git a/docs/source/guides/admin-guides/references/man1/rmdocker.1.rst b/docs/source/guides/admin-guides/references/man1/rmdocker.1.rst index 33db44ce4..db021f2a9 100644 --- a/docs/source/guides/admin-guides/references/man1/rmdocker.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rmdocker.1.rst @@ -48,7 +48,7 @@ EXAMPLES .. code-block:: perl rmdocker host01c01 - host01c01: Disconnect customzied network 'mynet0' done + host01c01: Disconnect customized network 'mynet0' done host01c01: success diff --git a/docs/source/guides/admin-guides/references/man1/rmdsklsnode.1.rst b/docs/source/guides/admin-guides/references/man1/rmdsklsnode.1.rst index 1ad0c3b3e..b9dd2625d 100644 --- a/docs/source/guides/admin-guides/references/man1/rmdsklsnode.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rmdsklsnode.1.rst @@ -39,11 +39,11 @@ If the node you are trying to remove is currently running the \ **rmdsklsnode**\ \ **Removing alternate NIM client definitions**\ -If you used the "-n" option when you created the NIM client definitions with the \ **mkdsklsnode**\ command then the NIM client machine names would be a combination of the xCAT node name and the osimage name used to initialize the NIM machine. To remove these definitions you must provide the name of the osimage that was used using the "-i" option. +If you used the "-n" option when you created the NIM client definitions with the \ **mkdsklsnode**\ command then the NIM client machine names would be a combination of the xCAT node name and the osimage name used to initialize the NIM machine. To remove these definitions, you must provide the name of the osimage that was used using the "-i" option. -In most cases you would most likely want to remove the old client definitions without disturbing the nodes that you just booted with the new alternate client definition. The \ **rmdsklsnode -r**\ option can be used to remove the old alternate client defintions without stopping the running node. +In most cases you would most likely want to remove the old client definitions without disturbing the nodes that you just booted with the new alternate client definition. The \ **rmdsklsnode -r**\ option can be used to remove the old alternate client definitions without stopping the running node. -However, if you have NIM dump resources assign to your nodes be aware that when the old NIM alternate client definitions are removed it will leave the nodes unable to produce a system dump. This is a current limitation in the NIM support for alternate client definitions. For this reason it is recommended that you wait to do this cleanup until right before you do your next upgrade. +However, if you have NIM dump resources assign to your nodes be aware that when the old NIM alternate client definitions are removed it will leave the nodes unable to produce a system dump. This is a current limitation in the NIM support for alternate client definitions. For this reason, it is recommended that you wait to do this cleanup until right before you do your next upgrade. ******* @@ -60,8 +60,7 @@ OPTIONS \ **-b |-**\ **-backupSN**\ - When using backup service nodes only update the backup. The default is to updat - e both the primary and backup service nodes. + When using backup service nodes only update the backup. The default is to update both the primary and backup service nodes. @@ -85,8 +84,7 @@ OPTIONS \ **-p|-**\ **-primarySN**\ - When using backup service nodes only update the primary. The default is to upda - te both the primary and backup service nodes. + When using backup service nodes only update the primary. The default is to update both the primary and backup service nodes. diff --git a/docs/source/guides/admin-guides/references/man1/rmhwconn.1.rst b/docs/source/guides/admin-guides/references/man1/rmhwconn.1.rst index 1edd0ad07..225bb4627 100644 --- a/docs/source/guides/admin-guides/references/man1/rmhwconn.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rmhwconn.1.rst @@ -52,7 +52,7 @@ DESCRIPTION For PPC (with HMC) specific: -This command is used to disconnect CEC and Frame nodes from HMC nodes, according to the connection information defined in ppc talbe in xCAT DB. +This command is used to disconnect CEC and Frame nodes from HMC nodes, according to the connection information defined in ppc table in xCAT DB. Note: If a CEC belongs to a frame with a BPA installed, this CEC cannot be disconnected individually. Instead, the whole frame should be disconnected. diff --git a/docs/source/guides/admin-guides/references/man1/rmigrate.1.rst b/docs/source/guides/admin-guides/references/man1/rmigrate.1.rst index d6b67dfcb..c76a6584e 100644 --- a/docs/source/guides/admin-guides/references/man1/rmigrate.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rmigrate.1.rst @@ -88,7 +88,7 @@ zVM specific: \ **vm**\ table - -Table governing VM paramaters. See vm(5)|vm.5 for further details. +Table governing VM parameters. See vm(5)|vm.5 for further details. This is used to determine the current host to migrate from. diff --git a/docs/source/guides/admin-guides/references/man1/rmkitcomp.1.rst b/docs/source/guides/admin-guides/references/man1/rmkitcomp.1.rst index 675774440..183372691 100644 --- a/docs/source/guides/admin-guides/references/man1/rmkitcomp.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rmkitcomp.1.rst @@ -29,7 +29,7 @@ DESCRIPTION *********** -The \ **rmkitcomp**\ command removes kit components from an xCAT osimage. All the kit component attribute values that are contained in the osimage will be removed, and the kit comoponent meta rpm and package rpm could be uninstalled by \ **-u|-**\ **-uninstall**\ option. +The \ **rmkitcomp**\ command removes kit components from an xCAT osimage. All the kit component attribute values that are contained in the osimage will be removed, and the kit component meta rpm and package rpm could be uninstalled by \ **-u|-**\ **-uninstall**\ option. Note: The xCAT support for Kits is only available for Linux operating systems. diff --git a/docs/source/guides/admin-guides/references/man1/rmvm.1.rst b/docs/source/guides/admin-guides/references/man1/rmvm.1.rst index f3fc52f98..39a083ec7 100644 --- a/docs/source/guides/admin-guides/references/man1/rmvm.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rmvm.1.rst @@ -65,7 +65,7 @@ OPTIONS \ **-**\ **-service**\ Remove the service partitions of the specified CECs. -\ **-p**\ KVM: Purge the existence of the VM from persistant storage. This will erase all storage related to the VM in addition to removing it from the active virtualization configuration. PPC: Remove the specified partiton on normal power machine. +\ **-p**\ KVM: Purge the existence of the VM from persistent storage. This will erase all storage related to the VM in addition to removing it from the active virtualization configuration. PPC: Remove the specified partition on normal power machine. \ **-f**\ Force remove the VM, even if the VM appears to be online. This will bring down a live VM if requested. diff --git a/docs/source/guides/admin-guides/references/man1/rnetboot.1.rst b/docs/source/guides/admin-guides/references/man1/rnetboot.1.rst index 90cc2f5fe..866e10306 100644 --- a/docs/source/guides/admin-guides/references/man1/rnetboot.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rnetboot.1.rst @@ -66,11 +66,11 @@ Note: if the "val" fields includes spaces or any other characters that will be p \ **-r**\ -specify the number of retries that the monitoring process will perform before declare the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag. +specify the number of retries that the monitoring process will perform before declaring the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag. \ **-t**\ -Specify the the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified. +Specify the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified. \ **-V|-**\ **-verbose**\ diff --git a/docs/source/guides/admin-guides/references/man1/rpower.1.rst b/docs/source/guides/admin-guides/references/man1/rpower.1.rst index 74dcc3cac..414471bd5 100644 --- a/docs/source/guides/admin-guides/references/man1/rpower.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rpower.1.rst @@ -32,7 +32,7 @@ BMC (using IPMI): \ **rpower**\ \ *noderange*\ [\ **pduon | pduoff | pdustat | pdureset**\ ] -OpenPower BMC (using IPMI): +OpenPOWER BMC (using IPMI): =========================== @@ -41,7 +41,7 @@ OpenPower BMC (using IPMI): \ **rpower**\ \ *noderange*\ [\ **pduon | pduoff | pdustat | pdureset**\ ] -OpenPower OpenBMC: +OpenPOWER OpenBMC: ================== @@ -181,7 +181,7 @@ OPTIONS \ **resetsp**\ - Reboot the service processor. If there are primary and secondary FSPs/BPAs of one cec/frame, it will reboot them almost at the sametime. + Reboot the service processor. If there are primary and secondary FSPs/BPAs of one cec/frame, it will reboot them almost at the same time. @@ -320,13 +320,13 @@ OPTIONS \ **-r**\ \ *retrycount*\ - specify the number of retries that the monitoring process will perform before declare the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag. + specify the number of retries that the monitoring process will perform before declaring the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag. \ **-t**\ \ *timeout*\ - Specify the the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified. + Specify the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified. Power off, then on. diff --git a/docs/source/guides/admin-guides/references/man1/rspconfig.1.rst b/docs/source/guides/admin-guides/references/man1/rspconfig.1.rst index 9660a425d..c2165234b 100644 --- a/docs/source/guides/admin-guides/references/man1/rspconfig.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rspconfig.1.rst @@ -564,7 +564,7 @@ OPTIONS \ **USERID**\ ={\ *newpasswd*\ } \ **updateBMC**\ ={\ **y|n**\ } - Change the password of the userid \ **USERID**\ for CMM in Flex system cluster. The option \ *updateBMC*\ can be used to specify whether updating the password of BMCs that connected to the speified CMM. The value is 'y' by default which means whenever updating the password of CMM, the password of BMCs will be also updated. Note that there will be several seconds needed before this command complete. + Change the password of the userid \ **USERID**\ for CMM in Flex system cluster. The option \ *updateBMC*\ can be used to specify whether updating the password of BMCs that connected to the specified CMM. The value is 'y' by default which means whenever updating the password of CMM, the password of BMCs will be also updated. Note that there will be several seconds needed before this command complete. If value "\*" is specified for USERID and the object node is \ *Flex System X node*\ , the password used to access the BMC of the System X node through IPMI will be updated as the same password of the userid \ **USERID**\ of the CMM in the same cluster. diff --git a/docs/source/guides/admin-guides/references/man1/rvitals.1.rst b/docs/source/guides/admin-guides/references/man1/rvitals.1.rst index e6929cdfc..7fa7e62d6 100644 --- a/docs/source/guides/admin-guides/references/man1/rvitals.1.rst +++ b/docs/source/guides/admin-guides/references/man1/rvitals.1.rst @@ -56,11 +56,18 @@ BMC specific: \ **rvitals**\ \ *noderange*\ {\ **temp | voltage | wattage | fanspeed | power | leds | all**\ } -OpenPOWER server specific: +OpenPOWER (IPMI) specific: ========================== -\ **rvitals**\ \ *noderange*\ [\ **temp | voltage | wattage | fanspeed | power | leds | all**\ ] +\ **rvitals**\ \ *noderange*\ [\ **temp | voltage | wattage | fanspeed | power | leds | chassis | all**\ ] + + +OpenPOWER (OpenBMC) specific: +============================= + + +\ **rvitals**\ \ *noderange*\ [\ **temp | voltage | wattage | fanspeed | power | altitude | all**\ ] @@ -69,7 +76,7 @@ OpenPOWER server specific: ******************* -\ **rvitals**\ retrieves hardware vital information from the on-board Service +\ **rvitals**\ Retrieves hardware vital information from the on-board Service Processor for a single or range of nodes and groups. @@ -133,6 +140,18 @@ Processor for a single or range of nodes and groups. +\ **chassis**\ + + Retrieves chassis status. + + + +\ **altitude**\ + + Retrieves altitude related attributes. + + + \ **power**\ Retrieves power status. diff --git a/docs/source/guides/admin-guides/references/man1/sinv.1.rst b/docs/source/guides/admin-guides/references/man1/sinv.1.rst index f1274c9d6..11a98a55b 100644 --- a/docs/source/guides/admin-guides/references/man1/sinv.1.rst +++ b/docs/source/guides/admin-guides/references/man1/sinv.1.rst @@ -19,7 +19,7 @@ sinv.1 **************** -\ **sinv**\ [\ **-o**\ \ *output*\ ] [\ **-p**\ \ *template path*\ ] [\ **-t**\ \ *template count*\ ] [\ **-s**\ \ *seed node*\ ] [\ **-i**\ ] [\ **-e**\ ] [\ **-r**\ ] [\ **-V**\ ] [\ **-**\ **-devicetype**\ \ *type_of_device*\ ] [\ **-l**\ \ *userID*\ ] [[\ **-f**\ \ *command file*\ ] | [\ **-c**\ \ *command*\ ]] +\ **sinv**\ [\ **-o**\ \ *output*\ ] \ **-p**\ \ *template path*\ [\ **-t**\ \ *template count*\ ] [\ **-s**\ \ *seed node*\ ] [\ **-i**\ ] [\ **-e**\ ] [\ **-r**\ ] [\ **-V**\ ] [\ **-**\ **-devicetype**\ \ *type_of_device*\ ] [\ **-l**\ \ *userID*\ ] {\ **-f**\ \ *command file*\ | \ **-c**\ \ *command*\ } \ **sinv**\ [\ **-h**\ | \ **-v**\ ] @@ -30,9 +30,9 @@ sinv.1 The \ **sinv**\ command is designed to check the configuration of the nodes in a cluster. -The command takes as input command line flags, and one or more templates which will be compared against the output of the xdsh command, designated to be run by the -c or -f flag, on the nodes in the noderange. +The command takes as input command line flags, and one or more templates which will be compared against the output of the \ **xdsh**\ command, designated to be run by the \ **-c**\ or \ **-f**\ flag, on the nodes in the noderange. -The nodes will then be grouped according to the template they match and a report returned to the administrator in the output file designated by the -o flag, or to stdout. +The nodes will then be grouped according to the template they match and a report returned to the administrator in the output file designated by the \ **-o**\ flag, or to stdout. \ **sinv**\ supports checking the output from the \ **rinv**\ or \ **xdsh**\ command. @@ -40,13 +40,13 @@ The \ **sinv**\ command is an xCAT Distributed Shell Utility. \ **COMMAND**\ \ **SPECIFICATION**\ : -The xdsh or rinv command to execute on the remote targets is specified by the \ **-c**\ flag, or by the \ **-f**\ flag +The \ **xdsh**\ or \ **rinv**\ command to execute on the remote targets is specified by the \ **-c**\ flag, or by the \ **-f**\ flag which is followed by the fully qualified path to a file containing the command. -Note: do not add | xdshcoll to the command on the command line or in the -command file, it is automatically added by sinv. +Note: do not add \ **| xdshcoll**\ to the command on the command line or in the +command file, it is automatically added by \ **sinv**\ . -The syntax for the \ **-c**\ \ **sinv**\ parameter is as follows: +The syntax for the \ **-c**\ parameter is as follows: "\ *command*\ [; \ *command*\ ]..." @@ -60,9 +60,9 @@ those that read from standard input. \ **REMOTE**\ \ **SHELL**\ \ **COMMAND**\ : -For xdsh, support is explicitly provided -for AIX Remote Shell and OpenSSH, but any secure remote command that -conforms to the IETF (Internet Engineering Task Force) Secure Remote +For \ **xdsh**\ , support is explicitly provided +for AIX Remote Shell and OpenSSH, but any secure remote command that +conforms to the IETF (Internet Engineering Task Force) Secure Remote Command Protocol can be used. See man \ **xdsh**\ for more details. @@ -74,32 +74,28 @@ Command Protocol can be used. See man \ **xdsh**\ for more details. \ **-o | -**\ **-output**\ \ *report output file*\ - Optional output file. This is the location of the file that will contain the report of the nodes that match, and do not match, the input templates. - If the flag is not used, the output will go to stdout. + Optional output file. This is the location of the file that will contain the report of the nodes that match, and do not match, the input templates. If the flag is not used, the output will go to stdout. \ **-p | -**\ **-tp**\ \ *template path*\ This is the path to the template file. The template contains the output - of xdsh command, that has been run against a "seed" node, a node - that contains the configuration that you would like - all nodes in your noderange to match. + of \ **xdsh**\ or \ **rinv**\ command, that has been run against a "seed" node, a node + that contains the configuration that you would like all nodes in your noderange to match. - The admin can create the template by running the xdsh command on - the seed node, pipe to xdshcoll ( required) and store the output + The admin can create the template by running the \ **xdsh**\ or \ **rinv**\ command on + the seed node, pipe to \ **xdshcoll**\ (required) and store the output in the template path. See examples. - \ **Note:**\ The admin can also edit the - template to remove any lines that they do not want checked. + \ **Note:**\ The admin can also edit the template to remove any lines that they do not want checked. An alternative method is to use the [\ **-s**\ \ *seed node*\ ] parameter, which will automatically build the template for you from the seed node named. - If a template path file does not exist, and a seed node is not input, - then sinv will automatically use the one node in the noderange as - the seed node and build the template. + If a a seed node is not provided, then command will automatically use the first node in the noderange as + the seed node. @@ -107,7 +103,7 @@ Command Protocol can be used. See man \ **xdsh**\ for more details. This count is the number of templates that the command will use to check for nodes matches. If the template in the template path does not - match a node, the \ **sinv**\ will check additional templates up + match a node, the \ **sinv**\ will check additional templates up to the template count. For each node, it will compare the node against each template to see if @@ -116,7 +112,7 @@ Command Protocol can be used. See man \ **xdsh**\ for more details. then a new template will be created from the node output. This will result in having all nodes that match a given template reported in their group at the end of the run in the output file. - If no template count is specified, 0 is the default, and all nodes will + If no template count is specified, 0 is the default, and all nodes will be compared against the first template. @@ -127,9 +123,8 @@ Command Protocol can be used. See man \ **xdsh**\ for more details. that is stored in template path. You can use this parameter instead of running the command yourself to build the template. - \ **Note:**\ If the template path file does not exists, and no seed node is - supplied, the seed node automatically is one node in the - noderange. + \ **Note:**\ If no seed node is supplied, the first node in the noderange is automatically + selected as a seed node. @@ -147,12 +142,12 @@ Command Protocol can be used. See man \ **xdsh**\ for more details. This requires the check of node output against template to be an exact match. If this flag is not set, \ **sinv**\ checks to see if the return from the - xdsh command to the nodes contain a match for each line in the input + \ **xdsh**\ or \ **rinv**\ command to the nodes contain a match for each line in the input template (except for xdshcoll header and comments). If not in exactmatch mode, - there can exist more lines in the xdsh return from the nodes. + there can be more lines in the \ **xdsh**\ or \ **rinv**\ return from the nodes. For example, if running a "rpm -qa | grep xCAT" command, without exactmatch - set, if the node containes more xCAT rpms that listed in the template, + set, if the node contains more xCAT rpms that listed in the template, it would be considered a match, as long as all rpms listed in the template were on the node. With exactmatch set, the output must be identical to the template. @@ -165,7 +160,7 @@ Command Protocol can be used. See man \ **xdsh**\ for more details. of relevant device configuration file. The devicetype value must correspond to a valid device configuration file. xCAT ships some default configuration files - for Ethernet switches and and IB switches under + for Ethernet switches and IB switches under \ */opt/xcat/share/xcat/devicetype*\ directory. If you want to overwrite any of the configuration files, copy them to \ */var/opt/xcat/*\ directory and cutomize. @@ -185,21 +180,21 @@ Command Protocol can be used. See man \ **xdsh**\ for more details. \ **-c | -**\ **-command**\ - The xdsh or rinv command that will be run. The command should be enclosed in - double quotes to insure correct shell interpretation. This parameter must only contain, the node range or the image path (Linux) or spot name for AIX. It cannot be used to set additional input flags to xdsh or rinv (for example -s,-T,-e). See examples below. + The \ **xdsh**\ or \ **rinv**\ command that will be run. The command should be enclosed in + double quotes to insure correct shell interpretation. This parameter must only contain, the node range or the image path (Linux) or spot name for AIX. It cannot be used to set additional input flags to \ **xdsh**\ or \ **rinv**\ (for example \ **-s**\ ,\ **-T**\ ,\ **-e**\ ). See examples below. - \ **Note:**\ do not add the | xdshcoll to the command, - it is automatically added by sinv. sinv also automatically sets the -v flag for xdsh. + \ **Note:**\ do not add the \ **| xdshcoll**\ to the command, + it is automatically added by \ **sinv**\ . \ **sinv**\ also automatically sets the \ **-v**\ flag for \ **xdsh**\ . \ **-f | -**\ **-file**\ - The file containing the xdsh or rinv command that will be run. + The file containing the \ **xdsh**\ or \ **rinv**\ command that will be run. This should be the fully qualified name of the file. - \ **Note:**\ do not add the | xdshcoll to the command in the file, - it is automatically added by sinv. + \ **Note:**\ do not add the \ **| xdshcoll**\ to the command in the file, + it is automatically added by \ **sinv**\ . @@ -208,11 +203,11 @@ Command Protocol can be used. See man \ **xdsh**\ for more details. This flag indicates that generated templates should be removed at the at the end of the \ **sinv**\ command execution. - If the flag is input, then all templates that are generated by the \ **sinv**\ + If the flag is specified, then all templates that are generated by the \ **sinv**\ command, will be removed. If the first template is created by the admin, it will not be removed. - If the flag is not input, no + If the flag is not specified, no templates will be removed. It is up to the admin to cleanup templates. @@ -242,7 +237,7 @@ Command Protocol can be used. See man \ **xdsh**\ for more details. -1. To setup sinv.template (name optional) for input to the \ **sinv**\ command , enter: +1. To setup sinv.template (name optional) for input to the \ **sinv**\ command, enter: .. code-block:: perl @@ -250,7 +245,7 @@ Command Protocol can be used. See man \ **xdsh**\ for more details. xdsh node1,node2 "rpm -qa | grep ssh " | xdshcoll > /tmp/sinv.template - Note: when setting up the template the output of xdsh must be piped to xdshcoll, sinv processing depends on it. + Note: when setting up the template the output of \ **xdsh**\ must be piped to \ **xdshcoll**\ , \ **sinv**\ processing depends on it. @@ -262,12 +257,12 @@ Command Protocol can be used. See man \ **xdsh**\ for more details. rinv node1-node2 serial | xdshcoll > /tmp/rinv.template - Note: when setting up the template the output of rinv must be piped to xdshcoll, sinv processing depends on it. + Note: when setting up the template the output of \ **rinv**\ must be piped to \ **xdshcoll**\ , \ **sinv**\ processing depends on it. 3. To execute \ **sinv**\ using the sinv.template generated above -on the nodegroup, \ **testnodes**\ ,possibly generating up to two +on the nodegroup, \ *testnodes*\ ,possibly generating up to two new templates, and removing all generated templates in the end, and writing output report to /tmp/sinv.output, enter: @@ -277,12 +272,12 @@ output report to /tmp/sinv.output, enter: sinv -c "xdsh testnodes rpm -qa | grep ssh" -p /tmp/sinv.template -t 2 -r -o /tmp/sinv.output - Note: do not add the pipe to xdshcoll on the -c flag, it is automatically added by the sinv routine. + Note: do not add the pipe to \ **xdshcoll**\ on the \ **-c**\ flag, it is automatically added by the \ **sinv**\ . -4. To execute \ **sinv**\ on noderange, node1-node4, using the seed node, node8, -to generate the first template, using the xdsh command (-c), +4. To execute \ **sinv**\ on noderange, \ *node1-node4*\ , using the seed node, \ *node8*\ , +to generate the first template, using the \ **xdsh**\ command (\ **-c**\ ), possibly generating up to two additional templates and not removing any templates at the end, enter: @@ -294,8 +289,8 @@ templates and not removing any templates at the end, enter: -5. To execute \ **sinv**\ on noderange, node1-node4, using the seed node, node8, -to generate the first template, using the rinv command (-c), +5. To execute \ **sinv**\ on noderange, \ *node1-node4*\ , using the seed node, \ *node8*\ , +to generate the first template, using the \ **rinv**\ command (\ **-c**\ ), possibly generating up to two additional templates and removing any generated templates at the end, enter: @@ -307,8 +302,8 @@ templates and removing any generated templates at the end, enter: -6. To execute \ **sinv**\ on noderange, node1-node4, using node1 as -the seed node, to generate the sinv.template from the xdsh command (-c), +6. To execute \ **sinv**\ on noderange, \ *node1-node4*\ , using \ *node1*\ as +the seed node, to generate the sinv.template from the \ **xdsh**\ command (\ **-c**\ ), using the exact match option, generating no additional templates, enter: @@ -322,14 +317,14 @@ using the exact match option, generating no additional templates, enter: -7. To execute \ **sinv**\ on the Linux osimage defined for cn1. First build a template from the /etc/hosts on the node. Then run sinv to compare. +7. To execute \ **sinv**\ on the Linux osimage defined for cn1. First build a template from the /etc/hosts on the node. Then run \ **sinv**\ to compare. .. code-block:: perl xdsh cn1 "cat /etc/hosts" | xdshcoll > /tmp/sinv2/template" - sinv -c "xdsh -i /install/netboot/rhels6/ppc64/test_ramdisk_statelite/rootimg cat /etc/hosts" -e -t1 -p /tmp/sinv.template -o /tmp/sinv.output + sinv -c "xdsh -i /install/netboot/rhels6/ppc64/test_ramdisk_statelite/rootimg cat /etc/hosts" -e -t 1 -p /tmp/sinv.template -o /tmp/sinv.output diff --git a/docs/source/guides/admin-guides/references/man1/snmove.1.rst b/docs/source/guides/admin-guides/references/man1/snmove.1.rst index 80c0fd598..453e64c94 100644 --- a/docs/source/guides/admin-guides/references/man1/snmove.1.rst +++ b/docs/source/guides/admin-guides/references/man1/snmove.1.rst @@ -59,7 +59,7 @@ node is second. The \ **xcatmaster**\ attribute must be set to the hostname of the primary service node as it is known by the node. When the \ **snmove**\ command is run it modifies the xCAT database to -switch the the primary server to the backup server. +switch the primary server to the backup server. It will also check the other services that are being used for the node (tftpserver, monserver, nfsserver, conserver), and if they were set @@ -114,13 +114,13 @@ OPTIONS \ **-l|-**\ **-liteonly**\ - Use this option to ONLY synchronize any AIX statelite files from the primary server to the backup server for the nodes. It will not do the actual moving of thre nodes the the backup servers. + Use this option to ONLY synchronize any AIX statelite files from the primary server to the backup server for the nodes. It will not do the actual moving of the nodes to the backup servers. \ **-P|-**\ **-postscripts**\ - Specifies a list of extra postscripts to be run on the nodes after the nodes are moved over to the new serive node. If \ **all**\ is specified, all the postscripts defined in the postscripts table will be run for the nodes. The specified postscripts must be stored under /install/postscripts directory. + Specifies a list of extra postscripts to be run on the nodes after the nodes are moved over to the new service node. If \ **all**\ is specified, all the postscripts defined in the postscripts table will be run for the nodes. The specified postscripts must be stored under /install/postscripts directory. diff --git a/docs/source/guides/admin-guides/references/man1/swapnodes.1.rst b/docs/source/guides/admin-guides/references/man1/swapnodes.1.rst index 55c8b6f4e..158c5f4cf 100644 --- a/docs/source/guides/admin-guides/references/man1/swapnodes.1.rst +++ b/docs/source/guides/admin-guides/references/man1/swapnodes.1.rst @@ -44,7 +44,7 @@ The \ **swapnodes**\ command shouldn't make the decision of which 2 nodes are s After running \ **swapnodes**\ command, the order of the I/O devices may be changed after IO re-assignment, so the administrator needs to run \ **rbootseq**\ to set the boot string for the current_node. And then boot the node with the same image and same postscripts because they have the same attributes. -Without \ **-o**\ option, it's used to swap the location info in the db between 2 nodes. With \ **-o**\ option, it's used to move the \ *current_node*\ definition to \ *fip_node*\ (the 2nd octant), not move the \ *fip_node*\ definition to the 1st octant. If the two nodes are in a cec, it will assign the IO adapters that were assigned to the defective node to the available node. Originally, the \ *current_node*\ is a defective non-compute node, and \ *fip_node*\ is a avaible compute node. After the swapping, the \ *current_node*\ will be a available node. +Without \ **-o**\ option, it's used to swap the location info in the db between 2 nodes. With \ **-o**\ option, it's used to move the \ *current_node*\ definition to \ *fip_node*\ (the 2nd octant), not move the \ *fip_node*\ definition to the 1st octant. If the two nodes are in a cec, it will assign the IO adapters that were assigned to the defective node to the available node. Originally, the \ *current_node*\ is a defective non-compute node, and \ *fip_node*\ is a available compute node. After the swapping, the \ *current_node*\ will be a available node. ******* @@ -94,7 +94,7 @@ EXAMPLES -1. To swap the service node attributes and IO assignments between sn1 and compute2 which are in the same cec, all the attributes in the ppc table and nodepos talbe of the two node will be swapped, and the the I/O adapters from the defective node (the original sn1) will be assigned to the available node (the original compute2). After the swapping, the sn1 will use the compute2's hardware resource and the I/O adapters from the original sn1. +1. To swap the service node attributes and IO assignments between sn1 and compute2 which are in the same cec, all the attributes in the ppc table and nodepos table of the two node will be swapped, and the I/O adapters from the defective node (the original sn1) will be assigned to the available node (the original compute2). After the swapping, the sn1 will use the compute2's hardware resource and the I/O adapters from the original sn1. .. code-block:: perl @@ -104,7 +104,7 @@ EXAMPLES -2. To swap the service node attributes and IO assignments between sn1 and compute2 which are NOT in the same cec, all the attributes in the ppc table and nodepos talbe of the two node will be swapped. After the swapping, the sn1 will use the compute2's hardware resource. +2. To swap the service node attributes and IO assignments between sn1 and compute2 which are NOT in the same cec, all the attributes in the ppc table and nodepos table of the two node will be swapped. After the swapping, the sn1 will use the compute2's hardware resource. .. code-block:: perl diff --git a/docs/source/guides/admin-guides/references/man1/switchdiscover.1.rst b/docs/source/guides/admin-guides/references/man1/switchdiscover.1.rst index 1ba9aff9b..e84f3e74d 100644 --- a/docs/source/guides/admin-guides/references/man1/switchdiscover.1.rst +++ b/docs/source/guides/admin-guides/references/man1/switchdiscover.1.rst @@ -23,13 +23,13 @@ DESCRIPTION *********** -The switchdiscover command scans the subnets and discovers all the swithches on the subnets. The command takes a list of subnets as input. The default subnets are the ones that the xCAT management node is on. It uses nmap command as default to discover the switches. However, you can specify other discovery methods such as lldp or snmp with \ **-s**\ flag. You can write the discovered switches into xCAT database with \ **-w**\ flag. This command supports may output formats such as xml(\ **-x**\ ), raw(\ **-r**\ ) and stanza(\ **-z**\ ) in addition to the default format. +The switchdiscover command scans the subnets and discovers all the switches on the subnets. The command takes a list of subnets as input. The default subnets are the ones that the xCAT management node is on. It uses nmap command as default to discover the switches. However, you can specify other discovery methods such as lldp or snmp with \ **-s**\ flag. You can write the discovered switches into xCAT database with \ **-w**\ flag. This command supports may output formats such as xml(\ **-x**\ ), raw(\ **-r**\ ) and stanza(\ **-z**\ ) in addition to the default format. \ **-**\ **-setup**\ flag is for switch-based switch discovery. It will find all the discovered switches on the subnets, then match them with predefined switches in the xCATDB. Next, it will set discovered switches with static ip address and hostname based on the predefined switch. It will also enable snmpv3 configuration. The details of the process are defined in the http://xcat-docs.readthedocs.io/en/latest/advanced/networks/switchdiscover/switches_discovery.html. -To view all the switches defined in the xCAT databasee use \ **lsdef -w "nodetype=switch"**\ command. +To view all the switches defined in the xCAT database use \ **lsdef -w "nodetype=switch"**\ command. -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 lldp method, make sure that lldpd package is installed and lldpd is running on the xCAT management node. lldpd comes from xcat-dep package or you can get it from http://vincentbernat.github.io/lldpd/installation.html. 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. @@ -102,13 +102,13 @@ OPTIONS \ **-x**\ - XML formated output. + XML formatted output. \ **-z**\ - Stanza formated output. + Stanza formatted output. diff --git a/docs/source/guides/admin-guides/references/man1/updatenode.1.rst b/docs/source/guides/admin-guides/references/man1/updatenode.1.rst index 55043ad8d..cd9a37448 100644 --- a/docs/source/guides/admin-guides/references/man1/updatenode.1.rst +++ b/docs/source/guides/admin-guides/references/man1/updatenode.1.rst @@ -325,7 +325,7 @@ PARAMETERS The scripts must be executable and copied to the /install/postscripts directory. Each script can take zero or more parameters. - If parameters are spcified, the whole list needs to be quoted by double quotes. + If parameters are specified, the whole list needs to be quoted by double quotes. For example: @@ -341,7 +341,7 @@ PARAMETERS Specifies one or more "attribute equals value" pairs, separated by spaces. Attr=val pairs must be specified last on the command line. The currently supported attributes are: "installp_bundle", "otherpkgs", "installp_flags", - "emgr_flags" and "rpm_flags". These attribute are only valid for AIX software + "emgr_flags" and "rpm_flags". These attributes are only valid for AIX software maintenance support. @@ -355,9 +355,7 @@ OPTIONS \ **-**\ **-fanout**\ =\ *fanout_value*\ - Specifies a fanout value for the maximum number of concur- - rently executing remote shell processes. Serial execution - can be specified by indicating a fanout value of \ **1**\ . If \ **-**\ **-fanout**\ is not specified, a default fanout value of \ **64**\ is used. + Specifies a fanout value for the maximum number of concurrently executing remote shell processes. Serial execution can be specified by indicating a fanout value of \ **1**\ . If \ **-**\ **-fanout**\ is not specified, a default fanout value of \ **64**\ is used. @@ -441,7 +439,7 @@ OPTIONS AIX and Linux and updating software (-S) for Linux only. The non-root userid must be previously defined as an xCAT user. The userid sudo setup will have to be done by the admin on the node. - This is not supported in a hiearchical cluster, that is the node is serviced by a service node. + This is not supported in a hierarchical cluster, that is the node is serviced by a service node. See the document Granting_Users_xCAT_privileges for required xcat/sudo setup. diff --git a/docs/source/guides/admin-guides/references/man1/xcat2nim.1.rst b/docs/source/guides/admin-guides/references/man1/xcat2nim.1.rst index e23510646..9069b27de 100644 --- a/docs/source/guides/admin-guides/references/man1/xcat2nim.1.rst +++ b/docs/source/guides/admin-guides/references/man1/xcat2nim.1.rst @@ -153,7 +153,7 @@ EXAMPLES xcat2nim -l -t node clstrn02 -7. To re-create a NIM machine definiton and display verbose output. +7. To re-create a NIM machine definition and display verbose output. .. code-block:: perl diff --git a/docs/source/guides/admin-guides/references/man5/networks.5.rst b/docs/source/guides/admin-guides/references/man5/networks.5.rst index b9ab58208..c71afb5f2 100644 --- a/docs/source/guides/admin-guides/references/man5/networks.5.rst +++ b/docs/source/guides/admin-guides/references/man5/networks.5.rst @@ -138,7 +138,7 @@ networks Attributes: \ **mtu**\ - The default MTU for the network + The default MTU for the network, If multiple networks are applied to the same nic on the SN and/or CN, the MTU shall be the same for those networks. diff --git a/docs/source/guides/admin-guides/references/man5/openbmc.5.rst b/docs/source/guides/admin-guides/references/man5/openbmc.5.rst index 14cbd3c80..11bbee003 100644 --- a/docs/source/guides/admin-guides/references/man5/openbmc.5.rst +++ b/docs/source/guides/admin-guides/references/man5/openbmc.5.rst @@ -27,7 +27,7 @@ DESCRIPTION *********** -Setting for nodes that are controlled by an on-board OpenBmc. +Setting for nodes that are controlled by an on-board OpenBMC. ******************* diff --git a/docs/source/guides/admin-guides/references/man5/postscripts.5.rst b/docs/source/guides/admin-guides/references/man5/postscripts.5.rst index a87cd902c..6bac116b9 100644 --- a/docs/source/guides/admin-guides/references/man5/postscripts.5.rst +++ b/docs/source/guides/admin-guides/references/man5/postscripts.5.rst @@ -44,13 +44,13 @@ postscripts Attributes: \ **postscripts**\ - Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute. + Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute. Please note that the postscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postscripts" attribute of a node with "chdef -m" command \ **postbootscripts**\ - Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. + Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. Please note that the postbootscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postbootscripts" attribute of a node with "chdef -m" command diff --git a/docs/source/guides/admin-guides/references/man5/xcatdb.5.rst b/docs/source/guides/admin-guides/references/man5/xcatdb.5.rst index 4100de4bb..e2cb86603 100644 --- a/docs/source/guides/admin-guides/references/man5/xcatdb.5.rst +++ b/docs/source/guides/admin-guides/references/man5/xcatdb.5.rst @@ -567,7 +567,7 @@ notification(5)|notification.5 openbmc(5)|openbmc.5 - Setting for nodes that are controlled by an on-board OpenBmc. + Setting for nodes that are controlled by an on-board OpenBMC. diff --git a/docs/source/guides/admin-guides/references/man7/group.7.rst b/docs/source/guides/admin-guides/references/man7/group.7.rst index 8aea1128b..9a67dd224 100644 --- a/docs/source/guides/admin-guides/references/man7/group.7.rst +++ b/docs/source/guides/admin-guides/references/man7/group.7.rst @@ -801,13 +801,13 @@ group Attributes: \ **postbootscripts**\ (postscripts.postbootscripts) - Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. + Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. Please note that the postbootscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postbootscripts" attribute of a node with "chdef -m" command \ **postscripts**\ (postscripts.postscripts) - Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute. + Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute. Please note that the postscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postscripts" attribute of a node with "chdef -m" command diff --git a/docs/source/guides/admin-guides/references/man7/network.7.rst b/docs/source/guides/admin-guides/references/man7/network.7.rst index 644e12908..593a52fb0 100644 --- a/docs/source/guides/admin-guides/references/man7/network.7.rst +++ b/docs/source/guides/admin-guides/references/man7/network.7.rst @@ -89,7 +89,7 @@ network Attributes: \ **mtu**\ (networks.mtu) - The default MTU for the network + The default MTU for the network, If multiple networks are applied to the same nic on the SN and/or CN, the MTU shall be the same for those networks. diff --git a/docs/source/guides/admin-guides/references/man7/node.7.rst b/docs/source/guides/admin-guides/references/man7/node.7.rst index 77646859a..0ab71ac4d 100644 --- a/docs/source/guides/admin-guides/references/man7/node.7.rst +++ b/docs/source/guides/admin-guides/references/man7/node.7.rst @@ -807,13 +807,13 @@ node Attributes: \ **postbootscripts**\ (postscripts.postbootscripts) - Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. + Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. Please note that the postbootscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postbootscripts" attribute of a node with "chdef -m" command \ **postscripts**\ (postscripts.postscripts) - Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute. + Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute. Please note that the postscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postscripts" attribute of a node with "chdef -m" command diff --git a/docs/source/guides/admin-guides/references/man8/makedns.8.rst b/docs/source/guides/admin-guides/references/man8/makedns.8.rst index 9b558dccf..a97c1401a 100644 --- a/docs/source/guides/admin-guides/references/man8/makedns.8.rst +++ b/docs/source/guides/admin-guides/references/man8/makedns.8.rst @@ -43,7 +43,7 @@ The \ **forwarders**\ value should be set to the IP address of one or more name An xCAT \ **network**\ definition must be defined for each network used in the cluster. The \ **net**\ and \ **mask**\ attributes will be used by the \ **makedns**\ command. -A network \ **domain**\ and \ **nameservers**\ values must be provided either in the \ **network**\ definiton corresponding to the node or in the \ **site**\ definition. +A network \ **domain**\ and \ **nameservers**\ values must be provided either in the \ **network**\ definition corresponding to the node or in the \ **site**\ definition. Only entries in /etc/hosts or the hosts specified by \ **noderange**\ that have a corresponding xCAT network definition will be added to DNS. diff --git a/docs/source/guides/admin-guides/references/man8/makeknownhosts.8.rst b/docs/source/guides/admin-guides/references/man8/makeknownhosts.8.rst index 8dad0e800..fe31b65ad 100644 --- a/docs/source/guides/admin-guides/references/man8/makeknownhosts.8.rst +++ b/docs/source/guides/admin-guides/references/man8/makeknownhosts.8.rst @@ -19,7 +19,7 @@ SYNOPSIS ******** -\ **makeknownhosts**\ \ *noderange*\ [\ **-r | -**\ **-remove**\ ] [\ **-V | -**\ **-verbose**\ ] +\ **makeknownhosts**\ \ *noderange*\ [\ **-r | -**\ **-remove | -d | -**\ **-delete**\ ] [\ **-V | -**\ **-verbose**\ ] \ **makeknownhosts**\ [\ **-h | -**\ **-help**\ ] @@ -53,12 +53,18 @@ OPTIONS -\ **-r|-**\ **-remove**\ +\ **-d|-**\ **-delete**\ Only removes the entries for the nodes from the known_hosts file. +\ **-r|-**\ **-remove**\ + + Synonymous to \ **-d|-**\ **-delete**\ . + + + \ **-V|-**\ **-verbose**\ Verbose mode. @@ -97,7 +103,7 @@ EXAMPLES .. code-block:: perl - makeknownhosts node02 -r + makeknownhosts node02 -d diff --git a/docs/source/guides/admin-guides/references/man8/makenetworks.8.rst b/docs/source/guides/admin-guides/references/man8/makenetworks.8.rst index 4b0b7a11c..aa78cdc5b 100644 --- a/docs/source/guides/admin-guides/references/man8/makenetworks.8.rst +++ b/docs/source/guides/admin-guides/references/man8/makenetworks.8.rst @@ -35,7 +35,7 @@ The \ **makenetworks**\ command can be used to gather network information from Every network that will be used to install a cluster node must be defined in the xCAT database. -The default behavior is to gather network information from the managment node, and any configured xCAT service nodes, and automatically save this information in the xCAT database. +The default behavior is to gather network information from the management node, and any configured xCAT service nodes, and automatically save this information in the xCAT database. You can use the "-d" option to display the network information without writing it to the database. diff --git a/docs/source/guides/admin-guides/references/man8/makeroutes.8.rst b/docs/source/guides/admin-guides/references/man8/makeroutes.8.rst index 9a0145393..1bb33dd5c 100644 --- a/docs/source/guides/admin-guides/references/man8/makeroutes.8.rst +++ b/docs/source/guides/admin-guides/references/man8/makeroutes.8.rst @@ -35,7 +35,7 @@ DESCRIPTION *********** -The \ **makeroutes**\ command adds or deletes routes on the management node or any given nodes. The \ **noderange**\ specifies the nodes where the routes are to be added or removed. When the \ *noderange*\ is omitted, the action will be done on the management node. The \ **-r**\ option specifies the name of routes. The details of the routes are defined in the \ **routes**\ table which contians the route name, subnet, net mask and gateway. If -r option is omitted, the names of the routes found on \ **noderes.routenames**\ for the nodes or on \ **site.mnroutenames**\ for the management node will be used. +The \ **makeroutes**\ command adds or deletes routes on the management node or any given nodes. The \ **noderange**\ specifies the nodes where the routes are to be added or removed. When the \ *noderange*\ is omitted, the action will be done on the management node. The \ **-r**\ option specifies the name of routes. The details of the routes are defined in the \ **routes**\ table which contains the route name, subnet, net mask and gateway. If -r option is omitted, the names of the routes found on \ **noderes.routenames**\ for the nodes or on \ **site.mnroutenames**\ for the management node will be used. If you want the routes be automatically setup during node deployment, first put a list of route names to \ **noderes.routenames**\ and then add \ *setroute*\ script name to the \ **postscripts.postbootscripts**\ for the nodes. diff --git a/docs/source/guides/admin-guides/references/man8/nodeset.8.rst b/docs/source/guides/admin-guides/references/man8/nodeset.8.rst index 23ec24e23..35edfcd45 100644 --- a/docs/source/guides/admin-guides/references/man8/nodeset.8.rst +++ b/docs/source/guides/admin-guides/references/man8/nodeset.8.rst @@ -53,7 +53,7 @@ Assume that /tftpboot is the root for tftpd (set in site(5)|site.5). \ **nodeset**\ is called by \ **rinstall**\ and \ **winstall**\ and is also called by the installation process remotely to set the boot state back to "boot". -A user can supply their own scripts to be run on the mn or on the service node (if a hierarchical cluster) for a node when the nodeset command is run. 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 nodeset command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the nodeset command are stored in the 'end' column of \ *prescripts*\ table. You can run 'tabdump -d prescripts' command for details. 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. 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. +A user can supply their own scripts to be run on the mn or on the service node (if a hierarchical cluster) for a node when the nodeset command is run. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts directory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the nodeset command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the nodeset command are stored in the 'end' column of \ *prescripts*\ table. You can run 'tabdump -d prescripts' command for details. 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. If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at a time. If it is not specified, the script will be invoked once for all the nodes. *************** @@ -114,7 +114,7 @@ A user can supply their own scripts to be run on the mn or on the service node ( \ **shell**\ - This instructs tho node to boot to the xCAT genesis environment, and present a shell prompt on console. + This instructs the node to boot to the xCAT genesis environment, and present a shell prompt on console. The node will also be able to be sshed into and have utilities such as wget, tftp, scp, nfs, and cifs. It will have storage drivers available for many common systems. diff --git a/docs/source/guides/admin-guides/references/man8/rinstall.8.rst b/docs/source/guides/admin-guides/references/man8/rinstall.8.rst index 0e06cd9e6..f33d0144c 100644 --- a/docs/source/guides/admin-guides/references/man8/rinstall.8.rst +++ b/docs/source/guides/admin-guides/references/man8/rinstall.8.rst @@ -19,9 +19,9 @@ Name **************** -\ **rinstall**\ \ *noderange*\ \ **boot**\ | \ **shell**\ | \ **runcmd=bmcsetup**\ [\ **-c | -**\ **-console**\ ] [\ **-V | -**\ **-verbose**\ ] +\ **rinstall**\ \ *noderange*\ [\ **boot**\ | \ **shell**\ | \ **runcmd=bmcsetup**\ ] [\ **runimage=**\ \ *task*\ ] [\ **-c | -**\ **-console**\ ] [\ **-V | -**\ **-verbose**\ ] -\ **rinstall**\ \ *noderange*\ \ **osimage**\ =\ *imagename*\ | [\ **-O**\ ] \ *imagename*\ [\ **-**\ **-ignorekernelchk**\ ] [\ **-c | -**\ **-console**\ ] [\ **-u | -**\ **-uefimode**\ ] [\ **-V | -**\ **-verbose**\ ] +\ **rinstall**\ \ *noderange*\ [\ **osimage**\ =\ *imagename*\ | \ *imagename*\ ] [\ **-**\ **-ignorekernelchk**\ ] [\ **-c | -**\ **-console**\ ] [\ **-u | -**\ **-uefimode**\ ] [\ **-V | -**\ **-verbose**\ ] \ **rinstall**\ [\ **-h | -**\ **-help | -v | -**\ **-version**\ ] @@ -31,11 +31,11 @@ Name ******************* -\ **rinstall**\ is a convenience command to begin OS provision on a noderange(support nodes with "nodetype.mgt=ipmi,blade,hmc,ivm,fsp,kvm,esx,rhevm"). +\ **rinstall**\ is a convenience command to begin OS provision on a noderange. -If \ **osimage**\ =\ *imagename*\ | \ **-O**\ \ *imagename*\ is specified or nodetype.provmethod=\ **osimage**\ is set, provision the noderange with the osimage specified/configured. +If \ **osimage**\ =\ *imagename*\ | \ *imagename*\ is specified or nodetype.provmethod=\ **osimage**\ is set, provision the noderange with the osimage specified/configured. -If -c is specified, it will then run rcons on the node. This is allowed only if one node in the noderange. If need consoles on multiple nodes , see winstall(8)|winstall.8. +If \ **-c**\ is specified, it will then run rcons on the node. This is allowed only if one node in the noderange. If need consoles on multiple nodes, see winstall(8)|winstall.8. *************** @@ -50,9 +50,9 @@ If -c is specified, it will then run rcons on the node. This is allowed only if -\ **osimage | osimage=**\ \ *imagename*\ |\ **-O**\ \ *imagename*\ +\ *imagename*\ | \ **osimage=**\ \ *imagename*\ - Prepare server for installing a node using the specified os image. The os image is defined in the \ *osimage*\ table and \ *linuximage*\ table. If the is omitted, the os image name will be obtained from \ *nodetype.provmethod*\ for the node. + Prepare server for installing a node using the specified os image. The os image is defined in the \ *osimage*\ table and \ *linuximage*\ table. If the \ *imagename*\ is omitted, the os image name will be obtained from \ *nodetype.provmethod*\ for the node. @@ -62,7 +62,7 @@ If -c is specified, it will then run rcons on the node. This is allowed only if -\ **runimage**\ =\ *task*\ +\ **runimage=**\ \ *task*\ If you would like to run a task after deployment, you can define that task with this attribute. @@ -70,14 +70,13 @@ If -c is specified, it will then run rcons on the node. This is allowed only if \ **runcmd=bmcsetup**\ - This instructs the node to boot to the xCAT nbfs environment and proceed to configure BMC - for basic remote access. This causes the IP, netmask, gateway, username, and password to be programmed according to the configuration table. + This instructs the node to boot to the xCAT nbfs environment and proceed to configure BMC for basic remote access. This causes the IP, netmask, gateway, username, and password to be programmed according to the configuration table. \ **shell**\ - This instructs tho node to boot to the xCAT genesis environment, and present a shell prompt on console. + This instructs the node to boot to the xCAT genesis environment, and present a shell prompt on console. The node will also be able to be sshed into and have utilities such as wget, tftp, scp, nfs, and cifs. It will have storage drivers available for many common systems. @@ -100,7 +99,7 @@ If -c is specified, it will then run rcons on the node. This is allowed only if -\ **-V | -**\ **-Verbose**\ +\ **-V | -**\ **-verbose**\ Verbose output. diff --git a/docs/source/guides/admin-guides/references/man8/winstall.8.rst b/docs/source/guides/admin-guides/references/man8/winstall.8.rst index cfe21170c..e939b5554 100644 --- a/docs/source/guides/admin-guides/references/man8/winstall.8.rst +++ b/docs/source/guides/admin-guides/references/man8/winstall.8.rst @@ -19,11 +19,11 @@ Name **************** -\ **rinstall**\ \ *noderange*\ \ **boot**\ | \ **shell**\ | \ **runcmd=bmcsetup**\ [\ **-c | -**\ **-console**\ ] [\ **-V | -**\ **-verbose**\ ] +\ **winstall**\ \ *noderange*\ [\ **boot**\ | \ **shell**\ | \ **runcmd=bmcsetup**\ ] [\ **runimage=**\ \ *task*\ ] [\ **-V | -**\ **-verbose**\ ] -\ **rinstall**\ \ *noderange*\ \ **osimage**\ =\ *imagename*\ | [\ **-O**\ ] \ *imagename*\ [\ **-**\ **-ignorekernelchk**\ ] [\ **-c | -**\ **-console**\ ] [\ **-u | -**\ **-uefimode**\ ] [\ **-V | -**\ **-verbose**\ ] +\ **winstall**\ \ *noderange*\ [\ **osimage**\ =\ *imagename*\ | \ *imagename*\ ] [\ **-**\ **-ignorekernelchk**\ ] [\ **-u | -**\ **-uefimode**\ ] [\ **-V | -**\ **-verbose**\ ] -\ **rinstall**\ [\ **-h | -**\ **-help | -v | -**\ **-version**\ ] +\ **winstall**\ [\ **-h | -**\ **-help | -v | -**\ **-version**\ ] ******************* @@ -31,11 +31,11 @@ Name ******************* -\ **winstall**\ is a convenience command to begin OS provision on a noderange(support nodes with "nodetype.mgt=ipmi,blade,hmc,ivm,fsp,kvm,esx,rhevm"). +\ **winstall**\ is a convenience command to begin OS provision on a noderange. -If \ **osimage**\ =\ *imagename*\ | \ **-O**\ \ *imagename*\ is specified or nodetype.provmethod=\ **osimage**\ is set, provision the noderange with the osimage specified/configured. +If \ **osimage**\ =\ *imagename*\ | \ *imagename*\ is specified or nodetype.provmethod=\ **osimage**\ is set, provision the noderange with the osimage specified/configured. -It will then run wcons on the nodes. +It will then run \ **wcons**\ on the noderange. *************** @@ -50,9 +50,9 @@ It will then run wcons on the nodes. -\ **osimage | osimage=**\ \ *imagename*\ |\ **-O**\ \ *imagename*\ +\ *imagename*\ | \ **osimage=**\ \ *imagename*\ - Prepare server for installing a node using the specified os image. The os image is defined in the \ *osimage*\ table and \ *linuximage*\ table. If the is omitted, the os image name will be obtained from \ *nodetype.provmethod*\ for the node. + Prepare server for installing a node using the specified os image. The os image is defined in the \ *osimage*\ table and \ *linuximage*\ table. If the \ *imagename*\ is omitted, the os image name will be obtained from \ *nodetype.provmethod*\ for the node. @@ -62,7 +62,7 @@ It will then run wcons on the nodes. -\ **runimage**\ =\ *task*\ +\ **runimage=**\ \ *task*\ If you would like to run a task after deployment, you can define that task with this attribute. @@ -70,14 +70,13 @@ It will then run wcons on the nodes. \ **runcmd=bmcsetup**\ - This instructs the node to boot to the xCAT nbfs environment and proceed to configure BMC - for basic remote access. This causes the IP, netmask, gateway, username, and password to be programmed according to the configuration table. + This instructs the node to boot to the xCAT nbfs environment and proceed to configure BMC for basic remote access. This causes the IP, netmask, gateway, username, and password to be programmed according to the configuration table. \ **shell**\ - This instructs tho node to boot to the xCAT genesis environment, and present a shell prompt on console. + This instructs the node to boot to the xCAT genesis environment, and present a shell prompt on console. The node will also be able to be sshed into and have utilities such as wget, tftp, scp, nfs, and cifs. It will have storage drivers available for many common systems. @@ -100,18 +99,12 @@ It will then run wcons on the nodes. -\ **-V | -**\ **-Verbose**\ +\ **-V | -**\ **-verbose**\ Verbose output. -\ **-c | -**\ **-console**\ - - Requests that rinstall runs rcons once the provision starts. This will only work if there is only one node in the noderange. See winstall(8)|winstall.8 for starting consoles on multiple nodes. - - - **************** \ **Examples**\ @@ -119,7 +112,7 @@ It will then run wcons on the nodes. -1. Provison nodes 1 through 20, using their current configuration. +1. Provision nodes 1 through 20, using their current configuration. .. code-block:: perl @@ -134,7 +127,7 @@ It will then run wcons on the nodes. .. code-block:: perl - winstall node1-node20 -O rhels6.4-ppc64-netboot-compute + winstall node1-node20 osimage=rhels6.4-ppc64-netboot-compute diff --git a/docs/source/guides/admin-guides/references/man8/xcatconfig.8.rst b/docs/source/guides/admin-guides/references/man8/xcatconfig.8.rst index 75d981311..85a089555 100644 --- a/docs/source/guides/admin-guides/references/man8/xcatconfig.8.rst +++ b/docs/source/guides/admin-guides/references/man8/xcatconfig.8.rst @@ -66,19 +66,19 @@ OPTIONS \ **-i|-**\ **-initialinstall**\ - The install option is normally run as a post operation from the rpm xCAT.spec file during the initial install of xCAT on the Management Node. It will setup the root ssh keys, ssh node keys, xCAT credentials, initialize the datebase, export directories, start syslog and other daemons as needed after the initial install of xCAT. + The install option is normally run as a post operation from the rpm xCAT.spec file during the initial install of xCAT on the Management Node. It will setup the root ssh keys, ssh node keys, xCAT credentials, initialize the database, export directories, start syslog and other daemons as needed after the initial install of xCAT. \ **-u|-**\ **-updateinstall**\ - The update install option is normally run as a post operation from the rpm xCAT.spec file during an update install of xCAT on the Management Node. It will check the setup the root ssh keys, ssh node keys, xCAT credentials, datebase, exported directories, syslog and the state of daemons needed by xCAT, after the updateinstall of xCAT. If setup is required, it will perform the operation. It will restart the necessary daemons. + The update install option is normally run as a post operation from the rpm xCAT.spec file during an update install of xCAT on the Management Node. It will check the setup the root ssh keys, ssh node keys, xCAT credentials, database, exported directories, syslog and the state of daemons needed by xCAT, after the updateinstall of xCAT. If setup is required, it will perform the operation. It will restart the necessary daemons. \ **-k|-**\ **-sshkeys**\ - This option will remove and regenerate the root id_rsa keys. It should only be used, if the keys are deleted or corrupted. The keys must then be distribute to the nodes by installing, running updatenode -k, or using xdsh -K option, for root to be able to ssh to the nodes without being prompted for a password. + This option will remove and regenerate the root id_rsa keys. It should only be used, if the keys are deleted or corrupted. The keys must then be distributed to the nodes by installing, running updatenode -k, or using xdsh -K option, for root to be able to ssh to the nodes without being prompted for a password. rspconfig will need to be run to distribute the key to the MM and HMCs. Any device, we need to ssh from the MN to the device will also have to be updated with the new ssh keys. @@ -91,7 +91,7 @@ OPTIONS \ **-c|-**\ **-credentials**\ - This option will remove all xcat credentials for root and any userids where credentials have been created. It will regenerate roots credentials, but the admin will have to add back all the userid credentials needed with the /opt/xcat/share/xcat/scripts/setup-local-client.sh command. It should only be used, if they are deleted or become corrupted. The root credentials must be redistribed to the service nodes by installing the service node or using updatenode -k. makeconservercf must be rerun to pick up the new credentials, and conserver must be stop and started. + This option will remove all xcat credentials for root and any userids where credentials have been created. It will regenerate roots credentials, but the admin will have to add back all the userid credentials needed with the /opt/xcat/share/xcat/scripts/setup-local-client.sh command. It should only be used, if they are deleted or become corrupted. The root credentials must be redistributed to the service nodes by installing the service node or using updatenode -k. makeconservercf must be rerun to pick up the new credentials, and conserver must be stopped and started. @@ -103,9 +103,9 @@ OPTIONS \ **-f|-**\ **-force**\ - The force option may be used after the install to reinitialize the Management Node. This option will regenerate keys, credential and reinititialize the site table. This option should be used, if keys or credentials become corrupt or lost. + The force option may be used after the install to reinitialize the Management Node. This option will regenerate keys, credential and reinitialize the site table. This option should be used, if keys or credentials become corrupt or lost. Additional action must be taken after using the force options. ssh keys must be redistributed to the nodes, site table attributes might need to be restored, makeconservercf needs to be rerun to pick up the new credentials and conserver stopped and started, rspconfig needs to be rerun to distribute the new keys to the MM and the HMCs. - A new set of common ssh host keys will have been generated for the nodes. If you wish your nodes to be able to ssh to each other with out password intervention, then you should redistribute these new keys to the nodes. If the nodes hostkeys are updated then you will need to remove their entries from the known_hosts files on the management node before using ssh, xdsh, xdcp. + A new set of common ssh host keys will have been generated for the nodes. If you wish your nodes to be able to ssh to each other with out password intervention, then you should redistribute these new keys to the nodes. If the nodes hostkeys are updated then you will need to remove their entries from the known_hosts files on the management node before using ssh, xdsh, xdcp. Redistribute credentials and ssh keys to the service nodes and ssh keys to the nodes by using the updatenode -k command. diff --git a/docs/source/guides/admin-guides/references/man8/xcatsetup.8.rst b/docs/source/guides/admin-guides/references/man8/xcatsetup.8.rst index 494551577..355cc6cb6 100644 --- a/docs/source/guides/admin-guides/references/man8/xcatsetup.8.rst +++ b/docs/source/guides/admin-guides/references/man8/xcatsetup.8.rst @@ -124,7 +124,7 @@ Configuration File The \ **config file**\ is organized in stanza format and supports the keywords in the sample file below. Comment lines -begin with "#". Stanzas can be ommitted if you do not want to define that type of object. +begin with "#". Stanzas can be omitted if you do not want to define that type of object. The only hostname formats supported are those shown in this sample file, although you can change the base text and the numbers. For example, hmc1-hmc3 could be changed to hwmgmt01-hwmgmt12. The hostnames specified must sort correctly. I.e. use node01-node80, instead of node1-node80. diff --git a/docs/source/guides/install-guides/common_sections.rst b/docs/source/guides/install-guides/common_sections.rst index e9f7cc87e..203b6cea9 100644 --- a/docs/source/guides/install-guides/common_sections.rst +++ b/docs/source/guides/install-guides/common_sections.rst @@ -37,11 +37,11 @@ xCAT consists of two software packages: ``xcat-core`` and ``xcat-dep`` * **Latest Release (Stable) Builds** - *This is the latest GA (Generally Availability) build that has been tested throughly* + *This is the latest GA (Generally Availability) build that has been tested thoroughly* * **Latest Snapshot Builds** - *This is the latest snapshot of the GA version build that may contain bug fixes but has not yet been tested throughly* + *This is the latest snapshot of the GA version build that may contain bug fixes but has not yet been tested thoroughly* * **Development Builds** diff --git a/docs/source/guides/install-guides/maintenance/uninstall_xcat.rst b/docs/source/guides/install-guides/maintenance/uninstall_xcat.rst index bfc60691f..6e343f834 100644 --- a/docs/source/guides/install-guides/maintenance/uninstall_xcat.rst +++ b/docs/source/guides/install-guides/maintenance/uninstall_xcat.rst @@ -58,7 +58,7 @@ Remove xCAT Files dpkg -l | awk '/xcat/ { print $2 }' - If you want to remove more cleanly, the list bleow maybe helpful. Listed are the packages of xcat installation tarball. Some RPMs may not to be installed in a specific environment. + If you want to remove more cleanly, the list below maybe helpful. Listed are the packages of xcat installation tarball. Some RPMs may not to be installed in a specific environment. * XCAT Core Packages list (xcat-core): diff --git a/docs/source/guides/install-guides/yum/update_xcat.rst b/docs/source/guides/install-guides/yum/update_xcat.rst index fc01d99ad..fbbbe4762 100644 --- a/docs/source/guides/install-guides/yum/update_xcat.rst +++ b/docs/source/guides/install-guides/yum/update_xcat.rst @@ -6,5 +6,5 @@ If at a later date you want to update xCAT, first, update the software repositor yum clean metadata # or, yum clean all yum update '*xCAT*' - - + # To check and update the packages provided by xcat-dep: + yum update '*xcat*' diff --git a/docs/source/guides/install-guides/zypper/update_xcat.rst b/docs/source/guides/install-guides/zypper/update_xcat.rst index c18bb5b3c..3da2a2bb2 100644 --- a/docs/source/guides/install-guides/zypper/update_xcat.rst +++ b/docs/source/guides/install-guides/zypper/update_xcat.rst @@ -6,4 +6,5 @@ If at a later date you want to update xCAT, first, update the software repositor zypper refresh zypper update "*xCAT*" - + # To check and update the packages provided by xcat-dep: + zypper update "*xcat*" diff --git a/docs/source/overview/differentiators.rst b/docs/source/overview/differentiators.rst index f84bf0a8a..eb015c76b 100644 --- a/docs/source/overview/differentiators.rst +++ b/docs/source/overview/differentiators.rst @@ -18,7 +18,7 @@ Differentiators IBM Power, IBM Power LE, x86_64 -* Support Multiple Virtulization Infrastructures +* Support Multiple Virtualization Infrastructures IBM PowerKVM, KVM, IBM zVM, ESXI, XEN diff --git a/docs/source/overview/quick_start.rst b/docs/source/overview/quick_start.rst index 8bf22dfae..d26fc33b8 100644 --- a/docs/source/overview/quick_start.rst +++ b/docs/source/overview/quick_start.rst @@ -33,7 +33,7 @@ If xCAT looks suitable for your requirement, following steps are recommended pro Now you have the node definition. Verify the hardware control for defined nodes is working. e.g. ``rpower stat``. - Refer to the doc: :doc:`Hardware Management ` to learn how to perform the remote hardware control. + Refer to the doc: :doc:`Hardware Management <../guides/admin-guides/manage_clusters/ppc64le/management/index>` to learn how to perform the remote hardware control. #. Deploy OS on the target nodes diff --git a/docs/source/overview/xcat2_release.rst b/docs/source/overview/xcat2_release.rst index 21a39166b..2062b7c30 100644 --- a/docs/source/overview/xcat2_release.rst +++ b/docs/source/overview/xcat2_release.rst @@ -71,7 +71,7 @@ xCAT 2.12.x | | | | | +---------------------------------+---------------+-------------+----------------------------------+ || xCAT 2.12.3 | | |- GitHub Issues resolved | -|| 2016/09/30 | | |- rinv options for OpenPower | +|| 2016/09/30 | | |- rinv options for OpenPOWER | || | | |- switch based switch discovery | | `2.12.3 Release Notes `_ | | |- Add xCAT Troubleshooting Log | | | | |- xCAT Log Classification | | | | |- RAID Configuration | diff --git a/perl-xCAT/xCAT/Client.pm b/perl-xCAT/xCAT/Client.pm index 079a62155..d7df0a9fc 100644 --- a/perl-xCAT/xCAT/Client.pm +++ b/perl-xCAT/xCAT/Client.pm @@ -33,7 +33,7 @@ if ($inet6support) { if ($^O =~ /^linux/i) { # Is IPv6 enabled on the MN or xcat client node at all? - my $ipv6enabled = `ip addr 2> /dev/null | grep inet6`; + my $ipv6enabled = `ip -6 -o addr 2> /dev/null`; if (!$ipv6enabled) { $inet6support = 0; } diff --git a/perl-xCAT/xCAT/DBobjUtils.pm b/perl-xCAT/xCAT/DBobjUtils.pm index 918818c58..e3e202136 100755 --- a/perl-xCAT/xCAT/DBobjUtils.pm +++ b/perl-xCAT/xCAT/DBobjUtils.pm @@ -678,6 +678,7 @@ sub setobjdefs # update the tables a row at a time foreach my $objname (keys %objhash) { + my $obj_need_update = 0; # get attr=val that are set in the DB ?? my $type = $objhash{$objname}{objtype}; @@ -782,6 +783,7 @@ sub setobjdefs $montable->commit; $monsettable->commit; + $objhash{$objname}{updated} = 1; next; } #if ($type eq 'monitoring') @@ -872,6 +874,9 @@ sub setobjdefs } } + unless ($ret) { + $objhash{$objname}{updated} = 1; + } $thistable->commit; @@ -1026,6 +1031,7 @@ sub setobjdefs $rsp->{data}->[0] = "access_tabentry \'$this_attr->{access_tabentry}\' is not valid."; xCAT::MsgUtils->message("E", $rsp, $::callback); + $objhash{$objname}{error} = 1; next; } $lookup_table = $tabentry{'lookup_table'}; @@ -1078,19 +1084,26 @@ sub setobjdefs split(/$delim/, $DBattrvals{$objname}{$attr_name}); my @minusList = split(/$delim/, $objhash{$objname}{$attr_name}); + my $operation_failed = 0; foreach my $em (@minusList) { if (!(grep { $_ eq $em } @currentList)) { if (($::opt_t eq 'group') && ($DBattrvals{$objname}{'grouptype'} ne 'dynamic')) { my $rsp; $rsp->{data}->[0] = "$objname is not a member of \'$em\'."; - xCAT::MsgUtils->message("W", $rsp, $::callback); + xCAT::MsgUtils->message("E", $rsp, $::callback); + $operation_failed = 1; } else { my $rsp; $rsp->{data}->[0] = "$em is not in the attribute of \'$attr_name\' for the \'$objname\' definition."; - xCAT::MsgUtils->message("W", $rsp, $::callback); + xCAT::MsgUtils->message("E", $rsp, $::callback); + $operation_failed = 1; } } } + if ($operation_failed) { + $objhash{$objname}{error} = 1; + next; + } # make a new list without the one specified my $first = 1; @@ -1109,6 +1122,12 @@ sub setobjdefs } $val = $newlist; } + else { + my $rsp; + $rsp->{data}->[0] = "No value got for attribute \'$attr_name\' for the \'$objname\' definition."; + xCAT::MsgUtils->message("E", $rsp, $::callback); + next; + } } else { @@ -1121,10 +1140,13 @@ sub setobjdefs # the key is 'tabattrs' $allupdates{$lookup_table}{$objname}{$attr_name}{'tabattrs'}{$::tabattr} = $val; $setattrs = 1; - + $obj_need_update = 1; push(@setattrlist, $attr_name); } # end - foreach attribute + if ($obj_need_update) { + $objhash{$objname}{updated} = 1; + } my $rsp; foreach my $att (keys %$invalidattr) { diff --git a/perl-xCAT/xCAT/FSPvitals.pm b/perl-xCAT/xCAT/FSPvitals.pm index 3f31bf31c..11915abd7 100644 --- a/perl-xCAT/xCAT/FSPvitals.pm +++ b/perl-xCAT/xCAT/FSPvitals.pm @@ -375,7 +375,6 @@ sub rackenv { push @result, [ $name, $td, $Rc ]; if (!exists($request->{verbose})) { - #if( $td =~ /^Rack altitude in meters/ ) { if ($td =~ /^BPA-B total output in watts/) { last; } diff --git a/perl-xCAT/xCAT/GlobalDef.pm b/perl-xCAT/xCAT/GlobalDef.pm index b953a5168..b9b99ea20 100644 --- a/perl-xCAT/xCAT/GlobalDef.pm +++ b/perl-xCAT/xCAT/GlobalDef.pm @@ -51,7 +51,9 @@ $::STATUS_BOOTED = "booted"; $::STATUS_POWERING_ON = "powering-on"; $::STATUS_POWERING_OFF = "powering-off"; $::STATUS_DISCOVERING = "discovering"; +$::STATUS_DISCOVERED = "discovered"; $::STATUS_CONFIGURING = "configuring"; +$::STATUS_CONFIGURED = "configured"; $::STATUS_STANDING_BY = "standingby"; $::STATUS_SHELL = "shell"; $::STATUS_DEFINED = "defined"; @@ -69,7 +71,9 @@ $::STATUS_BMCREADY = "bmcready"; $::STATUS_POWERING_ON => 1, $::STATUS_POWERING_OFF => 1, $::STATUS_DISCOVERING => 1, + $::STATUS_DISCOVERED => 1, $::STATUS_CONFIGURING => 1, + $::STATUS_CONFIGURED => 1, $::STATUS_STANDING_BY => 1, $::STATUS_SHELL => 1, $::STATUS_DEFINED => 1, diff --git a/perl-xCAT/xCAT/MsgUtils.pm b/perl-xCAT/xCAT/MsgUtils.pm index b2e6484be..577d97ec4 100644 --- a/perl-xCAT/xCAT/MsgUtils.pm +++ b/perl-xCAT/xCAT/MsgUtils.pm @@ -16,6 +16,7 @@ use xCAT::Utils; #use locale; use Socket; use File::Path; +use constant PERF_LOG => "/var/log/xcat/perf.log"; $::NOK = -1; $::OK = 0; @@ -823,5 +824,65 @@ sub trace() { } } +#------------------------------------------------------------------ + +=head3 _perf_log + Libary function to write the perf log. Do not use it directly. +=cut + +#----------------------------------------------------------------- +sub _perf_log +{ + my $type = shift; + my $msg = shift; + my $fh; + my $ret = open($fh, '>>', PERF_LOG); + if (!$ret) { + xCAT::MsgUtils->message("S", "Open perf log file error: $!"); + } + my $line = localtime()."\t$type\t$msg\n"; + print $fh $line; + close $fh; +} + +#------------------------------------------------------------------ + +=head3 perf_log_info + Trace information for perf + Argument: + $msg (trace message) +=cut + +#----------------------------------------------------------------- +sub perf_log_info +{ + shift; + my $msg = shift; + _perf_log('info', $msg); +} + +#------------------------------------------------------------------ + +=head3 perf_log_process + Trace process information for perf + Arguments: + $process_type (immediate, plugin, etc) + $req (xcat reqeust) + $msg (additional message, optional) +=cut + +#----------------------------------------------------------------- +sub perf_log_process +{ + shift; + my ($process_type, $req, $msg, $pid) = @_; + if (defined($req)) { + my $command = $req->{command}->[0]; + _perf_log($process_type, "$$\t$command\t$msg"); + } else { + _perf_log($process_type, "$pid\t$msg"); + } +} + 1; diff --git a/perl-xCAT/xCAT/NetworkUtils.pm b/perl-xCAT/xCAT/NetworkUtils.pm index a66576cf4..d54bf253b 100755 --- a/perl-xCAT/xCAT/NetworkUtils.pm +++ b/perl-xCAT/xCAT/NetworkUtils.pm @@ -19,8 +19,7 @@ use File::Path; use Math::BigInt; use Socket; use xCAT::GlobalDef; - -#use Data::Dumper; +use Sys::Hostname; use strict; use warnings "all"; my $socket6support = eval { require Socket6 }; @@ -229,6 +228,9 @@ sub gethostname() hostname Optional: GetNumber=>1 (return the address as a BigInt instead of readable string) + GetAllAddresses=>1 (return the ) + OnlyV6=>1 () + OnlyV4=> () Returns: ip address Globals: cache: %::hostiphash @@ -270,69 +272,117 @@ sub getipaddr # #pass in an ip and only want an ip?? # return $iporhost; #} + my $isip=0; + if ($iporhost and ($iporhost =~ /\d+\.\d+\.\d+\.\d+/) || ($iporhost =~ /:/)){ + $isip=1; + } + + +#print "============================\n"; +#print Dumper(\%::hostiphash); +#print "\n"; +#print Dumper(\%extraarguments); +#print "\n"; +#print "iporhost=$iporhost"; +#print "\n"; +#print "============================\n"; #cache, do not lookup DNS each time - if ($::hostiphash and defined($::hostiphash{$iporhost}) && $::hostiphash{$iporhost}) + if ( + ((not $extraarguments{OnlyV6}) and (not $extraarguments{GetAllAddresses})) and defined($::hostiphash{$iporhost}) and $::hostiphash{$iporhost}) { - return $::hostiphash{$iporhost}; + + if($extraarguments{GetNumber} ) { + if($::hostiphash{$iporhost}{Number}){ + #print "YYYYYYYYYY GetNumber Cache Hit!!!YYYYYYYYY\n"; + return $::hostiphash{$iporhost}{Number}; + } + } elsif($::hostiphash{$iporhost}{hostip}) { + #print "YYYYYYYYYY dns Cache Hit!!!YYYYYYYYY\n"; + return $::hostiphash{$iporhost}{hostip}; + } + } + + if ($socket6support) # the getaddrinfo and getnameinfo supports both IPv4 and IPv6 + { + my @returns; + my $reqfamily = AF_UNSPEC; + if ($extraarguments{OnlyV6}) { + $reqfamily = AF_INET6; + } elsif ($extraarguments{OnlyV4}) { + $reqfamily = AF_INET; + } + my @addrinfo; + if($isip) { + @addrinfo=Socket6::getaddrinfo($iporhost, 0, $reqfamily, SOCK_STREAM, 6,Socket6::AI_NUMERICHOST()); + }else{ + @addrinfo=Socket6::getaddrinfo($iporhost, 0, $reqfamily, SOCK_STREAM, 6); + } + my ($family, $socket, $protocol, $ip, $name) = splice(@addrinfo, 0, 5); + unless($reqfamily == AF_INET6){ + if($isip){ + if($name){ + $::hostiphash{$iporhost}{hostip}=$name; + } + }elsif($ip){ + $::hostiphash{$iporhost}{hostip}=$ip; + } + } + while ($ip) + { + if ($extraarguments{GetNumber}) { #return a BigInt for compare, e.g. for comparing ip addresses for determining if they are in a common network or range + my $ip = (Socket6::getnameinfo($ip, Socket6::NI_NUMERICHOST()))[0]; + my $bignumber = Math::BigInt->new(0); + foreach (unpack("N*", Socket6::inet_pton($family, $ip))) { #if ipv4, loop will iterate once, for v6, will go 4 times + $bignumber->blsft(32); + $bignumber->badd($_); + } + push(@returns, $bignumber); + $::hostiphash{$iporhost}{Number}=$returns[0]; + } else { + push @returns, (Socket6::getnameinfo($ip, Socket6::NI_NUMERICHOST()))[0]; + $::hostiphash{$iporhost}{hostip}=$returns[0]; + } + if (scalar @addrinfo and $extraarguments{GetAllAddresses}) { + ($family, $socket, $protocol, $ip, $name) = splice(@addrinfo, 0, 5); + } else { + $ip = 0; + } + } + unless ($extraarguments{GetAllAddresses}) { + return $returns[0]; + } + return @returns; } else { - if ($socket6support) # the getaddrinfo and getnameinfo supports both IPv4 and IPv6 - { - my @returns; - my $reqfamily = AF_UNSPEC; - if ($extraarguments{OnlyV6}) { - $reqfamily = AF_INET6; - } elsif ($extraarguments{OnlyV4}) { - $reqfamily = AF_INET; - } - my @addrinfo = Socket6::getaddrinfo($iporhost, 0, $reqfamily, SOCK_STREAM, 6); - my ($family, $socket, $protocol, $ip, $name) = splice(@addrinfo, 0, 5); - while ($ip) - { - if ($extraarguments{GetNumber}) { #return a BigInt for compare, e.g. for comparing ip addresses for determining if they are in a common network or range - my $ip = (Socket6::getnameinfo($ip, Socket6::NI_NUMERICHOST()))[0]; - my $bignumber = Math::BigInt->new(0); - foreach (unpack("N*", Socket6::inet_pton($family, $ip))) { #if ipv4, loop will iterate once, for v6, will go 4 times - $bignumber->blsft(32); - $bignumber->badd($_); - } - push(@returns, $bignumber); - } else { - push @returns, (Socket6::getnameinfo($ip, Socket6::NI_NUMERICHOST()))[0]; - } - if (scalar @addrinfo and $extraarguments{GetAllAddresses}) { - ($family, $socket, $protocol, $ip, $name) = splice(@addrinfo, 0, 5); - } else { - $ip = 0; - } - } - unless ($extraarguments{GetAllAddresses}) { - return $returns[0]; - } - return @returns; - } - else - { - #return inet_ntoa(inet_aton($iporhost)) - #TODO, what if no scoket6 support, but passing in a IPv6 hostname? - if ($iporhost =~ /:/) { #ipv6 - return undef; + #return inet_ntoa(inet_aton($iporhost)) + #TODO, what if no scoket6 support, but passing in a IPv6 hostname? + if ($iporhost =~ /:/) { #ipv6 + return undef; - #die "Attempt to process IPv6 address, but system does not have requisite IPv6 perl support"; - } - my $packed_ip; - $iporhost and $packed_ip = inet_aton($iporhost); - if (!$packed_ip) - { - return undef; - } - if ($extraarguments{GetNumber}) { #only 32 bits, no for loop needed. - return Math::BigInt->new(unpack("N*", $packed_ip)); - } - return inet_ntoa($packed_ip); + #die "Attempt to process IPv6 address, but system does not have requisite IPv6 perl support"; } + my $packed_ip; + $iporhost and $packed_ip = inet_aton($iporhost); + if (!$packed_ip) + { + return undef; + } + + my $myip=inet_ntoa($packed_ip); + + unless($isip) { + $::hostiphash{$iporhost}{hostip}=$myip; + } + + if ($extraarguments{GetNumber}) { #only 32 bits, no for loop needed. + my $number=Math::BigInt->new(unpack("N*", $packed_ip)); + $::hostiphash{$iporhost}{Number}=$number; + return $number; + } + + return $myip; } } @@ -417,7 +467,7 @@ sub linklocaladdr { =cut #------------------------------------------------------------------------------- -sub ishostinsubnet { +sub ishostinsubnet{ my ($class, $ip, $mask, $subnet) = @_; #safe guard @@ -425,6 +475,40 @@ sub ishostinsubnet { { return 0; } + + my $maskType=0; + + #CIDR notation supported + if ($subnet && ($subnet =~ /\//)) { + ($subnet, $mask) = split /\//, $subnet, 2; + $subnet =~ s/\/.*$//; + $maskType=1; + }elsif ($mask) { + if ($mask =~ /\//) { + $mask =~ s/^\///; + $maskType=1; + } elsif($mask =~ /^0x/i ) { + $maskType=2; + } + } + + my $ret=xCAT::NetworkUtils::isInSameSubnet( $ip, $subnet, $mask, $maskType); + if(defined $ret and $ret==1){ + return 1; + }else{ + return 0; + } +} + +sub ishostinsubnet_orig { + my ($class, $ip, $mask, $subnet) = @_; + + #safe guard + if (!defined($ip) || !defined($mask) || !defined($subnet)) + { + return 0; + } + my $numbits = 32; if ($ip =~ /:/) { #ipv6 $numbits = 128; @@ -652,7 +736,7 @@ sub get_nic_ip my %iphash; my $mode = "MULTICAST"; my $payingattention = 0; - my $interface; + my $interface = ""; my $keepcurrentiface; @@ -709,6 +793,7 @@ sub get_nic_ip delete $iphash{$interface}; } $keepcurrentiface = 0; + $interface = ""; if (!($line =~ /LOOPBACK/) and $line =~ /UP( |,|>)/ and $line =~ /$mode/) { @@ -1314,7 +1399,7 @@ sub formatNetmask Returns: 1: they are in same subnet - 2: not in same subnet + undef: not in same subnet Globals: none @@ -1853,16 +1938,13 @@ sub get_subnet_aix sub determinehostname { my $hostname; - my $hostnamecmd = "/bin/hostname"; - my @thostname = xCAT::Utils->runcmd($hostnamecmd, 0); - if ($::RUNCMD_RC != 0) - { # could not get hostname - xCAT::MsgUtils->message("S", - "Error $::RUNCMD_RC from $hostnamecmd command\n"); - exit $::RUNCMD_RC; + eval { + $hostname = hostname; + }; + if($@){ + xCAT::MsgUtils->message("S","Fail to get hostname: $@\n"); + exit -1; } - $hostname = $thostname[0]; - #get all potentially valid abbreviations, and pick the one that is ok #by 'noderange' my @hostnamecandidates; diff --git a/perl-xCAT/xCAT/ProfiledNodeUtils.pm b/perl-xCAT/xCAT/ProfiledNodeUtils.pm index dc351df6a..65cb35804 100644 --- a/perl-xCAT/xCAT/ProfiledNodeUtils.pm +++ b/perl-xCAT/xCAT/ProfiledNodeUtils.pm @@ -1365,7 +1365,7 @@ sub gen_chain_for_profiles { #run bmcsetups. #PowerNV nodes can't use 'runcmd=bmcsetup' to set BMC. - #But OpenPower need to support bmcsetup + #But OpenPOWER need to support bmcsetup my $nodehmtab = xCAT::Table->new('nodehm'); my $comments = ""; my $nodehmtab_entry = $nodehmtab->getNodeAttribs($hwprofile, ['comments']); diff --git a/perl-xCAT/xCAT/Schema.pm b/perl-xCAT/xCAT/Schema.pm index 8adc65980..b53caa87d 100755 --- a/perl-xCAT/xCAT/Schema.pm +++ b/perl-xCAT/xCAT/Schema.pm @@ -446,7 +446,7 @@ passed as argument rather than by table value', openbmc => { cols => [qw(node bmc consport taggedvlan username password comments disable)], keys => [qw(node)], - table_desc => 'Setting for nodes that are controlled by an on-board OpenBmc.', + table_desc => 'Setting for nodes that are controlled by an on-board OpenBMC.', descriptions => { node => 'The node name or group name.', bmc => 'The hostname of the BMC adapter.', @@ -893,8 +893,8 @@ passed as argument rather than by table value', table_desc => 'The scripts that should be run on each node after installation or diskless boot.', descriptions => { node => 'The node name or group name.', - postscripts => 'Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute.', - postbootscripts => 'Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list.', + postscripts => 'Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process. For diskless deployment, the scripts will be run at the init.d time, and xCAT will automatically add the list of scripts from the postbootscripts attribute to run after postscripts list. For installation of AIX, the scripts will run after the reboot and acts the same as the postbootscripts attribute. For AIX, use the postbootscripts attribute. Please note that the postscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postscripts" attribute of a node with "chdef -m" command', + postbootscripts => 'Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. Please note that the postbootscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postbootscripts" attribute of a node with "chdef -m" command', comments => 'Any user-written notes.', disable => "Set to 'yes' or '1' to comment out this row.", }, diff --git a/perl-xCAT/xCAT/Scope.pm b/perl-xCAT/xCAT/Scope.pm index 654e6950a..a7aaf2588 100644 --- a/perl-xCAT/xCAT/Scope.pm +++ b/perl-xCAT/xCAT/Scope.pm @@ -1,8 +1,173 @@ package xCAT::Scope; + use xCAT::Utils; use xCAT::Table; use xCAT::ServiceNodeUtils qw(getSNList); + +#----------------------------------------------------------------------------- + +=head3 split_node_array + + Split a node array into multiple subsets in case to handle them in parallel. + + Arguments: + Reference of source array + Maximum subset number + Default element capacity in each subset + Returns: An array of all subsets + Error: + none + Example: + my $subsets = split_node_array(\@nodes, 5, 250); +=cut + +#----------------------------------------------------------------------------- +sub split_node_array { + my $source = shift; + if ($source =~ /xCAT::Scope/) { + $source = shift; + } + my $max_sub = shift; + my $capacity = shift; + + if ($max_sub < 2) {return [$source];} + + my @dest = (); + my $total = $#{$source} + 1; + my $n_sub = int ($total / $capacity); + unless ($n_sub * $capacity == $total) { $n_sub++;} #POSIX::ceil + + if ( $n_sub <= 1 ) { + # Only 1 subset is enough + $dest[0] = $source; + + } elsif ( $n_sub > $max_sub ) { + # Exceed, then to recaculate the capacity of each subset as we only allow max_sub + $capacity = int ($total / $max_sub); + if ( $total % $max_sub > 0 ) { + $capacity += 1; + } + my $start = $end = 0; + for (1..$max_sub) { + $end = $start + $capacity - 1; + if ( $end > $total - 1 ) { + $end = $total - 1 + } + + my @temp = @$source[$start..$end]; + $dest[$_-1]=\@temp; + $start = $end + 1; + } + + } else { + # Only n_sub subsets are required, split the noderange into each subset + my $start = $end = 0; + for (1..$n_sub) { + $end = $start + $capacity - 1; + if ( $end > $total - 1 ) { + $end = $total - 1 + } + #print "subset #$_: $start to $end"; + my @temp = @$source[$start..$end]; + $dest[$_-1]=\@temp; + $start = $end + 1; + } + } + + return \@dest; +} + +#----------------------------------------------------------------------------- + +=head3 get_parallel_scope + + Convert a request object to an array of multiple requests according to the + splitted node range. + + Arguments: + Reference of request + Maximum subset number: Optional, default is 5 + Default element capacity in each subset: Optional, default is 250 + Returns: An array of requests + Error: + none + Example: + my $reqs = xCAT::Scope->get_parallel_scope($request); +=cut + +#----------------------------------------------------------------------------- +sub get_parallel_scope { + my $req = shift; + if ($req =~ /xCAT::Scope/) { + $req = shift; + } + my ($max_sub, $capacity) = @_; + #TODO, make the value configurable + unless ($max_sub) { $max_sub = 5; } + unless ($capacity) { $capacity = 250; } + + my $subsets = split_node_array(\@{$req->{node}}, $max_sub, $capacity); + # Just return the origin one if node range is not big enough. + if ($#{$subsets} < 1) { return [$req]; } + + my @requests = (); + foreach (@$subsets) { + my $reqcopy = {%$req}; + $reqcopy->{node} = $_; + push @requests, $reqcopy; + } + return \@requests; +} + +#----------------------------------------------------------------------------- + +=head3 get_broadcast_scope_with_parallel + + Convert a request object to an array of multiple requests according to the + splitted node range. + + Arguments: + Reference of request + Callback: TODO, Optional, the Callback will be used to filter the nodes + Returns: An array of requests + Error: + none + Example: + my $reqs = xCAT::Scope->get_broadcast_scope($request); +=cut + +#----------------------------------------------------------------------------- +sub get_broadcast_scope_with_parallel { + my $req = shift; + if ($req =~ /xCAT::Scope/) { + $req = shift; + } + #Exit if the packet has been preprocessed in its history + if ($req->{_xcatpreprocessed}->[0] == 1) { return [$req]; } + + #Handle the one for current management/service node + my $reqs = get_parallel_scope($req); + my @requests = @$reqs; + + #Broadcast the request to other management/service nodes + foreach (xCAT::ServiceNodeUtils->getSNList()) { + if (xCAT::NetworkUtils->thishostisnot($_)) { + my $xcatdest = $_; + my $reqcopy = {%$req}; + $reqcopy->{'_xcatdest'} = $_; + $reqcopy->{_xcatpreprocessed}->[0] = 1; + #Apply callback to filter the node range in future. + $reqs = get_parallel_scope($reqcopy); + foreach (@$reqs) { + push @requests, {%$_}; + } + } + } + return \@requests; +} + + sub get_broadcast_scope { my $req = shift; if ($req =~ /xCAT::Scope/) { diff --git a/perl-xCAT/xCAT/ServiceNodeUtils.pm b/perl-xCAT/xCAT/ServiceNodeUtils.pm index 5daf5c237..c27601874 100755 --- a/perl-xCAT/xCAT/ServiceNodeUtils.pm +++ b/perl-xCAT/xCAT/ServiceNodeUtils.pm @@ -14,7 +14,6 @@ if ($^O =~ /^aix/i) { } use lib "$::XCATROOT/lib/perl"; use strict; - #----------------------------------------------------------------------------- =head3 readSNInfo @@ -353,6 +352,37 @@ sub getSNandNodes #----------------------------------------------------------------------------- sub getSNList +{ + require xCAT::Table; + require xCAT::NodeRange; + my ($class, $service, $options) = @_; + my @servicenodes; + my $servicenodetab = xCAT::Table->new('servicenode'); + my $nodetab = xCAT::Table->new('nodelist'); + unless ($servicenodetab) # no servicenode table + { + xCAT::MsgUtils->message('I', "Unable to open servicenode table.\n"); + $servicenodetab->close; + return @servicenodes; + } + + + if($service){ + @servicenodes = $servicenodetab->getAllAttribsWhere(["$service==1"],'node'); + }else{ + @servicenodes = $servicenodetab->getAllAttribs(('node')); + } + + @servicenodes=xCAT::NodeRange::noderange(join(',',map {$_->{node}} @servicenodes)); + if($options eq "ALL"){ + return @servicenodes; + } + + @servicenodes = $nodetab->getAllAttribsWhere("node in ("."\'".join("\',\'", @servicenodes)."\'".") and groups not like '%__mgmtnode%'",'node'); + return map {$_->{node}} @servicenodes; +} + +sub getSNList_orig { require xCAT::Table; my ($class, $service, $options) = @_; @@ -367,6 +397,7 @@ sub getSNList } my @nodes = $servicenodetab->getAllNodeAttribs([$service]); $servicenodetab->close; + foreach my $node (@nodes) { if (!defined($service) || ($service eq "")) # want all the service nodes diff --git a/perl-xCAT/xCAT/Usage.pm b/perl-xCAT/xCAT/Usage.pm index 9a0600d1b..c452d6bfa 100755 --- a/perl-xCAT/xCAT/Usage.pm +++ b/perl-xCAT/xCAT/Usage.pm @@ -29,10 +29,10 @@ my %usage = ( BMC (using IPMI): rpower noderange [on|off|softoff|reset|boot|stat|state|status|wake|suspend [-w timeout] [-o] [-r]] rpower noderange [pduon|pduoff|pdustat] - OpenPower BMC: + OpenPOWER BMC: rpower noderange [on|off|reset|boot|stat|state|status] rpower noderange [pduon|pduoff|pdustat] - OpenPower OpenBMC: + OpenPOWER OpenBMC: rpower noderange [on|off|reset|boot|stat|state|status] KVM Virtualization specific: rpower [boot] [ -c ] @@ -81,8 +81,10 @@ my %usage = ( rvitals noderange {temp|wattage|fanspeed|leds|summary|all} BMC specific: rvitals noderange {temp|voltage|wattage|fanspeed|power|leds|all} - OpenPOWER server specific: - rvitals noderange [temp|voltage|wattage|fanspeed|power|leds|all] + OpenPOWER (IPMI) specific: + rvitals noderange [temp|voltage|wattage|fanspeed|power|leds|chassis|all] + OpenPOWER (OpenBMC) specific: + rvitals noderange [temp|voltage|wattage|fanspeed|power|altitude|all] MIC specific: rvitals noderange {thermal|all}", "reventlog" => @@ -93,14 +95,12 @@ my %usage = ( Common: rinv [all|model|serial] [-V|--verbose] rinv [-h|--help|-v|--version] - BMC specific: - rinv [mprom|deviceid|uuid|guid|vpd|dimm|all] - OpenPOWER (using ipmi) server specific: + BMC/MPA specific: + rinv [model|serial|asset|vpd|deviceid|guid|firm|dimm|mprom|all] + OpenPOWER (IPMI) server specific: rinv [model|serial|deviceid|uuid|guid|vpd|mprom|firm|all] - OpenPOWER (using openbmc) server specific: - rinv [model|serial|deviceid|uuid|guid|vpd|mprom|firm|cpu|dimm|all] - MPA specific: - rinv [firm|bios|diag|mprom|sprom|mparom|mac|mtm] + OpenPOWER (OpenBMC) server specific: + rinv [model|serial|firm|cpu|dimm|all] [-V|--verbose] PPC specific(with HMC): rinv [all|bus|config|serial|model|firm] PPC specific(using Direct FSP Management): @@ -622,3 +622,41 @@ sub parseCommand { return ""; } +#------------------------------------------------------------------------------ + +=head3 validateArgs + This function validates the arguments of the specified command + Arguments: + command + arguments(array @) + Returns: + $ref: a reference to array of [$retcode(integer),$info(string)] + $ref->[0]=0 : validation passed + $ret->[0]!=0: validation failed, the error info is returned in $ref->[1] + +=cut + +#------------------------------------------------------------------------------- + +sub validateArgs { + my $command=shift; + if ($command =~ /xCAT::Usage/) { $command = shift; } + + my $count=0; + my @extrargs=@_; + if($command =~ m/^(nodeset|rinstall|winstall)$/ ){ + #suppose that argument like "-p foo" have been processed and + #filtered by GetOpt subroutine + #fortunately the commands in this branch does not have such options + foreach(@extrargs){ + if($_ !~ m/^-[-]?\S+/){ + $count+=1; + } + } + if ($count!=1) { + return [1,"Invalid argument: '".join(" ",@extrargs)."'"]; + } + } + + return [0]; +} diff --git a/perl-xCAT/xCAT/Utils.pm b/perl-xCAT/xCAT/Utils.pm index a39ea8bb2..ea107f482 100644 --- a/perl-xCAT/xCAT/Utils.pm +++ b/perl-xCAT/xCAT/Utils.pm @@ -579,6 +579,69 @@ sub Version return $version; } +#------------------------------------------------------------------------------- + +=head3 get_conserver_version + Returns: + consever version number like 8.1.16, undef if error happens + Globals: + none + Error: + none + Example: + $version=xCAT::Utils->get_conserver_version(); + Comments: + none +=cut + +#------------------------------------------------------------------------------- +sub get_conserver_version +{ + my $cmd = "/usr/sbin/conserver -V"; + # output format: + # conserver: conserver.com version 8.2.1 + # conserver: default access type `r' + my @out = xCAT::Utils->runcmd("$cmd", 0); + if ($::RUNCMD_RC != 0 || @out < 1) { + return undef; + } + my @parts = split(' ',$out[0]); + if (@parts < 4) { + return undef; + } + my @count = $parts[3] =~ /\./g; + if (@count < 2) { + return undef; + } + return $parts[3]; +} + +#------------------------------------------------------------------------------- + +=head3 calc_conserver_version + Arguments: + version in string format + Returns: + version number + Globals: + none + Error: + none + Example: + $version=xCAT::Utils->calc_conserver_version("8.2.1"); + Comments: + none +=cut + +#------------------------------------------------------------------------------- +sub calc_conserver_version +{ + my $ver_str = shift; + my @vers = split(/\./, $ver_str); + return int($vers[2]) + int($vers[1]) * 10000 + int($vers[0]) * 100000000; +} + + #------------------------------------------------------------------------------- =head3 make_node_list_file @@ -3306,10 +3369,25 @@ sub isSELINUX =cut #------------------------------------------------------------------------------- + + sub noderangecontainsMn { my ($class, @noderange) = @_; + # check if any node in the noderange is the Management Node return the + # name + my @mnames; # management node names in the database, members of __mgmtnode + my $tab = xCAT::Table->new('nodelist'); + + my @nodelist = $tab->getAllAttribsWhere("node in ("."\'".join("\',\'", @noderange)."\'".") and groups like '%__mgmtnode%'",'node'); + return map {$_->{node}} @nodelist; # if no MN in the noderange, return nothing +} + +sub noderangecontainsMn_orig +{ + my ($class, @noderange) = @_; + # check if any node in the noderange is the Management Node return the # name my @mnames; # management node names in the database, members of __mgmtnode diff --git a/perl-xCAT/xCAT/data/discinfo.pm b/perl-xCAT/xCAT/data/discinfo.pm index 75274be3e..c3432566a 100755 --- a/perl-xCAT/xCAT/data/discinfo.pm +++ b/perl-xCAT/xCAT/data/discinfo.pm @@ -11,8 +11,9 @@ require Exporter; @EXPORT = qw(); @EXPORT_OK = qw(distnames numdiscs); +use strict; -my %distnames = ( +our %distnames = ( "1480943823.812754" => "centos7.3", #x86_64 "1450147276.351714" => "centos7.2", #ppc64le "1449699925.561114" => "centos7.2", #x86_64 @@ -135,7 +136,7 @@ my %distnames = ( "1394111947.452332" => "pkvm2.1", # ppc64, PowerKVM "1413749127.352649" => "pkvm2.1.1", # ppc64, PowerKVM ); -my %numdiscs = ( +our %numdiscs = ( "1156364963.862322" => 4, "1178480581.024704" => 3 ); diff --git a/perl-xCAT/xCAT/data/switchinfo.pm b/perl-xCAT/xCAT/data/switchinfo.pm new file mode 100644 index 000000000..79c36abfa --- /dev/null +++ b/perl-xCAT/xCAT/data/switchinfo.pm @@ -0,0 +1,45 @@ +# IBM(c) 2007 EPL license http://www.eclipse.org/legal/epl-v10.html + +#This module includes some glocal table to look up the switch type via mac and vendor + +package xCAT::data::switchinfo; + +require Exporter; +@ISA = qw(Exporter); +@EXPORT = qw(); +@EXPORT_OK = qw(global_mac_identity global_switch_type); + +use strict; + +#the hash to look up switch type with MAC +our %global_mac_identity = ( + "a8:97:dc" => "BNT G8052 switch", + "6c:ae:8b" => "BNT G8264-T switch", + "fc:cf:62" => "BNT G8124 switch", + "7c:fe:90" => "Mellanox IB switch", + "cc:37:ab" => "Edgecore Networks Switch", + "8c:ea:1b" => "Edgecore Networks Switch" +); + +#the hash to lookup switch type with vendor +our %global_switch_type = ( + Juniper => "Juniper", + juniper => "Juniper", + Cisco => "Cisco", + cisco => "Cisco", + BNT => "BNT", + Blade => "BNT", + G8052 => "BNT", + RackSwitch => "BNT", + Mellanox => "Mellanox", + mellanox => "Mellanox", + MLNX => "Mellanox", + MELLAN => "Mellanox", + Cumulus => "onie", + cumulus => "onie", + Edgecore => "onie" +); + + + +1; diff --git a/xCAT-OpenStack/postscripts/configgw b/xCAT-OpenStack/postscripts/configgw index 36c246eaf..e2b97be77 100755 --- a/xCAT-OpenStack/postscripts/configgw +++ b/xCAT-OpenStack/postscripts/configgw @@ -9,7 +9,7 @@ if [ -z "$1" ];then fi str_nic_name=$1 -str_ip_mask=`ip addr show dev $str_nic_name | grep inet | grep -v inet6 | awk '{print $2}' | head -n 1` +str_ip_mask=`ip -4 -o addr show dev $str_nic_name | awk '{print $4}' | head -n 1` str_ip=`echo $str_ip_mask | awk -F'/' '{print $1}'` str_mask=`echo $str_ip_mask | awk -F'/' '{print $2}'` diff --git a/xCAT-client/bin/rcons b/xCAT-client/bin/rcons index 2fa148d6a..c5b1b78df 100755 --- a/xCAT-client/bin/rcons +++ b/xCAT-client/bin/rcons @@ -87,7 +87,7 @@ if [ $USE_CONFLUENT == "1" ] && ([ -x "/opt/confluent/bin/confetty" ] || [ -x "/ fi if [ -z "$CONSERVER" ]; then CONSERVER=`nodels $1 nodehm.conserver 2>/dev/null | awk -F: '{print $2}' | tr -d ' '` - declare -a ipaddrs=`ip addr | grep 'inet' | awk {'print $2'} | cut -d/ -f1 | grep -v : | tr '\n' ' '` + declare -a ipaddrs=`ip -o a | awk {'print $4'} | cut -d/ -f1 | grep -v : | tr '\n' ' '` for IP in ${ipaddrs[*]}; do if [[ "${CONSERVER}" == "${IP}" ]]; then # conserver is the same node, do not connect using -s @@ -127,12 +127,22 @@ elif [ -f "/usr/bin/console" ] || [ -f "/bin/console" ]; then #NOTE: IPv6 is not good with the below if going by IP, needs more sophisticated #parsing CONSERVER=`echo $CONSERVER|cut -d: -f 1` - + CONSOLE_VER=`console -V | awk '/conserver.com version/ {print $4}'` #Detect console support of SSL, only fixup consolerc if encryption is detected if ! console -h 2>&1 | grep "encryption not compiled" > /dev/null; then # generate .consolerc if it does not exist or is empty if [ ! -s $HOME/.consolerc ]; then - cat > $HOME/.consolerc << EOF + if [ "$CONSOLE_VER" != "8.1.16" ]; then + cat > $HOME/.consolerc << EOF +config * { + port 782; + sslenabled yes; + sslcacertificatefile $HOME/.xcat/ca.pem; + sslcredentials $HOME/.xcat/client-cred.pem; +} +EOF + else + cat > $HOME/.consolerc << EOF config * { port 782; sslenabled yes; @@ -140,6 +150,7 @@ config * { sslcredentials $HOME/.xcat/client-cred.pem; } EOF + fi fi else # ssl is not enabled, comment out the ssl settings in .consolerc @@ -147,7 +158,10 @@ EOF sed -i 's/\Wssl/#ssl/1' $HOME/.consolerc fi fi - + # for migration, upgrade conserver + if [ "$CONSOLE_VER" != "8.1.16" ]; then + sed -i 's/sslauthority/sslcacertificatefile/1' $HOME/.consolerc + fi exec console $FORCE -M $CONSERVER $1 else if [[ "$FORCE" == "-s" ]]; then diff --git a/xCAT-client/pods/man1/bmcdiscover.1.pod b/xCAT-client/pods/man1/bmcdiscover.1.pod index 3d4058f51..2e967fab5 100644 --- a/xCAT-client/pods/man1/bmcdiscover.1.pod +++ b/xCAT-client/pods/man1/bmcdiscover.1.pod @@ -17,7 +17,7 @@ B [B<-u> I] [B<-p> I] B<-i> I B<--ips =head1 DESCRIPTION -The B command will discover Baseboard Management Controllers (BMCs) using a scan mathod. +The B command will discover Baseboard Management Controllers (BMCs) using a scan method. The command uses B to scan active nodes over a specified IP range. The IP range format should be a format that is acceptable by B. @@ -31,7 +31,7 @@ Note: The scan method currently support is B. =item B<--range> -Specify one or more IP ranges acceptable to nmap. IP rance can be hostnames, IP addresses, networks, etc. A single IP address (10.1.2.3) or an IP range (10.1.2.0/24) can be specified. If the range is very large, the B command may take a long time to return. +Specify one or more IP ranges acceptable to nmap. IP range can be hostnames, IP addresses, networks, etc. A single IP address (10.1.2.3) or an IP range (10.1.2.0/24) can be specified. If the range is very large, the B command may take a long time to return. =item B<-s> diff --git a/xCAT-client/pods/man1/cfgve.1.pod b/xCAT-client/pods/man1/cfgve.1.pod index 93c8dbc60..e2df6268f 100644 --- a/xCAT-client/pods/man1/cfgve.1.pod +++ b/xCAT-client/pods/man1/cfgve.1.pod @@ -81,7 +81,7 @@ The NFS export directory must be configured for read write access and must be owned by vdsm:kvm. B: "/data/images/rhev" is set by default. -B - A host must be specified for a storage doamin as SPM +B - A host must be specified for a storage domain as SPM (Storage Pool Manager) when initialize the storage domain. The role of SPM may be migrated to other host by rhev-m during the running of the datacenter (For example, when the current SPM encountered issue or going to maintenance diff --git a/xCAT-client/pods/man1/chvm.1.pod b/xCAT-client/pods/man1/chvm.1.pod index 99ec573f7..f1ac27855 100644 --- a/xCAT-client/pods/man1/chvm.1.pod +++ b/xCAT-client/pods/man1/chvm.1.pod @@ -114,7 +114,7 @@ This command also supports to change specific partition attributes by specifying For Power 755(use option I<--p775> to specify): -chvm could be used to change the octant configuration values for generating LPARs. chvm is designed to set the Octant configure value to split the CPU and memory for partitions, and set Octant Memory interleaving value. The chvm will only set the pending attributes value. After chvm, the CEC needs to be rebooted manually for the pending values to be enabled. Before reboot the cec, the administrator can use chvm to change the partition plan. If the the partition needs I/O slots, the administrator should use chvm to assign the I/O slots. +chvm could be used to change the octant configuration values for generating LPARs. chvm is designed to set the Octant configure value to split the CPU and memory for partitions, and set Octant Memory interleaving value. The chvm will only set the pending attributes value. After chvm, the CEC needs to be rebooted manually for the pending values to be enabled. Before reboot the cec, the administrator can use chvm to change the partition plan. If the partition needs I/O slots, the administrator should use chvm to assign the I/O slots. chvm is also designed to assign the I/O slots to the new LPAR. Both the current IO owning lpar and the new IO owning lpar must be powered off before an IO assignment. Otherwise, if the I/O slot is belonged to an Lpar and the LPAR is power on, the command will return an error when trying to assign that slot to a different lpar. @@ -127,7 +127,7 @@ chvm could be used to modify the resources assigned to partitions. The admin sha =head2 zVM specific: -The chvm command modifes the virtual machine's configuration specified in noderange. +The chvm command modifies the virtual machine's configuration specified in noderange. =head1 OPTIONS @@ -248,7 +248,7 @@ Purge the Hard disk. Deregisters and deletes the files. Multiple can be done w =item B<--resize> I=I -Change the size of the Hard disk. The disk in I format can not be set to less than it's current size. The disk in I format can be resized smaller, use caution. Multiple disks can be resized by using comma separated IB<=>I pairs. The disks are specified by SCSI id. Size defaults to GB. +Change the size of the Hard disk. The disk in I format can not be set to less than its current size. The disk in I format can be resized smaller, use caution. Multiple disks can be resized by using comma separated IB<=>I pairs. The disks are specified by SCSI id. Size defaults to GB. =back diff --git a/xCAT-client/pods/man1/csm2xcat.1.pod b/xCAT-client/pods/man1/csm2xcat.1.pod index fc1f66411..dffc47c79 100644 --- a/xCAT-client/pods/man1/csm2xcat.1.pod +++ b/xCAT-client/pods/man1/csm2xcat.1.pod @@ -11,7 +11,7 @@ B [B<-h>] =head1 DESCRIPTION -The csm2xcat command must be run on the Management Server of the CSM system that you want to migrate to xCAT. The commmand will build two xCAT stanza files that can update the xCAT database with the chdef command. +The csm2xcat command must be run on the Management Server of the CSM system that you want to migrate to xCAT. The command will build two xCAT stanza files that can update the xCAT database with the chdef command. Copy the csm2xcat command to the CSM Management Server. Run the command, indicating where you want your stanza files saved with the B<--dir> parameter. Check the stanza files to see if the information is what you want put in the xCAT database. Copy the two stanza files: node.stanza, device.stanza back to your xCAT Management node, and run the chdef command to input into the xCAT database. diff --git a/xCAT-client/pods/man1/db2sqlsetup.1.pod b/xCAT-client/pods/man1/db2sqlsetup.1.pod index 4bf2768de..8d9e9f059 100644 --- a/xCAT-client/pods/man1/db2sqlsetup.1.pod +++ b/xCAT-client/pods/man1/db2sqlsetup.1.pod @@ -28,7 +28,7 @@ For full information on the setup of DB2, see Setting_Up_DB2_as_the_xCAT_DB. When running of db2sqlsetup on the MN: One password must be supplied for the setup, a password for the xcatdb unix id which will be used as the DB2 instance id and database name. The password will be prompted for interactively or can be input with the XCATDB2PW environment variable. -The script will create the xcat database instance (xcatdb) in the /var/lib/db2 directory unless overriden by setting the site.databaseloc attribute. This attribute should not be set to the directory that is defined in the installloc attribute and it is recommended that the databaseloc be a new filesystem dedicated to the DB2 database, especially in very large clusters. +The script will create the xcat database instance (xcatdb) in the /var/lib/db2 directory unless overridden by setting the site.databaseloc attribute. This attribute should not be set to the directory that is defined in the installloc attribute and it is recommended that the databaseloc be a new filesystem dedicated to the DB2 database, especially in very large clusters. When running db2sqlseutp on the SN: Not only will the password for the DB2 instance Id be prompted for and must match the one on the Management Node; but also the hostname or ip address of the Management Node as known by the Service Node must be supplied , unless the XCATDB2SERVER environment variable is set. diff --git a/xCAT-client/pods/man1/dumpxCATdb.1.pod b/xCAT-client/pods/man1/dumpxCATdb.1.pod index b9e155a08..fbdf7e392 100644 --- a/xCAT-client/pods/man1/dumpxCATdb.1.pod +++ b/xCAT-client/pods/man1/dumpxCATdb.1.pod @@ -17,7 +17,7 @@ If not using the binary dump option (-b), then the dumpxCATdb command creates .c Supports using XCAT_SKIPTABLES env variable to provide a list of skip tables. The command will never backup TEAL or ISNM tables, except isnm_config. To dump TEAL tables use the documented process for TEAL. For ISNM use tabdump, after using tabprune to get to prune unnecessary records. -If using the binary dump option for the DB2 or postgreSQL database, then the routine will use the Database provide utilites for backup of the entire database. +If using the binary dump option for the DB2 or postgreSQL database, then the routine will use the Database provide utilities for backup of the entire database. =head1 OPTIONS @@ -28,7 +28,7 @@ B<-v> Command Version. B<-V> Verbose. -B<-a> All,without this flag the eventlog and auditlog will be skipped. +B<-a> All, without this flag the eventlog and auditlog will be skipped. B<-b> This flag is only used for the DB2 or postgreSQL database. The routine will use the database backup utilities to create a binary backup of the entire database. Note to use this backup on DB2, you will have first had to modify the logging of the database and have taken an offline initial backup. Refer to the xCAT DB2 documentation for more instructions. diff --git a/xCAT-client/pods/man1/genimage.1.pod b/xCAT-client/pods/man1/genimage.1.pod index 7d2414604..bc4f09d8b 100644 --- a/xCAT-client/pods/man1/genimage.1.pod +++ b/xCAT-client/pods/man1/genimage.1.pod @@ -29,7 +29,7 @@ for stateless: B for statelite: B -Besides prompting for some paramter values, the B command takes default guesses for the parameters not specified or not defined in the I and I tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Use B<--interactive> flag if you want the yum/zypper command to prompt you for the answers. +Besides prompting for some parameter values, the B command takes default guesses for the parameters not specified or not defined in the I and I tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Use B<--interactive> flag if you want the yum/zypper command to prompt you for the answers. If B<--onlyinitrd> is specified, genimage only regenerates the initrd for a stateless image to be used for a diskless install. diff --git a/xCAT-client/pods/man1/geninitrd.1.pod b/xCAT-client/pods/man1/geninitrd.1.pod index fce267474..f2d4cfc7a 100644 --- a/xCAT-client/pods/man1/geninitrd.1.pod +++ b/xCAT-client/pods/man1/geninitrd.1.pod @@ -26,7 +26,7 @@ If the initrd has been rebuilt by geninitrd, when run nodeset, the I<--noupdatei should be used to skip the rebuilding of initrd to improve the performance. Three attributes of osimage object can be used to specify the Driver RPM location and Driver names -for injecting new drviers to initrd. +for injecting new drivers to initrd. B - comma separated driver names that need to be injected to the initrd. The postfix '.ko' can be ignored. The netdrivers attribute must be set to specify the new driver list. @@ -51,7 +51,7 @@ this command is used to generate the initrd from the rootimg which generated by So the 'genimage' must be run once before running the geninitrd command. Two attributes of osimage object can be used to specify the Driver RPM location and Driver names -for injecting new drviers to initrd. +for injecting new drivers to initrd. B - comma separated driver names that need to be injected to the initrd. The postfix '.ko' can be ignored. The netdrivers attribute must be set to specify the new driver list. @@ -64,7 +64,7 @@ B - comma separated driver rpm packages (full path should be sp =head1 Parameters -I specifies the name of an os image definition to be used. The specification for the image is storted in the I table and I table. +I specifies the name of an os image definition to be used. The specification for the image is stored in the I table and I table. =over 12 diff --git a/xCAT-client/pods/man1/getadapter.1.pod b/xCAT-client/pods/man1/getadapter.1.pod index 0c10af7a1..0bdb93c42 100644 --- a/xCAT-client/pods/man1/getadapter.1.pod +++ b/xCAT-client/pods/man1/getadapter.1.pod @@ -12,24 +12,35 @@ B [B<-h>|B<--help>|B<-v>|B<--version>|B<-V>] Traditionally, network interfaces in Linux are enumerated as eth[0123...], but these names do not necessarily correspond to actual labels on the chassis. B help customer to get predictable network device name and some other network adapter information before provision or network configuration. -B use genesis to collect network adapters information, so that mean it need to restart the target node. +B B For each node within the , follows below scheme: -If the target node is scaned for the first time, B will trigger genesis to collect information then save the information at the B column of nics table. -If the target node has ever been scaned, B will use the information from nics table first. +If the target node is scanned for the first time, B will trigger genesis to collect information then save the information at the B column of nics table. +If the target node has ever been scanned, B will use the information from nics table first. If user hopes to scan the adapter information for the node but these information already exist, B<-f> option can be used to start rescan process. B tries to collect more information for the target network device, but doesn't guarantee collect same much information for every network device. -Below are the possible information can be collect up to now: -B: the consistent name which can be used by confignic directly in operating system which follow the same naming scheme with rhels7 -B: the pci location -B: the MAC address -B: All the names which satisfy predictable network device naming scheme. I<(if xcat enhance confignic command later, user can use these names to configure their network adapter, even customize their name)> -B: the vender of network device -B: the model of network device -B: the link state of network device +=head1 B + +=over 2 + +=item B: the consistent name which can be used by confignic directly in operating system which follow the same naming scheme with rhels7 + +=item B: the pci location + +=item B: the MAC address + +=item B: All the names which satisfy predictable network device naming scheme. I<(if xcat enhance confignic command later, user can use these names to configure their network adapter, even customize their name)> + +=item B: the vender of network device + +=item B: the model of network device + +=item B: the link state of network device + +=back =head1 OPTIONS diff --git a/xCAT-client/pods/man1/getmacs.1.pod b/xCAT-client/pods/man1/getmacs.1.pod index 68572339f..8bbbb8d17 100644 --- a/xCAT-client/pods/man1/getmacs.1.pod +++ b/xCAT-client/pods/man1/getmacs.1.pod @@ -23,12 +23,12 @@ B I [B<-V>| B<--verbose>] [B<-d>] [B<--arp>] [B<-i> I =head1 DESCRIPTION The getmacs command collects MAC address from a single or range of nodes. -Note that on AIX systems, the returned MAC address is not colon-seperated (for example 8ee2245cf004), while on Linux systems the MAC address is colon-seperated (for example 8e:e2:24:5c:f0:04). +Note that on AIX systems, the returned MAC address is not colon-separated (for example 8ee2245cf004), while on Linux systems the MAC address is colon-separated (for example 8e:e2:24:5c:f0:04). If no ping test performed, getmacs writes the first adapter MAC to the xCAT database. If ping test performed, getmacs will write the first successfully pinged MAC to xCAT database. For PPC (using Direct FSP Management) specific: -Note: If network adapters are physically assigned to LPARs, getmacs cannot read the MAC addresses unless perform B with option "B<-D>", since there is no HMC command to read them and getmacs has to login to open formware. And if the LPARs has never been activated before, getmacs need to be performed with the option "B<-D>" to get theirs MAC addresses. +Note: If network adapters are physically assigned to LPARs, getmacs cannot read the MAC addresses unless perform B with option "B<-D>", since there is no HMC command to read them and getmacs has to login to open firmware. And if the LPARs has never been activated before, getmacs need to be performed with the option "B<-D>" to get theirs MAC addresses. For PPC (using HMC) specific: @@ -42,7 +42,7 @@ Note: If "B<-d>" is specified, all the MAC of the blades will be displayed. If n B<--arp> -Read MAC address with ARP protocal. +Read MAC address with ARP protocol. B<-C> @@ -58,7 +58,7 @@ Perform discovery for mac address. By default, it will run ping test to test th B<-f> -Force immediate shutdown of the partition.This flag must be used with -D flag. +Force immediate shutdown of the partition. This flag must be used with -D flag. B<-F> @@ -86,7 +86,7 @@ Read MAC address when the lpar is in openfirmware state. This option mush be us B<-S> -The IP address of the machine to ping. The default is to read from xCAT databse if no B<-S> specified. +The IP address of the machine to ping. The default is to read from xCAT database if no B<-S> specified. B<-v> @@ -122,7 +122,7 @@ Output is similar to: ent U78A1.001.99203B5-P1-T6 00145eb55788 /lhea@23c00614/ethernet@23e00514 unsuccessful physical -2. To retrieve the MAC address with ARP protocal: +2. To retrieve the MAC address with ARP protocol: getmacs lpar4 --arp diff --git a/xCAT-client/pods/man1/groupfiles4dsh.1.pod b/xCAT-client/pods/man1/groupfiles4dsh.1.pod index 171b99978..7f2281eba 100644 --- a/xCAT-client/pods/man1/groupfiles4dsh.1.pod +++ b/xCAT-client/pods/man1/groupfiles4dsh.1.pod @@ -15,7 +15,7 @@ This tool will build a directory of files, one for each defined nodegroup in xCAT. The file will be named the nodegroup name and contain a list of nodes that belong to the nodegroup. The file can be used as input to the AIX dsh command. -The purpose of this tool is to allow backward compatiblity with scripts +The purpose of this tool is to allow backward compatibility with scripts that were created using the AIX or CSM dsh command Reference: man dsh. diff --git a/xCAT-client/pods/man1/imgexport.1.pod b/xCAT-client/pods/man1/imgexport.1.pod index a2376df26..0e535a57b 100644 --- a/xCAT-client/pods/man1/imgexport.1.pod +++ b/xCAT-client/pods/man1/imgexport.1.pod @@ -45,7 +45,7 @@ For statelite: where x is the name of the profile. -Any files specified by the B<-e> flag will also be exported. If B<-p> flag is specified, the names of the postscripts and the postbootscripts for the given node will be exported. The postscripts themsleves need to be manualy exported using B<-e> flag. +Any files specified by the B<-e> flag will also be exported. If B<-p> flag is specified, the names of the postscripts and the postbootscripts for the given node will be exported. The postscripts themselves need to be manualy exported using B<-e> flag. For statelite, the litefile table settings for the image will also be exported. The litetree and statelite tables are not exported. diff --git a/xCAT-client/pods/man1/imgimport.1.pod b/xCAT-client/pods/man1/imgimport.1.pod index f652f9d74..2757ee48a 100644 --- a/xCAT-client/pods/man1/imgimport.1.pod +++ b/xCAT-client/pods/man1/imgimport.1.pod @@ -50,7 +50,7 @@ If B<-p> flag is specified, the I table will be updated with the po If B<-f> flag is not specified, all the files will be copied to the same directories as the source. If it is specified, the old profile name x will be changed to the new and the files will be copied to the appropriate directores for the new profiles. For example, I will be copied to I and I will be copied to I. This flag is commonly used when you want to copy the image on the same xCAT mn so you can make modification on the new one. -After this command, you can run the B command and then start deploying the nodes. You can also choose to modify the files and run the following commands before the node depolyment. +After this command, you can run the B command and then start deploying the nodes. You can also choose to modify the files and run the following commands before the node deployment. For stateful: nodeset diff --git a/xCAT-client/pods/man1/liteimg.1.pod b/xCAT-client/pods/man1/liteimg.1.pod index 4a98c114a..9f8ed39ff 100644 --- a/xCAT-client/pods/man1/liteimg.1.pod +++ b/xCAT-client/pods/man1/liteimg.1.pod @@ -41,7 +41,7 @@ Note: If you make any changes to your litefile table after running liteimg then =head1 PARAMETERS -I specifies the name of a os image definition to be used. The specification for the image is storted in the I table and I table. +I specifies the name of a os image definition to be used. The specification for the image is stored in the I table and I table. =head1 OPTIONS diff --git a/xCAT-client/pods/man1/lsflexnode.1.pod b/xCAT-client/pods/man1/lsflexnode.1.pod index bcb1a2c93..4fa436316 100644 --- a/xCAT-client/pods/man1/lsflexnode.1.pod +++ b/xCAT-client/pods/man1/lsflexnode.1.pod @@ -22,7 +22,7 @@ There are several concepts to support the HX5 multiple blades combination: B: Multiple blades which combined by a scalability card is a complex. -B: A logic concept which containing part of the B in a complex. Each partition can map to a system to install Operating System. Each partition could have 1HX5, 1HX5+1MD or 2HX5+2MD. (MD is the Memory Drawer) +B: A logic concept which containing part of the B in a complex. Each partition can map to a system to install Operating System. Each partition could have 1HX5, 1HX5+1MD or 2HX5+2MD. (MD is the Memory Drawer) B: The physical blade which installed in the slot of a chassis. It can be a HX5 or MD. diff --git a/xCAT-client/pods/man1/lskitcomp.1.pod b/xCAT-client/pods/man1/lskitcomp.1.pod index 413e7f6be..dfd6e307c 100644 --- a/xCAT-client/pods/man1/lskitcomp.1.pod +++ b/xCAT-client/pods/man1/lskitcomp.1.pod @@ -57,7 +57,7 @@ Return the output with XML tags. The data is returned as: -Each tag contains info for a group of kit compoonents belonging to the same kit. The info inside is structured as follows: +Each tag contains info for a group of kit components belonging to the same kit. The info inside is structured as follows: The sub-tag contains the kit's name. The sub-tags store info about the kit's components. diff --git a/xCAT-client/pods/man1/lsslp.1.pod b/xCAT-client/pods/man1/lsslp.1.pod index 81d5cfdef..fe1e04cac 100755 --- a/xCAT-client/pods/man1/lsslp.1.pod +++ b/xCAT-client/pods/man1/lsslp.1.pod @@ -19,13 +19,13 @@ NOTE: SLP broadcast requests will propagate only within the subnet of the networ =head1 OPTIONS -B 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. +B The nodes which the user wants to discover. If the user specifies the noderange, lsslp will just return the nodes in the node range. Which means it will help to add the new nodes to the xCAT database without modifying the existed definitions. But the nodes' name specified in noderange should be defined in database in advance. The specified nodes' type can be frame/cec/hmc/fsp/bpa. If the it is frame or cec, lsslp will list the bpa or fsp nodes within the nodes(bap for frame, fsp for cec). Do not use noderange with the flag -s. B<-i> IP(s) the command will send out (defaults to all available adapters). B<-h> Display usage message. -B<-n> Only display and write the newly discovered hardwares. +B<-n> Only display and write the newly discovered hardware. B<-u> Do unicast to a specified IP range. Must be used with B<-s> and B<--range>. The B<-u> flag is not supported on AIX. @@ -33,16 +33,16 @@ B<--range> Specify one or more IP ranges. Must be use in unicast mode. It ac B<-r> Display Raw SLP response. -B<-C> The number of the expected responses specified by the user. When using this flag, lsslp will not return until the it has found all the nodes or time out. The default max time is 3 secondes. The user can use -T flag the specify the time they want to use. A short time will limite the time costing, while a long time will help to find all the nodes. +B<-C> The number of the expected responses specified by the user. When using this flag, lsslp will not return until the it has found all the nodes or time out. The default max time is 3 seconds. The user can use -T flag the specify the time they want to use. A short time will limit the time costing, while a long time will help to find all the nodes. -B<-T> The number in seconds to limite the time costing of lsslp. +B<-T> The number in seconds to limit the time of lsslp. B<-s> Service type interested in discovering. B<-t> Number or service-request attempts. -B<--vpdtable> Output the SLP response in vpdtable formatting. Easy for writting data to vpd table. +B<--vpdtable> Output the SLP response in vpdtable formatting. Easy for writing data to vpd table. B<-v> Command Version. @@ -52,9 +52,9 @@ B<-w> Writes output to xCAT database. B<-x> XML format. -B<-z> Stanza formated output. +B<-z> Stanza formatted output. -B<-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. +B<-I> Give the warning message for the nodes in database which have no SLP responses. Note that this flag can only be used after the database migration finished successfully. =head1 RETURN VALUE diff --git a/xCAT-client/pods/man1/lstree.1.pod b/xCAT-client/pods/man1/lstree.1.pod index 182abe37b..618151539 100644 --- a/xCAT-client/pods/man1/lstree.1.pod +++ b/xCAT-client/pods/man1/lstree.1.pod @@ -10,7 +10,7 @@ B [B<-s> | B<--servicenode>] [B<-H> | B<--hardwaremgmt>] [B<-v> | B<--vi =head1 DESCRIPTION -The B command can display the tree of service node hierarchy for the xCAT nodes which have service node defined or which are service nodes, display the tree of hardware hierarchy only for the physical objects, display the tree of VM hierarchy for the xCAT nodes which are virtual machines or which are the hosts of virtual machines. If a noderange is specified, only show the part of the hierarchy that involves those nodes. For ZVM, we only support to disply VM hierarchy. By default, lstree will show both the hardware hierarchy and the VM hierarchy for all the nodes. +The B command can display the tree of service node hierarchy for the xCAT nodes which have service node defined or which are service nodes, display the tree of hardware hierarchy only for the physical objects, display the tree of VM hierarchy for the xCAT nodes which are virtual machines or which are the hosts of virtual machines. If a noderange is specified, only show the part of the hierarchy that involves those nodes. For ZVM, we only support to display VM hierarchy. By default, lstree will show both the hardware hierarchy and the VM hierarchy for all the nodes. =head1 OPTIONS diff --git a/xCAT-client/pods/man1/lsvm.1.pod b/xCAT-client/pods/man1/lsvm.1.pod index d588fbf42..ac802ed7a 100644 --- a/xCAT-client/pods/man1/lsvm.1.pod +++ b/xCAT-client/pods/man1/lsvm.1.pod @@ -248,7 +248,7 @@ Output is similar to: Bytes per BSR array: 4096 Available BSR array: 256 -Note: The lines listed in "All Physical I/O info" section represent all the physical I/O resource information. The format is like "owner_lparid,slot_id,physical resource name,drc_index,slot_class_code(class discription)". The 'drc index' is short for Dynamic Resource Configuration Index, it uniquely indicates a physical I/O resource in a normal power machine. +Note: The lines listed in "All Physical I/O info" section represent all the physical I/O resource information. The format is like "owner_lparid,slot_id,physical resource name,drc_index,slot_class_code(class description)". The 'drc index' is short for Dynamic Resource Configuration Index, it uniquely indicates a physical I/O resource in a normal power machine. 9. For DFM-managed partition on normal power machine, list out the detailed information: diff --git a/xCAT-client/pods/man1/mkdef.1.pod b/xCAT-client/pods/man1/mkdef.1.pod index 8f5cdb899..af59220b2 100644 --- a/xCAT-client/pods/man1/mkdef.1.pod +++ b/xCAT-client/pods/man1/mkdef.1.pod @@ -50,7 +50,7 @@ A set of comma delimited object types. Use the help option to get a list of val =item B<--template> I -Name of the xCAT shipped object definition template or an existing object, from which the new object definition will be created. The newly created object will inherit the attributes of the template definition unless the attribute is specified in the arguments of B command. If there are a template and an existing object with the same name I, the tempalte object takes precedence over the existing object. For the details of xCAT shipped object definition templates, refer to the manpage of B<--template> option in L. +Name of the xCAT shipped object definition template or an existing object, from which the new object definition will be created. The newly created object will inherit the attributes of the template definition unless the attribute is specified in the arguments of B command. If there are a template and an existing object with the same name I, the template object takes precedence over the existing object. For the details of xCAT shipped object definition templates, refer to the manpage of B<--template> option in L. =item B<-V|--verbose> @@ -58,7 +58,7 @@ Verbose mode. =item B<-w> I B<-w> I ... -Use one or multiple -w flags to specify the selection string that can be used to select objects. The operators ==, !=, =~ and !~ are available. For mkdef commmand, the -w flag only makes sense for creating dynamic node group. Use the help option to get a list of valid attributes for each object type. +Use one or multiple -w flags to specify the selection string that can be used to select objects. The operators ==, !=, =~ and !~ are available. For mkdef command, the -w flag only makes sense for creating dynamic node group. Use the help option to get a list of valid attributes for each object type. Operator descriptions: == Select nodes where the attribute value is exactly this value. diff --git a/xCAT-client/pods/man1/mkdocker.1.pod b/xCAT-client/pods/man1/mkdocker.1.pod index 1f9ee535c..dcb4eb0e4 100644 --- a/xCAT-client/pods/man1/mkdocker.1.pod +++ b/xCAT-client/pods/man1/mkdocker.1.pod @@ -82,7 +82,7 @@ Output is similar to: host01c01: Pull image ubuntu start host01c01: Pull image ubuntu done host01c01: Remove default network connection - host01c01: Connecting customzied network 'mynet0' + host01c01: Connecting customized network 'mynet0' host01c01: success 2. To create a docker instance which have dir "destdir" in docker instance bind from "srcdir" on dockerhost, and have "Tty" opened with which the docker instance can be attached after started to check the files under "destdir". @@ -92,7 +92,7 @@ Output is similar to: Output is similar to: host01c01: Remove default network connection - host01c01: Connecting customzied network 'mynet0' + host01c01: Connecting customized network 'mynet0' host01c01: success =head1 SEE ALSO diff --git a/xCAT-client/pods/man1/mkdsklsnode.1.pod b/xCAT-client/pods/man1/mkdsklsnode.1.pod index 5e0a95278..3b51f160f 100644 --- a/xCAT-client/pods/man1/mkdsklsnode.1.pod +++ b/xCAT-client/pods/man1/mkdsklsnode.1.pod @@ -19,7 +19,7 @@ This command will also create a NIM resolv_conf resource to be used when install The "domain" and "nameservers" attributes can be set in either the xCAT "network" definition used by the nodes or in the xCAT cluster "site" definition. The setting in the "network" definition will take priority. The "search" field of the resolv.conf file will contain a list all the domains -listed in the xCAT network definitions and the xCAT site definiton. +listed in the xCAT network definitions and the xCAT site definition. The "nameservers" value can either be set to a specific IP address or the "" key word. The "" key word means that the value of the "xcatmaster" attribute of the node definition will be used in the /etc/resolv.conf file. (I.e. The name of the install server as known by the node.) @@ -41,11 +41,11 @@ You can use the "-n" option of the mkdsklsnode command to create and initialize B When using the "-n" option make sure that the new osimage you specify and all the NIM resources that are used are different than what are currently being used on the nodes. The NIM resources should not be shared between the old osimage and the new osimage. -You can use the force option to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinititializing. Use this option with caution since reinitializing a node will stop the node if it is currently running. +You can use the force option to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinitializing. Use this option with caution since reinitializing a node will stop the node if it is currently running. After the mkdsklsnode command completes you can use the B command to check the NIM node definition to see if it is ready for booting the node. ("lsnim -l "). -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 B command. Such scripts are called B. They should be copied to /install/prescripts dirctory. A table called I is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the B command are stored in the 'begin' column of I table. The scripts to be run at the end of the B command are stored in the 'end' column of I table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: I. 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 I<#xCAT setting:MAX_INSTANCE=number> is specified in the script, the script will get invoked for each node in parallel, but no more than I 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 B command. Such scripts are called B. They should be copied to /install/prescripts directory. A table called I is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the B command are stored in the 'begin' column of I table. The scripts to be run at the end of the B command are stored in the 'end' column of I table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: I. The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "diskless". If I<#xCAT setting:MAX_INSTANCE=number> is specified in the script, the script will get invoked for each node in parallel, but no more than I of instances will be invoked at a time. If it is not specified, the script will be invoked once for all the nodes. =head1 OPTIONS diff --git a/xCAT-client/pods/man1/mknimimage.1.pod b/xCAT-client/pods/man1/mknimimage.1.pod index 78dc2b00e..700ccdc43 100644 --- a/xCAT-client/pods/man1/mknimimage.1.pod +++ b/xCAT-client/pods/man1/mknimimage.1.pod @@ -24,7 +24,7 @@ B When creating a diskless osimage definition you also have the option of automatically updating the NIM SPOT resource. You can have additional software installed or you can have configuration files added or updated. To have software installed you must provide either the names of NIM installp_bundle resources or fileset names on the command line using the "attr=val" option. You may also supply the installp flags, RPM flags, emgr flags to use when installing the software. -To have configuration files updated you must provide the full path name of a "synclists" file which contains the the list of actual files to update. The xCAT osimage definition that is created will contain the installp_bundle, otherpkgs, and synclists files that are provided on the command line. +To have configuration files updated you must provide the full path name of a "synclists" file which contains the list of actual files to update. The xCAT osimage definition that is created will contain the installp_bundle, otherpkgs, and synclists files that are provided on the command line. B @@ -50,7 +50,7 @@ You can use the "-i" and "-p" options to copy an existing diskless osimage. To - any other resources (or attributes) included in the original osimage will be included in the new osimage definition. -- if the "-p" option is specified then the original NIM lpp_source resource will be copied to a new location and redfined to NIM. (The default would be to use the original lpp_source - to save file system space.) +- if the "-p" option is specified then the original NIM lpp_source resource will be copied to a new location and redefined to NIM. (The default would be to use the original lpp_source - to save file system space.) B @@ -67,7 +67,7 @@ To list a NIM resource definition use the AIX B command ("lsnim -l command ("nim -o check "). -To remove specific NIM resource definitons use the AIX B command. ("nim -o remove "). +To remove specific NIM resource definitions use the AIX B command. ("nim -o remove "). =head1 OPTIONS @@ -187,7 +187,7 @@ Value Specifies the security method required for NFS access. =back -Note that you may specify multiple "script", "otherpkgs", and "installp_bundle" resources by using a comma seperated list. (ex. "script=ascript,bscript"). RPM names may be included in the "otherpkgs" list by using a "R:" prefix(ex. "R:whatever.rpm"). epkg (AIX interim fix package) file names may be included in the "otherpkgs" using the 'E:' prefix. (ex. "otherpkgs=E:IZ38930TL0.120304.epkg.Z"). +Note that you may specify multiple "script", "otherpkgs", and "installp_bundle" resources by using a comma separated list. (ex. "script=ascript,bscript"). RPM names may be included in the "otherpkgs" list by using a "R:" prefix(ex. "R:whatever.rpm"). epkg (AIX interim fix package) file names may be included in the "otherpkgs" using the 'E:' prefix. (ex. "otherpkgs=E:IZ38930TL0.120304.epkg.Z"). =item B<-b> I @@ -195,7 +195,7 @@ Used to specify the path name of a mksysb file to use when defining a NIM mksysb =item B<-c|--completeosimage> -Complete the creation of the osimage definition passed in on the command line. This option will use any additonal values passed in on the command line and/or it will attempt to create required resources in order to complete the definition of the xCAT osimage. For example, if the osimage definition is missing a spot or shared_root resource the command will create those resources and add them to the osimage definition. +Complete the creation of the osimage definition passed in on the command line. This option will use any additional values passed in on the command line and/or it will attempt to create required resources in order to complete the definition of the xCAT osimage. For example, if the osimage definition is missing a spot or shared_root resource the command will create those resources and add them to the osimage definition. =item B<-f|--force> @@ -333,7 +333,7 @@ The xCAT osimage definition created by this command will include the "otherpkgs" mknimimage -u 61dskls installp_bundle=bndres1,bndres2 installp_flags="-agcQX" -Note that when "installp_bundle", "otherpkgs", or "synclists" values are specified with the "-u" option then the xCAT osimage definiton is not used or updated. +Note that when "installp_bundle", "otherpkgs", or "synclists" values are specified with the "-u" option then the xCAT osimage definition is not used or updated. 13) Update an existing image to support NFSv4. Also specify verbose messages. diff --git a/xCAT-client/pods/man1/mkvm.1.pod b/xCAT-client/pods/man1/mkvm.1.pod index 700521841..fd98f4525 100644 --- a/xCAT-client/pods/man1/mkvm.1.pod +++ b/xCAT-client/pods/man1/mkvm.1.pod @@ -88,7 +88,7 @@ Request to create a new full system partition for each CEC. =item B I B I B I B I B I B I [B<--vios>] -To specify the parameters which are used to create a partition. The I, I are necessay, and the value specified with this command have a more high priority. If the value of any of the three options is not specified, the corresponding value specified for the node object will be used. If any of the three attributes is neither specified with this command nor specified with the node object, error information will be returned. To reference to L for more information about 'drc_index' for I. +To specify the parameters which are used to create a partition. The I, I are necessary, and the value specified with this command have a more high priority. If the value of any of the three options is not specified, the corresponding value specified for the node object will be used. If any of the three attributes is neither specified with this command nor specified with the node object, error information will be returned. To reference to L for more information about 'drc_index' for I. The option I is used to specify the partition that will be created is a VIOS partition. If specified, the value for I shall be number which indicate the number of vSCSI server adapter will be created, and if no value specified for I, all the physical slot of the power machine will be asigned to VIOS partition. If not specified, it shall be in form of I to specify the vios and the virtual slot id of the vSCSI server adapter that will be connected from the Logical partition. @@ -241,7 +241,7 @@ First, define a node object: mkdef -t node -o lpar1 mgt=fsp cons=fsp nodetype=ppc,osi id=1 hcp=cec parent=cec hwtype=lpar groups=lpar,all -Then, create the partion on the specified cec. +Then, create the partition on the specified cec. mkvm lpar1 --full @@ -321,7 +321,7 @@ The output is similar to: mkvm viosnode vmcpus=1/4/16 vmmemory=1G/4G/32G vmphyslots=0x21010201,0x21010200 vmnics=vlan1 vmstorage=5 --vios -The resouces for the node is similar to: +The resources for the node is similar to: viosnode: Lpar Processor Info: Curr Processor Min: 1. diff --git a/xCAT-client/pods/man1/monadd.1.pod b/xCAT-client/pods/man1/monadd.1.pod index 1e587afdd..1ad4bd093 100644 --- a/xCAT-client/pods/man1/monadd.1.pod +++ b/xCAT-client/pods/man1/monadd.1.pod @@ -18,9 +18,9 @@ This command is used to register a monitoring plug-in module to monitor the xCAT =head1 Parameters -I is the name of the monitoring plug-in module. For example, if the the I is called I, then the actual file name that the xcatd looks for is I. Use I command to list all the monitoring plug-in modules that can be used. +I is the name of the monitoring plug-in module. For example, if the I is called I, then the actual file name that the xcatd looks for is I. Use I command to list all the monitoring plug-in modules that can be used. -I 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: I<-s key-value -s key=value ...> Note that the square brackets are needed here. Use I command to look for the possbile setting keys for a plug-in module. +I 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: I<-s key-value -s key=value ...> Note that the square brackets are needed here. Use I command to look for the possible setting keys for a plug-in module. =head1 OPTIONS diff --git a/xCAT-client/pods/man1/moncfg.1.pod b/xCAT-client/pods/man1/moncfg.1.pod index a1fc5a20c..47a3bba3a 100644 --- a/xCAT-client/pods/man1/moncfg.1.pod +++ b/xCAT-client/pods/man1/moncfg.1.pod @@ -15,12 +15,12 @@ B I I<[noderange]> B<[-r|--remote]> =head1 DESCRIPTION -This command is used to configure a 3rd party monitoring software to monitor the xCAT cluster. For example, it modifies the configration file for the monitoring software so that the nodes can be included in the monitoring domain. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the I<-r> option is specified, though the configuration of the nodes is usually performed during the node deployment stage. +This command is used to configure a 3rd party monitoring software to monitor the xCAT cluster. For example, it modifies the configuration file for the monitoring software so that the nodes can be included in the monitoring domain. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the I<-r> option is specified, though the configuration of the nodes is usually performed during the node deployment stage. =head1 Parameters -I is the name of the monitoring plug-in module. For example, if the the I is called I, then the actual file name that the xcatd looks for is I. Use I command to list all the monitoring plug-in modules that can be used. +I is the name of the monitoring plug-in module. For example, if the I is called I, then the actual file name that the xcatd looks for is I. Use I command to list all the monitoring plug-in modules that can be used. I specifies the nodes to be monitored. If omitted, all nodes will be monitored. diff --git a/xCAT-client/pods/man1/mondecfg.1.pod b/xCAT-client/pods/man1/mondecfg.1.pod index 1884ab1b1..6f7ccc753 100644 --- a/xCAT-client/pods/man1/mondecfg.1.pod +++ b/xCAT-client/pods/man1/mondecfg.1.pod @@ -15,7 +15,7 @@ B I I<[noderange]> B<[-r|--remote]> =head1 DESCRIPTION -This command is used to deconfigure a 3rd party monitoring software from monitoring the xCAT cluster. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the I<-r> option is specified. The deconfigration operation will remove the nodes from the 3rd party software's monitoring domain. +This command is used to deconfigure a 3rd party monitoring software from monitoring the xCAT cluster. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the I<-r> option is specified. The deconfiguration operation will remove the nodes from the 3rd party software's monitoring domain. =head1 PARAMETERS diff --git a/xCAT-client/pods/man1/monls.1.pod b/xCAT-client/pods/man1/monls.1.pod index 55cd86498..c9130a98e 100644 --- a/xCAT-client/pods/man1/monls.1.pod +++ b/xCAT-client/pods/man1/monls.1.pod @@ -15,7 +15,7 @@ B =head1 DESCRIPTION -This command is used to list the status, desctiption, the configuration scripts and the settings of one or all of the monitoring plug-in modules. +This command is used to list the status, description, the configuration scripts and the settings of one or all of the monitoring plug-in modules. =head1 Parameters @@ -26,9 +26,9 @@ I is the name of the monitoring plug-in module. =head1 OPTIONS -B<-a | --all> Searches the I directory and reports all the monitoring plug-in modules. If nothing is specified, the list is read from the I tabel. +B<-a | --all> Searches the I directory and reports all the monitoring plug-in modules. If nothing is specified, the list is read from the I table. -B<-d | --description> Display the description of the plug-in modules. The description ususally contains the possible settings. +B<-d | --description> Display the description of the plug-in modules. The description usually contains the possible settings. B<-h | --help> Display usage message. @@ -64,7 +64,7 @@ The output looks like this: nagiosmon not-monitored -3. To list the status and the desciption for I module, enter: +3. To list the status and the description for I module, enter: monls snmpmon -d diff --git a/xCAT-client/pods/man1/monshow.1.pod b/xCAT-client/pods/man1/monshow.1.pod index 22d4309f9..c3aa85385 100755 --- a/xCAT-client/pods/man1/monshow.1.pod +++ b/xCAT-client/pods/man1/monshow.1.pod @@ -36,7 +36,7 @@ B<-t> specifies a range of time for the data, The default is last 60 minutes. Fo B<-a> specifies a comma-separated list of attributes or metrics names. The default is all. -B<-w> specify one or multiple selection string that can be used to select events. The operators ==, !=, =,!,>,<,>=,<= are available. Wildcards % and _ are supported in the pattern string. % allows you to match any string of any length(including zero length) and _ allows you to match on a single character. The valid attributes are eventtype, monitor, monnode, application, component, id, serverity, message, rawdata, comments. Valid severity are: Informational, Warning, Critical. +B<-w> specify one or multiple selection string that can be used to select events. The operators ==, !=, =,!,>,<,>=,<= are available. Wildcards % and _ are supported in the pattern string. % allows you to match any string of any length(including zero length) and _ allows you to match on a single character. The valid attributes are eventtype, monitor, monnode, application, component, id, severity, message, rawdata, comments. Valid severity are: Informational, Warning, Critical. Operator descriptions: diff --git a/xCAT-client/pods/man1/monstart.1.pod b/xCAT-client/pods/man1/monstart.1.pod index 624fad4fa..092d6a399 100644 --- a/xCAT-client/pods/man1/monstart.1.pod +++ b/xCAT-client/pods/man1/monstart.1.pod @@ -18,7 +18,7 @@ This command is used to start a 3rd party software, (for example start the daemo =head1 PARAMETERS -I is the name of the monitoring plug-in module. For example, if the the I is called I, then the actual file name that the xcatd looks for is I. Use B command to list all the monitoring plug-in modules that can be used. +I is the name of the monitoring plug-in module. For example, if the I is called I, then the actual file name that the xcatd looks for is I. Use B command to list all the monitoring plug-in modules that can be used. I is the nodes to be monitored. If omitted, all nodes will be monitored. diff --git a/xCAT-client/pods/man1/nimnodecust.1.pod b/xCAT-client/pods/man1/nimnodecust.1.pod index ea5eaa711..93cba2a36 100644 --- a/xCAT-client/pods/man1/nimnodecust.1.pod +++ b/xCAT-client/pods/man1/nimnodecust.1.pod @@ -30,9 +30,9 @@ To create a NIM installp_bundle definition you can use the "nim -o define" opera nim -o define -t installp_bundle -a server=master -a location=/install/nim/mypkgs.bnd mypackages -See the AIX documantation for more information on using installp_bundle files. +See the AIX documentation for more information on using installp_bundle files. -The xCAT nimnodecust command will automatically handle the distribution of the packages to AIX service nodes when using an xCAT hierachical environment. +The xCAT nimnodecust command will automatically handle the distribution of the packages to AIX service nodes when using an xCAT hierarchical environment. =head1 OPTIONS diff --git a/xCAT-client/pods/man1/nimnodeset.1.pod b/xCAT-client/pods/man1/nimnodeset.1.pod index 2e9b9835f..04ecd9587 100644 --- a/xCAT-client/pods/man1/nimnodeset.1.pod +++ b/xCAT-client/pods/man1/nimnodeset.1.pod @@ -14,7 +14,7 @@ This xCAT command can be used to initialize AIX/NIM standalone machines. Once th If you are using xCAT service nodes the B command will automatically determine the correct server(s) for the node and do the initialization on that server(s). -The osimage_name is the name of an xCAT osimage definition that contains the list of NIM resources to use when initializing the nodes. If the osimage_name is not provided on the command line the code checks the node definition for the value of the "provmethod" attribute (which is the name of an osimage definition). If the osimage_image is provided on the command line then the code will also set the "provmethod" attribute of the node definiions. +The osimage_name is the name of an xCAT osimage definition that contains the list of NIM resources to use when initializing the nodes. If the osimage_name is not provided on the command line the code checks the node definition for the value of the "provmethod" attribute (which is the name of an osimage definition). If the osimage_image is provided on the command line then the code will also set the "provmethod" attribute of the node definitions. This command will also create a NIM resolv_conf resource to be used when installing the node. If a resolv_conf resource is not already included in the xCAT osimage definition and if the "domain" and "nameservers" values are set then a new NIM resolv_conf resource will be created and allocated to the nodes. @@ -22,7 +22,7 @@ NIM resolv_conf resource will be created and allocated to the nodes. The "domain" and "nameservers" attributes can be set in either the xCAT "network" definition used by the nodes or in the xCAT cluster "site" definition. The setting in the "network" definition will take priority. The "search" field of the resolv.conf file will contain a list all the domains -listed in the xCAT network definitions and the xCAT site definiton. +listed in the xCAT network definitions and the xCAT site definition. The "nameservers" value can either be set to a specific IP address or the "" key word. The "" key word means that the value of the "xcatmaster" attribute of the node definition will be used in the /etc/resolv.conf file. (I.e. The name of the install server as known by the node.) @@ -35,13 +35,13 @@ will be created. You can specify additional attributes and values using the "attr=val" command line option. This information will be passed on to the underlying call to the NIM "nim -o bos_inst" command. See the NIM documentation for information on valid command line options for the nim command. The "attr" must correspond to a NIM attribute supported for the NIM "bos_inst" operation. Information provided by the "attr=val" option will take precedence over the information provided in the osimage definition. -The force option can be used to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinititializing. +The force option can be used to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinitializing. This command will also create a NIM script resource to enable the xCAT support for user-provided customization scripts. After the B command completes you can use the B command to check the NIM node definition to see if it is ready for booting the node. ("lsnim -l "). -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 B command. Such scripts are called B. They should be copied to /install/prescripts dirctory. A table called I is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the B command are stored in the 'begin' column of I table. The scripts to be run at the end of the B command are stored in the 'end' column of I table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: I. 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 I<#xCAT setting:MAX_INSTANCE=number> is specified in the script, the script will get invoked for each node in parallel, but no more than I 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 B command. Such scripts are called B. They should be copied to /install/prescripts directory. A table called I is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the B command are stored in the 'begin' column of I table. The scripts to be run at the end of the B command are stored in the 'end' column of I table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: I. 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 I<#xCAT setting:MAX_INSTANCE=number> is specified in the script, the script will get invoked for each node in parallel, but no more than I of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes. =head1 OPTIONS @@ -50,7 +50,7 @@ You can supply your own scripts to be run on the management node or on the serv =item I Specifies one or more "attribute equals value" pairs, separated by spaces. Attr= -val pairs must be specified last on the command line. These are used to specify additional values that can be passed to the underlying NIM commands, ("nim -o bos_inst ..."). See the NIM documentation for valid "nim" command line options. Note that you may specify multiple "script" and "installp_bundle" values by using a comma seperated list. (ex. "script=ascript,bscript"). +val pairs must be specified last on the command line. These are used to specify additional values that can be passed to the underlying NIM commands, ("nim -o bos_inst ..."). See the NIM documentation for valid "nim" command line options. Note that you may specify multiple "script" and "installp_bundle" values by using a comma separated list. (ex. "script=ascript,bscript"). =item B<-b|--backupSN> @@ -70,8 +70,7 @@ The name of an existing xCAT osimage definition. =item B<-l|--location> -The directory location to use when creating new NIM resolv_conf resources. The d -efault location is /install/nim. +The directory location to use when creating new NIM resolv_conf resources. The default location is /install/nim. =item B<-p|--primarySN> diff --git a/xCAT-client/pods/man1/nodeaddunmged.1.pod b/xCAT-client/pods/man1/nodeaddunmged.1.pod index 60258c7a0..675daa669 100644 --- a/xCAT-client/pods/man1/nodeaddunmged.1.pod +++ b/xCAT-client/pods/man1/nodeaddunmged.1.pod @@ -34,7 +34,7 @@ Sets the IP address of the unmanaged node, where I is the IP address 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. =head1 EXAMPLES diff --git a/xCAT-client/pods/man1/nodechmac.1.pod b/xCAT-client/pods/man1/nodechmac.1.pod index 593b20a51..0bf9830f8 100644 --- a/xCAT-client/pods/man1/nodechmac.1.pod +++ b/xCAT-client/pods/man1/nodechmac.1.pod @@ -36,7 +36,7 @@ Sets the new MAC address for the NIC used by the provisioning node, where is 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. =head1 EXAMPLES diff --git a/xCAT-client/pods/man1/nodediscoverls.1.pod b/xCAT-client/pods/man1/nodediscoverls.1.pod index 5b6af9bf6..bde7b37e0 100644 --- a/xCAT-client/pods/man1/nodediscoverls.1.pod +++ b/xCAT-client/pods/man1/nodediscoverls.1.pod @@ -76,7 +76,7 @@ Command version. 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. =head1 EXAMPLES diff --git a/xCAT-client/pods/man1/nodediscoverstart.1.pod b/xCAT-client/pods/man1/nodediscoverstart.1.pod index 165a68d5a..4e3b98d37 100755 --- a/xCAT-client/pods/man1/nodediscoverstart.1.pod +++ b/xCAT-client/pods/man1/nodediscoverstart.1.pod @@ -52,7 +52,7 @@ When the nodes are discovered, PCM updates the affected configuration files on t When you power on the nodes, they PXE boot and DHCP/TFTP/HTTP on the management node give each node the xCAT genesis boot image, which inventories the node hardware and sends data to the management node. There, either the sequential discovery process or the -profile discovery process assigns node attributes and defines the node in the the database. +profile discovery process assigns node attributes and defines the node in the database. =head1 OPTIONS @@ -99,7 +99,7 @@ Sets the node groups that the discovered nodes should be put in for either the S Sets the rack name where the node is located for either the Sequential Discovery or Profile Discovery methods. -=item BI +=item BI Sets the chassis name that the Blade server or PureFlex blade is located in, for either the Sequential Discovery or Profile Discovery methods. This option is used for the Blade server and PureFlex system only. You cannot specify this option with the rack option. @@ -146,7 +146,7 @@ Command Version. 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. =head1 EXAMPLES diff --git a/xCAT-client/pods/man1/nodediscoverstatus.1.pod b/xCAT-client/pods/man1/nodediscoverstatus.1.pod index 2e261fdef..f65597e40 100644 --- a/xCAT-client/pods/man1/nodediscoverstatus.1.pod +++ b/xCAT-client/pods/man1/nodediscoverstatus.1.pod @@ -25,7 +25,7 @@ Command Version. 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. =head1 EXAMPLES diff --git a/xCAT-client/pods/man1/nodediscoverstop.1.pod b/xCAT-client/pods/man1/nodediscoverstop.1.pod index 8cde9a0cb..b8ce5b563 100644 --- a/xCAT-client/pods/man1/nodediscoverstop.1.pod +++ b/xCAT-client/pods/man1/nodediscoverstop.1.pod @@ -26,7 +26,7 @@ Command Version. 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. =head1 EXAMPLES diff --git a/xCAT-client/pods/man1/nodeimport.1.pod b/xCAT-client/pods/man1/nodeimport.1.pod index 30087957b..2c3b670f7 100644 --- a/xCAT-client/pods/man1/nodeimport.1.pod +++ b/xCAT-client/pods/man1/nodeimport.1.pod @@ -10,7 +10,7 @@ B B I B I command creates nodes by importing a hostinfo file which is following stanza format. In this hostinfo file, we can define node's hostname, ip, mac, switch name, switch port and host location infomation like rack, chassis, start unit, server height...etc +The B command creates nodes by importing a hostinfo file which is following stanza format. In this hostinfo file, we can define node's hostname, ip, mac, switch name, switch port and host location information like rack, chassis, start unit, server height...etc After nodes imported, the configuration files related with these nodes will be updated automatically. For example: /etc/hosts, dns configuration, dhcp configuration. And the kits node plugins will also be triggered automatically to update kit related configuration/services. @@ -56,9 +56,9 @@ Sets the node groups that the imported node belongs to, where is a 0 The command completed successfully. -1 An error has occured while validating parameters. +1 An error has occurred while validating parameters. -2 An error has occured while parsing hostinfo file. +2 An error has occurred while parsing hostinfo file. =head1 EXAMPLES @@ -106,7 +106,7 @@ To import nodes using a profile, follow the following steps: # hostinfo end. - Another example of a node infomation file, a PureFlex X/P node defined: + Another example of a node information file, a PureFlex X/P node defined: # hostinfo begin # To define a PureFlex P/X node, chassis and slot id must be specified. # The chassis must be a PureFlex chassis. @@ -153,7 +153,7 @@ Description: The name of the node, where __hostname__ is automatically generated B> This is a mandatory item. -Description: Specify the MAC address for the NIC used by the provisionging node, where is the NICs MAC address. +Description: Specify the MAC address for the NIC used by the provisioning node, where is the NICs MAC address. B> This is a mandatory item, when define switch, switchport and node nic name relationship. @@ -183,9 +183,9 @@ B> This is an optional item. Description: node location info. Specify the rack name which this node will be placed into. If not specify this item, there will be no node location info set for this node. this item must be specified together with height + unit. -B> This is an optional item. +B> This is an optional item. -Description: node location info, for blade(or PureFlex) only. Specify the chasiss name which this blade will be placed into. this item can not be specified together with rack. +Description: node location info, for blade(or PureFlex) only. Specify the chassis name which this blade will be placed into. this item can not be specified together with rack. B> This is an optional item. diff --git a/xCAT-client/pods/man1/nodels.1.pod b/xCAT-client/pods/man1/nodels.1.pod index b976091bf..e3e76cd58 100644 --- a/xCAT-client/pods/man1/nodels.1.pod +++ b/xCAT-client/pods/man1/nodels.1.pod @@ -75,7 +75,7 @@ Force display of table name and column name context for each result =item B<-b|--blame> -For values inherited from groups, display which groups provided the inheritence +For values inherited from groups, display which groups provided the inheritance =item B<-S> diff --git a/xCAT-client/pods/man1/nodepurge.1.pod b/xCAT-client/pods/man1/nodepurge.1.pod index 73b6a94ba..714f164f2 100644 --- a/xCAT-client/pods/man1/nodepurge.1.pod +++ b/xCAT-client/pods/man1/nodepurge.1.pod @@ -32,7 +32,7 @@ The nodes to be removed. 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. =head1 EXAMPLES diff --git a/xCAT-client/pods/man1/noderefresh.1.pod b/xCAT-client/pods/man1/noderefresh.1.pod index b25693c71..cafd50986 100644 --- a/xCAT-client/pods/man1/noderefresh.1.pod +++ b/xCAT-client/pods/man1/noderefresh.1.pod @@ -30,7 +30,7 @@ The nodes to be updated. 0 The command completed successfully. -1 An error has occured. +1 An error has occurred. =head1 EXAMPLES diff --git a/xCAT-client/pods/man1/nodestat.1.pod b/xCAT-client/pods/man1/nodestat.1.pod index 42a0dc5f0..fd964a3c9 100644 --- a/xCAT-client/pods/man1/nodestat.1.pod +++ b/xCAT-client/pods/man1/nodestat.1.pod @@ -41,7 +41,7 @@ Keywords to use: port -- the application daemon port number, if not specified, use internal list, then /etc/services. group -- the name of a node group that needs to get the application status from. If not specified, assume all the nodes in the nodelist table. To specify more than one groups, use group=a,group=b format. cmd -- the command that will be run locally on mn or sn. - lcmd -- the command that will be run the the mn only. + lcmd -- the command that will be run the mn only. dcmd -- the command that will be run distributed on the nodes using xdsh .... For commands specified by 'cmd' and 'lcmd', the input of is a list of comma separated node names, the output must be in the following format: @@ -63,7 +63,7 @@ Uses fping instead of nmap even if nmap is available. If you seem to be having =item B<-m>|B<--usemon> -Uses the settings from the B talbe to determine a list of applications that need to get status for. +Uses the settings from the B table to determine a list of applications that need to get status for. =item B<-p>|B<--powerstat> diff --git a/xCAT-client/pods/man1/rflash.1.pod b/xCAT-client/pods/man1/rflash.1.pod index de1f11e60..091eec11a 100644 --- a/xCAT-client/pods/man1/rflash.1.pod +++ b/xCAT-client/pods/man1/rflash.1.pod @@ -40,7 +40,7 @@ The command will update firmware for NeXtScale FPC when given an FPC node and th =head2 PPC (with HMC) specific: -The B command uses the B command to connect to the HMC controlling the given managed system and perform the updates. Before running B, use B to check if the related HMC ssh is enabled. To enable a HMC ssh connection, use B comamnd. +The B command uses the B command to connect to the HMC controlling the given managed system and perform the updates. Before running B, use B to check if the related HMC ssh is enabled. To enable a HMC ssh connection, use B command. B 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. @@ -50,7 +50,7 @@ The flash chip of a POWER5 and POWER6 managed system or power subsystem stores f The B<--commit> flag is used to write the contents of the temporary side of the flash to the permanent side. This flag should be used after updating code and verifying correct system operation. The B<--recover> flag is used to write the permanent side of the flash chip back to the temporary side. This flag should be used to recover from a corrupt flash operation, so that the previously running code can be restored. -BWhen the B<--commit> or B<--recover> two flags is used, the noderange B be BPA. It only B be CEC or LPAR ,and will take effect for B managed systems and power subsystems. +BWhen the B<--commit> or B<--recover> two flags is used, the noderange B be BPA. It only B be CEC or LPAR, and will take effect for B managed systems and power subsystems. xCAT recommends that you shutdown your Operating System images and power off your managed systems before applying disruptive updates to managed systems or power subsystems. @@ -68,7 +68,7 @@ The B option will load the new firmware into the T (temp) side, but wi In Direct FSP/BPA Management, there is B<-d> I option. The default value is /tmp. When doing firmware update, B will put some related data from rpm packages in directory, so the execution of B will require available disk space in for the command to properly execute: -For one GFW rpm package and one power code rpm package , if the GFW rpm package size is gfw_rpmsize, and the Power code rpm package size is power_rpmsize, it requires that the available disk space should be more than: 1.5*gfw_rpmsize + 1.5*power_rpmsize +For one GFW rpm package and one power code rpm package, if the GFW rpm package size is gfw_rpmsize, and the Power code rpm package size is power_rpmsize, it requires that the available disk space should be more than: 1.5*gfw_rpmsize + 1.5*power_rpmsize For Power 775, the B command takes effect on the primary and secondary FSPs or BPAs almost in parallel. @@ -76,7 +76,7 @@ For more details about the Firmware Update using Direct FSP/BPA Management, refe =head2 NeXtScale FPC specific: -The command will update firmware for NeXtScale FPC when given an FPC node and the http information needed to access the firmware. The http imformation required includes both the MN IP address as well as the directory containing the firmware. It is recommended that the firmware be downloaded and placed in the /install directory structure as the xCAT MN /install directory is configured with the correct permissions for http. Refer to the doc to get more details: XCAT_NeXtScale_Clusters +The command will update firmware for NeXtScale FPC when given an FPC node and the http information needed to access the firmware. The http information required includes both the MN IP address as well as the directory containing the firmware. It is recommended that the firmware be downloaded and placed in the /install directory structure as the xCAT MN /install directory is configured with the correct permissions for http. Refer to the doc to get more details: XCAT_NeXtScale_Clusters =head2 OpenPOWER specific: @@ -92,7 +92,7 @@ Writes the command's usage statement to standard output. =item B<-c|--check> -Chech the firmware version of BMC and HPM file. +Check the firmware version of BMC and HPM file. =item B<-p> I @@ -139,12 +139,12 @@ Verbose output. =over 4 =item 1. -To update only the power subsystem attached to a single HMC-attached pSeries CEC(cec_name), and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter: +To update only the power subsystem attached to a single HMC-attached pSeries CEC(cec_name), and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter: rflash cec_name -p /tmp/fw --activate disruptive =item 2. -To update only the power subsystem attached to a single HMC-attached pSeries node, and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter: +To update only the power subsystem attached to a single HMC-attached pSeries node, and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter: rflash bpa_name -p /tmp/fw --activate disruptive @@ -154,7 +154,7 @@ To commit a firmware update to permanent flash for both managed system and the r rflash cec_name --commit =item 4. -To update the firmware on a NeXtScale FPC specify the FPC node name and the HTTP location of the file including the xCAT MN IP address and the directory on the xCAT MN containing the firmware as follows: +To update the firmware on a NeXtScale FPC specify the FPC node name and the HTTP location of the file including the xCAT MN IP address and the directory on the xCAT MN containing the firmware as follows: rflash fpc01 http://10.1.147.169/install/firmware/fhet17a/ibm_fw_fpc_fhet17a-2.02_anyos_noarch.rom diff --git a/xCAT-client/pods/man1/rinv.1.pod b/xCAT-client/pods/man1/rinv.1.pod index e0799d15b..52ed22ccc 100644 --- a/xCAT-client/pods/man1/rinv.1.pod +++ b/xCAT-client/pods/man1/rinv.1.pod @@ -8,15 +8,15 @@ B [B<-h>|B<--help>|B<-v>|B<--version>] =head2 BMC/MPA specific: -B I {B|B|B|B|B|B|B|B|B|B|B|B|B|B|B} +B I [B|B|B|B|B|B|B|B|B|B] -=head2 OpenPOWER (using ipmi) server specific: +=head2 OpenPOWER (IPMI) server specific: -B I {B|B|B|B|B|B|B|B|B} +B I [B|B|B|B|B|B|B|B|B] -=head2 OpenPOWER (using openbmc) server specific: +=head2 OpenPOWER (OpenBMC) server specific: -B I {B|B|B|B|B|B|B|B|B|B|B} +B I [B|B|B|B|B|B] [B<-V>|B<--verbose>] =head2 PPC (with HMC) specific: @@ -40,7 +40,6 @@ B I [B<-t>] B I - =head2 zVM specific: B I [B|B] @@ -69,27 +68,22 @@ B I [B<--zfcppoolnames>] =head1 B -B retrieves hardware configuration information from the on-board +B retrieves hardware configuration information from the on-board Service Processor for a single or range of nodes and groups. -Calling B for VMware will display the UUID/GUID, nuumber of CPUs, amount of memory, the MAC address and a list of Hard disks. The output for each Hard disk includes the label, size and backing file location. +Calling B for VMware will display the UUID/GUID, number of CPUs, amount of memory, the MAC address and a list of Hard disks. The output for each Hard disk includes the label, size and backing file location. =head1 B =over 7 -=item B - -Retrieves PCI bus information. - =item B List all buses for each I/O slot. =item B -Retrieves number of processors, speed, total memory, and DIMM -locations. +Retrieves number of processors, speed, total memory, and DIMM locations. =item B @@ -113,7 +107,7 @@ To output the raw information of deconfigured resources for CEC. =item B -Retrieves asset tag. Usually it's the MAC address of eth0. +Retrieves asset tag. Usually it's the MAC address of eth0. =item B @@ -125,19 +119,23 @@ Diagnostics information of firmware. =item B -Retrieves mprom firmware level +Retrieves mprom firmware level. + +=item B + +Retrieves dual in-line memory module information. =item B -Retrieves device identification. Usually device, manufacturing and product ids. +Retrieves device identification. Usually device, manufacturing and product IDs. =item B -Retrieves the universally unique identifier +Retrieves the universally unique identifier. =item B -Retrieves the global unique identifier +Retrieves the global unique identifier . =item B @@ -151,6 +149,10 @@ Print help. Print version. +=item B<-V>|B<--verbose> + +Prints verbose output, if available. + =item B<-t> Set the values in the vm table to what vCenter has for the indicated nodes. diff --git a/xCAT-client/pods/man1/rmdocker.1.pod b/xCAT-client/pods/man1/rmdocker.1.pod index efe339027..d02992870 100644 --- a/xCAT-client/pods/man1/rmdocker.1.pod +++ b/xCAT-client/pods/man1/rmdocker.1.pod @@ -29,7 +29,7 @@ Force to removal of a running container or failed to disconnect customized netwo =head1 EXAMPLES rmdocker host01c01 - host01c01: Disconnect customzied network 'mynet0' done + host01c01: Disconnect customized network 'mynet0' done host01c01: success =head1 SEE ALSO diff --git a/xCAT-client/pods/man1/rmdsklsnode.1.pod b/xCAT-client/pods/man1/rmdsklsnode.1.pod index 9500d2290..f7ed75e27 100644 --- a/xCAT-client/pods/man1/rmdsklsnode.1.pod +++ b/xCAT-client/pods/man1/rmdsklsnode.1.pod @@ -20,11 +20,11 @@ If the node you are trying to remove is currently running the B com B -If you used the "-n" option when you created the NIM client definitions with the B command then the NIM client machine names would be a combination of the xCAT node name and the osimage name used to initialize the NIM machine. To remove these definitions you must provide the name of the osimage that was used using the "-i" option. +If you used the "-n" option when you created the NIM client definitions with the B command then the NIM client machine names would be a combination of the xCAT node name and the osimage name used to initialize the NIM machine. To remove these definitions, you must provide the name of the osimage that was used using the "-i" option. -In most cases you would most likely want to remove the old client definitions without disturbing the nodes that you just booted with the new alternate client definition. The B option can be used to remove the old alternate client defintions without stopping the running node. +In most cases you would most likely want to remove the old client definitions without disturbing the nodes that you just booted with the new alternate client definition. The B option can be used to remove the old alternate client definitions without stopping the running node. -However, if you have NIM dump resources assign to your nodes be aware that when the old NIM alternate client definitions are removed it will leave the nodes unable to produce a system dump. This is a current limitation in the NIM support for alternate client definitions. For this reason it is recommended that you wait to do this cleanup until right before you do your next upgrade. +However, if you have NIM dump resources assign to your nodes be aware that when the old NIM alternate client definitions are removed it will leave the nodes unable to produce a system dump. This is a current limitation in the NIM support for alternate client definitions. For this reason, it is recommended that you wait to do this cleanup until right before you do your next upgrade. =head1 OPTIONS @@ -36,8 +36,7 @@ Use the force option to stop and remove running nodes. This handles the situatio =item B<-b |--backupSN> -When using backup service nodes only update the backup. The default is to updat -e both the primary and backup service nodes. +When using backup service nodes only update the backup. The default is to update both the primary and backup service nodes. =item B<-h |--help> @@ -53,8 +52,7 @@ A set of comma delimited node names and/or group names. See the "noderange" man =item B<-p|--primarySN> -When using backup service nodes only update the primary. The default is to upda -te both the primary and backup service nodes. +When using backup service nodes only update the primary. The default is to update both the primary and backup service nodes. =item B<-r|--remdef> diff --git a/xCAT-client/pods/man1/rmhwconn.1.pod b/xCAT-client/pods/man1/rmhwconn.1.pod index 86ea9a15e..d0dd7cad9 100644 --- a/xCAT-client/pods/man1/rmhwconn.1.pod +++ b/xCAT-client/pods/man1/rmhwconn.1.pod @@ -24,7 +24,7 @@ B B<-s> For PPC (with HMC) specific: -This command is used to disconnect CEC and Frame nodes from HMC nodes, according to the connection information defined in ppc talbe in xCAT DB. +This command is used to disconnect CEC and Frame nodes from HMC nodes, according to the connection information defined in ppc table in xCAT DB. Note: If a CEC belongs to a frame with a BPA installed, this CEC cannot be disconnected individually. Instead, the whole frame should be disconnected. diff --git a/xCAT-client/pods/man1/rmigrate.1.pod b/xCAT-client/pods/man1/rmigrate.1.pod index fea02a867..2be54a94f 100644 --- a/xCAT-client/pods/man1/rmigrate.1.pod +++ b/xCAT-client/pods/man1/rmigrate.1.pod @@ -49,7 +49,7 @@ The maximum quiesce time a VM may be stopped during a relocation attempt. =head1 B B table - -Table governing VM paramaters. See L for further details. +Table governing VM parameters. See L for further details. This is used to determine the current host to migrate from. =head1 B diff --git a/xCAT-client/pods/man1/rmkitcomp.1.pod b/xCAT-client/pods/man1/rmkitcomp.1.pod index 591f0cfd7..5484300dc 100644 --- a/xCAT-client/pods/man1/rmkitcomp.1.pod +++ b/xCAT-client/pods/man1/rmkitcomp.1.pod @@ -10,7 +10,7 @@ B [B<-V>|B<--verbose>] [B<-u>|B<--uninstall>] [B<-f>|B<--force>] [B<- =head1 DESCRIPTION -The B command removes kit components from an xCAT osimage. All the kit component attribute values that are contained in the osimage will be removed, and the kit comoponent meta rpm and package rpm could be uninstalled by B<-u|--uninstall> option. +The B command removes kit components from an xCAT osimage. All the kit component attribute values that are contained in the osimage will be removed, and the kit component meta rpm and package rpm could be uninstalled by B<-u|--uninstall> option. Note: The xCAT support for Kits is only available for Linux operating systems. diff --git a/xCAT-client/pods/man1/rmvm.1.pod b/xCAT-client/pods/man1/rmvm.1.pod index 959a350d8..2dcf8cc67 100644 --- a/xCAT-client/pods/man1/rmvm.1.pod +++ b/xCAT-client/pods/man1/rmvm.1.pod @@ -37,7 +37,7 @@ B<-r> Retain the data object definitions of the nodes. B<--service> Remove the service partitions of the specified CECs. -B<-p> KVM: Purge the existence of the VM from persistant storage. This will erase all storage related to the VM in addition to removing it from the active virtualization configuration. PPC: Remove the specified partiton on normal power machine. +B<-p> KVM: Purge the existence of the VM from persistent storage. This will erase all storage related to the VM in addition to removing it from the active virtualization configuration. PPC: Remove the specified partition on normal power machine. B<-f> Force remove the VM, even if the VM appears to be online. This will bring down a live VM if requested. diff --git a/xCAT-client/pods/man1/rnetboot.1.pod b/xCAT-client/pods/man1/rnetboot.1.pod index 6b9fc9671..e968e9f2d 100644 --- a/xCAT-client/pods/man1/rnetboot.1.pod +++ b/xCAT-client/pods/man1/rnetboot.1.pod @@ -41,11 +41,11 @@ Note: if the "val" fields includes spaces or any other characters that will be p B<-r> -specify the number of retries that the monitoring process will perform before declare the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag. +specify the number of retries that the monitoring process will perform before declaring the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag. B<-t> -Specify the the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified. +Specify the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified. B<-V|--verbose> diff --git a/xCAT-client/pods/man1/rpower.1.pod b/xCAT-client/pods/man1/rpower.1.pod index 61e7be87c..0e38e78c8 100644 --- a/xCAT-client/pods/man1/rpower.1.pod +++ b/xCAT-client/pods/man1/rpower.1.pod @@ -14,13 +14,13 @@ B I [B|B|B|B|B|B|B I [B|B|B|B] -=head2 OpenPower BMC (using IPMI): +=head2 OpenPOWER BMC (using IPMI): B I [B|B|B|B|B|B|B] B I [B|B|B|B] -=head2 OpenPower OpenBMC: +=head2 OpenPOWER OpenBMC: B I [B|B|B|B|B|B|B] @@ -104,7 +104,7 @@ Exit Rack standby will be the default state that a rack goes into when power is =item B -Reboot the service processor. If there are primary and secondary FSPs/BPAs of one cec/frame, it will reboot them almost at the sametime. +Reboot the service processor. If there are primary and secondary FSPs/BPAs of one cec/frame, it will reboot them almost at the same time. =item B @@ -207,11 +207,11 @@ Do not use dependency table (default is to use dependency table). Valid only wit =item B<-r> I -specify the number of retries that the monitoring process will perform before declare the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag. +specify the number of retries that the monitoring process will perform before declaring the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag. =item B<-t> I -Specify the the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified. +Specify the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified. Power off, then on. diff --git a/xCAT-client/pods/man1/rspconfig.1.pod b/xCAT-client/pods/man1/rspconfig.1.pod index 900224f65..aba5fcd5a 100644 --- a/xCAT-client/pods/man1/rspconfig.1.pod +++ b/xCAT-client/pods/man1/rspconfig.1.pod @@ -416,7 +416,7 @@ Set the blade or MPA textid. When using '*', the textid used is the node name sp =item B={I} B={B} -Change the password of the userid B for CMM in Flex system cluster. The option I can be used to specify whether updating the password of BMCs that connected to the speified CMM. The value is 'y' by default which means whenever updating the password of CMM, the password of BMCs will be also updated. Note that there will be several seconds needed before this command complete. +Change the password of the userid B for CMM in Flex system cluster. The option I can be used to specify whether updating the password of BMCs that connected to the specified CMM. The value is 'y' by default which means whenever updating the password of CMM, the password of BMCs will be also updated. Note that there will be several seconds needed before this command complete. If value "*" is specified for USERID and the object node is I, the password used to access the BMC of the System X node through IPMI will be updated as the same password of the userid B of the CMM in the same cluster. diff --git a/xCAT-client/pods/man1/rvitals.1.pod b/xCAT-client/pods/man1/rvitals.1.pod index 32ff2fb81..fb246eb40 100644 --- a/xCAT-client/pods/man1/rvitals.1.pod +++ b/xCAT-client/pods/man1/rvitals.1.pod @@ -26,13 +26,17 @@ B I {B|B|B|B|B|B I {B|B|B|B|B|B|B} -=head2 OpenPOWER server specific: +=head2 OpenPOWER (IPMI) specific: -B I [B|B|B|B|B|B|B] +B I [B|B|B|B|B|B|B|B] + +=head2 OpenPOWER (OpenBMC) specific: + +B I [B|B|B|B|B|B|B] =head1 B -B retrieves hardware vital information from the on-board Service +B Retrieves hardware vital information from the on-board Service Processor for a single or range of nodes and groups. =head1 B @@ -75,6 +79,14 @@ Retrieves rack environmentals. Retrieves LEDs status. +=item B + +Retrieves chassis status. + +=item B + +Retrieves altitude related attributes. + =item B Retrieves power status. diff --git a/xCAT-client/pods/man1/sinv.1.pod b/xCAT-client/pods/man1/sinv.1.pod index 9c08ced7e..1d6dfa3d5 100644 --- a/xCAT-client/pods/man1/sinv.1.pod +++ b/xCAT-client/pods/man1/sinv.1.pod @@ -4,7 +4,7 @@ B - Checks the software configuration of the nodes in the cluster. =head1 B -B [B<-o> I] [B<-p> I