mirror of
https://github.com/xcat2/xcat-core.git
synced 2025-05-22 03:32:04 +00:00
Spelling for man1 and some formatting fixes
This commit is contained in:
parent
89356b69a2
commit
ae09fdfe6d
@ -567,7 +567,7 @@ Set the next boot state for the node1. ::
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
GET - Get all the vitals attributes.
|
||||
```````````````````````````````````
|
||||
````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`rvitals </guides/admin-guides/references/man1/rvitals.1>`
|
||||
|
||||
@ -598,7 +598,7 @@ Get all the vitails attributes for the node1. ::
|
||||
--------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
GET - Get the specific vitals attributes.
|
||||
````````````````````````````````````````
|
||||
`````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`rvitals </guides/admin-guides/references/man1/rvitals.1>`
|
||||
|
||||
@ -629,7 +629,7 @@ Get the 'fanspeed' vitals attribute. ::
|
||||
--------------------------------------------------------------------------------------
|
||||
|
||||
GET - Get all the inventory attributes.
|
||||
``````````````````````````````````````
|
||||
```````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`rinv </guides/admin-guides/references/man1/rinv.1>`
|
||||
|
||||
@ -660,7 +660,7 @@ Get all the inventory attributes for node1. ::
|
||||
--------------------------------------------------------------------------------------------------------------
|
||||
|
||||
GET - Get the specific inventory attributes.
|
||||
```````````````````````````````````````````
|
||||
````````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`rinv </guides/admin-guides/references/man1/rinv.1>`
|
||||
|
||||
@ -1130,7 +1130,7 @@ Create osimage resources based on an xCAT image or configuration file ::
|
||||
------------------------------------------------
|
||||
|
||||
GET - Get all the attributes for the osimage {imgname}.
|
||||
``````````````````````````````````````````````````````
|
||||
```````````````````````````````````````````````````````
|
||||
|
||||
The keyword ALLRESOURCES can be used as {imgname} which means to get image attributes for all the osimages.
|
||||
|
||||
@ -1163,7 +1163,7 @@ Get the attributes for the specified osimage. ::
|
||||
}
|
||||
|
||||
PUT - Change the attributes for the osimage {imgname}.
|
||||
`````````````````````````````````````````````````````
|
||||
``````````````````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1>`
|
||||
|
||||
@ -1348,7 +1348,7 @@ Create the networks resources base on the network configuration on xCAT MN. ::
|
||||
------------------------------------------------
|
||||
|
||||
GET - Get all the attributes for the network {netname}.
|
||||
``````````````````````````````````````````````````````
|
||||
```````````````````````````````````````````````````````
|
||||
|
||||
The keyword ALLRESOURCES can be used as {netname} which means to get network attributes for all the networks.
|
||||
|
||||
@ -1375,7 +1375,7 @@ Get all the attributes for network 'network1'. ::
|
||||
}
|
||||
|
||||
PUT - Change the attributes for the network {netname}.
|
||||
`````````````````````````````````````````````````````
|
||||
``````````````````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1>`
|
||||
|
||||
@ -1488,7 +1488,7 @@ Get all the policy objects. ::
|
||||
-----------------------------------------------------
|
||||
|
||||
GET - Get all the attributes for a policy {policy_priority}.
|
||||
```````````````````````````````````````````````````````````
|
||||
````````````````````````````````````````````````````````````
|
||||
|
||||
It will display all the policy attributes for one policy resource.
|
||||
|
||||
@ -1513,7 +1513,7 @@ Get all the attribute for policy 1. ::
|
||||
}
|
||||
|
||||
PUT - Change the attributes for the policy {policy_priority}.
|
||||
````````````````````````````````````````````````````````````
|
||||
`````````````````````````````````````````````````````````````
|
||||
|
||||
It will change one or more attributes for a policy.
|
||||
|
||||
@ -1638,7 +1638,7 @@ Get all the group names from xCAT database. ::
|
||||
----------------------------------------------
|
||||
|
||||
GET - Get all the attributes for the group {groupname}.
|
||||
``````````````````````````````````````````````````````
|
||||
```````````````````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`lsdef </guides/admin-guides/references/man1/lsdef.1>`
|
||||
|
||||
@ -1658,7 +1658,7 @@ Get all the attributes for group 'all'. ::
|
||||
}
|
||||
|
||||
PUT - Change the attributes for the group {groupname}.
|
||||
`````````````````````````````````````````````````````
|
||||
``````````````````````````````````````````````````````
|
||||
|
||||
Refer to the man page: :doc:`chdef </guides/admin-guides/references/man1/chdef.1>`
|
||||
|
||||
@ -1955,7 +1955,7 @@ URI list which can be used to create, query, change table entries.
|
||||
For a large number of nodes, this API call can be faster than using the corresponding nodes resource. The disadvantage is that you need to know the table names the attributes are stored in.
|
||||
|
||||
GET - Get attributes of tables for a noderange.
|
||||
``````````````````````````````````````````````
|
||||
```````````````````````````````````````````````
|
||||
|
||||
**Returns:**
|
||||
|
||||
@ -2026,7 +2026,7 @@ Get all the columns from tables nodetype and noderes for node1 and node2. ::
|
||||
}
|
||||
|
||||
PUT - Change the node table attributes for {noderange}.
|
||||
``````````````````````````````````````````````````````
|
||||
```````````````````````````````````````````````````````
|
||||
|
||||
**Parameters:**
|
||||
|
||||
@ -2048,7 +2048,7 @@ Change the nodetype.arch and noderes.netboot attributes for nodes node1,node2. :
|
||||
For a large number of nodes, this API call can be faster than using the corresponding nodes resource. The disadvantage is that you need to know the table names the attributes are stored in.
|
||||
|
||||
GET - Get table attributes for a noderange.
|
||||
``````````````````````````````````````````
|
||||
```````````````````````````````````````````
|
||||
|
||||
**Returns:**
|
||||
|
||||
@ -2120,7 +2120,7 @@ Use this for tables that don't have node name as the key of the table, for examp
|
||||
{keys} should be the name=value pairs which are used to search table. e.g. {keys} should be [net=192.168.1.0,mask=255.255.255.0] for networks table query since the net and mask are the keys of networks table.
|
||||
|
||||
GET - Get attributes for rows from non-node tables.
|
||||
``````````````````````````````````````````````````
|
||||
```````````````````````````````````````````````````
|
||||
|
||||
**Returns:**
|
||||
|
||||
|
@ -25,7 +25,7 @@ Creating additional branches will allow you to work on different tasks/enhanceme
|
||||
|
||||
|
||||
Committing code and pushing to remote branch
|
||||
-------------------------------------------
|
||||
--------------------------------------------
|
||||
|
||||
Once your code is ready....
|
||||
|
||||
|
@ -46,7 +46,7 @@ The xCAT ``rcons`` command relies on conserver (http://www.conserver.com/). The
|
||||
|
||||
|
||||
OpenBMC Specific
|
||||
```````````````
|
||||
````````````````
|
||||
|
||||
#. For OpenBMC managed servers, the root user must be able to ssh passwordless to the BMC for the ``rcons`` function to work.
|
||||
|
||||
|
@ -35,7 +35,7 @@ DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
The \ **bmcdiscover**\ command will discover Baseboard Management Controllers (BMCs) using a scan mathod.
|
||||
The \ **bmcdiscover**\ command will discover Baseboard Management Controllers (BMCs) using a scan method.
|
||||
|
||||
The command uses \ **nmap**\ to scan active nodes over a specified IP range. The IP range format should be a format that is acceptable by \ **nmap**\ .
|
||||
|
||||
@ -52,7 +52,7 @@ OPTIONS
|
||||
|
||||
\ **-**\ **-range**\
|
||||
|
||||
Specify one or more IP ranges acceptable to nmap. IP rance can be hostnames, IP addresses, networks, etc. A single IP address (10.1.2.3) or an IP range (10.1.2.0/24) can be specified. If the range is very large, the \ **bmcdiscover**\ command may take a long time to return.
|
||||
Specify one or more IP ranges acceptable to nmap. IP range can be hostnames, IP addresses, networks, etc. A single IP address (10.1.2.3) or an IP range (10.1.2.0/24) can be specified. If the range is very large, the \ **bmcdiscover**\ command may take a long time to return.
|
||||
|
||||
|
||||
|
||||
|
@ -98,7 +98,7 @@ OPTIONS
|
||||
be owned by vdsm:kvm.
|
||||
\ **localfs**\ : "/data/images/rhev" is set by default.
|
||||
|
||||
\ **virtsd.host**\ - A host must be specified for a storage doamin as SPM
|
||||
\ **virtsd.host**\ - A host must be specified for a storage domain as SPM
|
||||
(Storage Pool Manager) when initialize the storage domain. The role of SPM
|
||||
may be migrated to other host by rhev-m during the running of the datacenter
|
||||
(For example, when the current SPM encountered issue or going to maintenance
|
||||
|
@ -151,7 +151,7 @@ PPC (using Direct FSP Management) specific:
|
||||
|
||||
For Power 755(use option \ *--p775*\ to specify):
|
||||
|
||||
chvm could be used to change the octant configuration values for generating LPARs. chvm is designed to set the Octant configure value to split the CPU and memory for partitions, and set Octant Memory interleaving value. The chvm will only set the pending attributes value. After chvm, the CEC needs to be rebooted manually for the pending values to be enabled. Before reboot the cec, the administrator can use chvm to change the partition plan. If the the partition needs I/O slots, the administrator should use chvm to assign the I/O slots.
|
||||
chvm could be used to change the octant configuration values for generating LPARs. chvm is designed to set the Octant configure value to split the CPU and memory for partitions, and set Octant Memory interleaving value. The chvm will only set the pending attributes value. After chvm, the CEC needs to be rebooted manually for the pending values to be enabled. Before reboot the cec, the administrator can use chvm to change the partition plan. If the partition needs I/O slots, the administrator should use chvm to assign the I/O slots.
|
||||
|
||||
chvm is also designed to assign the I/O slots to the new LPAR. Both the current IO owning lpar and the new IO owning lpar must be powered off before an IO assignment. Otherwise, if the I/O slot is belonged to an Lpar and the LPAR is power on, the command will return an error when trying to assign that slot to a different lpar.
|
||||
|
||||
@ -166,7 +166,7 @@ zVM specific:
|
||||
=============
|
||||
|
||||
|
||||
The chvm command modifes the virtual machine's configuration specified in noderange.
|
||||
The chvm command modifies the virtual machine's configuration specified in noderange.
|
||||
|
||||
|
||||
|
||||
@ -336,7 +336,7 @@ VMware/KVM specific:
|
||||
|
||||
\ **-**\ **-resize**\ \ *disk*\ =\ *size*\
|
||||
|
||||
Change the size of the Hard disk. The disk in \ *qcow2*\ format can not be set to less than it's current size. The disk in \ *raw*\ format can be resized smaller, use caution. Multiple disks can be resized by using comma separated \ *disk*\ \ **=**\ \ *size*\ pairs. The disks are specified by SCSI id. Size defaults to GB.
|
||||
Change the size of the Hard disk. The disk in \ *qcow2*\ format can not be set to less than its current size. The disk in \ *raw*\ format can be resized smaller, use caution. Multiple disks can be resized by using comma separated \ *disk*\ \ **=**\ \ *size*\ pairs. The disks are specified by SCSI id. Size defaults to GB.
|
||||
|
||||
|
||||
|
||||
|
@ -29,7 +29,7 @@ DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
The csm2xcat command must be run on the Management Server of the CSM system that you want to migrate to xCAT. The commmand will build two xCAT stanza files that can update the xCAT database with the chdef command.
|
||||
The csm2xcat command must be run on the Management Server of the CSM system that you want to migrate to xCAT. The command will build two xCAT stanza files that can update the xCAT database with the chdef command.
|
||||
|
||||
Copy the csm2xcat command to the CSM Management Server. Run the command, indicating where you want your stanza files saved with the \ **-**\ **-dir**\ parameter. Check the stanza files to see if the information is what you want put in the xCAT database. Copy the two stanza files: node.stanza, device.stanza back to your xCAT Management node, and run the chdef command to input into the xCAT database.
|
||||
|
||||
|
@ -46,7 +46,7 @@ For full information on the setup of DB2, see Setting_Up_DB2_as_the_xCAT_DB.
|
||||
|
||||
When running of db2sqlsetup on the MN:
|
||||
One password must be supplied for the setup, a password for the xcatdb unix id which will be used as the DB2 instance id and database name. The password will be prompted for interactively or can be input with the XCATDB2PW environment variable.
|
||||
The script will create the xcat database instance (xcatdb) in the /var/lib/db2 directory unless overriden by setting the site.databaseloc attribute. This attribute should not be set to the directory that is defined in the installloc attribute and it is recommended that the databaseloc be a new filesystem dedicated to the DB2 database, especially in very large clusters.
|
||||
The script will create the xcat database instance (xcatdb) in the /var/lib/db2 directory unless overridden by setting the site.databaseloc attribute. This attribute should not be set to the directory that is defined in the installloc attribute and it is recommended that the databaseloc be a new filesystem dedicated to the DB2 database, especially in very large clusters.
|
||||
|
||||
When running db2sqlseutp on the SN:
|
||||
Not only will the password for the DB2 instance Id be prompted for and must match the one on the Management Node; but also the hostname or ip address of the Management Node as known by the Service Node must be supplied , unless the XCATDB2SERVER environment variable is set.
|
||||
|
@ -35,7 +35,7 @@ If not using the binary dump option (-b), then the dumpxCATdb command creates .c
|
||||
Supports using XCAT_SKIPTABLES env variable to provide a list of skip tables.
|
||||
The command will never backup TEAL or ISNM tables, except isnm_config. To dump TEAL tables use the documented process for TEAL. For ISNM use tabdump, after using tabprune to get to prune unnecessary records.
|
||||
|
||||
If using the binary dump option for the DB2 or postgreSQL database, then the routine will use the Database provide utilites for backup of the entire database.
|
||||
If using the binary dump option for the DB2 or postgreSQL database, then the routine will use the Database provide utilities for backup of the entire database.
|
||||
|
||||
|
||||
*******
|
||||
@ -49,7 +49,7 @@ OPTIONS
|
||||
|
||||
\ **-V**\ Verbose.
|
||||
|
||||
\ **-a**\ All,without this flag the eventlog and auditlog will be skipped.
|
||||
\ **-a**\ All, without this flag the eventlog and auditlog will be skipped.
|
||||
|
||||
\ **-b**\ This flag is only used for the DB2 or postgreSQL database. The routine will use the database backup utilities to create a binary backup of the entire database. Note to use this backup on DB2, you will have first had to modify the logging of the database and have taken an offline initial backup. Refer to the xCAT DB2 documentation for more instructions.
|
||||
|
||||
|
@ -46,7 +46,7 @@ for stateless: \ **packimage**\
|
||||
|
||||
for statelite: \ **liteimg**\
|
||||
|
||||
Besides prompting for some paramter values, the \ **genimage**\ command takes default guesses for the parameters not specified or not defined in the \ *osimage*\ and \ *linuximage*\ tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Use \ **-**\ **-interactive**\ flag if you want the yum/zypper command to prompt you for the answers.
|
||||
Besides prompting for some parameter values, the \ **genimage**\ command takes default guesses for the parameters not specified or not defined in the \ *osimage*\ and \ *linuximage*\ tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Use \ **-**\ **-interactive**\ flag if you want the yum/zypper command to prompt you for the answers.
|
||||
|
||||
If \ **-**\ **-onlyinitrd**\ is specified, genimage only regenerates the initrd for a stateless image to be used for a diskless install.
|
||||
|
||||
|
@ -43,7 +43,7 @@ If the initrd has been rebuilt by geninitrd, when run nodeset, the \ *--noupdate
|
||||
should be used to skip the rebuilding of initrd to improve the performance.
|
||||
|
||||
Three attributes of osimage object can be used to specify the Driver RPM location and Driver names
|
||||
for injecting new drviers to initrd.
|
||||
for injecting new drivers to initrd.
|
||||
|
||||
\ **netdrivers**\ - comma separated driver names that need to be injected to the initrd.
|
||||
The postfix '.ko' can be ignored. The netdrivers attribute must be set to specify the new driver list.
|
||||
@ -65,7 +65,7 @@ this command is used to generate the initrd from the rootimg which generated by
|
||||
So the 'genimage' must be run once before running the geninitrd command.
|
||||
|
||||
Two attributes of osimage object can be used to specify the Driver RPM location and Driver names
|
||||
for injecting new drviers to initrd.
|
||||
for injecting new drivers to initrd.
|
||||
|
||||
\ **netdrivers**\ - comma separated driver names that need to be injected to the initrd.
|
||||
The postfix '.ko' can be ignored. The netdrivers attribute must be set to specify the new driver list.
|
||||
@ -79,7 +79,7 @@ Parameters
|
||||
**********
|
||||
|
||||
|
||||
\ *imagename*\ specifies the name of an os image definition to be used. The specification for the image is storted in the \ *osimage*\ table and \ *linuximage*\ table.
|
||||
\ *imagename*\ specifies the name of an os image definition to be used. The specification for the image is stored in the \ *osimage*\ table and \ *linuximage*\ table.
|
||||
|
||||
|
||||
\ **-**\ **-ignorekernelchk**\
|
||||
|
@ -35,8 +35,8 @@ Traditionally, network interfaces in Linux are enumerated as eth[0123...], but t
|
||||
|
||||
\ **getadapter**\ For each node within the <noderange>, follows below scheme:
|
||||
|
||||
If the target node is scaned for the first time, \ **getadapter**\ will trigger genesis to collect information then save the information at the \ **nicsadapter**\ column of nics table.
|
||||
If the target node has ever been scaned, \ **getadapter**\ will use the information from nics table first.
|
||||
If the target node is scanned for the first time, \ **getadapter**\ will trigger genesis to collect information then save the information at the \ **nicsadapter**\ column of nics table.
|
||||
If the target node has ever been scanned, \ **getadapter**\ will use the information from nics table first.
|
||||
If user hopes to scan the adapter information for the node but these information already exist, \ **-f**\ option can be used to start rescan process.
|
||||
|
||||
\ **getadapter**\ tries to collect more information for the target network device, but doesn't guarantee collect same much information for every network device.
|
||||
|
@ -51,12 +51,12 @@ DESCRIPTION
|
||||
|
||||
|
||||
The getmacs command collects MAC address from a single or range of nodes.
|
||||
Note that on AIX systems, the returned MAC address is not colon-seperated (for example 8ee2245cf004), while on Linux systems the MAC address is colon-seperated (for example 8e:e2:24:5c:f0:04).
|
||||
Note that on AIX systems, the returned MAC address is not colon-separated (for example 8ee2245cf004), while on Linux systems the MAC address is colon-separated (for example 8e:e2:24:5c:f0:04).
|
||||
If no ping test performed, getmacs writes the first adapter MAC to the xCAT database. If ping test performed, getmacs will write the first successfully pinged MAC to xCAT database.
|
||||
|
||||
For PPC (using Direct FSP Management) specific:
|
||||
|
||||
Note: If network adapters are physically assigned to LPARs, getmacs cannot read the MAC addresses unless perform \ **Discovery**\ with option "\ **-D**\ ", since there is no HMC command to read them and getmacs has to login to open formware. And if the LPARs has never been activated before, getmacs need to be performed with the option "\ **-D**\ " to get theirs MAC addresses.
|
||||
Note: If network adapters are physically assigned to LPARs, getmacs cannot read the MAC addresses unless perform \ **Discovery**\ with option "\ **-D**\ ", since there is no HMC command to read them and getmacs has to login to open firmware. And if the LPARs has never been activated before, getmacs need to be performed with the option "\ **-D**\ " to get theirs MAC addresses.
|
||||
|
||||
For PPC (using HMC) specific:
|
||||
|
||||
@ -74,7 +74,7 @@ OPTIONS
|
||||
|
||||
\ **-**\ **-arp**\
|
||||
|
||||
Read MAC address with ARP protocal.
|
||||
Read MAC address with ARP protocol.
|
||||
|
||||
\ **-C**\
|
||||
|
||||
@ -90,7 +90,7 @@ Perform discovery for mac address. By default, it will run ping test to test th
|
||||
|
||||
\ **-f**\
|
||||
|
||||
Force immediate shutdown of the partition.This flag must be used with -D flag.
|
||||
Force immediate shutdown of the partition. This flag must be used with -D flag.
|
||||
|
||||
\ **-F**\
|
||||
|
||||
@ -118,7 +118,7 @@ Read MAC address when the lpar is in openfirmware state. This option mush be us
|
||||
|
||||
\ **-S**\
|
||||
|
||||
The IP address of the machine to ping. The default is to read from xCAT databse if no \ **-S**\ specified.
|
||||
The IP address of the machine to ping. The default is to read from xCAT database if no \ **-S**\ specified.
|
||||
|
||||
\ **-v**\
|
||||
|
||||
@ -167,7 +167,7 @@ Output is similar to:
|
||||
ent U78A1.001.99203B5-P1-T6 00145eb55788 /lhea@23c00614/ethernet@23e00514 unsuccessful physical
|
||||
|
||||
|
||||
2. To retrieve the MAC address with ARP protocal:
|
||||
2. To retrieve the MAC address with ARP protocol:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
@ -33,7 +33,7 @@ This tool will build a directory of files, one for each defined
|
||||
nodegroup in xCAT. The file will be named the nodegroup name and
|
||||
contain a list of nodes that belong to the nodegroup.
|
||||
The file can be used as input to the AIX dsh command.
|
||||
The purpose of this tool is to allow backward compatiblity with scripts
|
||||
The purpose of this tool is to allow backward compatibility with scripts
|
||||
that were created using the AIX or CSM dsh command
|
||||
|
||||
Reference: man dsh.
|
||||
|
@ -61,7 +61,7 @@ For statelite:
|
||||
|
||||
where x is the name of the profile.
|
||||
|
||||
Any files specified by the \ **-e**\ flag will also be exported. If \ **-p**\ flag is specified, the names of the postscripts and the postbootscripts for the given node will be exported. The postscripts themsleves need to be manualy exported using \ **-e**\ flag.
|
||||
Any files specified by the \ **-e**\ flag will also be exported. If \ **-p**\ flag is specified, the names of the postscripts and the postbootscripts for the given node will be exported. The postscripts themselves need to be manualy exported using \ **-e**\ flag.
|
||||
|
||||
For statelite, the litefile table settings for the image will also be exported. The litetree and statelite tables are not exported.
|
||||
|
||||
|
@ -69,7 +69,7 @@ If \ **-p**\ flag is specified, the \ *postscripts*\ table will be updated wit
|
||||
|
||||
If \ **-f**\ flag is not specified, all the files will be copied to the same directories as the source. If it is specified, the old profile name x will be changed to the new and the files will be copied to the appropriate directores for the new profiles. For example, \ */opt/xcat/share/xcat/netboot/sles/x.pkglist*\ will be copied to \ */install/custom/netboot/sles/compute_new.pkglist*\ and \ */install/netboot/sles11/ppc64/x/kernel*\ will be copied to \ */install/netboot/sles11/ppc64/compute_new/kernel*\ . This flag is commonly used when you want to copy the image on the same xCAT mn so you can make modification on the new one.
|
||||
|
||||
After this command, you can run the \ **nodeset**\ command and then start deploying the nodes. You can also choose to modify the files and run the following commands before the node depolyment.
|
||||
After this command, you can run the \ **nodeset**\ command and then start deploying the nodes. You can also choose to modify the files and run the following commands before the node deployment.
|
||||
|
||||
For stateful:
|
||||
nodeset
|
||||
|
@ -63,7 +63,7 @@ PARAMETERS
|
||||
**********
|
||||
|
||||
|
||||
\ *imagename*\ specifies the name of a os image definition to be used. The specification for the image is storted in the \ *osimage*\ table and \ *linuximage*\ table.
|
||||
\ *imagename*\ specifies the name of a os image definition to be used. The specification for the image is stored in the \ *osimage*\ table and \ *linuximage*\ table.
|
||||
|
||||
|
||||
*******
|
||||
|
@ -38,7 +38,7 @@ There are several concepts to support the HX5 multiple blades combination:
|
||||
|
||||
\ **Complex**\ : Multiple blades which combined by a scalability card is a complex.
|
||||
|
||||
\ **Parition**\ : A logic concept which containing part of the \ **Blade slot node**\ in a complex. Each partition can map to a system to install Operating System. Each partition could have 1HX5, 1HX5+1MD or 2HX5+2MD. (MD is the Memory Drawer)
|
||||
\ **Partition**\ : A logic concept which containing part of the \ **Blade slot node**\ in a complex. Each partition can map to a system to install Operating System. Each partition could have 1HX5, 1HX5+1MD or 2HX5+2MD. (MD is the Memory Drawer)
|
||||
|
||||
\ **Blade slot node**\ : The physical blade which installed in the slot of a chassis. It can be a HX5 or MD.
|
||||
|
||||
|
@ -89,7 +89,7 @@ OPTIONS
|
||||
</data>
|
||||
|
||||
|
||||
Each <kitinfo> tag contains info for a group of kit compoonents belonging to the same kit. The info inside <kitinfo> is structured as follows:
|
||||
Each <kitinfo> tag contains info for a group of kit components belonging to the same kit. The info inside <kitinfo> is structured as follows:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
@ -41,13 +41,13 @@ OPTIONS
|
||||
*******
|
||||
|
||||
|
||||
\ **noderange**\ The nodes which the user want to discover. If the user specify the noderange, lsslp will just return the nodes in the node range. Which means it will help to add the new nodes to the xCAT database without modifying the existed definitions. But the nodes' name specified in noderange should be defined in database in advance. The specified nodes' type can be frame/cec/hmc/fsp/bpa. If the it is frame or cec, lsslp will list the bpa or fsp nodes within the nodes(bap for frame, fsp for cec). Do not use noderange with the flag -s.
|
||||
\ **noderange**\ The nodes which the user wants to discover. If the user specifies the noderange, lsslp will just return the nodes in the node range. Which means it will help to add the new nodes to the xCAT database without modifying the existed definitions. But the nodes' name specified in noderange should be defined in database in advance. The specified nodes' type can be frame/cec/hmc/fsp/bpa. If the it is frame or cec, lsslp will list the bpa or fsp nodes within the nodes(bap for frame, fsp for cec). Do not use noderange with the flag -s.
|
||||
|
||||
\ **-i**\ IP(s) the command will send out (defaults to all available adapters).
|
||||
|
||||
\ **-h**\ Display usage message.
|
||||
|
||||
\ **-n**\ Only display and write the newly discovered hardwares.
|
||||
\ **-n**\ Only display and write the newly discovered hardware.
|
||||
|
||||
\ **-u**\ Do unicast to a specified IP range. Must be used with \ **-s**\ and \ **-**\ **-range**\ . The \ **-u**\ flag is not supported on AIX.
|
||||
|
||||
@ -55,15 +55,15 @@ OPTIONS
|
||||
|
||||
\ **-r**\ Display Raw SLP response.
|
||||
|
||||
\ **-C**\ The number of the expected responses specified by the user. When using this flag, lsslp will not return until the it has found all the nodes or time out. The default max time is 3 secondes. The user can use -T flag the specify the time they want to use. A short time will limite the time costing, while a long time will help to find all the nodes.
|
||||
\ **-C**\ The number of the expected responses specified by the user. When using this flag, lsslp will not return until the it has found all the nodes or time out. The default max time is 3 seconds. The user can use -T flag the specify the time they want to use. A short time will limit the time costing, while a long time will help to find all the nodes.
|
||||
|
||||
\ **-T**\ The number in seconds to limite the time costing of lsslp.
|
||||
\ **-T**\ The number in seconds to limit the time of lsslp.
|
||||
|
||||
\ **-s**\ Service type interested in discovering.
|
||||
|
||||
\ **-t**\ Number or service-request attempts.
|
||||
|
||||
\ **-**\ **-vpdtable**\ Output the SLP response in vpdtable formatting. Easy for writting data to vpd table.
|
||||
\ **-**\ **-vpdtable**\ Output the SLP response in vpdtable formatting. Easy for writing data to vpd table.
|
||||
|
||||
\ **-v**\ Command Version.
|
||||
|
||||
@ -73,9 +73,9 @@ OPTIONS
|
||||
|
||||
\ **-x**\ XML format.
|
||||
|
||||
\ **-z**\ Stanza formated output.
|
||||
\ **-z**\ Stanza formatted output.
|
||||
|
||||
\ **-I**\ Give the warning message for the nodes in database which have no SLP responses. Note that this flag noly can be used after the database migration finished successfully.
|
||||
\ **-I**\ Give the warning message for the nodes in database which have no SLP responses. Note that this flag can only be used after the database migration finished successfully.
|
||||
|
||||
|
||||
************
|
||||
|
@ -29,7 +29,7 @@ DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
The \ **lstree**\ command can display the tree of service node hierarchy for the xCAT nodes which have service node defined or which are service nodes, display the tree of hardware hierarchy only for the physical objects, display the tree of VM hierarchy for the xCAT nodes which are virtual machines or which are the hosts of virtual machines. If a noderange is specified, only show the part of the hierarchy that involves those nodes. For ZVM, we only support to disply VM hierarchy. By default, lstree will show both the hardware hierarchy and the VM hierarchy for all the nodes.
|
||||
The \ **lstree**\ command can display the tree of service node hierarchy for the xCAT nodes which have service node defined or which are service nodes, display the tree of hardware hierarchy only for the physical objects, display the tree of VM hierarchy for the xCAT nodes which are virtual machines or which are the hosts of virtual machines. If a noderange is specified, only show the part of the hierarchy that involves those nodes. For ZVM, we only support to display VM hierarchy. By default, lstree will show both the hardware hierarchy and the VM hierarchy for all the nodes.
|
||||
|
||||
|
||||
*******
|
||||
|
@ -360,7 +360,7 @@ Output is similar to:
|
||||
Available BSR array: 256
|
||||
|
||||
|
||||
Note: The lines listed in "All Physical I/O info" section represent all the physical I/O resource information. The format is like "owner_lparid,slot_id,physical resource name,drc_index,slot_class_code(class discription)". The 'drc index' is short for Dynamic Resource Configuration Index, it uniquely indicates a physical I/O resource in a normal power machine.
|
||||
Note: The lines listed in "All Physical I/O info" section represent all the physical I/O resource information. The format is like "owner_lparid,slot_id,physical resource name,drc_index,slot_class_code(class description)". The 'drc index' is short for Dynamic Resource Configuration Index, it uniquely indicates a physical I/O resource in a normal power machine.
|
||||
|
||||
9. For DFM-managed partition on normal power machine, list out the detailed information:
|
||||
|
||||
|
@ -84,7 +84,7 @@ OPTIONS
|
||||
|
||||
\ **-**\ **-template**\ \ *template-object-name*\
|
||||
|
||||
Name of the xCAT shipped object definition template or an existing object, from which the new object definition will be created. The newly created object will inherit the attributes of the template definition unless the attribute is specified in the arguments of \ **mkdef**\ command. If there are a template and an existing object with the same name \ *template-object-name*\ , the tempalte object takes precedence over the existing object. For the details of xCAT shipped object definition templates, refer to the manpage of \ **-**\ **-template**\ option in lsdef(1)|lsdef.1.
|
||||
Name of the xCAT shipped object definition template or an existing object, from which the new object definition will be created. The newly created object will inherit the attributes of the template definition unless the attribute is specified in the arguments of \ **mkdef**\ command. If there are a template and an existing object with the same name \ *template-object-name*\ , the template object takes precedence over the existing object. For the details of xCAT shipped object definition templates, refer to the manpage of \ **-**\ **-template**\ option in lsdef(1)|lsdef.1.
|
||||
|
||||
|
||||
|
||||
@ -96,7 +96,7 @@ OPTIONS
|
||||
|
||||
\ **-w**\ \ *attr==val*\ \ **-w**\ \ *attr=~val*\ ...
|
||||
|
||||
Use one or multiple -w flags to specify the selection string that can be used to select objects. The operators ==, !=, =~ and !~ are available. For mkdef commmand, the -w flag only makes sense for creating dynamic node group. Use the help option to get a list of valid attributes for each object type.
|
||||
Use one or multiple -w flags to specify the selection string that can be used to select objects. The operators ==, !=, =~ and !~ are available. For mkdef command, the -w flag only makes sense for creating dynamic node group. Use the help option to get a list of valid attributes for each object type.
|
||||
|
||||
Operator descriptions:
|
||||
== Select nodes where the attribute value is exactly this value.
|
||||
|
@ -137,7 +137,7 @@ Output is similar to:
|
||||
host01c01: Pull image ubuntu start
|
||||
host01c01: Pull image ubuntu done
|
||||
host01c01: Remove default network connection
|
||||
host01c01: Connecting customzied network 'mynet0'
|
||||
host01c01: Connecting customized network 'mynet0'
|
||||
host01c01: success
|
||||
|
||||
|
||||
@ -155,7 +155,7 @@ Output is similar to:
|
||||
.. code-block:: perl
|
||||
|
||||
host01c01: Remove default network connection
|
||||
host01c01: Connecting customzied network 'mynet0'
|
||||
host01c01: Connecting customized network 'mynet0'
|
||||
host01c01: success
|
||||
|
||||
|
||||
|
@ -38,7 +38,7 @@ This command will also create a NIM resolv_conf resource to be used when install
|
||||
The "domain" and "nameservers" attributes can be set in either the xCAT "network" definition used by the nodes or in the xCAT cluster "site" definition. The setting in the "network" definition will take priority.
|
||||
|
||||
The "search" field of the resolv.conf file will contain a list all the domains
|
||||
listed in the xCAT network definitions and the xCAT site definiton.
|
||||
listed in the xCAT network definitions and the xCAT site definition.
|
||||
|
||||
The "nameservers" value can either be set to a specific IP address or the "<xcatmaster>" key word. The "<xcatmaster>" key word means that the value of the "xcatmaster" attribute of the node definition will be used in the /etc/resolv.conf file. (I.e. The name of the install server as known by the node.)
|
||||
|
||||
@ -57,11 +57,11 @@ You can use the "-n" option of the mkdsklsnode command to create and initialize
|
||||
|
||||
\ **Note:**\ When using the "-n" option make sure that the new osimage you specify and all the NIM resources that are used are different than what are currently being used on the nodes. The NIM resources should not be shared between the old osimage and the new osimage.
|
||||
|
||||
You can use the force option to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinititializing. Use this option with caution since reinitializing a node will stop the node if it is currently running.
|
||||
You can use the force option to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinitializing. Use this option with caution since reinitializing a node will stop the node if it is currently running.
|
||||
|
||||
After the mkdsklsnode command completes you can use the \ **lsnim**\ command to check the NIM node definition to see if it is ready for booting the node. ("lsnim -l <nim_node_name>").
|
||||
|
||||
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **mkdsklsnode**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts dirctory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **mkdsklsnode**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **mkdsklsnode**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *diskless:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current current nodeset action, in this case "diskless". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes.
|
||||
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **mkdsklsnode**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts directory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **mkdsklsnode**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **mkdsklsnode**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *diskless:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "diskless". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at a time. If it is not specified, the script will be invoked once for all the nodes.
|
||||
|
||||
|
||||
*******
|
||||
|
@ -43,7 +43,7 @@ When creating a mksysb image definition you must specify either the "-n" or the
|
||||
|
||||
When creating a diskless osimage definition you also have the option of automatically updating the NIM SPOT resource. You can have additional software installed or you can have configuration files added or updated. To have software installed you must provide either the names of NIM installp_bundle resources or fileset names on the command line using the "attr=val" option. You may also supply the installp flags, RPM flags, emgr flags to use when installing the software.
|
||||
|
||||
To have configuration files updated you must provide the full path name of a "synclists" file which contains the the list of actual files to update. The xCAT osimage definition that is created will contain the installp_bundle, otherpkgs, and synclists files that are provided on the command line.
|
||||
To have configuration files updated you must provide the full path name of a "synclists" file which contains the list of actual files to update. The xCAT osimage definition that is created will contain the installp_bundle, otherpkgs, and synclists files that are provided on the command line.
|
||||
|
||||
\ **Updating an existing xCAT osimage**\
|
||||
|
||||
@ -69,7 +69,7 @@ You can use the "-i" and "-p" options to copy an existing diskless osimage. To
|
||||
|
||||
- any other resources (or attributes) included in the original osimage will be included in the new osimage definition.
|
||||
|
||||
- if the "-p" option is specified then the original NIM lpp_source resource will be copied to a new location and redfined to NIM. (The default would be to use the original lpp_source - to save file system space.)
|
||||
- if the "-p" option is specified then the original NIM lpp_source resource will be copied to a new location and redefined to NIM. (The default would be to use the original lpp_source - to save file system space.)
|
||||
|
||||
\ **Additional information**\
|
||||
|
||||
@ -85,7 +85,7 @@ To list a NIM resource definition use the AIX \ **lsnim**\ command ("lsnim -l <
|
||||
|
||||
To check the validity of a SPOT or lpp_source resource use the AIX \ **nim**\ command ("nim -o check <resourec-name>").
|
||||
|
||||
To remove specific NIM resource definitons use the AIX \ **nim**\ command. ("nim -o remove <resource-name>").
|
||||
To remove specific NIM resource definitions use the AIX \ **nim**\ command. ("nim -o remove <resource-name>").
|
||||
|
||||
|
||||
*******
|
||||
@ -255,7 +255,7 @@ OPTIONS
|
||||
|
||||
|
||||
|
||||
Note that you may specify multiple "script", "otherpkgs", and "installp_bundle" resources by using a comma seperated list. (ex. "script=ascript,bscript"). RPM names may be included in the "otherpkgs" list by using a "R:" prefix(ex. "R:whatever.rpm"). epkg (AIX interim fix package) file names may be included in the "otherpkgs" using the 'E:' prefix. (ex. "otherpkgs=E:IZ38930TL0.120304.epkg.Z").
|
||||
Note that you may specify multiple "script", "otherpkgs", and "installp_bundle" resources by using a comma separated list. (ex. "script=ascript,bscript"). RPM names may be included in the "otherpkgs" list by using a "R:" prefix(ex. "R:whatever.rpm"). epkg (AIX interim fix package) file names may be included in the "otherpkgs" using the 'E:' prefix. (ex. "otherpkgs=E:IZ38930TL0.120304.epkg.Z").
|
||||
|
||||
|
||||
|
||||
@ -267,7 +267,7 @@ OPTIONS
|
||||
|
||||
\ **-c|-**\ **-completeosimage**\
|
||||
|
||||
Complete the creation of the osimage definition passed in on the command line. This option will use any additonal values passed in on the command line and/or it will attempt to create required resources in order to complete the definition of the xCAT osimage. For example, if the osimage definition is missing a spot or shared_root resource the command will create those resources and add them to the osimage definition.
|
||||
Complete the creation of the osimage definition passed in on the command line. This option will use any additional values passed in on the command line and/or it will attempt to create required resources in order to complete the definition of the xCAT osimage. For example, if the osimage definition is missing a spot or shared_root resource the command will create those resources and add them to the osimage definition.
|
||||
|
||||
|
||||
|
||||
@ -492,7 +492,7 @@ The xCAT osimage definition created by this command will include the "otherpkgs"
|
||||
mknimimage -u 61dskls installp_bundle=bndres1,bndres2 installp_flags="-agcQX"
|
||||
|
||||
|
||||
Note that when "installp_bundle", "otherpkgs", or "synclists" values are specified with the "-u" option then the xCAT osimage definiton is not used or updated.
|
||||
Note that when "installp_bundle", "otherpkgs", or "synclists" values are specified with the "-u" option then the xCAT osimage definition is not used or updated.
|
||||
|
||||
13) Update an existing image to support NFSv4. Also specify verbose messages.
|
||||
|
||||
|
@ -148,7 +148,7 @@ OPTIONS
|
||||
|
||||
\ **vmcpus=**\ \ *value*\ \ **vmmemory=**\ \ *value*\ \ **vmphyslots=**\ \ *value*\ \ **vmothersetting=**\ \ *value*\ \ **vmnics=**\ \ *value*\ \ **vmstorage=**\ \ *value*\ [\ **-**\ **-vios**\ ]
|
||||
|
||||
To specify the parameters which are used to create a partition. The \ *vmcpus*\ , \ *vmmemory*\ are necessay, and the value specified with this command have a more high priority. If the value of any of the three options is not specified, the corresponding value specified for the node object will be used. If any of the three attributes is neither specified with this command nor specified with the node object, error information will be returned. To reference to lsvm(1)|lsvm.1 for more information about 'drc_index' for \ *vmphyslots*\ .
|
||||
To specify the parameters which are used to create a partition. The \ *vmcpus*\ , \ *vmmemory*\ are necessary, and the value specified with this command have a more high priority. If the value of any of the three options is not specified, the corresponding value specified for the node object will be used. If any of the three attributes is neither specified with this command nor specified with the node object, error information will be returned. To reference to lsvm(1)|lsvm.1 for more information about 'drc_index' for \ *vmphyslots*\ .
|
||||
|
||||
The option \ *vios*\ is used to specify the partition that will be created is a VIOS partition. If specified, the value for \ *vmstorage*\ shall be number which indicate the number of vSCSI server adapter will be created, and if no value specified for \ *vmphyslots*\ , all the physical slot of the power machine will be asigned to VIOS partition. If not specified, it shall be in form of \ *vios_name:server_slotid*\ to specify the vios and the virtual slot id of the vSCSI server adapter that will be connected from the Logical partition.
|
||||
|
||||
@ -392,7 +392,7 @@ First, define a node object:
|
||||
mkdef -t node -o lpar1 mgt=fsp cons=fsp nodetype=ppc,osi id=1 hcp=cec parent=cec hwtype=lpar groups=lpar,all
|
||||
|
||||
|
||||
Then, create the partion on the specified cec.
|
||||
Then, create the partition on the specified cec.
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
@ -515,7 +515,7 @@ The output is similar to:
|
||||
mkvm viosnode vmcpus=1/4/16 vmmemory=1G/4G/32G vmphyslots=0x21010201,0x21010200 vmnics=vlan1 vmstorage=5 --vios
|
||||
|
||||
|
||||
The resouces for the node is similar to:
|
||||
The resources for the node is similar to:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
@ -39,9 +39,9 @@ Parameters
|
||||
**********
|
||||
|
||||
|
||||
\ *name*\ is the name of the monitoring plug-in module. For example, if the the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used.
|
||||
\ *name*\ is the name of the monitoring plug-in module. For example, if the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used.
|
||||
|
||||
\ *settings*\ is the monitoring plug-in specific settings. It is used to customize the behavior of the plug-in or configure the 3rd party software. Format: \ *-s key-value -s key=value ...*\ Note that the square brackets are needed here. Use \ *monls name -d*\ command to look for the possbile setting keys for a plug-in module.
|
||||
\ *settings*\ is the monitoring plug-in specific settings. It is used to customize the behavior of the plug-in or configure the 3rd party software. Format: \ *-s key-value -s key=value ...*\ Note that the square brackets are needed here. Use \ *monls name -d*\ command to look for the possible setting keys for a plug-in module.
|
||||
|
||||
|
||||
*******
|
||||
|
@ -31,7 +31,7 @@ DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
This command is used to configure a 3rd party monitoring software to monitor the xCAT cluster. For example, it modifies the configration file for the monitoring software so that the nodes can be included in the monitoring domain. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified, though the configuration of the nodes is usually performed during the node deployment stage.
|
||||
This command is used to configure a 3rd party monitoring software to monitor the xCAT cluster. For example, it modifies the configuration file for the monitoring software so that the nodes can be included in the monitoring domain. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified, though the configuration of the nodes is usually performed during the node deployment stage.
|
||||
|
||||
|
||||
**********
|
||||
@ -39,7 +39,7 @@ Parameters
|
||||
**********
|
||||
|
||||
|
||||
\ *name*\ is the name of the monitoring plug-in module. For example, if the the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used.
|
||||
\ *name*\ is the name of the monitoring plug-in module. For example, if the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ *monls -a*\ command to list all the monitoring plug-in modules that can be used.
|
||||
|
||||
\ *noderange*\ specifies the nodes to be monitored. If omitted, all nodes will be monitored.
|
||||
|
||||
|
@ -31,7 +31,7 @@ DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
This command is used to deconfigure a 3rd party monitoring software from monitoring the xCAT cluster. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified. The deconfigration operation will remove the nodes from the 3rd party software's monitoring domain.
|
||||
This command is used to deconfigure a 3rd party monitoring software from monitoring the xCAT cluster. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the \ *-r*\ option is specified. The deconfiguration operation will remove the nodes from the 3rd party software's monitoring domain.
|
||||
|
||||
|
||||
**********
|
||||
|
@ -33,7 +33,7 @@ DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
This command is used to list the status, desctiption, the configuration scripts and the settings of one or all of the monitoring plug-in modules.
|
||||
This command is used to list the status, description, the configuration scripts and the settings of one or all of the monitoring plug-in modules.
|
||||
|
||||
|
||||
**********
|
||||
@ -49,9 +49,9 @@ OPTIONS
|
||||
*******
|
||||
|
||||
|
||||
\ **-a | -**\ **-all**\ Searches the \ *XCATROOT/lib/perl/xCAT_monitoring*\ directory and reports all the monitoring plug-in modules. If nothing is specified, the list is read from the \ *monitoring*\ tabel.
|
||||
\ **-a | -**\ **-all**\ Searches the \ *XCATROOT/lib/perl/xCAT_monitoring*\ directory and reports all the monitoring plug-in modules. If nothing is specified, the list is read from the \ *monitoring*\ table.
|
||||
|
||||
\ **-d | -**\ **-description**\ Display the description of the plug-in modules. The description ususally contains the possible settings.
|
||||
\ **-d | -**\ **-description**\ Display the description of the plug-in modules. The description usually contains the possible settings.
|
||||
|
||||
\ **-h | -**\ **-help**\ Display usage message.
|
||||
|
||||
@ -110,7 +110,7 @@ The output looks like this:
|
||||
nagiosmon not-monitored
|
||||
|
||||
|
||||
3. To list the status and the desciption for \ *snmpmon*\ module, enter:
|
||||
3. To list the status and the description for \ *snmpmon*\ module, enter:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
@ -59,7 +59,7 @@ OPTIONS
|
||||
|
||||
\ **-a**\ specifies a comma-separated list of attributes or metrics names. The default is all.
|
||||
|
||||
\ **-w**\ specify one or multiple selection string that can be used to select events. The operators ==, !=, =,!,>,<,>=,<= are available. Wildcards % and _ are supported in the pattern string. % allows you to match any string of any length(including zero length) and _ allows you to match on a single character. The valid attributes are eventtype, monitor, monnode, application, component, id, serverity, message, rawdata, comments. Valid severity are: Informational, Warning, Critical.
|
||||
\ **-w**\ specify one or multiple selection string that can be used to select events. The operators ==, !=, =,!,>,<,>=,<= are available. Wildcards % and _ are supported in the pattern string. % allows you to match any string of any length(including zero length) and _ allows you to match on a single character. The valid attributes are eventtype, monitor, monnode, application, component, id, severity, message, rawdata, comments. Valid severity are: Informational, Warning, Critical.
|
||||
|
||||
Operator descriptions:
|
||||
|
||||
|
@ -39,7 +39,7 @@ PARAMETERS
|
||||
**********
|
||||
|
||||
|
||||
\ *name*\ is the name of the monitoring plug-in module. For example, if the the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ **monls -a**\ command to list all the monitoring plug-in modules that can be used.
|
||||
\ *name*\ is the name of the monitoring plug-in module. For example, if the \ *name*\ is called \ *xxx*\ , then the actual file name that the xcatd looks for is \ */opt/xcat/lib/perl/xCAT_monitoring/xxx.pm*\ . Use \ **monls -a**\ command to list all the monitoring plug-in modules that can be used.
|
||||
|
||||
\ *noderange*\ is the nodes to be monitored. If omitted, all nodes will be monitored.
|
||||
|
||||
|
@ -57,9 +57,9 @@ To create a NIM installp_bundle definition you can use the "nim -o define" opera
|
||||
nim -o define -t installp_bundle -a server=master -a location=/install/nim/mypkgs.bnd mypackages
|
||||
|
||||
|
||||
See the AIX documantation for more information on using installp_bundle files.
|
||||
See the AIX documentation for more information on using installp_bundle files.
|
||||
|
||||
The xCAT nimnodecust command will automatically handle the distribution of the packages to AIX service nodes when using an xCAT hierachical environment.
|
||||
The xCAT nimnodecust command will automatically handle the distribution of the packages to AIX service nodes when using an xCAT hierarchical environment.
|
||||
|
||||
|
||||
*******
|
||||
|
@ -33,7 +33,7 @@ This xCAT command can be used to initialize AIX/NIM standalone machines. Once th
|
||||
|
||||
If you are using xCAT service nodes the \ **nimnodeset**\ command will automatically determine the correct server(s) for the node and do the initialization on that server(s).
|
||||
|
||||
The osimage_name is the name of an xCAT osimage definition that contains the list of NIM resources to use when initializing the nodes. If the osimage_name is not provided on the command line the code checks the node definition for the value of the "provmethod" attribute (which is the name of an osimage definition). If the osimage_image is provided on the command line then the code will also set the "provmethod" attribute of the node definiions.
|
||||
The osimage_name is the name of an xCAT osimage definition that contains the list of NIM resources to use when initializing the nodes. If the osimage_name is not provided on the command line the code checks the node definition for the value of the "provmethod" attribute (which is the name of an osimage definition). If the osimage_image is provided on the command line then the code will also set the "provmethod" attribute of the node definitions.
|
||||
|
||||
This command will also create a NIM resolv_conf resource to be used when installing the node. If a resolv_conf resource is not already included in the xCAT osimage definition and if the "domain" and "nameservers" values are set then a new
|
||||
NIM resolv_conf resource will be created and allocated to the nodes.
|
||||
@ -41,7 +41,7 @@ NIM resolv_conf resource will be created and allocated to the nodes.
|
||||
The "domain" and "nameservers" attributes can be set in either the xCAT "network" definition used by the nodes or in the xCAT cluster "site" definition. The setting in the "network" definition will take priority.
|
||||
|
||||
The "search" field of the resolv.conf file will contain a list all the domains
|
||||
listed in the xCAT network definitions and the xCAT site definiton.
|
||||
listed in the xCAT network definitions and the xCAT site definition.
|
||||
|
||||
The "nameservers" value can either be set to a specific IP address or the "<xcatmaster>" key word. The "<xcatmaster>" key word means that the value of the "xcatmaster" attribute of the node definition will be used in the /etc/resolv.conf file. (I.e. The name of the install server as known by the node.)
|
||||
|
||||
@ -58,13 +58,13 @@ will be created.
|
||||
|
||||
You can specify additional attributes and values using the "attr=val" command line option. This information will be passed on to the underlying call to the NIM "nim -o bos_inst" command. See the NIM documentation for information on valid command line options for the nim command. The "attr" must correspond to a NIM attribute supported for the NIM "bos_inst" operation. Information provided by the "attr=val" option will take precedence over the information provided in the osimage definition.
|
||||
|
||||
The force option can be used to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinititializing.
|
||||
The force option can be used to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinitializing.
|
||||
|
||||
This command will also create a NIM script resource to enable the xCAT support for user-provided customization scripts.
|
||||
|
||||
After the \ **nimnodeset**\ command completes you can use the \ **lsnim**\ command to check the NIM node definition to see if it is ready for booting the node. ("lsnim -l <nim_node_name>").
|
||||
|
||||
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **nimnodeset**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts dirctory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **nimnodeset**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **nimnodeset**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *standalone:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "standalone". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes.
|
||||
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the \ **nimnodeset**\ command. Such scripts are called \ **prescripts**\ . They should be copied to /install/prescripts directory. A table called \ *prescripts*\ is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the \ **nimnodeset**\ command are stored in the 'begin' column of \ *prescripts*\ table. The scripts to be run at the end of the \ **nimnodeset**\ command are stored in the 'end' column of \ *prescripts*\ table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: \ *standalone:myscript1,myscript2*\ . The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "standalone". If \ *#xCAT setting:MAX_INSTANCE=number*\ is specified in the script, the script will get invoked for each node in parallel, but no more than \ *number*\ of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes.
|
||||
|
||||
|
||||
*******
|
||||
@ -76,7 +76,7 @@ OPTIONS
|
||||
\ *attr=val [attr=val ...]*\
|
||||
|
||||
Specifies one or more "attribute equals value" pairs, separated by spaces. Attr=
|
||||
val pairs must be specified last on the command line. These are used to specify additional values that can be passed to the underlying NIM commands, ("nim -o bos_inst ..."). See the NIM documentation for valid "nim" command line options. Note that you may specify multiple "script" and "installp_bundle" values by using a comma seperated list. (ex. "script=ascript,bscript").
|
||||
val pairs must be specified last on the command line. These are used to specify additional values that can be passed to the underlying NIM commands, ("nim -o bos_inst ..."). See the NIM documentation for valid "nim" command line options. Note that you may specify multiple "script" and "installp_bundle" values by using a comma separated list. (ex. "script=ascript,bscript").
|
||||
|
||||
|
||||
|
||||
@ -106,8 +106,7 @@ OPTIONS
|
||||
|
||||
\ **-l|-**\ **-location**\
|
||||
|
||||
The directory location to use when creating new NIM resolv_conf resources. The d
|
||||
efault location is /install/nim.
|
||||
The directory location to use when creating new NIM resolv_conf resources. The default location is /install/nim.
|
||||
|
||||
|
||||
|
||||
|
@ -61,7 +61,7 @@ RETURN VALUE
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured.
|
||||
1 An error has occurred.
|
||||
|
||||
|
||||
********
|
||||
|
@ -63,7 +63,7 @@ RETURN VALUE
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured.
|
||||
1 An error has occurred.
|
||||
|
||||
|
||||
********
|
||||
|
@ -79,7 +79,7 @@ RETURN VALUE
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured.
|
||||
1 An error has occurred.
|
||||
|
||||
|
||||
********
|
||||
|
@ -114,7 +114,7 @@ RETURN VALUE
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured.
|
||||
1 An error has occurred.
|
||||
|
||||
|
||||
********
|
||||
|
@ -59,7 +59,7 @@ When the nodes are discovered, PCM updates the affected configuration files on t
|
||||
|
||||
When you power on the nodes, they PXE boot and DHCP/TFTP/HTTP on the management node give each node the xCAT genesis boot image,
|
||||
which inventories the node hardware and sends data to the management node. There, either the sequential discovery process or the
|
||||
profile discovery process assigns node attributes and defines the node in the the database.
|
||||
profile discovery process assigns node attributes and defines the node in the database.
|
||||
|
||||
|
||||
*******
|
||||
@ -127,7 +127,7 @@ OPTIONS
|
||||
|
||||
|
||||
|
||||
\ **chasiss=**\ \ *chassis-name*\
|
||||
\ **chassis=**\ \ *chassis-name*\
|
||||
|
||||
Sets the chassis name that the Blade server or PureFlex blade is located in, for either the Sequential Discovery or Profile Discovery methods. This option is used for the Blade server and PureFlex system only. You cannot specify this option with the rack option.
|
||||
|
||||
@ -196,7 +196,7 @@ RETURN VALUE
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured.
|
||||
1 An error has occurred.
|
||||
|
||||
|
||||
********
|
||||
|
@ -52,7 +52,7 @@ RETURN VALUE
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured.
|
||||
1 An error has occurred.
|
||||
|
||||
|
||||
********
|
||||
|
@ -53,7 +53,7 @@ RETURN VALUE
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured.
|
||||
1 An error has occurred.
|
||||
|
||||
|
||||
********
|
||||
|
@ -29,7 +29,7 @@ DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
The \ **nodeimport**\ command creates nodes by importing a hostinfo file which is following stanza format. In this hostinfo file, we can define node's hostname, ip, mac, switch name, switch port and host location infomation like rack, chassis, start unit, server height...etc
|
||||
The \ **nodeimport**\ command creates nodes by importing a hostinfo file which is following stanza format. In this hostinfo file, we can define node's hostname, ip, mac, switch name, switch port and host location information like rack, chassis, start unit, server height...etc
|
||||
|
||||
After nodes imported, the configuration files related with these nodes will be updated automatically. For example: /etc/hosts, dns configuration, dhcp configuration. And the kits node plugins will also be triggered automatically to update kit related configuration/services.
|
||||
|
||||
@ -83,9 +83,9 @@ RETURN VALUE
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured while validating parameters.
|
||||
1 An error has occurred while validating parameters.
|
||||
|
||||
2 An error has occured while parsing hostinfo file.
|
||||
2 An error has occurred while parsing hostinfo file.
|
||||
|
||||
|
||||
********
|
||||
@ -143,7 +143,7 @@ To import nodes using a profile, follow the following steps:
|
||||
|
||||
# hostinfo end.
|
||||
|
||||
Another example of a node infomation file, a PureFlex X/P node defined:
|
||||
Another example of a node information file, a PureFlex X/P node defined:
|
||||
# hostinfo begin
|
||||
# To define a PureFlex P/X node, chassis and slot id must be specified.
|
||||
# The chassis must be a PureFlex chassis.
|
||||
@ -191,7 +191,7 @@ Description: The name of the node, where __hostname__ is automatically generated
|
||||
|
||||
\ **mac=<mac-address**\ > This is a mandatory item.
|
||||
|
||||
Description: Specify the MAC address for the NIC used by the provisionging node, where <mac-address> is the NICs MAC address.
|
||||
Description: Specify the MAC address for the NIC used by the provisioning node, where <mac-address> is the NICs MAC address.
|
||||
|
||||
\ **switches=<nic-name!switch-name!switch-port**\ > This is a mandatory item, when define switch, switchport and node nic name relationship.
|
||||
|
||||
@ -221,9 +221,9 @@ Description: Lists the IP address for each network interface configuration (NIC)
|
||||
|
||||
Description: node location info. Specify the rack name which this node will be placed into. If not specify this item, there will be no node location info set for this node. this item must be specified together with height + unit.
|
||||
|
||||
\ **chasiss=<chassis-name**\ > This is an optional item.
|
||||
\ **chassis=<chassis-name**\ > This is an optional item.
|
||||
|
||||
Description: node location info, for blade(or PureFlex) only. Specify the chasiss name which this blade will be placed into. this item can not be specified together with rack.
|
||||
Description: node location info, for blade(or PureFlex) only. Specify the chassis name which this blade will be placed into. this item can not be specified together with rack.
|
||||
|
||||
\ **height=<chassis-height**\ > This is an optional item.
|
||||
|
||||
|
@ -109,7 +109,7 @@ OPTIONS
|
||||
|
||||
\ **-b|-**\ **-blame**\
|
||||
|
||||
For values inherited from groups, display which groups provided the inheritence
|
||||
For values inherited from groups, display which groups provided the inheritance
|
||||
|
||||
|
||||
|
||||
|
@ -59,7 +59,7 @@ RETURN VALUE
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured.
|
||||
1 An error has occurred.
|
||||
|
||||
|
||||
********
|
||||
|
@ -57,7 +57,7 @@ RETURN VALUE
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured.
|
||||
1 An error has occurred.
|
||||
|
||||
|
||||
********
|
||||
|
@ -63,7 +63,7 @@ Keywords to use:
|
||||
port -- the application daemon port number, if not specified, use internal list, then /etc/services.
|
||||
group -- the name of a node group that needs to get the application status from. If not specified, assume all the nodes in the nodelist table. To specify more than one groups, use group=a,group=b format.
|
||||
cmd -- the command that will be run locally on mn or sn.
|
||||
lcmd -- the command that will be run the the mn only.
|
||||
lcmd -- the command that will be run the mn only.
|
||||
dcmd -- the command that will be run distributed on the nodes using xdsh <nodes> ....
|
||||
|
||||
|
||||
@ -94,7 +94,7 @@ For the command specified by 'dcmd', no input is needed, the output can be a str
|
||||
|
||||
\ **-m | -**\ **-usemon**\
|
||||
|
||||
Uses the settings from the \ **monsetting**\ talbe to determine a list of applications that need to get status for.
|
||||
Uses the settings from the \ **monsetting**\ table to determine a list of applications that need to get status for.
|
||||
|
||||
|
||||
|
||||
|
@ -0,0 +1,23 @@
|
||||
|
||||
#########
|
||||
piflash.1
|
||||
#########
|
||||
|
||||
.. highlight:: perl
|
||||
|
||||
|
||||
********
|
||||
SYNOPSIS
|
||||
********
|
||||
|
||||
|
||||
\ **piflash**\ <noderange> -**\ **-package <filename>
|
||||
|
||||
|
||||
***********
|
||||
DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
\ **piflash**\ Remotely applies firmware updates to servers.
|
||||
|
@ -73,7 +73,7 @@ PPC (with HMC) specific:
|
||||
========================
|
||||
|
||||
|
||||
The \ **rflash**\ command uses the \ **xdsh**\ command to connect to the HMC controlling the given managed system and perform the updates. Before running \ **rflash**\ , use \ **rspconfig**\ to check if the related HMC ssh is enabled. To enable a HMC ssh connection, use \ **rspconfig**\ comamnd.
|
||||
The \ **rflash**\ command uses the \ **xdsh**\ command to connect to the HMC controlling the given managed system and perform the updates. Before running \ **rflash**\ , use \ **rspconfig**\ to check if the related HMC ssh is enabled. To enable a HMC ssh connection, use \ **rspconfig**\ command.
|
||||
|
||||
\ **Warning!**\ This command may take considerable time to complete, depending on the number of systems being updated and the workload on the target HMC. In particular, power subsystem updates may take an hour or more if there are many attached managed systems.
|
||||
|
||||
@ -83,7 +83,7 @@ The flash chip of a POWER5 and POWER6 managed system or power subsystem stores f
|
||||
|
||||
The \ **-**\ **-commit**\ flag is used to write the contents of the temporary side of the flash to the permanent side. This flag should be used after updating code and verifying correct system operation. The \ **-**\ **-recover**\ flag is used to write the permanent side of the flash chip back to the temporary side. This flag should be used to recover from a corrupt flash operation, so that the previously running code can be restored.
|
||||
|
||||
\ **NOTE:**\ When the \ **-**\ **-commit**\ or \ **-**\ **-recover**\ two flags is used, the noderange \ **cannot**\ be BPA. It only \ **can**\ be CEC or LPAR ,and will take effect for \ **both**\ managed systems and power subsystems.
|
||||
\ **NOTE:**\ When the \ **-**\ **-commit**\ or \ **-**\ **-recover**\ two flags is used, the noderange \ **cannot**\ be BPA. It only \ **can**\ be CEC or LPAR, and will take effect for \ **both**\ managed systems and power subsystems.
|
||||
|
||||
xCAT recommends that you shutdown your Operating System images and power off your managed systems before applying disruptive updates to managed systems or power subsystems.
|
||||
|
||||
@ -104,7 +104,7 @@ The \ **deferred**\ option will load the new firmware into the T (temp) side, b
|
||||
|
||||
In Direct FSP/BPA Management, there is \ **-d**\ \ *data_directory*\ option. The default value is /tmp. When doing firmware update, \ **rflash**\ will put some related data from rpm packages in <data_directory> directory, so the execution of \ **rflash**\ will require available disk space in <data_directory> for the command to properly execute:
|
||||
|
||||
For one GFW rpm package and one power code rpm package , if the GFW rpm package size is gfw_rpmsize, and the Power code rpm package size is power_rpmsize, it requires that the available disk space should be more than: 1.5\*gfw_rpmsize + 1.5\*power_rpmsize
|
||||
For one GFW rpm package and one power code rpm package, if the GFW rpm package size is gfw_rpmsize, and the Power code rpm package size is power_rpmsize, it requires that the available disk space should be more than: 1.5\*gfw_rpmsize + 1.5\*power_rpmsize
|
||||
|
||||
For Power 775, the \ **rflash**\ command takes effect on the primary and secondary FSPs or BPAs almost in parallel.
|
||||
|
||||
@ -115,7 +115,7 @@ NeXtScale FPC specific:
|
||||
=======================
|
||||
|
||||
|
||||
The command will update firmware for NeXtScale FPC when given an FPC node and the http information needed to access the firmware. The http imformation required includes both the MN IP address as well as the directory containing the firmware. It is recommended that the firmware be downloaded and placed in the /install directory structure as the xCAT MN /install directory is configured with the correct permissions for http. Refer to the doc to get more details: XCAT_NeXtScale_Clusters
|
||||
The command will update firmware for NeXtScale FPC when given an FPC node and the http information needed to access the firmware. The http information required includes both the MN IP address as well as the directory containing the firmware. It is recommended that the firmware be downloaded and placed in the /install directory structure as the xCAT MN /install directory is configured with the correct permissions for http. Refer to the doc to get more details: XCAT_NeXtScale_Clusters
|
||||
|
||||
|
||||
OpenPOWER specific:
|
||||
@ -140,7 +140,7 @@ The command will update firmware for OpenPOWER BMC when given an OpenPOWER node
|
||||
|
||||
\ **-c|-**\ **-check**\
|
||||
|
||||
Chech the firmware version of BMC and HPM file.
|
||||
Check the firmware version of BMC and HPM file.
|
||||
|
||||
|
||||
|
||||
@ -209,7 +209,7 @@ The command will update firmware for OpenPOWER BMC when given an OpenPOWER node
|
||||
|
||||
|
||||
|
||||
1. To update only the power subsystem attached to a single HMC-attached pSeries CEC(cec_name), and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter:
|
||||
1. To update only the power subsystem attached to a single HMC-attached pSeries CEC(cec_name), and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
@ -219,7 +219,7 @@ The command will update firmware for OpenPOWER BMC when given an OpenPOWER node
|
||||
|
||||
|
||||
|
||||
2. To update only the power subsystem attached to a single HMC-attached pSeries node, and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter:
|
||||
2. To update only the power subsystem attached to a single HMC-attached pSeries node, and recycle the power subsystem and all attached managed systems when the update is complete, and the Microcode update package and associated XML file are in /tmp/fw, enter:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
@ -239,7 +239,7 @@ The command will update firmware for OpenPOWER BMC when given an OpenPOWER node
|
||||
|
||||
|
||||
|
||||
4. To update the firmware on a NeXtScale FPC specify the FPC node name and the HTTP location of the file including the xCAT MN IP address and the directory on the xCAT MN containing the firmware as follows:
|
||||
4. To update the firmware on a NeXtScale FPC specify the FPC node name and the HTTP location of the file including the xCAT MN IP address and the directory on the xCAT MN containing the firmware as follows:
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
@ -114,10 +114,10 @@ zVM specific:
|
||||
*******************
|
||||
|
||||
|
||||
\ **rinv**\ retrieves hardware configuration information from the on-board
|
||||
\ **rinv**\ retrieves hardware configuration information from the on-board
|
||||
Service Processor for a single or range of nodes and groups.
|
||||
|
||||
Calling \ **rinv**\ for VMware will display the UUID/GUID, nuumber of CPUs, amount of memory, the MAC address and a list of Hard disks. The output for each Hard disk includes the label, size and backing file location.
|
||||
Calling \ **rinv**\ for VMware will display the UUID/GUID, number of CPUs, amount of memory, the MAC address and a list of Hard disks. The output for each Hard disk includes the label, size and backing file location.
|
||||
|
||||
|
||||
***************
|
||||
@ -140,7 +140,7 @@ Calling \ **rinv**\ for VMware will display the UUID/GUID, nuumber of CPUs, amo
|
||||
|
||||
\ **config**\
|
||||
|
||||
Retrieves number of processors, speed, total memory, and DIMM
|
||||
Retrieves number of processors, speed, total memory, and DIMM
|
||||
locations.
|
||||
|
||||
|
||||
|
@ -48,7 +48,7 @@ EXAMPLES
|
||||
.. code-block:: perl
|
||||
|
||||
rmdocker host01c01
|
||||
host01c01: Disconnect customzied network 'mynet0' done
|
||||
host01c01: Disconnect customized network 'mynet0' done
|
||||
host01c01: success
|
||||
|
||||
|
||||
|
@ -39,11 +39,11 @@ If the node you are trying to remove is currently running the \ **rmdsklsnode**\
|
||||
|
||||
\ **Removing alternate NIM client definitions**\
|
||||
|
||||
If you used the "-n" option when you created the NIM client definitions with the \ **mkdsklsnode**\ command then the NIM client machine names would be a combination of the xCAT node name and the osimage name used to initialize the NIM machine. To remove these definitions you must provide the name of the osimage that was used using the "-i" option.
|
||||
If you used the "-n" option when you created the NIM client definitions with the \ **mkdsklsnode**\ command then the NIM client machine names would be a combination of the xCAT node name and the osimage name used to initialize the NIM machine. To remove these definitions, you must provide the name of the osimage that was used using the "-i" option.
|
||||
|
||||
In most cases you would most likely want to remove the old client definitions without disturbing the nodes that you just booted with the new alternate client definition. The \ **rmdsklsnode -r**\ option can be used to remove the old alternate client defintions without stopping the running node.
|
||||
In most cases you would most likely want to remove the old client definitions without disturbing the nodes that you just booted with the new alternate client definition. The \ **rmdsklsnode -r**\ option can be used to remove the old alternate client definitions without stopping the running node.
|
||||
|
||||
However, if you have NIM dump resources assign to your nodes be aware that when the old NIM alternate client definitions are removed it will leave the nodes unable to produce a system dump. This is a current limitation in the NIM support for alternate client definitions. For this reason it is recommended that you wait to do this cleanup until right before you do your next upgrade.
|
||||
However, if you have NIM dump resources assign to your nodes be aware that when the old NIM alternate client definitions are removed it will leave the nodes unable to produce a system dump. This is a current limitation in the NIM support for alternate client definitions. For this reason, it is recommended that you wait to do this cleanup until right before you do your next upgrade.
|
||||
|
||||
|
||||
*******
|
||||
@ -60,8 +60,7 @@ OPTIONS
|
||||
|
||||
\ **-b |-**\ **-backupSN**\
|
||||
|
||||
When using backup service nodes only update the backup. The default is to updat
|
||||
e both the primary and backup service nodes.
|
||||
When using backup service nodes only update the backup. The default is to update both the primary and backup service nodes.
|
||||
|
||||
|
||||
|
||||
@ -85,8 +84,7 @@ OPTIONS
|
||||
|
||||
\ **-p|-**\ **-primarySN**\
|
||||
|
||||
When using backup service nodes only update the primary. The default is to upda
|
||||
te both the primary and backup service nodes.
|
||||
When using backup service nodes only update the primary. The default is to update both the primary and backup service nodes.
|
||||
|
||||
|
||||
|
||||
|
@ -52,7 +52,7 @@ DESCRIPTION
|
||||
|
||||
For PPC (with HMC) specific:
|
||||
|
||||
This command is used to disconnect CEC and Frame nodes from HMC nodes, according to the connection information defined in ppc talbe in xCAT DB.
|
||||
This command is used to disconnect CEC and Frame nodes from HMC nodes, according to the connection information defined in ppc table in xCAT DB.
|
||||
|
||||
Note: If a CEC belongs to a frame with a BPA installed, this CEC cannot be disconnected individually. Instead, the whole frame should be disconnected.
|
||||
|
||||
|
@ -88,7 +88,7 @@ zVM specific:
|
||||
|
||||
|
||||
\ **vm**\ table -
|
||||
Table governing VM paramaters. See vm(5)|vm.5 for further details.
|
||||
Table governing VM parameters. See vm(5)|vm.5 for further details.
|
||||
This is used to determine the current host to migrate from.
|
||||
|
||||
|
||||
|
@ -29,7 +29,7 @@ DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
The \ **rmkitcomp**\ command removes kit components from an xCAT osimage. All the kit component attribute values that are contained in the osimage will be removed, and the kit comoponent meta rpm and package rpm could be uninstalled by \ **-u|-**\ **-uninstall**\ option.
|
||||
The \ **rmkitcomp**\ command removes kit components from an xCAT osimage. All the kit component attribute values that are contained in the osimage will be removed, and the kit component meta rpm and package rpm could be uninstalled by \ **-u|-**\ **-uninstall**\ option.
|
||||
|
||||
Note: The xCAT support for Kits is only available for Linux operating systems.
|
||||
|
||||
|
@ -65,7 +65,7 @@ OPTIONS
|
||||
|
||||
\ **-**\ **-service**\ Remove the service partitions of the specified CECs.
|
||||
|
||||
\ **-p**\ KVM: Purge the existence of the VM from persistant storage. This will erase all storage related to the VM in addition to removing it from the active virtualization configuration. PPC: Remove the specified partiton on normal power machine.
|
||||
\ **-p**\ KVM: Purge the existence of the VM from persistent storage. This will erase all storage related to the VM in addition to removing it from the active virtualization configuration. PPC: Remove the specified partition on normal power machine.
|
||||
|
||||
\ **-f**\ Force remove the VM, even if the VM appears to be online. This will bring down a live VM if requested.
|
||||
|
||||
|
@ -66,11 +66,11 @@ Note: if the "val" fields includes spaces or any other characters that will be p
|
||||
|
||||
\ **-r**\
|
||||
|
||||
specify the number of retries that the monitoring process will perform before declare the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag.
|
||||
specify the number of retries that the monitoring process will perform before declaring the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag.
|
||||
|
||||
\ **-t**\
|
||||
|
||||
Specify the the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified.
|
||||
Specify the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified.
|
||||
|
||||
\ **-V|-**\ **-verbose**\
|
||||
|
||||
|
@ -181,7 +181,7 @@ OPTIONS
|
||||
|
||||
\ **resetsp**\
|
||||
|
||||
Reboot the service processor. If there are primary and secondary FSPs/BPAs of one cec/frame, it will reboot them almost at the sametime.
|
||||
Reboot the service processor. If there are primary and secondary FSPs/BPAs of one cec/frame, it will reboot them almost at the same time.
|
||||
|
||||
|
||||
|
||||
@ -320,13 +320,13 @@ OPTIONS
|
||||
|
||||
\ **-r**\ \ *retrycount*\
|
||||
|
||||
specify the number of retries that the monitoring process will perform before declare the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag.
|
||||
specify the number of retries that the monitoring process will perform before declaring the failure. The default value is 3. Setting the retrycount to 0 means only monitoring the os installation progress and will not re-initiate the installation if the node status has not been changed to the expected value after timeout. This flag must be used with -m flag.
|
||||
|
||||
|
||||
|
||||
\ **-t**\ \ *timeout*\
|
||||
|
||||
Specify the the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified.
|
||||
Specify the timeout, in minutes, to wait for the expectedstatus specified by -m flag. This is a required flag if the -m flag is specified.
|
||||
|
||||
Power off, then on.
|
||||
|
||||
|
@ -564,7 +564,7 @@ OPTIONS
|
||||
|
||||
\ **USERID**\ ={\ *newpasswd*\ } \ **updateBMC**\ ={\ **y|n**\ }
|
||||
|
||||
Change the password of the userid \ **USERID**\ for CMM in Flex system cluster. The option \ *updateBMC*\ can be used to specify whether updating the password of BMCs that connected to the speified CMM. The value is 'y' by default which means whenever updating the password of CMM, the password of BMCs will be also updated. Note that there will be several seconds needed before this command complete.
|
||||
Change the password of the userid \ **USERID**\ for CMM in Flex system cluster. The option \ *updateBMC*\ can be used to specify whether updating the password of BMCs that connected to the specified CMM. The value is 'y' by default which means whenever updating the password of CMM, the password of BMCs will be also updated. Note that there will be several seconds needed before this command complete.
|
||||
|
||||
If value "\*" is specified for USERID and the object node is \ *Flex System X node*\ , the password used to access the BMC of the System X node through IPMI will be updated as the same password of the userid \ **USERID**\ of the CMM in the same cluster.
|
||||
|
||||
|
@ -116,7 +116,7 @@ Command Protocol can be used. See man \ **xdsh**\ for more details.
|
||||
then a new template will be created from the node output.
|
||||
This will result in having all nodes that match a given template reported in
|
||||
their group at the end of the run in the output file.
|
||||
If no template count is specified, 0 is the default, and all nodes will
|
||||
If no template count is specified, 0 is the default, and all nodes will
|
||||
be compared against the first template.
|
||||
|
||||
|
||||
@ -127,7 +127,7 @@ Command Protocol can be used. See man \ **xdsh**\ for more details.
|
||||
that is stored in template path. You can use this parameter instead of running
|
||||
the command yourself to build the template.
|
||||
|
||||
\ **Note:**\ If the template path file does not exists, and no seed node is
|
||||
\ **Note:**\ If the template path file does not exist, and no seed node is
|
||||
supplied, the seed node automatically is one node in the
|
||||
noderange.
|
||||
|
||||
@ -152,7 +152,7 @@ Command Protocol can be used. See man \ **xdsh**\ for more details.
|
||||
there can exist more lines in the xdsh return from the nodes.
|
||||
|
||||
For example, if running a "rpm -qa | grep xCAT" command, without exactmatch
|
||||
set, if the node containes more xCAT rpms that listed in the template,
|
||||
set, if the node contains more xCAT rpms that listed in the template,
|
||||
it would be considered a match, as long as all rpms listed in the template
|
||||
were on the node. With exactmatch set, the output must be identical
|
||||
to the template.
|
||||
@ -165,7 +165,7 @@ Command Protocol can be used. See man \ **xdsh**\ for more details.
|
||||
of relevant device configuration file. The devicetype value must
|
||||
correspond to a valid device configuration file.
|
||||
xCAT ships some default configuration files
|
||||
for Ethernet switches and and IB switches under
|
||||
for Ethernet switches and IB switches under
|
||||
\ */opt/xcat/share/xcat/devicetype*\ directory. If you want to overwrite
|
||||
any of the configuration files, copy them to \ */var/opt/xcat/*\
|
||||
directory and cutomize.
|
||||
|
@ -59,7 +59,7 @@ node is second. The \ **xcatmaster**\ attribute must be set to the
|
||||
hostname of the primary service node as it is known by the node.
|
||||
|
||||
When the \ **snmove**\ command is run it modifies the xCAT database to
|
||||
switch the the primary server to the backup server.
|
||||
switch the primary server to the backup server.
|
||||
|
||||
It will also check the other services that are being used for the
|
||||
node (tftpserver, monserver, nfsserver, conserver), and if they were set
|
||||
@ -114,13 +114,13 @@ OPTIONS
|
||||
|
||||
\ **-l|-**\ **-liteonly**\
|
||||
|
||||
Use this option to ONLY synchronize any AIX statelite files from the primary server to the backup server for the nodes. It will not do the actual moving of thre nodes the the backup servers.
|
||||
Use this option to ONLY synchronize any AIX statelite files from the primary server to the backup server for the nodes. It will not do the actual moving of the nodes to the backup servers.
|
||||
|
||||
|
||||
|
||||
\ **-P|-**\ **-postscripts**\
|
||||
|
||||
Specifies a list of extra postscripts to be run on the nodes after the nodes are moved over to the new serive node. If \ **all**\ is specified, all the postscripts defined in the postscripts table will be run for the nodes. The specified postscripts must be stored under /install/postscripts directory.
|
||||
Specifies a list of extra postscripts to be run on the nodes after the nodes are moved over to the new service node. If \ **all**\ is specified, all the postscripts defined in the postscripts table will be run for the nodes. The specified postscripts must be stored under /install/postscripts directory.
|
||||
|
||||
|
||||
|
||||
|
@ -44,7 +44,7 @@ The \ **swapnodes**\ command shouldn't make the decision of which 2 nodes are s
|
||||
|
||||
After running \ **swapnodes**\ command, the order of the I/O devices may be changed after IO re-assignment, so the administrator needs to run \ **rbootseq**\ to set the boot string for the current_node. And then boot the node with the same image and same postscripts because they have the same attributes.
|
||||
|
||||
Without \ **-o**\ option, it's used to swap the location info in the db between 2 nodes. With \ **-o**\ option, it's used to move the \ *current_node*\ definition to \ *fip_node*\ (the 2nd octant), not move the \ *fip_node*\ definition to the 1st octant. If the two nodes are in a cec, it will assign the IO adapters that were assigned to the defective node to the available node. Originally, the \ *current_node*\ is a defective non-compute node, and \ *fip_node*\ is a avaible compute node. After the swapping, the \ *current_node*\ will be a available node.
|
||||
Without \ **-o**\ option, it's used to swap the location info in the db between 2 nodes. With \ **-o**\ option, it's used to move the \ *current_node*\ definition to \ *fip_node*\ (the 2nd octant), not move the \ *fip_node*\ definition to the 1st octant. If the two nodes are in a cec, it will assign the IO adapters that were assigned to the defective node to the available node. Originally, the \ *current_node*\ is a defective non-compute node, and \ *fip_node*\ is a available compute node. After the swapping, the \ *current_node*\ will be a available node.
|
||||
|
||||
|
||||
*******
|
||||
@ -94,7 +94,7 @@ EXAMPLES
|
||||
|
||||
|
||||
|
||||
1. To swap the service node attributes and IO assignments between sn1 and compute2 which are in the same cec, all the attributes in the ppc table and nodepos talbe of the two node will be swapped, and the the I/O adapters from the defective node (the original sn1) will be assigned to the available node (the original compute2). After the swapping, the sn1 will use the compute2's hardware resource and the I/O adapters from the original sn1.
|
||||
1. To swap the service node attributes and IO assignments between sn1 and compute2 which are in the same cec, all the attributes in the ppc table and nodepos table of the two node will be swapped, and the I/O adapters from the defective node (the original sn1) will be assigned to the available node (the original compute2). After the swapping, the sn1 will use the compute2's hardware resource and the I/O adapters from the original sn1.
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
@ -104,7 +104,7 @@ EXAMPLES
|
||||
|
||||
|
||||
|
||||
2. To swap the service node attributes and IO assignments between sn1 and compute2 which are NOT in the same cec, all the attributes in the ppc table and nodepos talbe of the two node will be swapped. After the swapping, the sn1 will use the compute2's hardware resource.
|
||||
2. To swap the service node attributes and IO assignments between sn1 and compute2 which are NOT in the same cec, all the attributes in the ppc table and nodepos table of the two node will be swapped. After the swapping, the sn1 will use the compute2's hardware resource.
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
@ -23,13 +23,13 @@ DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
The switchdiscover command scans the subnets and discovers all the swithches on the subnets. The command takes a list of subnets as input. The default subnets are the ones that the xCAT management node is on. It uses nmap command as default to discover the switches. However, you can specify other discovery methods such as lldp or snmp with \ **-s**\ flag. You can write the discovered switches into xCAT database with \ **-w**\ flag. This command supports may output formats such as xml(\ **-x**\ ), raw(\ **-r**\ ) and stanza(\ **-z**\ ) in addition to the default format.
|
||||
The switchdiscover command scans the subnets and discovers all the switches on the subnets. The command takes a list of subnets as input. The default subnets are the ones that the xCAT management node is on. It uses nmap command as default to discover the switches. However, you can specify other discovery methods such as lldp or snmp with \ **-s**\ flag. You can write the discovered switches into xCAT database with \ **-w**\ flag. This command supports may output formats such as xml(\ **-x**\ ), raw(\ **-r**\ ) and stanza(\ **-z**\ ) in addition to the default format.
|
||||
|
||||
\ **-**\ **-setup**\ flag is for switch-based switch discovery. It will find all the discovered switches on the subnets, then match them with predefined switches in the xCATDB. Next, it will set discovered switches with static ip address and hostname based on the predefined switch. It will also enable snmpv3 configuration. The details of the process are defined in the http://xcat-docs.readthedocs.io/en/latest/advanced/networks/switchdiscover/switches_discovery.html.
|
||||
|
||||
To view all the switches defined in the xCAT databasee use \ **lsdef -w "nodetype=switch"**\ command.
|
||||
To view all the switches defined in the xCAT database use \ **lsdef -w "nodetype=switch"**\ command.
|
||||
|
||||
For lldp method, make sure that lldpd package is installed and lldpd is running on the xCAT management node. lldpd comes from xcat-dep packge or you can get it from http://vincentbernat.github.io/lldpd/installation.html.
|
||||
For lldp method, make sure that lldpd package is installed and lldpd is running on the xCAT management node. lldpd comes from xcat-dep package or you can get it from http://vincentbernat.github.io/lldpd/installation.html.
|
||||
|
||||
For snmp method, make sure that snmpwalk command is installed and snmp is enabled for switches. To install snmpwalk, "yum install net-snmp-utils" for redhat and sles, "apt-get install snmp" for Ubuntu.
|
||||
|
||||
@ -102,13 +102,13 @@ OPTIONS
|
||||
|
||||
\ **-x**\
|
||||
|
||||
XML formated output.
|
||||
XML formatted output.
|
||||
|
||||
|
||||
|
||||
\ **-z**\
|
||||
|
||||
Stanza formated output.
|
||||
Stanza formatted output.
|
||||
|
||||
|
||||
|
||||
|
@ -325,7 +325,7 @@ PARAMETERS
|
||||
The scripts must be executable and copied
|
||||
to the /install/postscripts directory.
|
||||
Each script can take zero or more parameters.
|
||||
If parameters are spcified, the whole list needs to be quoted by double quotes.
|
||||
If parameters are specified, the whole list needs to be quoted by double quotes.
|
||||
For example:
|
||||
|
||||
|
||||
@ -341,7 +341,7 @@ PARAMETERS
|
||||
Specifies one or more "attribute equals value" pairs, separated by spaces.
|
||||
Attr=val pairs must be specified last on the command line. The currently
|
||||
supported attributes are: "installp_bundle", "otherpkgs", "installp_flags",
|
||||
"emgr_flags" and "rpm_flags". These attribute are only valid for AIX software
|
||||
"emgr_flags" and "rpm_flags". These attributes are only valid for AIX software
|
||||
maintenance support.
|
||||
|
||||
|
||||
@ -355,9 +355,7 @@ OPTIONS
|
||||
|
||||
\ **-**\ **-fanout**\ =\ *fanout_value*\
|
||||
|
||||
Specifies a fanout value for the maximum number of concur-
|
||||
rently executing remote shell processes. Serial execution
|
||||
can be specified by indicating a fanout value of \ **1**\ . If \ **-**\ **-fanout**\ is not specified, a default fanout value of \ **64**\ is used.
|
||||
Specifies a fanout value for the maximum number of concurrently executing remote shell processes. Serial execution can be specified by indicating a fanout value of \ **1**\ . If \ **-**\ **-fanout**\ is not specified, a default fanout value of \ **64**\ is used.
|
||||
|
||||
|
||||
|
||||
@ -441,7 +439,7 @@ OPTIONS
|
||||
AIX and Linux and updating software (-S) for Linux only.
|
||||
The non-root userid must be previously defined as an xCAT user.
|
||||
The userid sudo setup will have to be done by the admin on the node.
|
||||
This is not supported in a hiearchical cluster, that is the node is serviced by a service node.
|
||||
This is not supported in a hierarchical cluster, that is the node is serviced by a service node.
|
||||
See the document Granting_Users_xCAT_privileges for required xcat/sudo setup.
|
||||
|
||||
|
||||
|
@ -153,7 +153,7 @@ EXAMPLES
|
||||
xcat2nim -l -t node clstrn02
|
||||
|
||||
|
||||
7. To re-create a NIM machine definiton and display verbose output.
|
||||
7. To re-create a NIM machine definition and display verbose output.
|
||||
|
||||
|
||||
.. code-block:: perl
|
||||
|
@ -33,7 +33,7 @@ If xCAT looks suitable for your requirement, following steps are recommended pro
|
||||
|
||||
Now you have the node definition. Verify the hardware control for defined nodes is working. e.g. ``rpower <node> stat``.
|
||||
|
||||
Refer to the doc: :doc:`Hardware Management </guides/admin-guides/manage_clusters/ppc64le/management>` to learn how to perform the remote hardware control.
|
||||
Refer to the doc: :doc:`Hardware Management <../guides/admin-guides/manage_clusters/ppc64le/management/index>` to learn how to perform the remote hardware control.
|
||||
|
||||
#. Deploy OS on the target nodes
|
||||
|
||||
|
@ -17,7 +17,7 @@ B<bmcdiscover> [B<-u> I<bmc_user>] [B<-p> I<bmc_passwd>] B<-i> I<bmc_ip> B<--ips
|
||||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
The B<bmcdiscover> command will discover Baseboard Management Controllers (BMCs) using a scan mathod.
|
||||
The B<bmcdiscover> command will discover Baseboard Management Controllers (BMCs) using a scan method.
|
||||
|
||||
The command uses B<nmap> to scan active nodes over a specified IP range. The IP range format should be a format that is acceptable by B<nmap>.
|
||||
|
||||
@ -31,7 +31,7 @@ Note: The scan method currently support is B<nmap>.
|
||||
|
||||
=item B<--range>
|
||||
|
||||
Specify one or more IP ranges acceptable to nmap. IP rance can be hostnames, IP addresses, networks, etc. A single IP address (10.1.2.3) or an IP range (10.1.2.0/24) can be specified. If the range is very large, the B<bmcdiscover> command may take a long time to return.
|
||||
Specify one or more IP ranges acceptable to nmap. IP range can be hostnames, IP addresses, networks, etc. A single IP address (10.1.2.3) or an IP range (10.1.2.0/24) can be specified. If the range is very large, the B<bmcdiscover> command may take a long time to return.
|
||||
|
||||
=item B<-s>
|
||||
|
||||
|
@ -81,7 +81,7 @@ The NFS export directory must be configured for read write access and must
|
||||
be owned by vdsm:kvm.
|
||||
B<localfs>: "/data/images/rhev" is set by default.
|
||||
|
||||
B<virtsd.host> - A host must be specified for a storage doamin as SPM
|
||||
B<virtsd.host> - A host must be specified for a storage domain as SPM
|
||||
(Storage Pool Manager) when initialize the storage domain. The role of SPM
|
||||
may be migrated to other host by rhev-m during the running of the datacenter
|
||||
(For example, when the current SPM encountered issue or going to maintenance
|
||||
|
@ -114,7 +114,7 @@ This command also supports to change specific partition attributes by specifying
|
||||
|
||||
For Power 755(use option I<--p775> to specify):
|
||||
|
||||
chvm could be used to change the octant configuration values for generating LPARs. chvm is designed to set the Octant configure value to split the CPU and memory for partitions, and set Octant Memory interleaving value. The chvm will only set the pending attributes value. After chvm, the CEC needs to be rebooted manually for the pending values to be enabled. Before reboot the cec, the administrator can use chvm to change the partition plan. If the the partition needs I/O slots, the administrator should use chvm to assign the I/O slots.
|
||||
chvm could be used to change the octant configuration values for generating LPARs. chvm is designed to set the Octant configure value to split the CPU and memory for partitions, and set Octant Memory interleaving value. The chvm will only set the pending attributes value. After chvm, the CEC needs to be rebooted manually for the pending values to be enabled. Before reboot the cec, the administrator can use chvm to change the partition plan. If the partition needs I/O slots, the administrator should use chvm to assign the I/O slots.
|
||||
|
||||
chvm is also designed to assign the I/O slots to the new LPAR. Both the current IO owning lpar and the new IO owning lpar must be powered off before an IO assignment. Otherwise, if the I/O slot is belonged to an Lpar and the LPAR is power on, the command will return an error when trying to assign that slot to a different lpar.
|
||||
|
||||
@ -127,7 +127,7 @@ chvm could be used to modify the resources assigned to partitions. The admin sha
|
||||
|
||||
=head2 zVM specific:
|
||||
|
||||
The chvm command modifes the virtual machine's configuration specified in noderange.
|
||||
The chvm command modifies the virtual machine's configuration specified in noderange.
|
||||
|
||||
=head1 OPTIONS
|
||||
|
||||
@ -248,7 +248,7 @@ Purge the Hard disk. Deregisters and deletes the files. Multiple can be done w
|
||||
|
||||
=item B<--resize> I<disk>=I<size>
|
||||
|
||||
Change the size of the Hard disk. The disk in I<qcow2> format can not be set to less than it's current size. The disk in I<raw> format can be resized smaller, use caution. Multiple disks can be resized by using comma separated I<disk>B<=>I<size> pairs. The disks are specified by SCSI id. Size defaults to GB.
|
||||
Change the size of the Hard disk. The disk in I<qcow2> format can not be set to less than its current size. The disk in I<raw> format can be resized smaller, use caution. Multiple disks can be resized by using comma separated I<disk>B<=>I<size> pairs. The disks are specified by SCSI id. Size defaults to GB.
|
||||
|
||||
=back
|
||||
|
||||
|
@ -11,7 +11,7 @@ B<csm2xcat> [B<-h>]
|
||||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
The csm2xcat command must be run on the Management Server of the CSM system that you want to migrate to xCAT. The commmand will build two xCAT stanza files that can update the xCAT database with the chdef command.
|
||||
The csm2xcat command must be run on the Management Server of the CSM system that you want to migrate to xCAT. The command will build two xCAT stanza files that can update the xCAT database with the chdef command.
|
||||
|
||||
Copy the csm2xcat command to the CSM Management Server. Run the command, indicating where you want your stanza files saved with the B<--dir> parameter. Check the stanza files to see if the information is what you want put in the xCAT database. Copy the two stanza files: node.stanza, device.stanza back to your xCAT Management node, and run the chdef command to input into the xCAT database.
|
||||
|
||||
|
@ -28,7 +28,7 @@ For full information on the setup of DB2, see Setting_Up_DB2_as_the_xCAT_DB.
|
||||
|
||||
When running of db2sqlsetup on the MN:
|
||||
One password must be supplied for the setup, a password for the xcatdb unix id which will be used as the DB2 instance id and database name. The password will be prompted for interactively or can be input with the XCATDB2PW environment variable.
|
||||
The script will create the xcat database instance (xcatdb) in the /var/lib/db2 directory unless overriden by setting the site.databaseloc attribute. This attribute should not be set to the directory that is defined in the installloc attribute and it is recommended that the databaseloc be a new filesystem dedicated to the DB2 database, especially in very large clusters.
|
||||
The script will create the xcat database instance (xcatdb) in the /var/lib/db2 directory unless overridden by setting the site.databaseloc attribute. This attribute should not be set to the directory that is defined in the installloc attribute and it is recommended that the databaseloc be a new filesystem dedicated to the DB2 database, especially in very large clusters.
|
||||
|
||||
When running db2sqlseutp on the SN:
|
||||
Not only will the password for the DB2 instance Id be prompted for and must match the one on the Management Node; but also the hostname or ip address of the Management Node as known by the Service Node must be supplied , unless the XCATDB2SERVER environment variable is set.
|
||||
|
@ -17,7 +17,7 @@ If not using the binary dump option (-b), then the dumpxCATdb command creates .c
|
||||
Supports using XCAT_SKIPTABLES env variable to provide a list of skip tables.
|
||||
The command will never backup TEAL or ISNM tables, except isnm_config. To dump TEAL tables use the documented process for TEAL. For ISNM use tabdump, after using tabprune to get to prune unnecessary records.
|
||||
|
||||
If using the binary dump option for the DB2 or postgreSQL database, then the routine will use the Database provide utilites for backup of the entire database.
|
||||
If using the binary dump option for the DB2 or postgreSQL database, then the routine will use the Database provide utilities for backup of the entire database.
|
||||
|
||||
=head1 OPTIONS
|
||||
|
||||
@ -28,7 +28,7 @@ B<-v> Command Version.
|
||||
|
||||
B<-V> Verbose.
|
||||
|
||||
B<-a> All,without this flag the eventlog and auditlog will be skipped.
|
||||
B<-a> All, without this flag the eventlog and auditlog will be skipped.
|
||||
|
||||
B<-b> This flag is only used for the DB2 or postgreSQL database. The routine will use the database backup utilities to create a binary backup of the entire database. Note to use this backup on DB2, you will have first had to modify the logging of the database and have taken an offline initial backup. Refer to the xCAT DB2 documentation for more instructions.
|
||||
|
||||
|
@ -29,7 +29,7 @@ for stateless: B<packimage>
|
||||
|
||||
for statelite: B<liteimg>
|
||||
|
||||
Besides prompting for some paramter values, the B<genimage> command takes default guesses for the parameters not specified or not defined in the I<osimage> and I<linuximage> tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Use B<--interactive> flag if you want the yum/zypper command to prompt you for the answers.
|
||||
Besides prompting for some parameter values, the B<genimage> command takes default guesses for the parameters not specified or not defined in the I<osimage> and I<linuximage> tables. It also assumes default answers for questions from the yum/zypper command when installing rpms into the image. Use B<--interactive> flag if you want the yum/zypper command to prompt you for the answers.
|
||||
|
||||
If B<--onlyinitrd> is specified, genimage only regenerates the initrd for a stateless image to be used for a diskless install.
|
||||
|
||||
|
@ -26,7 +26,7 @@ If the initrd has been rebuilt by geninitrd, when run nodeset, the I<--noupdatei
|
||||
should be used to skip the rebuilding of initrd to improve the performance.
|
||||
|
||||
Three attributes of osimage object can be used to specify the Driver RPM location and Driver names
|
||||
for injecting new drviers to initrd.
|
||||
for injecting new drivers to initrd.
|
||||
|
||||
B<netdrivers> - comma separated driver names that need to be injected to the initrd.
|
||||
The postfix '.ko' can be ignored. The netdrivers attribute must be set to specify the new driver list.
|
||||
@ -51,7 +51,7 @@ this command is used to generate the initrd from the rootimg which generated by
|
||||
So the 'genimage' must be run once before running the geninitrd command.
|
||||
|
||||
Two attributes of osimage object can be used to specify the Driver RPM location and Driver names
|
||||
for injecting new drviers to initrd.
|
||||
for injecting new drivers to initrd.
|
||||
|
||||
B<netdrivers> - comma separated driver names that need to be injected to the initrd.
|
||||
The postfix '.ko' can be ignored. The netdrivers attribute must be set to specify the new driver list.
|
||||
@ -64,7 +64,7 @@ B<driverupdatesrc> - comma separated driver rpm packages (full path should be sp
|
||||
|
||||
=head1 Parameters
|
||||
|
||||
I<imagename> specifies the name of an os image definition to be used. The specification for the image is storted in the I<osimage> table and I<linuximage> table.
|
||||
I<imagename> specifies the name of an os image definition to be used. The specification for the image is stored in the I<osimage> table and I<linuximage> table.
|
||||
|
||||
=over 12
|
||||
|
||||
|
@ -16,8 +16,8 @@ B<getadapter> use genesis to collect network adapters information, so that mean
|
||||
|
||||
B<getadapter> For each node within the <noderange>, follows below scheme:
|
||||
|
||||
If the target node is scaned for the first time, B<getadapter> will trigger genesis to collect information then save the information at the B<nicsadapter> column of nics table.
|
||||
If the target node has ever been scaned, B<getadapter> will use the information from nics table first.
|
||||
If the target node is scanned for the first time, B<getadapter> will trigger genesis to collect information then save the information at the B<nicsadapter> column of nics table.
|
||||
If the target node has ever been scanned, B<getadapter> will use the information from nics table first.
|
||||
If user hopes to scan the adapter information for the node but these information already exist, B<-f> option can be used to start rescan process.
|
||||
|
||||
B<getadapter> tries to collect more information for the target network device, but doesn't guarantee collect same much information for every network device.
|
||||
|
@ -23,12 +23,12 @@ B<getmacs> I<noderange> [B<-V>| B<--verbose>] [B<-d>] [B<--arp>] [B<-i> I<ethN>
|
||||
=head1 DESCRIPTION
|
||||
|
||||
The getmacs command collects MAC address from a single or range of nodes.
|
||||
Note that on AIX systems, the returned MAC address is not colon-seperated (for example 8ee2245cf004), while on Linux systems the MAC address is colon-seperated (for example 8e:e2:24:5c:f0:04).
|
||||
Note that on AIX systems, the returned MAC address is not colon-separated (for example 8ee2245cf004), while on Linux systems the MAC address is colon-separated (for example 8e:e2:24:5c:f0:04).
|
||||
If no ping test performed, getmacs writes the first adapter MAC to the xCAT database. If ping test performed, getmacs will write the first successfully pinged MAC to xCAT database.
|
||||
|
||||
For PPC (using Direct FSP Management) specific:
|
||||
|
||||
Note: If network adapters are physically assigned to LPARs, getmacs cannot read the MAC addresses unless perform B<Discovery> with option "B<-D>", since there is no HMC command to read them and getmacs has to login to open formware. And if the LPARs has never been activated before, getmacs need to be performed with the option "B<-D>" to get theirs MAC addresses.
|
||||
Note: If network adapters are physically assigned to LPARs, getmacs cannot read the MAC addresses unless perform B<Discovery> with option "B<-D>", since there is no HMC command to read them and getmacs has to login to open firmware. And if the LPARs has never been activated before, getmacs need to be performed with the option "B<-D>" to get theirs MAC addresses.
|
||||
|
||||
For PPC (using HMC) specific:
|
||||
|
||||
@ -42,7 +42,7 @@ Note: If "B<-d>" is specified, all the MAC of the blades will be displayed. If n
|
||||
|
||||
B<--arp>
|
||||
|
||||
Read MAC address with ARP protocal.
|
||||
Read MAC address with ARP protocol.
|
||||
|
||||
B<-C>
|
||||
|
||||
@ -58,7 +58,7 @@ Perform discovery for mac address. By default, it will run ping test to test th
|
||||
|
||||
B<-f>
|
||||
|
||||
Force immediate shutdown of the partition.This flag must be used with -D flag.
|
||||
Force immediate shutdown of the partition. This flag must be used with -D flag.
|
||||
|
||||
B<-F>
|
||||
|
||||
@ -86,7 +86,7 @@ Read MAC address when the lpar is in openfirmware state. This option mush be us
|
||||
|
||||
B<-S>
|
||||
|
||||
The IP address of the machine to ping. The default is to read from xCAT databse if no B<-S> specified.
|
||||
The IP address of the machine to ping. The default is to read from xCAT database if no B<-S> specified.
|
||||
|
||||
B<-v>
|
||||
|
||||
@ -122,7 +122,7 @@ Output is similar to:
|
||||
ent U78A1.001.99203B5-P1-T6 00145eb55788 /lhea@23c00614/ethernet@23e00514 unsuccessful physical
|
||||
|
||||
|
||||
2. To retrieve the MAC address with ARP protocal:
|
||||
2. To retrieve the MAC address with ARP protocol:
|
||||
|
||||
getmacs lpar4 --arp
|
||||
|
||||
|
@ -15,7 +15,7 @@ This tool will build a directory of files, one for each defined
|
||||
nodegroup in xCAT. The file will be named the nodegroup name and
|
||||
contain a list of nodes that belong to the nodegroup.
|
||||
The file can be used as input to the AIX dsh command.
|
||||
The purpose of this tool is to allow backward compatiblity with scripts
|
||||
The purpose of this tool is to allow backward compatibility with scripts
|
||||
that were created using the AIX or CSM dsh command
|
||||
|
||||
Reference: man dsh.
|
||||
|
@ -45,7 +45,7 @@ For statelite:
|
||||
where x is the name of the profile.
|
||||
|
||||
|
||||
Any files specified by the B<-e> flag will also be exported. If B<-p> flag is specified, the names of the postscripts and the postbootscripts for the given node will be exported. The postscripts themsleves need to be manualy exported using B<-e> flag.
|
||||
Any files specified by the B<-e> flag will also be exported. If B<-p> flag is specified, the names of the postscripts and the postbootscripts for the given node will be exported. The postscripts themselves need to be manualy exported using B<-e> flag.
|
||||
|
||||
For statelite, the litefile table settings for the image will also be exported. The litetree and statelite tables are not exported.
|
||||
|
||||
|
@ -50,7 +50,7 @@ If B<-p> flag is specified, the I<postscripts> table will be updated with the po
|
||||
|
||||
If B<-f> flag is not specified, all the files will be copied to the same directories as the source. If it is specified, the old profile name x will be changed to the new and the files will be copied to the appropriate directores for the new profiles. For example, I</opt/xcat/share/xcat/netboot/sles/x.pkglist> will be copied to I</install/custom/netboot/sles/compute_new.pkglist> and I</install/netboot/sles11/ppc64/x/kernel> will be copied to I</install/netboot/sles11/ppc64/compute_new/kernel>. This flag is commonly used when you want to copy the image on the same xCAT mn so you can make modification on the new one.
|
||||
|
||||
After this command, you can run the B<nodeset> command and then start deploying the nodes. You can also choose to modify the files and run the following commands before the node depolyment.
|
||||
After this command, you can run the B<nodeset> command and then start deploying the nodes. You can also choose to modify the files and run the following commands before the node deployment.
|
||||
|
||||
For stateful:
|
||||
nodeset
|
||||
|
@ -41,7 +41,7 @@ Note: If you make any changes to your litefile table after running liteimg then
|
||||
|
||||
=head1 PARAMETERS
|
||||
|
||||
I<imagename> specifies the name of a os image definition to be used. The specification for the image is storted in the I<osimage> table and I<linuximage> table.
|
||||
I<imagename> specifies the name of a os image definition to be used. The specification for the image is stored in the I<osimage> table and I<linuximage> table.
|
||||
|
||||
|
||||
=head1 OPTIONS
|
||||
|
@ -22,7 +22,7 @@ There are several concepts to support the HX5 multiple blades combination:
|
||||
|
||||
B<Complex>: Multiple blades which combined by a scalability card is a complex.
|
||||
|
||||
B<Parition>: A logic concept which containing part of the B<Blade slot node> in a complex. Each partition can map to a system to install Operating System. Each partition could have 1HX5, 1HX5+1MD or 2HX5+2MD. (MD is the Memory Drawer)
|
||||
B<Partition>: A logic concept which containing part of the B<Blade slot node> in a complex. Each partition can map to a system to install Operating System. Each partition could have 1HX5, 1HX5+1MD or 2HX5+2MD. (MD is the Memory Drawer)
|
||||
|
||||
B<Blade slot node>: The physical blade which installed in the slot of a chassis. It can be a HX5 or MD.
|
||||
|
||||
|
@ -57,7 +57,7 @@ Return the output with XML tags. The data is returned as:
|
||||
</kitinfo>
|
||||
</data>
|
||||
|
||||
Each <kitinfo> tag contains info for a group of kit compoonents belonging to the same kit. The info inside <kitinfo> is structured as follows:
|
||||
Each <kitinfo> tag contains info for a group of kit components belonging to the same kit. The info inside <kitinfo> is structured as follows:
|
||||
|
||||
The <kit> sub-tag contains the kit's name.
|
||||
The <kitcomponent> sub-tags store info about the kit's components.
|
||||
|
@ -19,13 +19,13 @@ NOTE: SLP broadcast requests will propagate only within the subnet of the networ
|
||||
|
||||
=head1 OPTIONS
|
||||
|
||||
B<noderange> The nodes which the user want to discover. If the user specify the noderange, lsslp will just return the nodes in the node range. Which means it will help to add the new nodes to the xCAT database without modifying the existed definitions. But the nodes' name specified in noderange should be defined in database in advance. The specified nodes' type can be frame/cec/hmc/fsp/bpa. If the it is frame or cec, lsslp will list the bpa or fsp nodes within the nodes(bap for frame, fsp for cec). Do not use noderange with the flag -s.
|
||||
B<noderange> The nodes which the user wants to discover. If the user specifies the noderange, lsslp will just return the nodes in the node range. Which means it will help to add the new nodes to the xCAT database without modifying the existed definitions. But the nodes' name specified in noderange should be defined in database in advance. The specified nodes' type can be frame/cec/hmc/fsp/bpa. If the it is frame or cec, lsslp will list the bpa or fsp nodes within the nodes(bap for frame, fsp for cec). Do not use noderange with the flag -s.
|
||||
|
||||
B<-i> IP(s) the command will send out (defaults to all available adapters).
|
||||
|
||||
B<-h> Display usage message.
|
||||
|
||||
B<-n> Only display and write the newly discovered hardwares.
|
||||
B<-n> Only display and write the newly discovered hardware.
|
||||
|
||||
B<-u> Do unicast to a specified IP range. Must be used with B<-s> and B<--range>. The B<-u> flag is not supported on AIX.
|
||||
|
||||
@ -33,16 +33,16 @@ B<--range> Specify one or more IP ranges. Must be use in unicast mode. It ac
|
||||
|
||||
B<-r> Display Raw SLP response.
|
||||
|
||||
B<-C> The number of the expected responses specified by the user. When using this flag, lsslp will not return until the it has found all the nodes or time out. The default max time is 3 secondes. The user can use -T flag the specify the time they want to use. A short time will limite the time costing, while a long time will help to find all the nodes.
|
||||
B<-C> The number of the expected responses specified by the user. When using this flag, lsslp will not return until the it has found all the nodes or time out. The default max time is 3 seconds. The user can use -T flag the specify the time they want to use. A short time will limit the time costing, while a long time will help to find all the nodes.
|
||||
|
||||
B<-T> The number in seconds to limite the time costing of lsslp.
|
||||
B<-T> The number in seconds to limit the time of lsslp.
|
||||
|
||||
|
||||
B<-s> Service type interested in discovering.
|
||||
|
||||
B<-t> Number or service-request attempts.
|
||||
|
||||
B<--vpdtable> Output the SLP response in vpdtable formatting. Easy for writting data to vpd table.
|
||||
B<--vpdtable> Output the SLP response in vpdtable formatting. Easy for writing data to vpd table.
|
||||
|
||||
B<-v> Command Version.
|
||||
|
||||
@ -52,9 +52,9 @@ B<-w> Writes output to xCAT database.
|
||||
|
||||
B<-x> XML format.
|
||||
|
||||
B<-z> Stanza formated output.
|
||||
B<-z> Stanza formatted output.
|
||||
|
||||
B<-I> Give the warning message for the nodes in database which have no SLP responses. Note that this flag noly can be used after the database migration finished successfully.
|
||||
B<-I> Give the warning message for the nodes in database which have no SLP responses. Note that this flag can only be used after the database migration finished successfully.
|
||||
|
||||
|
||||
=head1 RETURN VALUE
|
||||
|
@ -10,7 +10,7 @@ B<lstree> [B<-s> | B<--servicenode>] [B<-H> | B<--hardwaremgmt>] [B<-v> | B<--vi
|
||||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
The B<lstree> command can display the tree of service node hierarchy for the xCAT nodes which have service node defined or which are service nodes, display the tree of hardware hierarchy only for the physical objects, display the tree of VM hierarchy for the xCAT nodes which are virtual machines or which are the hosts of virtual machines. If a noderange is specified, only show the part of the hierarchy that involves those nodes. For ZVM, we only support to disply VM hierarchy. By default, lstree will show both the hardware hierarchy and the VM hierarchy for all the nodes.
|
||||
The B<lstree> command can display the tree of service node hierarchy for the xCAT nodes which have service node defined or which are service nodes, display the tree of hardware hierarchy only for the physical objects, display the tree of VM hierarchy for the xCAT nodes which are virtual machines or which are the hosts of virtual machines. If a noderange is specified, only show the part of the hierarchy that involves those nodes. For ZVM, we only support to display VM hierarchy. By default, lstree will show both the hardware hierarchy and the VM hierarchy for all the nodes.
|
||||
|
||||
=head1 OPTIONS
|
||||
|
||||
|
@ -248,7 +248,7 @@ Output is similar to:
|
||||
Bytes per BSR array: 4096
|
||||
Available BSR array: 256
|
||||
|
||||
Note: The lines listed in "All Physical I/O info" section represent all the physical I/O resource information. The format is like "owner_lparid,slot_id,physical resource name,drc_index,slot_class_code(class discription)". The 'drc index' is short for Dynamic Resource Configuration Index, it uniquely indicates a physical I/O resource in a normal power machine.
|
||||
Note: The lines listed in "All Physical I/O info" section represent all the physical I/O resource information. The format is like "owner_lparid,slot_id,physical resource name,drc_index,slot_class_code(class description)". The 'drc index' is short for Dynamic Resource Configuration Index, it uniquely indicates a physical I/O resource in a normal power machine.
|
||||
|
||||
9. For DFM-managed partition on normal power machine, list out the detailed information:
|
||||
|
||||
|
@ -50,7 +50,7 @@ A set of comma delimited object types. Use the help option to get a list of val
|
||||
|
||||
=item B<--template> I<template-object-name>
|
||||
|
||||
Name of the xCAT shipped object definition template or an existing object, from which the new object definition will be created. The newly created object will inherit the attributes of the template definition unless the attribute is specified in the arguments of B<mkdef> command. If there are a template and an existing object with the same name I<template-object-name>, the tempalte object takes precedence over the existing object. For the details of xCAT shipped object definition templates, refer to the manpage of B<--template> option in L<lsdef(1)|lsdef.1>.
|
||||
Name of the xCAT shipped object definition template or an existing object, from which the new object definition will be created. The newly created object will inherit the attributes of the template definition unless the attribute is specified in the arguments of B<mkdef> command. If there are a template and an existing object with the same name I<template-object-name>, the template object takes precedence over the existing object. For the details of xCAT shipped object definition templates, refer to the manpage of B<--template> option in L<lsdef(1)|lsdef.1>.
|
||||
|
||||
=item B<-V|--verbose>
|
||||
|
||||
@ -58,7 +58,7 @@ Verbose mode.
|
||||
|
||||
=item B<-w> I<attr==val> B<-w> I<attr=~val> ...
|
||||
|
||||
Use one or multiple -w flags to specify the selection string that can be used to select objects. The operators ==, !=, =~ and !~ are available. For mkdef commmand, the -w flag only makes sense for creating dynamic node group. Use the help option to get a list of valid attributes for each object type.
|
||||
Use one or multiple -w flags to specify the selection string that can be used to select objects. The operators ==, !=, =~ and !~ are available. For mkdef command, the -w flag only makes sense for creating dynamic node group. Use the help option to get a list of valid attributes for each object type.
|
||||
|
||||
Operator descriptions:
|
||||
== Select nodes where the attribute value is exactly this value.
|
||||
|
@ -82,7 +82,7 @@ Output is similar to:
|
||||
host01c01: Pull image ubuntu start
|
||||
host01c01: Pull image ubuntu done
|
||||
host01c01: Remove default network connection
|
||||
host01c01: Connecting customzied network 'mynet0'
|
||||
host01c01: Connecting customized network 'mynet0'
|
||||
host01c01: success
|
||||
|
||||
2. To create a docker instance which have dir "destdir" in docker instance bind from "srcdir" on dockerhost, and have "Tty" opened with which the docker instance can be attached after started to check the files under "destdir".
|
||||
@ -92,7 +92,7 @@ Output is similar to:
|
||||
Output is similar to:
|
||||
|
||||
host01c01: Remove default network connection
|
||||
host01c01: Connecting customzied network 'mynet0'
|
||||
host01c01: Connecting customized network 'mynet0'
|
||||
host01c01: success
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
@ -19,7 +19,7 @@ This command will also create a NIM resolv_conf resource to be used when install
|
||||
The "domain" and "nameservers" attributes can be set in either the xCAT "network" definition used by the nodes or in the xCAT cluster "site" definition. The setting in the "network" definition will take priority.
|
||||
|
||||
The "search" field of the resolv.conf file will contain a list all the domains
|
||||
listed in the xCAT network definitions and the xCAT site definiton.
|
||||
listed in the xCAT network definitions and the xCAT site definition.
|
||||
|
||||
The "nameservers" value can either be set to a specific IP address or the "<xcatmaster>" key word. The "<xcatmaster>" key word means that the value of the "xcatmaster" attribute of the node definition will be used in the /etc/resolv.conf file. (I.e. The name of the install server as known by the node.)
|
||||
|
||||
@ -41,11 +41,11 @@ You can use the "-n" option of the mkdsklsnode command to create and initialize
|
||||
|
||||
B<Note:> When using the "-n" option make sure that the new osimage you specify and all the NIM resources that are used are different than what are currently being used on the nodes. The NIM resources should not be shared between the old osimage and the new osimage.
|
||||
|
||||
You can use the force option to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinititializing. Use this option with caution since reinitializing a node will stop the node if it is currently running.
|
||||
You can use the force option to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinitializing. Use this option with caution since reinitializing a node will stop the node if it is currently running.
|
||||
|
||||
After the mkdsklsnode command completes you can use the B<lsnim> command to check the NIM node definition to see if it is ready for booting the node. ("lsnim -l <nim_node_name>").
|
||||
|
||||
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the B<mkdsklsnode> command. Such scripts are called B<prescripts>. They should be copied to /install/prescripts dirctory. A table called I<prescripts> is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the B<mkdsklsnode> command are stored in the 'begin' column of I<prescripts> table. The scripts to be run at the end of the B<mkdsklsnode> command are stored in the 'end' column of I<prescripts> table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: I<diskless:myscript1,myscript2>. The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current current nodeset action, in this case "diskless". If I<#xCAT setting:MAX_INSTANCE=number> is specified in the script, the script will get invoked for each node in parallel, but no more than I<number> of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes.
|
||||
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the B<mkdsklsnode> command. Such scripts are called B<prescripts>. They should be copied to /install/prescripts directory. A table called I<prescripts> is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the B<mkdsklsnode> command are stored in the 'begin' column of I<prescripts> table. The scripts to be run at the end of the B<mkdsklsnode> command are stored in the 'end' column of I<prescripts> table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: I<diskless:myscript1,myscript2>. The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "diskless". If I<#xCAT setting:MAX_INSTANCE=number> is specified in the script, the script will get invoked for each node in parallel, but no more than I<number> of instances will be invoked at a time. If it is not specified, the script will be invoked once for all the nodes.
|
||||
|
||||
|
||||
=head1 OPTIONS
|
||||
|
@ -24,7 +24,7 @@ B<Adding software and configuration files to the osimage.>
|
||||
|
||||
When creating a diskless osimage definition you also have the option of automatically updating the NIM SPOT resource. You can have additional software installed or you can have configuration files added or updated. To have software installed you must provide either the names of NIM installp_bundle resources or fileset names on the command line using the "attr=val" option. You may also supply the installp flags, RPM flags, emgr flags to use when installing the software.
|
||||
|
||||
To have configuration files updated you must provide the full path name of a "synclists" file which contains the the list of actual files to update. The xCAT osimage definition that is created will contain the installp_bundle, otherpkgs, and synclists files that are provided on the command line.
|
||||
To have configuration files updated you must provide the full path name of a "synclists" file which contains the list of actual files to update. The xCAT osimage definition that is created will contain the installp_bundle, otherpkgs, and synclists files that are provided on the command line.
|
||||
|
||||
B<Updating an existing xCAT osimage>
|
||||
|
||||
@ -50,7 +50,7 @@ You can use the "-i" and "-p" options to copy an existing diskless osimage. To
|
||||
|
||||
- any other resources (or attributes) included in the original osimage will be included in the new osimage definition.
|
||||
|
||||
- if the "-p" option is specified then the original NIM lpp_source resource will be copied to a new location and redfined to NIM. (The default would be to use the original lpp_source - to save file system space.)
|
||||
- if the "-p" option is specified then the original NIM lpp_source resource will be copied to a new location and redefined to NIM. (The default would be to use the original lpp_source - to save file system space.)
|
||||
|
||||
|
||||
B<Additional information>
|
||||
@ -67,7 +67,7 @@ To list a NIM resource definition use the AIX B<lsnim> command ("lsnim -l <resou
|
||||
|
||||
To check the validity of a SPOT or lpp_source resource use the AIX B<nim> command ("nim -o check <resourec-name>").
|
||||
|
||||
To remove specific NIM resource definitons use the AIX B<nim> command. ("nim -o remove <resource-name>").
|
||||
To remove specific NIM resource definitions use the AIX B<nim> command. ("nim -o remove <resource-name>").
|
||||
|
||||
=head1 OPTIONS
|
||||
|
||||
@ -187,7 +187,7 @@ Value Specifies the security method required for NFS access.
|
||||
|
||||
=back
|
||||
|
||||
Note that you may specify multiple "script", "otherpkgs", and "installp_bundle" resources by using a comma seperated list. (ex. "script=ascript,bscript"). RPM names may be included in the "otherpkgs" list by using a "R:" prefix(ex. "R:whatever.rpm"). epkg (AIX interim fix package) file names may be included in the "otherpkgs" using the 'E:' prefix. (ex. "otherpkgs=E:IZ38930TL0.120304.epkg.Z").
|
||||
Note that you may specify multiple "script", "otherpkgs", and "installp_bundle" resources by using a comma separated list. (ex. "script=ascript,bscript"). RPM names may be included in the "otherpkgs" list by using a "R:" prefix(ex. "R:whatever.rpm"). epkg (AIX interim fix package) file names may be included in the "otherpkgs" using the 'E:' prefix. (ex. "otherpkgs=E:IZ38930TL0.120304.epkg.Z").
|
||||
|
||||
=item B<-b> I<mksysbfile>
|
||||
|
||||
@ -195,7 +195,7 @@ Used to specify the path name of a mksysb file to use when defining a NIM mksysb
|
||||
|
||||
=item B<-c|--completeosimage>
|
||||
|
||||
Complete the creation of the osimage definition passed in on the command line. This option will use any additonal values passed in on the command line and/or it will attempt to create required resources in order to complete the definition of the xCAT osimage. For example, if the osimage definition is missing a spot or shared_root resource the command will create those resources and add them to the osimage definition.
|
||||
Complete the creation of the osimage definition passed in on the command line. This option will use any additional values passed in on the command line and/or it will attempt to create required resources in order to complete the definition of the xCAT osimage. For example, if the osimage definition is missing a spot or shared_root resource the command will create those resources and add them to the osimage definition.
|
||||
|
||||
=item B<-f|--force>
|
||||
|
||||
@ -333,7 +333,7 @@ The xCAT osimage definition created by this command will include the "otherpkgs"
|
||||
|
||||
mknimimage -u 61dskls installp_bundle=bndres1,bndres2 installp_flags="-agcQX"
|
||||
|
||||
Note that when "installp_bundle", "otherpkgs", or "synclists" values are specified with the "-u" option then the xCAT osimage definiton is not used or updated.
|
||||
Note that when "installp_bundle", "otherpkgs", or "synclists" values are specified with the "-u" option then the xCAT osimage definition is not used or updated.
|
||||
|
||||
13) Update an existing image to support NFSv4. Also specify verbose messages.
|
||||
|
||||
|
@ -88,7 +88,7 @@ Request to create a new full system partition for each CEC.
|
||||
|
||||
=item B<vmcpus=> I<value> B<vmmemory=> I<value> B<vmphyslots=> I<value> B<vmothersetting=> I<value> B<vmnics=> I<value> B<vmstorage=> I<value> [B<--vios>]
|
||||
|
||||
To specify the parameters which are used to create a partition. The I<vmcpus>, I<vmmemory> are necessay, and the value specified with this command have a more high priority. If the value of any of the three options is not specified, the corresponding value specified for the node object will be used. If any of the three attributes is neither specified with this command nor specified with the node object, error information will be returned. To reference to L<lsvm(1)|lsvm.1> for more information about 'drc_index' for I<vmphyslots>.
|
||||
To specify the parameters which are used to create a partition. The I<vmcpus>, I<vmmemory> are necessary, and the value specified with this command have a more high priority. If the value of any of the three options is not specified, the corresponding value specified for the node object will be used. If any of the three attributes is neither specified with this command nor specified with the node object, error information will be returned. To reference to L<lsvm(1)|lsvm.1> for more information about 'drc_index' for I<vmphyslots>.
|
||||
|
||||
The option I<vios> is used to specify the partition that will be created is a VIOS partition. If specified, the value for I<vmstorage> shall be number which indicate the number of vSCSI server adapter will be created, and if no value specified for I<vmphyslots>, all the physical slot of the power machine will be asigned to VIOS partition. If not specified, it shall be in form of I<vios_name:server_slotid> to specify the vios and the virtual slot id of the vSCSI server adapter that will be connected from the Logical partition.
|
||||
|
||||
@ -241,7 +241,7 @@ First, define a node object:
|
||||
|
||||
mkdef -t node -o lpar1 mgt=fsp cons=fsp nodetype=ppc,osi id=1 hcp=cec parent=cec hwtype=lpar groups=lpar,all
|
||||
|
||||
Then, create the partion on the specified cec.
|
||||
Then, create the partition on the specified cec.
|
||||
|
||||
mkvm lpar1 --full
|
||||
|
||||
@ -321,7 +321,7 @@ The output is similar to:
|
||||
|
||||
mkvm viosnode vmcpus=1/4/16 vmmemory=1G/4G/32G vmphyslots=0x21010201,0x21010200 vmnics=vlan1 vmstorage=5 --vios
|
||||
|
||||
The resouces for the node is similar to:
|
||||
The resources for the node is similar to:
|
||||
|
||||
viosnode: Lpar Processor Info:
|
||||
Curr Processor Min: 1.
|
||||
|
@ -18,9 +18,9 @@ This command is used to register a monitoring plug-in module to monitor the xCAT
|
||||
|
||||
=head1 Parameters
|
||||
|
||||
I<name> is the name of the monitoring plug-in module. For example, if the the I<name> is called I<xxx>, then the actual file name that the xcatd looks for is I</opt/xcat/lib/perl/xCAT_monitoring/xxx.pm>. Use I<monls -a> command to list all the monitoring plug-in modules that can be used.
|
||||
I<name> is the name of the monitoring plug-in module. For example, if the I<name> is called I<xxx>, then the actual file name that the xcatd looks for is I</opt/xcat/lib/perl/xCAT_monitoring/xxx.pm>. Use I<monls -a> command to list all the monitoring plug-in modules that can be used.
|
||||
|
||||
I<settings> is the monitoring plug-in specific settings. It is used to customize the behavior of the plug-in or configure the 3rd party software. Format: I<-s key-value -s key=value ...> Note that the square brackets are needed here. Use I<monls name -d> command to look for the possbile setting keys for a plug-in module.
|
||||
I<settings> is the monitoring plug-in specific settings. It is used to customize the behavior of the plug-in or configure the 3rd party software. Format: I<-s key-value -s key=value ...> Note that the square brackets are needed here. Use I<monls name -d> command to look for the possible setting keys for a plug-in module.
|
||||
|
||||
=head1 OPTIONS
|
||||
|
||||
|
@ -15,12 +15,12 @@ B<moncfg> I<name> I<[noderange]> B<[-r|--remote]>
|
||||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
This command is used to configure a 3rd party monitoring software to monitor the xCAT cluster. For example, it modifies the configration file for the monitoring software so that the nodes can be included in the monitoring domain. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the I<-r> option is specified, though the configuration of the nodes is usually performed during the node deployment stage.
|
||||
This command is used to configure a 3rd party monitoring software to monitor the xCAT cluster. For example, it modifies the configuration file for the monitoring software so that the nodes can be included in the monitoring domain. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the I<-r> option is specified, though the configuration of the nodes is usually performed during the node deployment stage.
|
||||
|
||||
|
||||
=head1 Parameters
|
||||
|
||||
I<name> is the name of the monitoring plug-in module. For example, if the the I<name> is called I<xxx>, then the actual file name that the xcatd looks for is I</opt/xcat/lib/perl/xCAT_monitoring/xxx.pm>. Use I<monls -a> command to list all the monitoring plug-in modules that can be used.
|
||||
I<name> is the name of the monitoring plug-in module. For example, if the I<name> is called I<xxx>, then the actual file name that the xcatd looks for is I</opt/xcat/lib/perl/xCAT_monitoring/xxx.pm>. Use I<monls -a> command to list all the monitoring plug-in modules that can be used.
|
||||
|
||||
I<noderange> specifies the nodes to be monitored. If omitted, all nodes will be monitored.
|
||||
|
||||
|
@ -15,7 +15,7 @@ B<mondecfg> I<name> I<[noderange]> B<[-r|--remote]>
|
||||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
This command is used to deconfigure a 3rd party monitoring software from monitoring the xCAT cluster. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the I<-r> option is specified. The deconfigration operation will remove the nodes from the 3rd party software's monitoring domain.
|
||||
This command is used to deconfigure a 3rd party monitoring software from monitoring the xCAT cluster. The operation is performed on the management node and the service nodes of the given nodes. The operation will also be performed on the nodes if the I<-r> option is specified. The deconfiguration operation will remove the nodes from the 3rd party software's monitoring domain.
|
||||
|
||||
|
||||
=head1 PARAMETERS
|
||||
|
@ -15,7 +15,7 @@ B<monls [-a|--all] [-d|--description]>
|
||||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
This command is used to list the status, desctiption, the configuration scripts and the settings of one or all of the monitoring plug-in modules.
|
||||
This command is used to list the status, description, the configuration scripts and the settings of one or all of the monitoring plug-in modules.
|
||||
|
||||
|
||||
=head1 Parameters
|
||||
@ -26,9 +26,9 @@ I<name> is the name of the monitoring plug-in module.
|
||||
=head1 OPTIONS
|
||||
|
||||
|
||||
B<-a | --all> Searches the I<XCATROOT/lib/perl/xCAT_monitoring> directory and reports all the monitoring plug-in modules. If nothing is specified, the list is read from the I<monitoring> tabel.
|
||||
B<-a | --all> Searches the I<XCATROOT/lib/perl/xCAT_monitoring> directory and reports all the monitoring plug-in modules. If nothing is specified, the list is read from the I<monitoring> table.
|
||||
|
||||
B<-d | --description> Display the description of the plug-in modules. The description ususally contains the possible settings.
|
||||
B<-d | --description> Display the description of the plug-in modules. The description usually contains the possible settings.
|
||||
|
||||
B<-h | --help> Display usage message.
|
||||
|
||||
@ -64,7 +64,7 @@ The output looks like this:
|
||||
nagiosmon not-monitored
|
||||
|
||||
|
||||
3. To list the status and the desciption for I<snmpmon> module, enter:
|
||||
3. To list the status and the description for I<snmpmon> module, enter:
|
||||
|
||||
monls snmpmon -d
|
||||
|
||||
|
@ -36,7 +36,7 @@ B<-t> specifies a range of time for the data, The default is last 60 minutes. Fo
|
||||
|
||||
B<-a> specifies a comma-separated list of attributes or metrics names. The default is all.
|
||||
|
||||
B<-w> specify one or multiple selection string that can be used to select events. The operators ==, !=, =,!,>,<,>=,<= are available. Wildcards % and _ are supported in the pattern string. % allows you to match any string of any length(including zero length) and _ allows you to match on a single character. The valid attributes are eventtype, monitor, monnode, application, component, id, serverity, message, rawdata, comments. Valid severity are: Informational, Warning, Critical.
|
||||
B<-w> specify one or multiple selection string that can be used to select events. The operators ==, !=, =,!,>,<,>=,<= are available. Wildcards % and _ are supported in the pattern string. % allows you to match any string of any length(including zero length) and _ allows you to match on a single character. The valid attributes are eventtype, monitor, monnode, application, component, id, severity, message, rawdata, comments. Valid severity are: Informational, Warning, Critical.
|
||||
|
||||
Operator descriptions:
|
||||
|
||||
|
@ -18,7 +18,7 @@ This command is used to start a 3rd party software, (for example start the daemo
|
||||
|
||||
=head1 PARAMETERS
|
||||
|
||||
I<name> is the name of the monitoring plug-in module. For example, if the the I<name> is called I<xxx>, then the actual file name that the xcatd looks for is I</opt/xcat/lib/perl/xCAT_monitoring/xxx.pm>. Use B<monls -a> command to list all the monitoring plug-in modules that can be used.
|
||||
I<name> is the name of the monitoring plug-in module. For example, if the I<name> is called I<xxx>, then the actual file name that the xcatd looks for is I</opt/xcat/lib/perl/xCAT_monitoring/xxx.pm>. Use B<monls -a> command to list all the monitoring plug-in modules that can be used.
|
||||
|
||||
I<noderange> is the nodes to be monitored. If omitted, all nodes will be monitored.
|
||||
|
||||
|
@ -30,9 +30,9 @@ To create a NIM installp_bundle definition you can use the "nim -o define" opera
|
||||
|
||||
nim -o define -t installp_bundle -a server=master -a location=/install/nim/mypkgs.bnd mypackages
|
||||
|
||||
See the AIX documantation for more information on using installp_bundle files.
|
||||
See the AIX documentation for more information on using installp_bundle files.
|
||||
|
||||
The xCAT nimnodecust command will automatically handle the distribution of the packages to AIX service nodes when using an xCAT hierachical environment.
|
||||
The xCAT nimnodecust command will automatically handle the distribution of the packages to AIX service nodes when using an xCAT hierarchical environment.
|
||||
|
||||
=head1 OPTIONS
|
||||
|
||||
|
@ -14,7 +14,7 @@ This xCAT command can be used to initialize AIX/NIM standalone machines. Once th
|
||||
|
||||
If you are using xCAT service nodes the B<nimnodeset> command will automatically determine the correct server(s) for the node and do the initialization on that server(s).
|
||||
|
||||
The osimage_name is the name of an xCAT osimage definition that contains the list of NIM resources to use when initializing the nodes. If the osimage_name is not provided on the command line the code checks the node definition for the value of the "provmethod" attribute (which is the name of an osimage definition). If the osimage_image is provided on the command line then the code will also set the "provmethod" attribute of the node definiions.
|
||||
The osimage_name is the name of an xCAT osimage definition that contains the list of NIM resources to use when initializing the nodes. If the osimage_name is not provided on the command line the code checks the node definition for the value of the "provmethod" attribute (which is the name of an osimage definition). If the osimage_image is provided on the command line then the code will also set the "provmethod" attribute of the node definitions.
|
||||
|
||||
This command will also create a NIM resolv_conf resource to be used when installing the node. If a resolv_conf resource is not already included in the xCAT osimage definition and if the "domain" and "nameservers" values are set then a new
|
||||
NIM resolv_conf resource will be created and allocated to the nodes.
|
||||
@ -22,7 +22,7 @@ NIM resolv_conf resource will be created and allocated to the nodes.
|
||||
The "domain" and "nameservers" attributes can be set in either the xCAT "network" definition used by the nodes or in the xCAT cluster "site" definition. The setting in the "network" definition will take priority.
|
||||
|
||||
The "search" field of the resolv.conf file will contain a list all the domains
|
||||
listed in the xCAT network definitions and the xCAT site definiton.
|
||||
listed in the xCAT network definitions and the xCAT site definition.
|
||||
|
||||
The "nameservers" value can either be set to a specific IP address or the "<xcatmaster>" key word. The "<xcatmaster>" key word means that the value of the "xcatmaster" attribute of the node definition will be used in the /etc/resolv.conf file. (I.e. The name of the install server as known by the node.)
|
||||
|
||||
@ -35,13 +35,13 @@ will be created.
|
||||
|
||||
You can specify additional attributes and values using the "attr=val" command line option. This information will be passed on to the underlying call to the NIM "nim -o bos_inst" command. See the NIM documentation for information on valid command line options for the nim command. The "attr" must correspond to a NIM attribute supported for the NIM "bos_inst" operation. Information provided by the "attr=val" option will take precedence over the information provided in the osimage definition.
|
||||
|
||||
The force option can be used to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinititializing.
|
||||
The force option can be used to reinitialize a node if it already has resources allocated or it is in the wrong NIM state. This option will reset the NIM node and deallocate resources before reinitializing.
|
||||
|
||||
This command will also create a NIM script resource to enable the xCAT support for user-provided customization scripts.
|
||||
|
||||
After the B<nimnodeset> command completes you can use the B<lsnim> command to check the NIM node definition to see if it is ready for booting the node. ("lsnim -l <nim_node_name>").
|
||||
|
||||
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the B<nimnodeset> command. Such scripts are called B<prescripts>. They should be copied to /install/prescripts dirctory. A table called I<prescripts> is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the B<nimnodeset> command are stored in the 'begin' column of I<prescripts> table. The scripts to be run at the end of the B<nimnodeset> command are stored in the 'end' column of I<prescripts> table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: I<standalone:myscript1,myscript2>. The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "standalone". If I<#xCAT setting:MAX_INSTANCE=number> is specified in the script, the script will get invoked for each node in parallel, but no more than I<number> of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes.
|
||||
You can supply your own scripts to be run on the management node or on the service node (if their is hierarchy) for a node during the B<nimnodeset> command. Such scripts are called B<prescripts>. They should be copied to /install/prescripts directory. A table called I<prescripts> is used to specify the scripts and their associated actions. The scripts to be run at the beginning of the B<nimnodeset> command are stored in the 'begin' column of I<prescripts> table. The scripts to be run at the end of the B<nimnodeset> command are stored in the 'end' column of I<prescripts> table. Run 'tabdump prescripts -d' command for details. An example for the 'begin' or the 'end' column is: I<standalone:myscript1,myscript2>. The following two environment variables will be passed to each script: NODES contains all the names of the nodes that need to run the script for and ACTION contains the current nodeset action, in this case "standalone". If I<#xCAT setting:MAX_INSTANCE=number> is specified in the script, the script will get invoked for each node in parallel, but no more than I<number> of instances will be invoked at at a time. If it is not specified, the script will be invoked once for all the nodes.
|
||||
|
||||
=head1 OPTIONS
|
||||
|
||||
@ -50,7 +50,7 @@ You can supply your own scripts to be run on the management node or on the serv
|
||||
=item I<attr=val [attr=val ...]>
|
||||
|
||||
Specifies one or more "attribute equals value" pairs, separated by spaces. Attr=
|
||||
val pairs must be specified last on the command line. These are used to specify additional values that can be passed to the underlying NIM commands, ("nim -o bos_inst ..."). See the NIM documentation for valid "nim" command line options. Note that you may specify multiple "script" and "installp_bundle" values by using a comma seperated list. (ex. "script=ascript,bscript").
|
||||
val pairs must be specified last on the command line. These are used to specify additional values that can be passed to the underlying NIM commands, ("nim -o bos_inst ..."). See the NIM documentation for valid "nim" command line options. Note that you may specify multiple "script" and "installp_bundle" values by using a comma separated list. (ex. "script=ascript,bscript").
|
||||
|
||||
=item B<-b|--backupSN>
|
||||
|
||||
@ -70,8 +70,7 @@ The name of an existing xCAT osimage definition.
|
||||
|
||||
=item B<-l|--location>
|
||||
|
||||
The directory location to use when creating new NIM resolv_conf resources. The d
|
||||
efault location is /install/nim.
|
||||
The directory location to use when creating new NIM resolv_conf resources. The default location is /install/nim.
|
||||
|
||||
=item B<-p|--primarySN>
|
||||
|
||||
|
@ -34,7 +34,7 @@ Sets the IP address of the unmanaged node, where I<ip-address> is the IP address
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured.
|
||||
1 An error has occurred.
|
||||
|
||||
=head1 EXAMPLES
|
||||
|
||||
|
@ -36,7 +36,7 @@ Sets the new MAC address for the NIC used by the provisioning node, where <mac-a
|
||||
|
||||
0 The command completed successfully.
|
||||
|
||||
1 An error has occured.
|
||||
1 An error has occurred.
|
||||
|
||||
=head1 EXAMPLES
|
||||
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user