mtpti5iD/redhat-docs_dataset huggingface dataset:
23.8. Memory Allocation In cases where the guest virtual machine crashes, the optional attribute dumpCore can be used to control whether the guest virtual machine's memory should be included in the generated core dump( dumpCore='on' ) or not included ( dumpCore='off' ). Note that the default setting is on , so unless the parameter is set to off , the guest virtual machine memory will be included in the core dumpfile. The <maxMemory> element determines maximum run-time memory allocation of the guest. The slots attribute specifies the number of slots available for adding memory to the guest. The <memory> element specifies the maximum allocation of memory for the guest at boot time. This can also be set using the NUMA cell size configuration, and can be increased by hot-plugging of memory to the limit specified by maxMemory . The <currentMemory> element determines the actual memory allocation for a guest virtual machine. This value can be less than the maximum allocation (set by <memory> ) to allow for the guest virtual machine memory to balloon as needed. If omitted, this defaults to the same value as the <memory> element. The unit attribute behaves the same as for memory. <domain> <maxMemory slots='16' unit='KiB'>1524288</maxMemory> <memory unit='KiB' dumpCore='off'>524288</memory> <!-- changes the memory unit to KiB and does not allow the guest virtual machine's memory to be included in the generated core dumpfile --> <currentMemory unit='KiB'>524288</currentMemory> <!-- makes the current memory unit 524288 KiB --> ... </domain> Figure 23.10. Memory unit

Commands:
<domain> <maxMemory slots='16' unit='KiB'>1524288</maxMemory> <memory unit='KiB' dumpCore='off'>524288</memory> <!-- changes the memory unit to KiB and does not allow the guest virtual machine's memory to be included in the generated core dumpfile --> <currentMemory unit='KiB'>524288</currentMemory> <!-- makes the current memory unit 524288 KiB --> </domain>
8.153. numactl 8.153.1. RHBA-2014:1483 - numactl bug fix and enhancement update Updated numactl packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The numactl packages add simple Non-Uniform Memory Access (NUMA) policy support. It consists of the numactl program to run other programs with a specific NUMA policy, and the libnuma library to perform allocations with NUMA policy in applications. This update also fixes the following bugs: Note The numactl packages have been upgraded to upstream version 2.0.9, which provides a number of bug fixes and enhancements over the version. (BZ# 1017048 ) This update also fixes the following bugs: Bug Fixes BZ# 812462 Prior to this update, the numa_parse_cpustring() function added an unallowed CPU into its bitmask. As a consequence, only the bits the user has access to were set. Consequently, every time the function was used led to different outcomes. With this update, the numa_parse_cpustring() code sets all bits in the "cpustring" argument regardless of current task's CPU mask, and the aforementioned scenario no longer occurs. BZ# 819133 Previously, the compiler was enforcing libnuma to provide a constant within the "char*" parameter, which led to the following warning message being returned: testconst.c:10:45: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] The underlying source code has been fixed so that the string is handled as a constant, and the user no longer receives warning messages. BZ# 873456 Previously, when the user set the affinity of the shell to be a subset of available CPUs and then attempted to use the numactl utility to bind to something absent from that affinity mask, the attempt failed. An upstream patch has been applied to fix this bug, and the numactl environment has been extended so that the user can choose whether to allow for the affinity mask to determine available CPUs or not. BZ# 1100134 Due to incompatibilities emerging after the latest numactl packages update, virsh processes terminated unexpectedly when any virsh command was run. This bug has been fixed, and the virsh commands now work correctly. The numactl packages have been upgraded to upstream version 2.0.9, which provides a number of bug fixes and enhancements over the version. (BZ#1017048) Users of numactl are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
2.11.5. Displaying Parameters of Control Groups To display the parameters of specific cgroups, run: where parameter is a pseudofile that contains values for a subsystem, and list_of_cgroups is a list of cgroups separated with spaces. For example: displays the values of cpuset.cpus and memory.limit_in_bytes for cgroups group1 and group2 . If you do not know the names of the parameters themselves, use a command like:

Commands:
~]USD cgget -r parameter list_of_cgroups
~]USD cgget -r cpuset.cpus -r memory.limit_in_bytes group1 group2
~]USD cgget -g cpuset /
Chapter 8. Creating the mortgage-process project A project is a container for assets such as data objects, business processes, guided rules, decision tables, and forms. The project that you are creating is similar to the existing Mortgage_Process sample project in Business Central. Procedure In Business Central, go to Menu Design Projects . Red Hat Decision Manager provides a default space called MySpace , as shown in the following image. You can use the default space to create and test example projects. Figure 8.1. Default space Click Add Project . Enter mortgage-process in the Name field. Click Configure Advanced Options and modify the GAV fields with the following values: Group ID : com.myspace Artifact ID : mortgage-process Version : 1.0.0 Click Add . The Assets view of the project opens. 8.1. Modifying the Mortgages sample project The Mortgages sample project consists of predefined data objects, guided decision tables, guided rules, forms, and a business process. Using the sample project provides a quick way to get acclimated with Red Hat Decision Manager. In a real business scenario, you would create all of the assets by providing data that is specific to your business requirements. Navigate to the Mortgages sample project to view the predefined assets. Procedure In Business Central, go to Menu Design Projects . In the upper-right corner of the screen, click the arrow to Add Project and select Try Samples . Select Mortgages and click Ok . The Assets view of the project opens. Click an asset that you want to modify. All of the assets can be edited to meet your project requirements. 8.2. Creating a project using archetypes Archetypes are projects that are installed in Apache Maven repositories and contain a specific template structure. You can also generate parameterized versions of the project templates using archetypes. When you use an archetype to create a project, it is added to the Git repository that is connected to your Red Hat Decision Manager installation. Prerequisites You have created an archetype and added it to the Archetypes page in the Business Central Settings . For information about creating archetypes, see the Guide to Creating Archetypes . You have set a default archetype in your space in Business Central. For more information about archetypes management, see Configuring Business Central settings and properties . Procedure In Business Central, go to Menu Design Projects . Select or create the space into which you want to add a new project from an archetype template. Click Add Project . Type the project name and description in the Name and Description fields. Click Configure Advanced Options . Select the Based on template checkbox. Select the archetype from drop-down options if required. The default archetype is selected that is already set in the space. Click Add . The Assets view of the project opens based on the selected archetype template.

Commands:
Chapter 3. Defining Camel routes Red Hat build of Apache Camel for Quarkus supports the Java DSL language to define Camel Routes. 3.1. Java DSL Extending org.apache.camel.builder.RouteBuilder and using the fluent builder methods available there is the most common way of defining Camel Routes. Here is a simple example of a route using the timer component: import org.apache.camel.builder.RouteBuilder; public class TimerRoute extends RouteBuilder { @Override public void configure() throws Exception { from("timer:foo?period=1000") .log("Hello World"); } } 3.1.1. Endpoint DSL Since Camel 3.0, you can use fluent builders also for defining Camel endpoints. The following is equivalent with the example: import org.apache.camel.builder.RouteBuilder; import static org.apache.camel.builder.endpoint.StaticEndpointBuilders.timer; public class TimerRoute extends RouteBuilder { @Override public void configure() throws Exception { from(timer("foo").period(1000)) .log("Hello World"); } } Note Builder methods for all Camel components are available via camel-quarkus-core , but you still need to add the given component's extension as a dependency for the route to work properly. In case of the above example, it would be camel-quarkus-timer .

Commands:
import org.apache.camel.builder.RouteBuilder; public class TimerRoute extends RouteBuilder { @Override public void configure() throws Exception { from("timer:foo?period=1000") .log("Hello World"); } }
import org.apache.camel.builder.RouteBuilder; import static org.apache.camel.builder.endpoint.StaticEndpointBuilders.timer; public class TimerRoute extends RouteBuilder { @Override public void configure() throws Exception { from(timer("foo").period(1000)) .log("Hello World"); } }
8.10. alsa-utils 8.10.1. RHBA-2014:1603 - alsa-utils bug fix update Updated alsa-utils packages that fix one bug are now available for Red Hat Enterprise Linux 6. The alsa-utils packages containn command line utilities for the Advanced Linux Sound Architecture (ALSA). Bug Fix BZ# 1072956 The alsa-utils packages have been updated with various upstream fixes to improve stability and usage. Users of alsa-utils are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 3. Enhancements This section describes the major enhancements introduced in Red Hat OpenShift Data foundation 4.16. 3.1. New elements for bucket policies OpenShift Data Foundation now has the bucket policy elements, NotPrincipal , NotAction , and NotResource . For more information on these elements, see IAM JSON policy elements reference . 3.2. Addition of a new AWS region to the Multicloud Object Gateway Operator A new AWS region, ca-west-1 , is added to the supported regions of the Multicloud Object Gateway (MCG) operator for the creation of default backingstore. 3.3. Increase in resource allocation for OpenShift Data Foundation Multicloud Object Gateway BackingStore The default resources for PV pool CPU and memory are increased to 999m and 1Gi respectively to enable more resource allocation for OpenShift Data Foundation MCG BackingStore. 3.4. Multicloud Object Gateway created routes to work with HTTPS only For deployments that need to disable HTTP and use only HTTPS, an option is added to set DenyHTTP to the storage cluster CR spec.multiCloudGateway.denyHTTP . This causes the Multicloud Object Gateway created routes to use HTTPS only. 3.5. Addition of protected condition to DR protected workloads with metrics and alerts for monitoring Protected condition to DR protected workloads is added by summarizing various conditions regarding the DR protected workload from the ManagedCluster , and metrics and alerts are generated based on the same. DR protected workload health at the hub is reflected based only on the time when contents of the respective PVCs are synced. This applies only to RegionalDR use cases and not to MetroDR use cases. On the ManagedCluster , the workload DR protection health is expanded into several conditions. This makes it non-trivial for a user to monitor the workload DR health across these conditions. This added protected condition and alerts helps better workload DR protection monitoring. 3.6. Support for listing multiple uploads in NamespaceStore Filesystem You can now list the files that are still uploading or list incomplete multipart uploads in NamespaceStore Filesystem by using the following command: 3.7. Option to modify thresholds for Ceph full , nearfull , and backfillfull attributes Depending on the cluster requirements, the full , nearfull , and backfillfull threshold values can be updated by using the odf-cli CLI command. For example: odf set full <val> odf set nearful <val> odf set backfillfull <val> Note The value must be in the range of 0.0 to 1.0 and you need to ensure that the value is not very close to 1.0.

Commands:
s3api list--multipart-uploads --bucket <bucket_name>
Chapter 8. Documentation Supported configurations Check the latest information about 3scale 2.15 supported configurations at the Red Hat 3scale API Management Supported Configurations website. Security updates Check the latest information about 3scale 2.15 security updates in the Red Hat Product Advisories portal. Erratas Advisory for the Container Images: RHEA-2023:112722 Upgrade guides Check the procedures to upgrade your 3scale installation from 2.13 to 2.14, for the following deployments: Based on operators APIcast in operator-based deployments

Commands:
Chapter 1. Introduction to scaling storage Red Hat OpenShift Data Foundation is highly scalable storage system. OpenShift Data Foundation allows you to scale by adding the disks in the multiple of three, or three or any number depending upon the deployment type. For internal (dynamic provisioning) deployment mode, you can increase the capacity by adding 3 disks at a time. For internal-attached (Local Storage Operator based) mode, you can deploy with less than 3 failure domains. With flexible scale deployment enabled, you can scale up by adding any number of disks. For deployment with 3 failure domains, you will be able to scale up by adding disks in the multiple of 3. For scaling your storage in external mode, see Red Hat Ceph Storage documentation . Note You can use a maximum of nine storage devices per node. The high number of storage devices will lead to a higher recovery time during the loss of a node. This recommendation ensures that nodes stay below the cloud provider dynamic storage device attachment limits, and limits the recovery time after node failure with local storage devices. While scaling, you must ensure that there are enough CPU and Memory resources as per scaling requirement. Supported storage classes by default gp2-csi on AWS thin on VMware ovirt-csi-sc on Red Hat Virtualization managed_premium on Microsoft Azure 1.1. Supported Deployments for Red Hat OpenShift Data Foundation User-provisioned infrastructure: Amazon Web Services (AWS) VMware Bare metal IBM Power IBM Z or IBM(R) LinuxONE Installer-provisioned infrastructure: Amazon Web Services (AWS) Microsoft Azure Red Hat Virtualization VMware Bare metal

Commands:
Chapter 5. Container images with Go Toolset You can build your own Go Toolset containers from either Red Hat Enterprise Linux container images or Red Hat Universal Base Images (UBI). 5.1. Red Hat Enterprise Linux Go Toolset container images contents The Red Hat Enterprise Linux 8 and Red Hat Enterprise Linux 9 container images of Go Toolset contain the following packages: Component Version Package Go 1.22 RHEL 8 - go-toolset-1.22 RHEL 9 - go-toolset-1.22 5.2. Accessing Red Hat Enterprise Linux container images Pull the container image from the Red Hat registry before running your container and performing actions. Procedure To pull the required image, run: For an image based on Red Hat Enterprise Linux 8: For an image based on Red Hat Enterprise Linux 9: 5.3. Accessing the UBI Go Toolset container image on RHEL 8 On RHEL 8, install the UBI Go Toolset container image to access Go Toolset. Alternatively, you can install Go Toolset to the RHEL 8 base UBI container image. For further information, see Accessing Go Toolset from the base UBI container image on RHEL 8 . Procedure To pull the UBI Go Toolset container image from the Red Hat registry, run: On Red Hat Enterprise Linux 8 On Red Hat Enterprise Linux 9 5.4. Accessing Go Toolset from the base UBI container image on RHEL 8 On RHEL 8, Go Toolset packages are part of the Red Hat Universal Base Images (UBIs) repositories, which means you can install Go Toolset as an addition to the base UBI container image. To keep the container image size small, install only individual packages instead of the entire Go Toolset. Alternatively, you can install the UBI Go Toolset container image to access Go Toolset. For further information, see Accessing the UBI Go Toolset container image on RHEL 8 . Prerequisites An existing Containerfile. For information on creating Containerfiles, see the Dockerfile reference page. Procedure To create a container image containing Go Toolset, add the following lines to your Containerfile: To create a container image containing an individual package only, add the following lines to your Containerfile: Replace < package-name > with the name of the package you want to install. 5.5. Additional resources Go Toolset Container Images in the Red Hat Container Registry . For more information on Red Hat UBI images, see Working with Container Images . For more information on Red Hat UBI repositories, see Universal Base Images (UBI): Images, repositories, packages, and source code .

Commands:
podman pull registry.redhat.io/rhel8/go-toolset
podman pull registry.redhat.io/rhel9/go-toolset
podman pull registry.access.redhat.com/ubi8/go-toolset
podman pull registry.access.redhat.com/ubi9/go-toolset
FROM registry.access.redhat.com/ubi8/ubi: latest RUN yum module install -y go-toolset
RUN yum install -y < package-name >
9.2. The Graphical Installation Program User Interface If you have used a graphical user interface (GUI) before, you are already familiar with this process; use your mouse to navigate the screens, click buttons, or enter text fields. You can also navigate through the installation using the keyboard. The Tab key allows you to move around the screen, the Up and Down arrow keys to scroll through lists, + and - keys expand and collapse lists, while Space and Enter selects or removes from selection a highlighted item. You can also use the Alt + X key command combination as a way of clicking on buttons or making other screen selections, where X is replaced with any underlined letter appearing within that screen. Note If you are using an x86, AMD64, or Intel 64 system, and you do not wish to use the GUI installation program, the text mode installation program is also available. To start the text mode installation program, use the following command at the boot: prompt: Refer to Section 7.1.2, "The Boot Menu" for a description of the Red Hat Enterprise Linux boot menu and to Section 8.1, "The Text Mode Installation Program User Interface" for a brief overview of text mode installation instructions. It is highly recommended that installs be performed using the GUI installation program. The GUI installation program offers the full functionality of the Red Hat Enterprise Linux installation program, including LVM configuration which is not available during a text mode installation. Users who must use the text mode installation program can follow the GUI installation instructions and obtain all needed information. 9.2.1. Screenshots During Installation Anaconda allows you to take screenshots during the installation process. At any time during installation, press Shift + Print Screen and anaconda will save a screenshot to /root/anaconda-screenshots . If you are performing a Kickstart installation, use the autostep --autoscreenshot option to generate a screenshot of each step of the installation automatically. Refer to Section 32.3, "Creating the Kickstart File" for details of configuring a Kickstart file.

Commands:
linux text
23.4. Stacking I/O Parameters All layers of the Linux I/O stack have been engineered to propagate the various I/O parameters up the stack. When a layer consumes an attribute or aggregates many devices, the layer must expose appropriate I/O parameters so that upper-layer devices or tools will have an accurate view of the storage as it transformed. Some practical examples are: Only one layer in the I/O stack should adjust for a non-zero alignment_offset ; once a layer adjusts accordingly, it will export a device with an alignment_offset of zero. A striped Device Mapper (DM) device created with LVM must export a minimum_io_size and optimal_io_size relative to the stripe count (number of disks) and user-provided chunk size. In Red Hat Enterprise Linux 6, Device Mapper and Software Raid (MD) device drivers can be used to arbitrarily combine devices with different I/O parameters. The kernel's block layer will attempt to reasonably combine the I/O parameters of the individual devices. The kernel will not prevent combining heterogeneous devices; however, be aware of the risks associated with doing so. For instance, a 512-byte device and a 4K device may be combined into a single logical DM device, which would have a logical_block_size of 4K. File systems layered on such a hybrid device assume that 4K will be written atomically, but in reality it will span 8 logical block addresses when issued to the 512-byte device. Using a 4K logical_block_size for the higher-level DM device increases potential for a partial write to the 512-byte device if there is a system crash. If combining the I/O parameters of multiple devices results in a conflict, the block layer may issue a warning that the device is susceptible to partial writes and/or is misaligned.

Commands:
2.6. File System Backups It is important to make regular backups of your GFS2 file system in case of emergency, regardless of the size of your file system. Many system administrators feel safe because they are protected by RAID, multipath, mirroring, snapshots, and other forms of redundancy, but there is no such thing as safe enough. It can be a problem to create a backup since the process of backing up a node or set of nodes usually involves reading the entire file system in sequence. If this is done from a single node, that node will retain all the information in cache until other nodes in the cluster start requesting locks. Running this type of backup program while the cluster is in operation will negatively impact performance. Dropping the caches once the backup is complete reduces the time required by other nodes to regain ownership of their cluster locks/caches. This is still not ideal, however, because the other nodes will have stopped caching the data that they were caching before the backup process began. You can drop caches using the following command after the backup is complete: It is faster if each node in the cluster backs up its own files so that the task is split between the nodes. You might be able to accomplish this with a script that uses the rsync command on node-specific directories. The best way to make a GFS2 backup is to create a hardware snapshot on the SAN, present the snapshot to another system, and back it up there. The backup system should mount the snapshot with -o lockproto=lock_nolock since it will not be in a cluster.

Commands:
echo -n 3 > /proc/sys/vm/drop_caches