mtpti5iD/redhat-docs_dataset huggingface dataset:
7.3. SPM Priority The SPM role uses some of a host's available resources. The SPM priority setting of a host alters the likelihood of the host being assigned the SPM role: a host with high SPM priority will be assigned the SPM role before a host with low SPM priority. Critical virtual machines on hosts with low SPM priority will not have to contend with SPM operations for host resources. You can change a host's SPM priority in the SPM tab in the Edit Host window.

Commands:
5.3. Disabling Durable Transactions Durable transaction logging means that each LDAP update operation, comprised of a sequence of database operations in a transaction, is physically written to disk. Even though each LDAP operation can be comprised of multiple database operations, each LDAP operation is treated as a single database transaction. Each LDAP operation is both atomic and durable. Warning Turning off durable transactions can improve Directory Server write performance at the risk of data loss. When durable transaction logging is disabled, every directory database operation is written to the database transaction log file but may not be physically written to disk immediately. If a directory change was written to the logical database transaction log file but not physically written to disk at the time of a system crash, the change cannot be recovered. When durable transactions are disabled, the recovered database is consistent but does not reflect the results of any LDAP write operations that completed just before the system crash. By default, durable database transaction logging is enabled. To disable durable transaction logging: Stop the Directory Server instance: Edit the /etc/dirsrv/slapd- instance_name /dse.ldif file, and set the nsslapd-db-durable-transaction parameter in the cn=config,cn=ldbm database,cn=plugins,cn=config entry to off : Start the Directory Server instance:

Commands:
dsctl instance_name stop
dn: cn=config,cn=ldbm database,cn=plugins,cn=config nsslapd-db-durable-transaction: off
dsctl instance_name start
5.4.2.3. Locality of Reads/Writes Although not strictly constrained to a multi-requester environment, this aspect of hard drive performance does tend to show itself more in such an environment. The issue is whether the I/O requests being made of a hard drive are for data that is physically close to other data that is also being requested. The reason why this is important becomes apparent if the electromechanical nature of the hard drive is kept in mind. The slowest component of any hard drive is the access arm. Therefore, if the data being accessed by the incoming I/O requests requires no movement of the access arm, the hard drive is able to service many more I/O requests than if the data being accessed was spread over the entire drive, requiring extensive access arm movement. This can be illustrated by looking at hard drive performance specifications. These specifications often include adjacent cylinder seek times (where the access arm is moved a small amount -- only to the cylinder), and full-stroke seek times (where the access arm moves from the very first cylinder to the very last one). For example, here are the seek times for a high-performance hard drive: Table 5.4. Adjacent Cylinder and Full-Stroke Seek Times (in Milliseconds) Adjacent Cylinder Full-Stroke 0.6 8.2

Commands:
15.22. Displaying the Status of a Specific Replication Agreement You can display the status of a specific replication agreement using the command line and in the web console. 15.22.1. Displaying the Status of a Specific Replication Agreement Using the Command-Line To display the status of a replication agreement using the command line: This example shows replication currently fails because the consumer.example.com host is unavailable. 15.22.2. Displaying the Status of a Specific Replication Agreement Using the Web Console To display the status of a replication agreement in the web console: Open the Directory Server user interface in the web console. See Section 1.4, "Logging Into Directory Server Using the Web Console" . Select the instance. Open the Monitoring menu, and select Replication Select Replication entry from the list in the left pane. Depending on whether you want to display the status of a replication agreement between Directory Server instances or a Winsync Agreement, select the appropriate tab. The Update Status column displays the status of replication agreement.

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt status --suffix=" dc=example,dc=com " agreement_name agreement_name Status for agreement_name agmt consumer.example.com :636 Replica Enabled: on Update In Progress: FALSE Last Update Start: 19700101000000Z Last Update End: 19700101000000Z Number Of Changes Sent: 0 Number Of Changes Skipped: None Last Update Status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) Init In Progress: Last Init Start: 19700101000000Z Last Init End: 19700101000000Z Last Init Status: unavailable Reap Active: 0 Replication Status: Not in Synchronization: supplier (5bed8467000100010000) consumer (Unavailable) Reason(Unknown) Replication Lag Time: Unavailable
Chapter 21. CIDR range definitions You must specify non-overlapping ranges for the following CIDR ranges. Note Machine CIDR ranges cannot be changed after creating your cluster. Important OVN-Kubernetes, the default network provider in OpenShift Container Platform 4.11 to 4.13, uses the following IP address ranges internally: 100.64.0.0/16 , 169.254.169.0/29 , fd98::/64 and fd69::/125 . If your cluster uses OVN-Kubernetes, do not include any IP address ranges in any other CIDR definitions in your cluster. 21.1. Machine CIDR In the Machine classless inter-domain routing (CIDR) field, you must specify the IP address range for machines or cluster nodes. The default is 10.0.0.0/16 . This range must not conflict with any connected networks. 21.2. Service CIDR In the Service CIDR field, you must specify the IP address range for services. The range must be large enough to accommodate your workload. The address block must not overlap with any external service accessed from within the cluster. The default is 172.30.0.0/16 . 21.3. Pod CIDR In the pod CIDR field, you must specify the IP address range for pods. The pod CIDR is the same as the clusterNetwork CIDR and the cluster CIDR. The range must be large enough to accommodate your workload. The address block must not overlap with any external service accessed from within the cluster. The default is 10.128.0.0/14 . You can expand the range after cluster installation. Additional resources Cluster Network Operator Configuration Configuring the cluster network range 21.4. Host Prefix In the Host Prefix field, you must specify the subnet prefix length assigned to pods scheduled to individual machines. The host prefix determines the pod IP address pool for each machine. For example, if the host prefix is set to /23 , each machine is assigned a /23 subnet from the pod CIDR address range. The default is /23 , allowing 510 cluster nodes, and 510 pod IP addresses per node.

Commands:
Chapter 2. Configuring the upgrade strategy for OpenShift AI As a cluster administrator, you can configure either an automatic or manual upgrade strategy for the Red Hat OpenShift AI Operator. Important By default, the Red Hat OpenShift AI Operator follows a sequential update process. This means that if there are several versions between the current version and the version that you intend to upgrade to, Operator Lifecycle Manager (OLM) upgrades the Operator to each of the intermediate versions before it upgrades it to the final, target version. If you configure automatic upgrades, OLM automatically upgrades the Operator to the latest available version, without human intervention. If you configure manual upgrades, a cluster administrator must manually approve each sequential update between the current version and the final, target version. For information about supported versions, see the Red Hat OpenShift AI Self-Managed Life Cycle Knowledgebase article. Prerequisites You have cluster administrator privileges for your OpenShift cluster. The Red Hat OpenShift AI Operator is installed. Procedure Log in to the OpenShift cluster web console as a cluster administrator. In the Administrator perspective, in the left menu, select Operators Installed Operators . Click the Red Hat OpenShift AI Operator. Click the Subscription tab. Under Update approval , click the pencil icon and select one of the following update strategies: Automatic : New updates are installed as soon as they become available. Manual : A cluster administrator must approve any new update before installation begins. Click Save . Additional resources For more information about the subscription channels that are available in version 2 of the Red Hat OpenShift AI Operator, see Installing the Red Hat OpenShift AI Operator . For more information about upgrading Operators that have been installed by using OLM, see Updating installed Operators in the OpenShift documentation.

Commands:
Administration and Configuration Guide Red Hat JBoss Data Grid 6.6 For use with Red Hat JBoss Data Grid 6.6.1 Misha Husnain Ali Red Hat Engineering Content Services mhusnain@redhat.com Gemma Sheldon Red Hat Engineering Content Services gsheldon@redhat.com Rakesh Ghatvisave Red Hat Engineering Content Services rghatvis@redhat.com Christian Huffman Red Hat Engineering Content Services chuffman@redhat.com

Commands:
4.2. GFS2 File System Hangs and Requires Reboot of One Node If your GFS2 file system hangs and does not return commands run against it, but rebooting one specific node returns the system to normal, this may be indicative of a locking problem or bug. Should this occur, gather the following data: The GFS2 lock dump for the file system on each node: The DLM lock dump for the file system on each node: You can get this information with the dlm_tool : In this command, lsname is the lockspace name used by DLM for the file system in question. You can find this value in the output from the group_tool command. The output from the sysrq -t command. The contents of the /var/log/messages file. Once you have gathered that data, you can open a ticket with Red Hat Support and provide the data you have collected.

Commands:
cat /sys/kernel/debug/gfs2/ fsname /glocks >glocks. fsname . nodename
dlm_tool lockdebug -sv lsname .
Chapter 12. Supplementary ComputeNode Variant The following table lists all the packages in the Supplementary ComputeNode variant. For more information about support scope, see the Scope of Coverage Details document. Package Core Package? License java-1.5.0-ibm No IBM Binary Code License java-1.5.0-ibm-demo No IBM Binary Code License java-1.5.0-ibm-devel No IBM Binary Code License java-1.5.0-ibm-javacomm No IBM Binary Code License java-1.5.0-ibm-src No IBM Binary Code License java-1.6.0-ibm No IBM Binary Code License java-1.6.0-ibm-demo No IBM Binary Code License java-1.6.0-ibm-devel No IBM Binary Code License java-1.6.0-ibm-javacomm No IBM Binary Code License java-1.6.0-ibm-src No IBM Binary Code License java-1.7.1-ibm No IBM Binary Code License java-1.7.1-ibm-demo No IBM Binary Code License java-1.7.1-ibm-devel No IBM Binary Code License java-1.7.1-ibm-src No IBM Binary Code License java-1.8.0-ibm No IBM Binary Code License java-1.8.0-ibm-demo No IBM Binary Code License java-1.8.0-ibm-devel No IBM Binary Code License java-1.8.0-ibm-src No IBM Binary Code License system-switch-java No GPLv2+

Commands:
3.2. Installing Kerberos Kerberos packages may be installed by default, but make sure that the appropriate packages are installed for the Kerberos server or client being configured. To install packages for a Kerberos server: To install packages for a Kerberos client: If the Red Hat Enterprise Linux system will use Kerberos as part of single sign-on with smart cards, then also install the required PKI/OpenSSL package:

Commands:
yum install krb5-server krb5-libs krb5-auth-dialog
yum install krb5-workstation krb5-libs krb5-auth-dialog
yum install krb5-pkinit-openssl
Chapter 3. Configuring the Hot Rod C++ client Hot Rod C++ clients interact with remote Data Grid clusters via the RemoteCache API. 3.1. Configuration and Remote Cache Manager APIs Use the ConfigurationBuilder API to configure Hot Rod C++ client connections and the RemoteCacheManager API to obtain and configure remote caches. Configuration builder #include "infinispan/hotrod/ConfigurationBuilder.h" #include "infinispan/hotrod/RemoteCacheManager.h" #include <infinispan/hotrod/RemoteCache.h> #include <iostream> int main () { ConfigurationBuilder builder; // Configure a cache manager to connect with Hot Rod version 2.8 builder.protocolVersion(Configuration::PROTOCOL_VERSION_28); // Connect to a server at localhost with the default port. builder.addServer().host("127.0.0.1").port(11222); // Create and start a RemoteCacheManager to interact with caches. RemoteCacheManager cacheManager(builder.build(), false); cacheManager.start(); ... } Cross-site replication ConfigurationBuilder builder; builder.addServer().host("127.0.0.1").port(11222); // Configure a remote cluster and node when using cross-site replication. builder.addCluster("NYC").addClusterNode("192.0.2.0", 11322); Near caching ConfigurationBuilder builder; builder.addServer().host("127.0.0.1").port(11222); // Enable near-caching for the client. builder.nearCache().mode(NearCacheMode::INVALIDATED).maxEntries(4); Additional resources Hot Rod C++ client API

Commands:
#include "infinispan/hotrod/ConfigurationBuilder.h" #include "infinispan/hotrod/RemoteCacheManager.h" #include <infinispan/hotrod/RemoteCache.h> #include <iostream> int main () { ConfigurationBuilder builder; // Configure a cache manager to connect with Hot Rod version 2.8 builder.protocolVersion(Configuration::PROTOCOL_VERSION_28); // Connect to a server at localhost with the default port. builder.addServer().host("127.0.0.1").port(11222); // Create and start a RemoteCacheManager to interact with caches. RemoteCacheManager cacheManager(builder.build(), false); cacheManager.start(); }
ConfigurationBuilder builder; builder.addServer().host("127.0.0.1").port(11222); // Configure a remote cluster and node when using cross-site replication. builder.addCluster("NYC").addClusterNode("192.0.2.0", 11322);
ConfigurationBuilder builder; builder.addServer().host("127.0.0.1").port(11222); // Enable near-caching for the client. builder.nearCache().mode(NearCacheMode::INVALIDATED).maxEntries(4);
Chapter 3. Enabling Linux control group version 2 (cgroup v2) You can enable Linux control group version 2 (cgroup v2) in your cluster by editing the node.config object. Enabling cgroup v2 in OpenShift Container Platform disables all cgroups version 1 controllers and hierarchies in your cluster. cgroup v1 is enabled by default. cgroup v2 is the version of the Linux cgroup API. cgroup v2 offers several improvements over cgroup v1, including a unified hierarchy, safer sub-tree delegation, new features such as Pressure Stall Information , and enhanced resource management and isolation. Important OpenShift Container Platform cgroups version 2 support is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . 3.1. Enabling Linux cgroup v2 during installation You can enable Linux control group version 2 (cgroup v2) when you install a cluster by creating installation manifests. Procedure Create or edit the node.config object to specify the v2 cgroup: apiVersion: config.openshift.io/v1 kind: Node metadata: name: cluster spec: cgroupMode: "v1" Create or edit the FeatureGate object to enable the TechPreviewNoUpgrade feature set: apiVersion: config.openshift.io/v1 kind: FeatureGate metadata: name: cluster spec: featureSet: "TechPreviewNoUpgrade" Proceed with the installation as usual. Additional resources Enabling OpenShift Container Platform features using FeatureGates OpenShift Container Platform installation overview

Commands:
apiVersion: config.openshift.io/v1 kind: Node metadata: name: cluster spec: cgroupMode: "v1"
apiVersion: config.openshift.io/v1 kind: FeatureGate metadata: name: cluster spec: featureSet: "TechPreviewNoUpgrade"
Authentication builds for Red Hat OpenShift 1.1 Understanding authentication at runtime Red Hat OpenShift Documentation Team

Commands:
apiVersion: v1 data: .dockerconfigjson: <pull_secret> 1 kind: Secret metadata: annotations: build.shipwright.io/referenced.secret: "true" 2 name: secret-docker type: kubernetes.io/dockerconfigjson
apiVersion: v1 kind: Secret metadata: name: secret-git-basic-auth annotations: build.shipwright.io/referenced.secret: "true" type: kubernetes.io/basic-auth 1 stringData: 2 username: <cleartext_username> password: <cleartext_password>
apiVersion: v1 kind: Secret metadata: name: secret-git-ssh-auth annotations: build.shipwright.io/referenced.secret: "true" type: kubernetes.io/ssh-auth 1 data: ssh-privatekey: | 2 # Insert ssh private key, base64 encoded
apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: buildah-golang-build spec: source: git: url: git@gitlab.com:userjohn/newtaxi.git cloneSecret: secret-git-ssh-auth
apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: buildah-golang-build spec: source: git: url: https://gitlab.com/userjohn/newtaxi.git cloneSecret: secret-git-basic-auth
oc --namespace <namespace> create secret docker-registry <container_registry_secret_name> --docker-server=<registry_host> \ 1 --docker-username=<username> \ 2 --docker-password=<password> \ 3 --docker-email=<email_address>
oc --namespace <namespace> annotate secrets <container_registry_secret_name> build.shipwright.io/referenced.secret='true'
apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: buildah-golang-build # output: image: <path_to_image> pushSecret: <container_registry_secret_name>
Chapter 5. Managing Ceph daemons As a storage administrator, you can manage Ceph daemons on the Red Hat Ceph Storage dashboard. 5.1. Daemon actions The Red Hat Ceph Storage dashboard allows you to start, stop, restart, and redeploy daemons. Note These actions are supported on all daemons except monitor and manager daemons. Prerequisites A running Red Hat Ceph Storage cluster. Dashboard is installed. At least one daemon is configured in the storage cluster. Procedure You can manage daemons two ways. From the Services page: From the dashboard navigation, go to Administration->Services . Expand the service with the daemon that will have the action run on. Note The row can be collapsed at any time. On the Daemons tab, select the row with the daemon. Note The Daemons table can be searched and filtered. Select the action that needs to be run on the daemon. The options are Start , Stop , Restart , and Redeploy . Figure 5.1. Managing daemons from Services From the Hosts page: From the dashboard navigation, go to Cluster->Hosts . On the Hosts List tab, expand the host row and select the host with the daemon to perform the action on. On the Daemons tab of the host, select the row with the daemon. Note The Daemons table can be searched and filtered. Select the action that needs to be run on the daemon. The options are Start , Stop , Restart , and Redeploy . Figure 5.2. Managing daemons from Hosts

Commands:
Chapter 14. LVM (Logical Volume Manager) LVM is a tool for logical volume management which includes allocating disks, striping, mirroring and resizing logical volumes. With LVM, a hard drive or set of hard drives is allocated to one or more physical volumes . LVM physical volumes can be placed on other block devices which might span two or more disks. The physical volumes are combined into logical volumes , with the exception of the /boot/ partition. The /boot/ partition cannot be on a logical volume group because the boot loader cannot read it. If the root ( / ) partition is on a logical volume, create a separate /boot/ partition which is not a part of a volume group. Since a physical volume cannot span over multiple drives, to span over more than one drive, create one or more physical volumes per drive. Figure 14.1. Logical Volumes The volume groups can be divided into logical volumes , which are assigned mount points, such as /home and / and file system types, such as ext2 or ext3. When "partitions" reach their full capacity, free space from the volume group can be added to the logical volume to increase the size of the partition. When a new hard drive is added to the system, it can be added to the volume group, and partitions that are logical volumes can be increased in size. Figure 14.2. Logical Volumes On the other hand, if a system is partitioned with the ext3 file system, the hard drive is divided into partitions of defined sizes. If a partition becomes full, it is not easy to expand the size of the partition. Even if the partition is moved to another hard drive, the original hard drive space has to be reallocated as a different partition or not used. Important This chapter on LVM/LVM2 focuses on the use of the LVM GUI administration tool, i.e. system-config-lvm . For comprehensive information on the creation and configuration of LVM partitions in clustered and non-clustered storage, refer to the Logical Volume Manager Administration guide also provided by Red Hat. In addition, the Installation Guide for Red Hat Enterprise Linux 6 also documents how to create and configure LVM logical volumes during installation. For more information, refer to the Create LVM Logical Volume section of the Installation Guide for Red Hat Enterprise Linux 6. 14.1. What is LVM2? LVM version 2, or LVM2, was the default for Red Hat Enterprise Linux 5, which uses the device mapper driver contained in the 2.6 kernel. LVM2 can be upgraded from versions of Red Hat Enterprise Linux running the 2.4 kernel.

Commands:
Chapter 12. Marshalling Marshalling is the process of converting Java objects into a format that is transferable over the wire. Unmarshalling is the reversal of this process where data read from a wire format is converted into Java objects. Red Hat JBoss Data Grid uses marshalling and unmarshalling to: transform data for relay to other JBoss Data Grid nodes within the cluster. transform data to be stored in underlying cache stores. Report a bug 12.1. About Marshalling Framework Red Hat JBoss Data Grid uses the JBoss Marshalling Framework to marshall and unmarshall Java POJO s. Using the JBoss Marshalling Framework offers a significant performance benefit, and is therefore used instead of Java Serialization. Additionally, the JBoss Marshalling Framework can efficiently marshall Java POJO s, including Java classes. The Java Marshalling Framework uses high performance java.io.ObjectOutput and java.io.ObjectInput implementations compared to the standard java.io.ObjectOutputStream and java.io.ObjectInputStream . Report a bug

Commands: