mirror of
https://github.com/xcat2/xcat-core.git
synced 2025-06-13 09:50:19 +00:00
Spelling fixes for docs/sources/advanced rst files
This commit is contained in:
@ -25,7 +25,7 @@ Remove Old Provision Environment
|
||||
Change Definition
|
||||
-----------------
|
||||
|
||||
#. Change netwoks table definitions ::
|
||||
#. Change networks table definitions ::
|
||||
|
||||
lsdef -t network -l
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
=====================
|
||||
|
@ -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
|
||||
|
||||
|
@ -18,9 +18,9 @@ The nfs service on the primary management node or the primary management node it
|
||||
What is Shared Data
|
||||
====================
|
||||
|
||||
The term ``Shared Data`` means that the two management nodes use a single copy of xCAT data, no matter which management node is the primary MN, the cluster management capability is running on top of the single data copy. The acess to the data could be done through various ways like shared storage, NAS, NFS, samba etc. Based on the protocol being used, the data might be accessable only on one management node at a time or be accessable on both management nodes in parellel. If the data could only be accessed from one management node, the failover process need to take care of the data access transition; if the data could be accessed on both management nodes, the failover does not need to consider the data access transition, it usually means the failover process could be faster.
|
||||
The term ``Shared Data`` means that the two management nodes use a single copy of xCAT data, no matter which management node is the primary MN, the cluster management capability is running on top of the single data copy. The access to the data could be done through various ways like shared storage, NAS, NFS, samba etc. Based on the protocol being used, the data might be accessible only on one management node at a time or be accessible on both management nodes in parallel. If the data could only be accessed from one management node, the failover process need to take care of the data access transition; if the data could be accessed on both management nodes, the failover does not need to consider the data access transition, it usually means the failover process could be faster.
|
||||
|
||||
``Warning``: Running database through network file system has a lot of potential problems and is not practical, however, most of the database system provides database replication feature that can be used to synronize the database between the two management nodes
|
||||
``Warning``: Running database through network file system has a lot of potential problems and is not practical, however, most of the database system provides database replication feature that can be used to synchronize the database between the two management nodes
|
||||
|
||||
Configuration Requirements
|
||||
==========================
|
||||
@ -248,7 +248,7 @@ Besides the files mentioned above, there may be some additional customization fi
|
||||
|
||||
``Note``:
|
||||
If the IBM HPC software stack is configured in your environment, execute additional steps required to copy additional data or configuration files for HAMN setup.
|
||||
The dhcpsd.cnf should be syncronized between the primary management node and standby management node only when the DHCP configuration on the two management nodes are exactly the same.
|
||||
The dhcpsd.cnf should be synchronized between the primary management node and standby management node only when the DHCP configuration on the two management nodes are exactly the same.
|
||||
|
||||
Cluster Maintenance Considerations
|
||||
==================================
|
||||
@ -268,7 +268,7 @@ At this point, the HA MN Setup is complete, and customer workloads and system ad
|
||||
Failover
|
||||
========
|
||||
|
||||
There are two kinds of failover, planned failover and unplanned failover. The planned failover can be useful for updating the management nodes or any scheduled maintainance activities; the unplanned failover covers the unexpected hardware or software failures.
|
||||
There are two kinds of failover, planned failover and unplanned failover. The planned failover can be useful for updating the management nodes or any scheduled maintenance activities; the unplanned failover covers the unexpected hardware or software failures.
|
||||
|
||||
In a planned failover, you can do necessary cleanup work on the previous primary management node before failover to the previous standby management node. In a unplanned failover, the previous management node probably is not functioning at all, you can simply shutdown the system.
|
||||
|
||||
@ -367,7 +367,7 @@ On the new primary management node:
|
||||
|
||||
**DNS**: run ``makedns``. Verify dns services working for node resolution. Make sure the line ``nameserver=<virtual ip>`` is in ``/etc/resolv.conf``.
|
||||
|
||||
**DHCP**: if the dhcpd.leases is not syncronized between the primary management node and standby management node, run ``makedhcp -a`` to setup the DHCP leases. Verify dhcp is operational.
|
||||
**DHCP**: if the dhcpd.leases is not synchronized between the primary management node and standby management node, run ``makedhcp -a`` to setup the DHCP leases. Verify dhcp is operational.
|
||||
|
||||
**conserver**: run makeconservercf. This will recreate the ``/etc/conserver.cf`` config files for all the nodes.
|
||||
|
||||
|
@ -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"``
|
||||
|
@ -33,4 +33,4 @@ Restart PostgreSQL after editing the file: ::
|
||||
|
||||
|
||||
For more information about changing the ``pg_hab.conf`` file and ``postgresql.conf`` files, see the following documentation:
|
||||
`Setup the PostgreSQL Configuraion Files <https://sourceforge.net/p/xcat/wiki/Setting_Up_PostgreSQL_as_the_xCAT_DB/#setup-the-postgresql-configuration-files>`_
|
||||
`Setup the PostgreSQL Configuration Files <https://sourceforge.net/p/xcat/wiki/Setting_Up_PostgreSQL_as_the_xCAT_DB/#setup-the-postgresql-configuration-files>`_
|
||||
|
@ -179,7 +179,7 @@ compute node is rebooted or the compute node is explicitly moved to another SN
|
||||
using the `snmove <http://localhost/fake_todo>`_ command.
|
||||
|
||||
To use Service Node pools, you need to architect your network such that all of
|
||||
the compute nodes and service nodes in a partcular pool are on the same flat
|
||||
the compute nodes and service nodes in a particular pool are on the same flat
|
||||
network. If you don't want the management node to respond to manage some of
|
||||
the compute nodes, it shouldn't be on that same flat network. The
|
||||
site, dhcpinterfaces attribute should be set such that the SNs' DHCP daemon
|
||||
|
@ -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.
|
||||
|
||||
::
|
||||
|
||||
|
@ -49,7 +49,7 @@ Kit Framework
|
||||
|
||||
With time, the implementation of the xCAT Software Kit support may change.
|
||||
|
||||
In order to process a kit successfully, the kit must be conpatiable with the level of xCAT code that was used to build the kit. The xCAT kit commands and software kits contain the framework version and compatiable supported versions.
|
||||
In order to process a kit successfully, the kit must be compatible with the level of xCAT code that was used to build the kit. The xCAT kit commands and software kits contain the framework version and compatible supported versions.
|
||||
|
||||
To view the framework version, use the ``-v | --version`` option on :doc:`addkit </guides/admin-guides/references/man1/addkit.1>` ::
|
||||
|
||||
@ -59,7 +59,7 @@ To view the framework version, use the ``-v | --version`` option on :doc:`addkit
|
||||
compatible_frameworks = 0,1,2
|
||||
|
||||
|
||||
If the commands in the xCAT installation is not compatiable with the Software Kit obtained, update xCAT to a more recent release.
|
||||
If the commands in the xCAT installation is not compatible with the Software Kit obtained, update xCAT to a more recent release.
|
||||
|
||||
|
||||
.. [#] PCM is IBM Platform Cluster Manager
|
||||
|
@ -14,7 +14,7 @@ To check if a kitcomponent is valid for an existing OS image definition run the
|
||||
|
||||
chkkitcomp -i <osimage> <kitcompname>
|
||||
|
||||
If the kit component is compatible then add the kitcomponent to the OS image defintion using the addkitcomp command. ::
|
||||
If the kit component is compatible then add the kitcomponent to the OS image definition using the addkitcomp command. ::
|
||||
|
||||
addkitcomp -a -i <osimage> <kitcompname>
|
||||
|
||||
@ -34,7 +34,7 @@ The contents of the kit component may be listed by using the lskitcomponent comm
|
||||
Adding Multiple Versions of the Same Kit Component to an OS Image Definition
|
||||
`````````````````````````````````````````````````````````````````````````````
|
||||
|
||||
xCAT allows to have multiple versions/releases of a product software kit available in the cluster. Typically, different OS image definitions corresponding to the different versions/releases of a product software stack. However, in some instances, may need mulitple versions/releases of the same product available within a single OS image. This is only feasible if the software product supports the install of multiple versions or releases of its product within an OS image.
|
||||
xCAT allows to have multiple versions/releases of a product software kit available in the cluster. Typically, different OS image definitions corresponding to the different versions/releases of a product software stack. However, in some instances, may need multiple versions/releases of the same product available within a single OS image. This is only feasible if the software product supports the install of multiple versions or releases of its product within an OS image.
|
||||
|
||||
Currently, it is not possible to install multiple versions of a product into an OS image using xCAT commands. xCAT uses yum on RedHat and zypper on SLES to install product rpms. These package managers do not provide an interface to install different versions of the same package, and will always force an upgrade of the package. We are investigating different ways to accomplish this function for future xCAT releases.
|
||||
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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.
|
||||
|
||||
|
@ -21,7 +21,7 @@ Burn new firmware on each ibaX: ::
|
||||
|
||||
mstflint -d 0002:01:00.0 -i <image location> b
|
||||
|
||||
Note: if this is a PureFlex MezzanineP adapater then you must select the correct image for each ibaX device. Note the difference in the firmware image at end of filename: _0.bin (iba0/iba2) & _1.bin (iba1/iba3)
|
||||
Note: if this is a PureFlex MezzanineP adapter then you must select the correct image for each ibaX device. Note the difference in the firmware image at end of filename: _0.bin (iba0/iba2) & _1.bin (iba1/iba3)
|
||||
|
||||
Verify download successful: ::
|
||||
|
||||
|
@ -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
|
||||
|
@ -18,7 +18,7 @@ Diskful Installation
|
||||
chdef -t node -o <node_name> \
|
||||
-p postscripts="mlnxofed_ib_install -p /install/<path-to>/<MLNX_OFED_LINUX.iso>"
|
||||
|
||||
**[kernel mismatch issue]** The Mellanox OFED ISO is built againt a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. ::
|
||||
**[kernel mismatch issue]** The Mellanox OFED ISO is built against a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. ::
|
||||
|
||||
chdef -t node -o <node_name> \
|
||||
-p postscripts="mlnxofed_ib_install -p /install/<path-to>/<MLNX_OFED_LINUX.iso> \
|
||||
@ -42,4 +42,4 @@ Diskful Installation
|
||||
|
||||
* Verify that the Mellanox IB drivers are located at: ``/lib/modules/<kernel_version>/extra/``
|
||||
|
||||
* Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter.
|
||||
* Use the ``ibv_devinfo`` command to obtain information about the InfiniBand adapter.
|
||||
|
@ -28,7 +28,7 @@ Diskless Installation
|
||||
|
||||
*Note: The $1 is a argument that is passed to the the postinstall script at runtime.*
|
||||
|
||||
**[kernel mismatch issue]** The Mellanox OFED ISO is built againt a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. ::
|
||||
**[kernel mismatch issue]** The Mellanox OFED ISO is built against a series of specific kernel version. If the version of the linux kernel does not match any of the Mellanox offered pre-built kernel modules, you can pass the ``--add-kernel-support`` argument to the Mellanox installation script to build the kernel modules based on the version you are using. ::
|
||||
|
||||
/install/postscripts/mlnxofed_ib_install \
|
||||
-p /install/<path-to>/<MLNX_OFED_LINUX.iso> -m --add-kernel-support -end- \
|
||||
@ -62,4 +62,4 @@ Diskless Installation
|
||||
|
||||
* Verify that the Mellanox IB drivers are located at: ``/lib/modules/<kernel_version>/extra/``
|
||||
|
||||
* Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter.
|
||||
* Use the ``ibv_devinfo`` command to obtain information about the InfiniBand adapter.
|
||||
|
@ -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 |
|
||||
|
@ -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**
|
||||
|
||||
|
@ -66,7 +66,7 @@ Then run the following: ::
|
||||
Setup syslog on the Switch
|
||||
--------------------------
|
||||
|
||||
Use the following command to consolidate the syslog to the Management Node or Service Nodes, where ip is the addess of the MN or SN as known by the switch. ::
|
||||
Use the following command to consolidate the syslog to the Management Node or Service Nodes, where ip is the address of the MN or SN as known by the switch. ::
|
||||
|
||||
rspconfig mswitch logdest=<ip>
|
||||
|
||||
|
@ -12,7 +12,7 @@ xCAT provides support for detecting and installing the Cumulus Linux OS into ONI
|
||||
|
||||
The mac address of the switch management port is required for xCAT to configure the DHCP information and send over the OS to install on the switch.
|
||||
|
||||
**[small clusters]** If you know the mac address of the management port on the switch, create the pre-defined switch defintion providing the mac address. ::
|
||||
**[small clusters]** If you know the mac address of the management port on the switch, create the pre-defined switch definition providing the mac address. ::
|
||||
|
||||
mkdef frame01sw1 --template onieswitch arch=armv71 \
|
||||
ip=192.168.1.1 mac="aa:bb:cc:dd:ee:ff"
|
||||
@ -32,7 +32,7 @@ xCAT provides support for detecting and installing the Cumulus Linux OS into ONI
|
||||
ip=192.168.4.1 switch=coresw1 switchport=4
|
||||
...
|
||||
|
||||
#. Leverage ``switchdiscover`` over the DHCP range to automatically detect the MAC address and write them into the predefined swtiches above. ::
|
||||
#. Leverage ``switchdiscover`` over the DHCP range to automatically detect the MAC address and write them into the predefined switches above. ::
|
||||
|
||||
switchdiscover --range <IP range>
|
||||
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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
|
||||
----------
|
||||
|
@ -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
|
||||
|
@ -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``:
|
||||
|
||||
|
@ -15,7 +15,7 @@ POST - Create a token.
|
||||
|
||||
**Example:**
|
||||
|
||||
Aquire a token for user 'root'. ::
|
||||
Acquire a token for user 'root'. ::
|
||||
|
||||
|
||||
#curl -X POST -k 'https://127.0.0.1/xcatws/tokens?userName=root&userPW=cluster&pretty=1' -H Content-Type:application/json --data '{"userName":"root","userPW":"cluster"}'
|
||||
@ -62,8 +62,8 @@ Get all the node names from xCAT database. ::
|
||||
[URI:/nodes/{noderange}] - The node resource
|
||||
--------------------------------------------
|
||||
|
||||
GET - Get all the attibutes for the node {noderange}.
|
||||
`````````````````````````````````````````````````````
|
||||
GET - Get all the attributes for the node {noderange}.
|
||||
``````````````````````````````````````````````````````
|
||||
|
||||
The keyword ALLRESOURCES can be used as {noderange} which means to get node attributes for all the nodes.
|
||||
|
||||
@ -75,7 +75,7 @@ Refer to the man page: :doc:`lsdef </guides/admin-guides/references/man1/lsdef.1
|
||||
|
||||
**Example:**
|
||||
|
||||
Get all the attibutes for node 'node1'. ::
|
||||
Get all the attributes for node 'node1'. ::
|
||||
|
||||
|
||||
#curl -X GET -k 'https://127.0.0.1/xcatws/nodes/node1?userName=root&userPW=cluster&pretty=1'
|
||||
@ -90,8 +90,8 @@ Get all the attibutes for node 'node1'. ::
|
||||
}
|
||||
}
|
||||
|
||||
PUT - Change the attibutes for the node {noderange}.
|
||||
````````````````````````````````````````````````````
|
||||
PUT - Change the attributes for the node {noderange}.
|
||||
`````````````````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1>`
|
||||
|
||||
@ -101,7 +101,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -122,7 +122,7 @@ Refer to the man page: :doc:`mkdef </guides/admin-guides/references/man1/mkdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -138,7 +138,7 @@ Refer to the man page: :doc:`rmdef </guides/admin-guides/references/man1/rmdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -184,7 +184,7 @@ Refer to the man page: :doc:`makehosts </guides/admin-guides/references/man8/mak
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -204,7 +204,7 @@ Refer to the man page: :doc:`makedns </guides/admin-guides/references/man8/maked
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -219,7 +219,7 @@ Refer to the man page: :doc:`makedns </guides/admin-guides/references/man8/maked
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -237,7 +237,7 @@ Refer to the man page: :doc:`makedhcp </guides/admin-guides/references/man8/make
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -252,7 +252,7 @@ Refer to the man page: :doc:`makedhcp </guides/admin-guides/references/man8/make
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -356,7 +356,7 @@ Refer to the man page: :doc:`rpower </guides/admin-guides/references/man1/rpower
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -401,7 +401,7 @@ Refer to the man page: :doc:`renergy </guides/admin-guides/references/man1/rener
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -469,7 +469,7 @@ Refer to the man page: :doc:`rspconfig </guides/admin-guides/references/man1/rsp
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -512,7 +512,7 @@ Refer to the man page: :doc:`rsetboot </guides/admin-guides/references/man1/rset
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -555,7 +555,7 @@ Refer to the man page: :doc:`nodeset </guides/admin-guides/references/man1/nimno
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -566,7 +566,7 @@ Set the next boot state for the node1. ::
|
||||
[URI:/nodes/{noderange}/vitals] - The vitals resources for the node {noderange}
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
GET - Get all the vitals attibutes.
|
||||
GET - Get all the vitals attributes.
|
||||
```````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`rvitals </guides/admin-guides/references/man1/rvitals.1>`
|
||||
@ -597,7 +597,7 @@ Get all the vitails attributes for the node1. ::
|
||||
[URI:/nodes/{noderange}/vitals/{temp|voltage|wattage|fanspeed|power|leds...}] - The specific vital attributes for the node {noderange}
|
||||
--------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
GET - Get the specific vitals attibutes.
|
||||
GET - Get the specific vitals attributes.
|
||||
````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`rvitals </guides/admin-guides/references/man1/rvitals.1>`
|
||||
@ -628,7 +628,7 @@ Get the 'fanspeed' vitals attribute. ::
|
||||
[URI:/nodes/{noderange}/inventory] - The inventory attributes for the node {noderange}
|
||||
--------------------------------------------------------------------------------------
|
||||
|
||||
GET - Get all the inventory attibutes.
|
||||
GET - Get all the inventory attributes.
|
||||
``````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`rinv </guides/admin-guides/references/man1/rinv.1>`
|
||||
@ -659,7 +659,7 @@ Get all the inventory attributes for node1. ::
|
||||
[URI:/nodes/{noderange}/inventory/{pci|model...}] - The specific inventory attributes for the node {noderange}
|
||||
--------------------------------------------------------------------------------------------------------------
|
||||
|
||||
GET - Get the specific inventory attibutes.
|
||||
GET - Get the specific inventory attributes.
|
||||
```````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`rinv </guides/admin-guides/references/man1/rinv.1>`
|
||||
@ -714,7 +714,7 @@ Refer to the man page: :doc:`reventlog </guides/admin-guides/references/man1/rev
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -745,7 +745,7 @@ Refer to the man page: :doc:`rbeacon </guides/admin-guides/references/man1/rbeac
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -918,7 +918,7 @@ Refer to the man page: :doc:`xdcp </guides/admin-guides/references/man1/xdcp.1>`
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -947,7 +947,7 @@ Refer to the man page: :doc:`chvm </guides/admin-guides/references/man1/chvm.1>`
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example1:**
|
||||
|
||||
@ -982,7 +982,7 @@ Refer to the man page: :doc:`mkvm </guides/admin-guides/references/man1/mkvm.1>`
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1003,7 +1003,7 @@ Refer to the man page: :doc:`rmvm </guides/admin-guides/references/man1/rmvm.1>`
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1112,7 +1112,7 @@ Refer to the man page: :doc:`copycds </guides/admin-guides/references/man8/copyc
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example1:**
|
||||
|
||||
@ -1129,7 +1129,7 @@ Create osimage resources based on an xCAT image or configuration file ::
|
||||
[URI:/osimages/{imgname}] - The osimage resource
|
||||
------------------------------------------------
|
||||
|
||||
GET - Get all the attibutes for the osimage {imgname}.
|
||||
GET - Get all the attributes for the osimage {imgname}.
|
||||
``````````````````````````````````````````````````````
|
||||
|
||||
The keyword ALLRESOURCES can be used as {imgname} which means to get image attributes for all the osimages.
|
||||
@ -1162,7 +1162,7 @@ Get the attributes for the specified osimage. ::
|
||||
}
|
||||
}
|
||||
|
||||
PUT - Change the attibutes for the osimage {imgname}.
|
||||
PUT - Change the attributes for the osimage {imgname}.
|
||||
`````````````````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1>`
|
||||
@ -1173,7 +1173,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1192,7 +1192,7 @@ Refer to the man page: :doc:`mkdef </guides/admin-guides/references/man1/mkdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1207,7 +1207,7 @@ Refer to the man page: :doc:`rmdef </guides/admin-guides/references/man1/rmdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1257,7 +1257,7 @@ Refer to the man page: :doc:` </guides/admin-guides/references/>`
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example1:**
|
||||
|
||||
@ -1284,7 +1284,7 @@ Refer to the man page: :doc:`rmimage </guides/admin-guides/references/man1/rmima
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1336,7 +1336,7 @@ Refer to the man page: :doc:`makenetworks </guides/admin-guides/references/man8/
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1347,7 +1347,7 @@ Create the networks resources base on the network configuration on xCAT MN. ::
|
||||
[URI:/networks/{netname}] - The network resource
|
||||
------------------------------------------------
|
||||
|
||||
GET - Get all the attibutes for the network {netname}.
|
||||
GET - Get all the attributes for the network {netname}.
|
||||
``````````````````````````````````````````````````````
|
||||
|
||||
The keyword ALLRESOURCES can be used as {netname} which means to get network attributes for all the networks.
|
||||
@ -1360,7 +1360,7 @@ Refer to the man page: :doc:`lsdef </guides/admin-guides/references/man1/lsdef.1
|
||||
|
||||
**Example:**
|
||||
|
||||
Get all the attibutes for network 'network1'. ::
|
||||
Get all the attributes for network 'network1'. ::
|
||||
|
||||
#curl -X GET -k 'https://127.0.0.1/xcatws/networks/network1?userName=root&userPW=cluster&pretty=1'
|
||||
{
|
||||
@ -1374,7 +1374,7 @@ Get all the attibutes for network 'network1'. ::
|
||||
}
|
||||
}
|
||||
|
||||
PUT - Change the attibutes for the network {netname}.
|
||||
PUT - Change the attributes for the network {netname}.
|
||||
`````````````````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1>`
|
||||
@ -1385,7 +1385,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1404,7 +1404,7 @@ Refer to the man page: :doc:`mkdef </guides/admin-guides/references/man1/mkdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1419,7 +1419,7 @@ Refer to the man page: :doc:`rmdef </guides/admin-guides/references/man1/rmdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1487,7 +1487,7 @@ Get all the policy objects. ::
|
||||
[URI:/policy/{policy_priority}] - The policy resource
|
||||
-----------------------------------------------------
|
||||
|
||||
GET - Get all the attibutes for a policy {policy_priority}.
|
||||
GET - Get all the attributes for a policy {policy_priority}.
|
||||
```````````````````````````````````````````````````````````
|
||||
|
||||
It will display all the policy attributes for one policy resource.
|
||||
@ -1512,7 +1512,7 @@ Get all the attribute for policy 1. ::
|
||||
}
|
||||
}
|
||||
|
||||
PUT - Change the attibutes for the policy {policy_priority}.
|
||||
PUT - Change the attributes for the policy {policy_priority}.
|
||||
````````````````````````````````````````````````````````````
|
||||
|
||||
It will change one or more attributes for a policy.
|
||||
@ -1525,7 +1525,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1547,7 +1547,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1564,7 +1564,7 @@ Refer to the man page: :doc:`rmdef </guides/admin-guides/references/man1/rmdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1637,7 +1637,7 @@ Get all the group names from xCAT database. ::
|
||||
[URI:/groups/{groupname}] - The group resource
|
||||
----------------------------------------------
|
||||
|
||||
GET - Get all the attibutes for the group {groupname}.
|
||||
GET - Get all the attributes for the group {groupname}.
|
||||
``````````````````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`lsdef </guides/admin-guides/references/man1/lsdef.1>`
|
||||
@ -1648,7 +1648,7 @@ Refer to the man page: :doc:`lsdef </guides/admin-guides/references/man1/lsdef.1
|
||||
|
||||
**Example:**
|
||||
|
||||
Get all the attibutes for group 'all'. ::
|
||||
Get all the attributes for group 'all'. ::
|
||||
|
||||
#curl -X GET -k 'https://127.0.0.1/xcatws/groups/all?userName=root&userPW=cluster&pretty=1'
|
||||
{
|
||||
@ -1657,7 +1657,7 @@ Get all the attibutes for group 'all'. ::
|
||||
}
|
||||
}
|
||||
|
||||
PUT - Change the attibutes for the group {groupname}.
|
||||
PUT - Change the attributes for the group {groupname}.
|
||||
`````````````````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1>`
|
||||
@ -1668,7 +1668,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1776,7 +1776,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1793,7 +1793,7 @@ Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1816,7 +1816,7 @@ Refer to the man page: :doc:`makedns </guides/admin-guides/references/man8/maked
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1834,7 +1834,7 @@ Refer to the man page: :doc:`makedhcp </guides/admin-guides/references/man8/make
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1852,7 +1852,7 @@ Refer to the man page: :doc:`makehosts </guides/admin-guides/references/man8/mak
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -1954,7 +1954,7 @@ URI list which can be used to create, query, change table entries.
|
||||
|
||||
For a large number of nodes, this API call can be faster than using the corresponding nodes resource. The disadvantage is that you need to know the table names the attributes are stored in.
|
||||
|
||||
GET - Get attibutes of tables for a noderange.
|
||||
GET - Get attributes of tables for a noderange.
|
||||
``````````````````````````````````````````````
|
||||
|
||||
**Returns:**
|
||||
@ -2025,7 +2025,7 @@ Get all the columns from tables nodetype and noderes for node1 and node2. ::
|
||||
]
|
||||
}
|
||||
|
||||
PUT - Change the node table attibutes for {noderange}.
|
||||
PUT - Change the node table attributes for {noderange}.
|
||||
``````````````````````````````````````````````````````
|
||||
|
||||
**Parameters:**
|
||||
@ -2034,7 +2034,7 @@ PUT - Change the node table attibutes for {noderange}.
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -2047,7 +2047,7 @@ Change the nodetype.arch and noderes.netboot attributes for nodes node1,node2. :
|
||||
|
||||
For a large number of nodes, this API call can be faster than using the corresponding nodes resource. The disadvantage is that you need to know the table names the attributes are stored in.
|
||||
|
||||
GET - Get table attibutes for a noderange.
|
||||
GET - Get table attributes for a noderange.
|
||||
``````````````````````````````````````````
|
||||
|
||||
**Returns:**
|
||||
@ -2078,7 +2078,7 @@ Get OS and ARCH attributes from nodetype table for node1 and node2. ::
|
||||
[URI:/tables/{tablelist}/rows] - The non-node table resource
|
||||
------------------------------------------------------------
|
||||
|
||||
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, polciy, etc.
|
||||
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, policy, etc.
|
||||
|
||||
GET - Get all rows from non-node tables.
|
||||
````````````````````````````````````````
|
||||
@ -2115,11 +2115,11 @@ Get all rows from networks table. ::
|
||||
[URI:/tables/{tablelist}/rows/{keys}] - The non-node table rows resource
|
||||
------------------------------------------------------------------------
|
||||
|
||||
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, polciy, etc.
|
||||
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, policy, etc.
|
||||
|
||||
{keys} should be the name=value pairs which are used to search table. e.g. {keys} should be [net=192.168.1.0,mask=255.255.255.0] for networks table query since the net and mask are the keys of networks table.
|
||||
|
||||
GET - Get attibutes for rows from non-node tables.
|
||||
GET - Get attributes for rows from non-node tables.
|
||||
``````````````````````````````````````````````````
|
||||
|
||||
**Returns:**
|
||||
@ -2146,8 +2146,8 @@ Get row which net=192.168.1.0,mask=255.255.255.0 from networks table. ::
|
||||
]
|
||||
}
|
||||
|
||||
PUT - Change the non-node table attibutes for the row that matches the {keys}.
|
||||
``````````````````````````````````````````````````````````````````````````````
|
||||
PUT - Change the non-node table attributes for the row that matches the {keys}.
|
||||
```````````````````````````````````````````````````````````````````````````````
|
||||
|
||||
**Parameters:**
|
||||
|
||||
@ -2155,7 +2155,7 @@ PUT - Change the non-node table attibutes for the row that matches the {keys}.
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -2168,7 +2168,7 @@ DELETE - Delete rows from a non-node table that have the attribute values specif
|
||||
|
||||
**Returns:**
|
||||
|
||||
* No output when execution is successfull. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
* No output when execution is successful. Otherwise output the error information in the Standard Error Format: {error:[msg1,msg2...],errocode:errornum}.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -2179,10 +2179,10 @@ Delete a route row which routename=privnet in the routes table. ::
|
||||
[URI:/tables/{tablelist}/rows/{keys}/{attrlist}] - The non-node table attributes resource
|
||||
-----------------------------------------------------------------------------------------
|
||||
|
||||
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, polciy, etc.
|
||||
Use this for tables that don't have node name as the key of the table, for example: passwd, site, networks, policy, etc.
|
||||
|
||||
GET - Get specific attibutes for rows from non-node tables.
|
||||
```````````````````````````````````````````````````````````
|
||||
GET - Get specific attributes for rows from non-node tables.
|
||||
````````````````````````````````````````````````````````````
|
||||
|
||||
**Returns:**
|
||||
|
||||
|
@ -220,4 +220,4 @@ If you install systemimager RPMs on CentOS 6.5 node using **yum**, you may exper
|
||||
Kernel panic at times when install target node with rhels7.0 in Power 7 server
|
||||
``````````````````````````````````````````````````````````````````````````````
|
||||
|
||||
When you clone rhels7.0 image to target node which is Power 7 server lpar, you may hit Kernel panic problem at times after boot loader grub2 download kernel and initrd. This is an known issue but without a resulution. For now, we recommend you try again.
|
||||
When you clone rhels7.0 image to target node which is Power 7 server lpar, you may hit Kernel panic problem at times after boot loader grub2 download kernel and initrd. This is an known issue but without a resolution. For now, we recommend you try again.
|
||||
|
@ -11,7 +11,7 @@ The new support only addresses the way we generate and distribute root's ssh RSA
|
||||
|
||||
In the past, the setup allowed compute nodes to be able to ssh to the SN's without a password. Using zones, will no longer allow this to happen. Using zones only allows compute nodes to ssh without password to compute node, unless you add the service node into the zone which is not considered a good idea.
|
||||
|
||||
But add service node into a zone is not a good idea. Beacuse:
|
||||
But add service node into a zone is not a good idea. Because:
|
||||
|
||||
* IF you put the service node in a zone, it will no longer be able to ssh to the other servicenodes with being prompted for a password.
|
||||
* Allowing the compute node to ssh to the service node, could allow the service node to be compromised, by anyone who gained access to the compute node.
|
||||
|
Reference in New Issue
Block a user