mtpti5iD/redhat-docs_dataset huggingface dataset:
Appendix A. The Source-to-Image (S2I) build process Source-to-Image (S2I) is a build tool for generating reproducible Docker-formatted container images from online SCM repositories with application sources. With S2I builds, you can easily deliver the latest version of your application into production with shorter build times, decreased resource and network usage, improved security, and a number of other advantages. OpenShift supports multiple build strategies and input sources . For more information, see the Source-to-Image (S2I) Build chapter of the OpenShift Container Platform documentation. You must provide three elements to the S2I process to assemble the final container image: The application sources hosted in an online SCM repository, such as GitHub. The S2I Builder image, which serves as the foundation for the assembled image and provides the ecosystem in which your application is running. Optionally, you can also provide environment variables and parameters that are used by S2I scripts . The process injects your application source and dependencies into the Builder image according to instructions specified in the S2I script, and generates a Docker-formatted container image that runs the assembled application. For more information, check the S2I build requirements , build options and how builds work sections of the OpenShift Container Platform documentation.

Commands:
Chapter 40. 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 running state, use: Command Timer To control the command timer, you can write to /sys/block/ device-name /device/timeout . To do so, run: echo value /sys/block/ device-name /device/timeout Here, value is the timeout value (in seconds) you want to implement.

Commands:
cat /sys/block/ device-name /device/state
echo running > /sys/block/ device-name /device/state
6.2. Disabling vhost-net The vhost-net module is a kernel-level back end for virtio networking that reduces virtualization overhead by moving virtio packet processing tasks out of user space (the QEMU process) and into the kernel (the vhost-net driver). vhost-net is only available for virtio network interfaces. If the vhost-net kernel module is loaded, it is enabled by default for all virtio interfaces, but can be disabled in the interface configuration if a particular workload experiences a degradation in performance when vhost-net is in use. Specifically, when UDP traffic is sent from a host machine to a guest virtual machine on that host, performance degradation can occur if the guest virtual machine processes incoming data at a rate slower than the host machine sends it. In this situation, enabling vhost-net causes the UDP socket's receive buffer to overflow more quickly, which results in greater packet loss. It is therefore better to disable vhost-net in this situation to slow the traffic, and improve overall performance. To disable vhost-net , edit the <interface> sub-element in the guest virtual machine's XML configuration file and define the network as follows: Setting the driver name to qemu forces packet processing into QEMU user space, effectively disabling vhost-net for that interface.

Commands:
<interface type="network"> <model type="virtio"/> <driver name="qemu"/> </interface>
5.2.28. /proc/swaps This file measures swap space and its utilization. For a system with only one swap partition, the output of /proc/swap may look similar to the following: While some of this information can be found in other files in the /proc/ directory, /proc/swap provides a snapshot of every swap file name, the type of swap space, the total size, and the amount of space in use (in kilobytes). The priority column is useful when multiple swap files are in use. The lower the priority, the more likely the swap file is to be used.

Commands:
Filename Type Size Used Priority /dev/mapper/VolGroup00-LogVol01 partition 524280 0 -1
Chapter 2. Creating a subscription allocation for a disconnected Satellite Server Users on a connected Satellite Server create subscription manifests in the Manifests section of the Red Hat Hybrid Cloud Console. For information about how to create a manifest for a connected Satellite Server, see Creating a manifest for a connected Satellite Server . Users using a disconnected Satellite Server can still create a new subscription allocation to set aside subscriptions and entitlements for a system that is offline or air-gapped. This is necessary before you can download its manifest and upload it to a system. Procedure To create a manifest for a disconnected or air-gapped Satellite Server, complete the following steps: From the Subscription Allocations page, click Create Manifest . Click New Subscription Allocation Enter a Name for the allocation so that you can find it later. Select the Type of subscription management application you plan to use on the system. Click Create .

Commands:
Chapter 17. Annotating encrypted RBD storage classes Starting with OpenShift Data Foundation 4.14, when the OpenShift console creates a RADOS block device (RBD) storage class with encryption enabled, the annotation is set automatically. However, you need to add the annotation, cdi.kubevirt.io/clone-strategy=copy for any of the encrypted RBD storage classes that were previously created before updating to the OpenShift Data Foundation version 4.14. This enables customer data integration (CDI) to use host-assisted cloning instead of the default smart cloning. The keys used to access an encrypted volume are tied to the namespace where the volume was created. When cloning an encrypted volume to a new namespace, such as, provisioning a new OpenShift Virtualization virtual machine, a new volume must be created and the content of the source volume must then be copied into the new volume. This behavior is triggered automatically if the storage class is properly annotated.

Commands:
4.3.2. Backing Store -- the Central Tenet of Virtual Memory The short answer to this question is that the rest of the application remains on disk. In other words, disk acts as the backing store for RAM; a slower, larger storage medium acting as a "backup" for a much faster, smaller storage medium. This might at first seem to be a very large performance problem in the making -- after all, disk drives are so much slower than RAM. While this is true, it is possible to take advantage of the sequential and localized access behavior of applications and eliminate most of the performance implications of using disk drives as backing store for RAM. This is done by structuring the virtual memory subsystem so that it attempts to ensure that those parts of the application currently needed -- or likely to be needed in the near future -- are kept in RAM only for as long as they are actually needed. In many respects this is similar to the relationship between cache and RAM: making a small amount of fast storage combined with a large amount of slow storage act just like a large amount of fast storage. With this in mind, let us explore the process in more detail.

Commands:
Chapter 7. Upgrading the Migration Toolkit for Virtualization You can upgrade the MTV Operator by using the Red Hat OpenShift web console to install the new version. Procedure In the Red Hat OpenShift web console, click Operators Installed Operators Migration Toolkit for Virtualization Operator Subscription . Change the update channel to the correct release. See Changing update channel in the Red Hat OpenShift documentation. Confirm that Upgrade status changes from Up to date to Upgrade available . If it does not, restart the CatalogSource pod: Note the catalog source, for example, redhat-operators . From the command line, retrieve the catalog source pod: USD oc get pod -n openshift-marketplace | grep <catalog_source> Delete the pod: USD oc delete pod -n openshift-marketplace <catalog_source_pod> Upgrade status changes from Up to date to Upgrade available . If you set Update approval on the Subscriptions tab to Automatic , the upgrade starts automatically. If you set Update approval on the Subscriptions tab to Manual , approve the upgrade. See Manually approving a pending upgrade in the Red Hat OpenShift documentation. If you are upgrading from MTV 2.2 and have defined VMware source providers, edit the VMware provider by adding a VDDK init image. Otherwise, the update will change the state of any VMware providers to Critical . For more information, see Adding a VMSphere source provider . If you mapped to NFS on the Red Hat OpenShift destination provider in MTV 2.2, edit the AccessModes and VolumeMode parameters in the NFS storage profile. Otherwise, the upgrade will invalidate the NFS mapping. For more information, see Customizing the storage profile .

Commands:
oc get pod -n openshift-marketplace | grep <catalog_source>
oc delete pod -n openshift-marketplace <catalog_source_pod>
Chapter 14. 4.11 Release Notes Important Disk space requirements have changed. More disk space is now required for the partition or volume where the PostgreSQL database is stored. Please see Technical configuration required for installing RHUI . 14.1. New Features The following major enhancements have been introduced in Red Hat Update Infrastructure 4.11. New Pulp version This update introduces a newer version of Pulp, 3.49. Along with this update a number of CVEs were addressed in underlying libraries. For more information check errata problem description. Persistent Custom Configuration for rhui-tools.conf Previously, any modifications made to the rhui-tools.conf file were lost after upgrading RHUI. With this update, you can now preserve custom changes by creating the /root/.rhui/rhui-tools-custom.conf file. Any configurations specified in this file will override the default settings after an upgrade. 14.2. Bug Fixes The following bug has been fixed in Red Hat Update Infrastructure 4.11. Depreciation warnings addressed in installer playbook To avoid depreciation warnings, the Red Hat Update Infrastructure installer playbook has been updated to use dictionaries instead of lists of dictionaries. As a result, users will no longer see deprecation warnings when running or rerunning rhui-installer .

Commands:
2.3. Migration Migration describes the process of moving a guest virtual machine from one host to another. This is possible because the virtual machines are running in a virtualized environment instead of directly on the hardware. There are two ways to migrate a virtual machine: live and offline. Migration Types Offline migration An offline migration suspends the guest virtual machine, and then moves an image of the virtual machine's memory to the destination host. The virtual machine is then resumed on the destination host and the memory used by the virtual machine on the source host is freed. Live migration Live migration is the process of migrating an active virtual machine from one physical host to another. Note that this is not possible between all Red Hat Enterprise Linux releases. Consult the Virtualization Deployment and Administration Guide for details. 2.3.1. Benefits of Migrating Virtual Machines Migration is useful for: Load balancing When a host machine is overloaded, one or more of its virtual machines could be migrated to other hosts using live migration. Similarly, machines that are not running and tend to overload can be migrated using offline migration. Upgrading or making changes to the host When the need arises to upgrade, add, or remove hardware devices on a host, virtual machines can be safely relocated to other hosts. This means that guests do not experience any downtime due to changes that are made to hosts. Energy saving Virtual machines can be redistributed to other hosts and the unloaded host systems can be powered off to save energy and cut costs in low usage periods. Geographic migration Virtual machines can be moved to other physical locations for lower latency or for other reasons. When the migration process moves a virtual machine's memory, the disk volume associated with the virtual machine is also migrated. This process is performed using live block migration. Note For more information on migration, see the Red Hat Enterprise Linux 7 Virtualization Deployment and Administration Guide . 2.3.2. Virtualized to Virtualized Migration (V2V) As a special type of migration, Red Hat Enterprise Linux 7 provides tools for converting virtual machines from other types of hypervisors to KVM. The virt-v2v tool converts and imports virtual machines from Xen, other versions of KVM, and VMware ESX. Note For more information on V2V, see the V2V Knowledgebase articles . In addition, Red Hat Enterprise Linux 7.3 and later support physical-to-virtual (P2V) conversion using the virt-p2v tool. For details, see the P2V Knowledgebase article .

Commands:
6.2. Overcommitting Virtualized CPUs The KVM hypervisor supports overcommitting virtualized CPUs. Virtualized CPUs can be overcommitted as far as load limits of guest virtual machines allow. Use caution when overcommitting VCPUs as loads near 100% may cause dropped requests or unusable response times. Virtualized CPUs (vCPUs) are overcommitted best when a single host physical machine has multiple guest virtual machines that do not share the same vCPU. KVM should safely support guest virtual machines with loads under 100% at a ratio of five VCPUs (on 5 virtual machines) to one physical CPU on one single host physical machine. KVM will switch between all of the machines, making sure that the load is balanced. Do not overcommit guest virtual machines on more than the physical number of processing cores. For example a guest virtual machine with four vCPUs should not be run on a host physical machine with a dual core processor, but on a quad core host. In addition, it is not recommended to have more than 10 total allocated vCPUs per physical processor core. Important Do not overcommit CPUs in a production environment without extensive testing. Applications which use 100% of processing resources may become unstable in overcommitted environments. Test before deploying. For more information on how to get the best performance out of your virtual machine, refer to the Red Hat Enterprise Linux 6 Virtualization Tuning and Optimization Guide .

Commands:
7.52. evolution-exchange 7.52.1. RHBA-2015:1265 - evolution-exchange bug fix update Updated evolution-exchange packages that fix one bug are now available for Red Hat Enterprise Linux 6. The evolution-exchange packages enable added functionality to Evolution when used with a Microsoft Exchange Server 2003. The packages also contain Exchange Web Services (EWS) connector, which can connect to Microsoft Exchange 2007 and later servers. Bug Fix BZ# 1160279 When the Exchange Web Services (EWS) connector was used, the UI part of the connector failed to load due to a missing external symbol. Consequently, the user could neither change the settings nor configure a new mail account for the EWS part of the evolution-exchange packages. This update corrects the library link options during build time to have the missing symbol available. Now, the UI part of the EWS connector loads properly, and the mail account can be added and configured. Users of evolution-exchange are advised to upgrade to these updated packages, which fix this bug.

Commands:
Appendix C. Revision History Note that revision numbers relate to the edition of this manual, not to version numbers of Red Hat Enterprise Linux. Revision History Revision 6.7-4 Mon Apr 10 2017 Aneta Steflova Petrova Updated Smart Cards. Revision 6.7-3 Wed Mar 8 2017 Aneta Steflova Petrova Version for 6.9 GA publication. Revision 6.7-2 Wed May 4 2016 Marc Muehlfeld Preparing document for 6.8 GA publication. Revision 6.7-1 Thu Feb 18 2016 Aneta Petrova Minor updates to trust and sudo chapters, added a warning to renewing CA certificates issued by external CAs. Revision 6.7-0 Tue Jul 14 2015 Tomas Capek Version for 6.7 GA release. Revision 6.6-2 Tue Mar 31 2015 Tomas Capek Improved sections on setting a Kerberized NFS server and client. Revision 6.6-1 Fri Dec 19 2014 Tomas Capek Rebuilt to update the sort order on the splash page. Revision 6.6-0 Fri Oct 10 2014 Tomas Capek Version for 6.6 GA release. Revision 6.5-5 July 9, 2014 Ella Deon Ballard Fixed bugs. Revision 6.5-4 February 3, 2014 Ella Deon Ballard Fixed bugs. Revision 6.5-1 November 20, 2013 Ella Deon Ballard Fixed bugs. Revision 6.4-3 August 20, 2013 Ella Deon Lackey Fixed bugs, reorganized some chapters. Revision 6.4-1 March 1, 2013 Ella Deon Lackey Added trusts. Revision 6.3-1 October 18, 2012 Ella Deon Lackey Removed sudo configuration example, group sync information, CRL generation section. Revision 6.2-8 December 16, 2011 Ella Deon Lackey Updated sudoers_debug example. Fixed migration command example. Revision 6.2-7 December 6, 2011 Ella Deon Lackey Release for GA of Red Hat Enterprise Linux 6.2.

Commands:
16.4. Sub-Collections 16.4.1. Statistics Sub-Collection Each floating disk exposes a statistics sub-collection for disk-specific statistics. Each statistic contains the following elements: Table 16.2. Elements for virtual disk statistics Element Type Description name string The unique identifier for the statistic entry. description string A plain text description of the statistic. unit string The unit or rate to measure the statistical values. type One of GAUGE or COUNTER The type of statistic measures. values type= One of INTEGER or DECIMAL The data type for the statistical values that follow. value complex A data set that contains datum . datum see values type An individual piece of data from a value . disk id= relationship A relationship to the containing disk resource. The following table lists the statistic types for floating disks. Table 16.3. Disk statistic types Name Description data.current.read The data transfer rate in bytes per second when reading from the disk. data.current.write The data transfer rate in bytes per second when writing to the disk. Example 16.3. An XML representation of a virtual machine's statistics sub-collection Note This statistics sub-collection is read-only.

Commands:
<statistics> <statistic id="33b9212b-f9cb-3fd0-b364-248fb61e1272" href="/ovirt-engine/api/disks/f28ec14c-fc85-43e1-818d-96b49d50e27b/statistics/ 33b9212b-f9cb-3fd0-b364-248fb61e1272"> <name>data.current.read</name> <description>Read data rate</description> <values type="DECIMAL"> <value> <datum>0</datum> </value> </values> <type>GAUGE</type> <unit>BYTES_PER_SECOND</unit> <disk id="f28ec14c-fc85-43e1-818d-96b49d50e27b" href="/ovirt-engine/api/disks/f28ec14c-fc85-43e1-818d-96b49d50e27b"/> </statistic> </statistics>
Upgrading Red Hat OpenShift Service on AWS 4 Understanding upgrading options for Red Hat OpenShift Service on AWS Red Hat OpenShift Documentation Team

Commands:
rosa describe cluster --cluster=<cluster_name_or_id> 1
rosa list upgrade --cluster=<cluster_name_or_id>
VERSION NOTES 4.14.8 recommended 4.14.7 4.14.6
rosa upgrade cluster -c <cluster_name_or_id> --control-plane [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>
rosa upgrade cluster -c <cluster_name_or_id> --control-plane --version <version_number>
rosa upgrade cluster -c <cluster_name_or_id> --control-plane --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version=<version_number>
rosa describe cluster --cluster=<cluster_name_or_id> 1
OpenShift Version: 4.14.0
rosa list upgrade --cluster <cluster-name> --machinepool <machinepool_name>
VERSION NOTES 4.14.5 recommended 4.14.4 4.14.3
rosa describe machinepool --cluster=<cluster_name_or_id> <machinepool_name>
Replicas: 5 Node drain grace period: 30 minutes Management upgrade: - Type: Replace - Max surge: 20% - Max unavailable: 20%
rosa upgrade machinepool -c <cluster_name> <machinepool_name> [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>
rosa upgrade machinepool -c <cluster_name> <machinepool_name> --version <version_number>
rosa upgrade machinepool -c <cluster_name> <machinepool_name> --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version <version_number>
rosa describe cluster --cluster=<cluster_name|cluster_id> 1
rosa list upgrade --cluster=<cluster_name|cluster_id>
rosa upgrade cluster --cluster=<cluster_name|cluster_id> --version <version-id>
rosa upgrade cluster --cluster=<cluster_name|cluster_id> --version <version-id> --schedule-date yyyy-mm-dd --schedule-time HH:mm
rosa upgrade cluster --cluster=<cluster_name|cluster_id> --version <version-id> --node-drain-grace-period 15 minutes
rosa list upgrade --cluster=<cluster_name|cluster_id>
VERSION NOTES 4.15.14 recommended - scheduled for 2024-06-02 15:00 UTC 4.15.13
rosa list upgrades --cluster=<cluster_name|cluster_id>
VERSION NOTES 4.15.14 recommended - scheduled for 2024-06-02 15:00 UTC 4.15.13
rosa delete upgrade --cluster=<cluster_name|cluster_id>
I: Successfully canceled scheduled upgrade on cluster 'my-cluster'
7.224. vim 7.224.1. RHBA-2015:1310 - vim bug fix and enhancement update Updated vim packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. Vim (Vi IMproved) is an updated and improved version of the vi editor. Note The vim packages have been upgraded to upstream version 7.4, which provides a number of bug fixes and enhancements over the version. (BZ# 820331 , BZ# 893239 , BZ# 1083924 , BZ# 1112441 , BZ# 1201834 , BZ# 1202897 , BZ# 1204179 ) Users of vim are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 12. Viewing threads You can view and monitor the state of threads. Procedure Click the Runtime tab and then the Threads subtab. The Threads page lists active threads and stack trace details for each thread. By default, the thread list shows all threads in descending ID order. To sort the list by increasing ID, click the ID column label. Optionally, filter the list by thread state (for example, Blocked ) or by thread name. To drill down to detailed information for a specific thread, such as the lock class name and full stack trace for that thread, in the Actions column, click More .

Commands:
Chapter 109. AclRuleGroupResource schema reference Used in: AclRule The type property is a discriminator that distinguishes use of the AclRuleGroupResource type from AclRuleTopicResource , AclRuleClusterResource , AclRuleTransactionalIdResource . It must have the value group for the type AclRuleGroupResource . Property Description type Must be group . string name Name of resource for which given ACL rule applies. Can be combined with patternType field to use prefix pattern. string patternType Describes the pattern used in the resource field. The supported types are literal and prefix . With literal pattern type, the resource field will be used as a definition of a full topic name. With prefix pattern type, the resource name will be used only as a prefix. Default value is literal . string (one of [prefix, literal])

Commands: