mirror of
https://github.com/xcat2/xcat-core.git
synced 2025-05-31 01:56:39 +00:00
Merge pull request #3 from xcat2/master
Sync up with latest xcat2 team files
This commit is contained in:
zVMopenstack
GitHub
commit
680148ac01
19
README.rst
19
README.rst
@ -8,7 +8,7 @@ Documentation
|
||||
|
||||
xCAT documentation is available at: http://xcat-docs.readthedocs.io/en/latest/
|
||||
|
||||
|docs_latest| |docs_212| |docs_211|
|
||||
|docs_latest| |docs_2123| |docs_2122| |docs_212| |docs_211|
|
||||
|
||||
Open Source License
|
||||
-------------------
|
||||
@ -22,11 +22,20 @@ Developers
|
||||
Developers and prospective contributors are encouraged to read the `Developers Guide <http://xcat-docs.readthedocs.io/en/latest/developers/>`_
|
||||
In particular the `GitHub <http://xcat-docs.readthedocs.io/en/latest/developers/github/>`_ related subsection.
|
||||
|
||||
|
||||
.. |docs_212| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.12
|
||||
:alt: 2.12 documentation status
|
||||
.. |docs_2123| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.12.3
|
||||
:alt: 2.12.3 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.12/
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.12.3/
|
||||
|
||||
.. |docs_2122| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.12.2
|
||||
:alt: 2.12.2 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.12.2/
|
||||
|
||||
.. |docs_212| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.12.0
|
||||
:alt: 2.12.0 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.12.0/
|
||||
|
||||
.. |docs_211| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.11
|
||||
:alt: 2.11 documentation status
|
||||
|
||||
@ -102,16 +102,6 @@ if [ "$c_flag" -a "$d_flag" ];then
|
||||
fi
|
||||
|
||||
|
||||
|
||||
uploader="litingt"
|
||||
USER="xcat"
|
||||
SERVER="xcat.org"
|
||||
FILES_PATH="files"
|
||||
FRS="/var/www/${SERVER}/${FILES_PATH}"
|
||||
release="github.com/xcat2/xcat-core/releases"
|
||||
APT_DIR="${FRS}/xcat"
|
||||
APT_REPO_DIR="${APT_DIR}/repos/apt"
|
||||
|
||||
# Find where this script is located to set some build variables
|
||||
old_pwd=`pwd`
|
||||
cd `dirname $0`
|
||||
@ -121,11 +111,6 @@ curdir=`pwd`
|
||||
local_core_repo_path="$curdir/../../xcat-core"
|
||||
local_dep_repo_path="$curdir/../../xcat-dep/xcat-dep"
|
||||
|
||||
#define the url used for creating the source list file
|
||||
#define the upload dir used for uploading packages
|
||||
sf_repo_url="https://xcat.org/files/ubuntu"
|
||||
sf_dir="/var/www/xcat.org/files"
|
||||
|
||||
#use flock to only one person build at the same time
|
||||
# Get a lock, so can not do 2 builds at once
|
||||
exec 8>/var/lock/xcatbld.lock
|
||||
@ -218,7 +203,7 @@ then
|
||||
pkg_type="snap"
|
||||
build_string="Snap_Build"
|
||||
cur_date=`date +%Y%m%d%H%M`
|
||||
pkg_version="${short_ver}-${pkg_type}${cur_date}"
|
||||
pkg_version="${ver}-${pkg_type}${cur_date}"
|
||||
|
||||
if [ ! -d ../../$package_dir_name ];then
|
||||
mkdir -p "../../$package_dir_name"
|
||||
@ -248,9 +233,10 @@ then
|
||||
#3 symbolic link can't work during package
|
||||
if [ $file_low = "xcat-probe" ]; then
|
||||
CURDIR=$(pwd)
|
||||
mkdir -p ${CURDIR}/xCAT-probe/lib/perl/xCAT/
|
||||
cp -f ${CURDIR}/perl-xCAT/xCAT/NetworkUtils.pm ${CURDIR}/xCAT-probe/lib/perl/xCAT/
|
||||
cp -f ${CURDIR}/perl-xCAT/xCAT/GlobalDef.pm ${CURDIR}/xCAT-probe/lib/perl/xCAT/
|
||||
mkdir -p ${CURDIR}/lib/perl/xCAT/
|
||||
cp -f ${CURDIR}/../perl-xCAT/xCAT/NetworkUtils.pm ${CURDIR}/lib/perl/xCAT/
|
||||
cp -f ${CURDIR}/../perl-xCAT/xCAT/GlobalDef.pm ${CURDIR}/lib/perl/xCAT/
|
||||
cp -f ${CURDIR}/../perl-xCAT/xCAT/ServiceNodeUtils.pm ${CURDIR}/lib/perl/xCAT/
|
||||
fi
|
||||
dpkg-buildpackage -uc -us
|
||||
else
|
||||
@ -365,7 +351,6 @@ __EOF__
|
||||
chmod 775 mklocalrepo.sh
|
||||
|
||||
#create the xcat-core.list file
|
||||
#echo "deb ${sf_repo_url}/${REL}/${upload_dir}/ precise main" > xcat-core.list
|
||||
|
||||
cd ../
|
||||
if ! grep xcat /etc/group ; then
|
||||
@ -384,26 +369,8 @@ __EOF__
|
||||
ln -s xcat-core core-snap
|
||||
fi
|
||||
|
||||
# Decide whether to upload or not (default NOT to upload)
|
||||
if [ "$UP" != "1" ]; then
|
||||
echo "Upload not specified, Done! (rerun with UP=1, to upload)"
|
||||
cd $old_pwd
|
||||
exit 0
|
||||
fi
|
||||
|
||||
#upload the deb packages
|
||||
i=0
|
||||
echo "Uploading RPMs from $upload_dir to ${APT_REPO_DIR}/${REL}/ ..."
|
||||
while [ $((i+=1)) -le 5 ] && ! rsync -urLv --delete $upload_dir $USER@${SERVER}:${APT_REPO_DIR}/${REL}/
|
||||
do : ; done
|
||||
|
||||
#upload the tar ball
|
||||
i=0
|
||||
echo "Uploading $tar_name to ${APT_DIR}/xcat-core/${REL}/Ubuntu/core-snap/ ..."
|
||||
while [ $((i+=1)) -le 5 ] && ! rsync -v --force $tar_name $USER@${SERVER}:${APT_DIR}/xcat-core/${REL}/Ubuntu/core-snap/
|
||||
do : ; done
|
||||
|
||||
cd $old_pwd
|
||||
cd $old_pwd
|
||||
exit 0
|
||||
fi
|
||||
|
||||
if [ "$d_flag" ]
|
||||
@ -493,8 +460,6 @@ __EOF__
|
||||
|
||||
chmod 775 mklocalrepo.sh
|
||||
|
||||
#echo ""deb ${sf_repo_url}/xcat-dep/ precise main"" > xcat-dep.list
|
||||
|
||||
cd ..
|
||||
if ! grep xcat /etc/group ; then
|
||||
groupadd xcat
|
||||
@ -509,32 +474,7 @@ __EOF__
|
||||
chgrp root $dep_tar_name
|
||||
chmod g+w $dep_tar_name
|
||||
|
||||
# Decide whether to upload or not (default NOT to upload)
|
||||
if [ "$UP" != "1" ]; then
|
||||
echo "Upload not specified, Done! (rerun with UP=1, to upload)"
|
||||
cd $old_pwd
|
||||
exit 0
|
||||
fi
|
||||
|
||||
#upload the dep packages
|
||||
i=0
|
||||
echo "Uploading debs from xcat-dep to ${APT_REPO_DIR}/xcat-dep/ ..."
|
||||
while [ $((i+=1)) -le 5 ] && ! rsync -urLv --delete xcat-dep $USER@${SERVER}:${APT_REPO_DIR}/
|
||||
do : ; done
|
||||
|
||||
#upload the tarball
|
||||
i=0
|
||||
echo "Uploading $dep_tar_name to ${APT_DIR}/xcat-dep/2.x_Ubuntu/ ..."
|
||||
while [ $((i+=1)) -le 5 ] && ! rsync -v --force $dep_tar_name $USER@${SERVER}:${APT_DIR}/xcat-dep/2.x_Ubuntu/
|
||||
do : ; done
|
||||
|
||||
#upload the README file
|
||||
cd debs
|
||||
i=0
|
||||
echo "Uploading README to ${APT_DIR}/xcat-dep/2.x_Ubuntu/ ..."
|
||||
while [ $((i+=1)) -le 5 ] && ! rsync -v --force README $USER@${SERVER}:${APT_DIR}/xcat-dep/2.x_Ubuntu/
|
||||
do : ; done
|
||||
|
||||
cd $old_pwd
|
||||
exit 0
|
||||
fi
|
||||
exit 0
|
||||
|
||||
20
buildcore.sh
20
buildcore.sh
@ -67,14 +67,14 @@ if [ -z "$UP" ]; then
|
||||
fi
|
||||
|
||||
# These are the rpms that should be built for each kind of xcat build
|
||||
ALLBUILD="perl-xCAT xCAT-client xCAT-server xCAT-test xCAT-buildkit xCAT xCATsn xCAT-genesis-scripts xCAT-SoftLayer xCAT-vlan xCAT-confluent xCAT-probe"
|
||||
ALLBUILD="perl-xCAT xCAT-client xCAT-server xCAT-test xCAT-buildkit xCAT xCATsn xCAT-genesis-scripts xCAT-SoftLayer xCAT-vlan xCAT-confluent xCAT-probe xCAT-csm"
|
||||
ZVMBUILD="perl-xCAT xCAT-server xCAT-UI"
|
||||
ZVMLINK="xCAT-client xCAT xCATsn"
|
||||
# xCAT and xCATsn have PCM specific configuration - conserver-xcat, syslinux-xcat
|
||||
# xCAT-server has PCM specific configuration - RESTAPI(perl-JSON)
|
||||
# xCAT-client has PCM specific configuration - getxcatdocs(perl-JSON)
|
||||
PCMBUILD="xCAT xCAT-server xCAT-client xCATsn"
|
||||
PCMLINK="perl-xCAT xCAT-buildkit xCAT-genesis-scripts-x86_64 xCAT-genesis-scripts-ppc64 xCAT-vlan"
|
||||
PCMLINK="perl-xCAT xCAT-buildkit xCAT-genesis-scripts-x86_64 xCAT-genesis-scripts-ppc64 xCAT-vlan xCAT-probe"
|
||||
# Note: for FSM, the FlexCAT rpm is built separately from gsa/git
|
||||
FSMBUILD="perl-xCAT xCAT-client xCAT-server"
|
||||
FSMLINK=""
|
||||
@ -172,9 +172,17 @@ else
|
||||
fi
|
||||
|
||||
function setversionvars {
|
||||
VER=`cat Version`
|
||||
SHORTVER=`cat Version|cut -d. -f 1,2`
|
||||
SHORTSHORTVER=`cat Version|cut -d. -f 1`
|
||||
if [ ! -z "$USEGITVER" ]; then
|
||||
VER=`git describe`
|
||||
VER=${VER/-/.post}
|
||||
VER=${VER/-/.}
|
||||
else
|
||||
VER=`cat Version`
|
||||
fi
|
||||
XCATVER=$VER
|
||||
export XCATVER
|
||||
SHORTVER=`echo $VER|cut -d. -f 1,2`
|
||||
SHORTSHORTVER=`echo $VER|cut -d. -f 1`
|
||||
BUILD_TIME=`date`
|
||||
BUILD_MACHINE=`hostname`
|
||||
COMMIT_ID=`git rev-parse --short HEAD`
|
||||
@ -291,7 +299,7 @@ if [ "$OSNAME" = "AIX" ]; then
|
||||
fi
|
||||
|
||||
# Build the rest of the noarch rpms
|
||||
for rpmname in xCAT-client xCAT-server xCAT-IBMhpc xCAT-rmc xCAT-UI xCAT-test xCAT-buildkit xCAT-SoftLayer xCAT-vlan xCAT-confluent xCAT-probe; do
|
||||
for rpmname in xCAT-client xCAT-server xCAT-IBMhpc xCAT-rmc xCAT-UI xCAT-test xCAT-buildkit xCAT-SoftLayer xCAT-vlan xCAT-confluent xCAT-probe xCAT-csm; do
|
||||
if [[ " $EMBEDBUILD " != *\ $rpmname\ * ]]; then continue; fi
|
||||
if [ "$OSNAME" = "AIX" -a "$rpmname" = "xCAT-buildkit" ]; then continue; fi # do not build xCAT-buildkit on aix
|
||||
if [ "$OSNAME" = "AIX" -a "$rpmname" = "xCAT-SoftLayer" ]; then continue; fi # do not build xCAT-softlayer on aix
|
||||
|
||||
@ -7,7 +7,7 @@ The chain table (``tabdump chain``) is an xCAT database table that holds the cha
|
||||
* currchain
|
||||
* chain
|
||||
|
||||
To know how are those three attributes used, pls reference the picture:
|
||||
To know how are those three attributes used, reference the picture:
|
||||
|
||||
.. image:: chain_tasks_logic.png
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@ The ``image.tgz`` **must** have the following properties:
|
||||
* Created using the ``tar zcvf`` command
|
||||
* The tarball must include a ``runme.sh`` script to initiate the execution of the runimage
|
||||
|
||||
To create your own image, please reference :ref:`creating image for runimage <create_image_for_runimage>`.
|
||||
To create your own image, reference :ref:`creating image for runimage <create_image_for_runimage>`.
|
||||
|
||||
**Tip**: You could try to run ``wget http://<IP of xCAT Management Node>/<dir>/image.tgz`` manually to make sure the path has been set correctly.
|
||||
|
||||
|
||||
@ -36,11 +36,11 @@ Database Connection Changes
|
||||
|
||||
Granting or revoking access privilege in the database for the service node.
|
||||
|
||||
* For mysql, please refer to :ref:`grante_revoke_mysql_access_label`.
|
||||
* For mysql, refer to :ref:`grante_revoke_mysql_access_label`.
|
||||
.. There is no procedure in old document on sourceforge for postgress to
|
||||
grant or revoke the access privilege for service node.
|
||||
|
||||
* For postgress, please refer to `TODO <https://localhost/todo>`_.
|
||||
* For postgress, refer to `TODO <https://localhost/todo>`_.
|
||||
|
||||
Update Provision Environment on Service Node
|
||||
--------------------------------------------
|
||||
|
||||
@ -56,8 +56,7 @@ The following example describes the steps for **rhels7.1** on **ppc64le**::
|
||||
cd confluent-dep-rh7-ppc64le/
|
||||
./mklocalrepo.sh
|
||||
|
||||
**Note:** If the OS/architecture you are looking for is not provided under confluent-dep,
|
||||
please send an email to the xcat-user mailing list: xcat-user@lists.sourceforge.net
|
||||
**Note:** If the OS/architecture you are looking for is not provided under confluent-dep, send an email to the xcat-user mailing list: xcat-user@lists.sourceforge.net
|
||||
|
||||
|
||||
Install
|
||||
|
||||
@ -5,7 +5,7 @@ Docker Registry is a stateless, highly scalable server side application that sto
|
||||
|
||||
This document describes how to set up a local private docker registry on Ubuntu 15.04 on x86_64.
|
||||
|
||||
**Note:** Please ensure that docker registry is not already set up on this docker host.
|
||||
**Note:** Ensure that docker registry is not already set up on this docker host.
|
||||
|
||||
Setting Up Docker Host
|
||||
----------------------
|
||||
@ -17,7 +17,7 @@ Setting Up Docker Registry Manually
|
||||
|
||||
Docker registry needed to be set up on xCAT's MN.
|
||||
|
||||
This section describes two methods of setting up docker registry manullay.
|
||||
This section describes two methods of setting up docker registry manually.
|
||||
|
||||
First, create some folders where files for this tutorial will live. ::
|
||||
|
||||
|
||||
@ -24,7 +24,7 @@ By pulling xCAT Docker image and running xCAT Docker image in a container, you g
|
||||
xCAT Docker images
|
||||
------------------
|
||||
|
||||
xCAT shippes 2 Docker images for Docker host with different architecture:
|
||||
xCAT ships 2 Docker images for Docker host with different architecture:
|
||||
|
||||
* "xcat/xcat-ubuntu-x86_64": run on x86_64 Docker host
|
||||
* "xcat/xcat-ubuntu-ppc64le": run on ppc64le Docker host
|
||||
@ -81,12 +81,12 @@ Once you attach or ssh to the container, you will find that xCAT is running and
|
||||
|
||||
Currently, since xCAT can only generate the diskless osimages of Linux distributions with the same OS version and architecture with xCAT MN. If you need to provision diskless osimages besides ubuntu x86_64 with xCAT running in the Docker, you can use ``imgexport`` and ``imgimport`` to import the diskless osimages generated before.
|
||||
|
||||
If you start up the xCAT Docker container by following the steps described in sections above strictly, without specifying "--dns=IP_ADDRESS...", "--dns-search=DOMAIN...", or "--dns-opt=OPTION..." options, Docker uses the /etc/resolv.conf of the host machine (where the docker daemon runs). Any DNS problem inside container, please make sure the DNS server on the Docker host works well.
|
||||
If you start up the xCAT Docker container by following the steps described in sections above strictly, without specifying "--dns=IP_ADDRESS...", "--dns-search=DOMAIN...", or "--dns-opt=OPTION..." options, Docker uses the /etc/resolv.conf of the host machine (where the docker daemon runs). Any DNS problem inside container, make sure the DNS server on the Docker host works well.
|
||||
|
||||
Save and Restore xCAT data
|
||||
----------------------------
|
||||
|
||||
According to the policy of Docker, Docker image should only be the service deployment unit, it is not recommended to save data in Docker image. Docker uses "Data Volume" to save persisent data inside container, which can be simply taken as a shared directory between Docker host and Docker container.
|
||||
According to the policy of Docker, Docker image should only be the service deployment unit, it is not recommended to save data in Docker image. Docker uses "Data Volume" to save persistent data inside container, which can be simply taken as a shared directory between Docker host and Docker container.
|
||||
|
||||
For dockerized xCAT, there are 3 volumes recommended to save and restore xCAT user data.
|
||||
|
||||
|
||||
@ -69,7 +69,7 @@ Now run the xCAT Docker container with the Docker image "xcat/xcat-ubuntu-x86_64
|
||||
* use ``--privileged=true`` to give extended privileges to this container
|
||||
* use ``--hostname`` to specify the hostname of the container, which is available inside the container
|
||||
* use ``--name`` to assign a name to the container, this name can be used to manipulate the container on Docker host
|
||||
* use ``--add-host="xcatmn.clusers.com xcatmn:10.5.107.101"`` to write the ``/etc/hosts`` entries of Docker container inside container. Since xCAT use the FQDN(Fully Qualified Domain Name) to determine the cluster domain on startup, please make sure the format to be "<FQDN> <hostname>: <IP Address>", otherwise, you need to set the cluster domain with ``chdef -t site -o clustersite domain="clusters.com"`` inside the container manually
|
||||
* use ``--add-host="xcatmn.clusers.com xcatmn:10.5.107.101"`` to write the ``/etc/hosts`` entries of Docker container inside container. Since xCAT use the FQDN(Fully Qualified Domain Name) to determine the cluster domain on startup, make sure the format to be "<FQDN> <hostname>: <IP Address>", otherwise, you need to set the cluster domain with ``chdef -t site -o clustersite domain="clusters.com"`` inside the container manually
|
||||
* use ``--volume /docker/xcatdata/:/install`` to mount a pre-created "/docker/xcatdata" directory on Docker host to "/install" directory inside container as a data volume. This is optional, it is mandatory if you want to backup and restore xCAT data.
|
||||
* use ``--net=mgtnet`` to connect the container to the Docker network "mgtnet"
|
||||
* use ``--ip=10.5.107.101`` to specify the IP address of the xCAT Docker container
|
||||
|
||||
@ -4,7 +4,7 @@ Setup Docker host
|
||||
Install Docker Engine
|
||||
---------------------
|
||||
|
||||
The Docker host to run xCAT Docker image should be a baremental or virtual server with Docker v1.10 or above installed. For the details on system requirements and Docker installation, please refer to `Docker Installation Docs <https://docs.docker.com/engine/installation/>`_.
|
||||
The Docker host to run xCAT Docker image should be a baremental or virtual server with Docker v1.10 or above installed. For the details on system requirements and Docker installation, refer to `Docker Installation Docs <https://docs.docker.com/engine/installation/>`_.
|
||||
|
||||
**Note:**
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ Docker life-cycle management in xCAT
|
||||
|
||||
The Docker linux container technology is currently very popular. xCAT can help managing Docker containers. xCAT, as a system management tool has the natural advantage for supporting multiple operating systems, multiple architectures and large scale clusters.
|
||||
|
||||
This document describes how to use xCAT for docker management, from Docker Host setup to docker container operationis.
|
||||
This document describes how to use xCAT for docker management, from Docker Host setup to docker container operations.
|
||||
|
||||
**Note:** The document was verified with **Docker Version 1.10, 1.11** and **Docker API version 1.22.** The Docker Host was verified on **ubuntu14.04.3 x86_64**, **ubuntu15.10 x86_64**, **ubuntu16.04 x86_64** and **ubuntu16.04 ppc64el**.
|
||||
|
||||
|
||||
@ -101,7 +101,7 @@ You must set the **forwarders** attribute in the xCAT cluster **site** definitio
|
||||
|
||||
An xCAT **network** definition must be defined for each management network used in the cluster. The **net** and **mask** attributes will be used by the ``makedns`` command.
|
||||
|
||||
A network **domain** and **nameservers** value must be provided either in the network definiton corresponding to the nodes or in the site definition.
|
||||
A network **domain** and **nameservers** value must be provided either in the network definition corresponding to the nodes or in the site definition.
|
||||
|
||||
For example, if the cluster domain is **mycluster.com**, the IP address of the management node, (as known by the cluster nodes), is **100.0.0.41** and the site DNS servers are **50.1.2.254,50.1.3.254** then you would run the following command. ::
|
||||
|
||||
@ -249,7 +249,7 @@ To use this support you must set one or more of the following node definition at
|
||||
The additional NIC information may be set by directly editing the xCAT **nics** table or by using the **xCAT *defs** commands to modify the node definitions.
|
||||
|
||||
The details for how to add the additional information is described below. As you will see, entering this
|
||||
information manually can be tedious and error prone. This support is primarily targetted to be used in
|
||||
information manually can be tedious and error prone. This support is primarily targeted to be used in
|
||||
conjunction with other IBM products that have tools to fill in this information in an automated way.
|
||||
|
||||
Managing additional interface information using the **xCAT *defs** commands
|
||||
@ -269,7 +269,7 @@ For example, the expanded format for the **nicips** and **nichostnamesuffixes**
|
||||
nicips.eth1=10.1.1.6
|
||||
nichostnamesuffixes.eth1=-eth1
|
||||
|
||||
If we assume that your xCAT node name is **compute02** then this would mean that you have an additonal interface **("eth1")** and that the hostname and IP address are **compute02-eth1** and **10.1.1.6**.
|
||||
If we assume that your xCAT node name is **compute02** then this would mean that you have an additional interface **("eth1")** and that the hostname and IP address are **compute02-eth1** and **10.1.1.6**.
|
||||
|
||||
A "|" delimiter is used to specify multiple values for an interface. For example: ::
|
||||
|
||||
@ -285,7 +285,7 @@ For the **nicaliases** attribute a list of additional aliases may be provided. :
|
||||
|
||||
This indicates that the **compute02-eth1** hostname would get the additional two aliases, alias1 alias2, included in the **/etc/hosts** file, (when using the ``makehosts`` command).
|
||||
|
||||
The second line indicates that **compute02-eth2** would get the additonal alias **alias3** and that **compute02-eth-lab** would get **alias4**
|
||||
The second line indicates that **compute02-eth2** would get the additional alias **alias3** and that **compute02-eth-lab** would get **alias4**
|
||||
|
||||
Setting individual nic attribute values
|
||||
'''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
@ -13,15 +13,15 @@ The data synchronization is important for any high availability configuration. W
|
||||
* The configuration files for the services that are required by xCAT, like named, DHCP, apache, nfs, ssh, etc.
|
||||
* The operating systems images repository and users customization data repository, the ``/install`` directory contains these repositories in most cases.
|
||||
|
||||
There are a lot of ways for data syncronization, but considering the specific xCAT HAMN requirements, only several of the data syncronziation options are practical for xCAT HAMN.
|
||||
There are a lot of ways for data synchronization, but considering the specific xCAT HAMN requirements, only several of the data synchronziation options are practical for xCAT HAMN.
|
||||
|
||||
**1\. Move physical disks between the two management nodes**: if we could physically move the hard disks from the failed management node to the backup management node, and bring up the backup management node, then both the operating system and xCAT data will be identical between the new management node and the failed management node. RAID1 or disk mirroring could be used to avoid the disk be a single point of failure.
|
||||
|
||||
**2\. Shared data**: the two management nodes use the single copy of xCAT data, no matter which management node is the primary MN, the cluster management capability is running on top of the single data copy. The access to the data could be done through various ways like shared storage, NAS, NFS, samba etc. Based on the protocol being used, the data might be accessable only on one management node at a time or be accessable on both management nodes in parellel. If the data could only be accessed from one management node, the failover process need to take care of the data access transition; if the data could be accessed on both management nodes, the failover does not need to consider the data access transition, it usually means the failover process could be faster.
|
||||
**2\. Shared data**: the two management nodes use the single copy of xCAT data, no matter which management node is the primary MN, the cluster management capability is running on top of the single data copy. The access to the data could be done through various ways like shared storage, NAS, NFS, samba etc. Based on the protocol being used, the data might be accessible only on one management node at a time or be accessible on both management nodes in parallel. If the data could only be accessed from one management node, the failover process need to take care of the data access transition; if the data could be accessed on both management nodes, the failover does not need to consider the data access transition, it usually means the failover process could be faster.
|
||||
|
||||
Warning: Running database through network file system has a lot of potential problems and is not practical, however, most of the database system provides database replication feature that can be used to synronize the database between the two management nodes.
|
||||
Warning: Running database through network file system has a lot of potential problems and is not practical, however, most of the database system provides database replication feature that can be used to synchronize the database between the two management nodes.
|
||||
|
||||
**3\. Mirroring**: each of the management node has its own copy of the xCAT data, and the two copies of data are syncronized through mirroring mechanism. DRBD is used widely in the high availability configuration scenarios, to provide data replication by mirroring a whole block device via network. If we put all the important data for xCAT onto the DRBD devices, then it could assure the data is synchronized between the two management nodes. Some parallel file system also provides capability to mirror data through network.
|
||||
**3\. Mirroring**: each of the management node has its own copy of the xCAT data, and the two copies of data are synchronized through mirroring mechanism. DRBD is used widely in the high availability configuration scenarios, to provide data replication by mirroring a whole block device via network. If we put all the important data for xCAT onto the DRBD devices, then it could assure the data is synchronized between the two management nodes. Some parallel file system also provides capability to mirror data through network.
|
||||
|
||||
Manual vs. Automatic Failover
|
||||
-----------------------------
|
||||
@ -36,7 +36,7 @@ From xCAT perspective, if the management node needs to provide network services
|
||||
|
||||
**2\. Configuration complexity**
|
||||
|
||||
The configuration for the high availability applications is usually complex, it may take a long time to configure, debug and stablize the high availability configuration.
|
||||
The configuration for the high availability applications is usually complex, it may take a long time to configure, debug and stabilize the high availability configuration.
|
||||
|
||||
**3\. Maintenance effort**
|
||||
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
High Avaiability
|
||||
================
|
||||
High Availability
|
||||
=================
|
||||
|
||||
The xCAT management node plays an important role in the cluster, if the management node is down for whatever reason, the administrators will lose the management capability for the whole cluster, until the management node is back up and running. In some configuration, like the Linux nfs-based statelite in a non-hierarchy cluster, the compute nodes may not be able to run at all without the management node. So, it is important to consider the high availability for the management node.
|
||||
The xCAT management node plays an important role in the cluster, if the management node is down for whatever reason, the administrators will lose the management capability for the whole cluster, until the management node is back up and running. In some configurations, like the Linux NFSROOT-based statelite in a non-hierarchy cluster, the compute nodes may not be able to run at all without the management node. So, it is important to consider the high availability for the management node.
|
||||
|
||||
The goal of the HAMN(High Availability Management Node) configuration is, when the primary xCAT management node fails, the standby management node can take over the role of the management node, either through automatic failover or through manual procedure performed by the administrator, and thus avoid long periods of time during which your cluster does not have active cluster management function available.
|
||||
The goal of the HAMN (High Availability Management Node) configuration is, when the primary xCAT management node fails, the standby management node can take over the role of the management node, either through automatic failover or through manual procedure performed by the administrator, and thus avoid long periods of time during which your cluster does not have active cluster management function available.
|
||||
|
||||
|
||||
The following pages describes ways to configure the xCAT Management Node for High Availbility.
|
||||
The following pages describes ways to configure the xCAT Management Node for High Availability.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
@ -149,7 +149,7 @@ So, in this documentation, we will setup xCAT on both management nodes before we
|
||||
chdef -t site nameservers=10.1.0.1
|
||||
chdef -t network 10_1_0_0-255_255_255_0 tftpserver=10.1.0.1
|
||||
|
||||
#. Install and configure MySQL. MySQL will be used as the xCAT database system, please refer to the doc [ **todo** Setting_Up_MySQL_as_the_xCAT_DB].
|
||||
#. Install and configure MySQL. MySQL will be used as the xCAT database system, refer to the doc [ **todo** Setting_Up_MySQL_as_the_xCAT_DB].
|
||||
|
||||
Verify xcat is running on MySQL by running: ::
|
||||
|
||||
@ -219,7 +219,7 @@ Setup xCAT on the Standby Management Node
|
||||
|
||||
#. Install xCAT. The procedure described in :doc:`xCAT Install Guide <../../guides/install-guides/index>` should be used for the xCAT setup on the standby management node.
|
||||
|
||||
#. Install and configure MySQL. MySQL will be used as the xCAT database system, please refer to the doc [Setting_Up_MySQL_as_the_xCAT_DB].
|
||||
#. Install and configure MySQL. MySQL will be used as the xCAT database system, refer to the doc [Setting_Up_MySQL_as_the_xCAT_DB].
|
||||
|
||||
Verify xcat is running on MySQL by running: ::
|
||||
|
||||
@ -689,7 +689,7 @@ Configure Pacemaker
|
||||
|
||||
All the cluster resources are managed by Pacemaker, here is an example ``pacemaker`` configuration that has been used by different HA MN customers. You might need to do some minor modifications based on your cluster configuration.
|
||||
|
||||
Please be aware that you need to apply ALL the configuration at once. You cannot pick and choose which pieces to put in, and you cannot put some in now, and some later. Don't execute individual commands, but use crm configure edit instead. ::
|
||||
Be aware that you need to apply ALL the configuration at once. You cannot pick and choose which pieces to put in, and you cannot put some in now, and some later. Don't execute individual commands, but use crm configure edit instead. ::
|
||||
|
||||
node x3550m4n01
|
||||
node x3550m4n02
|
||||
@ -1043,7 +1043,7 @@ Add a crontab entry to check the differences
|
||||
|
||||
0 6 * * * /sbin/drbdadm verify all
|
||||
|
||||
Please note that this process will take a few hours. You could schedule it at a time when it can be expected to run when things are relatively idle. You might choose to only run it once a week, but nightly seems to be a nice choice as well. You should only put this cron job on one side or the other of the DRBD mirror . not both.
|
||||
Note that this process will take a few hours. You could schedule it at a time when it can be expected to run when things are relatively idle. You might choose to only run it once a week, but nightly seems to be a nice choice as well. You should only put this cron job on one side or the other of the DRBD mirror . not both.
|
||||
|
||||
Correcting the differences automatically
|
||||
----------------------------------------
|
||||
|
||||
@ -408,7 +408,7 @@ The operating system is installed on the internal disks.
|
||||
|
||||
#. Connect the shared disk to both management nodes
|
||||
|
||||
To verify the shared disks are connected correctly, run the sginfo command on both management nodes and look for the same serial number in the output. Please be aware that the sginfo command may not be installed by default on Linux, the sginfo command is shipped with package sg3_utils, you can manually install the package sg3_utils on both management nodes.
|
||||
To verify the shared disks are connected correctly, run the sginfo command on both management nodes and look for the same serial number in the output. Be aware that the sginfo command may not be installed by default on Linux, the sginfo command is shipped with package sg3_utils, you can manually install the package sg3_utils on both management nodes.
|
||||
|
||||
Once the sginfo command is installed, run sginfo -l command on both management nodes to list all the known SCSI disks, for example, enter: ::
|
||||
|
||||
|
||||
@ -132,8 +132,8 @@ Execute steps on xCAT MN rhmn1
|
||||
# chdef -t site master=10.2.2.250 nameservers=10.2.2.250
|
||||
# chdef -t network 10_0_0_0-255_0_0_0 tftpserver=10.2.2.250
|
||||
# tabdump networks
|
||||
~]#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,comments,disable
|
||||
"10_0_0_0-255_0_0_0","10.0.0.0","255.0.0.0","eth0","10.2.0.221",,"10.2.2.250",,,,,,,,,,,,
|
||||
~]#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,mtu,comments,disable
|
||||
"10_0_0_0-255_0_0_0","10.0.0.0","255.0.0.0","eth0","10.2.0.221",,"10.2.2.250",,,,,,,,,,,,,
|
||||
|
||||
#. Add 2 nodes into policy table: ::
|
||||
|
||||
@ -329,7 +329,7 @@ Install corosync and pacemaker on both rhmn2 and rhmn1
|
||||
Customize corosync/pacemaker configuration for xCAT
|
||||
------------------------------------------------------
|
||||
|
||||
Please be aware that you need to apply ALL the configuration at once. You cannot pick and choose which pieces to put in, and you cannot put some in now, and some later. Don't execute individual commands, but use crm configure edit instead.
|
||||
Be aware that you need to apply ALL the configuration at once. You cannot pick and choose which pieces to put in, and you cannot put some in now, and some later. Don't execute individual commands, but use crm configure edit instead.
|
||||
|
||||
Check that both rhmn2 and chetha are standby state now: ::
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ Appendix B: Diagnostics
|
||||
* **otherpkgs(including xCAT rpms) installation failed on the SN** --The OS
|
||||
repository is not created on the SN. When the "yum" command is processing
|
||||
the dependency, the rpm packages (including expect, nmap, and httpd, etc)
|
||||
required by xCATsn can't be found. In this case, please check whether the
|
||||
required by xCATsn can't be found. In this case, check whether the
|
||||
``/install/postscripts/repos/<osver>/<arch>/`` directory exists on the MN.
|
||||
If it is not on the MN, you need to re-run the "copycds" command, and there
|
||||
will be some file created under the
|
||||
|
||||
@ -12,7 +12,7 @@ If you no longer want to use MySQL/MariaDB to maintain ``xcatdb``, and like to s
|
||||
|
||||
XCATBYPASS=1 restorexCATdb -p ~/xcat-dbback
|
||||
|
||||
* Change to PostgreSQL, please following documentation: :doc:`/advanced/hierarchy/databases/postgres_install`
|
||||
* Change to PostgreSQL, following documentation: :doc:`/advanced/hierarchy/databases/postgres_install`
|
||||
|
||||
|
||||
* Change back to default xCAT database, SQLite (**Note**: xCAT Hierarchy cluster will no longer work)
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Diskless (Stateless) Installation
|
||||
=================================
|
||||
|
||||
**Note: The stateless Service Node is not supported in ubuntu hierarchy cluster. For ubuntu, please skip this section.**
|
||||
**Note: The stateless Service Node is not supported in ubuntu hierarchy cluster. For ubuntu, skip this section.**
|
||||
|
||||
If you want, your Service Nodes can be stateless (diskless). The Service Node
|
||||
must contain not only the OS, but also the xCAT software and its dependencies.
|
||||
|
||||
@ -16,6 +16,7 @@ Advanced Topics
|
||||
mixed_cluster/index.rst
|
||||
networks/index.rst
|
||||
ports/xcat_ports.rst
|
||||
probe/index.rst
|
||||
raid/index.rst
|
||||
restapi/index.rst
|
||||
security/index.rst
|
||||
|
||||
@ -63,4 +63,4 @@ If the kit does contain a deployment parameter file, the contents of the file wi
|
||||
addkitcomp -i <image> <kitcomponent name>
|
||||
vi /install/osimages/<image>/kits/KIT_DEPLOY_PARAMS.otherpkgs.pkglist
|
||||
|
||||
NOTE: Please be sure to know how changing any kit deployment parameters will impact the install of the product into the OS image. Many parameters include settings for automatic license acceptance and other controls to ensure proper unattended installs into a diskless image or remote installs into a diskful node. Changing these values will cause problems with genimage, updatenode, and other xCAT deployment commands.
|
||||
NOTE: Be sure to know how changing any kit deployment parameters will impact the install of the product into the OS image. Many parameters include settings for automatic license acceptance and other controls to ensure proper unattended installs into a diskless image or remote installs into a diskful node. Changing these values will cause problems with genimage, updatenode, and other xCAT deployment commands.
|
||||
|
||||
@ -101,7 +101,7 @@ The following software kits will be used to install the IBM HPC software stack o
|
||||
addkitcomp -a -i rhels7.2-ppc64le-install-compute \
|
||||
essl-computenode-3264rtecuda-5.4.0-0-rhels-7.2-ppc64le
|
||||
|
||||
If the system doesn't have GPU and the CUDA toolkit is not needed, the adminstrator should not add the following kit components that requires the CUDA packages: ``essl-loginnode-5.4.0-0-rhels-7.2-ppc64le``, ``essl-computenode-3264rte-5.4.0-0-rhels-7.2-ppc64le`` and ``essl-computenode-3264rtecuda-5.4.0-0-rhels-7.2-ppc64le``. Please check the ESSL installation guide: http://www.ibm.com/support/knowledgecenter/SSFHY8_5.4.0/com.ibm.cluster.essl.v5r4.essl300.doc/am5il_xcatinstall.htm
|
||||
If the system doesn't have GPU and the CUDA toolkit is not needed, the adminstrator should not add the following kit components that requires the CUDA packages: ``essl-loginnode-5.4.0-0-rhels-7.2-ppc64le``, ``essl-computenode-3264rte-5.4.0-0-rhels-7.2-ppc64le`` and ``essl-computenode-3264rtecuda-5.4.0-0-rhels-7.2-ppc64le``. Check the ESSL installation guide: http://www.ibm.com/support/knowledgecenter/SSFHY8_5.4.0/com.ibm.cluster.essl.v5r4.essl300.doc/am5il_xcatinstall.htm
|
||||
|
||||
#. Add the **Parallel ESSL** kitcomponents to osimage.
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ xCAT supports a unique software bundling concept called **software kits**. Soft
|
||||
|
||||
Prebuilt software kits are available as a tar file which can be downloaded and then added to the xCAT installation. After the kits are added to xCAT, kit components are then added to specific xCAT osimages to automatically install the software bundled with the kit during OS deployment. In some instances, software kits may be provided as partial kits. Partial kits need additional effort to complete the kit before it can be used by xCAT.
|
||||
|
||||
Software kits are supported for both diskful and diskless image provisionig.
|
||||
Software kits are supported for both diskful and diskless image provisioning.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
@ -5,9 +5,9 @@ A **stateless**, or **diskless**, provisioned nodes is one where the operating s
|
||||
|
||||
To deploy stateless compute nodes, you must first create a stateless image. The "netboot" osimages created from ``copycds`` in the **osimage** table are sample osimage definitions that can be used for deploying stateless nodes.
|
||||
|
||||
In a homogenous cluster, the management node is the same hardware architecture and running the same Operating System (OS) as the compute nodes, so ``genimage`` can directly be executed from the management node.
|
||||
In a homogeneous cluster, the management node is the same hardware architecture and running the same Operating System (OS) as the compute nodes, so ``genimage`` can directly be executed from the management node.
|
||||
|
||||
The issues arises in a heterogenous cluster, where the management node is running a different level operating system *or* hardware architecture as the compute nodes in which to deploy the image. The ``genimage`` command that builds stateless images depends on various utilities provided by the base operating system and needs to be run on a node with the same hardware architecture and *major* Operating System release as the nodes that will be booted from the image.
|
||||
The issues arises in a heterogeneous cluster, where the management node is running a different level operating system *or* hardware architecture as the compute nodes in which to deploy the image. The ``genimage`` command that builds stateless images depends on various utilities provided by the base operating system and needs to be run on a node with the same hardware architecture and *major* Operating System release as the nodes that will be booted from the image.
|
||||
|
||||
Same Operating System, Different Architecture
|
||||
---------------------------------------------
|
||||
@ -27,7 +27,7 @@ The following describes creating stateless images of the same Operating System,
|
||||
|
||||
lsdef -t osimage -z rhels6.3-x86_64-netboot-compute | sed 's/^[^ ]\+:/mycomputeimage:/' | mkdef -z
|
||||
|
||||
#. To obtain the ``genimage`` command to execte on ``n01``, execute the ``genimage`` command with the ``--dryrun`` option: ::
|
||||
#. To obtain the ``genimage`` command to execute on ``n01``, execute the ``genimage`` command with the ``--dryrun`` option: ::
|
||||
|
||||
genimage --dryrun mycomputeimage
|
||||
|
||||
|
||||
@ -26,7 +26,6 @@ Create a node definition for the x86_64 compute node, here is a sample: ::
|
||||
bmc=10.4.42.254
|
||||
bmcpassword=PASSW0RD
|
||||
bmcusername=USERID
|
||||
chain=runcmd=bmcsetup,shell
|
||||
cons=ipmi
|
||||
groups=all
|
||||
initrd=xcat/osimage/rhels6.6-x86_64-install-compute/initrd.img
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Configure Ethernet Switches
|
||||
---------------------------
|
||||
|
||||
It is recommended that spanning tree be set in the switches to portfast or edge-port for faster boot performance. Please see the relevant switch documentation as to how to configure this item.
|
||||
It is recommended that spanning tree be set in the switches to portfast or edge-port for faster boot performance. See the relevant switch documentation as to how to configure this item.
|
||||
|
||||
It is recommended that lldp protocol in the switches is enabled to collect the switch and port information for compute node during discovery process.
|
||||
|
||||
@ -71,9 +71,9 @@ Running Remote Commands in Parallel
|
||||
|
||||
You can use xdsh to run parallel commands on Ethernet switches. The following shows how to configure xCAT to run xdsh on the switches:
|
||||
|
||||
**[Note]**:Configure the switch to allow **ssh** or **telnet**. This varies for switch to switch. Please refer to the switch command references to find out how to do it.
|
||||
**[Note]**:Configure the switch to allow **ssh** or **telnet**. This varies for switch to switch. Refer to the switch command references to find out how to do it.
|
||||
|
||||
Add the switch in xCAT DB. Please refer to the "Discovering Switches" section if you want xCAT to discover and define the switches for you. ::
|
||||
Add the switch in xCAT DB. Refer to the "Discovering Switches" section if you want xCAT to discover and define the switches for you. ::
|
||||
|
||||
mkdef bntc125 groups=switch mgt=switch ip=10.4.25.1 nodetype=switch switchtype=BNT
|
||||
|
||||
@ -97,9 +97,9 @@ Set the ssh or telnet username an d password. ::
|
||||
|
||||
xdsh bntc125 --devicetype EthSwitch::BNT "enable;configure terminal;vlan 3;end;show vlan"
|
||||
|
||||
Please note that you can run multiple switch commands, they are separated by comma.
|
||||
Note that you can run multiple switch commands, they are separated by comma.
|
||||
|
||||
Please also note that --devicetype is used here. xCAT supports the following switch types out of the box: ::
|
||||
Also note that --devicetype is used here. xCAT supports the following switch types out of the box: ::
|
||||
|
||||
* BNT
|
||||
* Cisco
|
||||
@ -178,7 +178,7 @@ The new configuration file will look like this: ::
|
||||
|
||||
For **BNT** switches, the **command-to-set-term-length-to-0** is **terminal-length 0**.
|
||||
|
||||
Please make sure to add a semi-colon at the end of the "pre-command" line.
|
||||
Make sure to add a semi-colon at the end of the "pre-command" line.
|
||||
|
||||
Then you can run the xdsh like this: ::
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ Networks
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
switchdiscover/index.rst
|
||||
ethernet_switches/index.rst
|
||||
switchdiscover/index.rst
|
||||
infiniband/index.rst
|
||||
ipv6/index.rst
|
||||
|
||||
@ -1,11 +0,0 @@
|
||||
IB Driver Preparation and Installation
|
||||
======================================
|
||||
|
||||
xCAT provides sample postscripts to help you install the Mellanox OpenFabrics Enterprise Distribution (OFED) InfiniBand Driver. These scripts are located in ``opt/xcat/share/xcat/ib/scripts/Mellanox/``. You can use these scripts directly or change them to satisfy your own environment. **xCAT 2.11 drops support of mlnxofed_ib_install and recommends using version 2 of the script: mlnxofed_ib_install.v2**.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
mlnxofed_ib_install_v2_usage.rst
|
||||
mlnxofed_ib_install_v1_usage.rst
|
||||
|
||||
@ -5,7 +5,7 @@ Firmware Updates
|
||||
Adapter Firmware Update
|
||||
-----------------------
|
||||
|
||||
Please download the OFED IB adapter firmware from the Mellanox site `http://www.mellanox.com/page/firmware_table_IBM <http://www.mellanox.com/page/firmware_table_IBM>`_ .
|
||||
Download the OFED IB adapter firmware from the Mellanox site `http://www.mellanox.com/page/firmware_table_IBM <http://www.mellanox.com/page/firmware_table_IBM>`_ .
|
||||
|
||||
Obtain device id: ::
|
||||
|
||||
|
||||
@ -1,13 +1,18 @@
|
||||
InfiniBand (Mellanox)
|
||||
=====================
|
||||
|
||||
xCAT offers a certain degree support for Mellanox InfiniBand product, it help you to configurate Mellanox InfiniBand products easily. For more information about Mellanox InfiniBand, please refer to `Mellanox official site <http://www.mellanox.com/>`_.
|
||||
xCAT has the ability to help with Mellanox InfiniBand (IB) adapter installation and network configuration as part of the node provisioning process.
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
driver_and_installation.rst
|
||||
mlnxofed_ib_install_v2.rst
|
||||
network_configuration.rst
|
||||
switch_configuration.rst
|
||||
ufm_configuration.rst
|
||||
firmware_updates.rst
|
||||
|
||||
|
||||
|
||||
For more information about Mellanox products, refer to http://www.mellanox.com.
|
||||
|
||||
@ -0,0 +1,11 @@
|
||||
Configuration
|
||||
=============
|
||||
|
||||
The process to configure the osimage to install the Mellanox OFED Drivers for Diskful and Diskless scenarios are outlined below.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
mlnxofed_ib_install_v2_diskful.rst
|
||||
mlnxofed_ib_install_v2_diskless.rst
|
||||
|
||||
@ -1,53 +0,0 @@
|
||||
Configuration for Diskful Installation
|
||||
======================================
|
||||
|
||||
1. Set script ``mlnxofed_ib_install`` as postbootscript ::
|
||||
|
||||
chdef <node> -p postbootscripts=mlnxofed_ib_install
|
||||
|
||||
2. Specify dependence package **[required for RHEL and SLES]**
|
||||
|
||||
a) Copy the pkglist to the custom directory ::
|
||||
|
||||
cp /opt/xcat/share/xcat/install/<ostype>/compute.<osver>.<arch>.pkglist \
|
||||
/install/custom/install/<ostype>/compute.<osver>.<arch>.pkglist
|
||||
|
||||
b) Edit your /install/custom/install/<ostype>/compute.<osver>.<arch>.pkglist and add one line::
|
||||
|
||||
#INCLUDE:/opt/xcat/share/xcat/ib/netboot/<ostype>/ib.<osver>.<arch>.pkglist#
|
||||
|
||||
c) Make the related osimage use the customized pkglist ::
|
||||
|
||||
chdef -t osimage -o <osver>-<arch>-install-compute \
|
||||
pkglist=/install/custom/install/<ostype>/compute.<osver>.<arch>.pkglist
|
||||
|
||||
Take RHEL 6.4 on x86_64 for example ::
|
||||
|
||||
cp /opt/xcat/share/xcat/install/rh/compute.rhels6.x86_64.pkglist \
|
||||
/install/custom/install/rh/compute.rhels6.x86_64.pkglist
|
||||
|
||||
Edit the ``/install/custom/install/rh/compute.rhels6.x86_64.pkglist`` and add below line
|
||||
``#INCLUDE:/opt/xcat/share/xcat/ib/netboot/rh/ib.rhels6.x86_64.pkglist#``
|
||||
|
||||
Then ``/install/custom/install/rh/compute.rhels6.x86_64.pkglist`` looks like below ::
|
||||
|
||||
#Please make sure there is a space between @ and group name
|
||||
#INCLUDE:/opt/xcat/share/xcat/ib/netboot/rh/ib.rhels6.x86_64.pkglist#
|
||||
ntp
|
||||
nfs-utils
|
||||
net-snmp
|
||||
rsync
|
||||
yp-tools
|
||||
openssh-server
|
||||
util-linux-ng
|
||||
|
||||
Then modify related osimage ::
|
||||
|
||||
chdef -t osimage -o rhels6.4-x86_64-install-compute \
|
||||
pkglist=/install/custom/install/rh/compute.rhels6.x86_64.pkglist
|
||||
|
||||
3. Install node ::
|
||||
|
||||
nodeset <node> osimage=<osver>-<arch>-install-compute
|
||||
rsetboot <node> net
|
||||
rpower <node> reset
|
||||
@ -1,77 +0,0 @@
|
||||
Configuration for Diskless Installation
|
||||
=======================================
|
||||
|
||||
1. Specify dependence package **[required for RHEL and SLES]**
|
||||
|
||||
a) Copy a correct pkglist file **shipped by xCAT** according your environment to the ``/install/custom/netboot/<ostype>/`` directory ::
|
||||
|
||||
cp /opt/xcat/share/xcat/netboot/<ostype>/compute.<osver>.<arch>.pkglist \
|
||||
/install/custom/netboot/<ostype>/compute.<osver>.<arch>.pkglist
|
||||
|
||||
b) Edit your ``/install/custom/netboot/<ostype>/<profile>.pkglist`` and add one line ``#INCLUDE:/opt/xcat/share/xcat/ib/netboot/<ostype>/ib.<osver>.<arch>.pkglist#``
|
||||
|
||||
Take RHEL 6.4 on x86_64 for example ::
|
||||
|
||||
cp /opt/xcat/share/xcat/netboot/rh/compute.rhels6.x86_64.pkglist \
|
||||
/install/custom/netboot/rh/compute.rhels6.x86_64.pkglist
|
||||
|
||||
Edit the ``/install/custom/netboot/rh/compute.rhels6.x86_64.pkglist`` and add below line
|
||||
``#INCLUDE:/opt/xcat/share/xcat/ib/netboot/rh/ib.rhels6.x86_64.pkglist#``
|
||||
|
||||
Then ``/install/custom/netboot/rh/compute.rhels6.x86_64.pkglist`` looks like below ::
|
||||
|
||||
#INCLUDE:/opt/xcat/share/xcat/ib/netboot/rh/ib.rhels6.x86_64.pkglist#
|
||||
bash
|
||||
nfs-utils
|
||||
openssl
|
||||
dhclient
|
||||
.....
|
||||
|
||||
|
||||
2. Prepare postinstall scripts
|
||||
|
||||
a) Specify postinstall script **shipped by xCAT** ::
|
||||
|
||||
mkdir -p /install/custom/netboot/<ostype>/
|
||||
|
||||
cp /opt/xcat/share/xcat/netboot/<ostype>/<profile>.postinstall \
|
||||
/install/custom/netboot/<ostype>/
|
||||
|
||||
chmod +x /install/custom/netboot/<ostype>/<profile>.postinstall
|
||||
|
||||
Take RHEL 6.4 on x86_64 for example ::
|
||||
|
||||
mkdir -p /install/custom/netboot/rh/
|
||||
cp /opt/xcat/share/xcat/netboot/rh/compute.rhels6.x86_64.postinstall \
|
||||
/install/custom/netboot/rh/
|
||||
chmod +x /install/custom/netboot/rh/compute.rhels6.x86_64.postinstall
|
||||
|
||||
b) Edit ``/install/custom/netboot/<ostype>/<profile>.postinstall`` and add below line in the end: ::
|
||||
|
||||
installroot=$1 ofeddir=/install/post/otherpkgs/<osver>/<arch>/ofed/ \
|
||||
NODESETSTATE=genimage mlnxofed_options=--force /install/postscripts/mlnxofed_ib_install
|
||||
|
||||
|
||||
3. Set the related osimage use the customized pkglist and customized compute.postinsall
|
||||
|
||||
* [RHEL/SLES] ::
|
||||
|
||||
chdef -t osimage -o <osver>-<arch>-netboot-compute \
|
||||
pkglist=/install/custom/netboot/<ostype>/compute.<osver>.<arch>.pkglist \
|
||||
postinstall=/install/custom/netboot/<ostype>/<profile>.postinstall
|
||||
|
||||
* [Ubuntu] ::
|
||||
|
||||
chdef -t osimage -o <osver>-<arch>-netboot-compute \
|
||||
postinstall=/install/custom/netboot/<ostype>/<profile>.postinstall
|
||||
|
||||
4. Generate and package image for diskless installation ::
|
||||
|
||||
genimage <osver>-<arch>-netboot-compute
|
||||
packimage <osver>-<arch>-netboot-compute
|
||||
|
||||
5. Install node ::
|
||||
|
||||
nodeset <nodename> osimage=<osver>-<arch>-netboot-compute
|
||||
rsetboot <nodename> net
|
||||
rpower <nodename> reset
|
||||
@ -1,42 +0,0 @@
|
||||
Preparation
|
||||
===========
|
||||
|
||||
Obtain the Mellanox OFED ISO file from `Mellanox official site <http://www.mellanox.com/page/products_dyn?product_family=26&mtag=linux_sw_drivers>`_ and mount it onto suggested target location on the xCAT MN according your OS and ARCH: ::
|
||||
|
||||
mkdir -p /install/post/otherpkgs/<osver>/<arch>/ofed
|
||||
|
||||
mount -o loop MLNX_OFED_LINUX-<packver1>-<packver2>-<osver>-<arch>.iso \
|
||||
/install/post/otherpkgs/<osver>/<arch>/ofed
|
||||
|
||||
Take sles11 sp1 for x86_64 as an example ::
|
||||
|
||||
mkdir -p /install/post/otherpkgs/sles11.1/x86_64/ofed/
|
||||
|
||||
mount -o loop MLNX_OFED_LINUX-1.5.3-3.0.0-sles11sp1-x86_64.iso \
|
||||
/install/post/otherpkgs/sles11.1/x86_64/ofed/
|
||||
|
||||
|
||||
Take Ubuntu14.4.1 for Power8 LE as an example ::
|
||||
|
||||
mkdir -p /install/post/otherpkgs/ubuntu14.04.1/ppc64el/ofed
|
||||
|
||||
mount -o loop MLNX_OFED_LINUX-2.3-1.0.1-ubuntu14.04-ppc64le.iso \
|
||||
/install/post/otherpkgs/ubuntu14.04.1/ppc64el/ofed
|
||||
|
||||
|
||||
**[NOTE]**
|
||||
|
||||
* Mellanox provides OFED files with **tarball** and **ISO** two format, but for xCAT, we just support **ISO** format right now.
|
||||
|
||||
Copy Sample script **mlnxofed_ib_install** shipped by xCAT into ``/install/postscripts`` before using, such as ::
|
||||
|
||||
cp /opt/xcat/share/xcat/ib/scripts/Mellanox/mlnxofed_ib_install \
|
||||
/install/postscripts/mlnxofed_ib_install
|
||||
|
||||
The **mlnxofed_ib_install** invokes a script ``mlnxofedinstall`` shipped by Mellanox OFED ISO. If you want to pass the argument to ``mlnxofedinstall``, you set the argument to the environment variable ``mlnxofed_options`` which could be read by **mlnxofed_ib_install**. For example: PPE requires the 32-bit version of libibverbs, but the default **mlnxofed_ib_install** will remove all the old ib related packages at first including the 32-bit version of libibverbs. In this case, you can set the environment variable ``mlnxofed_options=--force`` when running the **mlnxofed_ib_install**. For diskful, you should put the environment variable ``mlnxofed_options=--force`` in mypostscript.tmpl. myposcript.tmpl is in ``/opt/xcat/share/xcat/templates/mypostscript/`` by default. When customize it, you should copy it into ``/install/postscripts/myposcript.tmpl`` ::
|
||||
|
||||
mlnxofed_options='--force'
|
||||
export mlnxofed_options
|
||||
|
||||
|
||||
|
||||
@ -1,9 +0,0 @@
|
||||
Using mlnxofed_ib_install (drops support)
|
||||
=========================================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
mlnxofed_ib_install_v1_preparation.rst
|
||||
mlnxofed_ib_install_v1_diskful.rst
|
||||
mlnxofed_ib_install_v1_diskless.rst
|
||||
@ -0,0 +1,13 @@
|
||||
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``.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
mlnxofed_ib_install_v2_preparation.rst
|
||||
mlnxofed_configuration.rst
|
||||
mlnxofed_ib_verified_scenario_matrix.rst
|
||||
mlnxofed_ib_known_issue.rst
|
||||
|
||||
@ -1,169 +1,44 @@
|
||||
Configuration for Diskful Installation
|
||||
=======================================
|
||||
|
||||
1. Set script ``mlnxofed_ib_install`` as ``postbootscripts`` or ``postscripts`` ::
|
||||
|
||||
chdef <node> -p postbootscripts="mlnxofed_ib_install -p /install/<subpath>/<MLNX_OFED_LINUX.iso>"
|
||||
|
||||
Or ::
|
||||
|
||||
chdef <node> -p postscripts="mlnxofed_ib_install -p /install/<subpath>/<MLNX_OFED_LINUX.iso>"
|
||||
|
||||
xCAT simulates completely the way Mellanox scripts work by using ``postbootscripts``. This way need to reboot after drive installation to make Mellanox drivers work reliably just like Mellanox suggested. If you want to use the reboot after operating system installation to avoid reboot twice, you can using ``postscripts`` attribute to install Mellanox drivers. This way has been verified in limited scenarios. For more information please refer to :doc:`The Scenarios Have Been Verified </advanced/networks/infiniband/mlnxofed_ib_verified_scenario_matrix>`. You can try this way in other else scenarios if you needed.
|
||||
|
||||
2. Specify dependency package
|
||||
|
||||
Some dependencies need to be installed before running Mellanox scripts. These dependencies are different between different scenario. xCAT configurates these dependency packages by using ``pkglist`` attribute of ``osimage`` definition. Please refer to :doc:`Add Additional Software Packages </guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/additional_pkg>` for more information::
|
||||
|
||||
# lsdef -t osimage <os>-<arch>-install-compute
|
||||
Object name: <os>-<arch>-install-compute
|
||||
imagetype=linux
|
||||
....
|
||||
pkgdir=/<os packages directory>
|
||||
pkglist=/<os packages list directory>/compute.<os>.<arch>.pkglist
|
||||
....
|
||||
|
||||
You can append the ib dependency packages list in the end of ``/<os packages list directory>/compute.<os>.<arch>.pkglist`` directly like below: ::
|
||||
|
||||
#cat /<os packages list directory>/compute.<os>.<arch>.pkglist
|
||||
@base
|
||||
@x11
|
||||
openssl
|
||||
ntp
|
||||
rsyn
|
||||
#ib part
|
||||
createrepo
|
||||
kernel-devel
|
||||
kernel-source
|
||||
....
|
||||
|
||||
|
||||
Or if you want to isolate InfiniBand dependency packages list into a separate file, after you edit this file, you can append the file in ``/<os packages list directory>/compute.<os>.<arch>.pkglist`` like below way: ::
|
||||
|
||||
#cat /<os packages list directory>/compute.<os>.<arch>.pkglist
|
||||
@base
|
||||
@x11
|
||||
openssl
|
||||
ntp
|
||||
rsyn
|
||||
#INCLUDE:/<ib pkglist path>/<you ib pkglist file>#
|
||||
|
||||
xCAT has shipped some ib pkglist files under ``/opt/xcat/share/xcat/ib/netboot/<ostype>/``, these pkglist files have been verified in sepecific scenario. Please refer to :doc:`The Scenarios Have Been Verified </advanced/networks/infiniband/mlnxofed_ib_verified_scenario_matrix>` to judge if you can use it directly in your environment. If so, you can use it like below: ::
|
||||
|
||||
#cat /<os packages list directory>/compute.<os>.<arch>.pkglist
|
||||
@base
|
||||
@x11
|
||||
openssl
|
||||
ntp
|
||||
rsyn
|
||||
#INCLUDE:/opt/xcat/share/xcat/ib/netboot/<ostype>/ib.<os>.<arch>.pkglist#
|
||||
|
||||
Take rhels7.2 on ppc64le for example: ::
|
||||
|
||||
# lsdef -t osimage rhels7.2-ppc64le-install-compute
|
||||
Object name: rhels7.2-ppc64le-install-compute
|
||||
imagetype=linux
|
||||
osarch=ppc64le
|
||||
osdistroname=rhels7.2-ppc64le
|
||||
osname=Linux
|
||||
osvers=rhels7.2
|
||||
otherpkgdir=/install/post/otherpkgs/rhels7.2/ppc64le
|
||||
pkgdir=/install/rhels7.2/ppc64le
|
||||
pkglist=/install/custom/install/rh/compute.rhels7.ib.pkglist
|
||||
profile=compute
|
||||
provmethod=install
|
||||
template=/opt/xcat/share/xcat/install/rh/compute.rhels7.tmpl
|
||||
|
||||
|
||||
**[Note]**: If the osimage definition was generated by xCAT command ``copycds``, default value ``/opt/xcat/share/xcat/install/rh/compute.rhels7.pkglist`` was assigned to ``pkglist`` attribute. ``/opt/xcat/share/xcat/install/rh/compute.rhels7.pkglist`` is the sample pkglist shipped by xCAT, recommend to make a copy of this sample and using the copy in real environment. In the above example, ``/install/custom/install/rh/compute.rhels7.ib.pkglist`` is a copy of ``/opt/xcat/share/xcat/install/rh/compute.rhels7.pkglist``. ::
|
||||
|
||||
# cat /install/custom/install/rh/compute.rhels7.ib.pkglist
|
||||
#Please make sure there is a space between @ and group name
|
||||
wget
|
||||
ntp
|
||||
nfs-utils
|
||||
net-snmp
|
||||
rsync
|
||||
yp-tools
|
||||
openssh-server
|
||||
util-linux
|
||||
net-tools
|
||||
#INCLUDE:/opt/xcat/share/xcat/ib/netboot/rh/ib.rhels7.ppc64le.pkglist#
|
||||
|
||||
|
||||
|
||||
3. Install node ::
|
||||
|
||||
nodeset <node> osimage=<osver>-<arch>-install-compute
|
||||
rsetboot <node> net
|
||||
rpower <node> reset
|
||||
|
||||
|
||||
After steps above, you can login target node and find the Mellanox InfiniBand drives are located under ``/lib/modules/<kernel_version>/extra/``.
|
||||
|
||||
Issue ``ibv_devinfo`` command you can get the InfiniBand apater information ::
|
||||
|
||||
# ibv_devinfo
|
||||
hca_id: mlx5_0
|
||||
transport: InfiniBand (0)
|
||||
fw_ver: 10.14.2036
|
||||
node_guid: f452:1403:0076:10e0
|
||||
sys_image_guid: f452:1403:0076:10e0
|
||||
vendor_id: 0x02c9
|
||||
vendor_part_id: 4113
|
||||
hw_ver: 0x0
|
||||
board_id: IBM1210111019
|
||||
phys_port_cnt: 2
|
||||
Device ports:
|
||||
port: 1
|
||||
state: PORT_INIT (2)
|
||||
max_mtu: 4096 (5)
|
||||
active_mtu: 4096 (5)
|
||||
sm_lid: 0
|
||||
port_lid: 65535
|
||||
port_lmc: 0x00
|
||||
link_layer: InfiniBand
|
||||
|
||||
port: 2
|
||||
state: PORT_DOWN (1)
|
||||
max_mtu: 4096 (5)
|
||||
active_mtu: 4096 (5)
|
||||
sm_lid: 0
|
||||
port_lid: 65535
|
||||
port_lmc: 0x00
|
||||
link_layer: InfiniBand
|
||||
|
||||
Using ``service openibd status`` to verify if openibd works well. Below is the output in rhels7.2. ::
|
||||
|
||||
|
||||
# service openibd status
|
||||
HCA driver loaded
|
||||
|
||||
Configured IPoIB devices:
|
||||
ib0 ib1
|
||||
|
||||
Currently active IPoIB devices:
|
||||
Configured Mellanox EN devices:
|
||||
|
||||
Currently active Mellanox devices:
|
||||
|
||||
The following OFED modules are loaded:
|
||||
|
||||
rdma_ucm
|
||||
rdma_cm
|
||||
ib_addr
|
||||
ib_ipoib
|
||||
mlx4_core
|
||||
mlx4_ib
|
||||
mlx4_en
|
||||
mlx5_core
|
||||
mlx5_ib
|
||||
ib_uverbs
|
||||
ib_umad
|
||||
ib_ucm
|
||||
ib_sa
|
||||
ib_cm
|
||||
ib_mad
|
||||
ib_core
|
||||
|
||||
|
||||
Diskful Installation
|
||||
====================
|
||||
|
||||
#. Prepare dependency packages in the pkglist
|
||||
|
||||
In order for the Mellanox installation script to execute successfully, certain dependency packages are required to be installed on the compute node. xCAT provides sample package list files to help resolve these dependencies. The samples are located at ``/opt/xcat/share/xcat/ib/netboot/<os>/``.
|
||||
|
||||
To use the ``/opt/xcat/share/xcat/ib/netboot/rh/ib.rhels7.ppc64le.pkglist``, edit your existing ``pkglist`` file for the target osimage and add the following at the bottom: ::
|
||||
|
||||
#INCLUDE:/opt/xcat/share/xcat/ib/netboot/rh/ib.rhels7.ppc64le.pkglist#
|
||||
|
||||
#. Configure the ``mlnxofed_ib_install`` script to install the MNLX_OFED drivers
|
||||
|
||||
xCAT has a concept of postscripts that can be used to customize the node after the operating system is installed.
|
||||
|
||||
Mellanox recommends that the operating system is rebooted after the drivers are installed, so xCAT recommends using the ``postscripts`` attribute to avoid the need for a second reboot. To invoke the ``mlnxofed_ib_install`` as a postscript ::
|
||||
|
||||
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. ::
|
||||
|
||||
chdef -t node -o <node_name> \
|
||||
-p postscripts="mlnxofed_ib_install -p /install/<path-to>/<MLNX_OFED_LINUX.iso> \
|
||||
-m --add-kernel-support -end-"
|
||||
|
||||
#. Provision the node
|
||||
|
||||
#. Verification
|
||||
|
||||
* The Mellanox IB drivers are located at: ``/lib/modules/<kernel_version>/extra/``
|
||||
|
||||
* Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter
|
||||
|
||||
* Check the status of ``openibd`` service
|
||||
|
||||
sysVinit: ::
|
||||
|
||||
service openibd status
|
||||
|
||||
systemd: ::
|
||||
|
||||
systemctl status openibd.service
|
||||
|
||||
|
||||
@ -1,169 +1,64 @@
|
||||
Configuration for Diskless Installation
|
||||
=======================================
|
||||
|
||||
1. Specify dependency package
|
||||
|
||||
Some dependencies need to be installed before running Mellanox scripts. These dependencies are different among different scenarios. xCAT can help user to install these dependency packages by adding these package names to the file specified by the ``pkglist`` attribute of the ``osimage`` definition. Please refer to :doc:`Add Additional Software Packages </guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/additional_pkg>` for more information::
|
||||
|
||||
# lsdef -t osimage <osver>-<arch>-netboot-compute
|
||||
Object name: <osver>-<arch>-netboot-compute
|
||||
imagetype=linux
|
||||
....
|
||||
pkgdir=/<os packages directory>
|
||||
pkglist=/<os packages list directory>/compute.<os>.<arch>.pkglist
|
||||
....
|
||||
|
||||
You can append the ib dependency packages list in the end of ``/<os packages list directory>/compute.<os>.<arch>.pkglist`` directly like below: ::
|
||||
|
||||
#cat /<os packages list directory>/compute.<os>.<arch>.pkglist
|
||||
bash
|
||||
nfs-utils
|
||||
openssl
|
||||
dhclient
|
||||
kernel
|
||||
.....
|
||||
|
||||
#ib part
|
||||
createrepo
|
||||
kernel-devel
|
||||
kernel-source
|
||||
....
|
||||
|
||||
|
||||
Or if you want to isolate InfiniBand dependency packages list into a separate file, after you edit this file, you can append the file in ``/<os packages list directory>/compute.<os>.<arch>.pkglist`` like below way: ::
|
||||
|
||||
#cat /<os packages list directory>/compute.<os>.<arch>.pkglist
|
||||
bash
|
||||
nfs-utils
|
||||
openssl
|
||||
dhclient
|
||||
kernel
|
||||
.....
|
||||
#INCLUDE:/<ib pkglist path>/<you ib pkglist file>#
|
||||
|
||||
xCAT ships some InfiniBand pkglist files under ``/opt/xcat/share/xcat/ib/netboot/<ostype>/``, these pkglist files have been verified in sepecific scenario. Please refer to :doc:`The Scenarios Have Been Verified </advanced/networks/infiniband/mlnxofed_ib_verified_scenario_matrix>` to judge if you can use it directly in your environment. If so, you can use it like below: ::
|
||||
|
||||
#cat /<os packages list directory>/compute.<os>.<arch>.pkglist
|
||||
bash
|
||||
nfs-utils
|
||||
openssl
|
||||
dhclient
|
||||
kernel
|
||||
.....
|
||||
#INCLUDE:/opt/xcat/share/xcat/ib/netboot/<ostype>/ib.<os>.<arch>.pkglist#
|
||||
|
||||
|
||||
2. Prepare postinstall scripts
|
||||
|
||||
Edit ``postinstall`` script to trigger InfniBand drvices installation during ``genimage``. Using below command to find out where the ``postinstall`` script is defined. ::
|
||||
|
||||
# lsdef -t osimage <os>-<arch>-netboot-compute
|
||||
Object name: <os>-<arch>-netboot-compute
|
||||
....
|
||||
postinstall=/<postinstall script path/compute.<os>.<arch>.postinstall
|
||||
....
|
||||
|
||||
|
||||
|
||||
Edit ``/<postinstall script path/compute.<os>.<arch>.postinstall`` and add below line in the end. ::
|
||||
|
||||
/install/postscripts/mlnxofed_ib_install \
|
||||
-p /install/<path>/<MLNX_OFED_LINUX.iso> -i $1 -n genimage
|
||||
|
||||
|
||||
**[Note]** Mellanox OFED ISO was built against a series of certain kernael versions, If the version of linux kernel you are using does not match with any of the Mellanox offered pre-built kernel modules, you can pass ``--add-kernel-support`` command line argument to Mellanox OFED installation script to build these kernel modules base on the version of linux kernel you are using. The line added into ``<profile>.postinstall`` should like below. ::
|
||||
|
||||
/install/postscripts/mlnxofed_ib_install \
|
||||
-p /install/<subpath>/<MLNX_OFED_LINUX.iso> -m --add-kernel-support -end- -i $1 -n genimage
|
||||
|
||||
|
||||
Take rhels7.2 on ppc64le for example: ::
|
||||
|
||||
#lsdef -t osimage rhels7.2-ppc64le-netboot-compute
|
||||
Object name: rhels7.2-ppc64le-netboot-compute
|
||||
exlist=/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.exlist
|
||||
imagetype=linux
|
||||
osarch=ppc64le
|
||||
osdistroname=rhels7.2-ppc64le
|
||||
osname=Linux
|
||||
osvers=rhels7.2
|
||||
otherpkgdir=/install/post/otherpkgs/rhels7.2/ppc64le
|
||||
permission=755
|
||||
pkgdir=/install/rhels7.2/ppc64le
|
||||
pkglist=/install/custom/netboot/rh/compute.rhels7.ppc64le.pkglist
|
||||
postinstall=/install/custom/netboot/rh/compute.rhels7.ppc64le.ib.postinstall
|
||||
profile=compute
|
||||
provmethod=netboot
|
||||
rootimgdir=/install/netboot/rhels7.2/ppc64le/compute
|
||||
|
||||
|
||||
**[Note]**: If the osimage definition was generated by xCAT command ``copycds``, default value ``/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.pkglist`` was assigned to ``pkglist`` attribute. ``/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.pkglist`` is the sample pkglist shipped by xCAT, recommend to make a copy of this sample and using the copy in real environment. In the above example, ``/install/custom/netboot/rh/compute.rhels7.ppc64le.pkglist`` is a copy of ``/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.pkglist``. For the same reason, ``/install/custom/netboot/rh/compute.rhels7.ppc64le.ib.postinstall`` is a copy of ``/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.postinstall``.
|
||||
|
||||
``compute.rhels7.ppc64le.pkglist`` looks like below: ::
|
||||
|
||||
# cat /install/custom/netboot/rh/compute.rhels7.ppc64le.pkglist
|
||||
bash
|
||||
nfs-utils
|
||||
openssl
|
||||
dhclient
|
||||
bc
|
||||
......
|
||||
lsvpd
|
||||
irqbalance
|
||||
procps-ng
|
||||
parted
|
||||
net-tools
|
||||
#INCLUDE:/opt/xcat/share/xcat/ib/netboot/rh/ib.rhels7.ppc64le.pkglist#
|
||||
|
||||
``compute.rhels7.ppc64le.ib.postinstall`` looks like below: ::
|
||||
|
||||
# cat /install/custom/netboot/rh/compute.rhels7.ppc64le.ib.postinstall
|
||||
#!/bin/sh
|
||||
#-- Do not remove following line if you want to make use of CVS version tracking
|
||||
.....
|
||||
# [ -r $workdir/$profile.$ext ] && cat $workdir/$profile.$ext | grep -E '^[[:space:]]*#.*[[:space:]]\$Id' >> $installroot/etc/IMGVERSION
|
||||
#done
|
||||
/install/postscripts/mlnxofed_ib_install -p /install/ofed/MLNX_OFED_LINUX-3.2-2.0.0.0-rhel7.2-ppc64le.iso -i $1 -n genimage
|
||||
|
||||
3. Generate and package image for diskless installation ::
|
||||
|
||||
genimage <osver>-<arch>-netboot-compute
|
||||
packimage <osver>-<arch>-netboot-compute
|
||||
|
||||
4. Install node ::
|
||||
|
||||
nodeset <nodename> osimage=<osver>-<arch>-netboot-compute
|
||||
rsetboot <nodename> net
|
||||
rpower <nodename> reset
|
||||
|
||||
After installation, you can login target ndoe and issue ``ibv_devinfo`` command to verify if your InfiniBand driver works well. if everything is fine, you can get the InfiniBand apater information. ::
|
||||
|
||||
# ibv_devinfo
|
||||
hca_id: mlx5_0
|
||||
transport: InfiniBand (0)
|
||||
fw_ver: 10.14.2036
|
||||
node_guid: f452:1403:0076:10e0
|
||||
sys_image_guid: f452:1403:0076:10e0
|
||||
vendor_id: 0x02c9
|
||||
vendor_part_id: 4113
|
||||
hw_ver: 0x0
|
||||
board_id: IBM1210111019
|
||||
phys_port_cnt: 2
|
||||
Device ports:
|
||||
port: 1
|
||||
state: PORT_INIT (2)
|
||||
max_mtu: 4096 (5)
|
||||
active_mtu: 4096 (5)
|
||||
sm_lid: 0
|
||||
port_lid: 65535
|
||||
port_lmc: 0x00
|
||||
link_layer: InfiniBand
|
||||
|
||||
port: 2
|
||||
state: PORT_DOWN (1)
|
||||
max_mtu: 4096 (5)
|
||||
active_mtu: 4096 (5)
|
||||
sm_lid: 0
|
||||
port_lid: 65535
|
||||
port_lmc: 0x00
|
||||
link_layer: InfiniBand
|
||||
Diskless Installation
|
||||
=====================
|
||||
|
||||
#. Prepare dependency packages in the pkglist
|
||||
|
||||
In order for the Mellanox installation script to execute successfully, certain dependency packages are required to be installed on the compute node. xCAT provides sample package list files to help resolve these dependencies. The samples are located at ``/opt/xcat/share/xcat/ib/netboot/<os>/``.
|
||||
|
||||
To use the ``/opt/xcat/share/xcat/ib/netboot/rh/ib.rhels7.ppc64le.pkglist``, edit your existing ``pkglist`` file for the target osimage and add the following at the bottom: ::
|
||||
|
||||
#INCLUDE:/opt/xcat/share/xcat/ib/netboot/rh/ib.rhels7.ppc64le.pkglist#
|
||||
|
||||
#. Configure the ``mlnxofed_ib_install`` script to install the MNLX_OFED drivers
|
||||
|
||||
Edit the ``postinstall`` script on the osimage to invoke the ``mlnxofed_ib_install`` install script.
|
||||
|
||||
For example, take ``rhels7.2-ppc64le-netboot-compute``:
|
||||
|
||||
#. Find the path to the ``postinstall`` script: ::
|
||||
|
||||
# lsdef -t osimage -o rhels7.2-ppc64le-netboot-compute -i postinstall
|
||||
Object name: rhels7.2-ppc64le-netboot-compute
|
||||
postinstall=/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.postinstall
|
||||
|
||||
#. Edit the ``/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.postinstall`` and add the following: ::
|
||||
|
||||
/install/postscripts/mlnxofed_ib_install \
|
||||
-p /install/<path-to>/<MLNX_OFED_LINUX.iso> -i $1 -n genimage
|
||||
|
||||
*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. ::
|
||||
|
||||
/install/postscripts/mlnxofed_ib_install \
|
||||
-p /install/<path-to>/<MLNX_OFED_LINUX.iso> -m --add-kernel-support -end- \
|
||||
-i $1 -n genimage
|
||||
|
||||
#. Generate the diskless image
|
||||
|
||||
Use the ``genimage`` command to generate the diskless image from the osimage definition ::
|
||||
|
||||
genimage <osimage>
|
||||
|
||||
Use the ``packimage`` command to pack the diskless image for deployment ::
|
||||
|
||||
packimage <osimage>
|
||||
|
||||
#. Provision the node
|
||||
|
||||
#. Verification
|
||||
|
||||
* The Mellanox IB drivers are located at: ``/lib/modules/<kernel_version>/extra/``
|
||||
|
||||
* Use the ``ibv_devinfo`` comamnd to obtain information about the InfiniBand adapter
|
||||
|
||||
* Check the status of ``openibd`` service
|
||||
|
||||
sysVinit: ::
|
||||
|
||||
service openibd status
|
||||
|
||||
systemd: ::
|
||||
|
||||
systemctl status openibd.service
|
||||
|
||||
|
||||
@ -1,46 +1,59 @@
|
||||
Preparation
|
||||
===========
|
||||
|
||||
Obtain the Mellanox OFED ISO
|
||||
----------------------------
|
||||
|
||||
Obtain the Mellanox OFED ISO file from `Mellanox official Download Page <http://www.mellanox.com/page/products_dyn?product_family=26&mtag=linux_sw_drivers>`_ and put it into one place under ``/install`` directory depending on your need.
|
||||
|
||||
**[NOTE]**
|
||||
|
||||
* Mellanox provides OFED drivers in **tarball** and **ISO image** formats. xCAT only supports the **iso** format at this time.
|
||||
* Mellanox provides different OFED ISOs depending on operating system and machine architecture, named like MLNX_OFED_LINUX-<packver1>-<packver2>-<osver>-<arch>.iso, you should download correct one according to your environment.
|
||||
* Mellanox has some updates and known issues for echo OFED, please read `InfiniBand/VPI Software Overview <http://www.mellanox.com/page/software_overview_ib>`_ to understand these information.
|
||||
* The Mellanox links offered above maybe outdate in future for Mellanox updates its web page, xCAT will keep updating for synchronization. If we don't update in time, please access `Mellanox web portal <http://www.mellanox.com>`_ to find ``Support/Education`` then ``InfiniBand/VPI Drivers`` lables.
|
||||
|
||||
Prepare Install Script
|
||||
----------------------
|
||||
|
||||
**mlnxofed_ib_install.v2** is a sample script, its framework can help you install Mellanox drives easily. But in specific scenario, some detail need to be modified to meet requirement, such like dependency package list. It has been verified in limited scenarios and can work as solution in these scenarios. For these scenarions information please refer to :doc:`The Scenarios Have Been Verified </advanced/networks/infiniband/mlnxofed_ib_verified_scenario_matrix>`.
|
||||
|
||||
Copy **mlnxofed_ib_install.v2** into ``/install/postscripts`` and change name to **mlnxofed_ib_install** ::
|
||||
|
||||
cp /opt/xcat/share/xcat/ib/scripts/Mellanox/mlnxofed_ib_install.v2 \
|
||||
/install/postscripts/mlnxofed_ib_install
|
||||
|
||||
chmod +x /install/postscripts/mlnxofed_ib_install
|
||||
|
||||
``mlnxofed_ib_install`` has some options, **'-p' is always needed**.
|
||||
Below are the details of these options:
|
||||
|
||||
* **-p**: [required]--the directory where the OFED iso file is located
|
||||
* **-m**: [optional]--the mlnxofed_ib_install invokes a script ``mlnxofedinstall`` shipped by Mellanox OFED iso. Use this option to pass arguments to the ``mlnxofedinstall``. You must include ``-end-`` at the completion of the options to distinguish the option list. if you don't pass any argument to ``mlnxofedinstall``, **defualt value** ``--without-32bit --without-fw-update --force`` will be passed to ``mlnxofedinstall`` by xCAT.
|
||||
* **-i**: [required for diskless]--the image root path
|
||||
* **-n**: [required for diskless]--nodeset status, the value is 'genimage'
|
||||
|
||||
In general you can use ``mlnxofed_ib_install`` like below ::
|
||||
|
||||
mlnxofed_ib_install -p /install/<path>/<MLNX_OFED_LINUX.iso>
|
||||
|
||||
If need to pass ``--without-32bit --without-fw-update --add-kernel-support --force`` to ``mlnxofedinstall``, refer to below command. ::
|
||||
|
||||
mlnxofed_ib_install -p /install/<path>/<MLNX_OFED_LINUX.iso> \
|
||||
-m --without-32bit --without-fw-update --add-kernel-support --force -end-
|
||||
|
||||
**[Note]** We recommend to update your firmware to the version Mellanox supported in its release notes to avoid unexpected problem when you install InfiniBand driver.
|
||||
|
||||
Preparation
|
||||
===========
|
||||
|
||||
Download MLNX_OFED ISO
|
||||
----------------------
|
||||
|
||||
**xCAT only supports installation using the ISO format.**
|
||||
|
||||
Download the Mellanox OFED ISO file `here (MLNX_OFED) <http://www.mellanox.com/page/products_dyn?product_family=26&mtag=linux_sw_drivers>`_.
|
||||
|
||||
|
||||
Prepare Installation Script
|
||||
---------------------------
|
||||
|
||||
The ``mlnxofed_ib_install.v2`` is a sample script intended to assist with the installation of the Mellanox OFED drivers. The following support matrix documents the limited number of scenarios that have been verified: :doc:`support matrix </advanced/networks/infiniband/mlnxofed_ib_verified_scenario_matrix>`.
|
||||
|
||||
#. Copy the ``mlnxofed_ib_install.v2`` to ``/install/postscripts``, renaming to ``mlnxofed_ib_install``. ::
|
||||
|
||||
cp /opt/xcat/share/xcat/ib/scripts/Mellanox/mlnxofed_ib_install.v2 \
|
||||
/install/postscripts/mlnxofed_ib_install
|
||||
|
||||
# ensure the script has execute permission
|
||||
chmod +x /install/postscripts/mlnxofed_ib_install
|
||||
|
||||
#. Familarize the options available for the xCAT ``mlnxofed_ib_install`` script.
|
||||
|
||||
+---------+------------------+----------------------------------------------------------+
|
||||
| Option | Required | Description |
|
||||
+=========+==================+==========================================================+
|
||||
|``-p`` | Yes || The full path to the MLNX_OFED ISO image |
|
||||
+---------+------------------+----------------------------------------------------------+
|
||||
|``-m`` | No || Use this option to pass arguments to the Mellanox OFED |
|
||||
| | || installation script ``mlnxofedinstall``. |
|
||||
| | || |
|
||||
| | || The special keyword ``-end-`` must be added to the end |
|
||||
| | || of the string to mark the completion of the option list |
|
||||
| | || option list. |
|
||||
| | || |
|
||||
| | || If nothing is specified, xCAT passes the the following |
|
||||
| | || ``--without-32bit --with out-fw-update --force`` |
|
||||
+---------+------------------+----------------------------------------------------------+
|
||||
|``-i`` | For diskless || The image root path of the diskless image |
|
||||
| | || |
|
||||
+---------+------------------+----------------------------------------------------------+
|
||||
|``-n`` | For diskless || nodeset status, value is ``genimage`` |
|
||||
| | || |
|
||||
+---------+------------------+----------------------------------------------------------+
|
||||
|
||||
|
||||
A very basic usage of the install script: ::
|
||||
|
||||
/install/postscripts/mlnxofed_ib_install -p /install/<path-to>/<MLNX_OFED_LINUX.iso>
|
||||
|
||||
|
||||
To pass the ``--add-kernel-support`` option to ``mlnxofedinstall``, use the following command: ::
|
||||
|
||||
/install/postscripts/mlnxofed_ib_install -p /install/<path-to>/<MLNX_OFED_LINUX.iso> \
|
||||
-m --without-32bit --without-fw-update --add-kernel-support --force -end-
|
||||
|
||||
|
||||
@ -1,12 +0,0 @@
|
||||
Using mlnxofed_ib_install.v2 (Recommend)
|
||||
=========================================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
mlnxofed_ib_install_v2_preparation.rst
|
||||
mlnxofed_ib_install_v2_diskful.rst
|
||||
mlnxofed_ib_install_v2_diskless.rst
|
||||
mlnxofed_ib_verified_scenario_matrix.rst
|
||||
mlnxofed_ib_known_issue.rst
|
||||
|
||||
@ -1,19 +1,19 @@
|
||||
Known Issues
|
||||
============
|
||||
|
||||
Preventing upgrade of the Mellanox Drivers
|
||||
------------------------------------------
|
||||
|
||||
Known Issue 1
|
||||
-------------
|
||||
On RedHat operating systems, after the Mellanox drivers are installed, you may have a requirement to update your operating system to a later version.
|
||||
Some operating systems may ship InfiniBand drivers that are higher version than the Mellanox drivers you have installed and therefor may update the existing drivers.
|
||||
|
||||
To prevent this from happening, add the following in the ``/etc/yum.conf`` ::
|
||||
|
||||
After you install mellanox derives in rhels7.2 successfully by xCAT, maybe you have new requirement to upgrade your operating system to higher version. In this case you probably hit such problem the IB adaptor drives shipped by operating system is higher than the Mellanox drives you have installed. That means the the Mellanox drives will be replaced by the drives shipped by operating system. If it's not the result you expect, you hope keep the Mellanox drives after operating system upgraded, please add below statement into ``/etc/yum.conf`` in your target node after you install mellanox derives successfully for the first time. ::
|
||||
|
||||
exclude=dapl* libib* ibacm infiniband* libmlx* librdma* opensm* ibutils*
|
||||
|
||||
|
||||
Known Issue 2
|
||||
-------------
|
||||
Development packages in SLES
|
||||
----------------------------
|
||||
|
||||
If you want to use ``--add-kernel-support`` attribute in sles12.1 and ppc64le scenario, you will find some dependency packages are not shipped by SLES Server DVDs, such like ``python-devel``, it's shipped in SDK DVDs. xCAT doesn't ship specific pkglist to support such scenario. If you have such requirement, please used ``otherpkglist`` and ``otherpkgs`` attributes to prepare dependency packages repository ahead. If you need help about ``otherpkglist`` and ``otherpkgs`` attributes, please refer to :doc:`Add Additional Software Packages </guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/additional_pkg>`.
|
||||
If using the ``--add-kernel-support`` attribute on SLES operating systems, you may find problems with installing some dependency packages which are not shipped by the SLES server DVDs. The development rpms are provided by the SDK DVDs. Refer to :doc:`Add Additional Software Packages </guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/additional_pkg>` to configure the SDK repositories.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,15 +1,52 @@
|
||||
The Scenarios Have Been Verified
|
||||
=================================
|
||||
MLNX_OFED Support Matrix
|
||||
========================
|
||||
|
||||
The following ISO images and attributs have been verified by the xCAT Team.
|
||||
|
||||
**RedHat Enterprise Linux**
|
||||
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| RHEL 7.2 (ppc64le) |
|
||||
+==================================+===================================================================+
|
||||
| **OFED ISO** | MLNX_OFED_LINUX-3.2-2.0.0.0-rhel7.2-ppc64le.iso |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| **Attribute Supported** | --without-32bit --without-fw-update --add-kernel-support --force |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| **IB.pkglist** | ib.rhels7.ppc64le.pkglist |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| RHEL 7.1 (ppc64) |
|
||||
+==================================+===================================================================+
|
||||
| **OFED ISO** | MLNX_OFED_LINUX-3.2-2.0.0.0-rhel7.1-ppc64.iso |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| **Attribute Supported** | --without-32bit --without-fw-update --add-kernel-support --force |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| **IB.pkglist** | ib.rhels7.ppc64.pkglist |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
|
||||
|
||||
+---------------+---------+---------------------------------------------------+------------------------------------------------------------------+---------------------------+
|
||||
| OS version | Arch | Ofed version | Attribute supported by mlnx | IB.pkglist |
|
||||
+===============+=========+===================================================+==================================================================+===========================+
|
||||
| rhels7.1 | ppc64 | MLNX_OFED_LINUX-3.2-2.0.0.0-rhel7.1-ppc64.iso |--without-32bit --without-fw-update --add-kernel-support --force | ib.rhels7.ppc64.pkglist |
|
||||
+---------------+---------+---------------------------------------------------+------------------------------------------------------------------+---------------------------+
|
||||
| rhels7.2 | ppc64le | MLNX_OFED_LINUX-3.2-2.0.0.0-rhel7.2-ppc64le.iso |--without-32bit --without-fw-update --add-kernel-support --force | ib.rhels7.ppc64le.pkglist |
|
||||
+---------------+---------+---------------------------------------------------+------------------------------------------------------------------+---------------------------+
|
||||
| sles12.1 | ppc64le |MLNX_OFED_LINUX-3.2-2.0.0.0-sles12sp1-ppc64le.iso |--without-32bit --without-fw-update --force | ib.sles12.ppc64le.pkglist |
|
||||
+---------------+---------+---------------------------------------------------+------------------------------------------------------------------+---------------------------+
|
||||
| ubuntu14.04.3 | ppc64le |MLNX_OFED_LINUX-3.2-2.0.0.0-ubuntu14.04-ppc64le.iso|--without-32bit --without-fw-update --add-kernel-support --force |ib.ubuntu14.ppc64le.pkglist|
|
||||
+---------------+---------+---------------------------------------------------+------------------------------------------------------------------+---------------------------+
|
||||
**Suse Linux Enterprise Server**
|
||||
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| SLES 12 (ppc64le) |
|
||||
+==================================+===================================================================+
|
||||
| **OFED ISO** | MLNX_OFED_LINUX-3.2-2.0.0.0-sles12sp1-ppc64le.iso |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| **Attribute Supported** | --without-32bit --without-fw-update --force |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| **IB.pkglist** | ib.sles12.ppc64le.pkglist |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
|
||||
|
||||
**Ubuntu**
|
||||
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| Ubuntu14.04.3 (ppc64le) |
|
||||
+==================================+===================================================================+
|
||||
| **OFED ISO** | MLNX_OFED_LINUX-3.2-2.0.0.0-ubuntu14.04-ppc64le.iso |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| **Attribute Supported** | --without-32bit --without-fw-update --add-kernel-support --force |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
| **IB.pkglist** | ib.ubuntu14.ppc64le.pkglist |
|
||||
+----------------------------------+-------------------------------------------------------------------+
|
||||
|
||||
@ -72,7 +72,7 @@ Use the following command to consolidate the syslog to the Management Node or Se
|
||||
|
||||
Configure xdsh for Mellanox Switch
|
||||
----------------------------------
|
||||
To run xdsh commands to the Mellanox Switch, you must use the --devicetype input flag to xdsh. In addition, for xCAT versions less than 2.8, you must add a configuration file, please see `Setup ssh connection to the Mellanox Switch`_ section.
|
||||
To run xdsh commands to the Mellanox Switch, you must use the --devicetype input flag to xdsh. In addition, for xCAT versions less than 2.8, you must add a configuration file, see `Setup ssh connection to the Mellanox Switch`_ section.
|
||||
|
||||
For the Mellanox Switch the ``--devicetype`` is ``IBSwitch::Mellanox``. See :doc:`xdsh man page </guides/admin-guides/references/man1/xdsh.1>` for details.
|
||||
|
||||
|
||||
@ -5,3 +5,4 @@ Switch Discover
|
||||
:maxdepth: 2
|
||||
|
||||
switches_discovery.rst
|
||||
switch_based_switch_discovery.rst
|
||||
|
||||
@ -0,0 +1,174 @@
|
||||
Switch-based Switch Discovery
|
||||
=============================
|
||||
|
||||
Currently, xCAT supports switch based hardware discovery, the servers are identified through the switches and switch ports they are directly connected to. A similar method can be used to discover switches using switch-based discovery within the user defined dynamic IP range.
|
||||
|
||||
Pre-requirement
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
In order to do switch-based switch discovery, the admin
|
||||
|
||||
1. Needs to manually setup and configure core-switch, SNMP v3 needs to be enabled in order for xCAT access to it. **username** and **userpassword** attributes are for the remote login. It can be for **ssh** or **telnet**. If it is for **telnet**, set protocol to “telnet”. If the **username** is blank, the **username** and **password** will be retrieved from the passwd table with “switch” as the key. SNMP attributes will used for SNMPv3 communication. **nodetype** has to be set to "switch" to differentiate between switch-based node discovery or switch-based switch discovery. Refer to switches table attributes. Example of core-switch definition:
|
||||
|
||||
::
|
||||
|
||||
lsdef switch-10-5-23-1
|
||||
Object name: switch-10-5-23-1
|
||||
groups=switch
|
||||
ip=10.5.23.1
|
||||
mac=ab:cd:ef:gh:dc
|
||||
mgt=switch
|
||||
nodetype=switch
|
||||
password=admin
|
||||
postbootscripts=otherpkgs
|
||||
postscripts=syslog,remoteshell,syncfiles
|
||||
protocol=telnet
|
||||
snmpauth=sha
|
||||
snmppassword=userpassword
|
||||
snmpusername=snmpadmin
|
||||
snmpversion=3
|
||||
switchtype=BNT
|
||||
usercomment=IBM
|
||||
username=root
|
||||
|
||||
|
||||
|
||||
2. Predefine all top-rack switches which connect to core-switch. The attribute **ip** is static ip address for the switch. When ``switchdiscover --setup`` command is issued, this ip address will replace dhcp IP address on the switch. **nodetype=switch** needs to be set to differentiate between switch-based node discovery or switch-based switch discovery during discovery process. the attribute **switch** is hostname of core-switch and **switchport** is the port number in the core-switch that top-rack switch is connected to.
|
||||
|
||||
::
|
||||
|
||||
lsdef switch-192-168-5-22
|
||||
objtype=node
|
||||
groups=switch
|
||||
ip=192.168.5.22
|
||||
mgt=switch
|
||||
nodetype=switch
|
||||
switch=switch-10-5-23-1
|
||||
switchport=45
|
||||
switchtype=BNT
|
||||
|
||||
|
||||
3. Add switches to /etc/hosts for hostname lookup and xdsh command. ::
|
||||
|
||||
makehosts switch-192-168-5-23
|
||||
makehosts switch-192-168-5-22
|
||||
|
||||
|
||||
4. Setup Dynamic IP range in network table for discovered switches to use. ::
|
||||
|
||||
# tabdump networks
|
||||
#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,mtu,comments,disable
|
||||
"192_168_0_0-255_255_0_0","192.168.0.0","255.255.0.0","enP4p1s0f2","<xcatmaster>",,"192.168.3.29",,,,"192.168.5.150-192.168.5.170",,,,,,,,,
|
||||
|
||||
|
||||
dhcp should be restarted after seting up dynamic IP range.
|
||||
|
||||
|
||||
Discover Switches
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
xCAT supports **switchdiscover** command to discover the switches that are attached to the subnets on xCAT management node. Refer to http://xcat-docs.readthedocs.io/en/latest/advanced/networks/switchdiscover/switches_discovery.html for more info.
|
||||
|
||||
For the switch-based switch discovery, we add **–setup** flag: ::
|
||||
|
||||
|
||||
switchdiscover [noderange|--range ip_ranges][-s scan_methods] [--setup]
|
||||
|
||||
|
||||
if **--setup** flag is specified, the command will perform following steps:
|
||||
|
||||
1. Use snmp or nmap scan methods to find all switches in the dynamic IP ranges specified by --range, the available switches will be stored in switch hash table with hostname, switchtype, vendor info and mac address.
|
||||
|
||||
|
||||
2. Based on mac address for each switch defined in the hash table, call **find_mac** subroutine. The **find_mac** subroutine will go thought the switch and switch ports and find matched mac address.
|
||||
|
||||
* If discovered switch didn't find any predefined switch matches, it will log the message ``NO predefined switch matched``.
|
||||
* If discovered switch matched with one of pre-defined switch, it will update the predefined switch with ::
|
||||
|
||||
otherinterface=x.x.x.x (discovered ip)
|
||||
state=matched
|
||||
switchtype=type of switch
|
||||
usercomment=vendor information
|
||||
|
||||
|
||||
3. After switches are matched, the command will call config files to set up static IP address, hostname and enable the snmpv3. Currently, BNT and Mellanox switches are supported. The two config files are located in the **/opt/xcat/share/xcat/scripts/config.BNT** and **/opt/xcat/share/xcat/scripts/config.Mellanox**. the log message ``the switch type is not support for config`` is displayed if switchtype is something other than BNT or Mellanox.
|
||||
|
||||
4. After discovery process, the predefined node attribute in the xCATdb will be updated.
|
||||
|
||||
::
|
||||
|
||||
lsdef switch-192-168-5-22
|
||||
groups=switch
|
||||
ip=192.168.5.22
|
||||
mac=a8:97:dc:02:92:00
|
||||
mgt=switch
|
||||
nodetype=switch
|
||||
password=admin
|
||||
postbootscripts=otherpkgs
|
||||
postscripts=syslog,remoteshell,syncfiles
|
||||
protocol=telnet
|
||||
snmpauth=sha
|
||||
snmppassword=xcatadminpassw0rd@snmp
|
||||
snmpusername=xcatadmin
|
||||
snmpversion=3
|
||||
status=hostname_configed
|
||||
statustime=08-31-2016 15:35:49
|
||||
supportedarchs=ppc64
|
||||
switch=switch-10-5-23-1
|
||||
switchport=45
|
||||
switchtype=BNT
|
||||
usercomment=IBM Networking Operating System RackSwitch G8052
|
||||
username=root
|
||||
|
||||
|
||||
|
||||
Configure switches
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The **switchdiscover** command with ``--setup`` flag will set up switches with static ip address, change the hostname from predefine switches and enable snmpv3 configuration. For other switches configuration, Refer to http://xcat-docs.readthedocs.io/en/latest/advanced/networks/ethernet_switches/ethernet_switches.html and http://xcat-docs.readthedocs.io/en/latest/advanced/networks/infiniband/switch_configuration.html
|
||||
|
||||
These two config files are located in the **/opt/xcat/share/xcat/scripts**. The **switchdiscover** process will call the config files with ``--all`` option. User can call these scripts to setup one of options manually.
|
||||
|
||||
1. **configBNT** is for configure BNT switches.
|
||||
|
||||
::
|
||||
|
||||
./configBNT --help
|
||||
Usage:
|
||||
configBNT [-?│-h│--help]
|
||||
configBNT [--switches switchnames] [--all]
|
||||
configBNT [--switches switchnames] [--ip]
|
||||
configBNT [--switches switchnames] [--name ]
|
||||
configBNT [--switches switchnames] [--snmp] [--user snmp_user] [--password snmp_password] [--group snmp_group]
|
||||
configBNT [--switches switchnames] [--port port] [--vlan vlan]
|
||||
|
||||
2. **configMellanox** is for configuring Mellanox switch. The script will configure ntp service on the switch with xCAT MN and will use rspconfig command to
|
||||
* enable ssh
|
||||
* enable snmp function on the switch
|
||||
* enable the snmp trap
|
||||
* set logging destination to xCAT MN
|
||||
|
||||
::
|
||||
|
||||
./configMellanox --help
|
||||
Usage:
|
||||
configMellonax [-?│-h│--help]
|
||||
configMellonax [--switches switchnames] [--all]
|
||||
configMellonax [--switches switchnames] [--ip]
|
||||
configMellonax [--switches switchnames] [--name]
|
||||
configMellonax [--switches switchnames] [--config]
|
||||
|
||||
|
||||
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.
|
||||
|
||||
**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.
|
||||
|
||||
**ip_configed** --- switch is set up to static ip address based on predefine switch IP address. If failure to set up IP address, the status will stay as **Matched**.
|
||||
|
||||
**hostname_configed** -- switch host name is changed based on predefine switch hostname. If failure to change hostname on the switch, the status will stay as **ip_configed**.
|
||||
|
||||
**switch_configed** -- snmpv3 is setup for the switches. This should be finial status after running ``switchdiscover --setup`` command. If failure to setup snmpv3, the status will stay as **hostname_configed**.
|
||||
|
||||
@ -37,5 +37,5 @@ The discovery process works with the following four kind of switches: ::
|
||||
BNT
|
||||
Juniper
|
||||
|
||||
The ``switchdiscover`` command can display the output in xml format, stanza forma and normal list format. Please see the man pages for this command for details.
|
||||
The ``switchdiscover`` command can display the output in xml format, stanza forma and normal list format. See the man pages for this command for details.
|
||||
|
||||
|
||||
@ -53,7 +53,7 @@ For example: ::
|
||||
|
||||
This means port 42 of switch1 is connected to port 50 of switch2. And switch1 can be accessed using SNMP version 3 and switch 2 can be accessed using SNMP version 2.
|
||||
|
||||
Note: The **username** and the **password** on the switches table are NOT the same as SSH user name and password. You have to configure SNMP on the switch for these parameters and then fill up this table. Please use **tabdump switches -d** command to find out the meaning of each column.
|
||||
Note: The **username** and the **password** on the switches table are NOT the same as SSH user name and password. You have to configure SNMP on the switch for these parameters and then fill up this table. Use **tabdump switches -d** command to find out the meaning of each column.
|
||||
|
||||
**2. Populate the switch table**
|
||||
|
||||
@ -80,7 +80,7 @@ The interface eth1 is for the application network on node1, node2 and node3. Not
|
||||
|
||||
**3. Configure the switch for SNMP access**
|
||||
|
||||
Please make sure that the MN can access the switch using SNMP and the switch is configured such that it has SNMP read and write permissions.
|
||||
Make sure that the MN can access the switch using SNMP and the switch is configured such that it has SNMP read and write permissions.
|
||||
|
||||
You can use **snmpwalk/snmpget** and **snmpset** commands on the mn to check. These commands are from **net-snmp-utils** rpm.
|
||||
|
||||
@ -215,7 +215,7 @@ For example: ::
|
||||
VLAN Security
|
||||
-------------
|
||||
|
||||
To make the vlan more secure, the root guard and the bpdu guard are enabled for each ports within the vlan by **mkvlan** and **chvlan** commands. This way it guards the topology changes on the switch by the hackers who hack the STP. However, when the vlan is removed by the **rmvlan** and the **chvlan (-d)** commands, the root guard and the bpdu guard are not disabled because the code cannot tell if the guards were enabled by the admin or not. If you want to remove the gurads after the vlan is removed, you need to use the switch command line interface to do so. Please refer to the documents for the switch command line interfaces for details.
|
||||
To make the vlan more secure, the root guard and the bpdu guard are enabled for each ports within the vlan by **mkvlan** and **chvlan** commands. This way it guards the topology changes on the switch by the hackers who hack the STP. However, when the vlan is removed by the **rmvlan** and the **chvlan (-d)** commands, the root guard and the bpdu guard are not disabled because the code cannot tell if the guards were enabled by the admin or not. If you want to remove the gurads after the vlan is removed, you need to use the switch command line interface to do so. Refer to the documents for the switch command line interfaces for details.
|
||||
|
||||
Limitation
|
||||
----------
|
||||
|
||||
5
docs/source/advanced/probe/detect_dhcpd.rst
Normal file
5
docs/source/advanced/probe/detect_dhcpd.rst
Normal file
@ -0,0 +1,5 @@
|
||||
detect_dhcpd
|
||||
============
|
||||
|
||||
**detect_dhcp** can be used to detect the dhcp server in a network for a specific mac address.
|
||||
|
||||
5
docs/source/advanced/probe/discovery.rst
Normal file
5
docs/source/advanced/probe/discovery.rst
Normal file
@ -0,0 +1,5 @@
|
||||
discovery
|
||||
=========
|
||||
|
||||
**discovery** can be used to probe the discovery process, including pre-check for required configuration and realtime monitor of discovery process.
|
||||
|
||||
3
docs/source/advanced/probe/image.rst
Normal file
3
docs/source/advanced/probe/image.rst
Normal file
@ -0,0 +1,3 @@
|
||||
image
|
||||
=====
|
||||
|
||||
27
docs/source/advanced/probe/index.rst
Normal file
27
docs/source/advanced/probe/index.rst
Normal file
@ -0,0 +1,27 @@
|
||||
xCAT probe
|
||||
==========
|
||||
|
||||
To help identify some of the common issues with xCAT, a new tool suite is now available **xCAT probe**.
|
||||
|
||||
You can use ``xcatprobe -l`` to list all valid subcommands, output will be as below ::
|
||||
|
||||
# xcatprobe -l
|
||||
osdeploy Probe operating system provision process. Supports two modes - 'Realtime monitor' and 'Replay history'.
|
||||
xcatmn After xcat installation, use this command to check if xcat has been installed correctly and is
|
||||
ready for use. Before using this command, install 'tftp', 'nslookup' and 'wget' commands.
|
||||
switch-macmap To retrieve MAC address mapping for the specified switch, or all the switches defined in
|
||||
'switches' table in xCAT db.
|
||||
......
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
xcatmn.rst
|
||||
detect_dhcpd.rst
|
||||
image.rst
|
||||
osdeploy.rst
|
||||
discovery.rst
|
||||
switch-macmap.rst
|
||||
nodecheck.rst
|
||||
osimagecheck.rst
|
||||
|
||||
2
docs/source/advanced/probe/nodecheck.rst
Normal file
2
docs/source/advanced/probe/nodecheck.rst
Normal file
@ -0,0 +1,2 @@
|
||||
nodecheck
|
||||
=========
|
||||
99
docs/source/advanced/probe/osdeploy.rst
Normal file
99
docs/source/advanced/probe/osdeploy.rst
Normal file
@ -0,0 +1,99 @@
|
||||
osdeploy
|
||||
========
|
||||
|
||||
**osdeploy** operating system provision process. Supports two modes - 'Realtime monitor' and 'Replay history'.
|
||||
|
||||
Realtime monitor: This is a default. This tool with monitor provision state of the node. Trigger 'Realtime monitor' before rebooting target node to do provisioning.
|
||||
|
||||
Replay history: Used after provisioning is finished to probe the previously completed provisioning.
|
||||
|
||||
**Note**: Currently, hierarchical structure is not supported.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
::
|
||||
|
||||
xcatprobe osdeploy -h
|
||||
xcatprobe osdeploy -n <node_range> [-t <max_waiting_time>] [-V]
|
||||
xcatprobe osdeploy -n <node_range> -r <xxhxxm> [-V]
|
||||
|
||||
Options:
|
||||
|
||||
* **-n**: The range of nodes to be monitored or replayed.
|
||||
* **-r**: Trigger 'Replay history' mode. Follow the duration of rolling back. Units are 'h' (hour) or 'm' (minute). If unit is not specified, hour will be used by default.
|
||||
* **-t**: The maximum time to wait when doing monitor, unit is minutes. default is 60.
|
||||
* **-V**: Output more information.
|
||||
|
||||
``-r`` means replay history of OS provision, if no ``-r`` means to do realtime monitor.
|
||||
|
||||
Realtime monitor
|
||||
----------------
|
||||
|
||||
To monitor OS provisioning in real time, open at least 2 terminal windows. One to run ``osdeploy`` probe: ::
|
||||
|
||||
xcatprobe osdeploy -n cn1 [-V]
|
||||
|
||||
After some pre-checks, the probe will wait for provisioning information, similar to output below: ::
|
||||
|
||||
# xcatprobe osdeploy -n c910f03c17k20
|
||||
The install NIC in current server is enp0s1 [INFO]
|
||||
All nodes which will be deployed are valid [ OK ]
|
||||
-------------------------------------------------------------
|
||||
Start capturing every message during OS provision process......
|
||||
-------------------------------------------------------------
|
||||
|
||||
Open second terminal window to run provisioning: ::
|
||||
|
||||
nodeset cn1 osimage=<osimage>
|
||||
rpower cn1 boot
|
||||
|
||||
When all the nodes complete provisioning, the probe will exit and display output similar to: ::
|
||||
|
||||
# xcatprobe osdeploy -n c910f03c17k20
|
||||
The install NIC in current server is enp0s1 [INFO]
|
||||
All nodes which will be deployed are valid [ OK ]
|
||||
-------------------------------------------------------------
|
||||
Start capturing every message during OS provision process......
|
||||
-------------------------------------------------------------
|
||||
|
||||
[c910f03c17k20] Use command rinstall to reboot node c910f03c17k20
|
||||
[c910f03c17k20] Node status is changed to powering-on
|
||||
[c910f03c17k20] Receive DHCPDISCOVER via enp0s1
|
||||
[c910f03c17k20] Send DHCPOFFER on 10.3.17.20 back to 42:d0:0a:03:11:14 via enp0s1
|
||||
[c910f03c17k20] DHCPREQUEST for 10.3.17.20 (10.3.5.4) from 42:d0:0a:03:11:14 via enp0s1
|
||||
[c910f03c17k20] Send DHCPACK on 10.3.17.20 back to 42:d0:0a:03:11:14 via enp0s1
|
||||
[c910f03c17k20] Via TFTP download /boot/grub2/grub2-c910f03c17k20
|
||||
[c910f03c17k20] Via TFTP download /boot/grub2/powerpc-ieee1275/normal.mod
|
||||
......
|
||||
[c910f03c17k20] Postscript: otherpkgs exited with code 0
|
||||
[c910f03c17k20] Node status is changed to booted
|
||||
[c910f03c17k20] done
|
||||
[c910f03c17k20] provision completed.(c910f03c17k20)
|
||||
[c910f03c17k20] provision completed [ OK ]
|
||||
All nodes specified to monitor, have finished OS provision process [ OK ]
|
||||
==================osdeploy_probe_report=================
|
||||
All nodes provisioned successfully [ OK ]
|
||||
|
||||
|
||||
If there is something wrong when provisioning, this probe will exit when timeout is reachedd or ``Ctrl+C`` is pressed by user. The maximum time can be set by using ``-t`` as below(default 30 minutes) ::
|
||||
|
||||
|
||||
xcatprobe osdeploy -n cn1 -t 30
|
||||
|
||||
Replay history
|
||||
--------------
|
||||
|
||||
To replay history of OS provision from 1 hour 20 minutes ago, use command as ::
|
||||
|
||||
xcatprobe osdeploy -n cn1 -r 1h20m
|
||||
|
||||
Outout will be similar to: ::
|
||||
|
||||
# xcatprobe osdeploy -n c910f03c17k20
|
||||
The install NIC in current server is enp0s1 [INFO]
|
||||
All nodes which will be deployed are valid [ OK ]
|
||||
Start to scan logs which are later than *********, waiting for a while.............
|
||||
==================osdeploy_probe_report=================
|
||||
All nodes provisioned successfully [ OK ]
|
||||
|
||||
2
docs/source/advanced/probe/osimagecheck.rst
Normal file
2
docs/source/advanced/probe/osimagecheck.rst
Normal file
@ -0,0 +1,2 @@
|
||||
osimagecheck
|
||||
============
|
||||
3
docs/source/advanced/probe/switch-macmap.rst
Normal file
3
docs/source/advanced/probe/switch-macmap.rst
Normal file
@ -0,0 +1,3 @@
|
||||
switch-macmap
|
||||
=============
|
||||
|
||||
56
docs/source/advanced/probe/xcatmn.rst
Normal file
56
docs/source/advanced/probe/xcatmn.rst
Normal file
@ -0,0 +1,56 @@
|
||||
xcatmn
|
||||
======
|
||||
|
||||
**xcatmn** can be used to check if xcat has been installed correctly and is ready for use.
|
||||
|
||||
**Note**: For several check items(eg. tftp service, dns service, http service), 'tftp', 'nslookup' and 'wget' are need. If not installed, a warning message will be displayed..
|
||||
|
||||
Command is as below ::
|
||||
|
||||
xcatprobe xcatmn -i <install_nic> [-V]
|
||||
|
||||
* **-i**: [Required] Specify the network interface name of provision network on management node.
|
||||
* **-V**: Output more information for debug.
|
||||
|
||||
For example, run command on Management Node ::
|
||||
|
||||
xcatprobe xcatmn -i eth0
|
||||
|
||||
Output will be similar to: ::
|
||||
|
||||
# xcatprobe xcatmn -i eth0
|
||||
[MN]: Sub process 'xcatd: SSL listener' is running [ OK ]
|
||||
[MN]: Sub process 'xcatd: DB Access' is running [ OK ]
|
||||
[MN]: Sub process 'xcatd: UDP listener' is running [ OK ]
|
||||
[MN]: Sub process 'xcatd: install monitor' is running [ OK ]
|
||||
[MN]: Sub process 'xcatd: Discovery worker' is running [ OK ]
|
||||
[MN]: Sub process 'xcatd: Command log writer' is running [ OK ]
|
||||
[MN]: xcatd is listening on port 3001 [ OK ]
|
||||
[MN]: xcatd is listening on port 3002 [ OK ]
|
||||
[MN]: 'lsxcatd -a' works [ OK ]
|
||||
[MN]: The value of 'master' in 'site' table is an IP address [ OK ]
|
||||
[MN]: NIC enp0s1 exists on current server [ OK ]
|
||||
[MN]: Get IP address of NIC eth0 [ OK ]
|
||||
[MN]: The IP *.*.*.* of eth0 equals the value of 'master' in 'site' table [ OK ]
|
||||
[MN]: IP *.*.*.* of NIC eth0 is a static IP on current server [ OK ]
|
||||
[MN]: *.*.*.* belongs to one of networks defined in 'networks' table [ OK ]
|
||||
[MN]: There is domain definition in 'site' table [ OK ]
|
||||
[MN]: There is a configuration in 'passwd' table for 'system' for node provisioning [ OK ]
|
||||
[MN]: There is /install directory on current server [ OK ]
|
||||
[MN]: There is /tftpboot directory on current server [ OK ]
|
||||
[MN]: The free space of '/' is less than 12 G [ OK ]
|
||||
[MN]: SELinux is disabled on current server [ OK ]
|
||||
[MN]: Firewall is closed on current server [ OK ]
|
||||
[MN]: HTTP service is ready on *.*.*.* [ OK ]
|
||||
[MN]: TFTP service is ready on *.*.*.* [ OK ]
|
||||
[MN]: DNS server is ready on *.*.*.* [ OK ]
|
||||
[MN]: The size of /var/lib/dhcpd/dhcpd.leases is less than 100M [ OK ]
|
||||
[MN]: DHCP service is ready on *.*.*.* [ OK ]
|
||||
======================do summary=====================
|
||||
[MN]: Check on MN PASS. [ OK ]
|
||||
|
||||
**[MN]** means that the verification is performed on the Management Node. Overall status of ``PASS`` or ``FAILED`` will be displayed after all items are verified..
|
||||
|
||||
Service Nodes are checked automatically for hierarchical clusters.
|
||||
|
||||
For Service Nodes, the output will contain ``[SN:nodename]`` to distinguish different Service Nodes.
|
||||
@ -18,7 +18,7 @@ Following sections show how to use ``diskdiscover`` and ``configraid``, we assum
|
||||
Discovering disk devices
|
||||
------------------------
|
||||
|
||||
Command ``diskdiscover`` scans disk devices, it can get the overview of disks and RAID arrays information from compute node; The outputs contain useful information for ``configraid`` to configure RAID arrays, user can get ``pci_id``, ``pci_slot_name``, ``disk names``, ``RAID arrays`` and other informations from the outputs. It should be ran in xcat genesis system. It can be executed without input parameter or with pci_id, pci_id includes PCI vender and device ID. For example, power8 SAS adapter pci_id is ``1014:034a``, ``1014`` is vender info, ``034a`` is PCI-E IPR SAS Adapter, more info about pci_id refer to ``http://pci-ids.ucw.cz/read/PC/1014/``.
|
||||
Command ``diskdiscover`` scans disk devices, it can get the overview of disks and RAID arrays information from compute node; The outputs contain useful information for ``configraid`` to configure RAID arrays, user can get ``pci_id``, ``pci_slot_name``, ``disk names``, ``RAID arrays`` and other informations from the outputs. It should be ran in xcat genesis system. It can be executed without input parameter or with pci_id, pci_id includes PCI vendor and device ID. For example, power8 SAS adapter pci_id is ``1014:034a``, ``1014`` is vendor info, ``034a`` is PCI-E IPR SAS Adapter, more info about pci_id refer to ``http://pci-ids.ucw.cz/read/PC/1014/``.
|
||||
|
||||
Here are steps to use ``diskdiscover``:
|
||||
|
||||
@ -70,19 +70,19 @@ Here are the input parameters introduction:
|
||||
#. **delete_raid** : List raid arrays which should be removed.
|
||||
|
||||
* If its value is all, all raid arrays detected should be deleted.
|
||||
* If its value is a list of raid array names, these raid arrays will be deleted. Raid array names should be seperated by ``#``.
|
||||
* If its value is a list of raid array names, these raid arrays will be deleted. Raid array names should be separated by ``#``.
|
||||
* If its value is null or there is no delete_raid, no raid array will be deleted.
|
||||
* If there is no delete_raid, the default value is null.
|
||||
|
||||
#. **stripe_size** : It is optional used when creating RAID arrays. If stripe size is not specified, it will default to the recommended stripe size for the selected RAID level.
|
||||
|
||||
#. **create_raid** : To create a raid array, add a line beginning with create_raid, all attributes keys and values are seperated by ``#``. The formats are as followings:
|
||||
#. **create_raid** : To create a raid array, add a line beginning with create_raid, all attributes keys and values are separated by ``#``. The formats are as followings:
|
||||
|
||||
* ``rl`` means RAID level, RAID level can be any supported RAID level for the given adapter, such as 0, 10, 5, 6. ``rl`` is a mandatory attribute for every create_raid. Supported RAID level is depend on pysical server's RAID adapter.
|
||||
* ``rl`` means RAID level, RAID level can be any supported RAID level for the given adapter, such as 0, 10, 5, 6. ``rl`` is a mandatory attribute for every create_raid. Supported RAID level is depend on physical server's RAID adapter.
|
||||
|
||||
* User can select disks based on following attributes value. User can find these value based on ``diskdiscover`` outputs as above section described.
|
||||
|
||||
a. ``pci_id`` is PCI vender and device ID.
|
||||
a. ``pci_id`` is PCI vendor and device ID.
|
||||
b. ``pci_slot_name`` is the specified PCI location. If using ``pci_slot_name``, this RAID array will be created using disks from it.
|
||||
c. ``disk_names`` is a list of advanced format disk names. If using ``disk_names``, this RAID array will be created using these disks.
|
||||
|
||||
@ -139,7 +139,7 @@ Configuring RAID manually in xcat genesis system shell
|
||||
|
||||
xdsh cn1 'configraid delete_raid=all create_raid="rl#0|pci_id#1014:034a|disk_num#2"'
|
||||
|
||||
Monitoring and debuging RAID configration process
|
||||
Monitoring and debuging RAID configuration process
|
||||
''''''''''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
#. Creating some RAID level arrays take very long time, for example, If user creates RAID 10, it will cost tens of minutes or hours. During this period, you can use xCAT xdsh command to monitor the progress of raid configuration. ::
|
||||
|
||||
@ -44,7 +44,7 @@ Enabling the certificate functionality of https server is useful for the Rest AP
|
||||
|
||||
The certificate for xcatd has already been generated when installing xCAT, it can be reused by the https server. To enable the server certificate authentication, the hostname of xCAT MN must be a fully qualified domain name (FQDN). The REST API client also must use this FQDN when accessing the https server. If the hostname of the xCAT MN is not a FQDN, you need to change the hostname first.
|
||||
|
||||
Typically the hostname of the xCAT MN is initially set to the NIC which faces to the cluster (usually an internal/private NIC). If you want to enable the REST API for public client, please set the hostname of xCAT MN to one of the public NIC.
|
||||
Typically the hostname of the xCAT MN is initially set to the NIC which faces to the cluster (usually an internal/private NIC). If you want to enable the REST API for public client, set the hostname of xCAT MN to one of the public NIC.
|
||||
|
||||
To change the hostname, edit /etc/sysconfig/network (RHEL) or /etc/HOSTNAME (SLES) and run: ::
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Transmission Channel
|
||||
--------------------
|
||||
|
||||
The xCAT daemon uses SSL to only allow authorized users to run xCAT commands. All xCAT commands are initiated as an xCAT **client**, even when run commands from the xCAT management node. This **client** opens an SSL socket to the xCAT daemon, sends the command and receives responses through this one socket. xCAT has configured the certificate for root, if you nee to authorize other users, please refer to below section.
|
||||
The xCAT daemon uses SSL to only allow authorized users to run xCAT commands. All xCAT commands are initiated as an xCAT **client**, even when run commands from the xCAT management node. This **client** opens an SSL socket to the xCAT daemon, sends the command and receives responses through this one socket. xCAT has configured the certificate for root, if you nee to authorize other users, refer to the section below.
|
||||
|
||||
|
||||
Create SSL Certificate So That User Can Be Authenticated By xCAT
|
||||
@ -25,7 +25,7 @@ This will create the following files in the <username> 's ``$HOME/.xcat`` direct
|
||||
Commands Access Control
|
||||
-----------------------
|
||||
|
||||
Except SSL channel, xCAT only authorize root on the management node to run **xCAT** commands by default. But xCAT can be configured to allow both **non-root users** and **remote users** to run limited xCAT commands. For remote users, we mean the users who triggers the xCAT commands from other nodes and not have to login to the management node. xCAT uses the **policy** table to control who has authority to run specific xCAT commands. For a full explanation of the **policy** table, please refer to :doc:`policy </guides/admin-guides/references/man5/policy.5>` man page.
|
||||
Except SSL channel, xCAT only authorize root on the management node to run **xCAT** commands by default. But xCAT can be configured to allow both **non-root users** and **remote users** to run limited xCAT commands. For remote users, we mean the users who triggers the xCAT commands from other nodes and not have to login to the management node. xCAT uses the **policy** table to control who has authority to run specific xCAT commands. For a full explanation of the **policy** table, refer to :doc:`policy </guides/admin-guides/references/man5/policy.5>` man page.
|
||||
|
||||
|
||||
Granting Users xCAT Privileges
|
||||
@ -74,7 +74,7 @@ Below are the steps of how to set up a login node.
|
||||
|
||||
1. Install the xCAT client
|
||||
|
||||
In order to avoid stucking in dependence problem in different distro. We recommand to create repository first by referring to below links.
|
||||
In order to avoid dependency problems on different distros, we recommend creating repository first by referring to links below.
|
||||
|
||||
* :doc:`Configure xCAT Software Repository in RHEL</guides/install-guides/yum/configure_xcat>`
|
||||
|
||||
@ -111,11 +111,11 @@ Below are the steps of how to set up a login node.
|
||||
|
||||
The remote not-root user still needs to set up the credentials for communication with management node. By running the ``/opt/xcat/share/xcat/scripts/setup-local-client.sh <username>`` command as root in management node, the credentials are generated in <username>'s ``$HOME/.xcat`` directory in management node. These credential files must be copied to the <username>'s ``$HOME/.xcat`` directory on the login node. **Note**: After ``scp``, in the login node, you must make sure the owner of the credentials is <username>.
|
||||
|
||||
Setup your ``policy`` table on the managment node with the permissions that you would like the non-root id to have.
|
||||
Setup your ``policy`` table on the management node with the permissions that you would like the non-root id to have.
|
||||
|
||||
At this time, the non-root id should be able to execute any commands that have been set in the ``policy`` table from the Login Node.
|
||||
|
||||
If any remote shell commmands (psh,xdsh) are needed, then you need to follow `Extra Setup For Remote Commands`_.
|
||||
If any remote shell commands (psh,xdsh) are needed, then you need to follow `Extra Setup For Remote Commands`_.
|
||||
|
||||
|
||||
Auditing
|
||||
@ -142,7 +142,7 @@ Password Management
|
||||
|
||||
xCAT is required to store passwords for various logons so that the application can login to the devices without having to prompt for a password. The issue is how to securely store these passwords.
|
||||
|
||||
Currently xCAT stores passwords in ``passwd`` table. You can store them as plaintext, you also can store them as MD5 ciphertext.
|
||||
Currently xCAT stores passwords in ``passwd`` table. You can store them as plain text, you can also store them as MD5 ciphertext.
|
||||
|
||||
Here is an example about how to store a MD5 encrypted password for root in ``passwd`` table. ::
|
||||
|
||||
@ -178,5 +178,5 @@ This setting of site.sshbetweennodes will only enable root ssh between nodes of
|
||||
Secure Zones
|
||||
````````````
|
||||
|
||||
You can set up multiple zones in an xCAT cluster. A node in the zone can ssh without password to any other node in the zone, but not to nodes in other zones. Please refer :doc:`Zones </advanced/zones/index>` for more information.
|
||||
You can set up multiple zones in an xCAT cluster. A node in the zone can ssh without password to any other node in the zone, but not to nodes in other zones. Refer to :doc:`Zones </advanced/zones/index>` for more information.
|
||||
|
||||
|
||||
@ -40,7 +40,7 @@ This document describes how to install and configure a template node (called gol
|
||||
Prepare the xCAT Management Node for Support Sysclone
|
||||
`````````````````````````````````````````````````````
|
||||
|
||||
How to configure xCAT management node please refer to section :ref:`install_guides`
|
||||
To configure xCAT management node refer to section :ref:`install_guides`
|
||||
|
||||
For support Sysclone, we need to install some extra rpms on management node and the golden client.
|
||||
|
||||
@ -93,7 +93,7 @@ Install and Configure the Golden Client
|
||||
|
||||
The Golden Client acts as a regular node for xCAT, just have some extra rpms to support clone. When you deploy golden client with xCAT, you just need to add a few additional definitions to the image which will be used to deploy golden client.
|
||||
|
||||
For information of how to install a regular node, please refer to section :ref:`Diskful Installation <diskful_installation>`
|
||||
For information of how to install a regular node, refer to section :ref:`Diskful Installation <diskful_installation>`
|
||||
|
||||
For support clone, add 'otherpkglist' and 'otherpkgdir' attributes to the image definition which will be used to deploy golden client, then deploy golden client as normal. then the golden client will have extra rpms to support clone. If you have deployed your golden client already, using 'updatenode' command to push these extra rpms to golden client. CentOS share the same pkglist file with RHEL. For example:
|
||||
|
||||
@ -121,7 +121,7 @@ For support clone, add 'otherpkglist' and 'otherpkgdir' attributes to the image
|
||||
chdef -t osimage -o <osimage-name> -p otherpkgdir=/install/post/otherpkgs/rhels6.3/ppc64
|
||||
updatenode <golden-cilent> -S
|
||||
|
||||
*[Note]: If you install systemimager RPMs on CentOS 6.5 node by above steps, you maybe hit failure. this is a known issue because some defect of CentOS6.5 itself. Please refer to known issue section for help.*
|
||||
*[Note]: If you install systemimager RPMs on CentOS 6.5 node by above steps, you maybe hit failure. this is a known issue because some defect of CentOS6.5 itself. Refer to known issue section for help.*
|
||||
|
||||
Capture Image from Golden Client
|
||||
````````````````````````````````
|
||||
@ -159,7 +159,7 @@ If, at a later time, you need to make changes to the golden client (install new
|
||||
|
||||
**[Limitation]**: In xcat2.8.5, this feature has limitation in RHEL and CentOS. when your delta changes related bootloader, it would encounter error. This issue will be fixed in xcat higher version. So up to now, in RHEL and CentOS, this feature just update files not related bootloader.
|
||||
|
||||
Update delta changes please follow below steps:
|
||||
Update delta changes follow below steps:
|
||||
|
||||
1. Make changes to your golden node (install new rpms, change config files, etc.).
|
||||
|
||||
@ -199,7 +199,7 @@ Known Issue
|
||||
Can not install systemimager RPMs in CentOS6.5 by yum
|
||||
``````````````````````````````````````````````````````
|
||||
|
||||
If you install systemimager RPMs on CentOS 6.5 node by yum, you maybe hit failure because some defect of CentOS6.5 itself. So please copy related RPMs to CentOS 6.5 node and install them by hand.
|
||||
If you install systemimager RPMs on CentOS 6.5 node using yum, you may experience some problems due to CentOS6.5 itself. If that happens, copy related RPMs to CentOS 6.5 node and install them by hand.
|
||||
|
||||
* **On management node**::
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@ Clone the xCAT project from `GitHub <https://github.com/xcat2/xcat-core>`_::
|
||||
xcat-deps
|
||||
---------
|
||||
|
||||
The ``xcat-deps`` package is currently owned and maintained by the core development on our internal servers. Please use the packages created at: http://xcat.org/download.html#xcat-dep
|
||||
The ``xcat-deps`` package is currently owned and maintained by the core development on our internal servers. Use the packages created at: http://xcat.org/download.html#xcat-dep
|
||||
|
||||
|
||||
man pages
|
||||
|
||||
@ -161,7 +161,7 @@ Add links to refer other web page is a very common way in writting document, it
|
||||
Add OS or ARCH Specific Contents
|
||||
--------------------------------
|
||||
|
||||
When writing a common xCAT doc, we always encounter the case that certain small part of content needs to be OS or ARCH specific. In this case, please use the following format to add specific branches.
|
||||
When writing a common xCAT doc, we always encounter the case that certain small part of content needs to be OS or ARCH specific. In this case, use the following format to add specific branches.
|
||||
|
||||
The keyword in the **[]** can be an OS name or ARCH name, or any name which can distinguish the content from other part.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ Contributor and Maintainer Agreements
|
||||
|
||||
We welcome developers willing to contribute to the xCAT project to help make it better.
|
||||
|
||||
Please follow the guidelines below.
|
||||
Follow the guidelines below.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
@ -7,7 +7,7 @@ In order to clarify the intellectual property license granted with Contributions
|
||||
|
||||
This version of the Agreement allows an entity (the "Corporation") to submit Contributions to the xCAT Community, to authorize Contributions submitted by its designated employees to the xCAT Community, and to grant copyright and patent licenses thereto.
|
||||
|
||||
If you have not already done so, please complete and sign, then scan and email a PDF file of this Agreement to: **xcat-legal@lists.sourceforge.net**. Please read this document carefully before signing and keep a copy for your records.
|
||||
If you have not already done so, complete and sign, then scan and email a PDF file of this Agreement to: **xcat-legal@lists.sourceforge.net**. Read this document carefully before signing and keep a copy for your records.
|
||||
|
||||
Corporation name: ___________________________________________________
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ The xCAT Community Individual Contributor License Agreement ("Agreement")
|
||||
|
||||
In order to clarify the intellectual property license granted with Contributions from any person or entity made for the benefit of the xCAT Community, a Contributor License Agreement ("CLA") must be on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the xCAT Community and its users; it does not change your rights to use your own Contributions for any other purpose.
|
||||
|
||||
If you have not already done so, please complete and sign, then scan and email a PDF file of this Agreement to: **xcat-legal@lists.sourceforge.net**.
|
||||
If you have not already done so, complete and sign, then scan and email a PDF file of this Agreement to: **xcat-legal@lists.sourceforge.net**.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
Global Configuration
|
||||
====================
|
||||
|
||||
All the xCAT global configurations are stored in site table, xCAT Admin can adjust the configuration by modifing the site attibute with ``tabedit``.
|
||||
All the xCAT global configurations are stored in site table, xCAT Admin can adjust the configuration by modifying the site attribute with ``tabedit``.
|
||||
|
||||
This section only presents some key global configurations, for the complete reference on the xCAT global configurations, please refer to the ``tabdump -d site``.
|
||||
This section only presents some key global configurations, for the complete reference on the xCAT global configurations, refer to the ``tabdump -d site``.
|
||||
|
||||
|
||||
Database Attributes
|
||||
@ -71,7 +71,7 @@ Install/Deployment Attributes
|
||||
The local directory name used to hold the node deployment packages.
|
||||
|
||||
* runbootscripts:
|
||||
If set to ``yes`` the scripts listed in the postbootscripts attribute in the osimage and postscripts tables will be run during each reboot of stateful (diskful) nodes. This attribute has no effect on stateless nodes. Please run the following command after you change the value of this attribute ::
|
||||
If set to ``yes`` the scripts listed in the postbootscripts attribute in the osimage and postscripts tables will be run during each reboot of stateful (diskful) nodes. This attribute has no effect on stateless nodes. Run the following command after you change the value of this attribute ::
|
||||
|
||||
updatenode <nodes> -P setuppostbootscripts
|
||||
|
||||
@ -83,9 +83,9 @@ Install/Deployment Attributes
|
||||
|
||||
'0': disable debug mode
|
||||
'1': enable basic debug mode
|
||||
'2': enalbe expert debug mode
|
||||
'2': enable expert debug mode
|
||||
|
||||
For the details on 'basic debug mode' and 'expert debug mode', please refer to xCAT documentation.
|
||||
For the details on 'basic debug mode' and 'expert debug mode', refer to xCAT documentation.
|
||||
|
||||
|
||||
Remoteshell Attributes
|
||||
|
||||
@ -19,7 +19,7 @@ For a cluster, several networks are necessary to enable the cluster management a
|
||||
|
||||
* DHCP(Dynamic Host Configuration Protocol)
|
||||
|
||||
The dhcp server, usually the management node or service node, privides the dhcp service for the entire cluster.
|
||||
The dhcp server, usually the management node or service node, provides the dhcp service for the entire cluster.
|
||||
|
||||
* TFTP(Trivial File Transfer Protocol)
|
||||
|
||||
|
||||
@ -54,7 +54,7 @@ It is important to note that some HA-related software like DRDB, Pacemaker, and
|
||||
HA Service Nodes
|
||||
````````````````
|
||||
|
||||
When you have NFS-based diskless (statelite) nodes, there is sometimes the motivation make the NFS serving highly available among all of the service nodes. This is not recommended because it is a very complex configuration. In our opinion, the complexity of this setup can nullify much of the availibility you hope to gain. If you need your compute nodes to be highly available, you should strongly consider stateful or stateless nodes.
|
||||
When you have NFS-based diskless (statelite) nodes, there is sometimes the motivation make the NFS serving highly available among all of the service nodes. This is not recommended because it is a very complex configuration. In our opinion, the complexity of this setup can nullify much of the availability you hope to gain. If you need your compute nodes to be highly available, you should strongly consider stateful or stateless nodes.
|
||||
|
||||
If you still have reasons to pursue HA service nodes:
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
xCAT Cluster OS Running Type
|
||||
============================
|
||||
|
||||
Whether a node is a pyhsical server or a virtual machine, it needs to run an Operating System to support user applications. Generally, the OS is installed in the hard disk of the compute node. But xCAT also support the type that running OS in the RAM.
|
||||
Whether a node is a physical server or a virtual machine, it needs to run an Operating System to support user applications. Generally, the OS is installed in the hard disk of the compute node. But xCAT also support the type that running OS in the RAM.
|
||||
|
||||
This section gives the pros and cons of each OS running type, and describes the cluster characteristics that will impact from each.
|
||||
|
||||
@ -32,7 +32,7 @@ Nodes boot from a RAMdisk OS image downloaded from the xCAT mgmt node or service
|
||||
|
||||
You can't use a large image with many different applications in the image for varied users, because it uses too much of the node's memory to store the ramdisk. (To mitigate this disadvantage, you can put your large application binaries and libraries in shared storage to reduce the ramdisk size. This requires some manual configuration of the image).
|
||||
|
||||
Each node can also have a local "scratch" disk for ``swap``, ``/tmp``, ``/var``, ``log`` files, dumps, etc. The purpose of the scratch disk is to provide a location for files that are written to by the node that can become quite large or for files that you don't want to disappear when the node reboots. There should be nothing put on the scratch disk that represents the node's "state", so that if the disk fails you can simply replace it and reboot the node. A scratch disk would typically be used for situations like: job scheduling preemption is required (which needs a lot of swap space), the applications write large temp files, or you want to keep gpfs log or trace files persistently. (As a partial alternative to using the scratch disk, customers can choose to put ``/tmp`` ``/var/tmp``, and log files (except GPFS logs files) in GPFS, but must be willing to accept the dependency on GPFS). This can be done by enabling the 'localdisk' support. For the details, please refer to the section [TODO Enabling the localdisk Option].
|
||||
Each node can also have a local "scratch" disk for ``swap``, ``/tmp``, ``/var``, ``log`` files, dumps, etc. The purpose of the scratch disk is to provide a location for files that are written to by the node that can become quite large or for files that you don't want to disappear when the node reboots. There should be nothing put on the scratch disk that represents the node's "state", so that if the disk fails you can simply replace it and reboot the node. A scratch disk would typically be used for situations like: job scheduling preemption is required (which needs a lot of swap space), the applications write large temp files, or you want to keep gpfs log or trace files persistently. (As a partial alternative to using the scratch disk, customers can choose to put ``/tmp`` ``/var/tmp``, and log files (except GPFS logs files) in GPFS, but must be willing to accept the dependency on GPFS). This can be done by enabling the 'localdisk' support. For the details, refer to the section [TODO Enabling the localdisk Option].
|
||||
|
||||
|
||||
OSimage Definition
|
||||
|
||||
@ -40,7 +40,7 @@ For a complete reference, see the man page for xcatdb: ``man xcatdb``.
|
||||
|
||||
**Manipulate xCAT Database Tables**
|
||||
|
||||
xCAT offers 5 commands to manipulate the databse tables:
|
||||
xCAT offers 5 commands to manipulate the database tables:
|
||||
|
||||
* ``tabdump``
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@ Another example is if "node1" is assigned the IP address "10.0.0.1", node2 is as
|
||||
#node,ip,hostnames,otherinterfaces,comments,disable
|
||||
"compute","|node(\d+)|10.0.0.($1+0)|",,,,
|
||||
|
||||
In this example, the regular expression in the ``ip`` attribute uses ``|`` to separate the 1st and 2nd part. This means that xCAT will allow arithmetic operations in the 2nd part. In the 1st part, ``(\d+)``, will match the number part of the node name and put that in a variable called ``$1``. The 2nd part is what value to give the ``ip`` attribute. In this case it will set it to the string "10.0.0." and the number that is in ``$1``. (Zero is added to ``$1`` just to remove any leading zeroes.)
|
||||
In this example, the regular expression in the ``ip`` attribute uses ``|`` to separate the 1st and 2nd part. This means that xCAT will allow arithmetic operations in the 2nd part. In the 1st part, ``(\d+)``, will match the number part of the node name and put that in a variable called ``$1``. The 2nd part is what value to give the ``ip`` attribute. In this case it will set it to the string "10.0.0." and the number that is in ``$1``. (Zero is added to ``$1`` just to remove any leading zeros.)
|
||||
|
||||
A more involved example is with the ``vm`` table. If your kvm nodes have node names c01f01x01v01, c01f02x03v04, etc., and the kvm host names are c01f01x01, c01f02x03, etc., then you might have an ``vm`` table like ::
|
||||
|
||||
@ -45,14 +45,14 @@ Before you panic, let me explain each column:
|
||||
|
||||
``|\D+(\d+)\D+(\d+)\D+(\d+)\D+(\d+)|dir:///install/vms/vm($4+0)|``
|
||||
|
||||
This item is similar to the one above. This substituion pattern will produce the value for the 5th column (a list of storage files or devices to be used). Because this row was the match for "c01f02x03v04", the produced value is "dir:///install/vms/vm4".
|
||||
This item is similar to the one above. This substitution pattern will produce the value for the 5th column (a list of storage files or devices to be used). Because this row was the match for "c01f02x03v04", the produced value is "dir:///install/vms/vm4".
|
||||
|
||||
Just as the explained above, when the node definition "c01f02x03v04" is created with ::
|
||||
|
||||
# mkdef -t node -o c01f02x03v04 groups=kvms
|
||||
1 object definitions have been created or modified.
|
||||
|
||||
The generated node deinition is ::
|
||||
The generated node definition is ::
|
||||
|
||||
# lsdef c01f02x03v04
|
||||
Object name: c01f02x03v04
|
||||
|
||||
@ -67,7 +67,7 @@ You can get the detail description of each object by ``man <object type>`` e.g.
|
||||
|
||||
* **group Object**
|
||||
|
||||
**group** is an object which includes multiple **node object**. When you set **group** attribute for a **node object** to a group name like **x86_64**, the group **x86_64** is automatically genereated and the node is assigned to the group.
|
||||
**group** is an object which includes multiple **node object**. When you set **group** attribute for a **node object** to a group name like **x86_64**, the group **x86_64** is automatically generated and the node is assigned to the group.
|
||||
|
||||
The benefits of using **group object**:
|
||||
|
||||
|
||||
@ -18,15 +18,15 @@ The paralell compression tool ``pigz`` can be enabled by installing ``pigz`` pac
|
||||
|
||||
EPEL has an ``epel-release`` package that includes gpg keys for package signing and repository information. Installing this package for your Enterprise Linux version should allow you to use normal tools such as ``yum`` to install packages and their dependencies.
|
||||
|
||||
Please refer to the http://fedoraproject.org/wiki/EPEL for more details on EPEL
|
||||
Refer to the http://fedoraproject.org/wiki/EPEL for more details on EPEL
|
||||
|
||||
1) Enabling the ``pigz`` in ``genimage`` (only supported in RHELS6 or above)
|
||||
|
||||
``pigz`` should be installed in the diskless rootimg. Please download ``pigz`` package from https://dl.fedoraproject.org/pub/epel/ , then customize the diskless osimage to install ``pigz`` as the additional packages, see :doc:`Install Additional Other Packages</guides/admin-guides/manage_clusters/ppc64le/diskless/customize_image/additional_pkg>` for more details.
|
||||
``pigz`` should be installed in the diskless rootimg. Download ``pigz`` package from https://dl.fedoraproject.org/pub/epel/ , then customize the diskless osimage to install ``pigz`` as the additional packages, see :doc:`Install Additional Other Packages</guides/admin-guides/manage_clusters/ppc64le/diskless/customize_image/additional_pkg>` for more details.
|
||||
|
||||
2) Enabeling the ``pigz`` in ``packimage``
|
||||
|
||||
``pigz`` should be installed on the management server. Please download ``pigz`` package from https://dl.fedoraproject.org/pub/epel/ , then install the ``pigz`` with ``yum`` or ``rpm``.
|
||||
``pigz`` should be installed on the management server. Download ``pigz`` package from https://dl.fedoraproject.org/pub/epel/ , then install the ``pigz`` with ``yum`` or ``rpm``.
|
||||
|
||||
* **[UBUNTU]**
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ If you have newer updates to some of your operating system packages that you wou
|
||||
createrepo .
|
||||
chdef -t osimage <os>-<arch>-<inst_type>-<profile> pkgdir=/install/<os>/<arch>,/install/osupdates/<os>/<arch>
|
||||
|
||||
Note:If the objective node is not installed by xCAT,please make sure the correct osimage pkgdir attribute so that you could get the correct repository data.
|
||||
Note:If the objective node is not installed by xCAT, make sure the correct osimage pkgdir attribute so that you could get the correct repository data.
|
||||
|
||||
.. _File-Format-for-pkglist-label:
|
||||
|
||||
|
||||
@ -72,7 +72,7 @@ Here is partition definition file example for RedHat LVM partition in IBM Power
|
||||
|
||||
.. BEGIN_partition_definition_file_example_RedHat_RAID1_for_IBM_Power_machines
|
||||
|
||||
Partition definition file example for RedHat RAID1 please refer to :doc:`Configure RAID before Deploy OS </guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/raid_cfg>`
|
||||
To partition definition file example for RedHat RAID1 refer to :doc:`Configure RAID before Deploy OS </guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/raid_cfg>`
|
||||
|
||||
.. END_partition_definition_file_example_RedHat_RAID1_for_IBM_Power_machines
|
||||
|
||||
@ -287,7 +287,7 @@ Here is partition definition file example for SLES standard partition in ppc64 m
|
||||
|
||||
.. BEGIN_partition_definition_file_example_SLES_RAID1
|
||||
|
||||
Partition definition file example for SLES RAID1 please refer to `Configure RAID before Deploy OS <http://xcat-docs.readthedocs.org/en/latest/guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/raid_cfg.html>`_
|
||||
To partition definition file example for SLES RAID1 refer to `Configure RAID before Deploy OS <http://xcat-docs.readthedocs.org/en/latest/guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/raid_cfg.html>`_
|
||||
|
||||
.. END_partition_definition_file_example_SLES_RAID1
|
||||
|
||||
|
||||
@ -90,12 +90,12 @@ Other information about the network should be defined in the ``networks`` table.
|
||||
Use the ``tabedit`` command to add/modify the networks in the``networks`` table ::
|
||||
|
||||
tabdump networks
|
||||
#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,comments,disable
|
||||
#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,mtu,comments,disable
|
||||
...
|
||||
"net11", "11.1.89.0", "255.255.255.0", "eth1",,,,,,,,,,,,,,,
|
||||
"net12", "12.1.89.0", "255.255.255.0", "eth1",,,,,,,,,,,,,,,
|
||||
"net13", "13.1.89.0", "255.255.255.0", "eth2",,,,,,,,,,,,,,,
|
||||
"net14", "14.1.89.0", "255.255.255.0", "eth2",,,,,,,,,,,,,,,
|
||||
"net11", "11.1.89.0", "255.255.255.0", "eth1",,,,,,,,,,,,,,,,
|
||||
"net12", "12.1.89.0", "255.255.255.0", "eth1",,,,,,,,,,,,,,,,
|
||||
"net13", "13.1.89.0", "255.255.255.0", "eth2",,,,,,,,,,,,,,,,
|
||||
"net14", "14.1.89.0", "255.255.255.0", "eth2",,,,,,,,,,,,,,,,
|
||||
|
||||
Option -r to remove the undefined NICS
|
||||
--------------------------------------
|
||||
|
||||
@ -53,6 +53,8 @@ For ubuntu ppc64le, the initrd.gz shipped with the ISO does not support network
|
||||
|
||||
[ubuntu 16.04]: http://xcat.org/files/netboot/ubuntu16.04/ppc64el/mini.iso
|
||||
|
||||
[ubuntu 16.04.1]: http://xcat.org/files/netboot/ubuntu16.04.1/ppc64el/mini.iso
|
||||
|
||||
* Mount mini.iso ::
|
||||
|
||||
mkdir /tmp/iso
|
||||
@ -61,7 +63,7 @@ For ubuntu ppc64le, the initrd.gz shipped with the ISO does not support network
|
||||
* Copy the netboot initrd.gz to osimage ::
|
||||
|
||||
mkdir -p /install/<ubuntu-version>/ppc64el/install/netboot
|
||||
cp /tmp/iso/install/initrd.gz /install/<ubuntu-version>/ppc64el/installe/netboot
|
||||
cp /tmp/iso/install/initrd.gz /install/<ubuntu-version>/ppc64el/install/netboot
|
||||
|
||||
**[Below tips maybe helpful for you]**
|
||||
|
||||
|
||||
@ -150,7 +150,7 @@ Currently, only NFS is supported for the setup of kdump.
|
||||
|
||||
If the dump attribute is not set, the kdump service will not be enabled.
|
||||
|
||||
Please make sure the NFS remote path(nfs://<nfs_server_ip>/<kdump_path>) is exported and it is read-writeable to the node where kdump service is enabled.
|
||||
Make sure the NFS remote path(nfs://<nfs_server_ip>/<kdump_path>) is exported and it is read-writeable to the node where kdump service is enabled.
|
||||
|
||||
How to trigger kernel panic on Linux
|
||||
------------------------------------
|
||||
@ -163,11 +163,7 @@ Normally, kernel panic() will trigger booting into capture kernel. Once the kern
|
||||
|
||||
#. For SLES10 the directory is <kdump_path>/<node hostname>
|
||||
|
||||
For RHELS6 testing purposes, you can simulate the trigger through /proc interface: ::
|
||||
|
||||
echo c > /proc/sysrq-trigger
|
||||
|
||||
For SLES11.1 testing, you can use the following commands: ::
|
||||
For Redhat and SLES11.1 testing, you can use the following commands: ::
|
||||
|
||||
echo 1 > /proc/sys/kernel/sysrq
|
||||
echo c > /proc/sysrq-trigger
|
||||
|
||||
@ -104,7 +104,7 @@ Skip this section if you want to use the image as is.
|
||||
|
||||
* Modify .pkglist file to add or remove packges that are from the os distro
|
||||
|
||||
* Modify .otherpkgs.pkglist to add or remove packages from other sources. Please refer to ``Using_Updatenode`` for details
|
||||
* Modify .otherpkgs.pkglist to add or remove packages from other sources. Refer to ``Using_Updatenode`` for details
|
||||
|
||||
* For diskful, modify the .tmpl file to change the kickstart/autoyast configuration
|
||||
|
||||
|
||||
@ -586,11 +586,11 @@ This is an example of the generated postscript for a servicenode install. It is
|
||||
export ENABLESSHBETWEENNODES
|
||||
NETWORKS_LINES=4
|
||||
export NETWORKS_LINES
|
||||
NETWORKS_LINE1='netname=public_net||net=8.112.154.64||mask=255.255.255.192||mgtifname=eth0||gateway=8.112.154.126||dhcpserver=||tftpserver=8.112.154.69||nameservers=8.112.8.1||ntpservers=||logservers=||dynamicrange=||staticrange=||staticrangeincrement=||nodehostname=||ddnsdomain=||vlanid=||domain=||disable=||comments='
|
||||
NETWORKS_LINE1='netname=public_net||net=8.112.154.64||mask=255.255.255.192||mgtifname=eth0||gateway=8.112.154.126||dhcpserver=||tftpserver=8.112.154.69||nameservers=8.112.8.1||ntpservers=||logservers=||dynamicrange=||staticrange=||staticrangeincrement=||nodehostname=||ddnsdomain=||vlanid=||domain=||mtu=||disable=||comments='
|
||||
export NETWORKS_LINE2
|
||||
NETWORKS_LINE3='netname=sn21_net||net=10.2.1.0||mask=255.255.255.0||mgtifname=eth1||gateway=<xcatmaster>||dhcpserver=||tftpserver=||nameservers=10.2.1.100,10.2.1.101||ntpservers=||logservers=||dynamicrange=||staticrange=||staticrangeincrement=||nodehostname=||ddnsdomain=||vlanid=||domain=||disable=||comments='
|
||||
NETWORKS_LINE3='netname=sn21_net||net=10.2.1.0||mask=255.255.255.0||mgtifname=eth1||gateway=<xcatmaster>||dhcpserver=||tftpserver=||nameservers=10.2.1.100,10.2.1.101||ntpservers=||logservers=||dynamicrange=||staticrange=||staticrangeincrement=||nodehostname=||ddnsdomain=||vlanid=||domain=||mtu=||disable=||comments='
|
||||
export NETWORKS_LINE3
|
||||
NETWORKS_LINE4='netname=sn22_net||net=10.2.2.0||mask=255.255.255.0||mgtifname=eth1||gateway=10.2.2.100||dhcpserver=10.2.2.100||tftpserver=10.2.2.100||nameservers=10.2.2.100||ntpservers=||logservers=||dynamicrange=10.2.2.120-10.2.2.250||staticrange=||staticrangeincrement=||nodehostname=||ddnsdomain=||vlanid=||domain=||disable=||comments='
|
||||
NETWORKS_LINE4='netname=sn22_net||net=10.2.2.0||mask=255.255.255.0||mgtifname=eth1||gateway=10.2.2.100||dhcpserver=10.2.2.100||tftpserver=10.2.2.100||nameservers=10.2.2.100||ntpservers=||logservers=||dynamicrange=10.2.2.120-10.2.2.250||staticrange=||staticrangeincrement=||nodehostname=||ddnsdomain=||vlanid=||domain=||mtu=||disable=||comments='
|
||||
export NETWORKS_LINE4
|
||||
NODE=xcatsn23
|
||||
export NODE
|
||||
|
||||
@ -109,7 +109,7 @@ To create the virtual machine "vm1" with 20G hard disk on a hypervisor directory
|
||||
|
||||
mkvm vm1 -s 20G
|
||||
|
||||
When "vm1" is created successfully, a VM hard disk file with a name like "vm1.sda.qcow2" will be found in the location specified by **vmstorage**. What's more, the **mac** attribute of "vm1" is set automatically, please check it with: ::
|
||||
When "vm1" is created successfully, a VM hard disk file with a name like "vm1.sda.qcow2" will be found in the location specified by **vmstorage**. What's more, the **mac** attribute of "vm1" is set automatically, check it with: ::
|
||||
|
||||
lsdef vm1 -i mac
|
||||
|
||||
@ -132,7 +132,7 @@ or running the following command on the kvm hypervisor "kvmhost1" ::
|
||||
Monitoring the Virtual Machine
|
||||
``````````````````````````````
|
||||
|
||||
When the VM has been created and powered on, please choose one of the following methods to monitor and access it.
|
||||
When the VM has been created and powered on, choose one of the following methods to monitor and access it.
|
||||
|
||||
* Open the console on kvm hypervisor: ::
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ Installing Additional OS Distro Packages
|
||||
|
||||
For packages from the OS distro, add the new package names (without the version number) in the .pkglist file. If you have newer updates to some of your operating system packages that you would like to apply to your OS image, you can place them in another directory, and add that directory to your osimage pkgdir attribute. How to add additional OS distro packages, go to :ref:`Install-Additional-OS-Packages-label`
|
||||
|
||||
Note:If the objective node is not installed by xCAT, please make sure the correct osimage pkgdir attribute so that you could get the correct repository data.
|
||||
Note:If the objective node is not installed by xCAT, make sure the correct osimage pkgdir attribute so that you could get the correct repository data.
|
||||
|
||||
Install Additional non-OS Packages
|
||||
``````````````````````````````````
|
||||
@ -132,8 +132,8 @@ Linux: xdsh <noderange> -e /install/postscripts/xcatdsklspost -m <server> <scrip
|
||||
where <scripts> is a comma separated postscript like ospkgs,otherpkgs etc.
|
||||
|
||||
* wget is used in xcatdsklspost/xcataixpost to get all the postscripts from the <server> to the node. You can check /tmp/wget.log file on the node to see if wget was successful or not. You need to make sure the /xcatpost directory has enough space to hold the postscripts.
|
||||
* A file called /xcatpost/mypostscript (Linux) is created on the node which contains the environmental variables and scripts to be run. Please make sure this file exists and it contains correct info. You can also run this file on the node manually to debug.
|
||||
* For ospkgs/otherpkgs, if /install is not mounted on the <server>, it will download all the rpms from the <server> to the node using wget. Please make sure /tmp and /xcatpost have enough space to hold the rpms and please check /tmp/wget.log for errors.
|
||||
* For ospkgs/otherpkgs, If zypper or yum is installed on the node, it will be used the command to install the rpms. Please make sure to run createrepo on the source direcory on the <server> every time a rpm is added or removed. Otherwise, the rpm command will be used, in this case, please make sure all the necessary depended rpms are copied in the same source directory.
|
||||
* A file called /xcatpost/mypostscript (Linux) is created on the node which contains the environmental variables and scripts to be run. Make sure this file exists and it contains correct info. You can also run this file on the node manually to debug.
|
||||
* For ospkgs/otherpkgs, if /install is not mounted on the <server>, it will download all the rpms from the <server> to the node using wget. Make sure /tmp and /xcatpost have enough space to hold the rpms and check /tmp/wget.log for errors.
|
||||
* For ospkgs/otherpkgs, If zypper or yum is installed on the node, it will be used the command to install the rpms. Make sure to run createrepo on the source direcory on the <server> every time a rpm is added or removed. Otherwise, the rpm command will be used, in this case, make sure all the necessary depended rpms are copied in the same source directory.
|
||||
* You can append -x on the first line of ospkgs/otherpkgs to get more debug info.
|
||||
|
||||
|
||||
@ -4,9 +4,9 @@ Set attributes in the ``networks`` table
|
||||
#. Display the network settings defined in the xCAT ``networks`` table using: ``tabdump networks`` ::
|
||||
|
||||
#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,
|
||||
dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,
|
||||
dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,mtu,
|
||||
comments,disable
|
||||
"10_0_0_0-255_0_0_0","10.0.0.0","255.0.0.0","eth0","10.0.0.101",,"10.4.27.5",,,,,,,,,,,,
|
||||
"10_0_0_0-255_0_0_0","10.0.0.0","255.0.0.0","eth0","10.0.0.101",,"10.4.27.5",,,,,,,,,,,,,
|
||||
|
||||
A default network is created for the detected primary network using the same netmask and gateway. There may be additional network entries in the table for each network present on the management node where xCAT is installed.
|
||||
|
||||
|
||||
@ -8,9 +8,9 @@ Configure network table
|
||||
Normally, there will be at least two entries for the two subnet on MN in ``networks`` table after xCAT is installed::
|
||||
|
||||
#tabdump networks
|
||||
#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,comments,disable
|
||||
"10_0_0_0-255_255_0_0","10.0.0.0","255.255.0.0","eth1","<xcatmaster>",,"10.0.1.1",,,,,,,,,,,,
|
||||
"50_0_0_0-255_255_0_0","50.0.0.0","255.255.0.0","eth2","<xcatmaster>",,"50.0.1.1",,,,,,,,,,,,
|
||||
#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,mtu,comments,disable
|
||||
"10_0_0_0-255_255_0_0","10.0.0.0","255.255.0.0","eth1","<xcatmaster>",,"10.0.1.1",,,,,,,,,,,,,
|
||||
"50_0_0_0-255_255_0_0","50.0.0.0","255.255.0.0","eth2","<xcatmaster>",,"50.0.1.1",,,,,,,,,,,,,
|
||||
|
||||
Run the following command to add networks in ``networks`` table if there are no entries in it::
|
||||
|
||||
|
||||
@ -27,11 +27,11 @@ The BMC IP address is obtained by the open range dhcp server and the plan in thi
|
||||
|
||||
#. Detect the BMCs and add the node definitions into xCAT.
|
||||
|
||||
Use the ``bmcdiscover`` command to discover the BMCs responding over an IP range and automatically write the output into the xCAT database. You **must** use the ``-t`` option to indicate node type is bmc and the ``-w`` option to automatically write the output into the xCAT database.
|
||||
Use the ``bmcdiscover`` command to discover the BMCs responding over an IP range and automatically write the output into the xCAT database. You **must** use the ``-w`` option to automatically write the output into the xCAT database.
|
||||
|
||||
To discover the BMC with an IP address of 172.30.0.1, use the command: ::
|
||||
|
||||
bmcdiscover --range 172.30.0.1 -t -z -w
|
||||
bmcdiscover --range 172.30.0.1 -z -w
|
||||
|
||||
The discovered nodes will be written to xCAT database: ::
|
||||
|
||||
@ -47,6 +47,7 @@ The BMC IP address is obtained by the open range dhcp server and the plan in thi
|
||||
postbootscripts=otherpkgs
|
||||
postscripts=syslog,remoteshell,syncfiles
|
||||
serial=10112CA
|
||||
nodetype=mp
|
||||
|
||||
|
||||
#. **Pre-define** the compute nodes:
|
||||
@ -84,6 +85,8 @@ The BMC IP address is obtained by the open range dhcp server and the plan in thi
|
||||
|
||||
ip=10.1.2.1
|
||||
|
||||
#. Remove ``nodetype`` and ``hwtype`` if defined in the ``predefined.stanza``.
|
||||
|
||||
#. Repeat for additional nodes in the ``predefined.stanza`` file based on the MTMS mapping.
|
||||
|
||||
|
||||
@ -105,6 +108,9 @@ The BMC IP address is obtained by the open range dhcp server and the plan in thi
|
||||
|
||||
chdef cn01 chain="runcmd=bmcsetup"
|
||||
|
||||
#. Set the target `osimage` into the chain table to automatically provision the operating system after the node discovery is complete. ::
|
||||
|
||||
chdef cn01 -p chain="osimage=<osimage_name>"
|
||||
|
||||
#. Change the BMC IP address
|
||||
|
||||
|
||||
@ -82,6 +82,10 @@ The BMC IP address is obtained by the open range dhcp server and the plan is to
|
||||
|
||||
chdef cn01 chain="runcmd=bmcsetup"
|
||||
|
||||
#. Set the target `osimage` into the chain table to automatically provision the operating system after the node discovery is complete. ::
|
||||
|
||||
chdef cn01 -p chain="osimage=<osimage_name>"
|
||||
|
||||
#. Define the compute nodes into xCAT: ::
|
||||
|
||||
cat predefined.stanzas | mkdef -z
|
||||
|
||||
@ -22,7 +22,7 @@ The discovered PBMC node will be like this::
|
||||
postscripts=syslog,remoteshell,syncfiles
|
||||
serial=10112CA
|
||||
|
||||
**Note**: Pls note that the PBMC node is just used to control the physical during hardware discovery process, it will be deleted after the correct server node object is found.
|
||||
**Note**: Note that the PBMC node is just used to control the physical during hardware discovery process, it will be deleted after the correct server node object is found.
|
||||
|
||||
Start discovery process
|
||||
-----------------------
|
||||
|
||||
@ -5,7 +5,7 @@ After environment is ready, and the server is powered, we can start server disco
|
||||
|
||||
The following command can be used to discovery BMC within an IP range and write the discovered node definition into xCAT database::
|
||||
|
||||
bmcdiscover -s nmap --range 50.0.100.1-100 -t -z -w
|
||||
bmcdiscover -s nmap --range 50.0.100.1-100 -z -w
|
||||
|
||||
The discovered BMC node will be like this::
|
||||
|
||||
@ -27,7 +27,7 @@ The discovered BMC node will be like this::
|
||||
|
||||
2. bmcdiscover will use username/password pair set in ``passwd`` table with **key** equal **ipmi**. If you'd like to use other username/password pair, you can use ::
|
||||
|
||||
bmcdiscover -s nmap --range 50.0.100.1-100 -t -z -w -u <username> -p <password>
|
||||
bmcdiscover -s nmap --range 50.0.100.1-100 -z -w -u <username> -p <password>
|
||||
|
||||
Start discovery process
|
||||
-----------------------
|
||||
|
||||
@ -18,10 +18,16 @@ Predefine a group of nodes with desired IP address for host and IP address for F
|
||||
nodeadd cn1 groups=powerLE,all
|
||||
chdef cn1 mgt=ipmi cons=ipmi ip=10.0.101.1 bmc=50.0.101.1 netboot=petitboot installnic=mac primarynic=mac
|
||||
|
||||
In order to do BMC configuration during the discovery process, set ``runcmd=bmcsetup``. For more info about chain, please refer to :doc:`Chain <../../../../../advanced/chain/index>` ::
|
||||
In order to do BMC configuration during the discovery process, set ``runcmd=bmcsetup``. ::
|
||||
|
||||
chdef cn1 chain="runcmd=bmcsetup"
|
||||
|
||||
Set the target `osimage` into the chain table to automatically provision the operating system after the node discovery is complete. ::
|
||||
|
||||
chdef cn1 -p chain="osimage=<osimage_name>"
|
||||
|
||||
For more information about chain, refer to :doc:`Chain <../../../../../advanced/chain/index>`
|
||||
|
||||
Initialize the discovery process
|
||||
````````````````````````````````
|
||||
|
||||
|
||||
@ -54,10 +54,16 @@ After switches are defined, the server node can be predefined with the following
|
||||
chdef cn1 mgt=ipmi cons=ipmi ip=10.0.101.1 bmc=50.0.101.1 netboot=petitboot installnic=mac primarynic=mac
|
||||
chdef cn1 switch=switch1 switchport=0
|
||||
|
||||
In order to do BMC configuration during the discovery process, set ``runcmd=bmcsetup``. For more info about chain, please refer to :doc:`Chain <../../../../../advanced/chain/index>` ::
|
||||
In order to do BMC configuration during the discovery process, set ``runcmd=bmcsetup``. ::
|
||||
|
||||
chdef cn1 chain="runcmd=bmcsetup"
|
||||
|
||||
Set the target `osimage` into the chain table to automatically provision the operating system after the node discovery is complete. ::
|
||||
|
||||
chdef cn1 -p chain="osimage=<osimage_name>"
|
||||
|
||||
For more information about chain, refer to :doc:`Chain <../../../../../advanced/chain/index>`
|
||||
|
||||
Add cn1 into DNS::
|
||||
|
||||
makehosts cn1
|
||||
|
||||
@ -14,7 +14,7 @@ With xCAT, the end user can turn the beacon light on or off with the commands sh
|
||||
rbeacon cn1 on
|
||||
rbeacon cn1 off
|
||||
|
||||
Please notice, the current state of the beacon light can not be inquery remotely. As a workaround, one can always use the ``rbeacon`` command to turn all the beacon lights in one frame off, and then turn a particular beancon light on. ::
|
||||
The current state of the beacon light can not be queried remotely. As a workaround, one can always use the ``rbeacon`` command to turn all the beacon lights in one frame off, and then turn a particular beacon light on. ::
|
||||
|
||||
rbeacon a_group_of_cn off
|
||||
rbeacon cn5 on
|
||||
@ -35,7 +35,7 @@ Or do a hardware reset, run ::
|
||||
|
||||
rpower cn1 reset
|
||||
|
||||
Get the current rpower state of a machine, please refer to the example below. ::
|
||||
Get the current rpower state of a machine, refer to the example below. ::
|
||||
|
||||
# rpower cn1 state
|
||||
cn1: Running
|
||||
@ -80,16 +80,16 @@ To get all the hardware information, which including the model type, serial numb
|
||||
|
||||
rinv cn1 all
|
||||
|
||||
As an example, in order to get only the information of firmware version, the follwing command can be used. ::
|
||||
As an example, in order to get only the information of firmware version, the following command can be used. ::
|
||||
|
||||
rinv cn1 firm
|
||||
|
||||
Remote Hardware Vitals
|
||||
``````````````````````
|
||||
|
||||
Collect runtime information from running physical machine is also a big requirement for real life system administrators. This kind of information includes, temperature of CPU, internal voltage of paricular socket, wattage with workload, speed of cooling fan, et al.
|
||||
Collect runtime information from running physical machine is also a big requirement for real life system administrators. This kind of information includes, temperature of CPU, internal voltage of particular socket, wattage with workload, speed of cooling fan, et al.
|
||||
|
||||
In order to get such information, please use ``rvitals`` command. Please also notice, this kind of information various among different model types of the machine. Thus, please check the actual output of the ``rvitals`` command against your machine, to verify which kinds of information can be get. The information may change due to the firmware updating of the machine. ::
|
||||
In order to get such information, use ``rvitals`` command. This kind of information varies among different model types of the machine. Thus, check the actual output of the ``rvitals`` command against your machine, to verify which kinds of information can be extracted. The information may change after the firmware update of the machine. ::
|
||||
|
||||
rvitals cn1 all
|
||||
|
||||
@ -115,7 +115,7 @@ Update node firmware to the version of the HPM file
|
||||
Configures Nodes' Service Processors
|
||||
````````````````````````````````````
|
||||
|
||||
Here comes the command, ``rspconfig``. It is used to configure the service processor of a physical machine. On a OpenPower system, the service processor is the BMC, Baseboard Management Controller. Various variables can be set through the command. But, please also notice, the actual configuration may change among different machine-model types.
|
||||
Here comes the command, ``rspconfig``. It is used to configure the service processor of a physical machine. On a OpenPower system, the service processor is the BMC, Baseboard Management Controller. Various variables can be set through the command. Also notice, the actual configuration may change among different machine-model types.
|
||||
|
||||
Examples
|
||||
|
||||
|
||||
@ -28,7 +28,7 @@ rpower fails with "Error: internal error Process exited while reading console lo
|
||||
|
||||
Then restart the NFS services and try to power on the VM again...
|
||||
|
||||
**Note**: For stateless hypervisor, please purge the VM by ``rmvm -p vm1``, reboot the hypervisor and then create the VM.
|
||||
**Note**: For stateless hypervisor, purge the VM by ``rmvm -p vm1``, reboot the hypervisor and then create the VM.
|
||||
|
||||
rpower fails with "Error: internal error: process exited while connecting to monitor qemu: Permission denied"
|
||||
-------------------------------------------------------------------------------------------------------------
|
||||
@ -77,7 +77,7 @@ Error: Cannot communicate via libvirt to kvmhost1
|
||||
The kvm related commands complain "Error: Cannot communicate via libvirt to kvmhost1"
|
||||
|
||||
**Solution**:
|
||||
Usually caused by incorrect ssh configuration between xCAT management node and hypervisor. Please make sure it is possible to access the hypervisor from management node via ssh without password.
|
||||
Usually caused by incorrect ssh configuration between xCAT management node and hypervisor. Make sure it is possible to access the hypervisor from management node via ssh without password.
|
||||
|
||||
|
||||
Fail to ping the installed VM
|
||||
@ -89,7 +89,7 @@ Fail to ping the installed VM
|
||||
ADDRCONF(NETDEV_UP): eth0 link is not ready.
|
||||
|
||||
**Solutoin**:
|
||||
Usually caused by the incorrect VM NIC model. Please try the following steps to specify "virtio": ::
|
||||
Usually caused by the incorrect VM NIC model. Try the following steps to specify "virtio": ::
|
||||
|
||||
rmvm vm1
|
||||
chdef vm1 vmnicnicmodel=virtio
|
||||
|
||||
@ -3,4 +3,4 @@ x86_64
|
||||
|
||||
This section is not available at this time.
|
||||
|
||||
Please refer to `xCAT Documentation <https://sourceforge.net/p/xcat/wiki/XCAT_Documentation/>`_ on SourceForge for information on System X servers.
|
||||
Refer to `xCAT Documentation <https://sourceforge.net/p/xcat/wiki/XCAT_Documentation/>`_ on SourceForge for information on System X servers.
|
||||
|
||||
@ -23,7 +23,7 @@ SYNOPSIS
|
||||
|
||||
\ **bmcdiscover**\ [\ **-v | -**\ **-version**\ ]
|
||||
|
||||
\ **bmcdiscover**\ [\ **-s**\ \ *scan_method*\ ] [\ **-u**\ \ *bmc_user*\ ] [\ **-p**\ \ *bmc_passwd*\ ] [\ **-z**\ ] [\ **-w**\ ] [\ **-t**\ ] \ **-**\ **-range**\ \ *ip_ranges*\
|
||||
\ **bmcdiscover**\ [\ **-s**\ \ *scan_method*\ ] [\ **-u**\ \ *bmc_user*\ ] [\ **-p**\ \ *bmc_passwd*\ ] [\ **-z**\ ] [\ **-w**\ ] \ **-**\ **-range**\ \ *ip_ranges*\
|
||||
|
||||
\ **bmcdiscover**\ \ **-u**\ \ *bmc_user*\ \ **-p**\ \ *bmc_passwd*\ \ **-i**\ \ *bmc_ip*\ \ **-**\ **-check**\
|
||||
|
||||
@ -74,12 +74,6 @@ OPTIONS
|
||||
|
||||
|
||||
|
||||
\ **-t**\
|
||||
|
||||
Generate a BMC type node object
|
||||
|
||||
|
||||
|
||||
\ **-i|-**\ **-bmcip**\
|
||||
|
||||
BMC IP address.
|
||||
|
||||
@ -47,7 +47,7 @@ OPTIONS
|
||||
|
||||
|
||||
|
||||
\ **-n|-**\ **-nodes**\ The nodes or groups to be added or removed. It takes the noderange format. Please check the man page for noderange for details.
|
||||
\ **-n|-**\ **-nodes**\ The nodes or groups to be added or removed. It takes the noderange format. Check the man page for noderange for details.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -62,7 +62,7 @@ VMware/KVM specific:
|
||||
====================
|
||||
|
||||
|
||||
\ **chvm**\ \ *noderange*\ [\ **-a**\ \ *size*\ ] [\ **-d**\ \ *disk*\ ] [\ **-p**\ \ *disk*\ ] [\ **-**\ **-resize**\ \ **disk**\ =\ *size*\ ] [\ **-**\ **-cpus**\ \ *count*\ ] [\ **-**\ **-mem**\ \ *memory*\ ]
|
||||
\ **chvm**\ \ *noderange*\ [\ **-a**\ \ *size*\ ] [\ **-d**\ \ *disk*\ ] [\ **-p**\ \ *disk*\ ] [\ **-**\ **-resize**\ \ *disk*\ =\ *size*\ ] [\ **-**\ **-cpus**\ \ *count*\ ] [\ **-**\ **-mem**\ \ *memory*\ ]
|
||||
|
||||
|
||||
zVM specific:
|
||||
@ -318,7 +318,7 @@ VMware/KVM specific:
|
||||
|
||||
\ **-d**\ \ *disk*\
|
||||
|
||||
Deregister the Hard disk but leave the backing files. Multiple can be done with comma separated values. The disks are specified by SCSI id. Size defaults to GB.
|
||||
Deregister the Hard disk but leave the backing files. Multiple can be done with comma separated values. The disks are specified by SCSI id.
|
||||
|
||||
|
||||
|
||||
@ -330,13 +330,13 @@ VMware/KVM specific:
|
||||
|
||||
\ **-p**\ \ *disk*\
|
||||
|
||||
Purge the Hard disk. Deregisters and deletes the files. Multiple can be done with comma separated values. The disks are specified by SCSI id. Size defaults to GB.
|
||||
Purge the Hard disk. Deregisters and deletes the files. Multiple can be done with comma separated values. The disks are specified by SCSI id.
|
||||
|
||||
|
||||
|
||||
\ **-**\ **-resize**\ \ **disk**\ =\ *size*\
|
||||
\ **-**\ **-resize**\ \ *disk*\ =\ *size*\
|
||||
|
||||
Change the size of the Hard disk. The disk can never be set to less than it's current size. Multiple disks can be resized to \ *size*\ by using comma separated values on the left side of \ **=**\ . The disks are specified by SCSI id. Size defaults to GB.
|
||||
Change the size of the Hard disk. The disk in \ *qcow2*\ format can not be set to less than it's current size. The disk in \ *raw*\ format can be resized smaller, use caution. Multiple disks can be resized by using comma separated \ *disk*\ \ **=**\ \ *size*\ pairs. The disks are specified by SCSI id. Size defaults to GB.
|
||||
|
||||
|
||||
|
||||
@ -838,7 +838,7 @@ The resource information after modification is similar to:
|
||||
lpar1: 128.
|
||||
|
||||
|
||||
Note: The physical I/O resources specified with \ *add_physlots*\ will be appended to the specified partition. The physical I/O resources which are not specified but belonged to the partition will not be removed. For more information about \ *add_physlots*\ , please refer to lsvm(1)|lsvm.1.
|
||||
Note: The physical I/O resources specified with \ *add_physlots*\ will be appended to the specified partition. The physical I/O resources which are not specified but belonged to the partition will not be removed. For more information about \ *add_physlots*\ , refer to lsvm(1)|lsvm.1.
|
||||
|
||||
|
||||
VMware/KVM specific:
|
||||
@ -976,6 +976,14 @@ Output is similar to:
|
||||
gpok3: Replacing user entry of LNX3... Done
|
||||
|
||||
|
||||
8. To resize virtual machine's disk sdb to 10G and sdc to 15G:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
chvm gpok3 --resize sdb=10G,sdc=15G
|
||||
|
||||
|
||||
|
||||
|
||||
*****
|
||||
|
||||
@ -46,7 +46,7 @@ for stateless: \ **packimage**\
|
||||
|
||||
for statelite: \ **liteimg**\
|
||||
|
||||
Besides prompting for some paramter values, the \ **genimage**\ command takes default guesses for the parameters not specified or not defined in the \ *osimage*\ and \ *linuximage*\ tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Please use \ **-**\ **-interactive**\ flag if you want the yum/zypper command to prompt you for the answers.
|
||||
Besides prompting for some paramter values, the \ **genimage**\ command takes default guesses for the parameters not specified or not defined in the \ *osimage*\ and \ *linuximage*\ tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Use \ **-**\ **-interactive**\ flag if you want the yum/zypper command to prompt you for the answers.
|
||||
|
||||
If \ **-**\ **-onlyinitrd**\ is specified, genimage only regenerates the initrd for a stateless image to be used for a diskless install.
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user