mtpti5iD/redhat-docs_dataset huggingface dataset:
C.5. Glock Holders Table C.5, "Glock holder flags" shows the meanings of the different glock holder flags. Table C.5. Glock holder flags Flag Name Meaning a Async Do not wait for glock result (will poll for result later) A Any Any compatible lock mode is acceptable c No cache When unlocked, demote DLM lock immediately e No expire Ignore subsequent lock cancel requests E Exact Must have exact lock mode F First Set when holder is the first to be granted for this lock H Holder Indicates that requested lock is granted p Priority Enqueue holder at the head of the queue t Try A "try" lock T Try 1CB A "try" lock that sends a callback W Wait Set while waiting for request to complete The most important holder flags are H (holder) and W (wait) as mentioned earlier, since they are set on granted lock requests and queued lock requests respectively. The ordering of the holders in the list is important. If there are any granted holders, they will always be at the head of the queue, followed by any queued holders. If there are no granted holders, then the first holder in the list will be the one that triggers the state change. Since demote requests are always considered higher priority than requests from the file system, that might not always directly result in a change to the state requested. The glock subsystem supports two kinds of "try" lock. These are useful both because they allow the taking of locks out of the normal order (with suitable back-off and retry) and because they can be used to help avoid resources in use by other nodes. The normal t (try) lock is just what its name indicates; it is a "try" lock that does not do anything special. The T ( try 1CB ) lock, on the other hand, is identical to the t lock except that the DLM will send a single callback to current incompatible lock holders. One use of the T ( try 1CB ) lock is with the iopen locks, which are used to arbitrate among the nodes when an inode's i_nlink count is zero, and determine which of the nodes will be responsible for deallocating the inode. The iopen glock is normally held in the shared state, but when the i_nlink count becomes zero and ->delete_inode () is called, it will request an exclusive lock with T ( try 1CB ) set. It will continue to deallocate the inode if the lock is granted. If the lock is not granted it will result in the node(s) which were preventing the grant of the lock marking their glock(s) with the D (demote) flag, which is checked at ->drop_inode () time in order to ensure that the deallocation is not forgotten. This means that inodes that have zero link count but are still open will be deallocated by the node on which the final close () occurs. Also, at the same time as the inode's link count is decremented to zero the inode is marked as being in the special state of having zero link count but still in use in the resource group bitmap. This functions like the ext3 file system3's orphan list in that it allows any subsequent reader of the bitmap to know that there is potentially space that might be reclaimed, and to attempt to reclaim it.

Commands:
5.2. Physical Volume Administration This section describes the commands that perform the various aspects of physical volume administration. 5.2.1. Creating Physical Volumes The following subsections describe the commands used for creating physical volumes. 5.2.1.1. Setting the Partition Type If you are using a whole disk device for your physical volume, the disk must have no partition table. For DOS disk partitions, the partition id should be set to 0x8e using the fdisk or cfdisk command or an equivalent. For whole disk devices only the partition table must be erased, which will effectively destroy all data on that disk. You can remove an existing partition table by zeroing the first sector with the following command: 5.2.1.2. Initializing Physical Volumes Use the pvcreate command to initialize a block device to be used as a physical volume. Initialization is analogous to formatting a file system. The following command initializes /dev/sdd , /dev/sde , and /dev/sdf as LVM physical volumes for later use as part of LVM logical volumes. To initialize partitions rather than whole disks: run the pvcreate command on the partition. The following example initializes the partition /dev/hdb1 as an LVM physical volume for later use as part of an LVM logical volume. 5.2.1.3. Scanning for Block Devices You can scan for block devices that may be used as physical volumes with the lvmdiskscan command, as shown in the following example.

Commands:
dd if=/dev/zero of= PhysicalVolume bs=512 count=1
pvcreate /dev/sdd /dev/sde /dev/sdf
pvcreate /dev/hdb1
lvmdiskscan /dev/ram0 [ 16.00 MB] /dev/sda [ 17.15 GB] /dev/root [ 13.69 GB] /dev/ram [ 16.00 MB] /dev/sda1 [ 17.14 GB] LVM physical volume /dev/VolGroup00/LogVol01 [ 512.00 MB] /dev/ram2 [ 16.00 MB] /dev/new_vg/lvol0 [ 52.00 MB] /dev/ram3 [ 16.00 MB] /dev/pkl_new_vg/sparkie_lv [ 7.14 GB] /dev/ram4 [ 16.00 MB] /dev/ram5 [ 16.00 MB] /dev/ram6 [ 16.00 MB] /dev/ram7 [ 16.00 MB] /dev/ram8 [ 16.00 MB] /dev/ram9 [ 16.00 MB] /dev/ram10 [ 16.00 MB] /dev/ram11 [ 16.00 MB] /dev/ram12 [ 16.00 MB] /dev/ram13 [ 16.00 MB] /dev/ram14 [ 16.00 MB] /dev/ram15 [ 16.00 MB] /dev/sdb [ 17.15 GB] /dev/sdb1 [ 17.14 GB] LVM physical volume /dev/sdc [ 17.15 GB] /dev/sdc1 [ 17.14 GB] LVM physical volume /dev/sdd [ 17.15 GB] /dev/sdd1 [ 17.14 GB] LVM physical volume 7 disks 17 partitions 0 LVM physical volume whole disks 4 LVM physical volumes
10.6. Using Multiple Importers When you define the metadata import type for a model, you can also define a comma-separated list of importers. By doing so, you will ensure that all of the repository instances defined by import types are consulted in the order in which they have been defined. Here is an example: <vdb name="{vdb-name}" version="1"> <model name="{model-name}" type="PHYSICAL"> <source name="AccountsDB" translator-name="oracle" connection-jndi-name="java:/oracleDS"/> <metadata type="NATIVE,DDL"> **DDL Here** </metadata> </model> </vdb> In this model, the NATIVE importer is used first, then the DDL importer is used to add additional metadata to the NATIVE-imported metadata.

Commands:
<vdb name="{vdb-name}" version="1"> <model name="{model-name}" type="PHYSICAL"> <source name="AccountsDB" translator-name="oracle" connection-jndi-name="java:/oracleDS"/> <metadata type="NATIVE,DDL"> **DDL Here** </metadata> </model> </vdb>
10.3. Updating CA-KRA Connector Information After Cloning As covered in Section 2.7.9, "Custom Configuration and Clones" , configuration information is not updated in clone instances if it is made after the clone is created. Likewise, changes made to a clone are not copied back to the master instance. If a new KRA is installed or cloned after a clone CA is created, then the clone CA does not have the new KRA connector information in its configuration. This means that the clone CA is not able to send any archival requests to the KRA. Whenever a new KRA is created or cloned, copy its connector information into all of the cloned CAs in the deployment. To do this, use the pki ca-kraconnector-add command. If it is required to do this manually, follow these steps: On the master clone machine, open the master CA's CS.cfg file, and copy all of the ca.connector.KRA.* lines for the new KRA connector. Stop the clone CA instance. For example: Open the clone CA's CS.cfg file. Copy in the connector information for the new KRA instance or clone. Start the clone CA.

Commands:
vim /var/lib/pki/ instance_name /ca/conf/CS.cfg
pki-server stop instance_name
vim /var/lib/pki/ instance_name /ca/conf/CS.cfg
ca.connector.KRA.enable=true ca.connector.KRA.host=server-kra.example.com ca.connector.KRA.local=false ca.connector.KRA.nickName=subsystemCert cert-pki-ca ca.connector.KRA.port=10444 ca.connector.KRA.timeout=30 ca.connector.KRA.transportCert=MIIDbD...ZR0Y2zA== ca.connector.KRA.uri=/kra/agent/kra/connector
pki-server start instance_name
Chapter 158. KafkaRebalanceStatus schema reference Used in: KafkaRebalance Property Property type Description conditions Condition array List of status conditions. observedGeneration integer The generation of the CRD that was last reconciled by the operator. sessionId string The session identifier for requests to Cruise Control pertaining to this KafkaRebalance resource. This is used by the Kafka Rebalance operator to track the status of ongoing rebalancing operations. optimizationResult map A JSON object describing the optimization result.

Commands:
8.11. amtu 8.11.1. RHBA-2014:0639 - amtu bug fix update Updated amtu package that fixes three bugs is now available for Red Hat Enterprise Linux 6. The Abstract Machine Test Utility (AMTU) is an administrative utility to verify that the underlying protection mechanisms of the system hardware are being enforced correctly. Bug Fixes BZ# 689823 Previously, Abstract Machine Test Utility (AMTU) did not handle the name of the interface correctly under certain circumstances. As a consequence, AMTU failed to obtain a list of network interfaces to test. With this update, the interface hardware type and carriers are obtained from the /sys/class/net/ directory. Now, only an Ethernet and a token ring can be used, and a carrier must be present. As a result, AMTU handles the new network interface names as expected. BZ# 723049 Prior to this update, AMTU ran network tests on interfaces configured with a static IP that did not have an existing connection, causing those tests to fail. With this update, AMTU no longer runs tests on interfaces that are not up. BZ# 1098076 Previously, the name of the network interface was restricted to 4 characters on 32-bit systems and 8 characters on 64-bit system due to using the sizeof() operator instead of the strlen() function. As a consequence, AMTU did not correctly display the full network interface name in certain portions of the output. A patch has been applied to address this bug, and AMTU now always displays the full network interface name as expected. Users of amtu are advised to upgrade to the updated package, which fixes these bugs.

Commands:
4.23. Intel Modular Table 4.24, "Intel Modular" lists the fence device parameters used by fence_intelmodular , the fence agent for Intel Modular. Table 4.24. Intel Modular luci Field cluster.conf Attribute Description Name name A name for the Intel Modular device connected to the cluster. IP Address or Hostname ipaddr The IP address or host name assigned to the device. UDP/TCP Port (optional) udpport The UDP/TCP port to use for connection with the device; the default value is 161. Login login The login name used to access the device. Password passwd The password used to authenticate the connection to the device. Password Script (optional) passwd_script The script that supplies a password for access to the fence device. Using this supersedes the Password parameter. SNMP Version snmp_version The SNMP version to use (1, 2c, 3); the default value is 1. SNMP Community community The SNMP community string; the default value is private . SNMP Security Level snmp_sec_level The SNMP security level (noAuthNoPriv, authNoPriv, authPriv). SNMP Authentication Protocol snmp_auth_prot The SNMP authentication protocol (MD5, SHA). SNMP Privacy Protocol snmp_priv_prot The SNMP privacy protocol (DES, AES). SNMP Privacy Protocol Password snmp_priv_passwd The SNMP privacy protocol password. SNMP Privacy Protocol Script snmp_priv_passwd_script The script that supplies a password for SNMP privacy protocol. Using this supersedes the SNMP privacy protocol password parameter. Power Wait (seconds) power_wait Number of seconds to wait after issuing a power off or power on command. Power Timeout (seconds) power_timeout Number of seconds to continue testing for a status change after issuing a power off or power on command. The default value is 20. Shell Timeout (seconds) shell_timeout Number of seconds to wait for a command prompt after issuing a command. The default value is 3. Login Timeout (seconds) login_timeout Number of seconds to wait for a command prompt after login. The default value is 5. Times to Retry Power On Operation retry_on Number of attempts to retry a power on operation. The default value is 1. Port (Outlet) Number port Physical plug number or name of virtual machine. Delay (optional) delay The number of seconds to wait before fencing is started. The default value is 0. Figure 4.18, "Intel Modular" shows the configuration screen for adding an Intel Modular fence device. Figure 4.18. Intel Modular The following command creates a fence device instance for an Intel Modular device: The following is the cluster.conf entry for the fence_intelmodular device:

Commands:
ccs -f cluster.conf --addfencedev intelmodular1 agent=fence_intelmodular community=private ipaddr=192.168.0.1 login=root passwd=password123 snmp_priv_passwd=snmpasswd123 power_wait=60 udpport=161
<fencedevices> <fencedevice agent="fence_intelmodular" community="private" ipaddr="192.168.0.1" login="root" name="intelmodular1" passwd="password123" power_wait="60" snmp_priv_passwd="snmpasswd123" udpport="161"/> </fencedevices>
Chapter 8. Updating existing Kubernetes storage objects Storage version migration is used to update existing objects in the cluster from their current version to the latest version. The Kube Storage Version Migrator embedded controller is used in MicroShift to migrate resources without having to recreate those resources. Either you or a controller can create a StorageVersionMigration custom resource (CR) that requests a migration through the Migrator Controller. 8.1. Updating stored data to the latest storage version Updating stored data to the latest Kubernetes storage version is called storage migration. For example, updating from v1beta1 to v1beta2 is migration. To update your storage version, use the following procedure. Procedure Either you or any controller that has support for the StorageVersionMigration API must trigger a migration request. Use the following example request for reference: Example request apiVersion: migration.k8s.io/v1alpha1 kind: StorageVersionMigration metadata: name: snapshot-v1 spec: resource: group: snapshot.storage.k8s.io resource: volumesnapshotclasses 1 version: v1 2 1 You must use the plural name of the resource. 2 Version being updated to. The progress of the migration is posted to the StorageVersionMigration status. Note Failures can occur because of a misnamed group or resource. Migration failures can also occur when there is an incompatibility between the and latest versions.

Commands:
apiVersion: migration.k8s.io/v1alpha1 kind: StorageVersionMigration metadata: name: snapshot-v1 spec: resource: group: snapshot.storage.k8s.io resource: volumesnapshotclasses 1 version: v1 2
4.14. Hewlett-Packard BladeSystem Table 4.15, "HP BladeSystem (Red Hat Enterprise Linux 6.4 and later)" lists the fence device parameters used by fence_hpblade , the fence agent for HP BladeSystem. Table 4.15. HP BladeSystem (Red Hat Enterprise Linux 6.4 and later) luci Field cluster.conf Attribute Description Name name The name assigned to the HP Bladesystem device connected to the cluster. IP Address or Hostname ipaddr The IP address or host name assigned to the HP BladeSystem device. IP Port (optional) ipport The TCP port to use to connect to the device. Login login The login name used to access the HP BladeSystem device. This parameter is required. Password passwd The password used to authenticate the connection to the fence device. Password Script (optional) passwd_script The script that supplies a password for access to the fence device. Using this supersedes the Password parameter. Force Command Prompt cmd_prompt The command prompt to use. The default value is '\USD'. Missing port returns OFF instead of failure missing_as_off Missing port returns OFF instead of failure. Power Wait (seconds) power_wait Number of seconds to wait after issuing a power off or power on command. Power Timeout (seconds) power_timeout Number of seconds to continue testing for a status change after issuing a power off or power on command. The default value is 20. Shell Timeout (seconds) shell_timeout Number of seconds to wait for a command prompt after issuing a command. The default value is 3. Login Timeout (seconds) login_timeout Number of seconds to wait for a command prompt after login. The default value is 5. Times to Retry Power On Operation retry_on Number of attempts to retry a power on operation. The default value is 1. Use SSH secure Indicates that the system will use SSH to access the device. When using SSH, you must specify either a password, a password script, or an identity file. SSH Options ssh_options SSH options to use. The default value is -1 -c blowfish . Path to SSH Identity File identity_file The identity file for SSH. Figure 4.11, "HP BladeSystem" shows the configuration screen for adding an HP BladeSystem fence device. Figure 4.11. HP BladeSystem The following command creates a fence device instance for a BladeSystem device: The following is the cluster.conf entry for the fence_hpblade device:

Commands:
ccs -f cluster.conf --addfencedev hpbladetest1 agent=fence_hpblade cmd_prompt=c7000oa> ipaddr=192.168.0.1 login=root passwd=password123 missing_as_off=on power_wait=60
<fencedevices> <fencedevice agent="fence_hpblade" cmd_prompt="c7000oa>" ipaddr="hpbladeaddr" ipport="13456" login="root" missing_as_off="on" name="hpbladetest1" passwd="password123" passwd_script="hpbladepwscr" power_wait="60"/> </fencedevices>
Chapter 3. The pcs Command Line Interface The pcs command line interface controls and configures corosync and Pacemaker by providing an interface to the corosync.conf and cib.xml files. The general format of the pcs command is as follows. 3.1. The pcs Commands The pcs commands are as follows. cluster Configure cluster options and nodes. For information on the pcs cluster command, see Chapter 4, Cluster Creation and Administration . resource Create and manage cluster resources. For information on the pcs cluster command, see Chapter 6, Configuring Cluster Resources , Chapter 8, Managing Cluster Resources , and Chapter 9, Advanced Configuration . stonith Configure fence devices for use with Pacemaker. For information on the pcs stonith command, see Chapter 5, Fencing: Configuring STONITH . constraint Manage resource constraints. For information on the pcs constraint command, see Chapter 7, Resource Constraints . property Set Pacemaker properties. For information on setting properties with the pcs property command, see Chapter 12, Pacemaker Cluster Properties . status View current cluster and resource status. For information on the pcs status command, see Section 3.5, "Displaying Status" . config Display complete cluster configuration in user readable form. For information on the pcs config command, see Section 3.6, "Displaying the Full Cluster Configuration" .

Commands:
pcs [-f file ] [-h] [ commands ]
11.4. Preparation for IBM Power Systems servers Important Ensure that the real-base boot parameter is set to c00000 , otherwise you might see errors such as: IBM Power Systems servers offer many options for partitioning, virtual or native devices, and consoles. If you are using a non-partitioned system, you do not need any pre-installation setup. For systems using the HVSI serial console, hook up your console to the T2 serial port. If using a partitioned system the steps to create the partition and start the installation are largely the same. You should create the partition at the HMC and assign some CPU and memory resources, as well as SCSI and Ethernet resources, which can be either virtual or native. The HMC create partition wizard steps you through the creation. For more information on creating the partition, refer to the Partitioning for Linux with an HMC PDF in the IBM Systems Hardware Information Center at: http://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/topic/iphbi_p5/iphbibook.pdf If you are using virtual SCSI resources, rather than native SCSI, you must configure a 'link' to the virtual SCSI serving partition, and then configure the virtual SCSI serving partition itself. You create a 'link' between the virtual SCSI client and server slots using the HMC. You can configure a virtual SCSI server on either Virtual I/O Server (VIOS) or IBM i, depending on which model and options you have. If you are installing using Intel iSCSI Remote Boot, all attached iSCSI storage devices must be disabled. Otherwise, the installation will succeed but the installed system will not boot. For more information on using virtual devices, see the IBM Redbooks publication Virtualizing an Infrastructure with System p and Linux at: http://publib-b.boulder.ibm.com/abstracts/sg247499.html Once you have your system configured, you need to Activate from the HMC or power it on. Depending on what type of install you are doing, you may need to configure SMS to correctly boot the system into the installation program.

Commands:
DEFAULT CATCH!, exception-handler=fff00300
Chapter 4. General Updates In-place upgrade from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7 An in-place upgrade offers a way of upgrading a system to a new major release of Red Hat Enterprise Linux by replacing the existing operating system. To perform an in-place upgrade, use the Preupgrade Assistant , a utility that checks the system for upgrade issues before running the actual upgrade, and that also provides additional scripts for the Red Hat Upgrade Tool . When you have solved all the problems reported by the Preupgrade Assistant , use the Red Hat Upgrade Tool to upgrade the system. For details regarding procedures and supported scenarios, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Migration_Planning_Guide/chap-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-Upgrading.html and https://access.redhat.com/solutions/637583 . Note that the Preupgrade Assistant and the Red Hat Upgrade Tool are available in the Red Hat Enterprise Linux 6 Extras channel, see https://access.redhat.com/support/policy/updates/extras . (BZ#1432080) cloud-init moved to the Base channel As of Red Hat Enterprise Linux 7.4, the cloud-init package and its dependencies have been moved from the Red Hat Common channel to the Base channel. Cloud-init is a tool that handles early initialization of a system using metadata provided by the environment. It is typically used to configure servers booting in a cloud environment, such as OpenStack or Amazon Web Services. Note that the cloud-init package has not been updated since the latest version provided through the Red Hat Common channel. (BZ#1427280)

Commands:
D.20. Status View To open Teiid Designer's Status View , click the main menu's Window > Show View > Other... and then click the Teiid Designer > Status view in the dialog. The Status View provides a quick overview status of the selected project. A sample Status view for a project is shown below: Figure D.32. Status View The status view is broken down into common project areas: Source Connections - all Source Connections are fully defined. Sources - Source Models exist. XML Schema - XML Schemas exist. Views - View Models exist. VDBs - VDBs exist and are deployable. Model Validation (Status) - all Models pass validation. Test - all defined VDBs pass validation. The status of each area is denoted by an icon: A green check indicates OK, a red x indicates errors and a warning icon indicates potential problems. The project can be changed by selecting the Change Project button.

Commands: