mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Introduction The Red Hat Virtualization Manager provides a Representational State Transfer (REST) API . The API provides software developers and system administrators with control over their Red Hat Virtualization environment outside of the standard web interface. The API is useful for developers and administrators to integrate the functionality of a Red Hat Virtualization environment with custom scripts or external applications that access the API via the standard Hypertext Transfer Protocol (HTTP). The benefits of the API are: Broad client support - Any programming language, framework, or system with support for HTTP protocol can use the API. Self descriptive - Client applications require minimal knowledge of the virtualization infrastructure, as many details are discovered at runtime. Resource-based model - The resource-based REST model provides a natural way to manage a virtualization platform. This provides developers and administrators with the ability to: Integrate with enterprise IT systems. Integrate with third-party virtualization software. Perform automated maintenance or error-checking tasks. Automate repetitive tasks in a Red Hat Virtualization environment with scripts. This documentation acts as a reference for the Red Hat Virtualization API. It aims to provide developers and administrators with instructions and examples to help harness the functionality of their Red Hat Virtualization environment through the API, either directly or using the provided SDKs. 1.1. Representational State Transfer Representational State Transfer (REST) is a design architecture that focuses on resources for a specific service and their representations. A resource representation is a key abstraction of information that corresponds to one specific managed element on a server. A client sends a request to a server element located at a Uniform Resource Identifier (URI) and performs operations with standard HTTP methods, such as GET , POST , PUT , and DELETE . This provides a stateless communication between the client and server where each request acts independently of any other request, and contains all the information necessary to complete the request. 1.2. API Prerequisites Prerequisites for using the Red Hat Virtualization API: A networked installation of Red Hat Virtualization Manager, which includes the API. A client or programming library that initiates and receives HTTP requests from the API server. For example: The oVirt Python SDK . The oVirt Ruby SDK . The oVirt Java SDK . The cURL command line tool. RESTClient , a debugger for RESTful web services. Knowledge of Hypertext Transfer Protocol (HTTP), the protocol used for REST API interactions. The Internet Engineering Task Force provides a Request for Comments (RFC) explaining the Hypertext Transfer Protocol at http://www.ietf.org/rfc/rfc2616.txt . Knowledge of Extensible Markup Language (XML) or JavaScript Object Notation (JSON), which the API uses to construct resource representations. The W3C provides a full specification on XML at http://www.w3.org/TR/xml . ECMA International provide a free publication on JSON at http://www.ecma-international.org .

Commands:
Chapter 6. Managing administration roles and users 6.1. Understanding administration roles 6.1.1. The cluster-admin role As an administrator of an OpenShift Dedicated cluster with Customer Cloud Subscriptions (CCS), you have access to the cluster-admin role. The user who created the cluster can add the cluster-admin user role to an account to have the maximum administrator privileges. These privileges are not automatically assigned to your user account when you create the cluster. While logged in to an account with the cluster-admin role, users have mostly unrestricted access to control and configure the cluster. There are some configurations that are blocked with webhooks to prevent destabilizing the cluster, or because they are managed in OpenShift Cluster Manager and any in-cluster changes would be overwritten. Usage of the cluster-admin role is subject to the restrictions listed in your Appendix 4 agreement with Red Hat. As a best practice, limit the number of cluster-admin users to as few as possible. 6.1.2. The dedicated-admin role As an administrator of an OpenShift Dedicated cluster, your account has additional permissions and access to all user-created projects in your organization's cluster. While logged in to an account with the dedicated-admin role, the developer CLI commands (under the oc command) allow you increased visibility and management capabilities over objects across projects, while the administrator CLI commands (under the oc adm command) allow you to complete additional operations. Note While your account does have these increased permissions, the actual cluster maintenance and host configuration is still performed by the OpenShift Operations Team. 6.2. Managing OpenShift Dedicated administrators Administrator roles are managed using a cluster-admin or dedicated-admin group on the cluster. Existing members of this group can edit membership through OpenShift Cluster Manager . 6.2.1. Adding a user Procedure Navigate to the Cluster Details page and Access Control tab. Select the Cluster Roles and Access tab and click Add user . Enter the user name and select the group. Click Add user . Note Adding a user to the cluster-admin group can take several minutes to complete. 6.2.2. Removing a user Procedure Navigate to the Cluster Details page and Access Control tab. Click the Options menu to the right of the user and group combination and click Delete .

Commands:
E.2. GRUB The GNU GRand Unified Boot loader (GRUB) is a program which enables the selection of the installed operating system or kernel to be loaded at system boot time. It also allows the user to pass arguments to the kernel. E.2.1. GRUB and the Boot Process on BIOS-based x86 Systems This section describes the specific role GRUB plays when booting a BIOS-based x86 system. For a look at the overall boot process, refer to Section F.2, "A Detailed Look at the Boot Process" . GRUB loads itself into memory in the following stages: The Stage 1 or primary boot loader is read into memory by the BIOS from the MBR [16] . The primary boot loader exists on less than 512 bytes of disk space within the MBR and is capable of loading either the Stage 1.5 or Stage 2 boot loader. BIOS cannot read partition tables or file systems. It initializes the hardware, reads the MBR, then depends entirely on the stage 1 bootloader to continue the boot process. The Stage 1.5 boot loader is read into memory by the Stage 1 boot loader, if necessary. Some hardware requires an intermediate step to get to the Stage 2 boot loader. This is sometimes true when the /boot/ partition is above the 1024 cylinder head of the hard drive or when using LBA mode. The Stage 1.5 boot loader is found either on the /boot/ partition or on a small part of the MBR and the /boot/ partition. The Stage 2 or secondary boot loader is read into memory. The secondary boot loader displays the GRUB menu and command environment. This interface allows the user to select which kernel or operating system to boot, pass arguments to the kernel, or look at system parameters. The secondary boot loader reads the operating system or kernel as well as the contents of /boot/sysroot/ into memory. Once GRUB determines which operating system or kernel to start, it loads it into memory and transfers control of the machine to that operating system. The method used to boot Linux is called direct loading because the boot loader loads the operating system directly. There is no intermediary between the boot loader and the kernel. The boot process used by other operating systems may differ. For example, the Microsoft Windows operating system, as well as other operating systems, are loaded using chain loading . Under this method, the MBR points to the first sector of the partition holding the operating system, where it finds the files necessary to actually boot that operating system. GRUB supports both direct and chain loading boot methods, allowing it to boot almost any operating system. Warning During installation, Microsoft's DOS and Windows installation programs completely overwrite the MBR, destroying any existing boot loaders. If creating a dual-boot system, it is best to install the Microsoft operating system first. [16] For more on the system BIOS and the MBR, refer to Section F.2.1.1, "BIOS-based x86 Systems" .

Commands:
17.4. Establishing a Modem Connection A modem can be used to configure an Internet connection over an active phone line. An Internet Service Provider (ISP) account (also called a dial-up account) is required. To add a modem connection, follow these steps: Click the Devices tab. Click the New button on the toolbar. Select Modem connection from the Device Type list, and click Forward . If there is a modem already configured in the hardware list (on the Hardware tab), the Network Administration Tool assumes you want to use it to establish a modem connection. If there are no modems already configured, it tries to detect any modems in the system. This probe might take a while. If a modem is not found, a message is displayed to warn you that the settings shown are not values found from the probe. After probing, the window in Figure 17.6, "Modem Settings" appears. Figure 17.6. Modem Settings Configure the modem device, baud rate, flow control, and modem volume. If you do not know these values, accept the defaults if the modem was probed successfully. If you do not have touch tone dialing, uncheck the corresponding checkbox. Click Forward . If your ISP is in the pre-configured list, select it. Otherwise, enter the required information about your ISP account. If you do not know these values, contact your ISP. Click Forward . On the IP Settings page, select whether to obtain an IP address automatically or whether to set one statically. Click Forward when finished. On the Create Dialup Connection page, click Apply . After configuring the modem device, it appears in the device list with the type Modem as shown in Figure 17.7, "Modem Device" . Figure 17.7. Modem Device Be sure to select File => Save to save the changes. After adding the modem device, you can edit its configuration by selecting the device from the device list and clicking Edit . For example, when the device is added, it is configured not to start at boot time by default. Edit its configuration to modify this setting. Compression, PPP options, login name, password, and more can also be changed. When the device is added, it is not activated immediately, as seen by its Inactive status. To activate the device, select it from the device list, and click the Activate button. If the system is configured to activate the device when the computer starts (the default), this step does not have to be performed again.

Commands:
Chapter 4. Quick Start Tutorial on Virtualization in Red Hat Enterprise Linux 6 This chapter provides instructions for installing essential virtualization tools and creating a virtual machine in Red Hat Enterprise Linux 6. Note The tutorial uses Virtual Machine Manager to quickly create a virtual machine for trying out KVM virtualization. To set up virtual machines with the capabilities necessary for a production environment, refer to the Red Hat Enterprise Linux 6 Host Configuration and Guest Installation Guide . 4.1. Tutorial overview Ensure that your system meets the basic requirements Ensure that the required packages are installed Create a virtual machine using Virtual Machine Manager

Commands:
4.213. pacemaker 4.213.1. RHBA-2011:1669 - pacemaker bug fix and enhancement update Updated pacemaker packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The Pacemaker Cluster Resource Manager provides the ability to create and manage high-availability server applications in the event of system downtime. The pacemaker packages have been upgraded to upstream version 1.1.6, which provides a number of bug fixes and enhancements over the version. In particular, this update fixes the following bugs: BZ# 708722 Prior to this update, when the pacemaker daemon did not have permission to write to the /var/log/cluster/corosync.log file, it wrote the following error to the system log: This update applies a patch to ensure that when such an error occurs, Pacemaker logs this problem on startup and no longer tries to access this file. BZ# 720136 When using the CRM command line interface, running the "configure", "template", and "list" commands in this particular order caused the crm process to terminate unexpectedly with the following error: With this update, the underlying source code has been modified to address this issue so that CRM no longer crashes. BZ# 743175 Under certain circumstances, an attempt to fence a node may have caused Pacemaker to stop responding when accessing the /var/run/cluster/fenced_override file. With this update, this error no longer occurs, and Pacemaker now works as expected in this scenario. BZ# 745526 Prior to this update, an error in the interaction between Pacemaker and CMAN's fencing subsystem prevented reliable fencing operation. This update applies a patch that corrects this error so that such fencing operations are now reliable. BZ# 708797 In the version of the crm(8) manual page, the EXAMPLES section incorrectly listed several example commands on a single line. This made it particularly difficult for a reader to distinguish these commands. This update introduces a new, completely rewritten manual page, which lists each example command on a separate line. All users who want to use the pacemaker Technology Preview should upgrade to these updated packages, which provide numerous bug fixes and enhancements.

Commands:
attrd: Cannot append to /var/log/cluster/corosync.log: Permission denied
NameError: global name 'listconfigs' is not defined
Chapter 2. Configuring SELinux to exclude SAP HANA directories By default, any application for which no SELinux security policy has been defined is blocked by SELinux if your RHEL system is running with SELinux set to enforcing mode. As of today, SAP does not provide SELinux policies for SAP HANA. For running SAP HANA executables while SELinux is set to enforcing, a certain SELinux boolean has to be set, and the SAP HANA related directories have to be excluded from SELinux protection. You can also use the fapolicyd framework to protect your SAP HANA software. For more information, refer to the Configuring fapolicyd to allow only SAP HANA executables document. Prerequisites SAP HANA is installed and stopped, or not yet installed. SELinux is available and set to enforcing mode. The directories in which SAP HANA and related software are installed (typically /hana and /usr/sap ) exist. Procedure Use the following command to set the SELinux boolean selinuxuser_execmod to 1 , allowing unconfined executables to use libraries that require text relocation (such as SAP HANA): Use the following commands to relabel the directories and files used by SAP HANA (typically /hana and /usr/sap ) so that SAP HANA can be run in unconfined mode: Note You can perform this step before or after installing SAP HANA, as all newly created directories and files below the upper level directories inherit the SELinux labels. Verification Use the following command to show the security context of a file or directory in /usr/bin and in /hana , confirming that the file or directory under /hana has the usr_t label:

Commands:
setsebool -P selinuxuser_execmod 1
semanage fcontext -a -t usr_t '/hana(/. )?'* semanage fcontext -a -t usr_t '/usr/sap(/. )?'* restorecon -Rv '/hana' restorecon -Rv '/usr/sap'
ls -lZ /usr/bin/ls -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 143296 Jan 6 2023 /usr/bin/ls ls -lZd /hana/shared drwxr-xr-x. 3 root root system_u:object_r:usr_t:s0 17 Apr 18 23:03 /hana/shared
Chapter 1. Introduction To learn about features introduced in each Red Hat Enterprise Linux 7 minor release, see the Release Notes for respective minor versions . The Performance Tuning Guide is a comprehensive guide to optimizing the various subsystems that make up Red Hat Enterprise Linux 7 for specific purposes. This guide also outlines the performance monitoring and tuning tools available in Red Hat Enterprise Linux 7. Before you begin tuning, Red Hat has the following important recommendations: Back up before you configure The default settings in Red Hat Enterprise Linux 7 are suitable for most services running under moderate loads. Improving the performance of a specific subsystem may affect another system adversely. Back up all data and configuration information before you begin tuning your system. Test configuration out of production The procedures documented in the Performance Tuning Guide are tested extensively by Red Hat engineers in both lab and field. Nonetheless, Red Hat recommends testing all planned configurations in a secure testing environment before applying those configurations to production systems. Who Should Read This Book The Performance Tuning Guide has been written primarily for two distinct but overlapping audiences: System administrators The Performance Tuning Guide documents the effects of each configuration option in detail so that system administrators can optimize Red Hat Enterprise Linux 7 for their specific purpose. Procedures in this guide are suitable for system administrators with Red Hat Certified Engineer (RHCE) certification or an equivalent amount of experience (3-5 years' experience deploying and managing Linux-based systems). System and business analysts This guide explains Red Hat Enterprise Linux 7 performance features at a high level. It provides information about how subsystems perform under specific workloads, allowing analysts to determine whether Red Hat Enterprise Linux 7 is suitable for their use case. Where possible, the Performance Tuning Guide also refers readers to more detailed feature documentation. This allows readers to develop the in-depth knowledge required to formulate the detailed deployment and optimization strategies necessary for infrastructure and deployment proposals.

Commands:
Chapter 7. Scaling hyperconverged nodes To scale HCI nodes up or down, the same principles and methods for scaling Compute nodes or Red Hat Ceph Storage nodes apply. 7.1. Scaling up hyperconverged nodes in HCI environments To scale up hyperconverged nodes in HCI environments follow the same procedure for scaling up non-hyperconverged nodes. For more information, see Adding nodes to the overcloud . Note When you tag new nodes, remember to use the right flavor. 7.2. Scaling down hyperconverged nodes in HCI environments To scale down hyperconverged nodes in HCI environments you must rebalance the Ceph OSD services on the HCI node, migrate instances from the HCI nodes, and remove the Compute nodes from the overcloud. Procedure Disable and rebalance the Ceph OSD services on the HCI node. This step is necessary because director does not automatically rebalance the Red Hat Ceph Storage cluster when you remove HCI or Red Hat Ceph Storage nodes. For more information, see Scaling the Ceph Storage cluster in Deploying Red Hat Ceph Storage and Red Hat OpenStack Platform together with director for more information. Migrate the instances from the HCI nodes. For more information, see Migrating virtual machines between Compute nodes in the Configuring the Compute Service for Instance Creation guide. Remove the Compute nodes from the overcloud. For more information, see Removing Compute nodes .

Commands:
Chapter 2. Compatibility Matrix for Red Hat Ceph Storage 6.1 The following tables list products and their versions compatible with Red Hat Ceph Storage 6.1. Host Operating System Version Notes Red Hat Enterprise Linux 9.5, 9.4, 9.3, 9.2, 9.2 EUS, 8.10, 8.9 Standard lifecycle 9.2 is included in the product. Note Red Hat Ceph Storage 6.1 supports Red Hat Enterprise Linux 8.8, 8.9, and 8.10 with bootstrap node in supported Red Hat Enterprise Linux 9.x. Important All nodes in the cluster and their clients must use the supported OS version(s) to ensure that the version of the ceph package is the same on all nodes. Using different versions of the ceph package is not supported. Important Ubuntu is not supported as a deploying host operating system. Product Version Notes Ansible Supported in a limited capacity. Supported for upgrade and conversion to Cephadm and for other minimal playbooks. Red Hat OpenShift 3.x, 4.2 - 4.7 RBD, Cinder and CephFS drivers are supported. Red Hat OpenShift Data Foundation See the Red Hat OpenShift Data Foundation Supportability and Interoperability Checker for detailed external mode version compatibility. Red Hat OpenStack Platform 17.1 Red Hat OpenStack Platform 17.1 supports Red Hat Ceph Storage 6.1 through both external and director deployed. Red Hat Satellite 6.x Only registering with the Content Delivery Network (CDN) is supported. Registering with Red Hat Network (RHN) is deprecated and not supported. Client Connector Version Notes S3A 2.8.x, 3.2.x, and trunk Red Hat Ceph Storage as a backup target Version Notes CommVault Cloud Data Management v11 IBM Spectrum Protect Plus 10.1.5 IBM Spectrum Protect server 8.1.8 NetApp AltaVault 4.3.2 and 4.4 Rubrik Cloud Data Management (CDM) 3.2 onwards Trilio, TrilioVault 3.0 S3 target Veeam (object storage) Veeam Availability Suite 9.5 Update 4 Supported on Red Hat Ceph Storage object storage with the S3 protocol Veritas NetBackup for Symantec OpenStorage (OST) cloud backup 7.7 and 8.0 Independent Software vendors Version Notes IBM Spectrum Discover 2.0.3 WekaIO 3.12.2

Commands:
9.3. Add a Profile to Your Project To enable the JBoss Maven repository for your project, add a profile to your settings.xml file in USDHOME/.m2/settings.xml as follows: Example 9.1. Adding a Profile Enable the profile by ensuring the following is included in the settings.xml file: Example 9.2. Enable the Profile If you are using a build system that does not support declarative dependency management, add the contents of the client/java/ directory, included in the Red Hat JBoss Data Grid package to the build classpath. Report a bug

Commands:
<profiles> <!-- Configure the JBoss GA Maven repository --> <profile> <id>jboss-ga-repository</id> <repositories> <repository> <id>jboss-ga-repository</id> <url>http://maven.repository.redhat.com/techpreview/all</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>jboss-ga-plugin-repository</id> <url>http://maven.repository.redhat.com/techpreview/all</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </pluginRepository> </pluginRepositories> </profile> <!-- Configure the JBoss Early Access Maven repository --> <profile> <id>jboss-earlyaccess-repository</id> <repositories> <repository> <id>jboss-earlyaccess-repository</id> <url>http://maven.repository.redhat.com/earlyaccess/all/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>jboss-earlyaccess-plugin-repository</id> <url>http://maven.repository.redhat.com/earlyaccess/all/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </pluginRepository> </pluginRepositories> </profile> </profiles> <!-- Add active profiles information here -->
<activeProfiles> <!-- Optionally, make the repositories active by default --> <activeProfile>jboss-ga-repository</activeProfile> <activeProfile>jboss-earlyaccess-repository</activeProfile> </activeProfiles>