mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. KVM Paravirtualized (virtio) Drivers Paravirtualized drivers enhance the performance of guests, decreasing guest I/O latency and increasing throughput almost to bare-metal levels. It is recommended to use the paravirtualized drivers for fully virtualized guests running I/O-heavy tasks and applications. Virtio drivers are KVM's paravirtualized device drivers, available for guest virtual machines running on KVM hosts. These drivers are included in the virtio package. The virtio package supports block (storage) devices and network interface controllers. Note PCI devices are limited by the virtualized system architecture. See Chapter 16, Guest Virtual Machine Device Configuration for additional limitations when using assigned devices. 5.1. Using KVM virtio Drivers for Existing Storage Devices You can modify an existing hard disk device attached to the guest to use the virtio driver instead of the virtualized IDE driver. The example shown in this section edits libvirt configuration files. Note that the guest virtual machine does not need to be shut down to perform these steps, however the change will not be applied until the guest is completely shut down and rebooted. Procedure 5.1. Using KVM virtio drivers for existing devices Ensure that you have installed the appropriate driver ( viostor ), before continuing with this procedure. Run the virsh edit guestname command as root to edit the XML configuration file for your device. For example, virsh edit guest1 . The configuration files are located in the /etc/libvirt/qemu/ directory. Below is a file-based block device using the virtualized IDE driver. This is a typical entry for a virtual machine not using the virtio drivers. Change the entry to use the virtio device by modifying the bus= entry to virtio . Note that if the disk was previously IDE, it has a target similar to hda , hdb , or hdc . When changing to bus=virtio the target needs to be changed to vda , vdb , or vdc accordingly. Remove the address tag inside the disk tags. This must be done for this procedure to work. Libvirt will regenerate the address tag appropriately the time the virtual machine is started. Alternatively, virt-manager , virsh attach-disk or virsh attach-interface can add a new device using the virtio drivers. See the libvirt website for more details on using Virtio: http://www.linux-kvm.org/page/Virtio

Commands:
<disk type='file' device='disk'> <source file='/var/lib/libvirt/images/disk1.img'/> <target dev='hda' bus='ide'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </disk>
<disk type='file' device='disk'> <source file='/var/lib/libvirt/images/disk1.img'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </disk>
Chapter 84. ExternalConfigurationVolumeSource schema reference Used in: ExternalConfiguration Property Description configMap Reference to a key in a ConfigMap. Exactly one Secret or ConfigMap has to be specified. For more information, see the external documentation for core/v1 configmapvolumesource . ConfigMapVolumeSource name Name of the volume which will be added to the Kafka Connect pods. string secret Reference to a key in a Secret. Exactly one Secret or ConfigMap has to be specified. For more information, see the external documentation for core/v1 secretvolumesource . SecretVolumeSource

Commands:
18.3.5. Automating the Installation with Kickstart You can allow an installation to run unattended by using Kickstart. A Kickstart file specifies settings for an installation. Once the installation system boots, it can read a Kickstart file and carry out the installation process without any further input from a user. On System z, this also requires a parameter file (optionally an additional configuration file under z/VM). This parameter file must contain the required network options described in Section 26.3, "Installation Network Parameters" and specify a kickstart file using the ks= option. The kickstart file typically resides on the network. The parameter file often also contains the options cmdline and RUNKS=1 to execute the loader without having to log in over the network with SSH (Refer to Section 26.6, "Parameters for Kickstart Installations" ). For further information and details on how to set up a kickstart file, refer to Section 32.3, "Creating the Kickstart File" . 18.3.5.1. Every Installation Produces a Kickstart File The Red Hat Enterprise Linux installation process automatically writes a Kickstart file that contains the settings for the installed system. This file is always saved as /root/anaconda-ks.cfg . You may use this file to repeat the installation with identical settings, or modify copies to specify settings for other systems.

Commands:
Providing feedback on Red Hat documentation We appreciate and prioritize your feedback regarding our documentation. Provide as much detail as possible, so that your request can be quickly addressed. Prerequisites You are logged in to the Red Hat Customer Portal. Procedure To provide feedback, perform the following steps: Click the following link: Create Issue . Describe the issue or enhancement in the Summary text box. Provide details about the issue or requested enhancement in the Description text box. Type your name in the Reporter text box. Click the Create button. This action creates a documentation ticket and routes it to the appropriate documentation team. Thank you for taking the time to provide feedback.

Commands:
4.6. Configuring SSL Connections with the TPS By default, the TPS communicates with the Enterprise Security Client over standard HTTP. It is also possible, and in many situations desirable, to secure the TPS-client communications by using HTTP over SSL (HTTPS). The Enterprise Security Client has to have the CA certificate for the CA which issued the TPS's certificates in order to trust the TPS connection. From there, the Enterprise Security Client can be configured to connect to the TPS's SSL certificate. Download the CA certificate used by the TPS. Open the CA's end user pages in a web browser. Click the Retrieval tab at the top. In the left menu, click the Import CA Certificate Chain link. Choose the radio button to download the chain as a file, and remember the location and name of the downloaded file. Open the Enterprise Security Client. Import the CA certificate. Click the View Certificates button. Click the Authorities tab. Click Import . Browse to the CA certificate chain file, and select it. When prompted, confirm that you want to trust the CA. The Enterprise Security Client needs to be configured to communicate with the TPS over SSL; this is done by setting the Phone Home URL , which is the default URL the Enterprise Security Client uses to connect to the TPS. Insert a new, blank token into the machine. Blank tokens are unformatted, so they do not have an existing Phone Home URL, and the URL must be set manually. Formatted tokens (tokens can be formatted by the manufacturer or by your IT department) already have the URL set, and thus do not prompt to set the Phone Home URL. Fill in the new TPS URL with the SSL port information. For example: Click the Test button to send a message to the TPS. If the request is successful, the client opens a dialog box saying that the Phone Home URL was successfully obtained.

Commands:
http s ://server.example.com: 9444/ca/ee/ca/
http s ://server.example.com: 7890 /cgi-bin/home/index.cgi
Chapter 1. Selecting OpenShift AI administrator and user groups By default, all users authenticated in OpenShift can access OpenShift AI. Also by default, users with cluster-admin permissions are OpenShift AI administrators. A cluster admin is a superuser that can perform any action in any project in the OpenShift cluster. When bound to a user with a local binding, they have full control over quota and every action on every resource in the project. After a cluster admin user defines additional administrator and user groups in OpenShift, you can add those groups to OpenShift AI by selecting them in the OpenShift AI dashboard. Prerequisites You have logged in to OpenShift AI as a user with OpenShift AI administrator privileges. The groups that you want to select as administrator and user groups for OpenShift AI already exist in OpenShift. For more information, see Managing users and groups . Procedure From the OpenShift AI dashboard, click Settings User management . Select your OpenShift AI administrator groups: Under Data science administrator groups , click the text box and select an OpenShift group. Repeat this process to define multiple administrator groups. Select your OpenShift AI user groups: Under Data science user groups , click the text box and select an OpenShift group. Repeat this process to define multiple user groups. Important The system:authenticated setting allows all users authenticated in OpenShift to access OpenShift AI. Click Save changes . Verification Administrator users can successfully log in to OpenShift AI and have access to the Settings navigation menu. Non-administrator users can successfully log in to OpenShift AI. They can also access and use individual components, such as projects and workbenches.

Commands:
20.3.4.5. Configuring ssh-agent The ssh-agent can be used to store your passphrase so that you do not have to enter it each time you make a ssh or scp connection. If you are not running the X Window System, follow these steps from a shell prompt. If you are running GNOME but you do not want to configure it to prompt you for your passphrase when you log in (refer to Section 20.3.4.4, "Configuring ssh-agent with GNOME" ), this procedure will work in a terminal window, such as an XTerm. If you are running X but not GNOME, this procedure will work in a terminal window. However, your passphrase will only be remembered for that terminal window; it is not a global setting. At a shell prompt, type the following command: Then type the command: and enter your passphrase(s). If you have more than one key pair configured, you will be prompted for each one. When you log out, your passphrase(s) will be forgotten. You must execute these two commands each time you log in to a virtual console or open a terminal window.

Commands:
exec /usr/bin/ssh-agent USDSHELL
ssh-add
Chapter 2. FIPS support Federal Information Processing Standards (FIPS) are standards for computer security and interoperability. To use FIPS with AMQ Streams, you must have a FIPS-compliant OpenJDK (Open Java Development Kit) installed on your system. If your RHEL system is FIPS-enabled, OpenJDK automatically switches to FIPS mode when running AMQ Streams. This ensures that AMQ Streams uses the FIPS-compliant security libraries provided by OpenJDK. Minimum password length When running in the FIPS mode, SCRAM-SHA-512 passwords need to be at least 32 characters long. If you have a Kafka cluster with custom configuration that uses a password length that is less than 32 characters, you need to update your configuration. If you have any users with passwords shorter than 32 characters, you need to regenerate a password with the required length. Additional resources What are Federal Information Processing Standards (FIPS) 2.1. Installing AMQ Streams with FIPS mode enabled Enable FIPS mode before you install AMQ Streams on RHEL. Red Hat recommends installing RHEL with FIPS mode enabled, as opposed to enabling FIPS mode later. Enabling FIPS mode during the installation ensures that the system generates all keys with FIPS-approved algorithms and continuous monitoring tests in place. With RHEL running in FIPS mode, you must ensure that the AMQ Streams configuration is FIPS-compliant. Additionally, your Java implementation must also be FIPS-compliant. Note Running AMQ Streams on RHEL in FIPS mode requires a FIPS-compliant JDK. We recommend using OpenJDK 17.0.6 or newer. Procedure Install RHEL in FIPS mode. For further information, see the information on security hardening in the RHEL documentation . Proceed with the installation of AMQ Streams. Configure AMQ Streams to use FIPS-compliant algorithms and protocols. If used, ensure that the following configuration is compliant: SSL cipher suites and TLS versions must be supported by the JDK framework. SCRAM-SHA-512 passwords must be at least 32 characters long. Important Make sure that your installation environment and AMQ Streams configuration remains compliant as FIPS requirements change.

Commands:
Chapter 10. Troubleshooting builds Use the following to troubleshoot build issues. 10.1. Resolving denial for access to resources If your request for access to resources is denied: Issue A build fails with: requested access to the resource is denied Resolution You have exceeded one of the image quotas set on your project. Check your current quota and verify the limits applied and storage in use: USD oc describe quota 10.2. Service certificate generation failure If your request for access to resources is denied: Issue If a service certificate generation fails with (service's service.beta.openshift.io/serving-cert-generation-error annotation contains): Example output secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60 Resolution The service that generated the certificate no longer exists, or has a different serviceUID . You must force certificates regeneration by removing the old secret, and clearing the following annotations on the service: service.beta.openshift.io/serving-cert-generation-error and service.beta.openshift.io/serving-cert-generation-error-num . To clear the annotations, enter the following commands: USD oc delete secret <secret_name> USD oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error- USD oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num- Note The command removing an annotation has a - after the annotation name to be removed.

Commands:
requested access to the resource is denied
oc describe quota
secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60
oc delete secret <secret_name>
oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-
oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-
11.2. Hardware Requirements For installation of Red Hat Enterprise Linux on IBM Power Systems servers, Red Hat supports hard drives connected by a standard internal interface, such as SCSI, SATA, or SAS. Fibre Channel Host Bus Adapters and multipath devices are supported. Vendor-provided drivers may be required for certain hardware. Virtualized installation on Power Systems servers is also supported when using Virtual SCSI (vSCSI) adapters in virtual client LPARs. Note that Red Hat does not support installation to USB drives or SD memory cards.

Commands:
Chapter 8. Publishing on the catalog After uploading your test result files, your application is scanned for vulnerabilities. When the scanning is complete, you can publish your product on the Red Hat Ecosystem Catalog . To receive RHOSO certification, ensure: All required tests have been run successfully. Red Hat has reviewed and validated your test configuration report. Perform the following steps to publish your product on the catalog: Procedure Navigate to your Product listing page. Click Publish . Your certified application is now published on the Red Hat Ecosystem Catalog .

Commands:
3.2. Listing Data Centers This Ruby example lists the data centers. # Get the reference to the root of the services tree: system_service = connection.system_service # Get the reference to the service that manages the # collection of data centers: dcs_service = system_service.data_centers_service # Retrieve the list of data centers and for each one # print its name: dcs = dcs_service.list dcs.each do |dc| puts dc.name end In an environment with only the Default data center, the example outputs: For more information, see http://www.rubydoc.info/gems/ovirt-engine-sdk/OvirtSDK4/DataCentersService:list .

Commands:
Get the reference to the root of the services tree: system_service = connection.system_service Get the reference to the service that manages the collection of data centers: dcs_service = system_service.data_centers_service Retrieve the list of data centers and for each one print its name: dcs = dcs_service.list dcs.each do |dc| puts dc.name end
Default
Appendix D. LVM Object Tags An LVM tag is a word that can be used to group LVM2 objects of the same type together. Tags can be attached to objects such as physical volumes, volume groups, and logical volumes. Tags can be attached to hosts in a cluster configuration. Tags can be given on the command line in place of PV, VG or LV arguments. Tags should be prefixed with @ to avoid ambiguity. Each tag is expanded by replacing it with all objects possessing that tag which are of the type expected by its position on the command line. As of the Red Hat Enterprise Linux 6.1 release, LVM tags are strings of up to 1024 characters (for earlier releases the upper length limit was 128 characters). LVM tags cannot start with a hyphen. A valid tag can consist of a limited range of characters only. For the Red Hat Enterprise Linux 6.0 release, the allowed characters are [A-Za-z0-9_+.-]. As of the Red Hat Enterprise Linux 6.1 release, the list of allowed characters has been extended, and tags can contain the "/", "=", "!", ":", "#", and "&" characters. Only objects in a volume group can be tagged. Physical volumes lose their tags if they are removed from a volume group; this is because tags are stored as part of the volume group metadata and that is deleted when a physical volume is removed. The following command lists all the logical volumes with the database tag. The following command lists the currently active host tags. D.1. Adding and Removing Object Tags To add or delete tags from physical volumes, use the --addtag or --deltag option of the pvchange command. To add or delete tags from volume groups, use the --addtag or --deltag option of the vgchange or vgcreate commands. To add or delete tags from logical volumes, use the --addtag or --deltag option of the lvchange or lvcreate commands. As of the Red Hat Enterprise Linux 6.1 release, you can specify multiple --addtag and --deltag arguments within a single pvchange , vgchange , or lvchange command. For example, the following command deletes the tags T9 and T10 and adds the tags T13 and T14 to the volume group grant .

Commands:
lvs @database
lvm tags
vgchange --deltag T9 --deltag T10 --addtag T13 --addtag T14 grant
7.125. libusb1 7.125.1. RHBA-2013:0310 - libusb1 bug fix update Updated libusb1 packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The libusb1 packages provide a library to communicate with USB devices from userspace. Bug Fixes BZ# 820205 Prior to this update, the usbredir network protocol caused a conflict with the libusb library. As a consequence, SPICE USB-redirection failed with the following errors in the virt-viewer tool: usbredirhost error: submitting bulk transfer on ep 02: -1" when trying to redirect one USB device to two guests simultaneously. This update modifies the underlying code to send the error message "Device is busy" and fail after the second attempt. BZ#830751 Prior to this update, USB Request Blocks (URBs) from the user space were not allowed to have transfer buffers larger than an arbitrary maximum. As a consequence, attempting to redirect certain USB mass-storage devices could fail. This update modifies the underlying code to allow programs to submit URBs of any size. If there is not sufficient memory available, the submission fails with an ENOMEM error. In addition, this update also replaces the old limits on individual transfer buffers with a single global limit of 16MB on the total amount of memory in use by the USB file system (usbfs) to prevent programs from submitting a lot of small URBs and so using all the DMA-able kernel memory. All users of libusb1 are advised to upgrade to these updated packages, which fix these bugs.

Commands:
End-user Guide Red Hat CodeReady Workspaces 2.15 Using Red Hat CodeReady Workspaces 2.15 Robert Kratky rkratky@redhat.com Fabrice Flore-Thebault ffloreth@redhat.com Jana Vrbkova jvrbkova@redhat.com Max Leonov mleonov@redhat.com Red Hat Developer Group Documentation Team devtools-docs@redhat.com

Commands:
Appendix B. Revision History Revision History Revision 4.1-1 Wed Aug 7 2019 Steven Levine Preparing document for 7.7 GA publication. Revision 3.1-2 Thu Oct 4 2018 Steven Levine Preparing document for 7.6 GA publication. Revision 2.1-1 Thu Mar 15 2018 Steven Levine Preparing document for 7.5 GA publication. Revision 2.1-0 Thu Dec 14 2017 Steven Levine Preparing document for 7.5 Beta publication. Revision 0.6-5 Wed Nov 22 2017 Steven Levine Updated version for 7.4. Revision 0.6-3 Thu Jul 27 2017 Steven Levine Document version for 7.4 GA publication. Revision 0.6-1 Wed May 10 2017 Steven Levine Preparing document for 7.4 Beta publication. Revision 0.5-9 Mon Dec 5 2016 Steven Levine Updated Version for 7.3. Revision 0.5-7 Mon Oct 17 2016 Steven Levine Version for 7.3 GA publication. Revision 0.5-6 Thu Aug 18 2016 Steven Levine Preparing document for 7.3 Beta publication. Revision 0.3-2 Mon Nov 9 2015 Steven Levine Preparing document for 7.2 GA publication. Revision 0.3-0 Wed Aug 19 2015 Steven Levine Preparing document for 7.2 Beta publication. Revision 0.2-6 Mon Feb 16 2015 Steven Levine Version for 7.1 GA release Revision 0.2-5 Thu Dec 11 2014 Steven Levine Version for 7.1 Beta release Revision 0.2-4 Thu Dec 04 2014 Steven Levine Version for 7.1 Beta release Revision 0.1-12 Tue Jun 03 2014 John Ha Version for 7.0 GA Release Revision 0.1-6 Mon Jun 13 2013 John Ha Build for beta of Red Hat Enterprise Linux 7 Revision 0.1-1 Wed Jan 16 2013 John Ha Branched from Red Hat Enterprise Linux 6 version of this Document

Commands:
12.6. Common Mistakes to Avoid It is very common for beginners to make mistakes when editing BIND configuration files. Be sure to avoid the following issues: Take care to increment the serial number when editing a zone file. If the serial number is not incremented, the master nameserver has the correct, new information, but the slave nameservers are never notified of the change and do not attempt to refresh their data of that zone. Be careful to use ellipses and semi-colons correctly in the /etc/named.conf file. An omitted semi-colon or unclosed ellipse section can cause named to refuse to start. Remember to place periods ( . ) in zone files after all FQDNs and omit them on hostnames. A period at the end of a domain name denotes a fully qualified domain name. If the period is omitted, then named appends the name of the zone or the USDORIGIN value to complete it. If a firewall is blocking connections from the named program to other nameservers, edit its configuration file. By default, BIND version 9 uses random ports above 1024 to query other nameservers. Some firewalls, however, expect all nameservers to communicate using only port 53. To force named to use port 53, add the following line to the options statement of /etc/named.conf :

Commands:
query-source address * port 53;