mtpti5iD/redhat-docs_dataset huggingface dataset:
4.30. WTI Power Switch Table 4.31, "WTI Power Switch" lists the fence device parameters used by fence_wti , the fence agent for the WTI network power switch. Table 4.31. WTI Power Switch luci Field cluster.conf Attribute Description Name name A name for the WTI power switch connected to the cluster. IP Address or Hostname ipaddr The IP or address or host name assigned to the device. IP Port (optional) ipport The TCP port to use to connect to the device. Login login The login name used to access the device. Password passwd The password used to authenticate the connection to the device. Password Script (optional) passwd_script The script that supplies a password for access to the fence device. Using this supersedes the Password parameter. Force command prompt cmd_prompt The command prompt to use. The default value is ['RSM>', '>MPC', 'IPS>', 'TPS>', 'NBB>', 'NPS>', 'VMR>'] Power Wait (seconds) power_wait Number of seconds to wait after issuing a power off or power on command. Power Timeout (seconds) power_timeout Number of seconds to continue testing for a status change after issuing a power off or power on command. The default value is 20. Shell Timeout (seconds) shell_timeout Number of seconds to wait for a command prompt after issuing a command. The default value is 3. Login Timeout (seconds) login_timeout Number of seconds to wait for a command prompt after login. The default value is 5. Times to Retry Power On Operation retry_on Number of attempts to retry a power on operation. The default value is 1. Use SSH secure Indicates that system will use SSH to access the device. When using SSH, you must specify either a password, a password script, or an identity file. SSH Options ssh_options SSH options to use. The default value is -1 -c blowfish . Path to SSH Identity File identity_file The identity file for SSH. Port port Physical plug number or name of virtual machine. Figure 4.23, "WTI Fencing" shows the configuration screen for adding a WTI fence device Figure 4.23. WTI Fencing The following command creates a fence device instance for a WTI fence device: The following is the cluster.conf entry for the fence_wti device:

Commands:
ccs -f cluster.conf --addfencedev wtipwrsw1 agent=fence_wti cmd_prompt=VMR> login=root passwd=password123 power_wait=60
<fencedevices> <fencedevice agent="fence_wti" cmd_prompt="VMR&gt;" ipaddr="192.168.0.1" login="root" name="wtipwrsw1" passwd="password123" power_wait="60"/> </fencedevices>
Chapter 15. Displaying resource constraints and resource dependencies There are a several commands you can use to display constraints that have been configured. You can display all configured resource constraints, or you can limit the display of esource constraints to specific types of resource constraints. Additionally, you can display configured resource dependencies. Displaying all configured constraints The following command lists all current location, order, and colocation constraints. If the --full option is specified, show the internal constraint IDs. As of RHEL 8.2, listing resource constraints no longer by default displays expired constraints. To include expired constaints in the listing, use the --all option of the pcs constraint command. This will list expired constraints, noting the constraints and their associated rules as (expired) in the display. Displaying location constraints The following command lists all current location constraints. If resources is specified, location constraints are displayed per resource. This is the default behavior. If nodes is specified, location constraints are displayed per node. If specific resources or nodes are specified, then only information about those resources or nodes is displayed. Displaying ordering constraints The following command lists all current ordering constraints. Displaying colocation constraints The following command lists all current colocation constraints. Displaying resource-specific constraints The following command lists the constraints that reference specific resources. Displaying resource dependencies (Red Hat Enterprise Linux 8.2 and later) The following command displays the relations between cluster resources in a tree structure. If the --full option is used, the command displays additional information, including the constraint IDs and the resource types. In the following example, there are 3 configured resources: C, D, and E. In the following example, there are 2 configured resources: A and B. Resources A and B are part of resource group G.

Commands:
pcs constraint [list|show] [--full]
pcs constraint location [show [resources [ resource ...]] | [nodes [ node ...]]] [--full]
pcs constraint order [show]
pcs constraint colocation [show]
pcs constraint ref resource
pcs resource relations resource [--full]
pcs constraint order start C then start D Adding C D (kind: Mandatory) (Options: first-action=start then-action=start) pcs constraint order start D then start E Adding D E (kind: Mandatory) (Options: first-action=start then-action=start) pcs resource relations C C `- order | start C then start D `- D `- order | start D then start E `- E pcs resource relations D D |- order | | start C then start D | `- C `- order | start D then start E `- E pcs resource relations E E `- order | start D then start E `- D `- order | start C then start D `- C
pcs resource relations A A `- outer resource `- G `- inner resource(s) | members: A B `- B pcs resource relations B B `- outer resource `- G `- inner resource(s) | members: A B `- A pcs resource relations G G `- inner resource(s) | members: A B |- A `- B
Chapter 1. Getting started with functions Function lifecycle management includes creating and deploying a function, after which it can be invoked. You can do all of these operations on OpenShift Serverless using the kn func tool. 1.1. Prerequisites To enable the use of OpenShift Serverless Functions on your cluster, you must complete the following steps: The OpenShift Serverless Operator and Knative Serving are installed on your cluster. Note Functions are deployed as a Knative service. If you want to use event-driven architecture with your functions, you must also install Knative Eventing. You have the oc CLI installed. You have the Knative ( kn ) CLI installed. Installing the Knative CLI enables the use of kn func commands which you can use to create and manage functions. You have installed Docker Container Engine or Podman version 3.4.7 or higher. You have access to an available image registry, such as the OpenShift Container Registry. If you are using Quay.io as the image registry, you must ensure that either the repository is not private, or that you have followed the OpenShift Container Platform documentation on Allowing pods to reference images from other secured registries . If you are using the OpenShift Container Registry, a cluster administrator must expose the registry . 1.2. Creating, deploying, and invoking a function On OpenShift Serverless, you can use the kn func to create, deploy, and invoke a function. Procedure Create a function project: USD kn func create -l <runtime> -t <template> <path> Example command USD kn func create -l typescript -t cloudevents examplefunc Example output Created typescript function in /home/user/demo/examplefunc Navigate to the function project directory: Example command USD cd examplefunc Build and run the function locally: Example command USD kn func run Deploy the function to your cluster: USD kn func deploy Example output Function deployed at: http://func.example.com Invoke the function: USD kn func invoke This invokes either a locally or remotely running function. If both are running, the local one is invoked. 1.3. Additional resources for OpenShift Container Platform Exposing a default registry manually Marketplace page for the Intellij Knative plugin Marketplace page for the Visual Studio Code Knative plugin Creating applications using the Developer perspective 1.4. steps See Using functions with Knative Eventing

Commands:
kn func create -l <runtime> -t <template> <path>
kn func create -l typescript -t cloudevents examplefunc
Created typescript function in /home/user/demo/examplefunc
cd examplefunc
kn func run
kn func deploy
Function deployed at: http://func.example.com
kn func invoke
C.2.3. Window Managers Window managers are X client programs which are either part of a desktop environment or, in some cases, stand-alone. Their primary purpose is to control the way graphical windows are positioned, resized, or moved. Window managers also control title bars, window focus behavior, and user-specified key and mouse button bindings. The Red Hat Enterprise Linux repositories provide five different window managers. metacity The Metacity window manager is the default window manager for GNOME. It is a simple and efficient window manager which supports custom themes. This window manager is automatically pulled in as a dependency when the GNOME desktop is installed. kwin The KWin window manager is the default window manager for KDE. It is an efficient window manager which supports custom themes. This window manager is automatically pulled in as a dependency when the KDE desktop is installed. compiz The Compiz compositing window manager is based on OpenGL and can use 3D graphics hardware to create fast compositing desktop effects for window management. Advanced features, such as a cube workspace, are implemented as loadable plug-ins. To run this window manager, you need to install the compiz package. mwm The Motif Window Manager ( mwm ) is a basic, stand-alone window manager. Since it is designed to be stand-alone, it should not be used in conjunction with GNOME or KDE. To run this window manager, you need to install the openmotif package. twm The minimalist Tab Window Manager ( twm ), which provides the most basic tool set among the available window managers, can be used either as a stand-alone or with a desktop environment. To run this window manager, you need to install the xorg-x11-twm package.

Commands:
Chapter 111. AclRuleTopicResource schema reference Used in: AclRule The type property is a discriminator that distinguishes use of the AclRuleTopicResource type from AclRuleGroupResource , AclRuleClusterResource , AclRuleTransactionalIdResource . It must have the value topic for the type AclRuleTopicResource . Property Property type Description type string Must be topic . name string Name of resource for which given ACL rule applies. Can be combined with patternType field to use prefix pattern. patternType string (one of [prefix, literal]) 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 .

Commands:
Appendix A. Using your subscription AMQ is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. A.1. Accessing your account Procedure Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. A.2. Activating a subscription Procedure Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. A.3. Downloading release files To access .zip, .tar.gz, and other release files, use the customer portal to find the relevant files for download. If you are using RPM packages or the Red Hat Maven repository, this step is not required. Procedure Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Red Hat AMQ entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ product. The Software Downloads page opens. Click the Download link for your component. A.4. Registering your system for packages To install RPM packages for this product on Red Hat Enterprise Linux, your system must be registered. If you are using downloaded release files, this step is not required. Procedure Go to access.redhat.com . Navigate to Registration Assistant . Select your OS version and continue to the page. Use the listed command in your system terminal to complete the registration. For more information about registering your system, see one of the following resources: Red Hat Enterprise Linux 6 - Registering the system and managing subscriptions Red Hat Enterprise Linux 7 - Registering the system and managing subscriptions Red Hat Enterprise Linux 8 - Registering the system and managing subscriptions Revised on 2020-10-08 11:31:52 UTC

Commands:
Chapter 8. The Backup and Restore API The backup and restore API is a collection of functions that allows you to perform full or file-level backup and restoration of virtual machines. The API combines several components of Red Hat Virtualization, such as live snapshots and the REST API , to create and work with temporary volumes that can be attached to a virtual machine containing backup software provided by an independent software provider. For supported third-party backup vendors, consult the Red Hat Virtualization Ecosystem at Red Hat Marketplace . 8.1. Backing Up a Virtual Machine Use the backup and restore API to back up a virtual machine. This procedure assumes you have two virtual machines: the virtual machine to back up, and a virtual machine on which the software for managing the backup is installed. Procedure 8.1. Backing Up a Virtual Machine Using the REST API , create a snapshot of the virtual machine to back up: Note When you take a snapshot of a virtual machine, a copy of the configuration data of the virtual machine as at the time the snapshot was taken is stored in the data attribute of the configuration attribute in initialization under the snapshot. Important You cannot take snapshots of disks that are marked as shareable or that are based on direct LUN disks. Retrieve the configuration data of the virtual machine from the data attribute under the snapshot: Identify the disk ID and snapshot ID of the snapshot: Attach the snapshot to the backup virtual machine and activate the disk: Use the backup software on the backup virtual machine to back up the data on the snapshot disk. Detach the snapshot disk from the backup virtual machine: Optionally, delete the snapshot: You have backed up the state of a virtual machine at a fixed point in time using backup software installed on a separate virtual machine.

Commands:
POST /ovirt-engine/api/vms/ 11111111-1111-1111-1111-111111111111 /snapshots/ HTTP/1.1 Accept: application/xml Content-type: application/xml <snapshot> <description>BACKUP</description> </snapshot>
GET /ovirt-engine/api/vms/ 11111111-1111-1111-1111-111111111111 /snapshots/ 11111111-1111-1111-1111-111111111111 HTTP/1.1 Accept: application/xml Content-type: application/xml
GET /ovirt-engine/api/vms/ 11111111-1111-1111-1111-111111111111 /snapshots/ 11111111-1111-1111-1111-111111111111 /disks HTTP/1.1 Accept: application/xml Content-type: application/xml
POST /ovirt-engine/api/vms/ 22222222-2222-2222-2222-222222222222 /disks/ HTTP/1.1 Accept: application/xml Content-type: application/xml <disk id=" 11111111-1111-1111-1111-111111111111 "> <snapshot id=" 11111111-1111-1111-1111-111111111111 "/> <active>true</active> </disk>
DELETE /ovirt-engine/api/vms/ 22222222-2222-2222-2222-222222222222 /disks/ 11111111-1111-1111-1111-111111111111 HTTP/1.1 Accept: application/xml Content-type: application/xml <action> <detach>true</detach> </action>
DELETE /ovirt-engine/api/vms/ 11111111-1111-1111-1111-111111111111 /snapshots/ 11111111-1111-1111-1111-111111111111 HTTP/1.1 Accept: application/xml Content-type: application/xml
Chapter 1. Introduction Migration Toolkit for Runtimes product will be End of Life on September 30th, 2024 All customers using this product should start their transition to Migration Toolkit for Applications . Migration Toolkit for Applications is fully backwards compatible with all features and rulesets available in Migration Toolkit for Runtimes and will be maintained in the long term. 1.1. About the CLI Guide This guide is for engineers, consultants, and others who want to use the Migration Toolkit for Runtimes (MTR) to migrate Java applications, .NET applications, or other components. In MTR 7.1 and later, you can use MTR to analyze applications written in languages other than Java. To run analysis on applications written in languages other than Java, add a custom rule set and do not specify a target language. This guide describes how to install and run the CLI, review the generated reports, and take advantage of additional features. 1.2. About the Migration Toolkit for Runtimes What is the Migration Toolkit for Runtimes? The Migration Toolkit for Runtimes (MTR) is an extensible and customizable rule-based tool that simplifies the migration and modernization of Java applications. MTR examines application artifacts, including project source directories and application archives, and then produces an HTML report highlighting areas needing changes. MTR supports many migration paths, including the following examples: Upgrading to the latest release of Red Hat JBoss Enterprise Application Platform Migrating from Oracle WebLogic or IBM WebSphere Application Server to Red Hat JBoss Enterprise Application Platform Containerizing applications and making them cloud-ready Migrating from Java Spring Boot to Quarkus Updating from Oracle JDK to OpenJDK Upgrading from OpenJDK 8 to OpenJDK 11 Upgrading from OpenJDK 11 to OpenJDK 17 Upgrading from OpenJDK 17 to OpenJDK 21 Migrating EAP Java applications to Azure Migrating Spring Boot Java applications to Azure For more information about use cases and migration paths, see the MTR for developers web page. How does the Migration Toolkit for Runtimes simplify migration? The Migration Toolkit for Runtimes looks for common resources and known trouble spots when migrating applications. It provides a high-level view of the technologies used by the application. MTR generates a detailed report evaluating a migration or modernization path. This report can help you to estimate the effort required for large-scale projects and to reduce the work involved. How do I learn more? See the Introduction to the Migration Toolkit for Runtimes to learn more about the features, supported configurations, system requirements, and available tools in the Migration Toolkit for Runtimes. 1.3. The MTR CLI The CLI is a command-line tool in the Migration Toolkit for Runtimes that you can use to assess and prioritize migration and modernization efforts for applications. It provides numerous reports that highlight the analysis without using the other tools. The CLI includes a wide array of customization options. By using the CLI, you can tune MTR analysis options or integrate with external automation tools.

Commands:
22.2. The Engine Configuration Tool 22.2.1. The Engine Configuration Tool The engine configuration tool is a command-line utility for configuring global settings for your Red Hat Virtualization environment. The tool interacts with a list of key-value mappings that are stored in the engine database, and allows you to retrieve and set the value of individual keys, and retrieve a list of all available configuration keys and values. Furthermore, different values can be stored for each configuration level in your Red Hat Virtualization environment. Note Neither the Red Hat Virtualization Manager nor Red Hat JBoss Enterprise Application Platform need to be running to retrieve or set the value of a configuration key. Because the configuration key value-key mappings are stored in the engine database, they can be updated while the postgresql service is running. Changes are then applied when the ovirt-engine service is restarted. 22.2.2. Syntax for the engine-config Command You can run the engine configuration tool from the machine on which the Red Hat Virtualization Manager is installed. For detailed information on usage, print the help output for the command: Common tasks: List available configuration keys List available configuration values Retrieve value of configuration key Replace KEY_NAME with the name of the preferred key to retrieve the value for the given version of the key. Use the --cver parameter to specify the configuration version of the value to be retrieved. If no version is provided, values for all existing versions are returned. Set value of configuration key Replace KEY_NAME with the name of the specific key to set, and replace KEY_VALUE with the value to be set. You must specify the VERSION in environments with more than one configuration version. Restart the ovirt-engine service to load changes The ovirt-engine service needs to be restarted for your changes to take effect.

Commands:
engine-config --help
engine-config --list
engine-config --all
engine-config --get KEY_NAME
engine-config --set KEY_NAME = KEY_VALUE --cver= VERSION
systemctl restart ovirt-engine.service
7.271. wdaemon 7.271.1. RHBA-2013:0293 - wdaemon bug fix and enhancement update Updated wdaemon packages that fix one bug and add one enhancement are now available for Red Hat Enterprise Linux 6. The wdaemon packages contain a daemon to wrap input driver hotplugging in the X.Org implementation of the X Window System server. The wdaemon packages emulate virtual input devices to avoid otherwise non-persistent configuration of Wacom tablets to persist across device removals. Bug Fix BZ# 852332 Due to the broken %postun scriptlet, an attempt to uninstall wdaemon caused an error message to appear. This error message also occurred during the wdaemon update because the old package is removed during the update. Consequently, the wdaemon service was not restarted after the update. The %postun scriptlet has been fixed and wdaemon works as expected in this situation. Enhancement BZ# 838752 This enhancement adds support for emulation of the Wacom Intuos5 tablet series. All users of wdaemon are advised to upgrade to these updated packages which fix this bug and add this enhancement.

Commands:
2.11. Obtaining Information About Control Groups There are several ways to find and monitor control groups, subsystems, and hierarchies configured on your system. 2.11.1. Finding a Process To find the cgroup to which a process belongs, run: Or, if you know the PID for the process, run: where PID stands for a PID of the inspected process.

Commands:
~]USD ps -O cgroup
~]USD cat /proc/ PID /cgroup
3.3.2. Striped Logical Volumes When you write data to an LVM logical volume, the file system lays the data out across the underlying physical volumes. You can control the way the data is written to the physical volumes by creating a striped logical volume. For large sequential reads and writes, this can improve the efficiency of the data I/O. Striping enhances performance by writing data to a predetermined number of physical volumes in round-robin fashion. With striping, I/O can be done in parallel. In some situations, this can result in near-linear performance gain for each additional physical volume in the stripe. The following illustration shows data being striped across three physical volumes. In this figure: the first stripe of data is written to PV1 the second stripe of data is written to PV2 the third stripe of data is written to PV3 the fourth stripe of data is written to PV1 In a striped logical volume, the size of the stripe cannot exceed the size of an extent. Figure 3.5. Striping Data Across Three PVs Striped logical volumes can be extended by concatenating another set of devices onto the end of the first set. In order to extend a striped logical volume, however, there must be enough free space on the underlying physical volumes that make up the volume group to support the stripe. For example, if you have a two-way stripe that uses up an entire volume group, adding a single physical volume to the volume group will not enable you to extend the stripe. Instead, you must add at least two physical volumes to the volume group. For more information on extending a striped volume, see Section 5.4.14.1, "Extending a Striped Volume" .

Commands: