mtpti5iD/redhat-docs_dataset huggingface dataset:
25.20. Controlling the SCSI Command Timer and Device Status The Linux SCSI layer sets a timer on each command. When this timer expires, the SCSI layer will quiesce the host bus adapter (HBA) and wait for all outstanding commands to either time out or complete. Afterwards, the SCSI layer will activate the driver's error handler. When the error handler is triggered, it attempts the following operations in order (until one successfully executes): Abort the command. Reset the device. Reset the bus. Reset the host. If all of these operations fail, the device will be set to the offline state. When this occurs, all I/O to that device will be failed, until the problem is corrected and the user sets the device to running . The process is different, however, if a device uses the Fibre Channel protocol and the rport is blocked. In such cases, the drivers wait for several seconds for the rport to become online again before activating the error handler. This prevents devices from becoming offline due to temporary transport problems. Device States To display the state of a device, use: To set a device to the running state, use: Command Timer To control the command timer, modify the /sys/block/ device-name /device/timeout file: Replace value in the command with the timeout value, in seconds, that you want to implement.

Commands:
cat /sys/block/ device-name /device/state
echo running > /sys/block/ device-name /device/state
echo value > /sys/block/ device-name /device/timeout
Appendix D. Teiid Designer Views D.1. Teiid Designer Views Views are dockable windows which present data from your models or your modeling session in various forms. Some views support particular Model Editors and their content is dependent on workspace selection. This section summarizes most of the views used and available in Teiid Designer . The full list is presented in the main menu's Window > Show View > Other... dialog under the Teiid Designer category. Figure D.1. Show View Dialog

Commands:
2.8. The Storage Pool Manager Red Hat Virtualization uses metadata to describe the internal structure of storage domains. Structural metadata is written to a segment of each storage domain. Hosts work with the storage domain metadata based on a single writer, and multiple readers configuration. Storage domain structural metadata tracks image and snapshot creation and deletion, and volume and domain extension. The host that can make changes to the structure of the data domain is known as the Storage Pool Manager (SPM). The SPM coordinates all metadata changes in the data center, such as creating and deleting disk images, creating and merging snapshots, copying images between storage domains, creating templates and storage allocation for block devices. There is one SPM for every data center. All other hosts can only read storage domain structural metadata. A host can be manually selected as the SPM, or it can be assigned by the Red Hat Virtualization Manager. The Manager assigns the SPM role by causing a potential SPM host to attempt to assume a storage-centric lease. The lease allows the SPM host to write storage metadata. It is storage-centric because it is written to the storage domain rather than being tracked by the Manager or hosts. Storage-centric leases are written to a special logical volume in the master storage domain called leases . Metadata about the structure of the data domain is written to a special logical volume called metadata . The leases logical volume protects the metadata logical volume from changes. The Manager uses VDSM to issue the spmStart command to a host, causing VDSM on that host to attempt to assume the storage-centric lease. If the host is successful it becomes the SPM and retains the storage-centric lease until the Red Hat Virtualization Manager requests that a new host assume the role of SPM. The Manager moves the SPM role to another host if: The SPM host can not access all storage domains, but can access the master storage domain The SPM host is unable to renew the lease because of a loss of storage connectivity or the lease volume is full and no write operation can be performed The SPM host crashes Figure 2.1. The Storage Pool Manager Exclusively Writes Structural Metadata.

Commands:
Chapter 4. Deprecated features The features deprecated in this release, and that were supported in releases of AMQ Streams, are outlined below. 4.1. Kafka Connect with Source-to-Image (S2I) AMQ Streams 1.7 introduces build configuration to the KafkaConnect resource, as described in Chapter 1, Features . With the introduction of build configuration to the KafkaConnect resource, AMQ Streams can now automatically build a container image with the connector plugins you require for your data connections. As a result, support for Kafka Connect with Source-to-Image (S2I) is deprecated. To prepare for this change, you can migrate Kafka Connect S2I instances to Kafka Connect instances. See Migrating from Kafka Connect with S2I to Kafka Connect 4.2. Metrics configuration Metrics configuration is now specified as a ConfigMap for Kafka components. Previously, the spec.metrics property was used. To update the configuration, and enable Prometheus metrics export, a new ConfigMap must be created that matches the configuration for the .spec.metrics property. The .spec.metricsConfig property is used to specify the ConfigMap, as described in Chapter 1, Features . See Upgrading AMQ Streams 4.3. API versions The introduction of v1beta2 updates the schemas of the custom resources. Older API versions are deprecated. The v1alpha1 API version is deprecated for the following AMQ Streams custom resources: Kafka KafkaConnect KafkaConnectS2I KafkaConnector KafkaMirrorMaker KafkaMirrorMaker2 KafkaTopic KafkaUser KafkaBridge KafkaRebalance The v1beta1 API version is deprecated for the following AMQ Streams custom resources: Kafka KafkaConnect KafkaConnectS2I KafkaMirrorMaker KafkaTopic KafkaUser Important The v1alpha1 and v1beta1 versions will be removed in the minor release. See AMQ Streams custom resource upgrades . 4.4. Annotations The following annotations are deprecated, and will be removed in AMQ Streams 1.8.0: Table 4.1. Deprecated annotations and their replacements Deprecated annotation Replacement annotation cluster.operator.strimzi.io/delete-claim strimzi.io/delete-claim (Internal) operator.strimzi.io/generation strimzi.io/generation (Internal) operator.strimzi.io/delete-pod-and-pvc strimzi.io/delete-pod-and-pvc operator.strimzi.io/manual-rolling-update strimzi.io/manual-rolling-update

Commands:
33.7. Modifying Existing Printers To delete an existing printer, select the printer and click the Delete button on the toolbar. The printer is removed from the printer list once you confirm deletion of the printer configuration. To set the default printer, select the printer from the printer list and click the Make Default Printer button in the Settings tab. 33.7.1. The Settings Tab To change printer driver configuration, click the corresponding name in the Printer list and click the Settings tab. You can modify printer settings such as make and model, make a printer the default, print a test page, change the device location (URI), and more. Figure 33.8. Settings Tab

Commands:
Chapter 21. Using early kdump to capture boot time crashes Early kdump is a feature of the kdump mechanism that captures the vmcore file if a system or kernel crash occurs during the early phases of the boot process before the system services start. Early kdump loads the crash kernel and the initramfs of crash kernel in the memory much earlier. A kernel crash can sometimes occur during the early boot phase before the kdump service starts and is able to capture and save the contents of the crashed kernel memory. Therefore, crucial information related to the crash that is important for troubleshooting is lost. To address this problem, you can use the early kdump feature, which is a part of the kdump service. 21.1. Enabling early kdump The early kdump feature sets up the crash kernel and the initial RAM disk image ( initramfs ) to load early enough to capture the vmcore information for an early crash. This helps to eliminate the risk of losing information about the early boot kernel crashes. Prerequisites An active RHEL subscription. A repository containing the kexec-tools package for your system CPU architecture. Fulfilled kdump configuration and targets requirements. For more information see, Supported kdump configurations and targets . Procedure Verify that the kdump service is enabled and active: If kdump is not enabled and running, set all required configurations and verify that kdump service is enabled. Rebuild the initramfs image of the booting kernel with the early kdump functionality: Add the rd.earlykdump kernel command line parameter: Reboot the system to reflect the changes: Verification Verify that rd.earlykdump is successfully added and early kdump feature is enabled: Additional resources The /usr/share/doc/kexec-tools/early-kdump-howto.txt file What is early kdump support and how do I configure it? (Red Hat Knowledgebase)

Commands:
systemctl is-enabled kdump.service && systemctl is-active kdump.service enabled active
dracut -f --add earlykdump
grubby --update-kernel=/boot/vmlinuz-USD(uname -r) --args="rd.earlykdump"
reboot
cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-187.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet rd.earlykdump journalctl -x | grep early-kdump Mar 20 15:44:41 redhat dracut-cmdline[304]: early-kdump is enabled. Mar 20 15:44:42 redhat dracut-cmdline[304]: kexec: loaded early-kdump kernel
8.16. Kdump Use this screen to select whether or not to use Kdump on this system. Kdump is a kernel crash dumping mechanism which, in the event of a system crash, captures information that can be invaluable in determining the cause of the crash. Note that if you enable Kdump , you must reserve a certain amount of system memory for it. As a result, less memory is available for your processes. If you do not want to use Kdump on this system, uncheck Enable kdump . Otherwise, set the amount of memory to reserve for Kdump . You can let the installer reserve a reasonable amount automatically, or you can set any amount manually. When your are satisfied with the settings, click Done to save the configuration and return to the screen. Figure 8.37. Kdump Enablement and Configuration

Commands:
Chapter 1. Red Hat JBoss Web Server for OpenShift The Apache Tomcat 10 component of Red Hat JBoss Web Server (JWS) 6.0 is available as a containerized image that is designed for Red Hat OpenShift. You can use this image to build, scale, and test Java web applications for deployment across hybrid cloud environments. 1.1. Differences between Red Hat JBoss Web Server and JWS for OpenShift JWS for OpenShift images are different from a regular release of Red Hat JBoss Web Server. Consider the following differences between the JWS for OpenShift images and a standard JBoss Web Server deployment: In a JWS for OpenShift image, the /opt/jws-6.0/ directory is the location of JWS_HOME . In a JWS for OpenShift deployment, all load balancing is handled by the OpenShift router rather than the JBoss Core Services mod_cluster connector or mod_jk connector. Additional resources Red Hat JBoss Web Server documentation 1.2. OpenShift image version compatibility and support OpenShift images are tested with different operating system versions, configurations and interface points that represent the most common combination of technologies that Red Hat OpenShift Container Platform customers are using. Additional resources OpenShift Container Platform Tested 3.X Integrations page OpenShift Container Platform Tested 4.X Integrations page 1.3. Supported architectures for JBoss Web Server JBoss Web Server supports the following architectures: AMD64 (x86_64) IBM Z (s390x) in the OpenShift environment IBM Power (ppc64le) in the OpenShift environment ARM64 (aarch64) in the OpenShift environment You can use the JBoss Web Server image for OpenJDK 17 with all supported architectures. For more information about images, see the Red Hat Container Catalog . Additional resources Red Hat Container Catalog 1.4. Health checks for Red Hat container images All OpenShift Container Platform images have a health rating associated with them. You can find the health rating for Red Hat JBoss Web Server by navigating to the Certfied container images page, and then search for JBoss Web Server and select the 6.0 version. You can also perform health checks on an OpenShift container to test the container for liveliness and readiness. Additional resources Monitoring application health by using health checks 1.5. Additional resources (or steps) Support of Red Hat Middleware products and components on Red Hat OpenShift

Commands:
Chapter 4. Registering the system for updates using GNOME You must register your system to get software updates for your system. This section explains how you can register your system using GNOME. Prerequisites A valid account with Red Hat customer portal See the Create a Red Hat Login page for new user registration. Activation Key or keys, if you are registering the system with activation key A registration server, if you are registering system using the registration server 4.1. Registering a system using an activation key on GNOME Follow the steps in this procedure to register your system with an activation key. You can get the activation key from your organization administrator. Prerequisites Activation key or keys. See the Activation Keys page for creating new activation keys. Procedure Open the system menu , which is accessible from the upper-right screen corner, and click the Settings icon. In the Details About section, click Register . Select Registration Server . If you are not using the Red Hat server, enter the server address in the URL field. In the Registration Type menu, select Activation Keys . Under Registration Details : Enter your activation keys in the Activation Keys field. Separate your keys by a comma ( , ). Enter the name or ID of your organization in the Organization field. Click Register . 4.2. Unregistering the system using GNOME Follow the steps in this procedure to unregister your system. After unregistering, your system no longer receives software updates. Procedure Open the system menu , which is accessible from the upper-right screen corner, and click the Settings icon. In the Details About section, click Details . The Registration Details screen appears. Click Unregister . A warning appears about the impact of unregistering the system. Click Unregister . 4.3. Additional resources Registering the system and managing subscriptions Creating Red Hat Customer Portal Activation Keys (Red Hat Knowledgebase) Creating and managing activation keys Registering Systems with Activation keys (Red Hat Knowledgebase)

Commands:
Chapter 9. Kernel Chelsio firmware updated to version 1.15.37.0 Chelsio firmware has been updated to version 1.15.37.0, which provides a number of bug fixes and enhancements over the version. The most notable bug fixes are: The iscsi tlv driver is no longer incorrectly sent to host. The firmware no longer terminates unexpectedly due to enabling or disabling the Data Center Bridging Capability Exchange (DCBX) protocol. The app priority value is now handled correctly in the firmware. (BZ#1349112) The bnxt_en driver updated to the latest upstream version The bnxt_en driver has been updated with several minor fixes and with support for BCM5731X, BCM5741X, and 57404 Network Partitioning (NPAR) devices. (BZ#1347825) The ahci driver supports Marwell 88SE9230 The ahci driver now supports Marvell 88SE9230 controller. (BZ#1392941)

Commands:
Chapter 27. Kerberos PKINIT Authentication in IdM Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) is a preauthentication mechanism for Kerberos. As of Red Hat Enterprise Linux 7.4, the Identity Management (IdM) server includes a mechanism for Kerberos PKINIT authentication. The following sections give an overview of the PKINIT implementation in IdM and describe how to configure PKINIT in IdM. 27.1. Default PKINIT Status in Different IdM Versions The default PKINIT configuration on your IdM servers depends on the version of IdM in Red Hat Enterprise Linux (RHEL) and the certificate authority (CA) configuration. See Table 27.1, "Default PKINIT configuration in IdM versions" . Table 27.1. Default PKINIT configuration in IdM versions RHEL version CA configuration PKINIT configuration 7.3 and earlier Without a CA Local PKINIT: IdM only uses PKINIT for internal purposes on servers. 7.3 and earlier With an integrated CA IdM attempts to configure PKINIT by using the certificate signed by the integrated IdM CA. If the attempt fails, IdM configures local PKINIT only. 7.4 and later Without a CA No external PKINIT certificate provided to IdM Local PKINIT: IdM only uses PKINIT for internal purposes on servers. 7.4 and later Without a CA External PKINIT certificate provided to IdM IdM configures PKINIT by using the external Kerberos key distribution center (KDC) certificate and CA certificate. 7.4 and later With an integrated CA IdM configures PKINIT by using the certificate signed by the IdM CA. At domain level 0, PKINIT is disabled. The default behavior is local PKINIT: IdM only uses PKINIT for internal purposes on servers. See also Chapter 7, Displaying and Raising the Domain Level .

Commands:
7.11. Creating a Virtual Machine Based on a Template Create a virtual machine from a template to enable the virtual machines to be pre-configured with an operating system, network interfaces, applications and other resources. Note Virtual machines created from a template depend on that template. So you cannot remove a template from the Manager if a virtual machine was created from that template. However, you can clone a virtual machine from a template to remove the dependency on that template. Note If the BIOS type of the virtual machine differs from the BIOS type of the template, the Manager might change devices in the virtual machine, possibly preventing the operating system from booting. For example, if the template uses IDE disks and the i440fx chipset, changing the BIOS type to the Q35 chipset automatically changes the IDE disks to SATA disks. So configure the chipset and BIOS type to match the chipset and BIOS type of the template. Creating a Virtual Machine Based on a Template Click Compute Virtual Machines . Click New . Select the Cluster on which the virtual machine will run. Select a template from the Template list. Enter a Name , Description , and any Comments , and accept the default values inherited from the template in the rest of the fields. You can change them if needed. Click the Resource Allocation tab. Select the Thin or Clone radio button in the Storage Allocation area. If you select Thin , the disk format is QCOW2. If you select Clone , select either QCOW2 or Raw for disk format. Use the Target drop-down list to select the storage domain on which the virtual machine's virtual disk will be stored. Click OK . The virtual machine is displayed in the Virtual Machines tab. Additional Resources Creating a cloned virtual machine based on a template UEFI and the Q35 chipset in the Administration Guide .

Commands:
7.4. RHBA-2014:1577 - new packages: glib-networking New glib-networking packages are now available for Red Hat Enterprise Linux 6. The glib-networking packages provide modules that extend the networking support in Glib. In particular, the packages contain a libproxy-based implementation of the GProxyResolver class type and a gnutls-based implementation of the GTlsConnection class type. This enhancement update adds the glib-networking packages to Red Hat Enterprise Linux 6. (BZ# 1101418 , BZ# 1119162 ) The glib-networking packages are installed automatically as a dependency of the libsoup packages.

Commands:
Chapter 4. Knative CLI for use with OpenShift Serverless The Knative ( kn ) CLI enables simple interaction with Knative components on OpenShift Dedicated. 4.1. Key features The Knative ( kn ) CLI is designed to make serverless computing tasks simple and concise. Key features of the Knative CLI include: Deploy serverless applications from the command line. Manage features of Knative Serving, such as services, revisions, and traffic-splitting. Create and manage Knative Eventing components, such as event sources and triggers. Create sink bindings to connect existing Kubernetes applications and Knative services. Extend the Knative CLI with flexible plugin architecture, similar to the kubectl CLI. Configure autoscaling parameters for Knative services. Scripted usage, such as waiting for the results of an operation, or deploying custom rollout and rollback strategies. 4.2. Installing the Knative CLI See Installing the Knative CLI .

Commands:
F.2. About Consistency Guarantee Despite the locking of a single owner instead of all owners, Red Hat JBoss Data Grid's consistency guarantee remains intact. Consider the following situation: If Key K is hashed to nodes {A,B} and transaction TX1 acquires a lock for K on, for example, node A and If another cache access occurs on node B , or any other node, and TX2 attempts to lock K , this access attempt fails with a timeout because the transaction TX1 already holds a lock on K. This lock acquisition attempt always fails because the lock for key K is always deterministically acquired on the same node of the cluster, irrespective of the transaction's origin. Report a bug

Commands:
5.4.16.2. Converting a Linear Device to a RAID Device You can convert an existing linear logical volume to a RAID device by using the --type argument of the lvconvert command. The following command converts the linear logical volume my_lv in volume group my_vg to a 2-way RAID1 array. Since RAID logical volumes are composed of metadata and data subvolume pairs, when you convert a linear device to a RAID1 array, a new metadata subvolume is created and associated with the original logical volume on (one of) the same physical volumes that the linear volume is on. The additional images are added in metadata/data subvolume pairs. For example, if the original device is as follows: After conversion to a 2-way RAID1 array the device contains the following data and metadata subvolume pairs: If the metadata image that pairs with the original logical volume cannot be placed on the same physical volume, the lvconvert will fail.

Commands:
lvconvert --type raid1 -m 1 my_vg/my_lv
lvs -a -o name,copy_percent,devices my_vg LV Copy% Devices my_lv /dev/sde1(0)
lvconvert --type raid1 -m 1 my_vg/my_lv lvs -a -o name,copy_percent,devices my_vg LV Copy% Devices my_lv 6.25 my_lv_rimage_0(0),my_lv_rimage_1(0) [my_lv_rimage_0] /dev/sde1(0) [my_lv_rimage_1] /dev/sdf1(1) [my_lv_rmeta_0] /dev/sde1(256) [my_lv_rmeta_1] /dev/sdf1(0)