mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Introduction A virtual machine is a software implementation of a computer. The Red Hat Virtualization environment enables you to create virtual desktops and virtual servers. Virtual machines consolidate computing tasks and workloads. In traditional computing environments, workloads usually run on individually administered and upgraded servers. Virtual machines reduce the amount of hardware and administration required to run the same computing tasks and workloads. 1.1. Audience Most virtual machine tasks in Red Hat Virtualization can be performed in both the VM Portal and Administration Portal. However, the user interface differs between each portal, and some administrative tasks require access to the Administration Portal. Tasks that can only be performed in the Administration Portal will be described as such in this book. Which portal you use, and which tasks you can perform in each portal, is determined by your level of permissions. Virtual machine permissions are explained in Virtual Machines and Permissions . The VM Portal's user interface is described in the Introduction to the VM Portal . The Administration Portal's user interface is described in the Administration Guide . The creation and management of virtual machines through the Red Hat Virtualization REST API is documented in the REST API Guide .

Commands:
Chapter 16. Updating the Red Hat Single Sign-On client When automation hub is installed and you know the URL of the instance, you must update the Red Hat Single Sign-On to set the Valid Redirect URIs and Web Origins settings. Procedure Navigate to Operator Installed Operators . Select the RH-SSO project. Click Red Hat Single Sign-On Operator . Select Keycloak Client . Click on the automation-hub-client-secret client. Select YAML . Update the Client YAML to add the Valid Redirect URIs and Web Origins settings. redirectUris: - 'https://private-ah-ansible-automation-platform.apps-crc.testing/*' webOrigins: - 'https://private-ah-ansible-automation-platform.apps-crc.testing' Field Description redirectURIs This is the location determined in Determine Automation Hub Route . Be sure to add the /* to the end of the redirectUris setting. webOrigins This is the location determined in Determine Automation Hub Route . Note Ensure the indentation is correct when entering these settings. Click Save . To verify connectivity Navigate to the automation hub route. Enter the hub_admin user credentials and sign in. Red Hat Single Sign-On processes the authentication and redirects back to automation hub. 16.1. Additional resources For more information on running operators on OpenShift Container Platform, see Working with Operators in OpenShift Container Platform in the OpenShift Container Platform product documentation.

Commands:
redirectUris: - 'https://private-ah-ansible-automation-platform.apps-crc.testing/*' webOrigins: - 'https://private-ah-ansible-automation-platform.apps-crc.testing'
D.2. Host Tags In a cluster configuration, you can define host tags in the configuration files. If you set hosttags = 1 in the tags section, a host tag is automatically defined using the machine's host name. This allow you to use a common configuration file which can be replicated on all your machines so they hold identical copies of the file, but the behavior can differ between machines according to the host name. For information on the configuration files, see Appendix B, The LVM Configuration Files . For each host tag, an extra configuration file is read if it exists: lvm_ hosttag. conf. If that file defines new tags, then further configuration files will be appended to the list of files to read in. For example, the following entry in the configuration file always defines tag1 , and defines tag2 if the host name is host1 .

Commands:
tags { tag1 { } tag2 { host_list = ["host1"] } }
7.2. Limitations of Using Hibernate with JBoss Data Virtualization Many Hibernate use cases assume a data source has the ability (with proper user permissions) to process Data Definition Language (DDL) statements like CREATE TABLE and DROP TABLE as well as Data Manipulation Language (DML) statements like SELECT, UPDATE, INSERT and DELETE. JBoss Data Virtualization can handle a broad range of DML, but does not directly support DDL against a particular source. Sequence and Identity generation are not supported. Identifier generation based upon table values, such as the hilo generator, require that the identifier table(s) be exposed through JBoss Data Virtualization. The GUID identifier generation strategy is directly supported.

Commands:
6.2. Local Authentication: Internal Domain The Red Hat Virtualization Manager creates a limited, internal administration domain during installation. This domain is not the same as an AD or IdM domain, because it exists based on a key in the Red Hat Virtualization PostgreSQL database rather than as a directory service user on a directory server. The internal domain is also different from an external domain because the internal domain will only have one user: the admin@internal user. Taking this approach to initial authentication allows Red Hat Virtualization to be evaluated without requiring a complete, functional directory server, and ensures an administrative account is available to troubleshoot any issues with external directory services. The admin@internal user is for the initial configuration of an environment. This includes installing and accepting hosts, adding external AD or IdM authentication domains, and delegating permissions to users from external domains.

Commands:
Chapter 21. Time Parameters You can modify the time synchronization service with time parameters. Parameter Description ChronyAclRules Access Control List of NTP clients. By default no clients are permitted. The default value is ['deny all'] . ChronyGlobalPoolOptions Default pool options for the configured NTP pools in chrony.conf. If this is specified, NtpIburstEnable, MaxPoll, and MinPoll are ignored. ChronyGlobalServerOptions Default server options for the configured NTP servers in chrony.conf. If this is specified, NtpIburstEnable, MaxPoll, and MinPoll are ignored. EnablePackageInstall Set to true to enable package installation at deploy time. The default value is false . MaxPoll Specify maximum poll interval of upstream servers for NTP messages, in seconds to the power of two. Allowed values are 4 to 17. The default value is 10 . MinPoll Specify minimum poll interval of upstream servers for NTP messages, in seconds to the power of two. The minimum poll interval defaults to 6 (64 s). Allowed values are 4 to 17. The default value is 6 . NtpIburstEnable Specifies whether to enable the iburst option for every NTP peer. If iburst is enabled, when the NTP server is unreachable NTP will send a burst of eight packages instead of one. This is designed to speed up the initial syncrhonization. The default value is true . NtpPool NTP pool list. Defaults to [], so only NtpServer is used by default. NtpServer NTP servers list. The default value is ['0.pool.ntp.org', '1.pool.ntp.org', '2.pool.ntp.org', '3.pool.ntp.org'] . TimeZone The timezone to be set on the overcloud. The default value is UTC .

Commands:
3.5. Search Criteria You can specify the search criteria after the colon in the query. The syntax of {criteria} is as follows: <prop><operator><value> or <obj-type><prop><operator><value> Examples The following table describes the parts of the syntax: Table 3.3. Example Search Criteria Part Description Values Example Note prop The property of the searched-for resource. Can also be the property of a resource type (see obj-type ), or tag (custom tag). Limit your search to objects with a certain property. For example, search for objects with a status property. Status N/A obj-type A resource type that can be associated with the searched-for resource. These are system objects, like data centers and virtual machines. Users N/A operator Comparison operators. = != (not equal) > < >= <= N/A Value options depend on property. Value What the expression is being compared to. String Integer Ranking Date (formatted according to Regional Settings) Jones 256 normal Wildcards can be used within strings. "" (two sets of quotation marks with no space between them) can be used to represent an un-initialized (empty) string. Double quotes should be used around a string or date containing spaces

Commands:
Chapter 5. Storage Enhancements to device-mapper Several significant enhancements to device-mapper have been introduced in Red Hat Enterprise Linux 6.6: The dm-cache device-mapper target, which allows fast storage devices to act as a cache for slower storage devices, has been added as a Technology Preview. The device-mapper-multipath ALUA priority checker no longer places the preferred path device in its own path group if there are other paths that could be used for load balancing. The fast_io_fail_tmo parameter in the multipath.conf file now works on iSCSI devices in addition to Fibre Channel devices. Better performance can now be achieved in setups with a large number of multipath devices due to an improved way in which the device-mapper multipath handles sysfs files. A new force_sync parameter in multipath.conf has been introduced. The parameter disables asynchronous path checks, which can help limit the number of CPU contention issues on setups with a large number of multipath devices. dm-era Technology Preview The device-mapper-persistent-data package now provides tools to help use the new dm-era device mapper functionality released as a Technology Preview. The dm-era functionality keeps track of which blocks on a device were written within user-defined periods of time called an era . This functionality allows backup software to track changed blocks or restore the coherency of a cache after reverting changes.

Commands:
Chapter 1. System Requirements Virtualization is available with the KVM hypervisor for Red Hat Enterprise Linux 7 on the Intel 64 and AMD64 architectures. This chapter lists system requirements for running virtual machines, also referred to as VMs. For information on installing the virtualization packages, see Chapter 2, Installing the Virtualization Packages . 1.1. Host System Requirements Minimum host system requirements 6 GB free disk space. 2 GB RAM. Recommended system requirements One core or thread for each virtualized CPU and one for the host. 2 GB of RAM, plus additional RAM for virtual machines. 6 GB disk space for the host, plus the required disk space for the virtual machine(s). Most guest operating systems require at least 6 GB of disk space. Additional storage space for each guest depends on their workload. Swap space Swap space in Linux is used when the amount of physical memory (RAM) is full. If the system needs more memory resources and the RAM is full, inactive pages in memory are moved to the swap space. While swap space can help machines with a small amount of RAM, it should not be considered a replacement for more RAM. Swap space is located on hard drives, which have a slower access time than physical memory. The size of your swap partition can be calculated from the physical RAM of the host. The Red Hat Customer Portal contains an article on safely and efficiently determining the size of the swap partition: https://access.redhat.com/site/solutions/15244 . When using raw image files, the total disk space required is equal to or greater than the sum of the space required by the image files, the 6 GB of space required by the host operating system, and the swap space for the guest. Equation 1.1. Calculating required space for guest virtual machines using raw images total for raw format = images + hostspace + swap For qcow images, you must also calculate the expected maximum storage requirements of the guest (total for qcow format) , as qcow and qcow2 images are able to grow as required. To allow for this expansion, first multiply the expected maximum storage requirements of the guest (expected maximum guest storage) by 1.01, and add to this the space required by the host (host) , and the necessary swap space (swap) . Equation 1.2. Calculating required space for guest virtual machines using qcow images total for qcow format = (expected maximum guest storage * 1.01) + host + swap Guest virtual machine requirements are further outlined in Chapter 7, Overcommitting with KVM .

Commands:
Chapter 3. Drivers and plugins support with Red Hat OpenStack Services on OpenShift Red Hat OpenStack Services on OpenShift includes components from the OpenStack project, such as drivers or plugins, that enable connectivity to Partner products. Partners may also decide to distribute their own components to be deployed on Red Hat OpenStack Services on OpenShift. To better support the integration of Partner products, Red Hat has established a certification process for ecosystem partners to certify their components with Red Hat OpenStack Services on OpenShift. Using certified components provides customers with a higher level of confidence in usage, as Red Hat and the Partner have an established relationship and the software is certified for combined use. Additional resources For more information on the supportability of RHOSO-certified components, see Support for certified OpenStack Services on OpenShift component . 3.1. Strength of Red Hat Certification program and benefit to customers The strength of the Red Hat certification program lies in the close collaboration between Red Hat and Partners to ensure that certified components, regardless of who ships them, are developed and tested together to ensure customer stability and success. If Red Hat requires subject matter expertise from the component developer for issues, Red Hat collaborates with the partner via TSANet , the industry-standard multi-vendor support community. In this case, partners will provide their support based on their own Severity or SLA response time. Additionally, some Certified Red Hat Partners and Red Hat maintain active engineering relationships that either party can leverage to ensure progress on customer issues. 3.2. Use of uncertified components Using an uncertified component does not invalidate support for the entire Red Hat OpenStack deployment. There might be situations where a customer chooses to deploy an uncertified component. In those instances, Red Hat's general Third-Party Software Support Policy is used as part of the diagnostic process. Key points to consider include: If Red Hat believes that the uncertified component is involved in the reported issue, Red Hat might request replacing that component as a diagnostic step. If removing the uncertified component is not possible, Red Hat might collaborate with another partner on issue resolution. It is recommended by Red Hat that customers maintain active support agreements with all partners that are part of a multi-vendor solution. Red Hat additionally recommends that all partners that a customer chooses to use are part of TSANet , the industry-standard multi-vendor support community.

Commands:
Chapter 2. Custom signup form fields Learn how to add custom signup fields and the different options around this feature. By default, 3scale provides commonly used fields at user/account/application signup. You may need to add your own custom fields to these common defaults. In your Admin Portal, go to Audience > Accounts > Field Definitions where you can see the default form fields and define new ones. The new account/user signup page is actually an amalgamation of the first two sections. The account fields appear at the top, followed by the user fields, followed by the password fields which don't need to be configured. Try adding 3 extra fields, 2 to the user signup section and 1 to the account section. Click create, add the following new field definition and then create it. The required checkbox will, of course, make it mandatory on the signup form. There are also options to make things hidden and read only. A hidden field may be added, for example, when you want new signups to have fields set that you don't necessarily want to highlight to them, such as access_restricted_areas which would be empty by default. As an admin, you can update this to true later on a per-user basis. Your page logic could read it in to determine what to display. A read-only field might be, for example, browser location, which you could use JavaScript on page load to set. Now try adding a drop-down to the user signup form. Call it "employment type". Add these comma-separated values into the choices field: full time, part time, contract. The drop-down will be populated with these values. Now add a pre-defined field to the account. Usually the fields you add have no system functionality - they simply hold data that you can access later. See restricted content . Create a field as normal. Then on the drop-down above "name", choose po_number. With this field, a PO number will appear on 3scale-generated invoices sent to this developer account. System-generated fields can be overridden by your admins at any time. Give the field a name - something like "PO number" - and create it. Now take a look at your work. You can see the free text last name and the employment type drop-down have been added to the User section. The PO number system field, also free text, has been added to the Account section. Finally, these custom fields can be set using the 3scale ActiveDocs; for example, application create .

Commands:
Chapter 14. Using the Skupper Operator on Kubernetes The Red Hat Service Interconnect Operator creates and manages Skupper sites in Kubernetes. 14.1. Creating a site using the Skupper Operator Create a YAML file defining the ConfigMap of the site you want to create. For example, create skupper-site.yaml that provisions a site with a console: apiVersion: v1 kind: ConfigMap metadata: name: skupper-site namespace: my-namespace data: console: "true" flow-collector: "true" console-user: "admin" console-password: "changeme" Note Currently, you must enable the console on the same site as you enable the flow collector. You can also create a site without a console: apiVersion: v1 kind: ConfigMap metadata: name: skupper-site namespace: my-namespace Apply the YAML to create a ConfigMap named skupper-site in the namespace you want to use: USD kubectl apply -f skupper-site.yaml Verify that the site is created by checking that the Skupper router and service controller pods are running: USD kubectl get pods NAME READY STATUS RESTARTS AGE skupper-router-8c6cc6d76-27562 1/1 Running 0 40s skupper-service-controller-57cdbb56c5-vc7s2 1/1 Running 0 34s Note If you deployed the Operator to a single namespace, an additional site controller pod is also running.

Commands:
apiVersion: v1 kind: ConfigMap metadata: name: skupper-site namespace: my-namespace data: console: "true" flow-collector: "true" console-user: "admin" console-password: "changeme"
apiVersion: v1 kind: ConfigMap metadata: name: skupper-site namespace: my-namespace
kubectl apply -f skupper-site.yaml
kubectl get pods NAME READY STATUS RESTARTS AGE skupper-router-8c6cc6d76-27562 1/1 Running 0 40s skupper-service-controller-57cdbb56c5-vc7s2 1/1 Running 0 34s
Chapter 2. Installing .NET 6.0 .NET 6.0 is included in the AppStream repositories for RHEL 8. The AppStream repositories are enabled by default on RHEL 8 systems. You can install the .NET 6.0 runtime with the latest 6.0 Software Development Kit (SDK). When a newer SDK becomes available for .NET 6.0, you can install it by running sudo yum upgrade . Prerequisites Installed and registered RHEL 8 with attached subscriptions. For more information, see Performing a standard RHEL installation . Procedure Install .NET 6.0 and all of its dependencies: Verification steps Verify the installation: The output returns the relevant information about the .NET installation and the environment.

Commands:
sudo yum install dotnet-sdk-6.0 -y
dotnet --info
8.7. bfa-firmware 8.7.1. RHBA-2013:1549 - bfa-firmware bug fix and enhancement update Updated bfa-firmware packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The bfa-firmware package contains the Brocade Fibre Channel Host Bus Adapter (HBA) Firmware to run Brocade Fibre Channel and CNA adapters. This package also supports the Brocade BNA network adapter. Note The bfa-firmware packages have been upgraded to upstream version 3.2.21-1, which provides a number of bug fixes and enhancements over the version. (BZ# 928990 , BZ# 1007100 ) All users of bfa-firmware are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 1. Planning your Red Hat Ansible Automation Platform Operator on Red Hat OpenShift Container Platform Red Hat Ansible Automation Platform is supported on both Red Hat Enterprise Linux and Red Hat Openshift. OpenShift operators help install and automate day-2 operations of complex, distributed software on Red Hat OpenShift Container Platform. The Ansible Automation Platform Operator enables you to deploy and manage Ansible Automation Platform components on Red Hat OpenShift Container Platform. You can use this section to help plan your Red Hat Ansible Automation Platform installation on your Red Hat OpenShift Container Platform environment. Before installing, review the supported installation scenarios to determine which meets your requirements. 1.1. About Ansible Automation Platform Operator The Ansible Automation Platform Operator provides cloud-native, push-button deployment of new Ansible Automation Platform instances in your OpenShift environment. The Ansible Automation Platform Operator includes resource types to deploy and manage instances of automation controller and private automation hub. It also includes automation controller job resources for defining and launching jobs inside your automation controller deployments. Deploying Ansible Automation Platform instances with a Kubernetes native operator offers several advantages over launching instances from a playbook deployed on Red Hat OpenShift Container Platform, including upgrades and full lifecycle support for your Red Hat Ansible Automation Platform deployments. You can install the Ansible Automation Platform Operator from the Red Hat Operators catalog in OperatorHub. 1.2. OpenShift Container Platform version compatibility The Ansible Automation Platform Operator to install Ansible Automation Platform 2.4 is available on OpenShift Container Platform 4.9 and later versions. Additional resources See the Red Hat Ansible Automation Platform Life Cycle for the most current compatibility details. 1.3. Supported installation scenarios for Red Hat OpenShift Container Platform You can use the OperatorHub on the Red Hat OpenShift Container Platform web console to install Ansible Automation Platform Operator. Alternatively, you can install {OperatorPlatform} from the OpenShift Container Platform command-line interface (CLI), oc . Follow one of the workflows below to install the Ansible Automation Platform Operator and use it to install the components of Ansible Automation Platform that you require. Automation controller custom resources first, then automation hub custom resources; Automation hub custom resources first, then automation controller custom resources; Automation controller custom resources; Automation hub custom resources. 1.4. Custom resources You can define custom resources for each primary installation workflows. 1.5. Additional resources See Understanding OperatorHub to learn more about OpenShift Container Platform OperatorHub.

Commands: