mtpti5iD/redhat-docs_dataset huggingface dataset:
7.4. Block I/O Tuning Techniques This section describes more techniques for tuning block I/O performance in virtualized environments. 7.4.1. Disk I/O Throttling When several virtual machines are running simultaneously, they can interfere with system performance by using excessive disk I/O. Disk I/O throttling in KVM provides the ability to set a limit on disk I/O requests sent from virtual machines to the host machine. This can prevent a virtual machine from over-utilizing shared resources and impacting the performance of other virtual machines. Disk I/O throttling can be useful in various situations, for example when guest virtual machines belonging to different customers are running on the same host, or when quality of service guarantees are given for different guests. Disk I/O throttling can also be used to simulate slower disks. I/O throttling can be applied independently to each block device attached to a guest and supports limits on throughput and I/O operations. Use the virsh blkdeviotune command to set I/O limits for a virtual machine: Device specifies a unique target name ( <target dev='name'/> ) or source file ( <source file='name'/> ) for one of the disk devices attached to the virtual machine. Use the virsh domblklist command for a list of disk device names. Optional parameters include: total-bytes-sec The total throughput limit in bytes per second. read-bytes-sec The read throughput limit in bytes per second. write-bytes-sec The write throughput limit in bytes per second. total-iops-sec The total I/O operations limit per second. read-iops-sec The read I/O operations limit per second. write-iops-sec The write I/O operations limit per second. For example, to throttle vda on virtual_machine to 1000 I/O operations per second and 50 MB per second throughput, run this command: 7.4.2. Multi-Queue virtio-scsi Multi-queue virtio-scsi provides improved storage performance and scalability in the virtio-scsi driver. It enables each virtual CPU to have a separate queue and interrupt to use without affecting other vCPUs. 7.4.2.1. Configuring Multi-Queue virtio-scsi Multi-queue virtio-scsi is disabled by default on Red Hat Enterprise Linux 7. To enable multi-queue virtio-scsi support in the guest, add the following to the guest XML configuration, where N is the total number of vCPU queues:

Commands:
virsh blkdeviotune virtual_machine device --parameter limit
virsh blkdeviotune virtual_machine vda --total-iops-sec 1000 --total-bytes-sec 52428800
<controller type='scsi' index='0' model='virtio-scsi'> <driver queues=' N ' /> </controller>
7.230. smartmontools 7.230.1. RHBA-2013:0365 - smartmontools bug fix and enhancement update Updated smartmontools packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The smartmontools packages provide the smartctl tool and the smartd daemon to control and monitor storage systems using the Self-Monitoring, Analysis and Reporting Technology System (SMART) built into most modern ATA and SCSI hard disks. Note The smartmontools packages have been upgraded to upstream version 5.43, which provides a number of bug fixes and enhancements over the version. (BZ#826144) All users of smartmontools are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 5. Troubleshooting Software Collections This chapter helps you troubleshoot some of the common issues you can encounter when building your Software Collections. 5.1. Error: line XX : Unknown tag: %scl_package software_collection_name You can encounter this error message when building a Software Collection package. It is usually caused by a missing package scl-utils-build . To install the scl-utils-build package, run the following command: For more information, see Section 1.3, "Enabling Support for Software Collections" .

Commands:
yum install scl-utils-build
Chapter 13. Managing Red Hat Gluster Storage Volume Life-Cycle Extensions Red Hat Gluster Storage allows automation of operations by user-written scripts. For every operation, you can execute a pre and a post script. Pre Scripts : These scripts are run before the occurrence of the event. You can write a script to automate activities like managing system-wide services. For example, you can write a script to stop exporting the SMB share corresponding to the volume before you stop the volume. Post Scripts : These scripts are run after execution of the event. For example, you can write a script to export the SMB share corresponding to the volume after you start the volume. You can run scripts for the following events: Creating a volume Starting a volume Adding a brick Removing a brick Tuning volume options Stopping a volume Deleting a volume Naming Convention While creating the file names of your scripts, you must follow the naming convention followed in your underlying file system like XFS. Note To enable the script, the name of the script must start with an S . Scripts run in lexicographic order of their names. 13.1. Location of Scripts This section provides information on the folders where the scripts must be placed. When you create a trusted storage pool, the following directories are created: /var/lib/glusterd/hooks/1/create/ /var/lib/glusterd/hooks/1/delete/ /var/lib/glusterd/hooks/1/start/ /var/lib/glusterd/hooks/1/stop/ /var/lib/glusterd/hooks/1/set/ /var/lib/glusterd/hooks/1/add-brick/ /var/lib/glusterd/hooks/1/remove-brick/ After creating a script, you must ensure to save the script in its respective folder on all the nodes of the trusted storage pool. The location of the script dictates whether the script must be executed before or after an event. Scripts are provided with the command line argument --volname= VOLNAME to specify the volume. Command-specific additional arguments are provided for the following volume operations: Start volume --first=yes , if the volume is the first to be started --first=no , for otherwise Stop volume --last=yes , if the volume is to be stopped last. --last=no , for otherwise Set volume -o key=value For every key, value is specified in volume set command.

Commands:
Appendix A. Component Versions This appendix provides a list of key components and their versions in the Red Hat Enterprise Linux 7.4 release. Table A.1. Component Versions Component Version Kernel 3.10.0-693 QLogic qla2xxx driver 8.07.00.38.07.4-k1 QLogic qla4xxx driver 5.04.00.00.07.02-k0 Emulex lpfc driver 0:11.2.0.6 iSCSI initiator utils iscsi-initiator-utils-6.2.0.874-4 DM-Multipath device-mapper-multipath-0.4.9-111 LVM lvm2-2.02.171-8

Commands:
Chapter 1. Preface Red Hat Ceph Storage supports Light-weight Directory Access Protocol (LDAP) servers for authenticating Ceph Object Gateway users. Configuring a cluster for use with LDAP requires the following: A Ceph Object Gateway server and Ceph Storage cluster. An LDAP server. An SSL certificate for LDAPS. An LDAP user for authenticating the Ceph Object Gateway. At least one LDAP user for authenticating S3 clients.

Commands:
Chapter 1. Installation Overview Installing a standalone Manager environment with remote databases involves the following steps: Install and configure the Red Hat Virtualization Manager: Install two Red Hat Enterprise Linux machines: one for the Manager, and one for the databases. The second machine will be referred to as the remote server. Register the Manager machine with the Content Delivery Network and enable the Red Hat Virtualization Manager repositories. Manually configure the Manager database on the remote server. You can also use this procedure to manually configure the Data Warehouse database if you do not want the Data Warehouse setup script to configure it automatically. Configure the Red Hat Virtualization Manager using engine-setup . Install the Data Warehouse service and database on the remote server. If you want to use the websocket proxy to allow users to connect to virtual machines through the noVNC console, install it on the remote server. Connect to the Administration Portal to add hosts and storage domains. Install hosts to run virtual machines on: Use either host type, or both: Red Hat Virtualization Host Red Hat Enterprise Linux Add the hosts to the Manager. Prepare storage to use for storage domains. You can use one of the following storage types: NFS iSCSI Fibre Channel (FCP) POSIX-compliant file system Local storage Red Hat Gluster Storage Add storage domains to the Manager. Important Keep the environment up to date. See https://access.redhat.com/articles/2974891 for more information. Since bug fixes for known issues are frequently released, Red Hat recommends using scheduled tasks to update the hosts and the Manager.

Commands:
25.9. Testing The Certificate To test the test certificate installed by default, either a CA-signed certificate, or a self-signed certificate, point your Web browser to the following home page (replacing server.example.com with your domain name): Note Note the s after http . The https: prefix is used for secure HTTP transactions. If you are using a CA-signed certificate from a well-known CA, your browser probably automatically accepts the certificate (without prompting you for input) and creates the secure connection. Your browser does not automatically recognize a test or a self-signed certificate, because the certificate is not signed by a CA. If you are not using a certificate from a CA, follow the instructions provided by your browser to accept the certificate. Once your browser accepts the certificate, your secure server displays a default home page.

Commands:
https:// server.example.com
Chapter 13. Lifecyle bucket configuration in Multicloud Object Gateway Multicloud Object Gateway (MCG) lifecycle provides a way to reduce storage costs due to accumulated data objects. Deletion of expired objects is a simplified way that enables handling of unused data. Data expiration is a part of Amazon Web Services (AWS) lifecycle management and sets an expiration date for automatic deletion. The minimal time resolution of the lifecycle expiration is one day. For more information, see Expiring objects . AWS S3 API is used to configure lifecyle bucket in MCG. For information about the data bucket APIs and their support level, see Support of Multicloud Object Gateway data bucket APIs . There are a few limitations with the expiratation rule API for MCG in comaparison with AWS: ExpiredObjectDeleteMarker is accepted but it is not processed. No option to define specific non-current version's expiration conditions

Commands:
3.3.2. Option: CPU Configuration Use this option to select the CPU configuration type, based on the desired CPU model. Expand the list to see available options, or click the Copy host CPU configuration button to detect and apply the physical host's CPU model and configuration. Once you select a CPU configuration, its available CPU features/instructions are displayed and can be individually enabled/disabled in the CPU Features list. Refer to the following diagram which shows these options: Figure 3.5. CPU Configuration Options Note Copying the host CPU configuration is recommended over manual configuration. Note Alternately, run the virsh capabilities command on your host machine to view the virtualization capabilities of your system, including CPU types and NUMA capabilities.

Commands:
Part IV. Deprecated Functionality This part provides an overview of functionality that has been deprecated in all minor releases of Red Hat Enterprise Linux 7 up to Red Hat Enterprise Linux 7.2. Deprecated functionality continues to be supported until the end of life of Red Hat Enterprise Linux 7. Deprecated functionality will likely not be supported in future major releases of this product and is not recommended for new deployments. For the most recent list of deprecated functionality within a particular major release, refer to the latest version of release documentation. Deprecated hardware components are not recommended for new deployments on the current or future major releases. Hardware driver updates are limited to security and critical fixes only. Red Hat recommends replacing this hardware as soon as reasonably feasible. A package can be deprecated and not recommended for further use. Under certain circumstances, a package can be removed from a product. Product documentation then identifies more recent packages that offer functionality similar, identical, or more advanced to the one deprecated, and provides further recommendations.

Commands:
Chapter 6. Security 6.1. Connecting with a user and password AMQ .NET can authenticate connections with a user and password. To specify the credentials used for authentication, set the user and password fields in the connection URL. Example: Connecting with a user and password Address addr = new Address("amqp:// <user> : <password> @example.com"); Connection conn = new Connection(addr); 6.2. Configuring SASL authentication Client connections to remote peers may exchange SASL user name and password credentials. The presence of the user field in the connection URI controls this exchange. If user is specified then SASL credentials are exchanged; if user is absent then the SASL credentials are not exchanged. By default the client supports EXTERNAL , PLAIN , and ANONYMOUS SASL mechanisms. 6.3. Configuring an SSL/TLS transport Secure communication with servers is achieved using SSL/TLS. A client may be configured for SSL/TLS Handshake only or for SSL/TLS Handshake and client certificate authentication. See the Managing Certificates section for more information. Note TLS Server Name Indication (SNI) is handled automatically by the client library. However, SNI is signaled only for addresses that use the amqps transport scheme where the host is a fully qualified domain name or a host name. SNI is not signaled when the host is a numeric IP address.

Commands:
Address addr = new Address("amqp:// <user> : <password> @example.com"); Connection conn = new Connection(addr);
Appendix A. Using your subscription Streams for Apache Kafka is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Streams for Apache Kafka for Apache Kafka entries in the INTEGRATION AND AUTOMATION category. Select the desired Streams for Apache Kafka product. The Software Downloads page opens. Click the Download link for your component. Installing packages with DNF To install a package and all the package dependencies, use: dnf install <package_name> To install a previously-downloaded package from a local directory, use: dnf install <path_to_download_package> Revised on 2024-05-30 17:22:50 UTC

Commands:
dnf install <package_name>
dnf install <path_to_download_package>
Chapter 100. KafkaUserSpec schema reference Used in: KafkaUser Property Description authentication Authentication mechanism enabled for this Kafka user. The supported authentication mechanisms are scram-sha-512 , tls , and tls-external . scram-sha-512 generates a secret with SASL SCRAM-SHA-512 credentials. tls generates a secret with user certificate for mutual TLS authentication. tls-external does not generate a user certificate. But prepares the user for using mutual TLS authentication using a user certificate generated outside the User Operator. ACLs and quotas set for this user are configured in the CN=<username> format. Authentication is optional. If authentication is not configured, no credentials are generated. ACLs and quotas set for the user are configured in the <username> format suitable for SASL authentication. The type depends on the value of the authentication.type property within the given object, which must be one of [tls, tls-external, scram-sha-512]. KafkaUserTlsClientAuthentication , KafkaUserTlsExternalClientAuthentication , KafkaUserScramSha512ClientAuthentication authorization Authorization rules for this Kafka user. The type depends on the value of the authorization.type property within the given object, which must be one of [simple]. KafkaUserAuthorizationSimple quotas Quotas on requests to control the broker resources used by clients. Network bandwidth and request rate quotas can be enforced.Kafka documentation for Kafka User quotas can be found at http://kafka.apache.org/documentation/#design_quotas . KafkaUserQuotas template Template to specify how Kafka User Secrets are generated. KafkaUserTemplate

Commands:
4.17. Hewlett-Packard iLO MP Table 4.18, "HP iLO (Integrated Lights Out) MP" lists the fence device parameters used by fence_ilo_mp , the fence agent for HP iLO MP devices. Table 4.18. HP iLO (Integrated Lights Out) MP luci Field cluster.conf Attribute Description Name name A name for the server with HP iLO support. IP Address or Hostname ipaddr The IP address or host name assigned to the device. IP Port (optional) ipport TCP port to use for connection with the device. 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. 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. Force Command Prompt cmd_prompt The command prompt to use. The default value is 'MP>', 'hpiLO->'. Power Wait (seconds) power_wait Number of seconds to wait after issuing a power off or power on command. Delay (seconds) delay The number of seconds to wait before fencing is started. The default value is 0. 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. Figure 4.13, "HP iLO MP" shows the configuration screen for adding an HP iLO MPfence device. Figure 4.13. HP iLO MP The following command creates a fence device instance for a HP iLO MP device: The following is the cluster.conf entry for the fence_hpilo_mp device:

Commands:
ccs -f cluster.conf --addfencedev hpilomptest1 agent=fence_hpilo cmd_prompt=hpiLO-> ipaddr=192.168.0.1 login=root passwd=password123 power_wait=60
<fencedevices> <fencedevice agent="fence_ilo_mp" cmd_prompt="hpiLO-&gt;" ipaddr="192.168.0.1" login="root" name="hpilomptest1" passwd="password123" power_wait="60"/> </fencedevices>
Chapter 8. Post-update configuration changes for clusters backed by local storage In Red Hat OpenShift Container Platform 4.6 and onward, the Local Storage Operator provides new custom resource types for managing local storage: LocalVolumeDiscovery LocalVolumeSet If you have incrementally upgraded to OpenShift Data Foundation version 4.9 from version 4.5 or earlier with Local Storage Operator, and these resources have not yet been created, additional configuration steps are required after an update to ensure that all features work as expected. These resource types are not automatically handled as part of an update from 4.5, and must be created manually. See Post-update configuration changes for clusters backed by local storage for instructions on creating the resources. Note If you had already created these resources after upgrading from 4.5, then you do not need to create them after upgrading to 4.9. 8.1. Adding annotations You need to add annotations to the storage cluster to enable replacing of failed storage devices through the user interface when you upgraded to OpenShift Data Foundation version 4.9 from a version. Procedure Log in to the OpenShift Container Platform Web Console. Click Home Search . Search for StorageCluster in Resources and click on it. Beside ocs-storagecluster , click Action menu (...) Edit annotations . Add cluster.ocs.openshift.io/local-devices and true for KEY and VALUE respectively. Click Save .

Commands:
Preface Red Hat OpenShift Data Foundation 4.9 supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) Google Cloud clusters. Note Only internal OpenShift Data Foundation clusters are supported on Google Cloud. See Planning your deployment for more information about deployment requirements. To deploy OpenShift Data Foundation in internal mode, start with the requirements in Preparing to deploy OpenShift Data Foundation chapter and follow the appropriate deployment process based on your requirement: Deploy OpenShift Data Foundation on Google Cloud Deploy standalone Multicloud Object Gateway component

Commands:
Chapter 3. Red Hat build of OpenJDK 8.0.345 release notes Review the following release note for an overview of changes from the Red Hat build of OpenJDK 8.0.345 patch release: Reverted disablement of changing the user.dir property In the Red Hat build of OpenJDK 8.0.342 release, the ability to edit the user.dir property was disabled. This change originated in the Red Hat build of OpenJDK 11 release. In the Red Hat build of OpenJDK 8.0.345 release, this change is reverted because of a possible impact to software that relies on settings made in earlier versions of Red Hat build of OpenJDK 8, which supported edits to the user.dir property. In the Red Hat build of OpenJDK 8.0.345 release, you can again make changes to user.dir property. See, JDK-8290832 (JDK Bug System)

Commands:
Chapter 7. Installing and Configuring Certificate System Red Hat Certificate System provides different subsystems that can be installed individually. For example, you can install multiple subsystem instances on a single server or you can run them independently on different hosts. This enables you to adapt the installation to your environment to provide a higher availability, scalability, and fail-over support. This chapter describes the package installation and how to set up the individual subsystems. The Certificate System includes the following subsystems: Certificate Authority (CA) Key Recovery Authority (KRA) Online Certificate Status Protocol (OCSP) Responder Token Key Service (TKS) Token Processing System (TPS) Each subsystem is installed and configured individually as a standalone Tomcat web server instance. However, Red Hat Certificate System additionally supports running a single shared Tomcat web server instance that can contain up to one of each subsystem. 7.1. Subsystem Configuration Order The order in which the individual subsystems are set up is important because of relationships between the different subsystems: At least one CA running as a security domain is required before any of the other public key infrastructure (PKI) subsystems can be installed. Install the OCSP after the CA has been configured. The KRA, and TKS subsystems can be installed in any order, after the CA and OCSP have been configured. The TPS subsystem depends on the CA and TKS, and optionally on the KRA and OCSP subsystem. Note In certain situations, administrators want to install a standalone KRA or OCSP which do not require a CA running as a security domain. For details, see Section 7.9, "Setting up a Standalone KRA or OCSP" .

Commands: