mtpti5iD/redhat-docs_dataset huggingface dataset:
3.3.3. Command-Line Arguments You can also allow a SystemTap script to accept simple command-line arguments using a USD or @ immediately followed by the number of the argument on the command line. Use USD if you are expecting the user to enter an integer as a command-line argument, and @ if you are expecting a string. Example 3.10. commandlineargs.stp Example 3.10, "commandlineargs.stp" is similar to Example 3.1, "wildcards.stp" , except that it allows you to pass the kernel function to be probed as a command-line argument (as in stap commandlineargs.stp kernel function ). You can also specify the script to accept multiple command-line arguments, noting them as @1 , @2 , and so on, in the order they are entered by the user.

Commands:
probe kernel.function(@1) { } probe kernel.function(@1).return { }
Chapter 7. Backing up important files Backing up important configuration files, inventory files, and modified playbooks makes it easy to restore or redeploy your cluster. Red Hat recommends backing up your configuration after initial deployment, and after confirming the success of any major changes in your cluster. You can also take backups after a node has failed if necessary. Prerequisites Example playbooks and inventory files are stored in the /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment directory. If you have manually created or modified inventory and playbook files and you are not storing them in this directory, ensure that you know the path to their location. Procedure Log in to a hyperconverged host as the root user. Change into the hc-ansible-deployment directory and back up the default archive_config_inventory.yml file. Edit the archive_config_inventory.yml file with details of the cluster you want to back up. hosts The backend FQDN of each host in the cluster that you want to back up. backup_dir The directory in which to store backup files. nbde_setup If you use Network-Bound Disk Encryption, set this to true . Otherwise, set to false . upgrade Set to false . For example: Run the archive_config.yml playbook using your updated inventory file with the backupfiles tag. This creates an archive in the /root directory specific to each host FQDN in the hosts section of the inventory, for example, /root/rhvh-node-host1-backend.example.com-backup.tar.gz . Transfer the backup archives to a different machine.

Commands:
cd /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment cp archive_config_inventory.yml archive_config_inventory.yml.bk
all: hosts: host1-backend.example.com : host2-backend.example.com : host3-backend.example.com : vars: backup_dir: /rhhi-backup nbde_setup: true upgrade: false
ansible-playbook -i archive_config_inventory.yml archive_config.yml --tags=backupfiles
scp /root/rhvh-node-host1-backend.example.com-backup.tar.gz backup-host.example.com:/backups/
Chapter 9. Viewing and managing JMX domains and MBeans Java Management Extensions (JMX) is a Java technology that allows you to manage resources (services, devices, and applications) dynamically at runtime. The resources are represented by objects called MBeans (for Managed Bean). You can manage and monitor resources as soon as they are created, implemented, or installed. With the JMX plugin on HawtIO, you can view and manage JMX domains and MBeans. You can view MBean attributes, run commands, and create charts that show statistics for the MBeans. The JMX tab provides a tree view of the active JMX domains and MBeans organized in folders. You can view details and execute commands on the MBeans. Procedure : To view and edit MBean attributes : In the tree view, select an MBean. Click the Attributes tab. Click an attribute to see its details. To perform operations : In the tree view, select an MBean. Click the Operations tab, expand one of the listed operations. Click Execute to run the operation. To view charts : In the tree view, select an item. Click the Chart tab.

Commands:
Appendix H. Using your subscription AMQ Streams is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the AMQ Streams for Apache Kafka entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ Streams product. The Software Downloads page opens. Click the Download link for your component. Revised on 2024-03-20 09:52:55 UTC

Commands:
9.16. Red Hat JBoss Data Grid and Complex Data Types Note When you use Teiid Designer to reverse-engineer the view into a pojo, a BigDecimal data type is defined in the view. Unfortunately for the Google Protobuf used for serialization, complex data types cannot be converted to either C or C++. It is therefore recommended that you use primitive data types only. (You will come across this situation if you are trying to materialize a view that contains a complex data type or if there is an existing JDG cache that contains a POJO that has complex data types.) As the protobuffer does not support BigDecimal directly, you have three options: use all primitive data types implement a marshaller that will handle the conversion, which means the .proto file will also need to be created (see Red Hat JBoss Data Grid for the creation of files) create a view that will convert the BigdDecimal to a string, then materialize that view.

Commands:
Chapter 162. KafkaNodePoolStatus schema reference Used in: KafkaNodePool Property Property type Description conditions Condition array List of status conditions. observedGeneration integer The generation of the CRD that was last reconciled by the operator. nodeIds integer array Node IDs used by Kafka nodes in this pool. clusterId string Kafka cluster ID. roles string (one or more of [controller, broker]) array Added in Streams for Apache Kafka 2.7. The roles currently assigned to this pool. replicas integer The current number of pods being used to provide this resource. labelSelector string Label selector for pods providing this resource.

Commands:
Chapter 1. Integrating and certifying with RHOSO This guide describes the process for Partners to integrate Partner solutions, such as drivers (Storage, Networking) or application workloads (VNF, NFV), with Red Hat OpenStack Services on OpenShift (RHOSO), before certifying the solutions. Upon the successful integration of the Partner solution with RHOSO, Partners can then proceed with Red Hat OpenStack Certification. Red Hat OpenStack Certification is offered to Partners who want to offer their solutions for use with RHOSO in a jointly-supported customer environment. For more information about the certification process, see the Product Documentation for Red Hat Software Certification 1.1. General Certification Prerequisites If this is your first time certifying your solution with RHOSO, or you need a refresh on the Red Hat Partner process, you can request an orientation session with the Red Hat Technology Partner Success Desk (TPSD) of the Ecosystem Partner Management (EPM) Team. Select the "Certification" for the category and Red Hat OpenStack Platform for the product. The orientation session is to review the requirements for the certification process and answer any questions that you might have. The following are certification prerequisites and integration points for OpenStack drivers for the Block storage service (cinder), the File storage services (manila), and the Networking service (neutron). Ensure that you review the prerequisites for any OpenStack driver or service before you progress further.

Commands:
Preface This document provides instructions for installing and configuring the Bare Metal service (ironic) in the overcloud, and using the service to provision and manage physical machines for end users. The Bare Metal service components are also used by the Red Hat OpenStack Platform director, as part of the undercloud, to provision and manage the bare metal nodes that make up the OpenStack environment (the overcloud). For more information about how the director uses the Bare Metal service, see the Director Installation and Usage guide.

Commands:
22.4.4. Installing via NFS The NFS dialog applies only if you selected NFS Image in the Installation Method dialog. If you used the repo=nfs boot option, you already specified a server and path. Figure 22.6. NFS Setup Dialog Enter the domain name or IP address of your NFS server in the NFS server name field. For example, if you are installing from a host named eastcoast in the domain example.com , enter eastcoast.example.com . Enter the name of the exported directory in the Red Hat Enterprise Linux 6.9 directory field: If the NFS server is exporting a mirror of the Red Hat Enterprise Linux installation tree, enter the directory which contains the root of the installation tree. If everything was specified properly, a message appears indicating that the installation program for Red Hat Enterprise Linux is running. If the NFS server is exporting the ISO image of the Red Hat Enterprise Linux DVD, enter the directory which contains the ISO image. If you followed the setup described in Section 19.1.2, "Preparing for an NFS Installation" , the exported directory is the one that you specified as publicly_available_directory . Specify any NFS mount options that you require in the NFS mount options field. Refer to the man pages for mount and nfs for a comprehensive list of options. If you do not require any mount options, leave the field empty. Proceed with Chapter 23, Installation Phase 3: Installing Using Anaconda .

Commands:
11.2. Volumes Storage pools are divided into storage volumes. Storage volumes are an abstraction of physical partitions, LVM logical volumes, file-based disk images and other storage types handled by libvirt. Storage volumes are presented to guest virtual machines as local storage devices regardless of the underlying hardware. Referencing Volumes To reference a specific volume, three approaches are possible: The name of the volume and the storage pool A volume may be referred to by name, along with an identifier for the storage pool it belongs in. On the virsh command line, this takes the form --pool storage_pool volume_name . For example, a volume named firstimage in the guest_images pool. The full path to the storage on the host physical machine system A volume may also be referred to by its full path on the file system. When using this approach, a pool identifier does not need to be included. For example, a volume named secondimage.img , visible to the host physical machine system as /images/secondimage.img . The image can be referred to as /images/secondimage.img . The unique volume key When a volume is first created in the virtualization system, a unique identifier is generated and assigned to it. The unique identifier is termed the volume key . The format of this volume key varies upon the storage used. When used with block based storage such as LVM, the volume key may follow this format: When used with file based storage, the volume key may instead be a copy of the full path to the volume storage. For example, a volume with the volume key of Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr : virsh provides commands for converting between a volume name, volume path, or volume key: vol-name Returns the volume name when provided with a volume path or volume key. vol-path Returns the volume path when provided with a volume key, or a storage pool identifier and volume name. The vol-key command Returns the volume key when provided with a volume path, or a storage pool identifier and volume name.

Commands:
virsh vol-info --pool guest_images firstimage Name: firstimage Type: block Capacity: 20.00 GB Allocation: 20.00 GB virsh #
virsh vol-info /images/secondimage.img Name: secondimage.img Type: file Capacity: 20.00 GB Allocation: 136.00 kB
c3pKz4-qPVc-Xf7M-7WNM-WJc8-qSiz-mtvpGn
/images/secondimage.img
virsh vol-info Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr Name: firstimage Type: block Capacity: 20.00 GB Allocation: 20.00 GB
virsh vol-name /dev/ guest_images / firstimage firstimage virsh vol-name Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr
virsh vol-path Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr /dev/ guest_images / firstimage virsh vol-path --pool guest_images firstimage /dev/ guest_images / firstimage
virsh vol-key /dev/ guest_images / firstimage Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr virsh vol-key --pool guest_images firstimage Wlvnf7-a4a3-Tlje-lJDa-9eak-PZBv-LoZuUr
16.2. Key Benefits of Tiering (Deprecated) Warning Tiering is considered deprecated as of Red Hat Gluster Storage 3.5. Red Hat no longer recommends its use, and does not support tiering in new deployments and existing deployments that upgrade to Red Hat Gluster Storage 3.5.3. The following are the key benefits of data tiering: Automatic classification and movement of files based on the access patterns Faster response time and reduced latency Better I/O performance Improved data-storage efficiency Reduced deployment and operating costs

Commands:
Chapter 5. Updating an image You can update the packages and the package version for an image you have already created. For that, you can use one of the following options to perform the update. Use the Update button in the dashboard to add the latest package version update to the image. Use the More options icon (...) to the image you plan to update to be able to choose the package version to update your image. For example, if the system is running the version 2 and you are running the version 5, you can pick one of the versions between 2 and 5 to update the image. Warning Using RHEL for Edge customized images that were created using the on-premise version of RHEL image builder is not supported in the Red Hat Hybrid Cloud Console. There is no support for updating an Edge system by using the CLI. You can only update your Edge systems by using the Red Hat Hybrid Cloud Console. Prerequisites You must have a Red Hat Hybrid Cloud Console account. You must have built an image in the Red Hat Hybrid Cloud Console. Procedure Access Red Hat Hybrid Cloud Console platform and log in. From the console dashboard, navigate to Red Hat Insights > RHEL > Inventory > Images . The Insights image builder environment opens. In the image builder application, click the Immutable (OSTree) tab. Choose between one of the 2 ways to update your image: Either the click the Update button or click the More options icon (...) . Click Update image . On the Update image: image-name wizard, follow the steps: On the Details page, enter a description for the image. Click . On the Options page, follow the steps: Select the image base release for your image. To build an update, clear the RHEL for Edge installer (.iso) check box. Click . On the Content page: On the Additional Red Hat packages page, add any core RHEL package, for example, emacs . In the Available packages search field, enter emacs and click the search icon. Select emacs from the search results. Click the Add Selected or Add all arrow button to add emacs to the list. Click . On the Custom repositories page: Select the custom repository you added. On the Additional custom packages page: Add the packages that you want. Click . On the Review page: Check the data is correct and click Update image . Additional resources How to start the upgrade process of an Edge Management deployed system . Edge Management supportability .

Commands:
Chapter 2. Configure User Access to manage notifications To configure notifications settings, you must be a member of a group with the Notifications administrator role. This group must be configured in User Access by an Organization Administrator. In the Red Hat Hybrid Cloud Console > Settings > Identity & Access Management > User Access > Groups , an Organization Administrator performs the following high-level steps: Create a User Access group for Notifications administrators. Add the Notifications administrator role to the group. Add members (users with account access) to the group. Organization Administrator The Organization Administrator configures the User Access group for Notifications administrators, then adds the Notifications administrator role and users to the group. Notifications administrator Notifications administrators configure how services interact with notifications. Notifications administrators configure behavior groups to define how services notify users about events. Notifications viewer The Notifications viewer role is automatically granted to everyone on the account and limits how a user can interact with notifications service views and configurations. A viewer can view notification configurations, but cannot modify or remove them. Additional resources To learn more about User Access on the Red Hat Hybrid Cloud Console, see the User Access Configuration Guide for Role-based Access Control (RBAC) with FedRAMP . 2.1. Creating and configuring a notifications group in the Hybrid Cloud Console An Organization Administrator of a Hybrid Cloud Console account creates a group with the Notifications administrator role and adds members to the group. Prerequisites You are logged in to the Red Hat Hybrid Cloud Console as an Organization Administrator. Procedure Click Settings . Under Identity & Access Management , click User Access . In the left navigation panel, expand User Access if necessary and then click Groups . Click Create group . Enter a group name, for example, Notifications administrators , and a description, and then click . Select the role to add to this group, in this case Notifications administrator , and then click . Add members to the group: Search for individual users or filter by username, email, or status. Check the box to each intended member's name, and then click . On the Review details screen, click Submit to finish creating the group. 2.2. Editing or removing a User Access group You can make changes to an existing User Access group in the Red Hat Hybrid Cloud Console and you can delete groups that are no longer needed. Prerequisites You are logged in to the Red Hat Hybrid Cloud Console and meet one of the following criteria: You are a user with Organization Administrator permissions. You are a member of a group that has the User Access administrator role assigned to it. Procedure Navigate to Red Hat Hybrid Cloud Console > Settings > Identity & Access Management > User Access > Groups . Click the options icon (...) on the far right of the group name row, and then click Edit or Delete . Make and save changes or delete the group.

Commands:
Chapter 6. Verifying the post-upgrade state After performing the in-place upgrade to RHEL 9, verify that the system is in the correct state. Doing so allows you to identify and correct any critical errors that could impact your system. 6.1. Verifying the post-upgrade state of the RHEL 9 system This procedure lists Verification recommended to perform after an in-place upgrade to RHEL 9. Prerequisites The system has been upgraded following the steps described in Performing the upgrade and you have been able to log in to RHEL 9. Procedure After the upgrade completes, determine whether the system is in the required state, at least: Verify that the current OS version is RHEL 9. For example: Check the OS kernel version. For example: Note that .el9 is important and the version should not be earlier than 5.14.0. If you are using the Red Hat Subscription Manager: Verify that the correct product is installed. For example: Verify that the release version is set to the expected target OS version immediately after the upgrade. For example: Verify that network services are operational, for example, try to connect to a server using SSH. Check the post-upgrade status of your applications. In some cases, you may need to perform migration and configuration changes manually. For example, to migrate your databases, follow instructions in Configuring and using database servers .

Commands:
cat /etc/redhat-release Red Hat Enterprise Linux release 9.4 (Plow)
uname -r 5.14.0-70.10.1.el9_0.x86_64
subscription-manager list --installed +-----------------------------------------+ Installed Product Status +-----------------------------------------+ Product Name: Red Hat Enterprise Linux for x86_64 Product ID: 479 Version: 9.4 Arch: x86_64 Status: Subscribed
subscription-manager release Release: 9.4
Chapter 3. Block pools The OpenShift Data Foundation operator installs a default set of storage pools depending on the platform in use. These default storage pools are owned and controlled by the operator and it cannot be deleted or modified. Note Multiple block pools are not supported for external mode OpenShift Data Foundation clusters. 3.1. Managing block pools in internal mode With OpenShift Container Platform, you can create multiple custom storage pools which map to storage classes that provide the following features: Enable applications with their own high availability to use persistent volumes with two replicas, potentially improving application performance. Save space for persistent volume claims using storage classes with compression enabled. 3.1.1. Creating a block pool Prerequisites You must be logged into the OpenShift Container Platform web console as an administrator. Procedure Click Storage Data Foundation . In the Storage systems tab, select the storage system and then click the BlockPools tab. Click Create Block Pool . Enter Pool name . Note Using 2-way replication data protection policy is not supported for the default pool. However, you can use 2-way replication if you are creating an additional pool. Select Data protection policy as either 2-way Replication or 3-way Replication . Optional: Select Enable compression checkbox if you need to compress the data. Enabling compression can impact application performance and might prove ineffective when data to be written is already compressed or encrypted. Data written before enabling compression is not compressed. Click Create . 3.1.2. Updating an existing pool Prerequisites You must be logged into the OpenShift Container Platform web console as an administrator. Procedure Click Storage Data Foundation . In the Storage systems tab, select the storage system and then click BlockPools . Click the Action Menu (...) at the end the pool you want to update. Click Edit Block Pool . Modify the form details as follows: Note Using 2-way replication data protection policy is not supported for the default pool. However, you can use 2-way replication if you are creating an additional pool. Change the Data protection policy to either 2-way Replication or 3-way Replication. Enable or disable the compression option. Enabling compression can impact application performance and might prove ineffective when data to be written is already compressed or encrypted. Data written before enabling compression is not compressed. Click Save . 3.1.3. Deleting a pool Use this procedure to delete a pool in OpenShift Data Foundation. Prerequisites You must be logged into the OpenShift Container Platform web console as an administrator. Procedure . Click Storage Data Foundation . In the Storage systems tab, select the storage system and then click the BlockPools tab. Click the Action Menu (...) at the end the pool you want to delete. Click Delete Block Pool . Click Delete to confirm the removal of the Pool. Note A pool cannot be deleted when it is bound to a PVC. You must detach all the resources before performing this activity.

Commands: