mtpti5iD/redhat-docs_dataset huggingface dataset:
3.5. Example: List Host Collection This example uses a Red Hat Virtualization Host. Red Hat Virtualization Manager automatically registers any configured Red Hat Virtualization Host. This example retrieves a representation of the hosts collection and shows a Red Hat Virtualization Host named hypervisor registered with the virtualization environment. Example 3.5. List hosts collection Request: cURL command: Result: Note the id code of your Default host. This code identifies this host in relation to other resources of your virtual environment. This host is a member of the Default cluster and accessing the nics sub-collection shows this host has a connection to the ovirtmgmt network.

Commands:
GET /ovirt-engine/api/hosts HTTP/1.1 Accept: application/xml
curl -X GET -H "Accept: application/xml" -u [USER:PASS] --cacert [CERT] https:// [RHEVM Host] :443/ovirt-engine/api/hosts
HTTP/1.1 200 OK Accept: application/xml <hosts> <host id="0656f432-923a-11e0-ad20-5254004ac988" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988"> <name>hypervisor</name> <actions> <link rel="install" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/install"/> <link rel="activate" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/activate"/> <link rel="fence" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/fence"/> <link rel="deactivate" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/deactivate"/> <link rel="approve" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/approve"/> <link rel="iscsilogin" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/iscsilogin"/> <link rel="iscsidiscover" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/iscsidiscover"/> <link rel="commitnetconfig" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/ commitnetconfig"/> </actions> <link rel="storage" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/storage"/> <link rel="nics" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/nics"/> <link rel="tags" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/tags"/> <link rel="permissions" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/permissions"/> <link rel="statistics" href="/ovirt-engine/api/hosts/0656f432-923a-11e0-ad20-5254004ac988/statistics"/> <address>10.64.14.110</address> <status> <state>non_operational</state> </status> <cluster id="99408929-82cf-4dc7-a532-9d998063fa95" href="/ovirt-engine/api/clusters/99408929-82cf-4dc7-a532-9d998063fa95"/> <port>54321</port> <storage_manager>true</storage_manager> <power_management> <enabled>false</enabled> <options/> </power_management> <ksm> <enabled>false</enabled> </ksm> <transparent_hugepages> <enabled>true</enabled> </transparent_hugepages> <iscsi> <initiator>iqn.1994-05.com.example:644949fe81ce</initiator> </iscsi> <cpu> <topology cores="2"/> <name>Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz</name> <speed>2993</speed> </cpu> <summary> <active>0</active> <migrating>0</migrating> <total>0</total> </summary> </host> </hosts>
Chapter 42. Hardware Enablement LSI Syncro CS HA-DAS adapters Red Hat Enterprise Linux 7.1 included code in the megaraid_sas driver to enable LSI Syncro CS high-availability direct-attached storage (HA-DAS) adapters. While the megaraid_sas driver is fully supported for previously enabled adapters, the use of this driver for Syncro CS is available as a Technology Preview. Support for this adapter is provided directly by LSI, your system integrator, or system vendor. Users deploying Syncro CS on Red Hat Enterprise Linux 7.2 and later are encouraged to provide feedback to Red Hat and LSI. (BZ#1062759) tss2 enables TPM 2.0 for IBM Power LE The tss2 package adds IBM implementation of a Trusted Computing Group Software Stack (TSS) 2.0 as a Technology Preview for the IBM Power LE architecture. This package enables users to interact with TPM 2.0 devices. (BZ#1384452) The ibmvnic device driver available as a Technology Preview Since Red Hat Enterprise Linux 7.3, the IBM Virtual Network Interface Controller (vNIC) driver for IBM POWER architectures, ibmvnic , has been available as a Technology Preview. vNIC is a PowerVM virtual networking technology that delivers enterprise capabilities and simplifies network management. It is a high-performance, efficient technology that when combined with SR-IOV NIC provides bandwidth control Quality of Service (QoS) capabilities at the virtual NIC level. vNIC significantly reduces virtualization overhead, resulting in lower latencies and fewer server resources, including CPU and memory, required for network virtualization. With Red Hat Enterprise Linux 7.6, the ibmvnic driver has been upgraded to version 1.0, which provides a number of bug fixes and enhancements over the version. Notable changes include: The code that previously requested error information has been removed because no error ID is provided by the Virtual Input-Output (VIOS) Server. Error reporting has been updated with the cause string. As a result, during a recovery, the driver classifies the string as a warning rather than an error. Error recovery on a login failure has been fixed. The failed state that occurred after a failover while migrating Logical Partitioning (LPAR) has been fixed. The driver can now handle all possible login response return values. A driver crash that happened during a failover or Link Power Management (LPM) if the Transmit and Receive (Tx/Rx) queues have changed has been fixed. (BZ#1519746)

Commands:
11.2. Configuring SNMP with the Red Hat High Availability Add-On To configure SNMP with the Red Hat High Availability Add-On, perform the following steps on each node in the cluster to ensure that the necessary services are enabled and running. To use SNMP traps with the Red Hat High Availability Add-On, the snmpd service is required and acts as the master agent. Since the foghorn service is the subagent and uses the AgentX protocol, you must add the following line to the /etc/snmp/snmpd.conf file to enable AgentX support: To specify the host where the SNMP trap notifications should be sent, add the following line to the to the /etc/snmp/snmpd.conf file: For more information on notification handling, see the snmpd.conf man page. Make sure that the snmpd daemon is enabled and running by executing the following commands: If the messagebus daemon is not already enabled and running, execute the following commands: Make sure that the foghorn daemon is enabled and running by executing the following commands: Execute the following command to configure your system so that the COROSYNC-MIB generates SNMP traps and to ensure that the corosync-notifyd daemon is enabled and running: After you have configured each node in the cluster for SNMP and ensured that the necessary services are running, D-bus signals will be received by the foghorn service and translated into SNMPv2 traps. These traps are then passed to the host that you defined with the trapsink entry to receive SNMPv2 traps.

Commands:
master agentx
trap2sink host
chkconfig snmpd on service snmpd start
chkconfig messagebus on service messagebus start
chkconfig foghorn on service foghorn start
echo "OPTIONS=\"-d\" " > /etc/sysconfig/corosync-notifyd chkconfig corosync-notifyd on service corosync-notifyd start
Chapter 2. Process Description RHEL OpenStack Platform includes all the drivers required for all Dell devices supported by the Block Storage service. In addition, the Director also has the puppet manifests, environment files, and Orchestration templates necessary for integrating the device as a back end to the Overcloud. Configuring a single Dell device as a back end involves editing the default environment file and including it in the Overcloud deployment. This file is available locally on the Undercloud, and can be edited to suit your environment. After editing this file, invoke it through the Director. Doing so ensures that it will persist through future Overcloud updates. The following sections describe this process in greater detail. In addition, the default environment file already contains enough information to call the necessary puppet manifests and Orchestration (Heat) templates that will configure the rest of the required Block Storage settings.

Commands:
B.2. Tracepoints The tracepoints can be found under the /sys/kernel/debug/tracing/ directory assuming that debugfs is mounted in the standard place at the /sys/kernel/debug directory. The events subdirectory contains all the tracing events that may be specified and, provided the gfs2 module is loaded, there will be a gfs2 subdirectory containing further subdirectories, one for each GFS2 event. The contents of the /sys/kernel/debug/tracing/events/gfs2 directory should look roughly like the following: To enable all the GFS2 tracepoints, enter the following command: To enable a specific tracepoint, there is an enable file in each of the individual event subdirectories. The same is true of the filter file which can be used to set an event filter for each event or set of events. The meaning of the individual events is explained in more detail below. The output from the tracepoints is available in ASCII or binary format. This appendix does not currently cover the binary interface. The ASCII interface is available in two ways. To list the current content of the ring buffer, you can enter the following command: This interface is useful in cases where you are using a long-running process for a certain period of time and, after some event, want to look back at the latest captured information in the buffer. An alternative interface, /sys/kernel/debug/tracing/trace_pipe , can be used when all the output is required. Events are read from this file as they occur; there is no historical information available through this interface. The format of the output is the same from both interfaces and is described for each of the GFS2 events in the later sections of this appendix. A utility called trace-cmd is available for reading tracepoint data. For more information on this utility, see the link in Section B.10, "References" . The trace-cmd utility can be used in a similar way to the strace utility, for example to run a command while gathering trace data from various sources.

Commands:
ls enable gfs2_bmap gfs2_glock_queue gfs2_log_flush filter gfs2_demote_rq gfs2_glock_state_change gfs2_pin gfs2_block_alloc gfs2_glock_put gfs2_log_blocks gfs2_promote
echo -n 1 >/sys/kernel/debug/tracing/events/gfs2/enable
cat /sys/kernel/debug/tracing/trace
3.2. Using the Red Hat Customer Portal The Red Hat Customer Portal at https://access.redhat.com/ is the main customer-oriented resource for official information related to Red Hat products. You can use it to find documentation, manage your subscriptions, download products and updates, open support cases, and learn about security updates. 3.2.1. Viewing Security Advisories on the Customer Portal To view security advisories (errata) relevant to the systems for which you have active subscriptions, log into the Customer Portal at https://access.redhat.com/ and click on the Download Products & Updates button on the main page. When you enter the Software & Download Center page, continue by clicking on the Errata button to see a list of advisories pertinent to your registered systems. To browse a list of all security updates for all active Red Hat products, go to Security Security Updates Active Products using the navigation menu at the top of the page. Click on the erratum code in the left part of the table to display more detailed information about the individual advisories. The page contains not only a description of the given erratum, including its causes, consequences, and required fixes, but also a list of all packages that the particular erratum updates along with instructions on how to apply the updates. The page also includes links to relevant references, such as related CVE . 3.2.2. Navigating CVE Customer Portal Pages The CVE ( Common Vulnerabilities and Exposures ) project, maintained by The MITRE Corporation, is a list of standardized names for vulnerabilities and security exposures. To browse a list of CVE that pertain to Red Hat products on the Customer Portal, log into your account at https://access.redhat.com/ and navigate to Security Resources CVE Database using the navigation menu at the top of the page. Click on the CVE code in the left part of the table to display more detailed information about the individual vulnerabilities. The page contains not only a description of the given CVE but also a list of affected Red Hat products along with links to relevant Red Hat errata. 3.2.3. Understanding Issue Severity Classification All security issues discovered in Red Hat products are assigned an impact rating by Red Hat Product Security according to the severity of the problem. The four-point scale consists of the following levels: Low, Moderate, Important, and Critical. In addition to that, every security issue is rated using the Common Vulnerability Scoring System ( CVSS ) base scores. Together, these ratings help you understand the impact of security issues, allowing you to schedule and prioritize upgrade strategies for your systems. Note that the ratings reflect the potential risk of a given vulnerability, which is based on a technical analysis of the bug, not the current threat level. This means that the security impact rating does not change if an exploit is released for a particular flaw. To see a detailed description of the individual levels of severity ratings on the Customer Portal, visit the Severity Ratings page.

Commands:
Chapter 156. KafkaRebalanceSpec schema reference Used in: KafkaRebalance Property Property type Description mode string (one of [remove-disks, remove-brokers, full, add-brokers]) Mode to run the rebalancing. The supported modes are full , add-brokers , remove-brokers . If not specified, the full mode is used by default. full mode runs the rebalancing across all the brokers in the cluster. add-brokers mode can be used after scaling up the cluster to move some replicas to the newly added brokers. remove-brokers mode can be used before scaling down the cluster to move replicas out of the brokers to be removed. remove-disks mode can be used to move data across the volumes within the same broker . brokers integer array The list of newly added brokers in case of scaling up or the ones to be removed in case of scaling down to use for rebalancing. This list can be used only with rebalancing mode add-brokers and removed-brokers . It is ignored with full mode. goals string array A list of goals, ordered by decreasing priority, to use for generating and executing the rebalance proposal. The supported goals are available at https://github.com/linkedin/cruise-control#goals . If an empty goals list is provided, the goals declared in the default.goals Cruise Control configuration parameter are used. skipHardGoalCheck boolean Whether to allow the hard goals specified in the Kafka CR to be skipped in optimization proposal generation. This can be useful when some of those hard goals are preventing a balance solution being found. Default is false. rebalanceDisk boolean Enables intra-broker disk balancing, which balances disk space utilization between disks on the same broker. Only applies to Kafka deployments that use JBOD storage with multiple disks. When enabled, inter-broker balancing is disabled. Default is false. excludedTopics string A regular expression where any matching topics will be excluded from the calculation of optimization proposals. This expression will be parsed by the java.util.regex.Pattern class; for more information on the supported format consult the documentation for that class. concurrentPartitionMovementsPerBroker integer The upper bound of ongoing partition replica movements going into/out of each broker. Default is 5. concurrentIntraBrokerPartitionMovements integer The upper bound of ongoing partition replica movements between disks within each broker. Default is 2. concurrentLeaderMovements integer The upper bound of ongoing partition leadership movements. Default is 1000. replicationThrottle integer The upper bound, in bytes per second, on the bandwidth used to move replicas. There is no limit by default. replicaMovementStrategies string array A list of strategy class names used to determine the execution order for the replica movements in the generated optimization proposal. By default BaseReplicaMovementStrategy is used, which will execute the replica movements in the order that they were generated. moveReplicasOffVolumes BrokerAndVolumeIds array List of brokers and their corresponding volumes from which replicas need to be moved.

Commands:
C.3. IdM Domain Services and Log Rotation Several IdM domain services use the system logrotate service to handle log rotation and compression: named (DNS) httpd (Apache) tomcat sssd krb5kdc (the Kerberos domain controller) The logrotate configuration files are stored in the /etc/logrotate.d/ directory. Example C.1. Default httpd Log Rotation File at /etc/logrotate.d/httpd Warning The logrotate policy files for most of the services create a new log file with the same name, default owner, and default permissions as the log. However, with the files for named and tomcat , a special create rule sets this behavior with explicit permissions as well as user and group ownership. Do not change the permissions or the user and group which own the named and tomcat log files. This is required for both IdM operations and SELinux settings. Changing the ownership of the log rotation policy or of the files can cause the IdM domains services to fail. Additional Resources The 389 Directory Server instances used by IdM as a back end and by the Dogtag Certificate System have their own internal log rotation policies. See the Configuring Subsystem Logs in the Red Hat Directory Server 10 Administration Guide . For details about other potential log rotation settings, such as compression settings or the size of the log files, see the Log Rotation in the System Administrator's Guide or the logrotate (8) man page.

Commands:
/var/log/httpd/*log { missingok notifempty sharedscripts delaycompress postrotate /sbin/service httpd reload > /dev/null 2>/dev/null || true endscript }
Chapter 1. Planning your Red Hat Ansible Automation Platform operator installation on Red Hat OpenShift Container Platform Red Hat Ansible Automation Platform is supported on both Red Hat Enterprise Linux and Red Hat OpenShift. OpenShift operators help install and automate day-2 operations of complex, distributed software on Red Hat OpenShift Container Platform. The Ansible Automation Platform Operator enables you to deploy and manage Ansible Automation Platform components on Red Hat OpenShift Container Platform. You can use this section to help plan your Red Hat Ansible Automation Platform installation on your Red Hat OpenShift Container Platform environment. Before installing, review the supported installation scenarios to determine which meets your requirements. 1.1. About Ansible Automation Platform Operator The Ansible Automation Platform Operator provides cloud-native, push-button deployment of new Ansible Automation Platform instances in your OpenShift environment. The Ansible Automation Platform Operator includes resource types to deploy and manage instances of Automation controller and Private Automation hub. It also includes automation controller job resources for defining and launching jobs inside your automation controller deployments. Deploying Ansible Automation Platform instances with a Kubernetes native operator offers several advantages over launching instances from a playbook deployed on Red Hat OpenShift Container Platform, including upgrades and full lifecycle support for your Red Hat Ansible Automation Platform deployments. You can install the Ansible Automation Platform Operator from the Red Hat Operators catalog in OperatorHub. 1.2. OpenShift Container Platform version compatibility The Ansible Automation Platform Operator to install Ansible Automation Platform 2.3 is available on OpenShift Container Platform 4.9 and later versions. Additional resources See the Red Hat Ansible Automation Platform Life Cycle for the most current compatibility details. 1.3. Supported installation scenarios for Red Hat OpenShift Container Platform You can use the OperatorHub on the Red Hat OpenShift Container Platform web console to install Ansible Automation Platform Operator. Alternatively, you can install Ansible Automation Platform Operator from the OpenShift Container Platform command-line interface (CLI), oc . Follow one of the workflows below to install the Ansible Automation Platform Operator and use it to install the components of Ansible Automation Platform that you require. Automation controller custom resources first, then automation hub custom resources; Automation hub custom resources first, then automation controller custom resources; Automation controller custom resources; Automation hub custom resources. 1.4. Custom resources You can define custom resources for each primary installation workflows. 1.5. Additional resources See Understanding OperatorHub to learn more about OpenShift Container Platform OperatorHub.

Commands:
Part I. Preparing the RHEL installation Essential steps for preparing a RHEL installation environment addresses system requirements, supported architectures, and offers customization options for installation media. Additionally, it covers methods for creating bootable installation media, setting up network-based repositories, and configuring UEFI HTTP or PXE installation sources. Guidance is also included for systems using UEFI Secure Boot and for installing RHEL on 64-bit IBM Z architecture.

Commands:
2.2. Removing Control Groups Transient cgroups are released automatically as soon as the processes they contain finish. By passing the --remain‐after-exit option to systemd-run you can keep the unit running after its processes finished to collect runtime information. To stop the unit gracefully, type: Replace name with the name of the service you wish to stop. To terminate one or more of the unit's processes, type as root : Replace name with a name of the unit, for example httpd.service . Use --kill-who to select which processes from the cgroup you wish to terminate. To kill multiple processes at the same time, pass a comma-separated list of PIDs. Replace signal with the type of POSIX signal you wish to send to specified processes. Default is SIGTERM . For more information, see the systemd.kill manual page. Persistent cgroups are released when the unit is disabled and its configuration file is deleted by running: where name stands for the name of the service to be disabled.

Commands:
~]# systemctl stop name . service
~]# systemctl kill name .service --kill-who= PID ,... --signal= signal
~]# systemctl disable name . service
Chapter 6. Installing the multi-model serving platform For deploying small and medium-sized models, OpenShift AI includes a multi-model serving platform that is based on the ModelMesh component. On the multi-model serving platform, multiple models can be deployed from the same model server and share the server resources. To install the multi-model serving platform or ModelMesh, follow the steps described in Installing Red Hat OpenShift AI components by using the CLI or Installing Red Hat OpenShift AI components by using the web console .

Commands: