mirror of
https://github.com/xcat2/xcat-core.git
synced 2025-09-05 17:58:14 +00:00
Merge tag '2.13.11' into lenovobuild2.13
xCAT 2.13.11 release
This commit is contained in:
Jarrod Johnson
70
README.rst
70
README.rst
@@ -6,9 +6,20 @@ xCAT is a toolkit for the deployment and administration of clusters.
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
xCAT documentation is available at: http://xcat-docs.readthedocs.io/en/latest/
|
||||
Latest xCAT documentation is available at: http://xcat-docs.readthedocs.io/en/latest/
|
||||
|
||||
`document for xCAT 2.13.11 <http://xcat-docs.readthedocs.io/en/2.13.11/>`_
|
||||
|
||||
`document for xCAT 2.13.10 <http://xcat-docs.readthedocs.io/en/2.13.10/>`_
|
||||
|
||||
`document for xCAT 2.13.9 <http://xcat-docs.readthedocs.io/en/2.13.9/>`_
|
||||
|
||||
`document for xCAT 2.13 <http://xcat-docs.readthedocs.io/en/2.13.0/>`_
|
||||
|
||||
`document for xCAT 2.12 <http://xcat-docs.readthedocs.io/en/2.12/>`_
|
||||
|
||||
`document for xCAT 2.11 <http://xcat-docs.readthedocs.io/en/2.11/>`_
|
||||
|
||||
|docs_latest| |docs_2137| |docs_2136| |docs_2135| |docs_2134| |docs_2133| |docs_2132| |docs_2131| |docs_2130| |docs_212|
|
||||
|
||||
Open Source License
|
||||
-------------------
|
||||
@@ -21,58 +32,3 @@ 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_2137| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.7
|
||||
:alt: 2.13.7 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.13.7/
|
||||
|
||||
.. |docs_2136| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.6
|
||||
:alt: 2.13.6 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.13.6/
|
||||
|
||||
.. |docs_2135| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.5
|
||||
:alt: 2.13.5 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.13.5/
|
||||
|
||||
.. |docs_2134| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.4
|
||||
:alt: 2.13.4 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.13.4/
|
||||
|
||||
.. |docs_2133| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.3
|
||||
:alt: 2.13.3 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.13.3/
|
||||
|
||||
.. |docs_2132| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.2
|
||||
:alt: 2.13.2 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.13.2/
|
||||
|
||||
.. |docs_2131| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.1
|
||||
:alt: 2.13.1 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.13.1/
|
||||
|
||||
.. |docs_2130| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.13.0
|
||||
:alt: 2.13.0 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.13.0/
|
||||
|
||||
.. |docs_212| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.12
|
||||
:alt: 2.12 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.12/
|
||||
|
||||
.. |docs_211| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=2.11
|
||||
:alt: 2.11 documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/2.11/
|
||||
|
||||
.. |docs_latest| image:: https://readthedocs.org/projects/xcat-docs/badge/?version=latest
|
||||
:alt: Latest documentation status
|
||||
:scale: 100%
|
||||
:target: http://xcat-docs.readthedocs.io/en/latest/
|
||||
|
||||
91
build-python-deb
Executable file
91
build-python-deb
Executable file
@@ -0,0 +1,91 @@
|
||||
#!/bin/bash
|
||||
#
|
||||
# Author: Yuan Bai (bybai@cn.ibm.com)
|
||||
#
|
||||
#
|
||||
printusage()
|
||||
{
|
||||
echo "Usage : build-python-deb xcat-openbmc-py"
|
||||
}
|
||||
# For the purpose of getting the distribution name
|
||||
if [[ ! -f /etc/lsb-release ]]; then
|
||||
echo "ERROR: Could not find /etc/lsb-release, is this script executed on a Ubuntu machine?"
|
||||
exit 1
|
||||
fi
|
||||
. /etc/lsb-release
|
||||
# Check the necessary commands before starting the build
|
||||
for cmd in dch dpkg-buildpackage
|
||||
do
|
||||
if ! type "$cmd" >/dev/null 2>&1
|
||||
then
|
||||
echo "ERROR: Required command, $package, not found." >&2
|
||||
exit 1
|
||||
fi
|
||||
done
|
||||
|
||||
# Supported distributions
|
||||
pkg_name=$1
|
||||
|
||||
if [ "$pkg_name" != "xcat-openbmc-py" ]; then
|
||||
printusage
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Find where this script is located to set some build variables
|
||||
old_pwd=`pwd`
|
||||
cd `dirname $0`
|
||||
curdir=`pwd`
|
||||
|
||||
if [ -z "$REL" ]; then
|
||||
t=${curdir%/src/xcat-core}
|
||||
REL=`basename $t`
|
||||
fi
|
||||
|
||||
if [ "$PROMOTE" != 1 ]; then
|
||||
ver=`cat Version`
|
||||
|
||||
echo "###############################"
|
||||
echo "# Building xcat-openbmc-py package #"
|
||||
echo "###############################"
|
||||
|
||||
#the package type: local | snap | alpha
|
||||
#the build introduce string
|
||||
build_string="Snap_Build"
|
||||
xcat_release="snap$(date '+%Y%m%d%H%M')"
|
||||
pkg_version="${ver}-${xcat_release}"
|
||||
packages="xCAT-openbmc-py"
|
||||
for file in $packages
|
||||
do
|
||||
file_low="${file,,}"
|
||||
target_archs="all"
|
||||
for target_arch in $target_archs
|
||||
do
|
||||
cd $file
|
||||
CURDIR=$(pwd)
|
||||
dch -v $pkg_version -b -c debian/changelog $build_string
|
||||
if [ "$target_arch" = "all" ]; then
|
||||
CURDIR=$(pwd)
|
||||
cp ${CURDIR}/debian/control ${CURDIR}/debian/control.save.998
|
||||
sed -i -e "s#>= 2.13-snap000000000000#= ${pkg_version}#g" ${CURDIR}/debian/control
|
||||
dpkg-buildpackage -rfakeroot -uc -us
|
||||
mv ${CURDIR}/debian/control.save.998 ${CURDIR}/debian/control
|
||||
dh_testdir
|
||||
dh_testroot
|
||||
dh_clean -d
|
||||
fi
|
||||
rc=$?
|
||||
if [ $rc -gt 0 ]; then
|
||||
echo "Error: $file build package failed exit code $rc"
|
||||
exit $rc
|
||||
fi
|
||||
rm -f debian/files
|
||||
rm -f debian/xcat-openbmc-py.debhelper.log
|
||||
rm -f debian/xcat-openbmc-py.substvars
|
||||
sed -i -e "s/* Snap_Build//g" debian/changelog
|
||||
cd -
|
||||
rm -f ${file_low}_*.tar.gz
|
||||
rm -f ${file_low}_*.changes
|
||||
rm -f ${file_low}_*.dsc
|
||||
done
|
||||
done
|
||||
fi
|
||||
@@ -183,8 +183,8 @@ then
|
||||
short_short_ver=`cat Version|cut -d. -f 1`
|
||||
build_time=`date`
|
||||
build_machine=`hostname`
|
||||
commit_id=`git rev-parse --short HEAD`
|
||||
commit_id_long=`git rev-parse HEAD`
|
||||
commit_id="${commit_id_long:0:7}"
|
||||
|
||||
package_dir_name=debs$REL
|
||||
#TODO: define the core path and tarball name
|
||||
@@ -213,7 +213,7 @@ then
|
||||
for file in $packages
|
||||
do
|
||||
file_low=`echo $file | tr '[A-Z]' '[a-z]'`
|
||||
if [ "$file" = "xCAT" -o "$file" = "xCAT-genesis-scripts" ]; then
|
||||
if [ "$file" = "xCAT" -o "$file" = "xCAT-genesis-scripts" -o "$file" = "xCATsn" ]; then
|
||||
target_archs="amd64 ppc64el"
|
||||
else
|
||||
target_archs="all"
|
||||
@@ -250,7 +250,7 @@ then
|
||||
# shipping bmcsetup and getipmi scripts as part of postscripts
|
||||
files=("bmcsetup" "getipmi")
|
||||
for f in "${files[@]}"; do
|
||||
cp ${CURDIR}/../xCAT-genesis-scripts/bin/$f ${CURDIR}/postscripts/$f
|
||||
cp ${CURDIR}/../xCAT-genesis-scripts/usr/bin/$f ${CURDIR}/postscripts/$f
|
||||
sed -i "s/xcat.genesis.$f/$f/g" ${CURDIR}/postscripts/$f
|
||||
done
|
||||
fi
|
||||
|
||||
@@ -71,6 +71,7 @@ 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 xCAT-csm"
|
||||
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 xCAT-openbmc-py"
|
||||
LENOVOBUILD="perl-xCAT xCAT-client xCAT-server xCAT xCATsn xCAT-genesis-scripts xCAT-vlan xCAT-probe"
|
||||
ZVMBUILD="perl-xCAT xCAT-server xCAT-UI"
|
||||
ZVMLINK="xCAT-client xCAT xCATsn"
|
||||
@@ -192,8 +193,8 @@ function setversionvars {
|
||||
SHORTSHORTVER=`echo $VER|cut -d. -f 1`
|
||||
BUILD_TIME=`date`
|
||||
BUILD_MACHINE=`hostname`
|
||||
COMMIT_ID=`git rev-parse --short HEAD`
|
||||
COMMIT_ID_LONG=`git rev-parse HEAD`
|
||||
COMMIT_ID="${COMMIT_ID_LONG:0:7}"
|
||||
XCAT_RELEASE="snap$(date '+%Y%m%d%H%M')"
|
||||
echo "$XCAT_RELEASE" >Release
|
||||
}
|
||||
@@ -327,7 +328,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 xCAT-csm; 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 xCAT-openbmc-py; 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
|
||||
|
||||
8
docs/source/QA/index.rst
Normal file
8
docs/source/QA/index.rst
Normal file
@@ -0,0 +1,8 @@
|
||||
Questions & Answers
|
||||
===================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
|
||||
makehosts.rst
|
||||
133
docs/source/QA/makehosts.rst
Normal file
133
docs/source/QA/makehosts.rst
Normal file
@@ -0,0 +1,133 @@
|
||||
DNS, Hostname, Alias
|
||||
====================
|
||||
|
||||
Q: When there are multiple NICs, how to generate ``/etc/hosts`` records?
|
||||
------------------------------------------------------------------------
|
||||
|
||||
When there are multiple NICs, and you want to use ``confignetwork`` to configure these NICs, suggest to use ``hosts`` table to configure the installation NIC (``installnic``) and to use ``nics`` table to configure secondary NICs. Refer to the following example to generate ``/etc/hosts`` records.
|
||||
|
||||
**Best practice example**:
|
||||
|
||||
* There are 2 networks in different domains: ``mgtnetwork`` and ``pubnetwork``
|
||||
* ``mgtnetwork`` is xCAT management network
|
||||
* There are 2 adapters in system node1: ``eth0`` and ``eth1``
|
||||
* Add installnic ``eth0`` ``10.5.106.101`` record in ``/etc/hosts``, its alias is ``mgtnic``
|
||||
* hostnames ``node1-pub`` and ``node1.public.com`` are for nic ``eth1``, IP is ``192.168.30.101``
|
||||
|
||||
**Steps**:
|
||||
|
||||
#. Add networks entry in ``networks`` table: ::
|
||||
|
||||
chdef -t network mgtnetwork net=10.0.0.0 mask=255.0.0.0 domain=cluster.com
|
||||
chdef -t network pubnetwork net=192.168.30.0 mask=255.255.255.0 domain=public.com
|
||||
|
||||
#. Create ``node1`` with installnic IP ``10.5.106.101``, its alias is ``mgtnic``: ::
|
||||
|
||||
chdef node1 ip=10.5.106.101 hostnames=mgtnic groups=all
|
||||
|
||||
#. Configure ``eth1`` in ``nics`` table: ::
|
||||
|
||||
chdef node1 nicips.eth1=192.168.30.101 nichostnamesuffixes.eth1=-pub nicaliases.eth1=node1.public.com nictypes.eth1=Ethernet nicnetworks.eth1=pubnetwork
|
||||
|
||||
#. Check ``node1`` definition: ::
|
||||
|
||||
lsdef node1
|
||||
Object name: node1
|
||||
groups=all
|
||||
ip=10.5.106.101
|
||||
hostnames=mgtnic
|
||||
nicaliases.eth1=node1.public.com
|
||||
nichostnamesuffixes.eth1=-pub
|
||||
nicips.eth1=192.168.30.101
|
||||
nicnetworks.eth1=pubnetwork
|
||||
nictypes.eth1=Ethernet
|
||||
postbootscripts=otherpkgs
|
||||
postscripts=syslog,remoteshell,syncfiles
|
||||
|
||||
#. Execute ``makehosts -n`` to generate ``/etc/hosts`` records: ::
|
||||
|
||||
makehosts -n
|
||||
|
||||
#. Check results in ``/etc/hosts``: ::
|
||||
|
||||
10.5.106.101 node1 node1.cluster.com mgtnic
|
||||
192.168.30.101 node1-pub node1.public.com
|
||||
|
||||
#. Edit ``/etc/resolv.conf``, xCAT management node IP like ``10.5.106.2`` is nameserver: ::
|
||||
|
||||
search cluster.com public.com
|
||||
nameserver 10.5.106.2
|
||||
|
||||
#. Execute ``makedns -n`` to configure DNS
|
||||
|
||||
|
||||
Q: How to configure aliases?
|
||||
----------------------------
|
||||
|
||||
There are 3 methods to configure aliases:
|
||||
|
||||
#. Use ``hostnames`` in ``hosts`` table to configure aliases for the installnic.
|
||||
#. If you want to use script ``confignetwork`` to configure secondary NICs, suggest to use ``aliases`` in ``nics`` table to configure aliases. Refer to :doc:`Configure Aliases <../guides/admin-guides/manage_clusters/common/deployment/network/cfg_network_aliases>`
|
||||
#. If you want to generate aliases records in ``/etc/hosts`` for secondary NICs and you don't want to use the script ``confignetwork`` to configure these NICs, suggest to use ``otherinterfaces`` in ``hosts`` table to configure aliases. Refer to following example:
|
||||
|
||||
* If you want to add ``node1-hd`` ``20.1.1.1`` in ``hosts`` table, and don't use ``confignetwork`` to configure it, you can add ``otherinterfaces`` like this: ::
|
||||
|
||||
chdef node1 otherinterfaces="node1-hd:20.1.1.1"
|
||||
|
||||
* After executing ``makehosts -n``, you can get records in ``/etc/hosts`` like following: ::
|
||||
|
||||
20.1.1.1 node1-hd
|
||||
|
||||
**Note**: If suffixes or aliases for the same IP are configured in both ``hosts`` table and ``nics`` table, will cause conflicts. ``makehosts`` will use values from ``nics`` table. The values from ``nics`` table will over-write that from ``hosts`` table to create ``/etc/hosts`` records.
|
||||
|
||||
Q: How to handle the same short hostname in different domains?
|
||||
--------------------------------------------------------------
|
||||
|
||||
You can follow the best practice example.
|
||||
|
||||
**Best practice example**:
|
||||
|
||||
* There are 2 networks in different domains: ``mgtnetwork`` and ``pubnetwork``
|
||||
* ``mgtnetwork`` is xCAT management network
|
||||
* Generate 2 records with the same hostname in ``/etc/hosts``, like: ::
|
||||
|
||||
10.5.106.101 node1.cluster.com
|
||||
192.168.20.101 node1.public.com
|
||||
|
||||
* Nameserver is xCAT management node IP
|
||||
|
||||
**Steps**:
|
||||
|
||||
#. Add networks entry in ``networks`` table: ::
|
||||
|
||||
chdef -t network mgtnetwork net=10.0.0.0 mask=255.0.0.0 domain=cluster.com
|
||||
chdef -t network pubnetwork net=192.168.30.0 mask=255.255.255.0 domain=public.com
|
||||
|
||||
#. Create ``node1`` with ``ip=10.5.106.101``, xCAT can manage and install this node: ::
|
||||
|
||||
chdef node1 ip=10.5.106.101 groups=all
|
||||
|
||||
#. Create ``node1-pub`` with ``ip=192.168.30.101``, this node is only used to generate ``/etc/hosts`` records for public network, can use ``_unmanaged`` group name to label it: ::
|
||||
|
||||
chdef node1-pub ip=192.168.30.101 hostnames=node1.public.com groups=_unmanaged
|
||||
|
||||
#. Execute ``makehosts -n`` to generate ``/etc/hosts`` records: ::
|
||||
|
||||
makehosts -n
|
||||
|
||||
#. Check results in ``/etc/hosts``: ::
|
||||
|
||||
10.5.106.101 node1 node1.cluster.com
|
||||
192.168.30.101 node1-pub node1.public.com
|
||||
|
||||
#. Edit ``/etc/resolv.conf``, for example, xCAT management node IP is 10.5.106.2 : ::
|
||||
|
||||
search cluster.com public.com
|
||||
nameserver 10.5.106.2
|
||||
|
||||
#. Execute ``makedns -n`` to configure DNS
|
||||
|
||||
Q: When to use ``hosts`` table and ``nics`` table?
|
||||
--------------------------------------------------
|
||||
|
||||
``hosts`` table is used to store IP addresses and hostnames of nodes. ``makehosts`` use these data to create ``/etc/hosts`` records. ``nics`` table is used to stores secondary NICs details. Some scripts like ``confignetwork`` use data from ``nics`` table to configure secondary NICs. ``makehosts`` also use these data to create ``/etc/hosts`` records for each NIC.
|
||||
132
docs/source/QA/makehosts_qa.rst
Normal file
132
docs/source/QA/makehosts_qa.rst
Normal file
@@ -0,0 +1,132 @@
|
||||
DNS,hostname and alias Q/A list
|
||||
-------------------------------
|
||||
|
||||
Q: When there are multiple NICs, how to generate ``/etc/hosts`` records?
|
||||
````````````````````````````````````````````````````````````````````````
|
||||
|
||||
When there are multiple NICs, and you want to use ``confignetwork`` to configure these NICs, suggest to use ``hosts`` table to configure installnic and use ``nics`` table to configure secondary NICs. You can refer to the following best practice example to generate ``/etc/hosts`` records.
|
||||
|
||||
**Best practice example**:
|
||||
|
||||
* There are 2 networks in different domains: ``mgtnetwork`` and ``pubnetwork``
|
||||
* ``mgtnetwork`` is xCAT management network
|
||||
* There are 2 adapters in system node1: ``eth0`` and ``eth1``
|
||||
* Add installnic ``eth0`` ``10.5.106.101`` record in ``/etc/hosts``, its alias is ``mgtnic``
|
||||
* hostnames ``node1-pub`` and ``node1.public.com`` are for nic ``eth1``, ip is ``192.168.30.101``
|
||||
|
||||
**Steps**:
|
||||
|
||||
#. Add networks entry in ``networks`` table: ::
|
||||
|
||||
chdef -t network mgtnetwork net=10.0.0.0 mask=255.0.0.0 domain=cluster.com
|
||||
chdef -t network pubnetwork net=192.168.30.0 mask=255.255.255.0 domain=public.com
|
||||
|
||||
#. Create ``node1`` with installnic ip ``10.5.106.101``, its alias is ``mgtnic``: ::
|
||||
|
||||
chdef node1 ip=10.5.106.101 hostnames=mgtnic groups=all
|
||||
|
||||
#. Configure ``eth1`` in ``nics`` table: ::
|
||||
|
||||
chdef node1 nicips.eth1=192.168.30.101 nichostnamesuffixes.eth1=-pub nicaliases.eth1=node1.public.com nictypes.eth1=Ethernet nicnetworks.eth1=pubnetwork
|
||||
|
||||
#. Check ``node1`` definition: ::
|
||||
|
||||
lsdef node1
|
||||
Object name: node1
|
||||
groups=all
|
||||
ip=10.5.106.101
|
||||
hostnames=mgtnic
|
||||
nicaliases.eth1=node1.public.com
|
||||
nichostnamesuffixes.eth1=-pub
|
||||
nicips.eth1=192.168.30.101
|
||||
nicnetworks.eth1=pubnetwork
|
||||
nictypes.eth1=Ethernet
|
||||
postbootscripts=otherpkgs
|
||||
postscripts=syslog,remoteshell,syncfiles
|
||||
|
||||
#. Execute ``makehosts -n`` to generate ``/etc/hosts`` records: ::
|
||||
|
||||
makehosts -n
|
||||
|
||||
#. Check results in ``/etc/hosts``: ::
|
||||
|
||||
10.5.106.101 node1 node1.cluster.com mgtnic
|
||||
192.168.30.101 node1-pub node1.public.com
|
||||
|
||||
#. Edit ``/etc/resolv.conf``, xCAT management node ip like ``10.5.106.2`` is nameserver: ::
|
||||
|
||||
search cluster.com public.com
|
||||
nameserver 10.5.106.2
|
||||
|
||||
#. Execute ``makedns -n`` to configure DNS
|
||||
|
||||
Q: How to configure aliases?
|
||||
````````````````````````````
|
||||
|
||||
There are 3 methods to configure aliases:
|
||||
|
||||
#. Use ``hostnames`` in ``hosts`` table to configure aliases for the installnic.
|
||||
#. If you want to use script ``confignetwork`` to configure secondary NICs, suggest to use ``aliases`` in ``nics`` table to configure aliases, you can refer to :doc:`Configure Aliases <../guides/admin-guides/manage_clusters/common/deployment/network/cfg_network_aliases>`
|
||||
#. If you want to generate aliases records in ``/etc/hosts`` for secondary NICs, and don't want to use script ``confignetwork`` to configure these NICs, suggest to use ``otherinterfaces`` in ``hosts`` table to configure aliases. You can refer to following example:
|
||||
|
||||
* If you want to add ``node1-hd`` ``20.1.1.1`` in ``hosts`` table, and don't use ``confignetwork`` to configure it, you can add ``otherinterfaces`` like this: ::
|
||||
|
||||
chdef node1 otherinterfaces="node1-hd:20.1.1.1"
|
||||
|
||||
* After executing ``makehosts -n``, you can get records in ``/etc/hosts`` like following: ::
|
||||
|
||||
20.1.1.1 node1-hd
|
||||
|
||||
**Note**: If suffixes or aliases for the same IP are configured in both ``hosts`` table and ``nics`` table, will cause conflicts. ``makehosts`` will use values from ``nics`` table. The values from ``nics`` table will over-write that from ``hosts`` table to create ``/etc/hosts`` records.
|
||||
|
||||
Q: How to handle the same short hostname in different domains?
|
||||
``````````````````````````````````````````````````````````````
|
||||
|
||||
You can follow the best practice example.
|
||||
|
||||
**Best practice example**:
|
||||
|
||||
* There are 2 networks in different domains: ``mgtnetwork`` and ``pubnetwork``
|
||||
* ``mgtnetwork`` is xCAT management network
|
||||
* Generate 2 records with the same hostname in ``/etc/hosts``, like: ::
|
||||
|
||||
10.5.106.101 node1.cluster.com
|
||||
192.168.20.101 node1.public.com
|
||||
|
||||
* Nameserver is xCAT management node IP
|
||||
|
||||
**Steps**:
|
||||
|
||||
#. Add networks entry in ``networks`` table: ::
|
||||
|
||||
chdef -t network mgtnetwork net=10.0.0.0 mask=255.0.0.0 domain=cluster.com
|
||||
chdef -t network pubnetwork net=192.168.30.0 mask=255.255.255.0 domain=public.com
|
||||
|
||||
#. Create ``node1`` with ``ip=10.5.106.101``, xCAT can manage and install this node: ::
|
||||
|
||||
chdef node1 ip=10.5.106.101 groups=all
|
||||
|
||||
#. Create ``node1-pub`` with ``ip=192.168.30.101``, this node is only used to generate ``/etc/hosts`` records for public network, can use ``_unmanaged`` group name to label it: ::
|
||||
|
||||
chdef node1-pub ip=192.168.30.101 hostnames=node1.public.com groups=_unmanaged
|
||||
|
||||
#. Execute ``makehosts -n`` to generate ``/etc/hosts`` records: ::
|
||||
|
||||
makehosts -n
|
||||
|
||||
#. Check results in ``/etc/hosts``: ::
|
||||
|
||||
10.5.106.101 node1 node1.cluster.com
|
||||
192.168.30.101 node1-pub node1.public.com
|
||||
|
||||
#. Edit ``/etc/resolv.conf``, for example, xCAT management node IP is 10.5.106.2 : ::
|
||||
|
||||
search cluster.com public.com
|
||||
nameserver 10.5.106.2
|
||||
|
||||
#. Execute ``makedns -n`` to configure DNS
|
||||
|
||||
Q: When to use ``hosts`` table and ``nics`` table?
|
||||
``````````````````````````````````````````````````
|
||||
|
||||
``hosts`` table is used to store IP addresses and hostnames of nodes. ``makehosts`` use these data to create ``/etc/hosts`` records. ``nics`` table is used to stores secondary NICs details. Some scripts like ``confignetwork`` use data from ``nics`` table to configure secondary NICs. ``makehosts`` also use these data to create ``/etc/hosts`` records for each NIC.
|
||||
@@ -18,9 +18,9 @@ Remove Old Provision Environment
|
||||
|
||||
makedhcp -d <noderange>
|
||||
|
||||
#. Remove the nodes from the conserver configuration ::
|
||||
#. Remove the nodes from the goconserver configuration ::
|
||||
|
||||
makeconservercf -d <noderange>
|
||||
makegocons -d <noderange>
|
||||
|
||||
Change Definition
|
||||
-----------------
|
||||
@@ -76,6 +76,6 @@ Update The Provision Environment
|
||||
|
||||
makedhcp -a
|
||||
|
||||
#. Configure the new names in conserver ::
|
||||
#. Configure the new names in goconserver ::
|
||||
|
||||
makeconservercf
|
||||
makegocons
|
||||
|
||||
@@ -190,9 +190,9 @@ Then update the following in xCAT:
|
||||
|
||||
"1.4","new_MN_name",,,,,,"trusted",,``
|
||||
|
||||
* Setup up conserver with new credentials ::
|
||||
* Setup up goconserver with new credentials ::
|
||||
|
||||
makeconservercf
|
||||
makegocons
|
||||
|
||||
External DNS Server Changed
|
||||
---------------------------
|
||||
@@ -262,9 +262,9 @@ If it exists, then use the return name and do the following:
|
||||
|
||||
makedhcp -a
|
||||
|
||||
- Add the MN to conserver ::
|
||||
- Add the MN to goconserver ::
|
||||
|
||||
makeconservercf
|
||||
makegocons
|
||||
|
||||
Update the genesis packages
|
||||
---------------------------
|
||||
|
||||
119
docs/source/advanced/goconserver/configuration.rst
Normal file
119
docs/source/advanced/goconserver/configuration.rst
Normal file
@@ -0,0 +1,119 @@
|
||||
Configuration
|
||||
=============
|
||||
|
||||
Location
|
||||
--------
|
||||
|
||||
The configuration file for ``goconserver`` is located at ``/etc/goconserver/server.conf``.
|
||||
When the configuration is changed, reload using: ``systemctl restart goconserver.service``.
|
||||
An example for the configuration could be found from
|
||||
`Example Conf <https://github.com/xcat2/goconserver/blob/master/etc/goconserver/server.conf>`_.
|
||||
|
||||
Tag For xCAT
|
||||
------------
|
||||
|
||||
xCAT generates a configuration file that includes a identifier on the first
|
||||
line. For example: ::
|
||||
|
||||
#generated by xcat Version 2.13.10 (git commit 7fcd37ffb7cec37c021ab47d4baec151af547ac0, built Thu Jan 25 07:15:36 EST 2018)
|
||||
|
||||
``makegocons`` checks for this token and will not make changes to the
|
||||
configuration file if it exists. This gives the user the ability to customize
|
||||
the configuration based on their specific site configuration.
|
||||
|
||||
|
||||
Multiple Output Plugins
|
||||
-----------------------
|
||||
|
||||
``goconserver`` support console redirection to multiple targets with ``file``,
|
||||
``tcp`` and ``udp`` logger plugins. The entry could be found like below: ::
|
||||
|
||||
console:
|
||||
# the console session port for client(congo) to connect.
|
||||
port: 12430
|
||||
|
||||
logger:
|
||||
# for file logger
|
||||
file:
|
||||
# multiple file loggers could be specified
|
||||
# valid fields: name, logdir
|
||||
- name: default
|
||||
logdir: /var/log/goconserver/nodes/
|
||||
- name: xCAT
|
||||
logdir: /var/log/consoles
|
||||
|
||||
tcp:
|
||||
- name: logstash
|
||||
host: briggs01
|
||||
port: 9653
|
||||
ssl_key_file: /etc/xcat/cert/server-cred.pem
|
||||
ssl_cert_file: /etc/xcat/cert/server-cred.pem
|
||||
ssl_ca_cert_file: /etc/xcat/cert/ca.pem
|
||||
|
||||
- name: rsyslog
|
||||
host: sn02
|
||||
port: 9653
|
||||
|
||||
udp:
|
||||
- name: filebeat
|
||||
host: 192.168.1.5
|
||||
port: 512
|
||||
|
||||
With the configuration above, the console log files for each node would be written in
|
||||
both ``/var/log/goconserver/nodes/<node>.log`` and ``/var/log/consoles/<node>.log``.
|
||||
In addition, console log content will be redirected into remote services
|
||||
specified in the tcp and udp sections.
|
||||
|
||||
Verification
|
||||
------------
|
||||
|
||||
To check if ``goconserver`` works correctly, see the log file ``/var/log/goconserver/server.log``.
|
||||
|
||||
#. Check if TCP logger has been activated.
|
||||
|
||||
When starting ``goconserver``, if the log message is like below, it
|
||||
means the TCP configuration has been activated. ::
|
||||
|
||||
{"file":"github.com/xcat2/goconserver/console/logger/tcp.go (122)","level":"info","msg":"Starting TCP publisher: logstash","time":"2018-03-02T21:15:35-05:00"}
|
||||
{"file":"github.com/xcat2/goconserver/console/logger/tcp.go (122)","level":"info","msg":"Starting TCP publisher: sn02","time":"2018-03-02T21:15:35-05:00"}
|
||||
|
||||
#. Debug when encounter error about TCP logger
|
||||
|
||||
If the remote service is not started or the network is unreachable, the
|
||||
log message would be like below. ::
|
||||
|
||||
{"file":"github.com/xcat2/goconserver/console/logger/tcp.go (127)","level":"error","msg":"TCP publisher logstash: dial tcp 10.6.27.1:9653: getsockopt: connection refused","time":"2018-03-07T21:12:58-05:00"}
|
||||
|
||||
Check the service status and the network configuration including the
|
||||
``selinux`` and ``iptable rules``. When the remote service works
|
||||
correctly, TCP or UDP logger of ``goconserver`` would recover automatically.
|
||||
|
||||
Reconnect Interval
|
||||
------------------
|
||||
|
||||
If console node is defined with ``ondemand=false``, when the console connection
|
||||
could not be established, ``goconserver`` would reconnect automatically. The
|
||||
interval time could be specified at ::
|
||||
|
||||
console:
|
||||
# retry interval in second if console could not be connected.
|
||||
reconnect_interval: 10
|
||||
|
||||
Performance Tuning
|
||||
------------------
|
||||
|
||||
Adjust the worker numbers to leverage multi-core processor performance based on
|
||||
the site configuration. ::
|
||||
|
||||
global:
|
||||
# the max cpu cores for workload
|
||||
worker: 4
|
||||
|
||||
Debug
|
||||
-----
|
||||
|
||||
The log level for ``goconserver`` is defined in ``/etc/goconserver/server.conf`` ::
|
||||
|
||||
global:
|
||||
# debug, info, warn, error, fatal, panic
|
||||
log_level: info
|
||||
14
docs/source/advanced/goconserver/index.rst
Normal file
14
docs/source/advanced/goconserver/index.rst
Normal file
@@ -0,0 +1,14 @@
|
||||
Go Conserver
|
||||
============
|
||||
|
||||
``goconserver`` is a conserver replacement written in `Go <https://golang.org/>`_
|
||||
programming language. For more information, see https://github.com/xcat2/goconserver/
|
||||
|
||||
.. toctree::
|
||||
|
||||
:maxdepth: 2
|
||||
|
||||
quickstart.rst
|
||||
configuration.rst
|
||||
rest.rst
|
||||
|
||||
20
docs/source/advanced/goconserver/quickstart.rst
Normal file
20
docs/source/advanced/goconserver/quickstart.rst
Normal file
@@ -0,0 +1,20 @@
|
||||
Quickstart
|
||||
==========
|
||||
|
||||
To enable ``goconserver``, execute the following steps:
|
||||
|
||||
#. Install the ``goconserver`` RPM: ::
|
||||
|
||||
yum install goconserver
|
||||
|
||||
|
||||
#. If upgrading xCAT running ``conserver``, stop it first: ::
|
||||
|
||||
systemctl stop conserver.service
|
||||
|
||||
|
||||
#. Start ``goconserver`` and create the console configuration files with a single command ::
|
||||
|
||||
makegocons
|
||||
|
||||
The new console logs will start logging to ``/var/log/consoles/<node>.log``
|
||||
5
docs/source/advanced/goconserver/rest.rst
Normal file
5
docs/source/advanced/goconserver/rest.rst
Normal file
@@ -0,0 +1,5 @@
|
||||
REST API
|
||||
========
|
||||
|
||||
``goconserver`` provides REST API interface to manage the node sessions. For
|
||||
detail, see `REST <https://github.com/xcat2/goconserver/tree/master/api/>`_.
|
||||
@@ -8,6 +8,7 @@ Advanced Topics
|
||||
cluster_maintenance/index.rst
|
||||
migration/index.rst
|
||||
confluent/index.rst
|
||||
goconserver/index.rst
|
||||
docker/index.rst
|
||||
domain_name_resolution/index.rst
|
||||
gpu/index.rst
|
||||
@@ -23,6 +24,6 @@ Advanced Topics
|
||||
restapi/index.rst
|
||||
security/index.rst
|
||||
softlayer/index.rst
|
||||
switches/index.rst
|
||||
sysclone/index.rst
|
||||
zones/index.rst
|
||||
xcat-inventory/index.rst
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
Networks
|
||||
========
|
||||
Networking
|
||||
==========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
@@ -12,12 +12,16 @@ xCAT provides support for detecting and installing the Cumulus Linux OS into ONI
|
||||
|
||||
The mac address of the switch management port is required for xCAT to configure the DHCP information and send over the OS to install on the switch.
|
||||
|
||||
**[small clusters]** If you know the mac address of the management port on the switch, create the pre-defined switch definition providing the mac address. ::
|
||||
**Small Clusters**
|
||||
|
||||
If you know the mac address of the management port on the switch, create the pre-defined switch definition providing the mac address. ::
|
||||
|
||||
mkdef frame01sw1 --template onieswitch arch=armv71 \
|
||||
ip=192.168.1.1 mac="aa:bb:cc:dd:ee:ff"
|
||||
|
||||
**[large clusters]** xCAT's :doc:`switchdiscover </guides/admin-guides/references/man1/switchdiscover.1>` command can be used to discover the mac address and fill in the predefined switch definitions based on the switch/switchport mapping.
|
||||
**Large Clusters**
|
||||
|
||||
xCAT's :doc:`switchdiscover </guides/admin-guides/references/man1/switchdiscover.1>` command can be used to discover the mac address and fill in the predefined switch definitions based on the switch/switchport mapping.
|
||||
|
||||
|
||||
#. Define all the switch objects providing the switch/switchport mapping: ::
|
||||
|
||||
@@ -4,7 +4,19 @@ Switch Management
|
||||
Switch Port and VLAN Configuration
|
||||
----------------------------------
|
||||
|
||||
xCAT expects the configuration for the front-panel ports to be located at ``/etc/network/interfaces.d/xCAT.intf`` on the switch. The ``configinterface`` postscript can download an interface configuration file from the management node. Place the configuration file in the directory ``/install/custom/sw_os/cumulus/interface/`` on the management node. It will first look for a file named the same as the switch's hostname, followed by the name of each group, followed by the word 'default'. If the postscript cannot find a configuration file on the management node, it will set all the ports on the switch to be part of VLAN 1. See the Cumulus Networks documentation for more information regarding advanced networking configuration. ::
|
||||
xCAT places the front-panel port configuration in ``/etc/network/interfaces.d/xCAT.intf``.
|
||||
|
||||
The ``configinterface`` postscript can be used to pull switch interface configuration from the xCAT Management Node (MN) to the switch. Place the switch specific confguration files in the following directory on the MN: ``/install/custom/sw_os/cumulus/interface/``.
|
||||
|
||||
xCAT will look for files in the above directory in the following order:
|
||||
|
||||
1. file name that matches the switch hostname
|
||||
2. file name that matches the switch group name
|
||||
3. file name that has the word 'default'
|
||||
|
||||
Note: If the postscript cannot find a configuration file on the MN, it will set all ports on the switch to be part of VLAN 1.
|
||||
|
||||
Execute the script using the following command: ::
|
||||
|
||||
updatenode <switch> -P configinterface
|
||||
|
||||
@@ -12,9 +24,11 @@ xCAT expects the configuration for the front-panel ports to be located at ``/etc
|
||||
Re-install OS
|
||||
-------------
|
||||
|
||||
There may be occasions where a re-install of the OS is required. Assuming the files are available on the xCAT management node, the following commands will invoke the install process:
|
||||
There may be occasions where a re-install of the Cumulus Linux OS is required. The following commands can be used to invoke the install:
|
||||
|
||||
* **[use xCAT]** ``xdsh`` can be used to invoke the reinstall of the OS: ::
|
||||
**Note:** Assumption that the Cumulus Linux files are on the xCAT MN in the correct place.
|
||||
|
||||
* **Using xCAT**, ``xdsh`` can invoke the reinstall of the OS: ::
|
||||
|
||||
# to clear out all the previous configuration, use the -k option (optional)
|
||||
xdsh <switch> "/usr/cumulus/bin/onie-select -k
|
||||
@@ -22,7 +36,7 @@ There may be occasions where a re-install of the OS is required. Assuming the
|
||||
# to invoke the reinstall of the OS
|
||||
xdsh <switch> "/usr/cumulus/bin/onie-select -i -f;reboot"
|
||||
|
||||
* **[manually]** Log into the Cumulus OS switch and run the following commands: ::
|
||||
* **Manually**, log into the switch and run the following commands: ::
|
||||
|
||||
sudo onie-select -i
|
||||
sudo reboot
|
||||
|
||||
@@ -1,62 +1,79 @@
|
||||
Cumulus OS upgrade
|
||||
Cumulus OS Upgrade
|
||||
==================
|
||||
|
||||
The Cumulus OS on the ONIE switches can be upgraded in 2 ways:
|
||||
The Cumulus OS on the ONIE switches can be upgraded using one of the following methods:
|
||||
|
||||
* Upgrade only the changed packages, using ``apt-get update`` and ``apt-get upgrade``. If the ONIE switches has internet access, this is the preferred method, otherwise, you need to build up a local cumulus mirror in the cluster.
|
||||
Full Install
|
||||
------------
|
||||
|
||||
Since in a typical cluster setup, the switches usually do not have internet access, you can create a local mirror on the server which has internet access and can be reached from the switches, the steps are ::
|
||||
Perform a full install from the ``.bin`` file of the new Cumulus Linux OS version, using ONIE.
|
||||
|
||||
**Note:** Make sure you back up all your data and configuration files as the binary install will erase all previous configuration.
|
||||
|
||||
mkdir -p /install/mirror/cumulus
|
||||
cd /install/mirror/cumulus
|
||||
#the wget might take a long time, it will be better if you can set up
|
||||
#a cron job to sync the local mirror with upstream
|
||||
wget -m --no-parent http://repo3.cumulusnetworks.com/repo/
|
||||
|
||||
then compose a ``sources.list`` file on MN like this(take 172.21.253.37 as ip address of the local mirror server) ::
|
||||
#. Place the binary image under ``/install`` on the xCAT MN node.
|
||||
|
||||
#cat /tmp/sources.list
|
||||
deb http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3 cumulus upstream
|
||||
deb-src http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3 cumulus upstream
|
||||
|
||||
deb http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3-security-updates cumulus upstream
|
||||
deb-src http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3-security-updates cumulus upstream
|
||||
|
||||
deb http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3-updates cumulus upstream
|
||||
deb-src http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3-updates cumulus upstream
|
||||
|
||||
distribute the ``sources.list`` file to the switches to upgrade with ``xdcp``, take "switch1" as an example here ::
|
||||
|
||||
xdcp switch1 /tmp/sources.list /etc/apt/sources.list
|
||||
|
||||
then invoke ``apt-get update`` and ``apt-get install`` on the switches to start package upgrade, a reboot might be needed after upgrading ::
|
||||
|
||||
xdsh switch1 'apt-get update && apt-get upgrade && reboot'
|
||||
|
||||
check the `/etc/os-release` file to make sure the Cumulus OS has been upgraded ::
|
||||
|
||||
cat /etc/os-release
|
||||
|
||||
|
||||
|
||||
* Performe a binary (full image) install of the new version, using ONIE. If you expect to upgrade between major versions or if you have the binary image to upgrade to, this way is the recommended one. Make sure to backup your data and configuration files because binary install will erase all the configuration and data on the switch.
|
||||
|
||||
The steps to perform a binary (full image) install of the new version are:
|
||||
|
||||
1) place the binary image "cumulus-linux-3.4.1.bin" under ``/install`` directory on MN("172.21.253.37") ::
|
||||
In this example, IP=172.21.253.37 is the IP on the Management Node. ::
|
||||
|
||||
mkdir -p /install/onie/
|
||||
cp cumulus-linux-3.4.1.bin /install/onie/
|
||||
|
||||
2) invoke the upgrade on switches with ``xdsh`` ::
|
||||
#. Invoke the upgrade on the switches using :doc:`xdsh </guides/admin-guides/references/man1/xdsh.1>`: ::
|
||||
|
||||
xdsh switch1 "/usr/cumulus/bin/onie-install -a -f -i http://172.21.253.37/install/onie/cumulus-linux-3.4.1.bin && reboot"
|
||||
xdsh switch1 "/usr/cumulus/bin/onie-install -a -f -i \
|
||||
http://172.21.253.37/install/onie/cumulus-linux-3.4.1.bin && reboot"
|
||||
|
||||
The full upgrade process might cost 30 min, you can ping the switch with ``ping switch1`` to check whether it finishes upgrade.
|
||||
|
||||
3) After upgrading, the license should be installed, see :ref:`Activate the License <activate-the-license>` for detailed steps.
|
||||
**Note:** The full upgrade process may run 30 minutes or longer.
|
||||
|
||||
#. After upgrading, the license should be installed, see :ref:`Activate the License <activate-the-license>` for details.
|
||||
|
||||
#. Restore your data and configuration files on the switch.
|
||||
|
||||
|
||||
|
||||
Update Changed Packages
|
||||
-----------------------
|
||||
|
||||
This is the preferred method for upgrading the switch OS for incremental OS updates.
|
||||
|
||||
Create Local Mirror
|
||||
```````````````````
|
||||
|
||||
If the switches do not have access to the public Internet, you can create a local mirror of the Cumulus Linux repo.
|
||||
|
||||
#. Create a local mirror on the Management Node: ::
|
||||
|
||||
4) Restore your data and configuration files on the switch.
|
||||
mkdir -p /install/mirror/cumulus
|
||||
cd /install/mirror/cumulus
|
||||
wget -m --no-parent http://repo3.cumulusnetworks.com/repo/
|
||||
|
||||
#. Create a ``sources.list`` file to point to the local repo on the Management node. In this example, IP=172.21.253.37 is the IP on the Management Node. ::
|
||||
|
||||
# cat /tmp/sources.list
|
||||
deb http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3 cumulus upstream
|
||||
deb-src http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3 cumulus upstream
|
||||
|
||||
deb http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3-security-updates cumulus upstream
|
||||
deb-src http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3-security-updates cumulus upstream
|
||||
|
||||
deb http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3-updates cumulus upstream
|
||||
deb-src http://172.21.253.37/install/mirror/cumulus/repo3.cumulusnetworks.com/repo CumulusLinux-3-updates cumulus upstream
|
||||
|
||||
|
||||
#. Distribute the ``sources.list`` file to your switches using :doc:`xdcp </guides/admin-guides/references/man1/xdcp.1>`. ::
|
||||
|
||||
xdcp switch1 /tmp/sources.list /etc/apt/sources.list
|
||||
|
||||
Invoke the Update
|
||||
`````````````````
|
||||
|
||||
#. Use xCAT :doc:`xdsh </guides/admin-guides/references/man1/xdsh.1>` to invoke the update: ::
|
||||
|
||||
#
|
||||
# A reboot may be needed after the upgrade
|
||||
#
|
||||
xdsh switch1 'apt-get update && apt-get upgrade && reboot'
|
||||
|
||||
#. Check in ``/etc/os-release`` file to verify that the OS has been upgraded.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -105,7 +105,7 @@ if **--setup** flag is specified, the command will perform following steps:
|
||||
snmppassword=xcatadminpassw0rd@snmp
|
||||
snmpusername=xcatadmin
|
||||
snmpversion=3
|
||||
status=hostname_configed
|
||||
status=hostname_configured
|
||||
statustime=08-31-2016 15:35:49
|
||||
supportedarchs=ppc64
|
||||
switch=switch-10-5-23-1
|
||||
@@ -155,13 +155,13 @@ These two config files are located in the **/opt/xcat/share/xcat/scripts** direc
|
||||
Switch Status
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
During the switch-based switch discovery process, there are four states displayed. User may only see **switch_configed** status on node definition if discovery process successfully finished.
|
||||
During the switch-based switch discovery process, there are four states displayed. User may only see **switch_configured** status on node definition if discovery process successfully finished.
|
||||
|
||||
**Matched** --- Discovered switch is matched to predefine switch, **otherinterfaces** attribute is updated to dhcp IP address, and mac address, **switch type** and **usercomment** also updated with vendor information for the predefined switch.
|
||||
|
||||
**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**.
|
||||
**ip_configured** --- 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**.
|
||||
**hostname_configured** -- switch host name is changed based on predefine switch hostname. If failure to change hostname on the switch, the status will stay as **ip_configured**.
|
||||
|
||||
**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**.
|
||||
**switch_configured** -- 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_configured**.
|
||||
|
||||
|
||||
109
docs/source/advanced/pdu/crpdu.rst
Normal file
109
docs/source/advanced/pdu/crpdu.rst
Normal file
@@ -0,0 +1,109 @@
|
||||
Collaborative PDU
|
||||
=================
|
||||
|
||||
Collaborative PDU is also referred as Coral PDU, it controls power for compute Rack. User can access PDU via SSH and can use the **PduManager** command to configure and manage the PDU product.
|
||||
|
||||
|
||||
Pre-Defined PDU Objects
|
||||
-----------------------
|
||||
|
||||
A pre-defined PDU node object is required before running pdudiscover command. ::
|
||||
|
||||
mkdef coralpdu groups=pdu mgt=pdu nodetype=pdu (required)
|
||||
|
||||
all other attributes can be set by chdef command or pdudisocover command. ::
|
||||
|
||||
--switch required for pdudiscover command to do mapping
|
||||
--switchport required for pdudiscover command to do mapping
|
||||
--ip ip address of the pdu.
|
||||
--mac can be filled in by pdudiscover command
|
||||
--pdutype crpdu(for coral pdu) or irpdu(for infrastructure PDUs)
|
||||
|
||||
|
||||
The following attributes need to be set in order to configure snmp with non-default values. ::
|
||||
|
||||
--community community string for coral pdu
|
||||
--snmpversion snmp version number, required if configure snmpv3 for coral pdu
|
||||
--snmpuser snmpv3 user name, required if configure snmpv3 for coral pdu
|
||||
--authkey auth passphrase for snmpv3 configuration
|
||||
--authtype auth protocol (MD5|SHA) for snmpv3 configuration
|
||||
--privkey priv passphrase for snmpv3 configuration
|
||||
--privtype priv protocol (AES|DES) for snmpv3 configuration
|
||||
--seclevel security level (noAuthNoPriv|authNoPriv|authPriv) for snmpv3 configuration
|
||||
|
||||
Make sure to run makehosts after pre-defined PDU. ::
|
||||
|
||||
makehosts coralpdu
|
||||
|
||||
|
||||
Configure PDUs
|
||||
--------------
|
||||
|
||||
After pre-defining PDUs, user can use **pdudisocver --range ip_range --setup** to configure the PDUs, or following commands can be used:
|
||||
|
||||
* To configure passwordless of Coral PDU: ::
|
||||
|
||||
# rspconfig coralpdu sshcfg
|
||||
|
||||
* To change hostname of Coral PDU: ::
|
||||
|
||||
# rspconfig coralpdu hosname=f5pdu3
|
||||
|
||||
* To change ip address of PDU: ::
|
||||
|
||||
# rsconfig coralpdu ip=x.x.x.x netmaks=255.x.x.x
|
||||
|
||||
* To configure SNMP community string or snmpv3 of PDU (the attribute needs to pre-defined): ::
|
||||
|
||||
# rspconfig coralpdu snmpcfg
|
||||
|
||||
|
||||
Remote Power Control of PDU
|
||||
---------------------------
|
||||
|
||||
Use the rpower command to remotely power on and off PDU.
|
||||
|
||||
* To check power stat of PDU: ::
|
||||
|
||||
# rpower coralpdu stat
|
||||
|
||||
* To power off the PDU: ::
|
||||
|
||||
# rpower coralpdu off
|
||||
|
||||
* To power on the PDU: ::
|
||||
|
||||
# rpower coralpdu on
|
||||
|
||||
Coral PDUs have three relays, the following commands are for individual relay support of PDU:
|
||||
|
||||
* To check power stat of relay: ::
|
||||
|
||||
# rpower coralpdu relay=1 stat
|
||||
|
||||
* To power off the relay: ::
|
||||
|
||||
# rpower coralpdu relay=2 off
|
||||
|
||||
* To power on the relay: ::
|
||||
|
||||
# rpower coralpdu relay=3 on
|
||||
|
||||
|
||||
Show Monitor Data
|
||||
-----------------
|
||||
|
||||
Use the rvitals command to show realtime monitor data(input voltage, current, power) of PDU. ::
|
||||
|
||||
# rvitals coralpdu
|
||||
|
||||
|
||||
Show manufacture information
|
||||
-----------------------------
|
||||
|
||||
Use the rinv command to show MFR information of PDU ::
|
||||
|
||||
# rinv coralpdu
|
||||
|
||||
|
||||
|
||||
@@ -1,10 +1,14 @@
|
||||
PDUs
|
||||
====
|
||||
|
||||
Power Distribution Units (PDUs) are devices that distribute power to servers in a frame. Intelligent PDUs have the capability of monitoring the amount of power that is being used by devices plugged into it.
|
||||
Power Distribution Units (PDUs) are devices that distribute power to servers in a frame. They have the capability of monitoring the amount of power that is being used by devices plugged into it and cycle power to individual receptacles. xCAT can support two kinds of PDUs, infrastructure PDU (irpdu) and collaborative PDU (crpdu).
|
||||
|
||||
The Infrastructure rack PDUs are switched and monitored 1U PDU products which can connect up to nine C19 devices or up to 12 C13 devices and an additional three C13 peripheral devices to a signle dedicated power source. The Collaborative PDU is on the compute rack and has the 6x IEC 320-C13 receptacles that feed the rack switches. These two types of PDU have different design and implementation. xCAT has different code path to maintains PDU commands via **pdutype**.
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
pdu.rst
|
||||
irpdu.rst
|
||||
crpdu.rst
|
||||
|
||||
161
docs/source/advanced/pdu/irpdu.rst
Normal file
161
docs/source/advanced/pdu/irpdu.rst
Normal file
@@ -0,0 +1,161 @@
|
||||
Infrastructure PDU
|
||||
==================
|
||||
|
||||
Users can access Infrastructure PDU via telnet and use the **IBM PDU Configuration Utility** to set up and configure the PDU. xCAT supports PDU commands for power management and monitoring through SNMP.
|
||||
|
||||
|
||||
PDU Commands
|
||||
------------
|
||||
|
||||
Administrators will need to know the exact mapping of the outlets to each server in the frame. xCAT cannot validate the physical cable is connected to the correct server.
|
||||
|
||||
Add a ``pdu`` attribute to the compute node definition in the form "PDU_Name:outlet": ::
|
||||
|
||||
#
|
||||
# Compute server cn01 has two power supplies
|
||||
# connected to outlet 6 and 7 on pdu=f5pdu3
|
||||
#
|
||||
chdef cn01 pdu=f5pdu3:6,f5pdu3:7
|
||||
|
||||
|
||||
The following commands are supported against a compute node:
|
||||
|
||||
* Check the pdu status for a compute node: ::
|
||||
|
||||
# rpower cn01 pdustat
|
||||
cn01: f5pdu3 outlet 6 is on
|
||||
cn01: f5pdu3 outlet 7 is on
|
||||
|
||||
|
||||
* Power off the PDU outlets for a compute node: ::
|
||||
|
||||
# rpower cn01 pduoff
|
||||
cn01: f5pdu3 outlet 6 is off
|
||||
cn01: f5pdu3 outlet 7 is off
|
||||
|
||||
* Power on the PDU outlets for a compute node: ::
|
||||
|
||||
# rpower cn01 pduon
|
||||
cn01: f5pdu3 outlet 6 is on
|
||||
cn01: f5pdu3 outlet 7 is on
|
||||
|
||||
* Power cycling the PDU outlets for a compute node: ::
|
||||
|
||||
# rpower cn01 pdureset
|
||||
cn01: f5pdu3 outlet 6 is reset
|
||||
cn01: f5pdu3 outlet 7 is reset
|
||||
|
||||
The following commands are supported against a PDU:
|
||||
|
||||
* To change hostname of IR PDU: ::
|
||||
|
||||
# rspconfig f5pdu3 hosname=f5pdu3
|
||||
|
||||
* To change ip address of IR PDU: ::
|
||||
|
||||
# rsconfig f5pdu3 ip=x.x.x.x netmaks=255.x.x.x
|
||||
|
||||
* Check the status of the full PDU: ::
|
||||
|
||||
# rpower f5pdu3 stat
|
||||
f5pdu3: outlet 1 is on
|
||||
f5pdu3: outlet 2 is on
|
||||
f5pdu3: outlet 3 is on
|
||||
f5pdu3: outlet 4 is on
|
||||
f5pdu3: outlet 5 is on
|
||||
f5pdu3: outlet 6 is off
|
||||
f5pdu3: outlet 7 is off
|
||||
f5pdu3: outlet 8 is on
|
||||
f5pdu3: outlet 9 is on
|
||||
f5pdu3: outlet 10 is on
|
||||
f5pdu3: outlet 11 is on
|
||||
f5pdu3: outlet 12 is on
|
||||
|
||||
* Power off the full PDU: ::
|
||||
|
||||
# rpower f5pdu3 off
|
||||
f5pdu3: outlet 1 is off
|
||||
f5pdu3: outlet 2 is off
|
||||
f5pdu3: outlet 3 is off
|
||||
f5pdu3: outlet 4 is off
|
||||
f5pdu3: outlet 5 is off
|
||||
f5pdu3: outlet 6 is off
|
||||
f5pdu3: outlet 7 is off
|
||||
f5pdu3: outlet 8 is off
|
||||
f5pdu3: outlet 9 is off
|
||||
f5pdu3: outlet 10 is off
|
||||
f5pdu3: outlet 11 is off
|
||||
f5pdu3: outlet 12 is off
|
||||
|
||||
* Power on the full PDU: ::
|
||||
|
||||
# rpower f5pdu3 on
|
||||
f5pdu3: outlet 1 is on
|
||||
f5pdu3: outlet 2 is on
|
||||
f5pdu3: outlet 3 is on
|
||||
f5pdu3: outlet 4 is on
|
||||
f5pdu3: outlet 5 is on
|
||||
f5pdu3: outlet 6 is on
|
||||
f5pdu3: outlet 7 is on
|
||||
f5pdu3: outlet 8 is on
|
||||
f5pdu3: outlet 9 is on
|
||||
f5pdu3: outlet 10 is on
|
||||
f5pdu3: outlet 11 is on
|
||||
f5pdu3: outlet 12 is on
|
||||
|
||||
* Power reset the full PDU: ::
|
||||
|
||||
# rpower f5pdu3 reset
|
||||
f5pdu3: outlet 1 is reset
|
||||
f5pdu3: outlet 2 is reset
|
||||
f5pdu3: outlet 3 is reset
|
||||
f5pdu3: outlet 4 is reset
|
||||
f5pdu3: outlet 5 is reset
|
||||
f5pdu3: outlet 6 is reset
|
||||
f5pdu3: outlet 7 is reset
|
||||
f5pdu3: outlet 8 is reset
|
||||
f5pdu3: outlet 9 is reset
|
||||
f5pdu3: outlet 10 is reset
|
||||
f5pdu3: outlet 11 is reset
|
||||
f5pdu3: outlet 12 is reset
|
||||
|
||||
* PDU inventory information: ::
|
||||
|
||||
# rinv f6pdu16
|
||||
f6pdu16: PDU Software Version: "OPDP_sIBM_v01.3_2"
|
||||
f6pdu16: PDU Machine Type: "1U"
|
||||
f6pdu16: PDU Model Number: "dPDU4230"
|
||||
f6pdu16: PDU Part Number: "46W1608"
|
||||
f6pdu16: PDU Name: "IBM PDU"
|
||||
f6pdu16: PDU Serial Number: "4571S9"
|
||||
f6pdu16: PDU Description: "description"
|
||||
|
||||
* PDU and outlet power information: ::
|
||||
|
||||
# rvitals f6pdu15
|
||||
f6pdu15: Voltage Warning: 0
|
||||
f6pdu15: outlet 1 Current: 0 mA
|
||||
f6pdu15: outlet 1 Max Capacity of the current: 16000 mA
|
||||
f6pdu15: outlet 1 Current Threshold Warning: 9600 mA
|
||||
f6pdu15: outlet 1 Current Threshold Critical: 12800 mA
|
||||
f6pdu15: outlet 1 Last Power Reading: 0 Watts
|
||||
f6pdu15: outlet 2 Current: 0 mA
|
||||
f6pdu15: outlet 2 Max Capacity of the current: 16000 mA
|
||||
f6pdu15: outlet 2 Current Threshold Warning: 9600 mA
|
||||
f6pdu15: outlet 2 Current Threshold Critical: 12800 mA
|
||||
f6pdu15: outlet 2 Last Power Reading: 0 Watts
|
||||
f6pdu15: outlet 3 Current: 1130 mA
|
||||
f6pdu15: outlet 3 Max Capacity of the current: 16000 mA
|
||||
f6pdu15: outlet 3 Current Threshold Warning: 9600 mA
|
||||
f6pdu15: outlet 3 Current Threshold Critical: 12800 mA
|
||||
f6pdu15: outlet 3 Last Power Reading: 217 Wattsv
|
||||
|
||||
**Note:** For BMC based compute nodes, turning the PDU outlet power on does not automatically power on the compute side. Users will need to issue ``rpower <node> on`` to power on the compute side after the BMC boots.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,17 +1,39 @@
|
||||
PDU
|
||||
===
|
||||
Discovering PDUs
|
||||
================
|
||||
|
||||
xCAT provides basic remote management for each power outlet plugged into the PDUs using SNMP communication. This documentation will focus on configuration of the PDU and Node objects to allow xCAT to control power at the PDU outlet level.
|
||||
xCAT provides `pdudiscover` command to discover the PDUs that are attached to the neighboring subnets on xCAT management node. ::
|
||||
|
||||
pdudiscover [<noderange>|--range ipranges] [-r|-x|-z] [-w] [-V|--verbose] [--setup]
|
||||
|
||||
xCAT uses snmp scan method to discover PDU. Make sure net-snmp-utils package is installed on xCAT MN in order to use snmpwalk command. ::
|
||||
|
||||
Options:
|
||||
--range Specify one or more IP ranges. Each can be an ip address (10.1.2.3) or an ip range
|
||||
(10.1.2.0/24). If the range is huge, for example, 192.168.1.1/8, the pdu
|
||||
discover may take a very long time to scan. So the range should be exactly
|
||||
specified. It accepts multiple formats. For example:
|
||||
192.168.1.1/24, 40-41.1-2.3-4.1-100.
|
||||
|
||||
If the range is not specified, the command scans all the subnets that the active
|
||||
network interfaces (eth0, eth1) are on where this command is issued.
|
||||
-r Display Raw responses.
|
||||
-x XML formatted output.
|
||||
-z Stanza formatted output.
|
||||
-w Writes output to xCAT database.
|
||||
--setup Process switch-based pdu discovery and configure the PDUs. For crpdu, --setup options will configure passwordless , change ip address from dhcp to static, hostname changes and snmp v3 configuration. For irpdu, it will configure ip address and hostname. It required predefined PDU node definition with switch name and switch port attributes for mapping.
|
||||
|
||||
|
||||
Define PDU Objects
|
||||
------------------
|
||||
|
||||
|
||||
|
||||
#. Define pdu object ::
|
||||
|
||||
mkdef f5pdu3 groups=pdu ip=50.0.0.8 mgt=pdu nodetype=pdu
|
||||
mkdef f5pdu3 groups=pdu ip=50.0.0.8 mgt=pdu nodetype=pdu pdutype=irpdu
|
||||
|
||||
#. Define switch attribute for pdu object which will be used for pdudiscover **--setup** options. ::
|
||||
|
||||
chdef f5pdu3 switch=mid08 switchport=3
|
||||
|
||||
#. Add hostname to /etc/hosts::
|
||||
|
||||
@@ -19,129 +41,6 @@ Define PDU Objects
|
||||
|
||||
#. Verify the SNMP command responds against the PDU: ::
|
||||
|
||||
snmpwalk -v1 -cpublic -mALL f5pdu3 .1.3.6.1.2.1.1
|
||||
|
||||
|
||||
Define PDU Attribute
|
||||
--------------------
|
||||
|
||||
Administrators will need to know the exact mapping of the outlets to each server in the frame. xCAT cannot validate the physical cable is connected to the correct server.
|
||||
|
||||
Add a ``pdu`` attribute to the compute node definition in the form "PDU_Name:outlet": ::
|
||||
|
||||
#
|
||||
# Compute server cn01 has two power supplies
|
||||
# connected to outlet 6 and 7 on pdu=f5pdu3
|
||||
#
|
||||
chdef cn01 pdu=f5pdu3:6,f5pdu3:7
|
||||
|
||||
|
||||
Verify the setting: ``lsdef cn01 -i pdu``
|
||||
|
||||
|
||||
PDU Commands
|
||||
------------
|
||||
|
||||
The following commands are supported against a compute node:
|
||||
|
||||
* Check the pdu status for a compute node: ::
|
||||
|
||||
# rpower cn01 pdustat
|
||||
cn01: f5pdu3 outlet 6 is on
|
||||
cn01: f5pdu3 outlet 7 is on
|
||||
|
||||
|
||||
* Power off the PDU outlets on a compute node: ::
|
||||
|
||||
# rpower cn01 pduoff
|
||||
cn01: f5pdu3 outlet 6 is off
|
||||
cn01: f5pdu3 outlet 7 is off
|
||||
|
||||
* Power on the PDU outlets on a compute node: ::
|
||||
|
||||
# rpower cn01 pduon
|
||||
cn01: f5pdu3 outlet 6 is on
|
||||
cn01: f5pdu3 outlet 7 is on
|
||||
|
||||
* Power cycling the PDU outlets on a compute node: ::
|
||||
|
||||
# rpower cn01 pdureset
|
||||
cn01: f5pdu3 outlet 6 is reset
|
||||
cn01: f5pdu3 outlet 7 is reset
|
||||
|
||||
The following commands are supported against a PDU:
|
||||
|
||||
* Check the status of the full PDU: ::
|
||||
|
||||
# rinv f5pdu3
|
||||
f5pdu3: outlet 1 is on
|
||||
f5pdu3: outlet 2 is on
|
||||
f5pdu3: outlet 3 is on
|
||||
f5pdu3: outlet 4 is on
|
||||
f5pdu3: outlet 5 is on
|
||||
f5pdu3: outlet 6 is off
|
||||
f5pdu3: outlet 7 is off
|
||||
f5pdu3: outlet 8 is on
|
||||
f5pdu3: outlet 9 is on
|
||||
f5pdu3: outlet 10 is on
|
||||
f5pdu3: outlet 11 is on
|
||||
f5pdu3: outlet 12 is on
|
||||
|
||||
* Power off the full PDU: ::
|
||||
|
||||
# rpower f5pdu3 off
|
||||
f5pdu3: outlet 1 is off
|
||||
f5pdu3: outlet 2 is off
|
||||
f5pdu3: outlet 3 is off
|
||||
f5pdu3: outlet 4 is off
|
||||
f5pdu3: outlet 5 is off
|
||||
f5pdu3: outlet 6 is off
|
||||
f5pdu3: outlet 7 is off
|
||||
f5pdu3: outlet 8 is off
|
||||
f5pdu3: outlet 9 is off
|
||||
f5pdu3: outlet 10 is off
|
||||
f5pdu3: outlet 11 is off
|
||||
f5pdu3: outlet 12 is off
|
||||
|
||||
* Power on the full PDU: ::
|
||||
|
||||
# rpower f5pdu3 on
|
||||
f5pdu3: outlet 1 is on
|
||||
f5pdu3: outlet 2 is on
|
||||
f5pdu3: outlet 3 is on
|
||||
f5pdu3: outlet 4 is on
|
||||
f5pdu3: outlet 5 is on
|
||||
f5pdu3: outlet 6 is on
|
||||
f5pdu3: outlet 7 is on
|
||||
f5pdu3: outlet 8 is on
|
||||
f5pdu3: outlet 9 is on
|
||||
f5pdu3: outlet 10 is on
|
||||
f5pdu3: outlet 11 is on
|
||||
f5pdu3: outlet 12 is on
|
||||
|
||||
* Power reset the full PDU: ::
|
||||
|
||||
# rpower f5pdu3 reset
|
||||
f5pdu3: outlet 1 is reset
|
||||
f5pdu3: outlet 2 is reset
|
||||
f5pdu3: outlet 3 is reset
|
||||
f5pdu3: outlet 4 is reset
|
||||
f5pdu3: outlet 5 is reset
|
||||
f5pdu3: outlet 6 is reset
|
||||
f5pdu3: outlet 7 is reset
|
||||
f5pdu3: outlet 8 is reset
|
||||
f5pdu3: outlet 9 is reset
|
||||
f5pdu3: outlet 10 is reset
|
||||
f5pdu3: outlet 11 is reset
|
||||
f5pdu3: outlet 12 is reset
|
||||
|
||||
|
||||
**Note:** For BMC based compute nodes, turning the PDU outlet power on does not automatically power on the compute side. Users will need to issue ``rpower <node> on`` to power on the compute node after the BMC boots.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
snmpwalk -v1 -cpublic -mALL f5pdu3 system
|
||||
|
||||
|
||||
|
||||
@@ -6,4 +6,5 @@ The security of a system covers a wide range of elements, from the security of s
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
security
|
||||
ssl_config.rst
|
||||
security.rst
|
||||
|
||||
56
docs/source/advanced/security/ssl_config.rst
Normal file
56
docs/source/advanced/security/ssl_config.rst
Normal file
@@ -0,0 +1,56 @@
|
||||
OpenSSL Configuration
|
||||
=====================
|
||||
|
||||
xCAT does not ship OpenSSL RPMS nor does it statically link to any OpenSSL libraries. Communication between the xCAT client and daemon utilizes OpenSSL and the administrator can configure SSL_version and SSL_cipher that should be used by xCAT daemons.
|
||||
|
||||
The configuration is stored in the xCAT site table using the ``site.xcatsslversion`` and ``site.xcatsslciphers`` variables.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
By default, xCAT ships with ``TLSv1`` configured. The current highest SSL version that can be supported is ``TLSv1.2``.
|
||||
|
||||
* For rhels7.x and sles12.x and higher: ::
|
||||
|
||||
chtab key=xcatsslversion site.value=TLSv12
|
||||
|
||||
* For ubuntu 14.x and higher: ::
|
||||
|
||||
chtab key=xcatsslversion site.value=TLSv1_2
|
||||
|
||||
* For AIX 7.1.3.x: ::
|
||||
|
||||
chtab key=xcatsslversion site.value=TLSv1_2
|
||||
|
||||
|
||||
If running > ``TLSv1``, it is possible to disable insecure ciphers. Here's an example of one possible configuration: ::
|
||||
|
||||
"xcatsslciphers","kDH:kEDH:kRSA:!SSLv3:!SSLv2:!aNULL:!eNULL:!MEDIUM:!LOW:!MD5:!EXPORT:!CAMELLIA:!ECDH",,
|
||||
|
||||
After making any changes to these configuration values, ``xcatd`` must be restarted: ::
|
||||
|
||||
service restart xcatd
|
||||
|
||||
|
||||
If any mistakes have been made and communiation is lost to xCAT, use ``XCATBYPASS`` to fix/remove the bad configuration: ::
|
||||
|
||||
XCATBYPASS=1 tabedit site
|
||||
|
||||
|
||||
Validation
|
||||
----------
|
||||
|
||||
Use the ``openssl`` command to validate the SSL configuration is valid and expected.
|
||||
|
||||
* To check whether TLSv1 is supported by xcatd: ::
|
||||
|
||||
openssl s_client -connect 127.0.0.1:3001 -tls1
|
||||
|
||||
* To check if SSLv3 is disabled on ``xcatd``: ::
|
||||
|
||||
openssl s_client -connect localhost:3001 -ssl3
|
||||
|
||||
You should get a reponse similar to: ::
|
||||
|
||||
70367087597568:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1259:SSL alert number 40
|
||||
70367087597568:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
|
||||
@@ -1,2 +0,0 @@
|
||||
Ethernet Switches
|
||||
=================
|
||||
@@ -1,7 +0,0 @@
|
||||
Switch Management
|
||||
=================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
ethernet_switches.rst
|
||||
@@ -0,0 +1,28 @@
|
||||
Define and create your first xCAT cluster easily
|
||||
================================================
|
||||
|
||||
The inventory templates for 2 kinds of typical xCAT cluster is shipped. You can create your first xCAT cluster easily by making several modifications on the template. The templates can be found under ``/opt/xcat/share/xcat/inventory_templates`` on management node with ``xcat-inventory`` installed.
|
||||
|
||||
Currently, the inventory templates includes:
|
||||
|
||||
1. flat_cluster_template.yaml:
|
||||
|
||||
a flat baremetal cluster, including **openbmc controlled PowerLE servers**, **IPMI controlled Power servers(commented out)**, **X86_64 servers(commented out)**
|
||||
|
||||
2. flat_kvm_cluster_template.yaml: a flat KVM based Virtual Machine cluster, including **PowerKVM based VM nodes**, **KVM based X86_64 VM nodes(commented out)**
|
||||
|
||||
The steps to create your first xCAT cluster is:
|
||||
|
||||
1. create a customized cluster inventory file "mycluster.yaml" based on ``flat_cluster_template.yaml`` ::
|
||||
|
||||
cp /opt/xcat/share/xcat/inventory_templates/flat_cluster_template.yaml /git/cluster/mycluster.yaml
|
||||
|
||||
2. custmize the cluster inventory file "mycluster.yaml" by modifying the attributs in the line under token ``#CHANGEME`` according to the setup of your phisical cluster. You can create new node definition by duplicating and modifying the node definition in the template.
|
||||
|
||||
3. import the cluster inventory file ::
|
||||
|
||||
xcat-inventory import -f /git/cluster/mycluster.yaml
|
||||
|
||||
Now you have your 1st xCAT cluster, you can start bring up the cluster by provision nodes.
|
||||
|
||||
|
||||
21
docs/source/advanced/xcat-inventory/index.rst
Normal file
21
docs/source/advanced/xcat-inventory/index.rst
Normal file
@@ -0,0 +1,21 @@
|
||||
xcat-inventory
|
||||
==============
|
||||
|
||||
`xcat-inventory <https://github.com/xcat2/xcat-inventory>`_ is an inventory tool for the cluster managed by xCAT. Its features includes:
|
||||
|
||||
* a object based view of the cluster inventory, which is flexible, extensible and well formatted
|
||||
|
||||
* interfaces to export/import the cluster inventory data in yaml/json format, which can be then managed under source control
|
||||
|
||||
* inventory templates for typical clusters, which help user to defines a cluster easily
|
||||
|
||||
* ability to intergrate with Ansible(Comming Soon)
|
||||
|
||||
|
||||
This section presents 2 typical user case of ``xcat-inventory``
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
version_control_inventory.rst
|
||||
define_create_cluster.rst
|
||||
@@ -0,0 +1,50 @@
|
||||
Manage the xCAT Cluster Definition under Source Control
|
||||
=======================================================
|
||||
|
||||
The xCAT cluster inventory data, including global configuration and object definitions(node/osimage/passwd/policy/network/router), and the relationship of the objects, can be exported to a YAML/JSON file(**inventory file**) from xCAT Database, or be imported to xCAT Database from the inventory file.
|
||||
|
||||
By managing the inventory file under source control system, you can manage the xCAT cluster definition under source control. This section presents a typical step-by-step scenario on how to manage cluster inventory data under ``git``.
|
||||
|
||||
|
||||
1. create a directory ``/git/cluster`` under git directory to hold the cluster inventory ::
|
||||
|
||||
mkdir -p /git/cluster
|
||||
cd /git/cluster
|
||||
git init
|
||||
|
||||
2. export the current cluster configuration to a inventory file "mycluster.yaml" under the git directory created above ::
|
||||
|
||||
xcat-inventory export --format=yaml >/git/cluster/mycluster.yaml
|
||||
|
||||
3. check diff and commit the cluster inventory file(commit no: c95673) ::
|
||||
|
||||
cd /git/cluster
|
||||
git diff
|
||||
git add /git/cluster/mycluster.yaml
|
||||
git commit /git/cluster/mycluster.yaml -m "$(date "+%Y_%m_%d_%H_%M_%S"): initial cluster inventory data; blah-blah"
|
||||
|
||||
4. ordinary cluster maintenance and operation: replaced bad nodes, turn on xcatdebugmode...
|
||||
|
||||
5. cluster setup is stable now, export and commit the cluster configuration(commit no: c95673) ::
|
||||
|
||||
xcat-inventory export --format=yaml >/git/cluster/mycluster.yaml
|
||||
cd /git/cluster
|
||||
git diff
|
||||
git add xcat-inventory export --format=yaml >/git/cluster/mycluster.yaml
|
||||
git commit /git/cluster/mycluster.yaml -m "$(date "+%Y_%m_%d_%H_%M_%S"): replaced bad nodes; turn on xcatdebugmode; blah-blah"
|
||||
|
||||
6. ordinary cluster maintenance and operation, some issues are founded in current cluster, need to restore the current cluster configuration to commit no c95673 [1]_ ::
|
||||
|
||||
cd /git/cluster
|
||||
git checkout c95673
|
||||
xcat-inventory import -f /git/cluster/mycluster.yaml
|
||||
|
||||
*Notice:*
|
||||
|
||||
1. The cluster inventory data exported by ``xcat-inventory`` does not include intermidiate data, transiate data and historical data in xCAT DataBase, such as node status, auditlog table
|
||||
|
||||
2. We suggest you backup your xCAT database by ``dumpxCATdb`` before your trial on this feature, although we have run sufficient test on this
|
||||
|
||||
.. [1] When you import the inventory data to xCAT Database in step 6, there are 2 modes: ``clean mode`` and ``update mode``. If you choose the ``clean mode`` by ``xcat-inventory import -c|--clean``, all the objects definitions that are not included in the inventory file will be removed; Otherwise, only the objects included in the inventory file will be updated or inserted. Please choose the proper mode according to your need
|
||||
|
||||
|
||||
@@ -59,7 +59,7 @@ author = u'IBM Corporation'
|
||||
# The short X.Y version.
|
||||
version = '2'
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = '2.13.8'
|
||||
release = '2.13.11'
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
|
||||
@@ -1,87 +1,64 @@
|
||||
Enable Kdump Over Ethernet
|
||||
Enable kdump Over Ethernet
|
||||
==========================
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
kdump is an advanced crash dumping mechanism. When enabled, the system is booted from the context of another kernel. This second kernel reserves a small amount of memory, and its only purpose is to capture the core dump image in case the system crashes. Being able to analyze the core dump helps significantly to determine the exact cause of the system failure.
|
||||
kdump is an feature of the Linux kernel that allows the system to be booted from the context of another kernel. This second kernel reserves a small amount of memory and its only purpose is to capture the core dump in the event of a kernel crash. The ability to analyze the core dump helps to determine causes of system failures.
|
||||
|
||||
|
||||
xCAT Interface
|
||||
--------------
|
||||
|
||||
The pkglist, exclude and postinstall files location and name can be obtained by running the following command: ::
|
||||
The following attributes of an osimage should be modified to enable ``kdump``:
|
||||
|
||||
lsdef -t osimage <osimage name>
|
||||
* pkglist
|
||||
* exlist
|
||||
* postinstall
|
||||
* dump
|
||||
* crashkernelsize
|
||||
* postscripts
|
||||
|
||||
Here is an example: ::
|
||||
Configure the ``pkglist`` file
|
||||
------------------------------
|
||||
|
||||
lsdef -t osimage rhels7.1-ppc64le-netboot-compute
|
||||
Object name: rhels7.1-ppc64le-netboot-compute
|
||||
exlist=/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.exlist
|
||||
imagetype=linux
|
||||
osarch=ppc64le
|
||||
osdistroname=rhels7.1-ppc64le
|
||||
osname=Linux
|
||||
osvers=rhels7.1
|
||||
otherpkgdir=/install/post/otherpkgs/rhels7.1/ppc64le
|
||||
permission=755
|
||||
pkgdir=/install/rhels7.1/ppc64le
|
||||
pkglist=/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.pkglist
|
||||
postinstall=/opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.postinstall
|
||||
profile=compute
|
||||
provmethod=netboot
|
||||
rootimgdir=/install/netboot/rhels7.1/ppc64le/compute
|
||||
The ``pkglist`` for the osimage needs to include the appropriate RPMs. The following list of RPMs are provided as a sample, always refer to the Operating System specific documentataion to ensure the required packages are there for ``kdump`` support.
|
||||
|
||||
In above example, pkglist file is /opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.pkglist, exclude files is in /opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.exlist, and postinstall file is /opt/xcat/share/xcat/netboot/rh/compute.rhels7.ppc64le.postinstall.
|
||||
|
||||
Setup pkglist
|
||||
-------------
|
||||
|
||||
Before setting up kdump, the appropriate rpms should be added to the pkglist file.Here is the rpm packages list which needs to be added to pkglist file for kdump for different OS.
|
||||
|
||||
* **[RHEL]** ::
|
||||
* **[RHELS]** ::
|
||||
|
||||
kexec-tools
|
||||
crash
|
||||
|
||||
* **[SLES11]** ::
|
||||
* **[SLES]** ::
|
||||
|
||||
kdump
|
||||
kexec-tools
|
||||
makedumpfile
|
||||
|
||||
* **[SLES10]** ::
|
||||
|
||||
kernel-kdump
|
||||
kexec-tools
|
||||
kdump
|
||||
makedumpfile
|
||||
|
||||
* **[Ubuntu]** ::
|
||||
|
||||
<TODO>
|
||||
|
||||
The exclude file
|
||||
----------------
|
||||
Modify the ``exlist`` file
|
||||
--------------------------
|
||||
|
||||
The base diskless image excludes the /boot directory, but it is required for kdump. Update the exlist file and remove the entry for /boot. Then run the packimage or liteimg command to update your image with the changes.
|
||||
The default diskless image created by ``copycds`` excludes the ``/boot`` directory in the exclude list file, but this is required for ``kdump``.
|
||||
|
||||
<TODO exclude files list>
|
||||
Update the ``exlist`` for the target osimage and remove the line ``/boot``: ::
|
||||
|
||||
The postinstall file
|
||||
--------------------
|
||||
./boot* # <-- remove this line
|
||||
|
||||
The kdump will create a new initrd which used in the dumping stage. The /tmp or /var/tmp directory will be used as the temporary directory. These 2 directory only are allocated 10M space by default. You need to enlarge it to 200M. Modify the postinstall file to increase /tmp space.
|
||||
Run ``packimage`` to update the diskless image with the changes.
|
||||
|
||||
The ``postinstall`` file
|
||||
------------------------
|
||||
|
||||
The kdump will create a new initrd which used in the dumping stage. The ``/tmp`` or ``/var/tmp`` directory will be used as the temporary directory. These 2 directory only are allocated 10M space by default. You need to enlarge it to 200M. Modify the postinstall file to increase ``/tmp`` space.
|
||||
|
||||
* **[RHELS]** ::
|
||||
|
||||
tmpfs /var/tmp tmpfs defaults,size=200m 0 2
|
||||
|
||||
* **[SLES10]** ::
|
||||
|
||||
tmpfs /var/tmp tmpfs defaults,size=200m 0 2
|
||||
|
||||
* **[SLES11]** ::
|
||||
|
||||
tmpfs /tmp tmpfs defaults,size=200m 0 2
|
||||
@@ -90,105 +67,107 @@ The kdump will create a new initrd which used in the dumping stage. The /tmp or
|
||||
|
||||
<TODO>
|
||||
|
||||
The dump attribute
|
||||
------------------
|
||||
The ``dump`` attribute
|
||||
----------------------
|
||||
|
||||
In order to support kdump, the dump attribute was added into linuximage table, which is used to define the remote path where the crash information should be dumped to. Use the chdef command to change the image's dump attribute using the URI format. ::
|
||||
To support kernel dumps, the ``dump`` attribute **must** be set on the osimage definition. If not set, kdump service will not be enabled. The ``dump`` attribute defines the NFS remote path where the crash information is to be stored.
|
||||
|
||||
Use the ``chdef`` command to set a value of the ``dump`` attribute: ::
|
||||
|
||||
chdef -t osimage <image name> dump=nfs://<nfs_server_ip>/<kdump_path>
|
||||
|
||||
The <nfs_server_ip> can be excluded if the destination NFS server is the service or management node. ::
|
||||
If the NFS server is the Service Node or Management Node, the server can be left out: ::
|
||||
|
||||
chdef -t osimage <image name> dump=nfs:///<kdump_path>
|
||||
|
||||
The crashkernelsize attribute
|
||||
-----------------------------
|
||||
**Note:** Only NFS is currently supported as a storage location. 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.
|
||||
|
||||
For system x machine, on sles10 set the crashkernelsize attribute like this: ::
|
||||
|
||||
chdef -t osimage <image name> crashkernelsize=<size>M@16M
|
||||
The ``crashkernelsize`` attribute
|
||||
---------------------------------
|
||||
|
||||
On sles11 and rhels6 set the crashkernelsize attribute like this: ::
|
||||
To allow the Operating System to automatically reserve the appropriate amount of memory for the ``kdump`` kernel, set ``crashkernelsize=auto``.
|
||||
|
||||
For setting specific sizes, use the following example:
|
||||
|
||||
* For System X machines, set the ``crashkernelsize`` using this format: ::
|
||||
|
||||
chdef -t osimage <image name> crashkernelsize=<size>M
|
||||
|
||||
Where <size> recommended value is 256. For more information about the size can refer to the following information:
|
||||
`<https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-kdump.html#s2-kdump-configuration-cli>`_.
|
||||
|
||||
`<http://www.novell.com/support/kb/doc.php?id=3374462>`_.
|
||||
|
||||
`<https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-kdump-configuration-cli.html>`_.
|
||||
|
||||
For system p machine, set the crashkernelsize attribute to this: ::
|
||||
* For Power System AC922, set the ``crashkernelsize`` using this format: ::
|
||||
|
||||
chdef -t osimage <image name> crashkernelsize=<size>M
|
||||
|
||||
* For System P machines, set the ``crashkernelsize`` using this format: ::
|
||||
|
||||
chdef -t osimage <image name> crashkernelsize=<size>@32M
|
||||
|
||||
Where <size> recommended value is 256, more information can refer the kdump document for the system x.
|
||||
**Notes**: the value of the ``crashkernelsize`` depends on the total physical memory size on the machine. For more about size, refer to `Appedix`_
|
||||
|
||||
When your node starts, and you get a kdump start error like this: ::
|
||||
If kdump start error like this: ::
|
||||
|
||||
Your running kernel is using more than 70% of the amount of space you reserved for kdump, you should consider increasing your crashkernel
|
||||
|
||||
You should modify this attribute using this chdef command: ::
|
||||
The ``crashkernelsize`` is not large enough, you should change the ``crashkernelsize`` larger until the error message disappear.
|
||||
|
||||
chdef -t osimage <image name> crashkernelsize=512M@32M
|
||||
The ``enablekdump`` postscript
|
||||
------------------------------
|
||||
|
||||
If 512M@32M is not large enough, you should change the crashkernelsize larger like 1024M until the error message disappear.
|
||||
|
||||
The enablekdump postscript
|
||||
--------------------------
|
||||
|
||||
This postscript enablekdump is used to start the kdump service when the node is booting up. Add it to your nodes list of postscripts by running this command: ::
|
||||
xCAT provides a postscript ``enablekdump`` that can be added to the Nodes to automatically start the ``kdump`` service when the node boots. Add to the nodes using the following command: ::
|
||||
|
||||
chdef -t node <node range> -p postscripts=enablekdump
|
||||
|
||||
|
||||
Notes
|
||||
-----
|
||||
Manually trigger a kernel panic on Linux
|
||||
----------------------------------------
|
||||
|
||||
Currently, only NFS is supported for the setup of kdump.
|
||||
Normally, kernel ``panic()`` will trigger booting into capture kernel. Once the kernel panic is triggered, the node will reboot into the capture kernel, and a kernel dump (vmcore) will be automatically saved to the directory on the specified NFS server (``<nfs_server_ip>``).
|
||||
|
||||
If the dump attribute is not set, the kdump service will not be enabled.
|
||||
Check your Operating System specific documentation for the path where the kernel dump is saved. For example:
|
||||
|
||||
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.
|
||||
* **[RHELS6]** ::
|
||||
|
||||
How to trigger kernel panic on Linux
|
||||
------------------------------------
|
||||
|
||||
Normally, kernel panic() will trigger booting into capture kernel. Once the kernel panic is triggered, the node will reboot into the capture kernel, and a kernel dump (vmcore) will be automatically saved to the directory on the specified NFS server (<nfs_server_ip>).
|
||||
|
||||
#. For RHESL6 the directory is <kdump_path>/var/crash/<node_ip>-<time>/
|
||||
<kdump_path>/var/crash/<node_ip>-<time>/
|
||||
|
||||
#. For SLES11 the directory is <kdump_path>/<node hostname>/<date>
|
||||
* **[SLES11]** ::
|
||||
|
||||
#. For SLES10 the directory is <kdump_path>/<node hostname>
|
||||
|
||||
For Redhat and SLES11.1 testing, you can use the following commands: ::
|
||||
<kdump_path>/<node hostname>/<date>
|
||||
|
||||
To trigger a dump, use the following commands: ::
|
||||
|
||||
echo 1 > /proc/sys/kernel/sysrq
|
||||
echo c > /proc/sysrq-trigger
|
||||
|
||||
This will force the Linux kernel to crash, and the address-YYYY-MM-DD-HH:MM:SS/vmcore file will be copied to the location you have selected on the specified NFS server directory.
|
||||
This will force the Linux kernel to crash, and the ``address-YYYY-MM-DD-HH:MM:SS/vmcore`` file should be copied to the location you set on the NFS server.
|
||||
|
||||
Dump Analysis
|
||||
-------------
|
||||
|
||||
Once the system has returned from recovering the crash, you may wish to analyze the kernel dump file using the crash tool.
|
||||
Once the system has returned from recovering the crash, you can analyze the kernel dump using the ``crash`` tool.
|
||||
|
||||
1.Locate the recent vmcore dump file.
|
||||
#. Locate the recent vmcore dump file.
|
||||
|
||||
2.Locate the kernel file for the crash server(the kernel is under /tftpboot/xcat/netboot/<OS name="">/<ARCH>/<profile>/kernel on management node).
|
||||
#. Locate the kernel file for the crash server. The kernel is under ``/tftpboot/xcat/netboot/<OS name="">/<ARCH>/<profile>/kernel`` on the managenent node.
|
||||
|
||||
3.Once you have located a vmcore dump file and kernel file, call crash: ::
|
||||
#. Once you have located a vmcore dump file and kernel file, call ``crash``: ::
|
||||
|
||||
crash <vmcore_dump_file> <kernel_file>
|
||||
|
||||
If crash cannot find any files under /usr/lib/debug? Make sure you have the kernel-debuginfo package installed.
|
||||
**Note:** If ``crash`` cannot find any files, make sure you have the ``kernel-debuginfo`` package installed.
|
||||
|
||||
For more information about the dump analysis you can refer the following documents:
|
||||
Appedix
|
||||
-------
|
||||
|
||||
`<http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/s1-kdump-crash.html RHEL document>`_
|
||||
#. OS Documentations on kdump configuration:
|
||||
|
||||
`<http://www.novell.com/support/kb/doc.php?id=3374462 SLES document>`_
|
||||
* http://www.novell.com/support/kb/doc.php?id=3374462.
|
||||
|
||||
* https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-kdump-configuration-cli.html.
|
||||
|
||||
* https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/kernel_crash_dump_guide/sect-kdump-config-cli.
|
||||
|
||||
#. OS Documentation on dump analysis:
|
||||
|
||||
* http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/s1-kdump-crash.htmlRHELdocument
|
||||
|
||||
* http://www.novell.com/support/kb/doc.php?id=3374462SLESdocument
|
||||
|
||||
@@ -20,6 +20,7 @@ For example, kernel-3.10.0-229.ael7b.ppc64le.rpm means kernelver=3.10.0-229.ael7
|
||||
mkdir -p /install/kernels/3.10.0-229.ael7b.ppc64le
|
||||
cp /tmp/kernel-3.10.0-229.ael7b.ppc64le.rpm /install/kernels/3.10.0-229.ael7b.ppc64le
|
||||
createrepo /install/kernels/3.10.0-229.ael7b.ppc64le/
|
||||
chdef -t osimage <imagename> -p pkgdir=/install/kernels/3.10.0-229.ael7b.ppc64le/
|
||||
|
||||
Run genimage/packimage to update the image with the new kernel.
|
||||
Note: If downgrading the kernel, you may need to first remove the rootimg directory. ::
|
||||
@@ -44,7 +45,7 @@ The "4.6.ppc64le" is replaced with "4-ppc64le": ::
|
||||
cp /tmp/kernel-default-3.12.28-4.6.ppc64le.rpm /install/kernels/3.12.28-4-ppc64le/
|
||||
cp /tmp/kernel-default-base-3.12.28-4.6.ppc64le.rpm /install/kernels/3.12.28-4-ppc64le/
|
||||
cp /tmp/kernel-default-devel-3.12.28-4.6.ppc64le.rpm /install/kernels/3.12.28-4-ppc64le/
|
||||
|
||||
chdef -t osimage <imagename> -p pkgdir=/install/kernels/3.12.28-4-ppc64le/
|
||||
|
||||
Run genimage/packimage to update the image with the new kernel.
|
||||
Note: If downgrading the kernel, you may need to first remove the rootimg directory.
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
Configure routes
|
||||
-----------------
|
||||
|
||||
There are 2 ways to configure OS route in xCAT:
|
||||
|
||||
* ``makeroutes``: command to add or delete routes on the management node or any given nodes.
|
||||
* ``setroute``: script to replace/add the routes to the node, it can be used in postscripts/postbootscripts.
|
||||
|
||||
``makeroutes`` or ``setroute`` will modify OS temporary route, it also modifies persistent route in ``/etc/sysconfig/static-routes`` file.
|
||||
|
||||
Before using ``makeroutes`` or ``setroute`` to configure OS route, details of the routes data such as routename, subnet, net mask and gateway should be stored in ``routes`` table.
|
||||
|
||||
**Notes**: the ``gateway`` in the ``networks`` table assigns ``gateway`` from DHCP to compute node, so if use ``makeroutes`` or ``setroute`` to configure OS static route for compute node, make sure there is no ``gateway`` for the specific network in ``networks`` table.
|
||||
|
||||
Configure ``routes`` table
|
||||
``````````````````````````
|
||||
|
||||
#. Store default route data in ``routes`` table: ::
|
||||
|
||||
chdef -t route defaultroute net=default mask=255.0.0.0 gateway=10.0.0.101
|
||||
|
||||
#. Store additional route data in ``routes`` table: ::
|
||||
|
||||
chdef -t route 20net net=20.0.0.0 mask=255.0.0.0 gateway=0.0.0.0 ifname=eth1
|
||||
|
||||
#. Check data in ``routes`` table: ::
|
||||
|
||||
tabdump routes
|
||||
#routename,net,mask,gateway,ifname,comments,disable
|
||||
"30net","30.0.0.0","255.0.0.0","0.0.0.0","eth2",,
|
||||
"20net","20.0.0.0","255.0.0.0","0.0.0.0","eth1",,
|
||||
"defaultroute","default","255.0.0.0","10.0.0.101",,,
|
||||
|
||||
Use ``makeroutes`` to configure OS route on xCAT management node
|
||||
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
#. define the names of the routes to be setup on the management node in ``site`` table: ::
|
||||
|
||||
chdef -t site mnroutenames="defaultroute,20net"
|
||||
lsdef -t site clustersite -i mnroutenames
|
||||
Object name: clustersite
|
||||
mnroutenames=defaultroute,20net
|
||||
|
||||
#. add all routes from the ``mnroutenames`` to the OS route table for the management node: ::
|
||||
|
||||
makeroutes
|
||||
|
||||
#. add route ``20net`` and ``30net`` to the OS route table for the management node: ::
|
||||
|
||||
makeroutes -r 20net,30net
|
||||
|
||||
#. delete route ``20net`` from the OS route table for the management node: ::
|
||||
|
||||
makeroutes -d -r 20net
|
||||
|
||||
Use ``makeroutes`` to configure OS route for compute node
|
||||
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
#. define the names of the routes to be setup on the compute node: ::
|
||||
|
||||
chdef -t cn1 routenames="defaultroute,20net"
|
||||
|
||||
#. add all routes from the ``routenames`` to the OS route table for the compute node: ::
|
||||
|
||||
makeroutes cn1
|
||||
|
||||
#. add route ``20net`` and ``30net`` to the OS route table for the compute node: ::
|
||||
|
||||
makeroutes cn1 -r 20net,30net
|
||||
|
||||
#. delete route ``20net`` from the OS route table for the compute node: ::
|
||||
|
||||
makeroutes cn1,cn2 -d -r 20net
|
||||
|
||||
Use ``setroute`` to configure OS route for compute node
|
||||
'''''''''''''''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
#. define the names of the routes to be setup on the compute node: ::
|
||||
|
||||
chdef -t cn1 routenames="defaultroute,20net"
|
||||
|
||||
#. If adding ``setroute [replace | add]`` into the node’s postscripts list, ``setroute`` will be executed during OS deployment on compute node to replace/add routes from ``routenames``: ::
|
||||
|
||||
chdef cn1 -p postscripts="setroute replace"
|
||||
|
||||
#. Or if the compute node is already running, use ``updatenode`` command to run ``setroute [replace | add]`` postscript: ::
|
||||
|
||||
updatenode cn1 -P "setroute replace"
|
||||
|
||||
Check result
|
||||
````````````
|
||||
|
||||
#. Use ``route`` command in xCAT management node to check OS route table.
|
||||
|
||||
#. Use ``xdsh cn1 route`` to check compute node OS route table.
|
||||
@@ -161,7 +161,7 @@ When the VM has been created and powered on, choose one of the following methods
|
||||
* Use **rcons/wcons** on xCAT management node to open text console: ::
|
||||
|
||||
chdef vm1 cons=kvm
|
||||
makeconservercf vm1
|
||||
makegocons vm1
|
||||
rcons vm1
|
||||
|
||||
* Connect to virtual machine through vnc console
|
||||
|
||||
@@ -126,7 +126,7 @@ The BMC IP address is obtained by the open range dhcp server and the plan in thi
|
||||
|
||||
Configure the conserver for the **discovered** node to watch the discovery process using ``rcons``::
|
||||
|
||||
makeconservercf node-8247-22l-10112ca
|
||||
makegocons node-8247-22l-10112ca
|
||||
|
||||
In another terminal window, open the remote console: ::
|
||||
|
||||
|
||||
@@ -99,9 +99,9 @@ The BMC IP address is obtained by the open range dhcp server and the plan is to
|
||||
|
||||
#. **[Optional]** Monitor the node discovery process using rcons
|
||||
|
||||
Configure the conserver for the **predefined** node to watch the discovery process using ``rcons``::
|
||||
Configure the goconserver for the **predefined** node to watch the discovery process using ``rcons``::
|
||||
|
||||
makeconservercf cn01
|
||||
makegocons cn01
|
||||
|
||||
In another terminal window, open the remote console: ::
|
||||
|
||||
|
||||
@@ -34,5 +34,5 @@ To start discovery process, just need to power on the PBMC node remotely with th
|
||||
**[Optional]** If you'd like to monitor the discovery process, you can use::
|
||||
|
||||
chdef Server-8247-22L-SN10112CA cons=ipmi
|
||||
makeconservercf
|
||||
makegocons
|
||||
rcons Server-8247-22L-SN10112CA
|
||||
|
||||
@@ -25,5 +25,5 @@ To start discovery process, just need to power on the PBMC node remotely with th
|
||||
|
||||
**[Optional]** If you'd like to monitor the discovery process, you can use::
|
||||
|
||||
makeconservercf node-8247-42l-10112ca
|
||||
makegocons node-8247-42l-10112ca
|
||||
rcons node-8247-42l-10112ca
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
.. include:: ../../../../common/deployment/network/cfg_routes.rst
|
||||
@@ -8,3 +8,4 @@ This section describes how to configure network adapters with persistent configu
|
||||
|
||||
cfg_network_adapter.rst
|
||||
cfg_second_adapter.rst
|
||||
cfg_routes.rst
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
.. include:: ../../../../common/deployment/network/cfg_routes.rst
|
||||
@@ -8,3 +8,4 @@ This section describes how to configure network adapters with persistent configu
|
||||
|
||||
cfg_network_adapter.rst
|
||||
cfg_second_adapter.rst
|
||||
cfg_routes.rst
|
||||
|
||||
@@ -6,5 +6,5 @@ Advanced Operations
|
||||
|
||||
rinv.rst
|
||||
rvitals.rst
|
||||
rflash.rst
|
||||
rflash/index.rst
|
||||
rspconfig.rst
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
``rflash`` - Remote Firmware Flashing
|
||||
=====================================
|
||||
|
||||
See :doc:`rflash manpage </guides/admin-guides/references/man1/rflash.1>` for more information.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
ipmi.rst
|
||||
openbmc/index.rst
|
||||
@@ -1,7 +1,5 @@
|
||||
``rflash`` - Remote Firmware Flashing
|
||||
=====================================
|
||||
|
||||
See :doc:`rflash manpage </guides/admin-guides/references/man1/rflash.1>` for more information.
|
||||
IPMI Firmware Update
|
||||
====================
|
||||
|
||||
The ``rflash`` command is provided to assist the system administrator in updating firmware.
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
OpenBMC Firmware Update
|
||||
=======================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
manually.rst
|
||||
unattended.rst
|
||||
@@ -0,0 +1,10 @@
|
||||
Manual Firmware Flash
|
||||
=====================
|
||||
|
||||
.. include:: ./openbmc_common.rst
|
||||
:start-after: BEGIN_flashing_OpenBMC_Servers
|
||||
:end-before: END_flashing_OpenBMC_Servers
|
||||
|
||||
.. include:: ./openbmc_common.rst
|
||||
:start-after: BEGIN_Validation_OpenBMC_firmware
|
||||
:end-before: END_Validation_OpenBMC_firmware
|
||||
@@ -0,0 +1,100 @@
|
||||
.. BEGIN_unattended_OpenBMC_flashing
|
||||
|
||||
Unattended flash of OpenBMC firmware will do the following events:
|
||||
|
||||
#. Upload both BMC firmware file and PNOR firmware file
|
||||
#. Activate both BMC firmware and PNOR firmware
|
||||
#. If BMC firmware becomes activate, reboot BMC to apply new BMC firmware, or else, ``rflash`` will exit
|
||||
#. If BMC itself state is ``NotReady``, ``rflash`` will exit
|
||||
#. If BMC itself state is ``Ready``, and use ``--no-host-reboot`` option, ``rflash`` will not reboot the compute node
|
||||
#. If BMC itself state is ``Ready``, and do not use ``--no-host-reboot`` option, ``rflash`` will reboot the compute node to apply PNOR firmware
|
||||
|
||||
Use the following command to flash the firmware unattended: ::
|
||||
|
||||
rflash <noderange> -d /path/to/directory
|
||||
|
||||
Use the following command to flash the firmware unattended and not reboot the compute node: ::
|
||||
|
||||
rflash <noderange> -d /path/to/directory --no-host-reboot
|
||||
|
||||
If there are errors encountered during the flash process, take a look at the manual steps to continue flashing the BMC.
|
||||
|
||||
.. END_unattended_OpenBMC_flashing
|
||||
|
||||
.. BEGIN_flashing_OpenBMC_Servers
|
||||
|
||||
The sequence of events that must happen to flash OpenBMC firmware is the following:
|
||||
|
||||
#. Power off the Host
|
||||
#. Upload and Activate BMC
|
||||
#. Reboot the BMC (applies BMC)
|
||||
#. Upload and Activate PNOR
|
||||
#. Power on the Host (applies PNOR)
|
||||
|
||||
|
||||
Power off Host
|
||||
--------------
|
||||
|
||||
Use the rpower command to power off the host: ::
|
||||
|
||||
rpower <noderange> off
|
||||
|
||||
Upload and Activate BMC Firmware
|
||||
--------------------------------
|
||||
|
||||
Use the rflash command to upload and activate the PNOR firmware: ::
|
||||
|
||||
rflash <noderange> -a /path/to/obmc-phosphor-image-witherspoon.ubi.mtd.tar
|
||||
|
||||
If running ``rflash`` in Hierarchy, the firmware files must be accessible on the Service Nodes.
|
||||
|
||||
**Note:** If a .tar file is provided, the ``-a`` option does an upload and activate in one step. If an ID is provided, the ``-a`` option just does activate the specified firmware. After firmware is activated, use the ``rflash <noderange> -l`` to view. The ``rflash`` command shows ``(*)`` as the active firmware and ``(+)`` on the firmware that requires reboot to become effective.
|
||||
|
||||
Reboot the BMC
|
||||
--------------
|
||||
|
||||
Use the ``rpower`` command to reboot the BMC: ::
|
||||
|
||||
rpower <noderange> bmcreboot
|
||||
|
||||
The BMC will take 2-5 minutes to reboot, check the status using: ``rpower <noderange> bmcstate`` and wait for ``BMCReady`` to be returned.
|
||||
|
||||
**Known Issue:** On reboot, the first call to the BMC after reboot, xCAT will return ``Error: BMC did not respond within 10 seconds, retry the command.``. Please retry.
|
||||
|
||||
Upload and Activate PNOR Firmware
|
||||
---------------------------------
|
||||
|
||||
Use the rflash command to upload and activate the PNOR firmware: ::
|
||||
|
||||
rflash <noderange> -a /path/to/witherspoon.pnor.squashfs.tar
|
||||
|
||||
If running ``rflash`` in Hierarchy, the firmware files must be accessible on the Service Nodes.
|
||||
|
||||
**Note:** The ``-a`` option does an upload and activate in one step, after firmware is activated, use the ``rflash <noderange> -l`` to view. The ``rflash`` command shows ``(*)`` as the active firmware and ``(+)`` on the firmware that requires reboot to become effective.
|
||||
|
||||
Power on Host
|
||||
-------------
|
||||
|
||||
User the ``rpower`` command to power on the Host: ::
|
||||
|
||||
rpower <noderange> on
|
||||
|
||||
.. END_flashing_OpenBMC_Servers
|
||||
|
||||
.. BEGIN_Validation_OpenBMC_firmware
|
||||
|
||||
Validation
|
||||
----------
|
||||
|
||||
Use one of the following commands to validate firmware levels are in sync:
|
||||
|
||||
* Use the ``rinv`` command to validate firmware level: ::
|
||||
|
||||
rinv <noderange> firm -V | grep -i ibm | grep "\*" | xcoll
|
||||
|
||||
* Use the ``rflash`` command to validate the firmware level: ::
|
||||
|
||||
rflash <noderange> -l | grep "\*" | xcoll
|
||||
|
||||
|
||||
.. END_Validation_OpenBMC_firmware
|
||||
@@ -0,0 +1,10 @@
|
||||
Unattended Firmware Flash
|
||||
=========================
|
||||
|
||||
.. include:: ./openbmc_common.rst
|
||||
:start-after: BEGIN_unattended_OpenBMC_flashing
|
||||
:end-before: END_unattended_OpenBMC_flashing
|
||||
|
||||
.. include:: ./openbmc_common.rst
|
||||
:start-after: BEGIN_Validation_OpenBMC_firmware
|
||||
:end-before: END_Validation_OpenBMC_firmware
|
||||
@@ -28,7 +28,37 @@ Troubleshooting
|
||||
General
|
||||
```````
|
||||
|
||||
The xCAT ``rcons`` command relies on conserver (http://www.conserver.com/). The ``conserver`` package should have been installed with xCAT as it's part of the xCAT dependency package. If you are having problems seeing the console, try the following.
|
||||
``xCAT`` has been integrated with 3 kinds of console server service, they are
|
||||
|
||||
- `conserver <http://www.conserver.com/>`_
|
||||
- `goconserver <https://github.com/xcat2/goconserver/>`_
|
||||
- `confluent <https://github.com/xcat2/confluent/>`_
|
||||
|
||||
``rcons`` command relies on one of them. The ``conserver`` and ``goconserver``
|
||||
packages should have been installed with xCAT as they are part of the xCAT
|
||||
dependency packages. If you hope to try ``confluent``,
|
||||
see `confluent </advanced/confluent/>`_.
|
||||
|
||||
For systemd based systems, ``goconserver`` is used by default. If you are
|
||||
having problems seeing the console, try the following.
|
||||
|
||||
#. Make sure ``goconserver`` is configured by running ``makegocons``.
|
||||
|
||||
#. Check if ``goconserver`` is up and running ::
|
||||
|
||||
systemctl status goconserver.service
|
||||
|
||||
#. If ``goconserver`` is not running, start the service using: ::
|
||||
|
||||
systemctl start goconserver.service
|
||||
|
||||
#. Try ``makegocons -q [<node>]`` to verify if the node has been registered.
|
||||
|
||||
#. Invoke the console again: ``rcons <node>``
|
||||
|
||||
More details for goconserver, see `goconserver documentation </advanced/goconserver/>`_.
|
||||
|
||||
**[Deprecated]** If ``conserver`` is used, try the following.
|
||||
|
||||
#. Make sure ``conserver`` is configured by running ``makeconservercf``.
|
||||
|
||||
@@ -42,12 +72,4 @@ The xCAT ``rcons`` command relies on conserver (http://www.conserver.com/). The
|
||||
[sysvinit] service conserver start
|
||||
[systemd] systemctl start conserver.service
|
||||
|
||||
#. After this, try invoking the console again: ``rcons <node>``
|
||||
|
||||
|
||||
OpenBMC Specific
|
||||
````````````````
|
||||
|
||||
#. For OpenBMC managed servers, the root user must be able to ssh passwordless to the BMC for the ``rcons`` function to work.
|
||||
|
||||
Copy the ``/root/.ssh/id_rsa.pub`` public key to the BMC's ``~/.ssh/authorized_keys`` file.
|
||||
#. Invoke the console again: ``rcons <node>``
|
||||
|
||||
@@ -25,10 +25,6 @@ SYNOPSIS
|
||||
|
||||
\ **bmcdiscover**\ [\ **-**\ **-sn**\ \ *SN_nodename*\ ] [\ **-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**\
|
||||
|
||||
\ **bmcdiscover**\ [\ **-u**\ \ *bmc_user*\ ] [\ **-p**\ \ *bmc_passwd*\ ] \ **-i**\ \ *bmc_ip*\ \ **-**\ **-ipsource**\
|
||||
|
||||
|
||||
***********
|
||||
DESCRIPTION
|
||||
@@ -98,18 +94,6 @@ OPTIONS
|
||||
|
||||
|
||||
|
||||
\ **-**\ **-check**\
|
||||
|
||||
Check BMC administrator User/Password.
|
||||
|
||||
|
||||
|
||||
\ **-**\ **-ipsource**\
|
||||
|
||||
Display the BMC IP configuration.
|
||||
|
||||
|
||||
|
||||
\ **-h|-**\ **-help**\
|
||||
|
||||
Display usage message
|
||||
@@ -187,22 +171,6 @@ Output is similar to:
|
||||
bmcdiscover -s nmap --range "10.4.22-23.100-254" -w -z
|
||||
|
||||
|
||||
5. To check if the username or password is correct against the BMC:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
bmcdiscover -i 10.4.23.254 -u USERID -p PASSW0RD --check
|
||||
|
||||
|
||||
6. Get BMC IP Address source, DHCP Address or static Address
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
bmcdiscover -i 10.4.23.254 -u USERID -p PASSW0RD --ipsource
|
||||
|
||||
|
||||
|
||||
********
|
||||
SEE ALSO
|
||||
|
||||
@@ -19,7 +19,7 @@ SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **nodediscoverls**\ [\ **-t seq | profile | switch | blade | manual | mtms | undef | all**\ ] [\ **-l**\ ]
|
||||
\ **nodediscoverls**\ [\ **-t seq | profile | switch | blade | manual | undef | all**\ ] [\ **-l**\ ]
|
||||
|
||||
\ **nodediscoverls**\ [\ **-u**\ \ *uuid*\ ] [\ **-l**\ ]
|
||||
|
||||
@@ -47,7 +47,7 @@ OPTIONS
|
||||
|
||||
|
||||
|
||||
\ **-t seq|profile|switch|blade|manual|mtms|undef|all**\
|
||||
\ **-t seq|profile|switch|blade|manual|undef|all**\
|
||||
|
||||
Display the nodes that have been discovered by the specified discovery method:
|
||||
|
||||
@@ -72,10 +72,6 @@ OPTIONS
|
||||
|
||||
|
||||
|
||||
\* \ **mtms**\ - MTMS discovery (used when node mtm and serial fields are filled in).
|
||||
|
||||
|
||||
|
||||
\* \ **undef**\ - Display the nodes that were in the discovery pool, but for which xCAT has not yet received a discovery request.
|
||||
|
||||
|
||||
|
||||
@@ -11,11 +11,28 @@ SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **rbeacon**\ [\ **-h | -**\ **-help | -v | -**\ **-version | -V | -**\ **-verbose**\ ]
|
||||
|
||||
BMC (using IPMI):
|
||||
=================
|
||||
|
||||
|
||||
\ **rbeacon**\ \ *noderange*\ {\ **on | blink | off | stat**\ }
|
||||
|
||||
\ **rbeacon**\ [\ **-h | -**\ **-help**\ ]
|
||||
|
||||
\ **rbeacon**\ {\ **-v | -**\ **-version**\ }
|
||||
OpenPOWER BMC (using IPMI):
|
||||
===========================
|
||||
|
||||
|
||||
\ **rbeacon**\ \ *noderange*\ {\ **on | blink | off | stat**\ }
|
||||
|
||||
|
||||
OpenPOWER OpenBMC:
|
||||
==================
|
||||
|
||||
|
||||
\ **rbeacon**\ \ *noderange*\ {\ **on | off**\ }
|
||||
|
||||
|
||||
|
||||
***********
|
||||
|
||||
@@ -19,10 +19,17 @@ Name
|
||||
****************
|
||||
|
||||
|
||||
\ **reventlog**\ \ *noderange*\ {\ *number-of-entries*\ [\ **-s**\ ]|\ **all [-s] | clear**\ }
|
||||
\ **reventlog**\ \ *noderange*\ [\ *number-of-entries*\ [\ **-s**\ ]|\ **all [-s] | clear**\ ]
|
||||
|
||||
\ **reventlog**\ [\ **-h | -**\ **-help | -v | -**\ **-version**\ ]
|
||||
|
||||
OpenPOWER OpenBMC specific :
|
||||
============================
|
||||
|
||||
|
||||
\ **reventlog**\ \ *noderange*\ [\ **resolved=**\ {\ *id-list*\ |\ **LED**\ }]
|
||||
|
||||
|
||||
|
||||
*******************
|
||||
\ **Description**\
|
||||
@@ -64,6 +71,12 @@ logs are stored on each servers service processor.
|
||||
|
||||
|
||||
|
||||
\ **resolved=**\ {\ *id-list*\ |\ **LED**\ }
|
||||
|
||||
Mark event log entries as resolved. Use comma separated list of entry ids to specify individual entries. Use \ **LED**\ to mark as resolved all event log entries that contribute to LED fault.
|
||||
|
||||
|
||||
|
||||
\ **-h | -**\ **-help**\
|
||||
|
||||
Print help.
|
||||
@@ -83,7 +96,7 @@ logs are stored on each servers service processor.
|
||||
|
||||
|
||||
|
||||
1.
|
||||
1. List last 5 event log entries from node4 and node5
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
@@ -110,7 +123,7 @@ logs are stored on each servers service processor.
|
||||
|
||||
|
||||
|
||||
2.
|
||||
2. Clear all event log entries from node4 and node5
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
@@ -129,6 +142,27 @@ logs are stored on each servers service processor.
|
||||
|
||||
|
||||
|
||||
3. Mark as resolved all event log entries from node4 that contribute to LED fault
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
reventlog node4 resolved=LED
|
||||
|
||||
|
||||
Output is similar to:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
Attempting to resolve the following log entries: LED...
|
||||
node4: Resolved 51.
|
||||
node4: Resolved 52.
|
||||
node4: Resolved 58.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
********
|
||||
SEE ALSO
|
||||
|
||||
@@ -19,15 +19,15 @@ Name
|
||||
****************
|
||||
|
||||
|
||||
\ **rflash**\ [\ **-h | -**\ **-help**\ | \ **-v | -**\ **-version**\ ]
|
||||
\ **rflash**\ [\ **-h | -**\ **-help**\ | \ **-v | -**\ **-version**\ | \ **-V | -**\ **-verbose**\ ]
|
||||
|
||||
PPC (with HMC) specific:
|
||||
========================
|
||||
|
||||
|
||||
\ **rflash**\ \ *noderange*\ \ **-p**\ \ *directory*\ [\ **-**\ **-activate**\ {\ **concurrent | disruptive**\ }] [\ **-V | -**\ **-verbose**\ ]
|
||||
\ **rflash**\ \ *noderange*\ \ **-p**\ \ *directory*\ [\ **-**\ **-activate**\ {\ **concurrent | disruptive**\ }]
|
||||
|
||||
\ **rflash**\ \ *noderange*\ {\ **-**\ **-commit | -**\ **-recover**\ } [\ **-V | -**\ **-verbose**\ ]
|
||||
\ **rflash**\ \ *noderange*\ {\ **-**\ **-commit | -**\ **-recover**\ }
|
||||
|
||||
|
||||
PPC (without HMC, using Direct FSP Management) specific:
|
||||
@@ -50,7 +50,7 @@ OpenPOWER BMC specific (using IPMI):
|
||||
====================================
|
||||
|
||||
|
||||
\ **rflash**\ \ *noderange*\ [\ *hpm_file_path*\ | \ **-d**\ \ *data_directory*\ ] [\ **-c | -**\ **-check**\ ] [\ **-**\ **-retry=**\ \ *count*\ ] [\ **-V**\ ]
|
||||
\ **rflash**\ \ *noderange*\ [\ *hpm_file_path*\ | \ **-d**\ \ *data_directory*\ ] [\ **-c | -**\ **-check**\ ] [\ **-**\ **-retry=**\ \ *count*\ ]
|
||||
|
||||
\ **rflash**\ \ *noderange*\ \ **-**\ **-recover**\ \ *bmc_file_path*\
|
||||
|
||||
@@ -63,7 +63,9 @@ OpenPOWER OpenBMC specific :
|
||||
|
||||
\ **rflash**\ \ *noderange*\ \ *tar_file_path*\ {[\ **-c | -**\ **-check**\ ] | [\ **-a | -**\ **-activate**\ ] | [\ **-u | -**\ **-upload**\ ]}
|
||||
|
||||
\ **rflash**\ \ *noderange*\ \ *image_id*\ {[\ **-a | -**\ **-activate**\ ] | [\ **-d | -**\ **-delete**\ ]}
|
||||
\ **rflash**\ \ *noderange*\ \ *tar_file_directory*\ [\ **-d**\ ] [\ **-**\ **-no-host-reboot**\ ]
|
||||
|
||||
\ **rflash**\ \ *noderange*\ \ *image_id*\ {[\ **-a | -**\ **-activate**\ ] | [\ **-**\ **-delete**\ ]}
|
||||
|
||||
|
||||
|
||||
@@ -135,17 +137,47 @@ OpenPOWER specific (using IPMI):
|
||||
================================
|
||||
|
||||
|
||||
The command will update firmware for OpenPOWER BMC when given an OpenPOWER node and either the hpm formatted file path or path to a data directory.
|
||||
The command will update firmware for OpenPOWER BMC when given an OpenPOWER node with \ *mgt=ipmi*\ and either the hpm formatted file path or path to a data directory.
|
||||
|
||||
\ **Note:**\ When using \ **rflash**\ in hierarchical environment, the hpm file or data directory must be accessible from Service Nodes.
|
||||
|
||||
|
||||
OpenPOWER OpenBMC specific:
|
||||
===========================
|
||||
OpenPOWER specific (using OpenBMC):
|
||||
===================================
|
||||
|
||||
|
||||
The command will update firmware for OpenPOWER OpenBMC when given an OpenPOWER node and either an update .tar file or an uploaded image id.
|
||||
The command will update firmware for OpenPOWER BMC when given an OpenPOWER node with \ *mgt=openbmc*\ and either an update .tar file or an uploaded image id.
|
||||
|
||||
\ **-l|-**\ **-list**\ :
|
||||
|
||||
The list option will list out available firmware on the BMC. It provides an interface to display the ID of the various firmware levels.
|
||||
|
||||
The (\*) symbol indicates the active running firmware on the server.
|
||||
|
||||
The (+) symbol indicates the firmware that is pending and a reboot is required to set it to be the active running firmware level.
|
||||
|
||||
\ **-u|-**\ **-upload**\ :
|
||||
|
||||
The upload option expects a .tar file as the input and will upload the file to the BMC. Use the list option to view the result.
|
||||
|
||||
\ **-a|-**\ **-activate**\ :
|
||||
|
||||
The activate option expects either a .tar file or an ID as the input. If a .tar file is provided, it will upload and activate the firmware in a single step
|
||||
|
||||
To apply the firmware level, a reboot is required to BMC and HOST.
|
||||
|
||||
\ **Note:**\ When using \ **rflash**\ in hierarchical environment, the .tar file must be accessible from Service Nodes.
|
||||
|
||||
\ **-d**\ :
|
||||
|
||||
This option steamlines the update, activate, reboot BMC and reboot HOST procedure. It expects a directory containing both BMC and PNOR .tar files. When BMC and PNOR tar files are provided, the command will upload and activate firmware. After BMC becomes activate, it will reboot BMC. If BMC state is Ready, the command will reboot the HOST. If BMC state is NotReady, the command will exit.
|
||||
|
||||
\ **Note:**\ When using \ **-**\ **-no-host-reboot**\ , it will not reboot the host after BMC is reboot.
|
||||
|
||||
\ **-**\ **-delete**\ :
|
||||
|
||||
This delete option will delete update image from BMC. It expects an ID as the input.
|
||||
|
||||
|
||||
|
||||
***************
|
||||
@@ -232,7 +264,7 @@ The command will update firmware for OpenPOWER OpenBMC when given an OpenPOWER n
|
||||
|
||||
|
||||
|
||||
\ **-d|-**\ **-delete**\
|
||||
\ **-**\ **-delete**\
|
||||
|
||||
Delete update image from BMC
|
||||
|
||||
@@ -325,7 +357,7 @@ The command will update firmware for OpenPOWER OpenBMC when given an OpenPOWER n
|
||||
|
||||
|
||||
|
||||
6. To update the firmware on IBM Power S822LC for Big Data machine specify the node name and the file path of the data directory containing pUpdate utility and BMC and/or PNOR update files:
|
||||
6. To update the firmware on IBM Power S822LC for Big Data machine specify the node name and the file path of the data directory containing pUpdate utility, both BMC and PNOR update files:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
@@ -340,7 +372,7 @@ The command will update firmware for OpenPOWER OpenBMC when given an OpenPOWER n
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
rflash p9euh02 -a /tmp/witherspoon.pnor.squashfs.tar
|
||||
rflash p9euh02 -a /tmp/witherspoon.pnor.squashfs.tar
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -90,7 +90,7 @@ OPTIONS
|
||||
|
||||
\ **-C|-**\ **-cleanup**\
|
||||
|
||||
Perform additional cleanup by running \ **nodeset offline**\ on the objects specified in the \ *noderange*\ .
|
||||
Perform additional cleanup by running \ **nodeset offline**\, \ **makeconservercf -d**\ and \ **makegocons --cleanup**\ on the objects specified in the \ *noderange*\ .
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ BMC (using IPMI):
|
||||
=================
|
||||
|
||||
|
||||
\ **rpower**\ \ *noderange*\ [\ **on | off | softoff | reset | boot | stat | state | status | wake | suspend**\ [\ **-w**\ \ *timeout*\ ] [\ **-o**\ ] [\ **-r**\ ]]
|
||||
\ **rpower**\ \ *noderange*\ [\ **on | off | softoff | reset | boot | cycle | stat | state | status | wake | suspend**\ [\ **-w**\ \ *timeout*\ ] [\ **-o**\ ] [\ **-r**\ ]]
|
||||
|
||||
\ **rpower**\ \ *noderange*\ [\ **pduon | pduoff | pdustat | pdureset**\ ]
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ SYNOPSIS
|
||||
|
||||
\ **rsetboot**\ \ *noderange*\ [\ **hd | net | cd | default | stat**\ ] [\ **-u**\ ] [\ **-p**\ ]
|
||||
|
||||
\ **rsetboot**\ [\ **-h | -**\ **-help | -v | -**\ **-version**\ ]
|
||||
\ **rsetboot**\ [\ **-h | -**\ **-help | -v | -**\ **-version | -V | -**\ **-verbose**\ ]
|
||||
|
||||
|
||||
***********
|
||||
@@ -62,7 +62,7 @@ OPTIONS
|
||||
|
||||
\ **-u**\
|
||||
|
||||
To specify the next boot mode to be "UEFI Mode".
|
||||
To specify the next boot mode to be "UEFI Mode". (Not supported for OpenBMC)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **rspconfig**\ [\ **-h | -**\ **-help | -v | -**\ **-version**\ ]
|
||||
\ **rspconfig**\ [\ **-h | -**\ **-help | -v | -**\ **-version | -V | -**\ **-verbose**\ ]
|
||||
|
||||
BMC/MPA specific:
|
||||
=================
|
||||
@@ -47,7 +47,45 @@ OpenBMC specific:
|
||||
=================
|
||||
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ {\ **ipsrc | ip | netmask | gateway | hostname | vlan | sshcfg**\ }
|
||||
\ **rspconfig**\ \ *noderange*\ {\ **ipsrc | ip | netmask | gateway | vlan**\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **admin_passwd**\ ={\ *currentpasswd,newpasswd*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **autoreboot**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **autoreboot={0|1}**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **bootmode**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **bootmode={safe|regular|setup}**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **dump**\ [\ **-l | -**\ **-list**\ ] [\ **-g | -**\ **-generate**\ ] [\ **-c | -**\ **-clear**\ {\ *id*\ | \ **all**\ }] [\ **-d | -**\ **-download**\ {\ *id*\ | \ **all**\ }]
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **gard -c|-**\ **-clear**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **ip=dhcp**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **hostname**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **hostname**\ ={\* | \ *name*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **ntpservers**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **ntpservers**\ ={\ *ntpservers*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **powerrestorepolicy**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **powerrestorepolicy={always_on|restore|always_off}**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **powersupplyredundancy**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **powersupplyredundancy={disabled|enabled}**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **sshcfg**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **timesyncmethod**\
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **timesyncmethod={manual|ntp}**\
|
||||
|
||||
|
||||
MPA specific:
|
||||
@@ -113,9 +151,9 @@ FSP/CEC specific:
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **admin_passwd**\ ={\ *currentpasswd,newpasswd*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **general_passwd**\ ={\ **currentpasswd,newpasswd**\ }
|
||||
\ **rspconfig**\ \ *noderange*\ \ **general_passwd**\ ={\ *currentpasswd,newpasswd*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \*\ **_passwd**\ ={\ **currentpasswd,newpasswd**\ }
|
||||
\ **rspconfig**\ \ *noderange*\ \*\ **_passwd**\ ={\ *currentpasswd,newpasswd*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ {\ *hostname*\ }
|
||||
|
||||
@@ -176,9 +214,9 @@ FSP/CEC (using Direct FSP Management) Specific:
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **admin_passwd**\ ={\ *currentpasswd,newpasswd*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **general_passwd**\ ={\ **currentpasswd,newpasswd**\ }
|
||||
\ **rspconfig**\ \ *noderange*\ \ **general_passwd**\ ={\ *currentpasswd,newpasswd*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \*\ **_passwd**\ ={\ **currentpasswd,newpasswd**\ }
|
||||
\ **rspconfig**\ \ *noderange*\ \*\ **_passwd**\ ={\ *currentpasswd,newpasswd*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ {\ **sysname**\ }
|
||||
|
||||
@@ -215,9 +253,9 @@ BPA/Frame (using Direct FSP Management) Specific:
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **admin_passwd**\ ={\ *currentpasswd,newpasswd*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \ **general_passwd**\ ={\ **currentpasswd,newpasswd**\ }
|
||||
\ **rspconfig**\ \ *noderange*\ \ **general_passwd**\ ={\ *currentpasswd,newpasswd*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ \*\ **_passwd**\ ={\ **currentpasswd,newpasswd**\ }
|
||||
\ **rspconfig**\ \ *noderange*\ \*\ **_passwd**\ ={\ *currentpasswd,newpasswd*\ }
|
||||
|
||||
\ **rspconfig**\ \ *noderange*\ {\ **frame**\ }
|
||||
|
||||
@@ -340,6 +378,12 @@ OPTIONS
|
||||
|
||||
|
||||
|
||||
\ **gard -c|-**\ **-clear**\
|
||||
|
||||
Clear gard file. [OpenBMC]
|
||||
|
||||
|
||||
|
||||
\ **garp**\ =\ *time*\
|
||||
|
||||
Get or set Gratuitous ARP generation interval. The unit is number of 1/2 second.
|
||||
@@ -430,6 +474,59 @@ OPTIONS
|
||||
|
||||
|
||||
|
||||
\ **powerrestorepolicy**\
|
||||
|
||||
Display or control BMC Power Restore Policy attribute setting. [OpenBMC]
|
||||
|
||||
|
||||
|
||||
\ **powersupplyredundancy**\
|
||||
|
||||
Display or control BMC Power Supply Redundancy attribute setting. [OpenBMC]
|
||||
|
||||
|
||||
|
||||
\ **autoreboot**\
|
||||
|
||||
Display or control BMC Auto Reboot attribute setting. [OpenBMC]
|
||||
|
||||
|
||||
|
||||
\ **bootmode**\
|
||||
|
||||
Display or control BMC Boot Mode attribute setting. [OpenBMC]
|
||||
|
||||
|
||||
|
||||
\ **dump**\
|
||||
|
||||
Generate/Manage BMC system dumps. If no sub-option is provided, will generate, wait, and download the dump. [OpenBMC]
|
||||
|
||||
|
||||
\ **-c**\ will clear a single specified dump, or use 'all' to clear all dumps on the BMC.
|
||||
|
||||
|
||||
|
||||
\ **-l**\ will list all the generated dumps on the BMC.
|
||||
|
||||
|
||||
|
||||
\ **-g**\ will generate a new dump on the BMC. Dump generation can take a few minutes.
|
||||
|
||||
|
||||
|
||||
\ **-d**\ will download a single dump or all generated dumps from the BMC to /var/log/xcat/dump on management or service node.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
\ **timesyncmethod**\
|
||||
|
||||
Set the method for time synchronization on the BMC. [OpenBMC]
|
||||
|
||||
|
||||
|
||||
\ **network**\ ={[\ *ip*\ ],[\ *host*\ ],[\ *gateway*\ ],[\ *netmask*\ ]|\*}
|
||||
|
||||
For MPA: get or set the MPA network parameters. If '\*' is specified, all parameters are read from the xCAT database.
|
||||
@@ -477,6 +574,12 @@ OPTIONS
|
||||
|
||||
|
||||
|
||||
\ **ntpservers**\
|
||||
|
||||
Get or set NTP servers name. [OpenBMC]
|
||||
|
||||
|
||||
|
||||
\ **pd1**\ ={\ **nonred | redwoperf | redwperf**\ }
|
||||
|
||||
Power Domain 1 - determines how an MPA responds to a loss of redundant power.
|
||||
@@ -1230,6 +1333,48 @@ EXAMPLES
|
||||
|
||||
|
||||
|
||||
31. To list BMC dumps available for download:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
rspconfig p9euh02 dump -l
|
||||
|
||||
|
||||
Output is similar to:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
p9euh02: [1] Generated: 09/06/2017 14:31:49, Size: 4528
|
||||
p9euh02: [2] Generated: 09/06/2017 14:31:55, Size: 4516
|
||||
p9euh02: [3] Generated: 09/06/2017 14:32:01, Size: 4236
|
||||
p9euh02: [4] Generated: 09/06/2017 14:32:07, Size: 4248
|
||||
p9euh02: [5] Generated: 09/06/2017 14:32:11, Size: 4268
|
||||
|
||||
|
||||
|
||||
|
||||
32. To generate and download BMC dump:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
rspconfig p9euh02 dump
|
||||
|
||||
|
||||
Output is similar to:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
Capturing BMC Diagnostic information, this will take some time...
|
||||
p9euh02: Dump requested. Target ID is 6, waiting for BMC to generate...
|
||||
p9euh02: Dump 6 generated. Downloading to /var/log/xcat/dump/20171211-0951_p9euh02_dump_6.tar.xz
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
********
|
||||
SEE ALSO
|
||||
|
||||
@@ -67,7 +67,7 @@ OpenPOWER (OpenBMC) specific:
|
||||
=============================
|
||||
|
||||
|
||||
\ **rvitals**\ \ *noderange*\ [\ **temp | voltage | wattage | fanspeed | power | altitude | all**\ ]
|
||||
\ **rvitals**\ \ *noderange*\ [\ **temp | voltage | wattage | fanspeed | power | leds | altitude | all**\ ]
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -62,7 +62,7 @@ be applied to a range of nodes, often in parallel.
|
||||
If you invoke xCAT \ **noderange**\ from a shell you may need to quote the
|
||||
\ **noderange**\ if the shell would otherwise treat the punctuation marks in
|
||||
the \ **noderange**\ as control operators. The affected punctuation marks may
|
||||
include Asterisk (\`*'), Left Square Bracket (\`[') , Right Square Bracket
|
||||
include Asterisk (\`\*'), Left Square Bracket (\`[') , Right Square Bracket
|
||||
(\`]'), Circumflex Accent (\`^'), and Overline (\`~').
|
||||
|
||||
\ **noderange**\ is a comma-separated list. Each token (text between commas)
|
||||
@@ -367,10 +367,12 @@ Example of \ **xCAT Node Name Format**\ node/group names:
|
||||
\ **Bugs**\
|
||||
************
|
||||
|
||||
|
||||
The special characters used by xCAT \ **noderange**\ are also special characters
|
||||
to many shell programs. In particular, the characters \`*', \`[', \`]', \`^',
|
||||
to many shell programs. In particular, the characters \`\*', \`[', \`]', \`^',
|
||||
and \`~' may have to be escaped from the shell.
|
||||
|
||||
|
||||
****************
|
||||
\ **SEE ALSO**\
|
||||
****************
|
||||
|
||||
@@ -80,7 +80,7 @@ linuximage Attributes:
|
||||
|
||||
\ **otherpkgdir**\
|
||||
|
||||
The base directory where the non-distro packages are stored. Only 1 local directory supported at present.
|
||||
The base directory and urls of internet repos from which the non-distro packages are retrived. Only 1 local directory is supported at present. The entries should be delimited with comma ",". Currently, the internet repos are only supported on Ubuntu and Redhat.
|
||||
|
||||
|
||||
|
||||
@@ -97,15 +97,15 @@ linuximage Attributes:
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
IMG_ARCH(The architecture of the osimage, such as "ppc64le","x86_64"),
|
||||
IMG_NAME(The name of the osimage, such as "rhels7.3-ppc64le-netboot-compute"),
|
||||
IMG_OSVER(The os release of the osimage, such as "rhels7.3","sles11.4"),
|
||||
IMG_ARCH(The architecture of the osimage, such as "ppc64le","x86_64"),
|
||||
IMG_NAME(The name of the osimage, such as "rhels7.3-ppc64le-netboot-compute"),
|
||||
IMG_OSVER(The os release of the osimage, such as "rhels7.3","sles11.4"),
|
||||
IMG_KERNELVERSION(the "kernelver" attribute of the osimage),
|
||||
IMG_PROFILE(the profile of the osimage, such as "service","compute"),
|
||||
IMG_PKGLIST(the "pkglist" attribute of the osimage),
|
||||
IMG_PKGDIR(the "pkgdir" attribute of the osimage),
|
||||
IMG_OTHERPKGLIST(the "otherpkglist" attribute of the osimage),
|
||||
IMG_OTHERPKGDIR(the "otherpkgdir" attribute of the osimage),
|
||||
IMG_PROFILE(the profile of the osimage, such as "service","compute"),
|
||||
IMG_PKGLIST(the "pkglist" attribute of the osimage),
|
||||
IMG_PKGDIR(the "pkgdir" attribute of the osimage),
|
||||
IMG_OTHERPKGLIST(the "otherpkglist" attribute of the osimage),
|
||||
IMG_OTHERPKGDIR(the "otherpkgdir" attribute of the osimage),
|
||||
IMG_ROOTIMGDIR(the "rootimgdir" attribute of the osimage)
|
||||
|
||||
|
||||
|
||||
@@ -60,8 +60,13 @@ nics Attributes:
|
||||
<nic1>!<ext1>,<nic2>!<ext2>,..., for example, eth0!-eth0,ib0!-ib0
|
||||
If multiple ip addresses are associated with each NIC:
|
||||
<nic1>!<ext1>|<ext2>,<nic2>!<ext1>|<ext2>,..., for example, eth0!-eth0|-eth0-ipv6,ib0!-ib0|-ib0-ipv6.
|
||||
The xCAT object definition commands support to use nichostnamesuffixes.<nicname> as the sub attributes.
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-),and period (.). When you are specifying "nichostnamesuffixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
The xCAT object definition commands support to use nichostnamesuffixes.<nicname> as the sub attributes.
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9) and minus sign (-). When you are specifying "nichostnamesuffixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -73,7 +78,7 @@ nics Attributes:
|
||||
If multiple ip addresses are associated with each NIC:
|
||||
<nic1>!<ext1>|<ext2>,<nic2>!<ext1>|<ext2>,..., for example, eth0!eth0-|eth0-ipv6i-,ib0!ib-|ib-ipv6-.
|
||||
The xCAT object definition commands support to use nichostnameprefixes.<nicname> as the sub attributes.
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-),and period (.). When you are specifying "nichostnameprefixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9) and minus sign (-). When you are specifying "nichostnameprefixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
|
||||
|
||||
|
||||
@@ -128,8 +133,7 @@ nics Attributes:
|
||||
|
||||
\ **nicsadapter**\
|
||||
|
||||
Comma-separated list of extra parameters that will be used for each NIC configuration.
|
||||
<nic1>!<param1=value1 param2=value2>,<nic2>!<param4=value4 param5=value5>, for example, enP3p3s0f1!mac=98:be:94:59:fa:cd linkstate=DOWN,enP3p3s0f2!mac=98:be:94:59:fa:ce candidatename=enP3p3s0f2/enx98be9459face
|
||||
Comma-separated list of NIC information collected by getadapter. <nic1>!<param1=value1 param2=value2>,<nic2>!<param4=value4 param5=value5>, for example, enP3p3s0f1!mac=98:be:94:59:fa:cd linkstate=DOWN,enP3p3s0f2!mac=98:be:94:59:fa:ce candidatename=enP3p3s0f2/enx98be9459face
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **nodehm Attributes:**\ \ *node*\ , \ *power*\ , \ *mgt*\ , \ *cons*\ , \ *termserver*\ , \ *termport*\ , \ *conserver*\ , \ *serialport*\ , \ *serialspeed*\ , \ *serialflow*\ , \ *getmac*\ , \ *cmdmapping*\ , \ *consoleondemand*\ , \ *comments*\ , \ *disable*\
|
||||
\ **nodehm Attributes:**\ \ *node*\ , \ *power*\ , \ *mgt*\ , \ *cons*\ , \ *termserver*\ , \ *termport*\ , \ *conserver*\ , \ *serialport*\ , \ *serialspeed*\ , \ *serialflow*\ , \ *getmac*\ , \ *cmdmapping*\ , \ *consoleondemand*\ , \ *consoleenabled*\ , \ *comments*\ , \ *disable*\
|
||||
|
||||
|
||||
***********
|
||||
@@ -114,6 +114,12 @@ nodehm Attributes:
|
||||
|
||||
|
||||
|
||||
\ **consoleenabled**\
|
||||
|
||||
A flag field to indicate whether the node is registered in the console server. If '1', console is enabled, if not set, console is not enabled.
|
||||
|
||||
|
||||
|
||||
\ **comments**\
|
||||
|
||||
Any user-written notes.
|
||||
|
||||
@@ -50,7 +50,7 @@ nodelist Attributes:
|
||||
|
||||
\ **status**\
|
||||
|
||||
The current status of this node. This attribute will be set by xCAT software. Valid values: defined, booting, netbooting, booted, discovering, configuring, installing, alive, standingby, powering-off, unreachable. If blank, defined is assumed. The possible status change sequences are: For installation: defined->[discovering]->[configuring]->[standingby]->installing->booting->booted->[alive], For diskless deployment: defined->[discovering]->[configuring]->[standingby]->netbooting->booted->[alive], For booting: [alive/unreachable]->booting->[alive], For powering off: [alive]->powering-off->[unreachable], For monitoring: alive->unreachable. Discovering and configuring are for x Series discovery process. Alive and unreachable are set only when there is a monitoring plug-in start monitor the node status for xCAT. Note that the status values will not reflect the real node status if you change the state of the node from outside of xCAT (i.e. power off the node using HMC GUI).
|
||||
The current status of this node. This attribute will be set by xCAT software. Valid values: defined, booting, netbooting, booted, discovering, configuring, installing, alive, standingby, powering-off, unreachable. If blank, defined is assumed. The possible status change sequences are: For installation: defined->[discovering]->[configuring]->[standingby]->installing->booting->[postbooting]->booted->[alive], For diskless deployment: defined->[discovering]->[configuring]->[standingby]->netbooting->[postbooting]->booted->[alive], For booting: [alive/unreachable]->booting->[postbooting]->booted->[alive], For powering off: [alive]->powering-off->[unreachable], For monitoring: alive->unreachable. Discovering and configuring are for x Series discovery process. Alive and unreachable are set only when there is a monitoring plug-in start monitor the node status for xCAT. Note that the status values will not reflect the real node status if you change the state of the node from outside of xCAT (i.e. power off the node using HMC GUI).
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -55,8 +55,8 @@ noderes Attributes:
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
Arch OS valid netboot options
|
||||
x86, x86_64 ALL pxe, xnba
|
||||
Arch OS valid netboot options
|
||||
x86, x86_64 ALL pxe, xnba
|
||||
ppc64 <=rhel6, <=sles11.3 yaboot
|
||||
ppc64 >=rhels7, >=sles11.4 grub2,grub2-http,grub2-tftp
|
||||
ppc64le NonVirtualize ALL petitboot
|
||||
|
||||
@@ -19,7 +19,7 @@ SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **pdu Attributes:**\ \ *node*\ , \ *nodetype*\ , \ *outlet*\ , \ *machinetype*\ , \ *modelnum*\ , \ *serialnum*\ , \ *comments*\ , \ *disable*\
|
||||
\ **pdu Attributes:**\ \ *node*\ , \ *nodetype*\ , \ *pdutype*\ , \ *outlet*\ , \ *username*\ , \ *password*\ , \ *snmpversion*\ , \ *community*\ , \ *snmpuser*\ , \ *authtype*\ , \ *authkey*\ , \ *privtype*\ , \ *privkey*\ , \ *seclevel*\ , \ *comments*\ , \ *disable*\
|
||||
|
||||
|
||||
***********
|
||||
@@ -48,27 +48,75 @@ pdu Attributes:
|
||||
|
||||
|
||||
|
||||
\ **pdutype**\
|
||||
|
||||
The type of pdu
|
||||
|
||||
|
||||
|
||||
\ **outlet**\
|
||||
|
||||
The pdu outlet count
|
||||
|
||||
|
||||
|
||||
\ **machinetype**\
|
||||
\ **username**\
|
||||
|
||||
The pdu machine type
|
||||
The remote login user name
|
||||
|
||||
|
||||
|
||||
\ **modelnum**\
|
||||
\ **password**\
|
||||
|
||||
The pdu model number
|
||||
The remote login password
|
||||
|
||||
|
||||
|
||||
\ **serialnum**\
|
||||
\ **snmpversion**\
|
||||
|
||||
The pdu serial number
|
||||
The version to use to communicate with switch. SNMPv1 is assumed by default.
|
||||
|
||||
|
||||
|
||||
\ **community**\
|
||||
|
||||
The community string to use for SNMPv1/v2
|
||||
|
||||
|
||||
|
||||
\ **snmpuser**\
|
||||
|
||||
The username to use for SNMPv3 communication, ignored for SNMPv1
|
||||
|
||||
|
||||
|
||||
\ **authtype**\
|
||||
|
||||
The authentication protocol(MD5|SHA) to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
\ **authkey**\
|
||||
|
||||
The authentication passphrase for SNMPv3
|
||||
|
||||
|
||||
|
||||
\ **privtype**\
|
||||
|
||||
The privacy protocol(AES|DES) to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
\ **privkey**\
|
||||
|
||||
The privacy passphrase to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
\ **seclevel**\
|
||||
|
||||
The Security Level(noAuthNoPriv|authNoPriv|authPriv) to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -44,67 +44,67 @@ servicenode Attributes:
|
||||
|
||||
\ **nameserver**\
|
||||
|
||||
Do we set up DNS on this service node? Valid values: 2, 1, no or 0. If 2, creates named.conf as dns slave, using the management node as dns master, and starts named. If 1, creates named.conf file with forwarding to the management node and starts named. If no or 0, it does not change the current state of the service.
|
||||
Do we set up DNS on this service node? Valid values: 2, 1, or 0. If 2, creates named.conf as dns slave, using the management node as dns master, and starts named. If 1, creates named.conf file with forwarding to the management node and starts named. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **dhcpserver**\
|
||||
|
||||
Do we set up DHCP on this service node? Not supported on AIX. Valid values:yes or 1, no or 0. If yes, runs makedhcp -n. If no or 0, it does not change the current state of the service.
|
||||
Do we set up DHCP on this service node? Not supported on AIX. Valid values:1 or 0. If 1, runs makedhcp -n. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **tftpserver**\
|
||||
|
||||
Do we set up TFTP on this service node? Not supported on AIX. Valid values:yes or 1, no or 0. If yes, configures and starts atftp. If no or 0, it does not change the current state of the service.
|
||||
Do we set up TFTP on this service node? Not supported on AIX. Valid values:1 or 0. If 1, configures and starts atftp. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **nfsserver**\
|
||||
|
||||
Do we set up file services (HTTP,FTP,or NFS) on this service node? For AIX will only setup NFS, not HTTP or FTP. Valid values:yes or 1, no or 0.If no or 0, it does not change the current state of the service.
|
||||
Do we set up file services (HTTP,FTP,or NFS) on this service node? For AIX will only setup NFS, not HTTP or FTP. Valid values:1 or 0.If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **conserver**\
|
||||
|
||||
Do we set up Conserver on this service node? Valid values:yes or 1, no or 0. If yes, configures and starts conserver daemon. If no or 0, it does not change the current state of the service.
|
||||
Do we set up console service on this service node? Valid values: 0, 1, or 2. If 0, it does not change the current state of the service. If 1, configures and starts conserver daemon. If 2, configures and starts goconserver daemon.
|
||||
|
||||
|
||||
|
||||
\ **monserver**\
|
||||
|
||||
Is this a monitoring event collection point? Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Is this a monitoring event collection point? Valid values: 1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **ldapserver**\
|
||||
|
||||
Do we set up ldap caching proxy on this service node? Not supported on AIX. Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Do we set up ldap caching proxy on this service node? Not supported on AIX. Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **ntpserver**\
|
||||
|
||||
Not used. Use setupntp postscript to setup a ntp server on this service node? Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Not used. Use setupntp postscript to setup a ntp server on this service node? Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **ftpserver**\
|
||||
|
||||
Do we set up a ftp server on this service node? Not supported on AIX Valid values:yes or 1, no or 0. If yes, configure and start vsftpd. (You must manually install vsftpd on the service nodes before this.) If no or 0, it does not change the current state of the service. xCAT is not using ftp for compute nodes provisioning or any other xCAT features, so this attribute can be set to 0 if the ftp service will not be used for other purposes
|
||||
Do we set up a ftp server on this service node? Not supported on AIX Valid values:1 or 0. If 1, configure and start vsftpd. (You must manually install vsftpd on the service nodes before this.) If 0, it does not change the current state of the service. xCAT is not using ftp for compute nodes provisioning or any other xCAT features, so this attribute can be set to 0 if the ftp service will not be used for other purposes
|
||||
|
||||
|
||||
|
||||
\ **nimserver**\
|
||||
|
||||
Not used. Do we set up a NIM server on this service node? Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Not used. Do we set up a NIM server on this service node? Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **ipforward**\
|
||||
|
||||
Do we set up ip forwarding on this service node? Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Do we set up ip forwarding on this service node? Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
@@ -116,7 +116,7 @@ servicenode Attributes:
|
||||
|
||||
\ **proxydhcp**\
|
||||
|
||||
Do we set up proxydhcp service on this node? valid values: yes or 1, no or 0. If yes, the proxydhcp daemon will be enabled on this node.
|
||||
Do we set up proxydhcp service on this node? valid values: 1 or 0. If 1, the proxydhcp daemon will be enabled on this node.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -136,6 +136,8 @@ site Attributes:
|
||||
service nodes will ignore this value and always be configured to forward
|
||||
to the management node.
|
||||
|
||||
emptyzonesenable: (yes or no). This is to set empty-zones-enable value in named.conf options section.
|
||||
|
||||
master: The hostname of the xCAT management node, as known by the nodes.
|
||||
|
||||
nameservers: A comma delimited list of DNS servers that each node in the cluster should
|
||||
@@ -260,6 +262,8 @@ site Attributes:
|
||||
|
||||
defserialspeed: The default serial speed - currently only used by mknb.
|
||||
|
||||
disablenodesetwarning: Allow the legacy xCAT non-osimage style nodeset to execute.
|
||||
|
||||
genmacprefix: When generating mac addresses automatically, use this manufacturing
|
||||
prefix (e.g. 00:11:aa)
|
||||
|
||||
|
||||
@@ -98,7 +98,7 @@ storage Attributes:
|
||||
|
||||
\ **controller**\
|
||||
|
||||
The management address to attach/detach new volumes.
|
||||
The management address to attach/detach new volumes.
|
||||
In the scenario involving multiple controllers, this data must be
|
||||
passed as argument rather than by table value
|
||||
|
||||
|
||||
@@ -191,7 +191,7 @@ vm Attributes:
|
||||
|
||||
\ **othersettings**\
|
||||
|
||||
This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0',the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\ on the host.
|
||||
This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0', the value for PCI device format also can be like:'devpassthrough:0001:01:00.1', the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\ on the host.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -356,6 +356,10 @@ zone(7)|zone.7
|
||||
|
||||
|
||||
|
||||
zvmivp(7)|zvmivp.7
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
******
|
||||
@@ -804,6 +808,12 @@ zvm(5)|zvm.5
|
||||
|
||||
|
||||
|
||||
zvmivp(5)|zvmivp.5
|
||||
|
||||
List of z/VM Installation Verification Procedures (IVPs) to be periodically run.
|
||||
|
||||
|
||||
|
||||
|
||||
********
|
||||
SEE ALSO
|
||||
|
||||
@@ -19,7 +19,7 @@ SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **zvm Attributes:**\ \ *node*\ , \ *hcp*\ , \ *userid*\ , \ *nodetype*\ , \ *parent*\ , \ *comments*\ , \ *disable*\
|
||||
\ **zvm Attributes:**\ \ *node*\ , \ *hcp*\ , \ *userid*\ , \ *nodetype*\ , \ *parent*\ , \ *comments*\ , \ *disable*\ , \ *discovered*\ , \ *status*\
|
||||
|
||||
|
||||
***********
|
||||
@@ -78,6 +78,18 @@ zvm Attributes:
|
||||
|
||||
|
||||
|
||||
\ **discovered**\
|
||||
|
||||
Set to '1' to indicate this node was discovered.
|
||||
|
||||
|
||||
|
||||
\ **status**\
|
||||
|
||||
The processing status. Key value pairs (key=value) indicating status of the node. Multiple pairs are separated by semi-colons. Keys include: CLONING, CLONE_ONLY.
|
||||
|
||||
|
||||
|
||||
|
||||
********
|
||||
SEE ALSO
|
||||
|
||||
112
docs/source/guides/admin-guides/references/man5/zvmivp.5.rst
Normal file
112
docs/source/guides/admin-guides/references/man5/zvmivp.5.rst
Normal file
@@ -0,0 +1,112 @@
|
||||
|
||||
########
|
||||
zvmivp.5
|
||||
########
|
||||
|
||||
.. highlight:: perl
|
||||
|
||||
|
||||
****
|
||||
NAME
|
||||
****
|
||||
|
||||
|
||||
\ **zvmivp**\ - a table in the xCAT database.
|
||||
|
||||
|
||||
********
|
||||
SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **zvmivp Attributes:**\ \ *id*\ , \ *ip*\ , \ *schedule*\ , \ *last_run*\ , \ *type_of_run*\ , \ *access_user*\ , \ *orch_parms*\ , \ *prep_parms*\ , \ *main_ivp_parms*\ , \ *comments*\ , \ *disable*\
|
||||
|
||||
|
||||
***********
|
||||
DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
List of z/VM Installation Verification Procedures (IVPs) to be periodically run.
|
||||
|
||||
|
||||
******************
|
||||
zvmivp Attributes:
|
||||
******************
|
||||
|
||||
|
||||
|
||||
\ **id**\
|
||||
|
||||
Unique identifier associated with the IVP run, e.g. 1.
|
||||
|
||||
|
||||
|
||||
\ **ip**\
|
||||
|
||||
IP address of the target system, either the IP of the OpenStack compute node or the xCAT management node.
|
||||
|
||||
|
||||
|
||||
\ **schedule**\
|
||||
|
||||
The hours (0-24) that the IVP should be run. Multiple hours are separated by a blank.
|
||||
|
||||
|
||||
|
||||
\ **last_run**\
|
||||
|
||||
The last time the IVP was run specified as a set of 3 blank delimeted words: year, Julian date, and hour (in 24 hour format).
|
||||
|
||||
|
||||
|
||||
\ **type_of_run**\
|
||||
|
||||
The type of run requested, 'fullivp' or 'basicivp'.
|
||||
|
||||
|
||||
|
||||
\ **access_user**\
|
||||
|
||||
User on the OpenStack node that is used to: push the IVP preparation script to the OpenStack system, drive the preparation script to validate the OpenStack configuration files, and return the created driver script to the xCAT MN system for the next part of the IVP. This user should be able to access the OpenStack configuration files that are scanned by the IVP.
|
||||
|
||||
|
||||
|
||||
\ **orch_parms**\
|
||||
|
||||
Parameters to pass to the IVP orchestrator script, verifynode.
|
||||
|
||||
|
||||
|
||||
\ **prep_parms**\
|
||||
|
||||
Parameters to pass to the phase 1 IVP preparation script.
|
||||
|
||||
|
||||
|
||||
\ **main_ivp_parms**\
|
||||
|
||||
Parameters to pass to the main IVP script.
|
||||
|
||||
|
||||
|
||||
\ **comments**\
|
||||
|
||||
Any user provided notes or description of the run.
|
||||
|
||||
|
||||
|
||||
\ **disable**\
|
||||
|
||||
Set to 'yes' or '1' to disable this IVP run.
|
||||
|
||||
|
||||
|
||||
|
||||
********
|
||||
SEE ALSO
|
||||
********
|
||||
|
||||
|
||||
\ **nodels(1)**\ , \ **chtab(8)**\ , \ **tabdump(8)**\ , \ **tabedit(8)**\
|
||||
|
||||
@@ -19,7 +19,7 @@ SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **group Attributes:**\ \ *addkcmdline*\ , \ *arch*\ , \ *authdomain*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *consport*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groupname*\ , \ *grouptype*\ , \ *hcp*\ , \ *height*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *machinetype*\ , \ *membergroups*\ , \ *members*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *modelnum*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *outlet*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *pdu*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *serial*\ , \ *serialflow*\ , \ *serialnum*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *wherevals*\ , \ *xcatmaster*\
|
||||
\ **group Attributes:**\ \ *addkcmdline*\ , \ *arch*\ , \ *authdomain*\ , \ *authkey*\ , \ *authtype*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *community*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *consport*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groupname*\ , \ *grouptype*\ , \ *hcp*\ , \ *height*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *membergroups*\ , \ *members*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *outlet*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *pdu*\ , \ *pdutype*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *privkey*\ , \ *privtype*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *seclevel*\ , \ *serial*\ , \ *serialflow*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpuser*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *wherevals*\ , \ *xcatmaster*\
|
||||
|
||||
|
||||
***********
|
||||
@@ -57,6 +57,18 @@ group Attributes:
|
||||
|
||||
|
||||
|
||||
\ **authkey**\ (pdu.authkey)
|
||||
|
||||
The authentication passphrase for SNMPv3
|
||||
|
||||
|
||||
|
||||
\ **authtype**\ (pdu.authtype)
|
||||
|
||||
The authentication protocol(MD5|SHA) to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
\ **bmc**\ (ipmi.bmc, openbmc.bmc)
|
||||
|
||||
The hostname of the BMC adapter.
|
||||
@@ -179,6 +191,12 @@ group Attributes:
|
||||
|
||||
|
||||
|
||||
\ **community**\ (pdu.community)
|
||||
|
||||
The community string to use for SNMPv1/v2
|
||||
|
||||
|
||||
|
||||
\ **cons**\ (nodehm.cons)
|
||||
|
||||
The console method. If nodehm.serialport is set, this will default to the nodehm.mgt setting, otherwise it defaults to unused. Valid values: cyclades, mrv, or the values valid for the mgt attribute.
|
||||
@@ -253,7 +271,7 @@ group Attributes:
|
||||
|
||||
\ **dockerflag**\ (vm.othersettings)
|
||||
|
||||
This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0',the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\ on the host.
|
||||
This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0', the value for PCI device format also can be like:'devpassthrough:0001:01:00.1', the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\ on the host.
|
||||
|
||||
|
||||
|
||||
@@ -457,12 +475,6 @@ group Attributes:
|
||||
|
||||
|
||||
|
||||
\ **machinetype**\ (pdu.machinetype)
|
||||
|
||||
The pdu machine type
|
||||
|
||||
|
||||
|
||||
\ **membergroups**\ (nodegroup.membergroups)
|
||||
|
||||
This attribute stores a comma-separated list of nodegroups that this nodegroup refers to. This attribute is only used by PCM.
|
||||
@@ -529,12 +541,6 @@ group Attributes:
|
||||
|
||||
|
||||
|
||||
\ **modelnum**\ (pdu.modelnum)
|
||||
|
||||
The pdu model number
|
||||
|
||||
|
||||
|
||||
\ **monserver**\ (noderes.monserver)
|
||||
|
||||
The monitoring aggregation point for this node. The format is "x,y" where x is the ip address as known by the management node and y is the ip address as known by the node.
|
||||
@@ -566,8 +572,8 @@ group Attributes:
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
Arch OS valid netboot options
|
||||
x86, x86_64 ALL pxe, xnba
|
||||
Arch OS valid netboot options
|
||||
x86, x86_64 ALL pxe, xnba
|
||||
ppc64 <=rhel6, <=sles11.3 yaboot
|
||||
ppc64 >=rhels7, >=sles11.4 grub2,grub2-http,grub2-tftp
|
||||
ppc64le NonVirtualize ALL petitboot
|
||||
@@ -629,7 +635,7 @@ group Attributes:
|
||||
If multiple ip addresses are associated with each NIC:
|
||||
<nic1>!<ext1>|<ext2>,<nic2>!<ext1>|<ext2>,..., for example, eth0!eth0-|eth0-ipv6i-,ib0!ib-|ib-ipv6-.
|
||||
The xCAT object definition commands support to use nichostnameprefixes.<nicname> as the sub attributes.
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-),and period (.). When you are specifying "nichostnameprefixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9) and minus sign (-). When you are specifying "nichostnameprefixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
|
||||
|
||||
|
||||
@@ -640,8 +646,13 @@ group Attributes:
|
||||
<nic1>!<ext1>,<nic2>!<ext2>,..., for example, eth0!-eth0,ib0!-ib0
|
||||
If multiple ip addresses are associated with each NIC:
|
||||
<nic1>!<ext1>|<ext2>,<nic2>!<ext1>|<ext2>,..., for example, eth0!-eth0|-eth0-ipv6,ib0!-ib0|-ib0-ipv6.
|
||||
The xCAT object definition commands support to use nichostnamesuffixes.<nicname> as the sub attributes.
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-),and period (.). When you are specifying "nichostnamesuffixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
The xCAT object definition commands support to use nichostnamesuffixes.<nicname> as the sub attributes.
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9) and minus sign (-). When you are specifying "nichostnamesuffixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -668,8 +679,7 @@ group Attributes:
|
||||
|
||||
\ **nicsadapter**\ (nics.nicsadapter)
|
||||
|
||||
Comma-separated list of extra parameters that will be used for each NIC configuration.
|
||||
<nic1>!<param1=value1 param2=value2>,<nic2>!<param4=value4 param5=value5>, for example, enP3p3s0f1!mac=98:be:94:59:fa:cd linkstate=DOWN,enP3p3s0f2!mac=98:be:94:59:fa:ce candidatename=enP3p3s0f2/enx98be9459face
|
||||
Comma-separated list of NIC information collected by getadapter. <nic1>!<param1=value1 param2=value2>,<nic2>!<param4=value4 param5=value5>, for example, enP3p3s0f1!mac=98:be:94:59:fa:cd linkstate=DOWN,enP3p3s0f2!mac=98:be:94:59:fa:ce candidatename=enP3p3s0f2/enx98be9459face
|
||||
|
||||
|
||||
|
||||
@@ -775,7 +785,7 @@ group Attributes:
|
||||
|
||||
|
||||
|
||||
\ **password**\ (ppchcp.password, mpa.password, websrv.password, switches.sshpassword)
|
||||
\ **password**\ (ppchcp.password, mpa.password, websrv.password, pdu.password, switches.sshpassword)
|
||||
|
||||
Password of the HMC or IVM. If not filled in, xCAT will look in the passwd table for key=hmc or key=ivm. If not in the passwd table, the default used is abc123 for HMCs and padmin for IVMs.
|
||||
|
||||
@@ -789,6 +799,10 @@ group Attributes:
|
||||
|
||||
or
|
||||
|
||||
The remote login password
|
||||
|
||||
or
|
||||
|
||||
The remote login password. It can be for ssh or telnet. If it is for telnet, set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.
|
||||
|
||||
|
||||
@@ -799,6 +813,12 @@ group Attributes:
|
||||
|
||||
|
||||
|
||||
\ **pdutype**\ (pdu.pdutype)
|
||||
|
||||
The type of pdu
|
||||
|
||||
|
||||
|
||||
\ **postbootscripts**\ (postscripts.postbootscripts)
|
||||
|
||||
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. Please note that the postbootscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postbootscripts" attribute of a node with "chdef -m" command
|
||||
@@ -862,6 +882,18 @@ group Attributes:
|
||||
|
||||
|
||||
|
||||
\ **privkey**\ (pdu.privkey)
|
||||
|
||||
The privacy passphrase to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
\ **privtype**\ (pdu.privtype)
|
||||
|
||||
The privacy protocol(AES|DES) to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
\ **productkey**\ (prodkey.key)
|
||||
|
||||
The product key relevant to the aforementioned node/group and product combination
|
||||
@@ -904,6 +936,12 @@ group Attributes:
|
||||
|
||||
|
||||
|
||||
\ **seclevel**\ (pdu.seclevel)
|
||||
|
||||
The Security Level(noAuthNoPriv|authNoPriv|authPriv) to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
\ **serial**\ (vpd.serial)
|
||||
|
||||
The serial number of the node.
|
||||
@@ -916,12 +954,6 @@ group Attributes:
|
||||
|
||||
|
||||
|
||||
\ **serialnum**\ (pdu.serialnum)
|
||||
|
||||
The pdu serial number
|
||||
|
||||
|
||||
|
||||
\ **serialport**\ (nodehm.serialport)
|
||||
|
||||
The serial port for this node, in the linux numbering style (0=COM1/ttyS0, 1=COM2/ttyS1). For SOL on IBM blades, this is typically 1. For rackmount IBM servers, this is typically 0.
|
||||
@@ -942,67 +974,67 @@ group Attributes:
|
||||
|
||||
\ **setupconserver**\ (servicenode.conserver)
|
||||
|
||||
Do we set up Conserver on this service node? Valid values:yes or 1, no or 0. If yes, configures and starts conserver daemon. If no or 0, it does not change the current state of the service.
|
||||
Do we set up console service on this service node? Valid values: 0, 1, or 2. If 0, it does not change the current state of the service. If 1, configures and starts conserver daemon. If 2, configures and starts goconserver daemon.
|
||||
|
||||
|
||||
|
||||
\ **setupdhcp**\ (servicenode.dhcpserver)
|
||||
|
||||
Do we set up DHCP on this service node? Not supported on AIX. Valid values:yes or 1, no or 0. If yes, runs makedhcp -n. If no or 0, it does not change the current state of the service.
|
||||
Do we set up DHCP on this service node? Not supported on AIX. Valid values:1 or 0. If 1, runs makedhcp -n. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupftp**\ (servicenode.ftpserver)
|
||||
|
||||
Do we set up a ftp server on this service node? Not supported on AIX Valid values:yes or 1, no or 0. If yes, configure and start vsftpd. (You must manually install vsftpd on the service nodes before this.) If no or 0, it does not change the current state of the service. xCAT is not using ftp for compute nodes provisioning or any other xCAT features, so this attribute can be set to 0 if the ftp service will not be used for other purposes
|
||||
Do we set up a ftp server on this service node? Not supported on AIX Valid values:1 or 0. If 1, configure and start vsftpd. (You must manually install vsftpd on the service nodes before this.) If 0, it does not change the current state of the service. xCAT is not using ftp for compute nodes provisioning or any other xCAT features, so this attribute can be set to 0 if the ftp service will not be used for other purposes
|
||||
|
||||
|
||||
|
||||
\ **setupipforward**\ (servicenode.ipforward)
|
||||
|
||||
Do we set up ip forwarding on this service node? Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Do we set up ip forwarding on this service node? Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupldap**\ (servicenode.ldapserver)
|
||||
|
||||
Do we set up ldap caching proxy on this service node? Not supported on AIX. Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Do we set up ldap caching proxy on this service node? Not supported on AIX. Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupnameserver**\ (servicenode.nameserver)
|
||||
|
||||
Do we set up DNS on this service node? Valid values: 2, 1, no or 0. If 2, creates named.conf as dns slave, using the management node as dns master, and starts named. If 1, creates named.conf file with forwarding to the management node and starts named. If no or 0, it does not change the current state of the service.
|
||||
Do we set up DNS on this service node? Valid values: 2, 1, or 0. If 2, creates named.conf as dns slave, using the management node as dns master, and starts named. If 1, creates named.conf file with forwarding to the management node and starts named. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupnfs**\ (servicenode.nfsserver)
|
||||
|
||||
Do we set up file services (HTTP,FTP,or NFS) on this service node? For AIX will only setup NFS, not HTTP or FTP. Valid values:yes or 1, no or 0.If no or 0, it does not change the current state of the service.
|
||||
Do we set up file services (HTTP,FTP,or NFS) on this service node? For AIX will only setup NFS, not HTTP or FTP. Valid values:1 or 0.If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupnim**\ (servicenode.nimserver)
|
||||
|
||||
Not used. Do we set up a NIM server on this service node? Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Not used. Do we set up a NIM server on this service node? Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupntp**\ (servicenode.ntpserver)
|
||||
|
||||
Not used. Use setupntp postscript to setup a ntp server on this service node? Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Not used. Use setupntp postscript to setup a ntp server on this service node? Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupproxydhcp**\ (servicenode.proxydhcp)
|
||||
|
||||
Do we set up proxydhcp service on this node? valid values: yes or 1, no or 0. If yes, the proxydhcp daemon will be enabled on this node.
|
||||
Do we set up proxydhcp service on this node? valid values: 1 or 0. If 1, the proxydhcp daemon will be enabled on this node.
|
||||
|
||||
|
||||
|
||||
\ **setuptftp**\ (servicenode.tftpserver)
|
||||
|
||||
Do we set up TFTP on this service node? Not supported on AIX. Valid values:yes or 1, no or 0. If yes, configures and starts atftp. If no or 0, it does not change the current state of the service.
|
||||
Do we set up TFTP on this service node? Not supported on AIX. Valid values:1 or 0. If 1, configures and starts atftp. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
@@ -1062,13 +1094,23 @@ group Attributes:
|
||||
|
||||
|
||||
|
||||
\ **snmpuser**\ (pdu.snmpuser)
|
||||
|
||||
The username to use for SNMPv3 communication, ignored for SNMPv1
|
||||
|
||||
|
||||
|
||||
\ **snmpusername**\ (switches.username)
|
||||
|
||||
The username to use for SNMPv3 communication, ignored for SNMPv1
|
||||
|
||||
|
||||
|
||||
\ **snmpversion**\ (switches.snmpversion)
|
||||
\ **snmpversion**\ (pdu.snmpversion, switches.snmpversion)
|
||||
|
||||
The version to use to communicate with switch. SNMPv1 is assumed by default.
|
||||
|
||||
or
|
||||
|
||||
The version to use to communicate with switch. SNMPv1 is assumed by default.
|
||||
|
||||
@@ -1076,7 +1118,7 @@ group Attributes:
|
||||
|
||||
\ **storagcontroller**\ (storage.controller)
|
||||
|
||||
The management address to attach/detach new volumes.
|
||||
The management address to attach/detach new volumes.
|
||||
In the scenario involving multiple controllers, this data must be
|
||||
passed as argument rather than by table value
|
||||
|
||||
@@ -1190,7 +1232,7 @@ group Attributes:
|
||||
|
||||
|
||||
|
||||
\ **username**\ (ppchcp.username, mpa.username, websrv.username, switches.sshusername)
|
||||
\ **username**\ (ppchcp.username, mpa.username, websrv.username, pdu.username, switches.sshusername)
|
||||
|
||||
Userid of the HMC or IVM. If not filled in, xCAT will look in the passwd table for key=hmc or key=ivm. If not in the passwd table, the default used is hscroot for HMCs and padmin for IVMs.
|
||||
|
||||
@@ -1204,6 +1246,10 @@ group Attributes:
|
||||
|
||||
or
|
||||
|
||||
The remote login user name
|
||||
|
||||
or
|
||||
|
||||
The remote login user name. It can be for ssh or telnet. If it is for telnet, set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.
|
||||
|
||||
|
||||
@@ -1276,7 +1322,7 @@ group Attributes:
|
||||
|
||||
\ **vmothersetting**\ (vm.othersettings)
|
||||
|
||||
This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0',the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\ on the host.
|
||||
This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0', the value for PCI device format also can be like:'devpassthrough:0001:01:00.1', the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\ on the host.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **node Attributes:**\ \ *addkcmdline*\ , \ *appstatus*\ , \ *appstatustime*\ , \ *arch*\ , \ *authdomain*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *consport*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groups*\ , \ *hcp*\ , \ *height*\ , \ *hidden*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *machinetype*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *modelnum*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *node*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *outlet*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *pdu*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *primarysn*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *serial*\ , \ *serialflow*\ , \ *serialnum*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *status*\ , \ *statustime*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *updatestatus*\ , \ *updatestatustime*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *xcatmaster*\ , \ *zonename*\
|
||||
\ **node Attributes:**\ \ *addkcmdline*\ , \ *appstatus*\ , \ *appstatustime*\ , \ *arch*\ , \ *authdomain*\ , \ *authkey*\ , \ *authtype*\ , \ *bmc*\ , \ *bmcpassword*\ , \ *bmcport*\ , \ *bmcusername*\ , \ *bmcvlantag*\ , \ *cfgmgr*\ , \ *cfgmgtroles*\ , \ *cfgserver*\ , \ *chain*\ , \ *chassis*\ , \ *cmdmapping*\ , \ *community*\ , \ *cons*\ , \ *conserver*\ , \ *consoleondemand*\ , \ *consport*\ , \ *cpucount*\ , \ *cputype*\ , \ *currchain*\ , \ *currstate*\ , \ *dhcpinterfaces*\ , \ *disksize*\ , \ *displayname*\ , \ *dockercpus*\ , \ *dockerflag*\ , \ *dockerhost*\ , \ *dockermemory*\ , \ *dockernics*\ , \ *domainadminpassword*\ , \ *domainadminuser*\ , \ *domaintype*\ , \ *getmac*\ , \ *groups*\ , \ *hcp*\ , \ *height*\ , \ *hidden*\ , \ *hostcluster*\ , \ *hostinterface*\ , \ *hostmanager*\ , \ *hostnames*\ , \ *hosttype*\ , \ *hwtype*\ , \ *id*\ , \ *initrd*\ , \ *installnic*\ , \ *interface*\ , \ *ip*\ , \ *iscsipassword*\ , \ *iscsiserver*\ , \ *iscsitarget*\ , \ *iscsiuserid*\ , \ *kcmdline*\ , \ *kernel*\ , \ *linkports*\ , \ *mac*\ , \ *memory*\ , \ *mgt*\ , \ *micbridge*\ , \ *michost*\ , \ *micid*\ , \ *miconboot*\ , \ *micpowermgt*\ , \ *micvlog*\ , \ *migrationdest*\ , \ *monserver*\ , \ *mpa*\ , \ *mtm*\ , \ *nameservers*\ , \ *netboot*\ , \ *nfsdir*\ , \ *nfsserver*\ , \ *nicaliases*\ , \ *niccustomscripts*\ , \ *nicdevices*\ , \ *nicextraparams*\ , \ *nichostnameprefixes*\ , \ *nichostnamesuffixes*\ , \ *nicips*\ , \ *nicnetworks*\ , \ *nicsadapter*\ , \ *nictypes*\ , \ *nimserver*\ , \ *node*\ , \ *nodetype*\ , \ *ondiscover*\ , \ *os*\ , \ *osvolume*\ , \ *otherinterfaces*\ , \ *ou*\ , \ *outlet*\ , \ *parent*\ , \ *passwd.HMC*\ , \ *passwd.admin*\ , \ *passwd.celogin*\ , \ *passwd.general*\ , \ *passwd.hscroot*\ , \ *password*\ , \ *pdu*\ , \ *pdutype*\ , \ *postbootscripts*\ , \ *postscripts*\ , \ *power*\ , \ *pprofile*\ , \ *prescripts-begin*\ , \ *prescripts-end*\ , \ *primarynic*\ , \ *primarysn*\ , \ *privkey*\ , \ *privtype*\ , \ *productkey*\ , \ *profile*\ , \ *protocol*\ , \ *provmethod*\ , \ *rack*\ , \ *room*\ , \ *routenames*\ , \ *seclevel*\ , \ *serial*\ , \ *serialflow*\ , \ *serialport*\ , \ *serialspeed*\ , \ *servicenode*\ , \ *setupconserver*\ , \ *setupdhcp*\ , \ *setupftp*\ , \ *setupipforward*\ , \ *setupldap*\ , \ *setupnameserver*\ , \ *setupnfs*\ , \ *setupnim*\ , \ *setupntp*\ , \ *setupproxydhcp*\ , \ *setuptftp*\ , \ *sfp*\ , \ *side*\ , \ *slot*\ , \ *slotid*\ , \ *slots*\ , \ *snmpauth*\ , \ *snmppassword*\ , \ *snmpprivacy*\ , \ *snmpuser*\ , \ *snmpusername*\ , \ *snmpversion*\ , \ *status*\ , \ *statustime*\ , \ *storagcontroller*\ , \ *storagetype*\ , \ *supernode*\ , \ *supportedarchs*\ , \ *supportproxydhcp*\ , \ *switch*\ , \ *switchinterface*\ , \ *switchport*\ , \ *switchtype*\ , \ *switchvlan*\ , \ *syslog*\ , \ *termport*\ , \ *termserver*\ , \ *tftpdir*\ , \ *tftpserver*\ , \ *unit*\ , \ *updatestatus*\ , \ *updatestatustime*\ , \ *urlpath*\ , \ *usercomment*\ , \ *userid*\ , \ *username*\ , \ *vmbeacon*\ , \ *vmbootorder*\ , \ *vmcfgstore*\ , \ *vmcluster*\ , \ *vmcpus*\ , \ *vmhost*\ , \ *vmmanager*\ , \ *vmmaster*\ , \ *vmmemory*\ , \ *vmnicnicmodel*\ , \ *vmnics*\ , \ *vmothersetting*\ , \ *vmphyslots*\ , \ *vmstorage*\ , \ *vmstoragecache*\ , \ *vmstorageformat*\ , \ *vmstoragemodel*\ , \ *vmtextconsole*\ , \ *vmvirtflags*\ , \ *vmvncport*\ , \ *webport*\ , \ *xcatmaster*\ , \ *zonename*\
|
||||
|
||||
|
||||
***********
|
||||
@@ -69,6 +69,18 @@ node Attributes:
|
||||
|
||||
|
||||
|
||||
\ **authkey**\ (pdu.authkey)
|
||||
|
||||
The authentication passphrase for SNMPv3
|
||||
|
||||
|
||||
|
||||
\ **authtype**\ (pdu.authtype)
|
||||
|
||||
The authentication protocol(MD5|SHA) to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
\ **bmc**\ (ipmi.bmc, openbmc.bmc)
|
||||
|
||||
The hostname of the BMC adapter.
|
||||
@@ -191,6 +203,12 @@ node Attributes:
|
||||
|
||||
|
||||
|
||||
\ **community**\ (pdu.community)
|
||||
|
||||
The community string to use for SNMPv1/v2
|
||||
|
||||
|
||||
|
||||
\ **cons**\ (nodehm.cons)
|
||||
|
||||
The console method. If nodehm.serialport is set, this will default to the nodehm.mgt setting, otherwise it defaults to unused. Valid values: cyclades, mrv, or the values valid for the mgt attribute.
|
||||
@@ -265,7 +283,7 @@ node Attributes:
|
||||
|
||||
\ **dockerflag**\ (vm.othersettings)
|
||||
|
||||
This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0',the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\ on the host.
|
||||
This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0', the value for PCI device format also can be like:'devpassthrough:0001:01:00.1', the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\ on the host.
|
||||
|
||||
|
||||
|
||||
@@ -469,12 +487,6 @@ node Attributes:
|
||||
|
||||
|
||||
|
||||
\ **machinetype**\ (pdu.machinetype)
|
||||
|
||||
The pdu machine type
|
||||
|
||||
|
||||
|
||||
\ **memory**\ (hwinv.memory)
|
||||
|
||||
The size of the memory for the node in MB.
|
||||
@@ -529,12 +541,6 @@ node Attributes:
|
||||
|
||||
|
||||
|
||||
\ **modelnum**\ (pdu.modelnum)
|
||||
|
||||
The pdu model number
|
||||
|
||||
|
||||
|
||||
\ **monserver**\ (noderes.monserver)
|
||||
|
||||
The monitoring aggregation point for this node. The format is "x,y" where x is the ip address as known by the management node and y is the ip address as known by the node.
|
||||
@@ -566,8 +572,8 @@ node Attributes:
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
Arch OS valid netboot options
|
||||
x86, x86_64 ALL pxe, xnba
|
||||
Arch OS valid netboot options
|
||||
x86, x86_64 ALL pxe, xnba
|
||||
ppc64 <=rhel6, <=sles11.3 yaboot
|
||||
ppc64 >=rhels7, >=sles11.4 grub2,grub2-http,grub2-tftp
|
||||
ppc64le NonVirtualize ALL petitboot
|
||||
@@ -629,7 +635,7 @@ node Attributes:
|
||||
If multiple ip addresses are associated with each NIC:
|
||||
<nic1>!<ext1>|<ext2>,<nic2>!<ext1>|<ext2>,..., for example, eth0!eth0-|eth0-ipv6i-,ib0!ib-|ib-ipv6-.
|
||||
The xCAT object definition commands support to use nichostnameprefixes.<nicname> as the sub attributes.
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-),and period (.). When you are specifying "nichostnameprefixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9) and minus sign (-). When you are specifying "nichostnameprefixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
|
||||
|
||||
|
||||
@@ -640,8 +646,13 @@ node Attributes:
|
||||
<nic1>!<ext1>,<nic2>!<ext2>,..., for example, eth0!-eth0,ib0!-ib0
|
||||
If multiple ip addresses are associated with each NIC:
|
||||
<nic1>!<ext1>|<ext2>,<nic2>!<ext1>|<ext2>,..., for example, eth0!-eth0|-eth0-ipv6,ib0!-ib0|-ib0-ipv6.
|
||||
The xCAT object definition commands support to use nichostnamesuffixes.<nicname> as the sub attributes.
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-),and period (.). When you are specifying "nichostnamesuffixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
The xCAT object definition commands support to use nichostnamesuffixes.<nicname> as the sub attributes.
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
Note: According to DNS rules a hostname must be a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9) and minus sign (-). When you are specifying "nichostnamesuffixes" or "nicaliases" make sure the resulting hostnames will conform to this naming convention
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -668,8 +679,7 @@ node Attributes:
|
||||
|
||||
\ **nicsadapter**\ (nics.nicsadapter)
|
||||
|
||||
Comma-separated list of extra parameters that will be used for each NIC configuration.
|
||||
<nic1>!<param1=value1 param2=value2>,<nic2>!<param4=value4 param5=value5>, for example, enP3p3s0f1!mac=98:be:94:59:fa:cd linkstate=DOWN,enP3p3s0f2!mac=98:be:94:59:fa:ce candidatename=enP3p3s0f2/enx98be9459face
|
||||
Comma-separated list of NIC information collected by getadapter. <nic1>!<param1=value1 param2=value2>,<nic2>!<param4=value4 param5=value5>, for example, enP3p3s0f1!mac=98:be:94:59:fa:cd linkstate=DOWN,enP3p3s0f2!mac=98:be:94:59:fa:ce candidatename=enP3p3s0f2/enx98be9459face
|
||||
|
||||
|
||||
|
||||
@@ -781,7 +791,7 @@ node Attributes:
|
||||
|
||||
|
||||
|
||||
\ **password**\ (ppchcp.password, mpa.password, websrv.password, switches.sshpassword)
|
||||
\ **password**\ (ppchcp.password, mpa.password, websrv.password, pdu.password, switches.sshpassword)
|
||||
|
||||
Password of the HMC or IVM. If not filled in, xCAT will look in the passwd table for key=hmc or key=ivm. If not in the passwd table, the default used is abc123 for HMCs and padmin for IVMs.
|
||||
|
||||
@@ -795,6 +805,10 @@ node Attributes:
|
||||
|
||||
or
|
||||
|
||||
The remote login password
|
||||
|
||||
or
|
||||
|
||||
The remote login password. It can be for ssh or telnet. If it is for telnet, set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.
|
||||
|
||||
|
||||
@@ -805,6 +819,12 @@ node Attributes:
|
||||
|
||||
|
||||
|
||||
\ **pdutype**\ (pdu.pdutype)
|
||||
|
||||
The type of pdu
|
||||
|
||||
|
||||
|
||||
\ **postbootscripts**\ (postscripts.postbootscripts)
|
||||
|
||||
Comma separated list of scripts that should be run on this node after diskful installation or diskless boot. Each script can take zero or more parameters. For example: "script1 p1 p2,script2,...". On AIX these scripts are run during the processing of /etc/inittab. On Linux they are run at the init.d time. xCAT automatically adds the scripts in the xcatdefaults.postbootscripts attribute to run first in the list. Please note that the postbootscripts specified for "xcatdefaults" will be assigned to node automatically, they can not be removed from "postbootscripts" attribute of a node with "chdef -m" command
|
||||
@@ -874,6 +894,18 @@ node Attributes:
|
||||
|
||||
|
||||
|
||||
\ **privkey**\ (pdu.privkey)
|
||||
|
||||
The privacy passphrase to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
\ **privtype**\ (pdu.privtype)
|
||||
|
||||
The privacy protocol(AES|DES) to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
\ **productkey**\ (prodkey.key)
|
||||
|
||||
The product key relevant to the aforementioned node/group and product combination
|
||||
@@ -916,6 +948,12 @@ node Attributes:
|
||||
|
||||
|
||||
|
||||
\ **seclevel**\ (pdu.seclevel)
|
||||
|
||||
The Security Level(noAuthNoPriv|authNoPriv|authPriv) to use for SNMPv3.
|
||||
|
||||
|
||||
|
||||
\ **serial**\ (vpd.serial)
|
||||
|
||||
The serial number of the node.
|
||||
@@ -928,12 +966,6 @@ node Attributes:
|
||||
|
||||
|
||||
|
||||
\ **serialnum**\ (pdu.serialnum)
|
||||
|
||||
The pdu serial number
|
||||
|
||||
|
||||
|
||||
\ **serialport**\ (nodehm.serialport)
|
||||
|
||||
The serial port for this node, in the linux numbering style (0=COM1/ttyS0, 1=COM2/ttyS1). For SOL on IBM blades, this is typically 1. For rackmount IBM servers, this is typically 0.
|
||||
@@ -954,67 +986,67 @@ node Attributes:
|
||||
|
||||
\ **setupconserver**\ (servicenode.conserver)
|
||||
|
||||
Do we set up Conserver on this service node? Valid values:yes or 1, no or 0. If yes, configures and starts conserver daemon. If no or 0, it does not change the current state of the service.
|
||||
Do we set up console service on this service node? Valid values: 0, 1, or 2. If 0, it does not change the current state of the service. If 1, configures and starts conserver daemon. If 2, configures and starts goconserver daemon.
|
||||
|
||||
|
||||
|
||||
\ **setupdhcp**\ (servicenode.dhcpserver)
|
||||
|
||||
Do we set up DHCP on this service node? Not supported on AIX. Valid values:yes or 1, no or 0. If yes, runs makedhcp -n. If no or 0, it does not change the current state of the service.
|
||||
Do we set up DHCP on this service node? Not supported on AIX. Valid values:1 or 0. If 1, runs makedhcp -n. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupftp**\ (servicenode.ftpserver)
|
||||
|
||||
Do we set up a ftp server on this service node? Not supported on AIX Valid values:yes or 1, no or 0. If yes, configure and start vsftpd. (You must manually install vsftpd on the service nodes before this.) If no or 0, it does not change the current state of the service. xCAT is not using ftp for compute nodes provisioning or any other xCAT features, so this attribute can be set to 0 if the ftp service will not be used for other purposes
|
||||
Do we set up a ftp server on this service node? Not supported on AIX Valid values:1 or 0. If 1, configure and start vsftpd. (You must manually install vsftpd on the service nodes before this.) If 0, it does not change the current state of the service. xCAT is not using ftp for compute nodes provisioning or any other xCAT features, so this attribute can be set to 0 if the ftp service will not be used for other purposes
|
||||
|
||||
|
||||
|
||||
\ **setupipforward**\ (servicenode.ipforward)
|
||||
|
||||
Do we set up ip forwarding on this service node? Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Do we set up ip forwarding on this service node? Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupldap**\ (servicenode.ldapserver)
|
||||
|
||||
Do we set up ldap caching proxy on this service node? Not supported on AIX. Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Do we set up ldap caching proxy on this service node? Not supported on AIX. Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupnameserver**\ (servicenode.nameserver)
|
||||
|
||||
Do we set up DNS on this service node? Valid values: 2, 1, no or 0. If 2, creates named.conf as dns slave, using the management node as dns master, and starts named. If 1, creates named.conf file with forwarding to the management node and starts named. If no or 0, it does not change the current state of the service.
|
||||
Do we set up DNS on this service node? Valid values: 2, 1, or 0. If 2, creates named.conf as dns slave, using the management node as dns master, and starts named. If 1, creates named.conf file with forwarding to the management node and starts named. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupnfs**\ (servicenode.nfsserver)
|
||||
|
||||
Do we set up file services (HTTP,FTP,or NFS) on this service node? For AIX will only setup NFS, not HTTP or FTP. Valid values:yes or 1, no or 0.If no or 0, it does not change the current state of the service.
|
||||
Do we set up file services (HTTP,FTP,or NFS) on this service node? For AIX will only setup NFS, not HTTP or FTP. Valid values:1 or 0.If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupnim**\ (servicenode.nimserver)
|
||||
|
||||
Not used. Do we set up a NIM server on this service node? Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Not used. Do we set up a NIM server on this service node? Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupntp**\ (servicenode.ntpserver)
|
||||
|
||||
Not used. Use setupntp postscript to setup a ntp server on this service node? Valid values:yes or 1, no or 0. If no or 0, it does not change the current state of the service.
|
||||
Not used. Use setupntp postscript to setup a ntp server on this service node? Valid values:1 or 0. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
\ **setupproxydhcp**\ (servicenode.proxydhcp)
|
||||
|
||||
Do we set up proxydhcp service on this node? valid values: yes or 1, no or 0. If yes, the proxydhcp daemon will be enabled on this node.
|
||||
Do we set up proxydhcp service on this node? valid values: 1 or 0. If 1, the proxydhcp daemon will be enabled on this node.
|
||||
|
||||
|
||||
|
||||
\ **setuptftp**\ (servicenode.tftpserver)
|
||||
|
||||
Do we set up TFTP on this service node? Not supported on AIX. Valid values:yes or 1, no or 0. If yes, configures and starts atftp. If no or 0, it does not change the current state of the service.
|
||||
Do we set up TFTP on this service node? Not supported on AIX. Valid values:1 or 0. If 1, configures and starts atftp. If 0, it does not change the current state of the service.
|
||||
|
||||
|
||||
|
||||
@@ -1074,13 +1106,23 @@ node Attributes:
|
||||
|
||||
|
||||
|
||||
\ **snmpuser**\ (pdu.snmpuser)
|
||||
|
||||
The username to use for SNMPv3 communication, ignored for SNMPv1
|
||||
|
||||
|
||||
|
||||
\ **snmpusername**\ (switches.username)
|
||||
|
||||
The username to use for SNMPv3 communication, ignored for SNMPv1
|
||||
|
||||
|
||||
|
||||
\ **snmpversion**\ (switches.snmpversion)
|
||||
\ **snmpversion**\ (pdu.snmpversion, switches.snmpversion)
|
||||
|
||||
The version to use to communicate with switch. SNMPv1 is assumed by default.
|
||||
|
||||
or
|
||||
|
||||
The version to use to communicate with switch. SNMPv1 is assumed by default.
|
||||
|
||||
@@ -1088,7 +1130,7 @@ node Attributes:
|
||||
|
||||
\ **status**\ (nodelist.status)
|
||||
|
||||
The current status of this node. This attribute will be set by xCAT software. Valid values: defined, booting, netbooting, booted, discovering, configuring, installing, alive, standingby, powering-off, unreachable. If blank, defined is assumed. The possible status change sequences are: For installation: defined->[discovering]->[configuring]->[standingby]->installing->booting->booted->[alive], For diskless deployment: defined->[discovering]->[configuring]->[standingby]->netbooting->booted->[alive], For booting: [alive/unreachable]->booting->[alive], For powering off: [alive]->powering-off->[unreachable], For monitoring: alive->unreachable. Discovering and configuring are for x Series discovery process. Alive and unreachable are set only when there is a monitoring plug-in start monitor the node status for xCAT. Note that the status values will not reflect the real node status if you change the state of the node from outside of xCAT (i.e. power off the node using HMC GUI).
|
||||
The current status of this node. This attribute will be set by xCAT software. Valid values: defined, booting, netbooting, booted, discovering, configuring, installing, alive, standingby, powering-off, unreachable. If blank, defined is assumed. The possible status change sequences are: For installation: defined->[discovering]->[configuring]->[standingby]->installing->booting->[postbooting]->booted->[alive], For diskless deployment: defined->[discovering]->[configuring]->[standingby]->netbooting->[postbooting]->booted->[alive], For booting: [alive/unreachable]->booting->[postbooting]->booted->[alive], For powering off: [alive]->powering-off->[unreachable], For monitoring: alive->unreachable. Discovering and configuring are for x Series discovery process. Alive and unreachable are set only when there is a monitoring plug-in start monitor the node status for xCAT. Note that the status values will not reflect the real node status if you change the state of the node from outside of xCAT (i.e. power off the node using HMC GUI).
|
||||
|
||||
|
||||
|
||||
@@ -1100,7 +1142,7 @@ node Attributes:
|
||||
|
||||
\ **storagcontroller**\ (storage.controller)
|
||||
|
||||
The management address to attach/detach new volumes.
|
||||
The management address to attach/detach new volumes.
|
||||
In the scenario involving multiple controllers, this data must be
|
||||
passed as argument rather than by table value
|
||||
|
||||
@@ -1226,7 +1268,7 @@ node Attributes:
|
||||
|
||||
|
||||
|
||||
\ **username**\ (ppchcp.username, mpa.username, websrv.username, switches.sshusername)
|
||||
\ **username**\ (ppchcp.username, mpa.username, websrv.username, pdu.username, switches.sshusername)
|
||||
|
||||
Userid of the HMC or IVM. If not filled in, xCAT will look in the passwd table for key=hmc or key=ivm. If not in the passwd table, the default used is hscroot for HMCs and padmin for IVMs.
|
||||
|
||||
@@ -1240,6 +1282,10 @@ node Attributes:
|
||||
|
||||
or
|
||||
|
||||
The remote login user name
|
||||
|
||||
or
|
||||
|
||||
The remote login user name. It can be for ssh or telnet. If it is for telnet, set protocol to "telnet". If the sshusername is blank, the username, password and protocol will be retrieved from the passwd table with "switch" as the key.
|
||||
|
||||
|
||||
@@ -1312,7 +1358,7 @@ node Attributes:
|
||||
|
||||
\ **vmothersetting**\ (vm.othersettings)
|
||||
|
||||
This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0',the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\ on the host.
|
||||
This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0', the value for PCI device format also can be like:'devpassthrough:0001:01:00.1', the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\ on the host.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -255,7 +255,7 @@ osimage Attributes:
|
||||
|
||||
\ **otherpkgdir**\ (linuximage.otherpkgdir)
|
||||
|
||||
The base directory where the non-distro packages are stored. Only 1 local directory supported at present.
|
||||
The base directory and urls of internet repos from which the non-distro packages are retrived. Only 1 local directory is supported at present. The entries should be delimited with comma ",". Currently, the internet repos are only supported on Ubuntu and Redhat.
|
||||
|
||||
|
||||
|
||||
@@ -324,15 +324,15 @@ osimage Attributes:
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
IMG_ARCH(The architecture of the osimage, such as "ppc64le","x86_64"),
|
||||
IMG_NAME(The name of the osimage, such as "rhels7.3-ppc64le-netboot-compute"),
|
||||
IMG_OSVER(The os release of the osimage, such as "rhels7.3","sles11.4"),
|
||||
IMG_ARCH(The architecture of the osimage, such as "ppc64le","x86_64"),
|
||||
IMG_NAME(The name of the osimage, such as "rhels7.3-ppc64le-netboot-compute"),
|
||||
IMG_OSVER(The os release of the osimage, such as "rhels7.3","sles11.4"),
|
||||
IMG_KERNELVERSION(the "kernelver" attribute of the osimage),
|
||||
IMG_PROFILE(the profile of the osimage, such as "service","compute"),
|
||||
IMG_PKGLIST(the "pkglist" attribute of the osimage),
|
||||
IMG_PKGDIR(the "pkgdir" attribute of the osimage),
|
||||
IMG_OTHERPKGLIST(the "otherpkglist" attribute of the osimage),
|
||||
IMG_OTHERPKGDIR(the "otherpkgdir" attribute of the osimage),
|
||||
IMG_PROFILE(the profile of the osimage, such as "service","compute"),
|
||||
IMG_PKGLIST(the "pkglist" attribute of the osimage),
|
||||
IMG_PKGDIR(the "pkgdir" attribute of the osimage),
|
||||
IMG_OTHERPKGLIST(the "otherpkglist" attribute of the osimage),
|
||||
IMG_OTHERPKGDIR(the "otherpkgdir" attribute of the osimage),
|
||||
IMG_ROOTIMGDIR(the "rootimgdir" attribute of the osimage)
|
||||
|
||||
|
||||
|
||||
@@ -40,15 +40,11 @@ pdu Attributes:
|
||||
|
||||
|
||||
\ **machinetype**\ (pdu.machinetype)
|
||||
|
||||
The pdu machine type
|
||||
|
||||
|
||||
|
||||
|
||||
\ **modelnum**\ (pdu.modelnum)
|
||||
|
||||
The pdu model number
|
||||
|
||||
|
||||
|
||||
|
||||
\ **node**\ (pdu.node)
|
||||
@@ -70,9 +66,7 @@ pdu Attributes:
|
||||
|
||||
|
||||
\ **serialnum**\ (pdu.serialnum)
|
||||
|
||||
The pdu serial number
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
49
docs/source/guides/admin-guides/references/man7/zvmivp.7.rst
Normal file
49
docs/source/guides/admin-guides/references/man7/zvmivp.7.rst
Normal file
@@ -0,0 +1,49 @@
|
||||
|
||||
########
|
||||
zvmivp.7
|
||||
########
|
||||
|
||||
.. highlight:: perl
|
||||
|
||||
|
||||
****
|
||||
NAME
|
||||
****
|
||||
|
||||
|
||||
\ **zvmivp**\ - a logical object definition in the xCAT database.
|
||||
|
||||
|
||||
********
|
||||
SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **zvmivp Attributes:**\ \ **\
|
||||
|
||||
|
||||
***********
|
||||
DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
Logical objects of this type are stored in the xCAT database in one or more tables. Use the following commands
|
||||
to manipulate the objects: \ **mkdef**\ , \ **chdef**\ , \ **lsdef**\ , and \ **rmdef**\ . These commands will take care of
|
||||
knowing which tables the object attributes should be stored in. The attribute list below shows, in
|
||||
parentheses, what tables each attribute is stored in.
|
||||
|
||||
|
||||
******************
|
||||
zvmivp Attributes:
|
||||
******************
|
||||
|
||||
|
||||
|
||||
|
||||
********
|
||||
SEE ALSO
|
||||
********
|
||||
|
||||
|
||||
\ **mkdef(1)**\ , \ **chdef(1)**\ , \ **lsdef(1)**\ , \ **rmdef(1)**\
|
||||
|
||||
@@ -21,6 +21,8 @@ SYNOPSIS
|
||||
|
||||
\ **makeconservercf**\ [\ **-V|-**\ **-verbose**\ ] [\ **-d|-**\ **-delete**\ ] [\ *noderange*\ ]
|
||||
|
||||
\ **makeconservercf**\ [\ **-V|-**\ **-verbose**\ ] [\ **-C|-**\ **-cleanup**\ ]
|
||||
|
||||
\ **makeconservercf**\ [\ **-V|-**\ **-verbose**\ ] [\ **-l|-**\ **-local**\ ] [\ *noderange*\ ]
|
||||
|
||||
\ **makeconservercf**\ [\ **-V|-**\ **-verbose**\ ] [\ **-c|-**\ **-conserver**\ ] [\ *noderange*\ ]
|
||||
@@ -42,6 +44,8 @@ does not have nodehm.cons set, it will not be written to the file.
|
||||
|
||||
If \ **-d**\ is specified, \ **makeconservercf**\ will remove specified nodes from /etc/conserver.cf file. If \ *noderange*\ is not specified, all xCAT nodes will be removed from /etc/conserver.cf file.
|
||||
|
||||
If \ **-C|-**\ **-cleanup**\ is specified, \ **makeconservercf**\ will remove console configuration entries from /etc/conserver.cf for the nodes whose definitions have been removed from xCATdb. \ **Don't**\ specify any noderange.
|
||||
|
||||
In the case of a hierarchical cluster (i.e. one with service nodes) \ **makeconservercf**\ will determine
|
||||
which nodes will have their consoles accessed from the management node and which from a service node
|
||||
(based on the nodehm.conserver attribute). The /etc/conserver.cf file will be created accordingly on
|
||||
@@ -60,6 +64,12 @@ OPTIONS
|
||||
|
||||
|
||||
|
||||
\ **-C|-**\ **-cleanup**\
|
||||
|
||||
Remove the entries for the nodes whose definitions have been removed from xCAT db.
|
||||
|
||||
|
||||
|
||||
\ **-c|-**\ **-conserver**\
|
||||
|
||||
Only set up the conserver on the conserver host. If no conserver host
|
||||
|
||||
174
docs/source/guides/admin-guides/references/man8/makegocons.8.rst
Normal file
174
docs/source/guides/admin-guides/references/man8/makegocons.8.rst
Normal file
@@ -0,0 +1,174 @@
|
||||
|
||||
############
|
||||
makegocons.8
|
||||
############
|
||||
|
||||
.. highlight:: perl
|
||||
|
||||
|
||||
****
|
||||
NAME
|
||||
****
|
||||
|
||||
|
||||
\ **makegocons**\ - Register or unregister the node in the goconserver service
|
||||
|
||||
|
||||
********
|
||||
SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **makegocons**\ [\ **-V|-**\ **-verbose**\ ] [\ **-d|-**\ **-delete**\ ] [\ **-q|-**\ **-query**\ ] [\ *noderange*\ ]
|
||||
|
||||
\ **makegocons**\ [\ **-V|-**\ **-verbose**\ ] [\ **-C|-**\ **-cleanup**\ ]
|
||||
|
||||
|
||||
***********
|
||||
DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
The \ **makegocons**\ command will start the goconserver service if it is not started, then
|
||||
send the REST request to create or delete the session resource in the goconserver service. The session
|
||||
information including the session command or ssh connection parameters (for openbmc) is generated by xcat
|
||||
based on the records in the related tables (e.g. nodehm, ipmi, ppc, openbmc).
|
||||
|
||||
By default \ **makegocons**\ will register the session for all of the nodes in xcat.
|
||||
|
||||
If a \ *noderange*\ is specified, only the session in the specified scope will be affected, goconserver
|
||||
service will not be restarted and the other session will not be disconnected. This is the advantage
|
||||
of goconserver over the conserver service with \ **makeconservercf**\ .
|
||||
|
||||
If \ **-d**\ is specified, \ **makegocons**\ will remove the session in the goconserver service.
|
||||
|
||||
In the case of a hierarchical cluster (i.e. one with service nodes) \ **makegocons**\ will determine
|
||||
which nodes will have their consoles accessed from the management node and which from a service node
|
||||
(based on the nodehm.conserver attribute).
|
||||
|
||||
To start goconserver on the specified service node, setup goconserver package on that service node, then set
|
||||
the \ **console**\ column of \ **servicenode**\ table to \ **2**\ .
|
||||
|
||||
To support diskless service node, a new column \ **consoleenabled**\ has been added in \ **nodehm**\ table, it is used by \ **makegocons**\
|
||||
command to save the current console state for the node. After reinstalling the service node, the console storage file which maintain
|
||||
the console nodes for goconserver is lost, xCAT would register the console nodes into goconserver based on \ **consoleenabled**\ attribute
|
||||
when restarting xcatd service.
|
||||
|
||||
For openbmc which uses ssh as the terminal session connection method, goconserver can help save the system
|
||||
resources as goconserver could handle the ssh connection within goroutine which is more light-weighted than the command process.
|
||||
|
||||
\ **Note:**\ goconserver only support the systemd based systems. It has been integrated with xCAT as a recommended package.
|
||||
|
||||
|
||||
*******
|
||||
OPTIONS
|
||||
*******
|
||||
|
||||
|
||||
|
||||
\ **-d|-**\ **-delete**\
|
||||
|
||||
Delete rather than add or refresh the nodes specified as a noderange.
|
||||
|
||||
|
||||
|
||||
\ **-C|-**\ **-cleanup**\
|
||||
|
||||
Remove the entries for the nodes whose definitions have been removed from xCAT db.
|
||||
|
||||
|
||||
|
||||
\ **-q|-**\ **-query**\
|
||||
|
||||
List the console connection of the nodes. If noderange is not specified, all of the console nodes will be displayed.
|
||||
|
||||
|
||||
|
||||
\ **-v|-**\ **-version**\
|
||||
|
||||
Display version.
|
||||
|
||||
|
||||
|
||||
\ **-V|-**\ **-verbose**\
|
||||
|
||||
Verbose mode.
|
||||
|
||||
|
||||
|
||||
\ **-h|-**\ **-help**\
|
||||
|
||||
Display usage message.
|
||||
|
||||
|
||||
|
||||
|
||||
************
|
||||
RETURN VALUE
|
||||
************
|
||||
|
||||
|
||||
|
||||
0. The command completed successfully.
|
||||
|
||||
|
||||
|
||||
1. An error has occurred.
|
||||
|
||||
|
||||
|
||||
|
||||
********
|
||||
EXAMPLES
|
||||
********
|
||||
|
||||
|
||||
|
||||
1. To create goconserver configuration for all the nodes.
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
makegocons
|
||||
|
||||
|
||||
|
||||
|
||||
2. To create goconserver configuration for nodes node01-node10.
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
makegocons node01-node10
|
||||
|
||||
|
||||
|
||||
|
||||
3. To remove goconserver configuration for node01.
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
makegocons -d node01
|
||||
|
||||
|
||||
|
||||
|
||||
4. To list console connection for node01.
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
||||
makegocons -q node01
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
********
|
||||
SEE ALSO
|
||||
********
|
||||
|
||||
|
||||
rcons(1)|rcons.1
|
||||
|
||||
@@ -32,6 +32,7 @@ Table of Contents
|
||||
guides/install-guides/index.rst
|
||||
guides/admin-guides/index.rst
|
||||
advanced/index.rst
|
||||
QA/index.rst
|
||||
references/index.rst
|
||||
troubleshooting/index.rst
|
||||
developers/index.rst
|
||||
|
||||
@@ -14,6 +14,39 @@ xCAT 2.13.x
|
||||
|xCAT |New OS |New |New Feature |
|
||||
|Version | |Hardware | |
|
||||
+=================================+===============+=============+==================================+
|
||||
|| xCAT 2.13.11 | | |- OpenBMC support in python: |
|
||||
|| 2018/3/9 | | | |
|
||||
|| | | | rpower,rbeacon,rsetboot |
|
||||
| `2.13.11 Release Notes <https://| | | rinv,rvitals |
|
||||
| github.com/xcat2/xcat-core/wiki | | | |
|
||||
| /XCAT_2.13.11_Release_Notes>`_ | | |- goconserver enhancement |
|
||||
| | | | |
|
||||
| | | | makegocons -q, -C\|--cleanup |
|
||||
| | | | |
|
||||
+---------------------------------+---------------+-------------+----------------------------------+
|
||||
|| xCAT 2.13.10 | | |- OpenBMC support: |
|
||||
|| 2018/1/26 | | | |
|
||||
|| | | | rspconfig powersupplyredundancy,|
|
||||
| `2.13.10 Release Notes <https://| | | powerrestorepolicy,bootmode |
|
||||
| github.com/xcat2/xcat-core/wiki | | | reventlog implementation |
|
||||
| /XCAT_2.13.10_Release_Notes>`_ | | | |
|
||||
| | | |- goconserver enhancement |
|
||||
| | | | |
|
||||
| | | | run goconserver on SN |
|
||||
| | | | |
|
||||
| | | | redirect console log |
|
||||
+---------------------------------+---------------+-------------+----------------------------------+
|
||||
|| xCAT 2.13.9 | | |- OpenBMC support: |
|
||||
|| 2017/12/18 | | | |
|
||||
|| | | | rflash -a/-u enhance, add -d |
|
||||
| `2.13.9 Release Notes <https:// | | | |
|
||||
| github.com/xcat2/xcat-core/wiki | | | reventlog implementation |
|
||||
| /XCAT_2.13.9_Release_Notes>`_ | | | |
|
||||
| | | | rspconfig dump,hostname, |
|
||||
| | | | ntpserver,admin_passwd |
|
||||
| | | | |
|
||||
| | | |- goconserver for OpenBMC |
|
||||
+---------------------------------+---------------+-------------+----------------------------------+
|
||||
|| xCAT 2.13.8 | | |- OpenBMC support: |
|
||||
|| 2017/11/3 | | | |
|
||||
|| | | | rflash/rpower run parallelly |
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
Power9 Firmware Update
|
||||
======================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
ipmi.rst
|
||||
openbmc/index.rst
|
||||
40
docs/source/references/coral/cluster_mgmt/firmware/ipmi.rst
Normal file
40
docs/source/references/coral/cluster_mgmt/firmware/ipmi.rst
Normal file
@@ -0,0 +1,40 @@
|
||||
IPMI Firmware Update
|
||||
====================
|
||||
|
||||
The process for updating firmware on the IBM Power9 Server (Boston) is documented below.
|
||||
|
||||
|
||||
Collect the required files
|
||||
--------------------------
|
||||
|
||||
Collect the following files and put them into a directory on the Management Node.
|
||||
|
||||
* pUpdate
|
||||
* pnor
|
||||
* bmc
|
||||
|
||||
If running ``rflash`` in Hierarchy, the firmware files/directory must be accessible on the Service Nodes.
|
||||
|
||||
Flash Firmware
|
||||
--------------
|
||||
|
||||
Using xCAT ``rflash`` command, specify the directory containing the files with the ``-d`` option. ::
|
||||
|
||||
rflash <noderange> -d /path-to-directory/
|
||||
|
||||
The ``pUpdate`` utility is leveraged in doing the firmware update against the target node and will do the following:
|
||||
|
||||
* power off the host
|
||||
* flash bmc and reboot
|
||||
* flash pnor
|
||||
* power on the host
|
||||
|
||||
Monitor the progress for the nodes by looking at the files under ``/var/log/xcat/rflash/``.
|
||||
|
||||
Validatation
|
||||
------------
|
||||
|
||||
Use the ``rinv`` command to validate firmware level: ::
|
||||
|
||||
rinv <noderange> firm | xcoll
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
OpenBMC Firmware Update
|
||||
=======================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
unattended.rst
|
||||
manually.rst
|
||||
@@ -0,0 +1,10 @@
|
||||
Manual Firmware Flash
|
||||
=====================
|
||||
|
||||
.. include:: ../../../../../guides/admin-guides/manage_clusters/ppc64le/management/advanced/rflash/openbmc/openbmc_common.rst
|
||||
:start-after: BEGIN_flashing_OpenBMC_Servers
|
||||
:end-before: END_flashing_OpenBMC_Servers
|
||||
|
||||
.. include:: ../../../../../guides/admin-guides/manage_clusters/ppc64le/management/advanced/rflash/openbmc/openbmc_common.rst
|
||||
:start-after: BEGIN_Validation_OpenBMC_firmware
|
||||
:end-before: END_Validation_OpenBMC_firmware
|
||||
@@ -0,0 +1,10 @@
|
||||
Unattended Firmware Flash
|
||||
=========================
|
||||
|
||||
.. include:: ../../../../../guides/admin-guides/manage_clusters/ppc64le/management/advanced/rflash/openbmc/openbmc_common.rst
|
||||
:start-after: BEGIN_unattended_OpenBMC_flashing
|
||||
:end-before: END_unattended_OpenBMC_flashing
|
||||
|
||||
.. include:: ../../../../../guides/admin-guides/manage_clusters/ppc64le/management/advanced/rflash/openbmc/openbmc_common.rst
|
||||
:start-after: BEGIN_Validation_OpenBMC_firmware
|
||||
:end-before: END_Validation_OpenBMC_firmware
|
||||
8
docs/source/references/coral/cluster_mgmt/index.rst
Normal file
8
docs/source/references/coral/cluster_mgmt/index.rst
Normal file
@@ -0,0 +1,8 @@
|
||||
Cluster Management
|
||||
==================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
scalability/index.rst
|
||||
firmware/index.rst
|
||||
@@ -0,0 +1,7 @@
|
||||
Scalability
|
||||
===========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
python/index.rst
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
@@ -0,0 +1,12 @@
|
||||
Python framework
|
||||
================
|
||||
|
||||
When testing the scale up of xCAT commands against OpenBMC REST API, it was evident that the Perl framework of xCAT did not scale well and was not sending commands to the BMCs in a true parallel fashion.
|
||||
|
||||
The team investigated the possibility of using Python framework
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
install/index.rst
|
||||
performance.rst
|
||||
@@ -0,0 +1,14 @@
|
||||
Disable Python Framework
|
||||
========================
|
||||
|
||||
By default, if ``xCAT-openbmc-py`` is installed and Python files are there, xCAT will default to running the Python framework.
|
||||
|
||||
A site table attribute is created to allow the ability to control between Python and Perl.
|
||||
|
||||
* To disable all Python code and revert to the Perl implementation: ::
|
||||
|
||||
chdef -t site clustersite openbmcperl=ALL
|
||||
|
||||
* To disable single commands, specify a command separated lists: ::
|
||||
|
||||
chdef -t site clustersite openbmcperl="rpower,rbeacon"
|
||||
@@ -0,0 +1,12 @@
|
||||
Installation
|
||||
============
|
||||
|
||||
A new RPM is created that contains the Python code: ``xCAT-openbmc-py``. The Python code requires additonal Python libraries that may not be available as an operating system provided package. The following will help resolve the dependencies.
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
rpm.rst
|
||||
pip.rst
|
||||
disable.rst
|
||||
@@ -0,0 +1,22 @@
|
||||
Using pip
|
||||
=========
|
||||
|
||||
A alternative method for installing the Python dependencies is using ``pip``.
|
||||
|
||||
#. Download ``pip`` using one of the following methods:
|
||||
|
||||
#. ``pip`` is provided in the EPEL repo as: ``python2-pip``
|
||||
|
||||
#. Follow the instructions to install from here: https://pip.pypa.io/en/stable/installing/
|
||||
|
||||
#. Use ``pip`` to install the following Python libraries: ::
|
||||
|
||||
pip install gevent docopt requests paramiko scp
|
||||
|
||||
|
||||
#. Install ``xCAT-openbmc-py`` using ``rpm`` with ``--nodeps``: ::
|
||||
|
||||
cd xcat-core
|
||||
rpm -ihv xCAT-openbmc-py*.rpm --nodeps
|
||||
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
Using RPM (recommended)
|
||||
=======================
|
||||
|
||||
**Support is only for RHEL 7.5 for Power LE (Power 9)**
|
||||
|
||||
The following repositories should be configured on your Management Node (and Service Nodes).
|
||||
|
||||
* RHEL 7.5 OS Repository
|
||||
* RHEL 7.5 Extras Repository
|
||||
* RHEL 7 EPEL Repo (https://fedoraproject.org/wiki/EPEL)
|
||||
* Fedora28 Repo (for ``gevent``, ``greenlet``)
|
||||
|
||||
#. Configure the MN/SN to the RHEL 7.5 OS Repo
|
||||
|
||||
#. Configure the MN/SN to the RHEL 7.5 Extras Repo
|
||||
|
||||
#. Configure the MN/SN to the EPEL Repo (https://fedoraproject.org/wiki/EPEL)
|
||||
|
||||
#. Create a local Fedora28 Repo and Configure the MN/SN to the FC28 Repo
|
||||
|
||||
Here's an example to configure the Fedora 28 repo at ``/install/repos/fc28``
|
||||
|
||||
#. Make the target repo directory on the MN: ::
|
||||
|
||||
mkdir -p /install/repos/fc28/ppc64le/Packages
|
||||
|
||||
#. Download the rpms from the Internet: ::
|
||||
|
||||
cd /install/repos/fc28/ppc64le/Packages
|
||||
wget https://www.rpmfind.net/linux/fedora-secondary/development/rawhide/Everything/ppc64le/os/Packages/p/python2-gevent-1.2.2-2.fc28.ppc64le.rpm
|
||||
wget https://www.rpmfind.net/linux/fedora-secondary/development/rawhide/Everything/ppc64le/os/Packages/p/python2-greenlet-0.4.13-2.fc28.ppc64le.rpm
|
||||
|
||||
#. Create a yum repo in that directory: ::
|
||||
|
||||
cd /install/repos/fc28/ppc64le/
|
||||
createrepo .
|
||||
|
||||
#. Install ``xCAT-openbmc-py`` using ``yum``: ::
|
||||
|
||||
yum install xCAT-openbmc-py
|
||||
|
||||
**Note**: The install will fail if the dependencies cannot be met.
|
||||
@@ -0,0 +1,40 @@
|
||||
Performance
|
||||
===========
|
||||
|
||||
Supported Commands
|
||||
------------------
|
||||
|
||||
The following commands are currently supported:
|
||||
|
||||
+----------------+-----------+-------------+----------------------------------+
|
||||
|Command |Support |Release |Notes |
|
||||
+================+===========+=============+==================================+
|
||||
| rpower | Yes | 2.13.11 | |
|
||||
+----------------+-----------+-------------+----------------------------------+
|
||||
| rinv | Yes | 2.13.11 | |
|
||||
+----------------+-----------+-------------+----------------------------------+
|
||||
| rbeacon | Yes | 2.13.11 | |
|
||||
+----------------+-----------+-------------+----------------------------------+
|
||||
| rspconfig | No | | |
|
||||
+----------------+-----------+-------------+----------------------------------+
|
||||
| rsetboot | Yes | 2.13.11 | |
|
||||
+----------------+-----------+-------------+----------------------------------+
|
||||
| rvitals | Yes | 2.13.11 | |
|
||||
+----------------+-----------+-------------+----------------------------------+
|
||||
| rflash | No | | |
|
||||
+----------------+-----------+-------------+----------------------------------+
|
||||
| reventlog | No | | |
|
||||
+----------------+-----------+-------------+----------------------------------+
|
||||
|
||||
|
||||
Data
|
||||
----
|
||||
|
||||
The following graph shows performance gains in the Python code implementation of ``mgt=openbmc`` when compared to the Perl implementation.
|
||||
|
||||
rpower <noderange> state
|
||||
````````````````````````
|
||||
|
||||
This chart gathers data points on a single 18-node frame, up to 4 frames (72-nodes).
|
||||
|
||||
.. image:: images/rpower_state.png
|
||||
@@ -7,6 +7,7 @@ CORAL stands for Collaboration of Oak Ridge, Argonne, and Livermore and is solut
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
cluster_mgmt/index.rst
|
||||
known_issues/index.rst
|
||||
.. mn/index.rst
|
||||
.. discovery/index.rst
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user