mtpti5iD/redhat-docs_dataset huggingface dataset:
Appendix A. Using your subscription Integration 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 . Scroll down to INTEGRATION AND AUTOMATION . Click Red Hat Integration to display the Red Hat Integration downloads page. Click the Download link for your component. Revised on 2023-11-17 04:11:22 UTC

Commands:
5.9. Scheduling In Red Hat Virtualization, scheduling refers to the way the Red Hat Virtualization Manager selects a host in a cluster as the target for a new or migrated virtual machine. For a host to be eligible to start a virtual machine or accept a migrated virtual machine from another host, it must have enough free memory and CPUs to support the requirements of the virtual machine being started on or migrated to it. A virtual machine will not start on a host with an overloaded CPU. By default, a host's CPU is considered overloaded if it has a load of more than 80% for 5 minutes, but these values can be changed using scheduling policies. If multiple hosts are eligible targets, one will be selected based on the load balancing policy for the cluster. For example, if the Evenly_Distributed policy is in effect, the Manager chooses the host with the lowest CPU utilization. If the Power_Saving policy is in effect, the host with the lowest CPU utilization between the maximum and minimum service levels will be selected. The Storage Pool Manager (SPM) status of a given host also affects eligibility as a target for starting virtual machines or virtual machine migration. A non-SPM host is a preferred target host, for instance, the first virtual machine started in a cluster will not run on the SPM host if the SPM role is held by a host in that cluster.

Commands:
6.8. RHEA-2013:0342 - new packages: libitm New libitm packages are now available for Red Hat Enterprise Linux 6. The libitm packages contain the GNU Transactional Memory runtime library that provides GCC transactional memory support. This enhancement update adds the libitm packages to Red Hat Enterprise Linux 6. (BZ#813301) All users who require libitm are advised to install these new packages.

Commands:
Appendix A. Working with files encrypted using Ansible Vault Red Hat recommends encrypting the contents of deployment and management files that contain passwords and other sensitive information. Ansible Vault is one method of encrypting these files. More information about Ansible Vault is available in the Ansible documentation . A.1. Encrypting files You can create an encrypted file by using the ansible-vault create command, or encrypt an existing file by using the ansible-vault encrypt command. When you create an encrypted file or encrypt an existing file, you are prompted to provide a password. This password is used to decrypt the file after encryption. You must provide this password whenever you work directly with information in this file or run a playbook that relies on the file's contents. Creating an encrypted file The ansible-vault create command prompts for a password for the new file, then opens the new file in the default text editor (defined as USDEDITOR in your shell environment) so that you can populate the file before saving it. If you have already created a file and you want to encrypt it, use the ansible-vault encrypt command. Encrypting an existing file A.2. Editing encrypted files You can edit an encrypted file using the ansible-vault edit command and providing the Vault password for that file. Editing an encrypted file The ansible-vault edit command prompts for a password for the file, then opens the file in the default text editor (defined as USDEDITOR in your shell environment) so that you can edit and save the file contents. A.3. Rekeying encrypted files to a new password You can change the password used to decrypt a file by using the ansible-vault rekey command. The ansible-vault rekey command prompts for the current Vault password, and then prompts you to set and confirm a new Vault password.

Commands:
ansible-vault create variables.yml New Vault password: Confirm New Vault password:
ansible-vault encrypt existing-variables.yml New Vault password: Confirm New Vault password: Encryption successful
ansible-vault edit variables.yml New Vault password: Confirm New Vault password:
ansible-vault rekey variables.yml Vault password: New Vault password: Confirm New Vault password: Rekey successful
Chapter 3. Introduction to Teiid Designer 3.1. Why Use Teiid Designer? Teiid Designer allows you map data sources to target formats. It also lets you do the following: resolve semantic differences create virtual data structures at a physical or logical level use declarative interfaces to integrate, aggregate, and transform the data on its way from source to target formats which is compatible and optimized for consumption by your applications It allows you to abstract the structure of the information you use in your applications from the underlying physical data structures. With Teiid Designer, data services are defined quickly, the resulting artifacts are easy to maintain and reuse, and all the valuable work and related metadata are saved for later reference. You can also use Teiid Designer to integrate multiple sources, and access them using these common data access standards: Web Services/SOAP/XML JDBC/SQL ODBC/SQL

Commands:
Chapter 11. Viewing and managing JMX domains and MBeans Java Management Extensions (JMX) is a Java technology that allows you to manage resources (services, devices, and applications) dynamically at runtime. The resources are represented by objects called MBeans (for Managed Bean). You can manage and monitor resources as soon as they are created, implemented, or installed. With the JMX plugin on HawtIO, you can view and manage JMX domains and MBeans. You can view MBean attributes, run commands, and create charts that show statistics for the MBeans. The JMX tab provides a tree view of the active JMX domains and MBeans organized in folders. You can view details and execute commands on the MBeans. Procedure : To view and edit MBean attributes : In the tree view, select an MBean. Click the Attributes tab. Click an attribute to see its details. To perform operations : In the tree view, select an MBean. Click the Operations tab, expand one of the listed operations. Click Execute to run the operation. To view charts : In the tree view, select an item. Click the Chart tab.

Commands:
23.3. Standards This section describes I/O standards used by ATA and SCSI devices. ATA ATA devices must report appropriate information via the IDENTIFY DEVICE command. ATA devices only report I/O parameters for physical_block_size , logical_block_size , and alignment_offset . The additional I/O hints are outside the scope of the ATA Command Set. SCSI I/O parameters support in Red Hat Enterprise Linux 6 requires at least version 3 of the SCSI Primary Commands (SPC-3) protocol. The kernel will only send an extended inquiry (which gains access to the BLOCK LIMITS VPD page) and READ CAPACITY(16) command to devices which claim compliance with SPC-3. The READ CAPACITY(16) command provides the block sizes and alignment offset: LOGICAL BLOCK LENGTH IN BYTES is used to derive /sys/block/ disk /queue/physical_block_size LOGICAL BLOCKS PER PHYSICAL BLOCK EXPONENT is used to derive /sys/block/ disk /queue/logical_block_size LOWEST ALIGNED LOGICAL BLOCK ADDRESS is used to derive: /sys/block/ disk /alignment_offset /sys/block/ disk / partition /alignment_offset The BLOCK LIMITS VPD page ( 0xb0 ) provides the I/O hints. It also uses OPTIMAL TRANSFER LENGTH GRANULARITY and OPTIMAL TRANSFER LENGTH to derive: /sys/block/ disk /queue/minimum_io_size /sys/block/ disk /queue/optimal_io_size The sg3_utils package provides the sg_inq utility, which can be used to access the BLOCK LIMITS VPD page. To do so, run:

Commands:
sg_inq -p 0xb0 disk
Chapter 163. StrimziPodSet schema reference Full list of StrimziPodSet schema properties Important StrimziPodSet is an internal Streams for Apache Kafka resource. Information is provided for reference only. Do not create, modify or delete StrimziPodSet resources as this might cause errors. 163.1. StrimziPodSet schema properties Property Property type Description spec StrimziPodSetSpec The specification of the StrimziPodSet. status StrimziPodSetStatus The status of the StrimziPodSet.

Commands:
probe::tty.resize Name probe::tty.resize - Called when a terminal resize happens Synopsis Values new_ypixel the new ypixel value old_col the old col value old_xpixel the old xpixel old_ypixel the old ypixel name the tty name old_row the old row value new_row the new row value new_xpixel the new xpixel value new_col the new col value

Commands:
tty.resize
Chapter 49. Storage Multi-queue I/O scheduling for SCSI Red Hat Enterprise Linux 7 includes a new multiple-queue I/O scheduling mechanism for block devices known as blk-mq. The scsi-mq package allows the Small Computer System Interface (SCSI) subsystem to make use of this new queuing mechanism. This functionality is provided as a Technology Preview and is not enabled by default. To enable it, add scsi_mod.use_blk_mq=Y to the kernel command line. Although blk-mq is intended to offer improved performance, particularly for low-latency devices, it is not guaranteed to always provide better performance. In particular, in some cases, enabling scsi-mq can result in significantly worse performance, especially on systems with many CPUs. (BZ#1109348) Targetd plug-in from the libStorageMgmt API Since Red Hat Enterprise Linux 7.1, storage array management with libStorageMgmt, a storage array independent API, has been fully supported. The provided API is stable, consistent, and allows developers to programmatically manage different storage arrays and utilize the hardware-accelerated features provided. System administrators can also use libStorageMgmt to manually configure storage and to automate storage management tasks with the included command-line interface. The Targetd plug-in is not fully supported and remains a Technology Preview. (BZ#1119909) Support for Data Integrity Field/Data Integrity Extension (DIF/DIX) DIF/DIX is a new addition to the SCSI Standard. It is fully supported in Red Hat Enterprise Linux 7 for the HBAs and storage arrays specified in the Features chapter, but it remains in Technology Preview for all other HBAs and storage arrays. DIF/DIX increases the size of the commonly used 512 byte disk block from 512 to 520 bytes, adding the Data Integrity Field (DIF). The DIF stores a checksum value for the data block that is calculated by the Host Bus Adapter (HBA) when a write occurs. The storage device then confirms the checksum on receipt, and stores both the data and the checksum. Conversely, when a read occurs, the checksum can be verified by the storage device, and by the receiving HBA. (BZ#1072107)

Commands:
Chapter 2. Enabling the Argo CD plugin You can use the Argo CD plugin to visualize the Continuous Delivery (CD) workflows in OpenShift GitOps. This plugin provides a visual overview of the application's status, deployment details, commit message, author of the commit, container image promoted to environment and deployment history. Prerequisites Add Argo CD instance information to your app-config.yaml configmap as shown in the following example: argocd: appLocatorMethods: - type: 'config' instances: - name: argoInstance1 url: https://argoInstance1.com username: USD{ARGOCD_USERNAME} password: USD{ARGOCD_PASSWORD} - name: argoInstance2 url: https://argoInstance2.com username: USD{ARGOCD_USERNAME} password: USD{ARGOCD_PASSWORD} Add the following annotation to the entity's catalog-info.yaml file to identify the Argo CD applications. annotations: ... # The label that Argo CD uses to fetch all the applications. The format to be used is label.key=label.value. For example, rht-gitops.com/janus-argocd=quarkus-app. argocd/app-selector: 'USD{ARGOCD_LABEL_SELECTOR}' (Optional) Add the following annotation to the entity's catalog-info.yaml file to switch between Argo CD instances as shown in the following example: annotations: ... # The Argo CD instance name used in `app-config.yaml`. argocd/instance-name: 'USD{ARGOCD_INSTANCE}' Note If you do not set this annotation, the Argo CD plugin defaults to the first Argo CD instance configured in app-config.yaml . Procedure Add the following to your dynamic-plugins ConfigMap to enable the Argo CD plugin. global: dynamic: includes: - dynamic-plugins.default.yaml plugins: - package: ./dynamic-plugins/dist/roadiehq-backstage-plugin-argo-cd-backend-dynamic disabled: false - package: ./dynamic-plugins/dist/backstage-community-plugin-redhat-argocd disabled: false Additional resources The package path, scope, and name of the Red Hat ArgoCD plugin has changed since 1.2. For more information, see Breaking Changes in the Release notes for Red Hat Developer Hub . For more information on installing dynamic plugins, see Installing and viewing dynamic plugins .

Commands:
argocd: appLocatorMethods: - type: 'config' instances: - name: argoInstance1 url: https://argoInstance1.com username: USD{ARGOCD_USERNAME} password: USD{ARGOCD_PASSWORD} - name: argoInstance2 url: https://argoInstance2.com username: USD{ARGOCD_USERNAME} password: USD{ARGOCD_PASSWORD}
annotations: # The label that Argo CD uses to fetch all the applications. The format to be used is label.key=label.value. For example, rht-gitops.com/janus-argocd=quarkus-app. argocd/app-selector: 'USD{ARGOCD_LABEL_SELECTOR}'
annotations: # The Argo CD instance name used in `app-config.yaml`. argocd/instance-name: 'USD{ARGOCD_INSTANCE}'
global: dynamic: includes: - dynamic-plugins.default.yaml plugins: - package: ./dynamic-plugins/dist/roadiehq-backstage-plugin-argo-cd-backend-dynamic disabled: false - package: ./dynamic-plugins/dist/backstage-community-plugin-redhat-argocd disabled: false
Chapter 10. Querying domain information using SSSD Security System Services Daemon (SSSD) can list domains in Identity Management (IdM) as well as the domains in Active Directory that is connected to IdM by a cross-forest trust. 10.1. Listing domains using sssctl You can use the sssctl domain-list command to debug problems with the domain topology. Note The status might not be available immediately. If the domain is not visible, repeat the command. Prerequisites You must be logged in with administrator privileges The sssctl tool is available on RHEL 7, RHEL 8, and RHEL 9 systems. Procedure To display help for the sssctl command, enter: To display a list of available domains, enter: The list includes domains in the cross-forest trust between Active Directory and Identity Management. 10.2. Verifying the domain status using sssctl You can use the sssctl domain-status command to debug problems with the domain topology. Note The status might not be available immediately. If the domain is not visible, repeat the command. Prerequisites You must be logged in with administrator privileges The sssctl tool is available on RHEL 7, RHEL 8, and RHEL 9 systems. Procedure To display help for the sssctl command, enter: To display user data for a particular domain, enter: The domain idm.example.com is online and visible from the client where you applied the command. If the domain is not available, the result is:

Commands:
sssctl --help .
sssctl domain-list implicit_files idm.example.com ad.example.com sub1.ad.example.com
sssctl --help
sssctl domain-status idm.example.com Online status: Online Active servers: IPA: server.idm.example.com Discovered IPA servers: - server.idm.example.com
sssctl domain-status ad.example.com Unable to get online status
A.8. Using the VDSM Hooking Module VDSM ships with a Python hooking module, providing helper functions for VDSM hook scripts. This module is provided as an example, and is only relevant to VDSM hooks written in Python. The hooking module supports reading of a virtual machine's libvirt XML into a DOM object. Hook scripts can then use Python's built-in xml.dom library to manipulate the object. The modified object can then be saved back to libvirt XML using the hooking module. The hooking module provides the following functions to support hook development: Table A.2. Hooking module functions Name Argument Description tobool string Converts a string "true" or "false" to a Boolean value read_domxml - Reads the virtual machine's libvirt XML into a DOM object write_domxml DOM object Writes the virtual machine's libvirt XML from a DOM object

Commands:
Chapter 2. Architectures Red Hat Enterprise Linux 9 is distributed with the kernel version 5.14, which provides support for the following architectures at the minimum required version: AMD and Intel 64-bit architectures (x86-64-v2) The 64-bit ARM architecture (ARMv8.0-A) IBM Power Systems, Little Endian (POWER9) 64-bit IBM Z (z14) Make sure you purchase the appropriate subscription for each architecture. Additional resources Removed for the time being until the decision about a KCS is made!!! Get Started with Red Hat Enterprise Linux - additional architectures

Commands:
Storage Administration Guide Red Hat Enterprise Linux 6 Deploying and configuring single-node storage in Red Hat Enterprise Linux 6 Edited by Marek Suchanek Red Hat Customer Content Services msuchane@redhat.com Milan Navratil Red Hat Customer Content Services Jacquelynn East Red Hat Customer Content Services Don Domingo Red Hat Customer Content Services Red Hat Subject Matter Experts Kamil Dudka Access Control Lists Base Operating System Core Services kdudka@redhat.com Doug Ledford RAID Server Development Hardware Enablement dledford@redhat.com Nathan Straz GFS2 Quality Engineering QE - Platform nstraz@redhat.com Contributors Sachin Prabhu NFS Software Maintenance Engineering sprabhu@redhat.com Rob Evers Online Storage Server Development Kernel Storage revers@redhat.com David Howells FS-Cache Server Development Hardware Enablement dhowells@redhat.com David Lehman Storage configuration during installation Base Operating System Installer dlehman@redhat.com Jeff Moyer Solid-State Disks Server Development Kernel File System jmoyer@redhat.com Eric Sandeen ext3, ext4, XFS, Encrypted File Systems Server Development Kernel File System esandeen@redhat.com Mike Snitzer I/O Stack and Limits Server Development Kernel Storage msnitzer@redhat.com Josef Bacik Disk Quotas Server Development Kernel File System David Wysochanski Server Development Kernel Storage Hans de Goede Base Operating System Installer Michael Christie Server Development Kernel Storage Daniel Novotny Base Operating System Core Services

Commands:
8.3.3.3. Enabling 1 GB huge pages for guests at boot or runtime Red Hat Enterprise Linux 6.7 systems support 2 MB and 1 GB huge pages, which can be allocated at boot or at runtime. Procedure 8.2. Allocating 1 GB huge pages at boot time To allocate different sizes of huge pages at boot, use the following command, specifying the number of huge pages. This example allocates 4 1 GB huge pages and 1024 2 MB huge pages: Change this command line to specify a different number of huge pages to be allocated at boot. Note The two steps must also be completed the first time you allocate 1 GB huge pages at boot time. Mount the 2 MB and 1 GB huge pages on the host: Restart libvirtd to enable the use of 1 GB huge pages on guests: 1 GB huge pages are now available for guests. Procedure 8.3. Allocating 1 GB huge pages at runtime 1 GB huge pages can also be allocated at runtime. Runtime allocation allows the system administrator to choose which NUMA node to allocate those pages from. However, runtime page allocation can be more prone to allocation failure than boot time allocation due to memory fragmentation. To allocate different sizes of huge pages at runtime, use the following command, replacing values for the number of huge pages, the NUMA node to allocate them from, and the huge page size: This example command allocates 4 1 GB huge pages from node1 and 1024 2MB huge pages from node3 . These huge page settings can be changed at any time with the above command, depending on the amount of free memory on the host system. Note The two steps must also be completed the first time you allocate 1 GB huge pages at runtime. Mount the 2 MB and 1 GB huge pages on the host: Restart libvirtd to enable the use of 1 GB huge pages on guests:

Commands:
'default_hugepagesz=1G hugepagesz=1G hugepages=4 hugepagesz=2M hugepages=1024'
mkdir /dev/hugepages1G mount -t hugetlbfs -o pagesize=1G none /dev/hugepages1G mkdir /dev/hugepages2M mount -t hugetlbfs -o pagesize=2M none /dev/hugepages2M
service restart libvirtd
echo 4 > /sys/devices/system/node/node1/hugepages/hugepages-1048576kB/nr_hugepages echo 1024 > /sys/devices/system/node/node3/hugepages/hugepages-2048kB/nr_hugepages
mkdir /dev/hugepages1G mount -t hugetlbfs -o pagesize=1G none /dev/hugepages1G mkdir /dev/hugepages2M mount -t hugetlbfs -o pagesize=2M none /dev/hugepages2M
systemctl restart libvirtd
11.13. Options Options can be provided for several commands. See "options clause" in Section A.7, "Productions" . Note Any option name of the form prefix:key will attempt to be resolved against the current set of namespaces. Failure to resolve will result in the option name being left as is. A resolved name will be replaced with {uri}key. See also Namespaces for Extension Metadata. Options can also be added using the ALTER statement.

Commands: