mtpti5iD/redhat-docs_dataset huggingface dataset:
Part III. Getting started with case management in Red Hat Process Automation Manager As a business rules and processes developer, you can use case management assets in Business Central to create unpredictable and ad hoc case processes. Case workers or process administrators can also use Business Central for case management and execution. Red Hat Process Automation Manager provides example projects with example business assets in Business Central as a reference. This document describes how to create and test an example IT orders project based on the IT_Orders sample project included in Business Central. Prerequisites Red Hat JBoss Enterprise Application Platform 7.4 is installed. For installation information, see Red Hat JBoss Enterprise Application Platform 7.4 Installation Guide . Red Hat Process Automation Manager is installed and configured with KIE Server. For more information see Installing and configuring Red Hat Process Automation Manager on Red Hat JBoss EAP 7.4 . Red Hat Process Automation Manager is running and you can log in to Business Central with the kie-server , user , and admin roles. You have reviewed the information in Designing and building cases for case management .

Commands:
Chapter 1. Installing a cluster on Alibaba Cloud by using the Assisted Installer Alibaba Cloud provides a broad range of cloud computing and data storage services to online businesses and global enterprises. You can install an OpenShift Container Platform cluster on Alibaba Cloud using the Assisted Installer. Important Installing Alibaba Cloud with Assisted Installer is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . 1.1. Process outline for creating a cluster with the Assisted Installer The main steps of the installation process are as follows: Create the cluster with the Assisted Installer and download the generated image. Convert the image to QCOW2 format. For more information, see the following section. Upload the image to the Object Storage Service bucket in Alibaba Cloud. Import the image to the Elastic Compute Service in Alibaba Cloud. Provision the Alibaba Cloud resources: In the Virtual Private Cloud (VPC) console, set the networking configurations. In the Alibaba Cloud DNS console, define the Domain Name System. In the Elastic Compute Service (ECS) console, provision the compute instances. Complete host discovery in the Assisted Installer. Complete the network configurations in Alibaba Cloud. Complete the cluster configuration and installation in the Assisted Installer. Additional resources Installing OpenShift Container Platform with the Assisted Installer 1.2. Converting the discovery image to QCOW2 format Convert the generated ISO to QCOW2 format before importing it into Alibaba Cloud. Prerequisites You have created a cluster and downloaded the discovery image in the Assisted Installer. You have access to a Linux machine that is outside the cluster, such as your desktop machine. Procedure Open the command line interface on the Linux machine. Verify that the system has virtualization flags enabled by running the following command: USD grep -e lm -e svm -e vmx /proc/cpuinfo Install the qemu-img package on a RHEL or Fedora machine by running the following command: USD sudo dnf install -y qemu-img Note If your system uses the APT package manager, install the package using the name qemu-utils instead. Convert the image to QCOW2 by running the following command: USD qemu-img convert -O qcow2 USD{CLUSTER_NAME}.iso USD{CLUSTER_NAME}.qcow2

Commands:
grep -e lm -e svm -e vmx /proc/cpuinfo
sudo dnf install -y qemu-img
qemu-img convert -O qcow2 USD{CLUSTER_NAME}.iso USD{CLUSTER_NAME}.qcow2
8.7. Data Type Metadata SYS.DataTypes This table supplies information on data types. See Section 3.1, "Supported Types" . Column Name Type Description Name string JBoss Data Virtualization design-time type name IsStandard boolean Always false IsPhysical boolean Always false TypeName string Design-time type name (same as Name) JavaClass string Java class returned for this type Scale integer Max scale of this type TypeLength integer Max length of this type NullType string Nullability: "Nullable", "No Nulls", "Unknown" IsSigned boolean Is signed numeric? IsAutoIncremented boolean Is auto-incremented? IsCaseSensitive boolean Is case-sensitive? Precision integer Max precision of this type Radix integer Radix of this type SearchType string Searchability: "Searchable", "All Except Like", "Like Only", "Unsearchable" UID string Data type unique ID OID integer Unique ID RuntimeType string JBoss Data Virtualization runtime data type name BaseType string Base type Description string Description of type Warning The OID column is no longer used on system tables. Use UID instead.

Commands:
Providing feedback on Red Hat documentation We appreciate your input on our documentation. Do let us know how we can make it better. To give feedback: For simple comments on specific passages: Make sure you are viewing the documentation in the HTML format. In addition, ensure you see the Feedback button in the upper right corner of the document. Use your mouse cursor to highlight the part of text that you want to comment on. Click the Add Feedback pop-up that appears below the highlighted text. Follow the displayed instructions. For submitting more complex feedback, create a Bugzilla ticket: Go to the Bugzilla website. In the Component section, choose documentation . Fill in the Description field with your suggestion for improvement. Include a link to the relevant part(s) of documentation. Click Submit Bug .

Commands:
3.3.3. Configuring a Node with Redundant Power If your cluster is configured with redundant power supplies for your nodes, you must be sure to configure fencing so that your nodes fully shut down when they need to be fenced. If you configure each power supply as a separate fence method, each power supply will be fenced separately; the second power supply will allow the system to continue running when the first power supply is fenced and the system will not be fenced at all. To configure a system with dual power supplies, you must configure your fence devices so that both power supplies are shut off and the system is taken completely down. When configuring your system using Conga , this requires that you configure two instances within a single fencing method. To configure fencing for a node with dual power supplies, follow the steps in this section. Before you can configure fencing for a node with redundant power, you must configure each of the power switches as a fence device for the cluster. For information on configuring fence devices, see Section 3.2, "Configuring Fence Devices" . From the cluster-specific page, click on Nodes along the top of the cluster display. This displays the nodes that constitute the cluster. This is also the default page that appears when you click on the cluster name beneath Manage Clusters from the menu on the left side of the luci Homebase page. Click on a node name. Clicking a link for a node causes a page to be displayed for that link showing how that node is configured. On the node-specific page, click Add Fence Method . Enter a name for the fencing method that you are configuring for this node. Click Submit . This displays the node-specific screen that now displays the method you have just added under Fence Devices . Configure the first power supply as a fence instance for this method by clicking Add Fence Instance . This displays a drop-down menu from which you can select one of the power fencing devices you have previously configured, as described in Section 3.2.1, "Creating a Fence Device" . Select one of the power fence devices for this method and enter the appropriate parameters for this device. Click Submit . This returns you to the node-specific screen with the fence method and fence instance displayed. Under the same fence method for which you have configured the first power fencing device, click Add Fence Instance . This displays a drop-down menu from which you can select the second power fencing devices you have previously configured, as described in Section 3.2.1, "Creating a Fence Device" . Select the second of the power fence devices for this method and enter the appropriate parameters for this device. Click Submit . This returns you to the node-specific screen with the fence methods and fence instances displayed, showing that each device will power the system off in sequence and power the system on in sequence. This is shown in Figure 3.2, "Dual-Power Fencing Configuration" . Figure 3.2. Dual-Power Fencing Configuration

Commands:
13.2.4. SSSD and System Services SSSD and its associated services are configured in the sssd.conf file. The [sssd] section also lists the services that are active and should be started when sssd starts within the services directive. SSSD can provide credentials caches for several system services: A Name Service Switch (NSS) provider service that answers name service requests from the sssd_nss module. This is configured in the [nss] section of the SSSD configuration. This is described in Section 13.2.5, "Configuring Services: NSS" . A PAM provider service that manages a PAM conversation through the sssd_pam module. This is configured in the [pam] section of the configuration. This is described in Section 13.2.6, "Configuring Services: PAM" . An SSH provider service that defines how SSSD manages the known_hosts file and other key-related configuration. Using SSSD with OpenSSH is described in Section 13.2.9, "Configuring Services: OpenSSH and Cached Keys" . An autofs provider service that connects to an LDAP server to retrieve configured mount locations. This is configured as part of an LDAP identity provider in a [domain/NAME] section in the configuration file. This is described in Section 13.2.7, "Configuring Services: autofs" . A sudo provider service that connects to an LDAP server to retrieve configured sudo policies. This is configured as part of an LDAP identity provider in a [domain/NAME] section in the configuration file. This is described in Section 13.2.8, "Configuring Services: sudo" . A PAC responder service that defines how SSSD works with Kerberos to manage Active Directory users and groups. This is specifically part of managing Active Directory identity providers with domains, as described in Section 13.2.13, "Creating Domains: Active Directory" .

Commands:
24.5. Viewing Hardware Information 24.5.1. Using the lspci Command The lspci command allows you to display information about PCI buses and devices that are attached to them. To list all PCI devices that are in the system, type the following at a shell prompt: lspci This displays a simple list of devices, for example: You can also use the -v command-line option to display more verbose output, or -vv for very verbose output: lspci -v | -vv For instance, to determine the manufacturer, model, and memory size of a system's video card, type: For a complete list of available command-line options, see the lspci (8) manual page.

Commands:
~]USD lspci 00:00.0 Host bridge: Intel Corporation 82X38/X48 Express DRAM Controller 00:01.0 PCI bridge: Intel Corporation 82X38/X48 Express Host-Primary PCI Express Bridge 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02) [output truncated]
~]USD lspci -v [output truncated] 01:00.0 VGA compatible controller: nVidia Corporation G84 [Quadro FX 370] (rev a1) (prog-if 00 [VGA controller]) Subsystem: nVidia Corporation Device 0491 Physical Slot: 2 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f2000000 (32-bit, non-prefetchable) [size=16M] Memory at e0000000 (64-bit, prefetchable) [size=256M] Memory at f0000000 (64-bit, non-prefetchable) [size=32M] I/O ports at 1100 [size=128] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: nouveau Kernel modules: nouveau, nvidiafb [output truncated]
1.5. Cluster Configuration Considerations When configuring a Red Hat High Availability Add-On cluster, you must take the following considerations into account: Red Hat does not support cluster deployments greater than 32 nodes for RHEL 7.7 (and later). It is possible, however, to scale beyond that limit with remote nodes running the pacemaker_remote service. For information on the pacemaker_remote service, see Section 9.4, "The pacemaker_remote Service" . The use of Dynamic Host Configuration Protocol (DHCP) for obtaining an IP address on a network interface that is utilized by the corosync daemons is not supported. The DHCP client can periodically remove and re-add an IP address to its assigned interface during address renewal. This will result in corosync detecting a connection failure, which will result in fencing activity from any other nodes in the cluster using corosync for heartbeat connectivity.

Commands:
8.2. Changed File Locations In Red Hat Enterprise Linux 7, the following changes have been made to the location of the input method and font configuration files, and directories: The .xinputrc file has been moved from the user's home directory to the ~/.config/imsettings/ directory. The .imsettings.log file has been moved from the user's home directory and can now be found in ~/.cache/imsettings/log . The ~/.fonts.conf file has been deprecated. Users are encouraged to move the file to the ~/.config/fontconfig/ directory. The ~/.fonts.conf.d directory has been deprecated. Users are encouraged to move the directory to the ~/.config/fontconfig/ directory. All disabled fontconfig configuration files in the /etc/fonts/conf.avail/ directory have been moved to the /usr/share/fontconfig/conf.avail/ directory. If you have any local symbolic links pointing to the old location, remember to update them.

Commands:
34.4. Date and Time Use this screen to adjust the date and time of the system clock. To change these settings after installation, click System Administration Date & Time . Figure 34.15. Firstboot date and time screen Click the Synchronize date and time over the network checkbox to configure your system to use Network Time Protocol (NTP) servers to maintain the accuracy of the clock. NTP provides time synchronization service to computers on the same network. Many public NTP servers are available on the Internet.

Commands:
6.3. Host Network Quality of Service Host network quality of service configures the networks on a host to enable the control of network traffic through the physical interfaces. Host network quality of service allows for the fine tuning of network performance by controlling the consumption of network resources on the same physical network interface controller. This helps to prevent situations where one network causes other networks attached to the same physical network interface controller to no longer function due to heavy traffic. By configuring host network quality of service, these networks can now function on the same physical network interface controller without congestion issues. 6.3.1. Creating a Host Network Quality of Service Entry Create a host network quality of service entry. Creating a Host Network Quality of Service Entry Click Compute Data Centers . Click a data center's name to open the details view. Click the QoS tab. Under Host Network , click New . Enter a Qos Name and a description for the quality of service entry. Enter the desired values for Weighted Share , Rate Limit [Mbps] , and Committed Rate [Mbps] . Click OK . 6.3.2. Settings in the New Host Network Quality of Service and Edit Host Network Quality of Service Windows Explained Host network quality of service settings allow you to configure bandwidth limits for outbound traffic. Table 6.2. Host Network QoS Settings Field Name Description Data Center The data center to which the host network QoS policy is to be added. This field is configured automatically according to the selected data center. QoS Name A name to represent the host network QoS policy within the Manager. Description A description of the host network QoS policy. Outbound The settings to be applied to outbound traffic. Weighted Share : Signifies how much of the logical link's capacity a specific network should be allocated, relative to the other networks attached to the same logical link. The exact share depends on the sum of shares of all networks on that link. By default this is a number in the range 1-100. Rate Limit [Mbps] : The maximum bandwidth to be used by a network. Committed Rate [Mbps] : The minimum bandwidth required by a network. The Committed Rate requested is not guaranteed and will vary depending on the network infrastructure and the Committed Rate requested by other networks on the same logical link. To change the maximum value allowed by the Rate Limit [Mbps] or Committed Rate [Mbps] fields, use the engine-config command to change the value of the MaxAverageNetworkQoSValue configuration key. You must restart the ovirt-engine service for the change to take effect. For example: 6.3.3. Removing a Host Network Quality of Service Entry Remove an existing network quality of service entry. Removing a Host Network Quality of Service Entry Click Compute Data Centers . Click a data center's name to open the details view. Click the QoS tab. Under Host Network , select a host network quality of service entry and click Remove . Click OK when prompted.

Commands:
engine-config -s MaxAverageNetworkQoSValue=2048 systemctl restart ovirt-engine
35.4. Installing Packages With yum The yum utility allows you to install packages on your system. To install a single package and all of its non-installed dependencies, enter a command in the following form: yum install package_name If you are installing packages on a multilib system, such as an AMD64 or Intel64 machine, you can specify the architecture of the package (as long as it is available in an enabled repository) by appending .arch to the package name. For example, to install the foobar package for i686 , type: To install packages when your system cannot access a network or the Internet, consider enabling the installation DVD or ISO image file as an installation repository (refer to Section 35.3.1.2, "Using a Red Hat Enterprise Linux Installation DVD as a Software Repository" ). Choose the appropriate installation media if you intend to install packages for a different architecture. For example, to install a 32-bit package on a 64-bit system, enable the 32-bit media as an installation repository. For more information on installing packages, refer to the Yum chapter in the Red Hat Enterprise Linux Deployment Guide .

Commands:
~]# yum install foobar.i686
8.169. ql2500-firmware 8.169.1. RHBA-2013:1709 - ql2500-firmware bug fix and enhancement update Updated ql2500-firmware package that fixes several bugs and adds various enhancements is now available for Red Hat Enterprise Linux 6. The ql2500-firmware package provides the firmware required to run the QLogic 2500 Series of mass storage adapters. Note The ql2500-firmware package has been upgraded to upstream version 7.00.01, which provides a number of bug fixes and enhancements over the version. (BZ#996754) All users of QLogic 2500 Series Fibre Channel adapters are advised to upgrade to this updated package, which fixes these bugs and adds these enhancements.

Commands:
probe::ioscheduler.elv_next_request.return Name probe::ioscheduler.elv_next_request.return - Fires when a request retrieval issues a return signal Synopsis Values disk_major Disk major number of the request rq Address of the request name Name of the probe point disk_minor Disk minor number of the request rq_flags Request flags

Commands:
ioscheduler.elv_next_request.return
Chapter 18. Additional information 18.1. MTV performance addendum The data provided here was collected from testing in Red Hat Labs and is provided for reference only. Overall, these numbers should be considered to show the best-case scenarios. The observed performance of migration can differ from these results and depends on several factors. 18.1.1. ESXi performance Single ESXi performance Test migration using the same ESXi host. In each iteration, the total VMs are increased, to display the impact of concurrent migration on the duration. The results show that migration time is linear when increasing the total VMs (50 GiB disk, Utilization 70%). The optimal number of VMs per ESXi is 10. Table 18.1. Single ESXi tests Test Case Description MTV VDDK max_vm inflight Migration Type Total Duration cold migration, 10 VMs, Single ESXi, Private Network [a] 2.6 7.0.3 100 cold 0:21:39 cold migration, 20 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 0:41:16 cold migration, 30 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 1:00:59 cold migration, 40 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 1:23:02 cold migration, 50 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 1:46:24 cold migration, 80 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 2:42:49 cold migration, 100 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 3:25:15 [a] Private Network refers to a non -Management network Multi ESXi hosts and single data store In each iteration, the number of ESXi hosts were increased, to show that increasing the number of ESXi hosts improves the migration time (50 GiB disk, Utilization 70%). Table 18.2. Multi ESXi hosts and single data store Test Case Description MTV VDDK Max_vm inflight Migration Type Total Duration cold migration, 100 VMs, Single ESXi, Private Network [a] 2.6 7.0.3 100 cold 3:25:15 cold migration, 100 VMs, 4 ESXs (25 VMs per ESX), Private Network 2.6 7.0.3 100 cold 1:22:27 cold migration, 100 VMs, 5 ESXs (20 VMs per ESX), Private Network, 1 DataStore 2.6 7.0.3 100 cold 1:04:57 [a] Private Network refers to a non-Management network 18.1.2. Different migration network performance Each iteration the Migration Network was changed, using the Provider , to find the fastest network for migration. The results show that there is no degradation using management compared to non-managment networks when all interfaces and network speeds are the same. Table 18.3. Different migration network tests Test Case Description MTV VDDK max_vm inflight Migration Type Total Duration cold migration, 10 VMs, Single ESXi, MGMT Network 2.6 7.0.3 100 cold 0:21:30 cold migration, 10 VMs, Single ESXi, Private Network [a] 2.6 7.0.3 20 cold 0:21:20 cold migration, 10 VMs, Single ESXi, Default Network 2.6.2 7.0.3 20 cold 0:21:30 [a] Private Network refers to a non-Management network

Commands: