mtpti5iD/redhat-docs_dataset huggingface dataset:
13.3.2. Adding Hard Drives and Other Block Devices to a Guest System administrators have the option to use additional hard drives to provide increased storage space for a guest, or to separate system data from user data. Procedure 13.2. Adding physical block devices to guests This procedure describes how to add a hard drive on the host physical machine to a guest. It applies to all physical block devices, including CD-ROM, DVD and floppy devices. Physically attach the hard disk device to the host physical machine. Configure the host physical machine if the drive is not accessible by default. Do one of the following: Create the additional storage by writing a disk element in a new file. In this example, this file will be known as NewStorage.xml . The following example is a configuration file section which contains an additional device-based storage container for the host physical machine partition /dev/sr0: Follow the instruction in the section to attach the device to the guest virtual machine. Alternatively, you can use the virsh attach-disk command, as shown: Note that the following options are available: The virsh attach-disk command also accepts the --config , --type , and --mode options, as shown: Additionally, --type also accepts --type disk in cases where the device is a hard drive. The guest virtual machine now has a new hard disk device called /dev/vdc on Linux (or something similar, depending on what the guest virtual machine OS chooses) or D: drive (for example) on Windows. You can now initialize the disk from the guest virtual machine, following the standard procedures for the guest virtual machine's operating system. Refer to Procedure 13.1, "Adding file-based storage" for an example. Warning When adding block devices to a guest, make sure to follow security considerations. This information is discussed in more detail in the Red Hat Enterprise Linux Virtualization Security Guide which can be found at https://access.redhat.com/site/documentation/ . Important Guest virtual machines should not be given write access to whole disks or block devices (for example, /dev/sdb ). Guest virtual machines with access to whole block devices may be able to modify volume labels, which can be used to compromise the host physical machine system. Use partitions (for example, /dev/sdb1 ) or LVM volumes to prevent this issue.

Commands:
<disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source dev='/dev/sr0'/> <target dev='vdc' bus='virtio'/> </disk>
# virsh attach-disk Guest1 /dev/sr0 vdc
# virsh attach-disk Guest1 /dev/sr0 vdc --config --type cdrom --mode readonly
20.41. Configuring the Guest Virtual Machine CPU Model For simple defaults, the guest virtual machine CPU configuration accepts the same basic XML representation as the host physical machine capabilities XML exposes. In other words, the XML from the virsh cpu-baseline command can now be copied directly into the guest virtual machine XML at the top level under the domain element. In the XML snippet, there are a few extra attributes available when describing a CPU in the guest virtual machine XML. These can mostly be ignored, but for the curious here is a quick description of what they do. The top level <cpu> element has an attribute called match with possible values of: match='minimum' - the host physical machine CPU must have at least the CPU features described in the guest virtual machine XML. If the host physical machine has additional features beyond the guest virtual machine configuration, these will also be exposed to the guest virtual machine. match='exact' - the host physical machine CPU must have at least the CPU features described in the guest virtual machine XML. If the host physical machine has additional features beyond the guest virtual machine configuration, these will be masked out from the guest virtual machine. match='strict' - the host physical machine CPU must have exactly the same CPU features described in the guest virtual machine XML. The enhancement is that the <feature> elements can each have an extra 'policy' attribute with possible values of: policy='force' - expose the feature to the guest virtual machine even if the host physical machine does not have it. This is usually only useful in the case of software emulation. Note It is possible that even using the force policy, the hypervisor may not be able to emulate the particular feature. policy='require' - expose the feature to the guest virtual machine and fail if the host physical machine does not have it. This is the sensible default. policy='optional' - expose the feature to the guest virtual machine if it happens to support it. policy='disable' - if the host physical machine has this feature, then hide it from the guest virtual machine. policy='forbid' - if the host physical machine has this feature, then fail and refuse to start the guest virtual machine. The 'forbid' policy is for a niche scenario where an incorrectly functioning application will try to use a feature even if it is not in the CPUID mask, and you wish to prevent accidentally running the guest virtual machine on a host physical machine with that feature. The 'optional' policy has special behavior with respect to migration. When the guest virtual machine is initially started the flag is optional, but when the guest virtual machine is live migrated, this policy turns into 'require', since you cannot have features disappearing across migration.

Commands:
Chapter 12. Supported integration with Red Hat products Streams for Apache Kafka 2.9 supports integration with the following Red Hat products: Red Hat build of Keycloak Provides OAuth 2.0 authentication and OAuth 2.0 authorization. For information on the functionality these products can introduce to your Streams for Apache Kafka deployment, refer to the product documentation. 12.1. Red Hat build of Keycloak (formerly Red Hat Single Sign-On) Streams for Apache Kafka supports OAuth 2.0 token-based authorization through Red Hat build of Keycloak Authorization Services , providing centralized management of security policies and permissions. Note Red Hat build of Keycloak replaces Red Hat Single Sign-On, which is now in maintenance support. We are working on updating our documentation, resources, and media to reflect this transition. In the interim, content that describes using Single Sign-On in the Streams for Apache Kafka documentation also applies to using the Red Hat build of Keycloak. Additional resources Red Hat build of Keycloak Supported Configurations Revised on 2025-03-05 17:44:31 UTC

Commands:
10.8. Each Node in a Two-Node Cluster Reports Second Node Down If your cluster is a two-node cluster and each node reports that it is up but that the other node is down, this indicates that your cluster nodes are unable to communicate with each other by means of multicast over the cluster heartbeat network. This is known as "split brain" or a "network partition." To address this, check the conditions outlined in Section 10.2, "Cluster Does Not Form" .

Commands:
A.8. vmstat Vmstat outputs reports on your system's processes, memory, paging, block input/output, interrupts, and CPU activity. It provides an instantaneous report of the average of these events since the machine was last booted, or since the report. -a Displays active and inactive memory. -f Displays the number of forks since boot. This includes the fork , vfork , and clone system calls, and is equivalent to the total number of tasks created. Each process is represented by one or more tasks, depending on thread usage. This display does not repeat. -m Displays slab information. -n Specifies that the header will appear once, not periodically. -s Displays a table of various event counters and memory statistics. This display does not repeat. delay The delay between reports in seconds. If no delay is specified, only one report is printed, with the average values since the machine was last booted. count The number of times to report on the system. If no count is specified and delay is defined, vmstat reports indefinitely. -d Displays disk statistics. -p Takes a partition name as a value, and reports detailed statistics for that partition. -S Defines the units output by the report. Valid values are k (1000 bytes), K (1024 bytes), m (1,000,000 bytes), or M (1,048,576 bytes). -D Report summary statistics about disk activity. For detailed information about the output provided by each output mode, see the man page:

Commands:
man vmstat
27.4. Configuration Examples 27.4.1. Labeling Gluster Bricks A Gluster brick is an export directory on a server in the trusted storage pool. In case that the brick is not labeled with the correct SELinux context, glusterd_brick_t , SELinux denies certain file access operations and generates various AVC messages. The following procedure shows how to label Gluster bricks with the correct SELinux context. The procedure assumes that you previously created and formatted a logical volume, for example /dev/rhgs/gluster , to be used as the Gluster brick. For detailed information about Gluster bricks, see the Red Hat Gluster Storage Volumes chapter in the Administration Guide for Red Hat Gluster Storage. Procedure 27.1. How to Label a Gluster Brick Create a directory to mount the previously formatted logical volume. For example: Mount the logical volume, in this case /dev/vg-group/gluster , to the /mnt/brick1/ directory created in the step. Note that the mount command mounts devices only temporarily. To mount the device permanently, add an entry similar as the following one to the /etc/fstab file: For more information, see the fstab (5) manual page. Check the SELinux context of /mnt/brick1/ : The directory is labeled with the unlabeled_t SELinux type. Change the SELinux type of /mnt/brick1/ to the glusterd_brick_t SELinux type: Use the restorecon utility to apply the changes: Finally, verify that the context has been successfully changed:

Commands:
~]# mkdir /mnt/brick1
~]# mount /dev/vg-group/gluster /mnt/brick1/
/dev/vg-group/gluster /mnt/brick1 xfs rw,inode64,noatime,nouuid 1 2
~]USD ls -lZd /mnt/brick1/ drwxr-xr-x. root root system_u:object_r:unlabeled_t:s0 /mnt/brick1/
~]# semanage fcontext -a -t glusterd_brick_t "/mnt/brick1(/.*)?"
~]# restorecon -Rv /mnt/brick1
~]USD ls -lZd /mnt/brick1 drwxr-xr-x. root root system_u:object_r:glusterd_brick_t:s0 /mnt/brick1/
Chapter 16. tags Optional. An operator-defined list of tags placed on each log by the collector or normalizer. The payload can be a string with whitespace-delimited string tokens or a JSON list of string tokens. Data type text file The path to the log file from which the collector reads this log entry. Normally, this is a path in the /var/log file system of a cluster node. Data type text offset The offset value. Can represent bytes to the start of the log line in the file (zero- or one-based), or log line numbers (zero- or one-based), so long as the values are strictly monotonically increasing in the context of a single log file. The values are allowed to wrap, representing a new version of the log file (rotation). Data type long

Commands:
B.2. GFS to GFS2 Conversion Procedure Use the following procedure to convert a GFS file system to a GFS2 file system. On a Red Hat Enterprise Linux system, make a backup of your existing GFS file system. Unmount the GFS file system from all nodes in the cluster. Execute the gfs_fsck command on the GFS file system to ensure there is no file system corruption. Execute gfs2_convert gfsfilesystem . The system will display warnings and confirmation questions before converting gfsfilesystem to GFS2. Upgrade to Red Hat Enterprise Linux 6. The following example converts a GFS file system on block device /dev/shell_vg/500g to a GFS2 file system.

Commands:
/root/cluster/gfs2/convert/gfs2_convert /dev/shell_vg/500g gfs2_convert version 2 (built May 10 2010 10:05:40) Copyright (C) Red Hat, Inc. 2004-2006 All rights reserved. Examining file system............... This program will convert a gfs1 filesystem to a gfs2 filesystem. WARNING: This can't be undone. It is strongly advised that you: 1. Back up your entire filesystem first. 2. Run gfs_fsck first to ensure filesystem integrity. 3. Make sure the filesystem is NOT mounted from any node. 4. Make sure you have the latest software versions. Convert /dev/shell_vg/500g from GFS1 to GFS2? (y/n)y Converting resource groups................ Converting inodes. 24208 inodes from 1862 rgs converted. Fixing file and directory information. 18 cdpn symlinks moved to empty directories. Converting journals. Converting journal space to rg space. Writing journal #1...done. Writing journal #2...done. Writing journal #3...done. Writing journal #4...done. Building GFS2 file system structures. Removing obsolete GFS1 file system structures. Committing changes to disk. /dev/shell_vg/500g: filesystem converted successfully to gfs2.
36.6.2. Itanium Systems Itanium systems use ELILO as the boot loader, which uses /boot/efi/EFI/redhat/elilo.conf as the configuration file. Confirm that this file contains an image section with the same version as the kernel package just installed: Notice that the default is not set to the new kernel. To configure ELILO to boot the new kernel, change the value of the default variable to the value of the label for the image section that contains the new kernel. Begin testing the new kernel by rebooting the computer and watching the messages to ensure that the hardware is detected properly.

Commands:
prompt timeout=50 default=old image=vmlinuz-2.6.9-5.EL label=linux initrd=initrd-2.6.9-5.EL.img read-only append="root=LABEL=/" image=vmlinuz-2.6.9-1.906_EL label=old initrd=initrd-2.6.9-1.906.img read-only append="root=LABEL=/"
Chapter 6. Additional Resources This chapter provides references to other relevant sources of information about Red Hat Software Collections 3.3 and Red Hat Enterprise Linux. 6.1. Red Hat Product Documentation The following documents are directly or indirectly relevant to this book: Red Hat Software Collections 3.3 Packaging Guide - The Packaging Guide for Red Hat Software Collections explains the concept of Software Collections, documents the scl utility, and provides a detailed explanation of how to create a custom Software Collection or extend an existing one. Red Hat Developer Toolset 8.1 Release Notes - The Release Notes for Red Hat Developer Toolset document known problems, possible issues, changes, and other important information about this Software Collection. Red Hat Developer Toolset 8.1 User Guide - The User Guide for Red Hat Developer Toolset contains more information about installing and using this Software Collection. Using Red Hat Software Collections Container Images - This book provides information on how to use container images based on Red Hat Software Collections. The available container images include applications, daemons, databases, as well as the Red Hat Developer Toolset container images. The images can be run on Red Hat Enterprise Linux 7 Server and Red Hat Enterprise Linux Atomic Host. Getting Started with Containers - This guide contains a comprehensive overview of information about building and using container images on Red Hat Enterprise Linux 7 and Red Hat Enterprise Linux Atomic Host. Using and Configuring Red Hat Subscription Manager - The Using and Configuring Red Hat Subscription Manager book provides detailed information on how to register Red Hat Enterprise Linux systems, manage subscriptions, and view notifications for the registered systems. Red Hat Enterprise Linux 6 Deployment Guide - The Deployment Guide for Red Hat Enterprise Linux 6 provides relevant information regarding the deployment, configuration, and administration of this system. Red Hat Enterprise Linux 7 System Administrator's Guide - The System Administrator's Guide for Red Hat Enterprise Linux 7 provides information on deployment, configuration, and administration of this system. 6.2. Red Hat Developers Red Hat Developer Program - The Red Hat Developers community portal. Overview of Red Hat Software Collections on Red Hat Developers - The Red Hat Developers portal provides a number of tutorials to get you started with developing code using different development technologies. This includes the Node.js, Perl, PHP, Python, and Ruby Software Collections. Red Hat Developer Blog - The Red Hat Developer Blog contains up-to-date information, best practices, opinion, product and program announcements as well as pointers to sample code and other resources for those who are designing and developing applications based on Red Hat technologies.

Commands:
Chapter 1. Deploying a Block Storage service custom back end The Red Hat OpenStack Platform director installs and manages a complete, Enterprise-grade OpenStack deployment with minimal manual configuration. For more information about the director, see the Director Installation and Usage guide. The Openstack environment that director creates is called the overcloud. The overcloud contains all the components that provide services to end users, including Block Storage. This document provides guidance about how to deploy a custom back end to the Block Storage service (cinder) on the overcloud. By default, the Block Storage service is installed on Controller nodes. Prerequisites You have already deployed the overcloud with the director. The overcloud has a functioning Block Storage service. You are familiar with Block Storage concepts and configuration. For more information about Block Storage, see Block Storage and Volumes in the Storage Guide . Warning This procedure has been tested successfully in limited use cases. Ensure that you test your planned deployment on a non-production environment first. If you have any questions, contact Red Hat support.

Commands:
30.4. Performing the Upgrade After retrieving all of the necessary packages, it is time to upgrade the existing kernel. Important It is strongly recommended that you keep the old kernel in case there are problems with the new kernel. At a shell prompt, change to the directory that contains the kernel RPM packages. Use -i argument with the rpm command to keep the old kernel. Do not use the -U option, since it overwrites the currently installed kernel, which creates boot loader problems. For example: The step is to verify that the initial RAM disk image has been created. See Section 30.5, "Verifying the Initial RAM Disk Image" for details.

Commands:
~]# rpm -ivh kernel- <kernel_version> . <arch> .rpm
7.59. firstboot 7.59.1. RHEA-2013:0488 - firstboot enhancement update Updated firstboot packages that add one enhancement are now available for Red Hat Enterprise Linux 6. The firstboot utility runs after installation and guides the user through a series of steps that allows for easier configuration of the machine. Enhancement BZ#831818 Previously, the Firstboot utility allowed displaying only the English version of the End User Licence Agreement (EULA), which could be problematic for users who do not understand English. This update modifies Firstboot so that it uses the USDLANG environment variable to find the localized EULA file according to the language set during installation. If the EULA file in the selected language is not found, the default EULA file, which is in English, is used. Users can now read the EULA document in the language chosen during installation before accepting it. All users of firstboot are advised to upgrade to these updated packages, which add this enhancement.

Commands:
6.3. Hyper-V Red Hat Enterprise Linux 7 Hosted as a Generation 2 Virtual Machine Red Hat Enterprise Linux 7 can be used as a generation 2 virtual machine in the Microsoft Hyper-V Server 2012 R2 host. In addition to the functions supported in the generation, generation 2 provides new functions on a virtual machine; for example: boot from a SCSI virtual hard disk, and UEFI firmware support.

Commands:
Chapter 12. Internationalization 12.1. Red Hat Enterprise Linux 8 international languages Red Hat Enterprise Linux 8 supports the installation of multiple languages and the changing of languages based on your requirements. East Asian Languages - Japanese, Korean, Simplified Chinese, and Traditional Chinese. European Languages - English, German, Spanish, French, Italian, Portuguese, and Russian. The following table lists the fonts and input methods provided for various major languages. Language Default Font (Font Package) Input Methods English dejavu-sans-fonts French dejavu-sans-fonts German dejavu-sans-fonts Italian dejavu-sans-fonts Russian dejavu-sans-fonts Spanish dejavu-sans-fonts Portuguese dejavu-sans-fonts Simplified Chinese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-libpinyin, libpinyin Traditional Chinese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-libzhuyin, libzhuyin Japanese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-kkc, libkkc Korean google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-hangul, libhangul 12.2. Notable changes to internationalization in RHEL 8 RHEL 8 introduces the following changes to internationalization compared to RHEL 7: Support for the Unicode 11 computing industry standard has been added. Internationalization is distributed in multiple packages, which allows for smaller footprint installations. For more information, see Using langpacks . A number of glibc locales have been synchronized with Unicode Common Locale Data Repository (CLDR).

Commands: