mtpti5iD/redhat-docs_dataset huggingface dataset:
18.5. Enhancing Remote Management of Virtual Machines with NSS In Red Hat Enterprise Linux 7.3 and later, you can use the libvirt Name Service Switch (NSS) module to make it easier to connect to guests with SSH, TLS, SSL, as well as other remote login services. In addition, the module also benefits utilities that use host name translation, such as ping . To be able to use this functionality, install the libvirt-nss package: Note If installing libvirt-nss fails, make sure that the Optional repository for Red Hat Enterprise Linux is enabled. For instructions, see the System Administrator's Guide . Finally, enable the module by adding libvirt_guest to the hosts line of the /etc/nsswitch.conf file, for example as follows: The order in which modules are listed on the hosts line determines the order in which these modules are consulted to find the specified remote guest. As a result, libvirt's NSS module is added to modules that translate host domain names to IP addresses. This for example enables connecting to a remote guest in NAT mode without setting a static IP address and only using the guest's name: Note If you do not know the guest's name, you can obtain it by using the virsh list --all command.

Commands:
yum install libvirt-nss
passwd: compat shadow: compat group: compat hosts: files libvirt_guest dns
ssh root@guestname root@guestname's password: Last login: Thu Aug 10 09:12:31 2017 from 192.168.122.1
1.4. Supported Guest CPU Models Every hypervisor has its own policy for which CPU features the guest will see by default. The set of CPU features presented to the guest by the hypervisor depends on the CPU model chosen in the guest virtual machine configuration. 1.4.1. Listing the Guest CPU Models To view a full list of the CPU models supported for an architecture type, run the virsh cpu-models architecture command. For example: The full list of supported CPU models and features is contained in the cpu_map.xml file, located in /usr/share/libvirt/ : A guest's CPU model and features can be changed in the <cpu> section of the domain XML file. See Section 23.12, "CPU Models and Topology" for more information. The host model can be configured to use a specified feature set as needed. For more information, see Section 23.12.1, "Changing the Feature Set for a Specified CPU" .

Commands:
virsh cpu-models x86_64 486 pentium pentium2 pentium3 pentiumpro coreduo n270 core2duo qemu32 kvm32 cpu64-rhel5 cpu64-rhel6 kvm64 qemu64 Conroe Penryn Nehalem Westmere SandyBridge Haswell athlon phenom Opteron_G1 Opteron_G2 Opteron_G3 Opteron_G4 Opteron_G5
virsh cpu-models ppc64 POWER7 POWER7_v2.1 POWER7_v2.3 POWER7+_v2.1 POWER8_v1.0
cat /usr/share/libvirt/cpu_map.xml
8.3. Running Red Hat Enterprise Linux as a Guest Virtual Machine on a Hyper-V Hypervisor It is possible to run a Red Hat Enterprise Linux guest virtual machine on a Microsoft Windows host physical machine running the Microsoft Windows Hyper-V hypervisor. In particular, the following enhancements have been made to allow for easier deployment and management of Red Hat Enterprise Linux guest virtual machines: Upgraded VMBUS protocols - VMBUS protocols have been upgraded to Windows 8 level. As part of this work, now VMBUS interrupts can be processed on all available virtual CPUs in the guest. Furthermore, the signaling protocol between the Red Hat Enterprise Linux guest virtual machine and the Windows host physical machine has been optimized. Synthetic frame buffer driver - Provides enhanced graphics performance and superior resolution for Red Hat Enterprise Linux desktop users. Live Virtual Machine Backup support - Provisions uninterrupted backup support for live Red Hat Enterprise Linux guest virtual machines. Dynamic expansion of fixed size Linux VHDs - Allows expansion of live mounted fixed size Red Hat Enterprise Linux VHDs. For more information, refer to the following article: Enabling Linux Support on Windows Server 2012 R2 Hyper-V . Note The Hyper-V hypervisor supports shrinking a GPT-partitioned disk on a Red Hat Enterprise Linux guest if there is free space after the last partition, by allowing the user to drop the unused last part of the disk. However, this operation will silently delete the secondary GPT header on the disk, which may produce error messages when the guest examines the partition table (for example, when printing the partition table with parted ). This is a known limit of Hyper-V. As a workaround, it is possible to manually restore the secondary GPT header after shrinking the GPT disk by using the expert menu in gdisk and the e command. Furthermore, using the "expand" option in the Hyper-V manager also places the GPT secondary header in a location other than at the end of disk, but this can be moved with parted . See the gdisk and parted man pages for more information on these commands.

Commands:
1.3. Image Builder output formats Image Builder can create images in multiple output formats shown in the following table. Table 1.1. Image Builder output formats Description CLI name file extension QEMU QCOW2 Image qcow2 .qcow2 Ext4 File System Image 80 .qcow2 Raw Partitioned Disk Image partitioned-disk .img Live Bootable ISO live-iso .iso TAR Archive tar .tar Amazon Machine Image Disk ami .ami VMware Virtual Machine Disk vmdk .vmdk Openstack openstack .qcow2

Commands:
6.15. RHEA-2013:0283 - new package: cgdcbxd New cgdcbxd packages are now available for Red Hat Enterprise Linux 6. The cgdcbxd packages provide a daemon to manage the priority of network traffic in Data Center Bridging (DCB) enabled environments. By using the information exchanged over the DCB Capability Exchange Protocol (DCBX) on a LAN, cgdcbxd enforces network priority on running applications on your host with the net_prio cgroup. This enhancement update adds the cgdcbxd packages to Red Hat Enterprise Linux 6. (BZ#835171) All users who require cgdcbxd are advised to install these new packages.

Commands:
Chapter 119. KafkaMirrorMakerTemplate schema reference Used in: KafkaMirrorMakerSpec Property Description deployment Template for Kafka MirrorMaker Deployment . DeploymentTemplate pod Template for Kafka MirrorMaker Pods . PodTemplate podDisruptionBudget Template for Kafka MirrorMaker PodDisruptionBudget . PodDisruptionBudgetTemplate mirrorMakerContainer Template for Kafka MirrorMaker container. ContainerTemplate serviceAccount Template for the Kafka MirrorMaker service account. ResourceTemplate

Commands:
Chapter 6. I/O Scheduling You can use an input/output (I/O) scheduler to improve disk performance both when Red Hat Enterprise Linux 7 is a virtualization host as well as when it is a virtualization guest . 6.1. I/O Scheduling with Red Hat Enterprise Linux as a Virtualization Host When using Red Hat Enterprise Linux 7 as a host for virtualized guests, the default deadline scheduler is usually ideal. This scheduler performs well on nearly all workloads. However, if maximizing I/O throughput is more important than minimizing I/O latency on the guest workloads, it may be beneficial to use the cfq scheduler instead.

Commands:
Chapter 1. Cluster health 1.1. Verifying OpenShift Data Foundation is healthy Storage health is visible on the Block and File and Object dashboards. Procedure In the OpenShift Web Console, click Storage Data Foundation . In the Status card of the Overview tab, click Storage System and then click the storage system link from the pop up that appears. Check if the Status card has a green tick in the Block and File and the Object tabs. Green tick indicates that the cluster is healthy. See Section 1.2, "Storage health levels and cluster state" for information about the different health states and the alerts that appear. 1.2. Storage health levels and cluster state Status information and alerts related to OpenShift Data Foundation are displayed in the storage dashboards. 1.2.1. Block and File dashboard indicators The Block and File dashboard shows the complete state of OpenShift Data Foundation and the state of persistent volumes. The states that are possible for each resource type are listed in the following table. Table 1.1. OpenShift Data Foundation health levels State Icon Description UNKNOWN OpenShift Data Foundation is not deployed or unavailable. Green Tick Cluster health is good. Warning OpenShift Data Foundation cluster is in a warning state. In internal mode, an alert will be displayed along with the issue details. Alerts are not displayed for external mode. Error OpenShift Data Foundation cluster has encountered an error and some component is nonfunctional. In internal mode, an alert is displayed along with the issue details. Alerts are not displayed for external mode. 1.2.2. Object dashboard indicators The Object dashboard shows the state of the Multicloud Object Gateway and any object claims in the cluster. The states that are possible for each resource type are listed in the following table. Table 1.2. Object Service health levels State Description Green Tick Object storage is healthy. Multicloud Object Gateway is not running Shown when NooBaa system is not found. All resources are unhealthy Shown when all NooBaa pools are unhealthy. Many buckets have issues Shown when >= 50% of buckets encounter error(s). Some buckets have issues Shown when >= 30% of buckets encounter error(s). Unavailable Shown when network issues and/or errors exist. 1.2.3. Alert panel The Alert panel appears below the Status card in both the Block and File dashboard and the Object dashboard when the cluster state is not healthy. Information about specific alerts and how to respond to them is available in Troubleshooting OpenShift Data Foundation .

Commands:
Chapter 4. Unsupported and deprecated features Cryostat 2.1 removes some features because of their high maintenance costs, low community interest, and better alternative solutions. ContainerJFR variants Cryostat 2.1 removes the TimeoutHandler implementation. The Vertx server no longer uses this implementation to automatically end a delayed response message that was sent by a Cryostat request handler. The WebClientAssetsHandler and the StaticAssetsHandler now prevent these delayed response issues.

Commands:
Chapter 1. Recommendations for large deployments Use the following undercloud and overcloud recommendations, specifications, and configuration for deploying a large Red Hat OpenStack Platform (RHOSP) environment. RHOSP 17.0 deployments that include more than 100 overcloud nodes are considered large environments. Red Hat has tested and validated optimum performance on a large scale environment of 700 overcloud nodes using RHOSP 17.0 without using minion. For DCN-based deployments, the number of nodes from the central and edge sites can be very high. For recommendations about DCN deployments, contact Red Hat Global Support Services.

Commands:
Chapter 13. Semi-automated installations: Making Kickstart files available to the RHEL installer After your Kickstart file is ready, you can make it available to for installation on the destination system. 13.1. Sharing the installation files on a local volume This procedure describes how to store the Kickstart script file on a volume on the system to be installed. This method enables you to bypass the need for another system. Prerequisites You have a drive that can be moved to the machine to be installed, such as a USB stick. The drive contains a partition that can be read by the installation program. The supported types are ext2 , ext3 , ext4 , xfs , and fat . The drive is connected to the system and its volumes are mounted. Procedure List volume information and note the UUID of the volume to which you want to copy the Kickstart file. Navigate to the file system on the volume. Copy the Kickstart file to this file system. Make a note of the string to use later with the inst.ks= option. This string is in the form hd:UUID= volume-UUID : path/to/kickstart-file.cfg . Note that the path is relative to the file system root, not to the / root of file system hierarchy. Replace volume-UUID with the UUID you noted earlier. Unmount all drive volumes: Add all the volumes to the command, separated by spaces. 13.2. Sharing the installation files on a local volume for automatic loading A specially named Kickstart file can be present in the root of a specially named volume on the system to be installed. This lets you bypass the need for another system, and makes the installation program load the file automatically. Prerequisites You have a drive that can be moved to the machine to be installed, such as a USB stick. The drive contains a partition that can be read by the installation program. The supported types are ext2 , ext3 , ext4 , xfs , and fat . The drive is connected to the system and its volumes are mounted. Procedure List volume information to which you want to copy the Kickstart file. Navigate to the file system on the volume. Copy the Kickstart file into the root of this file system. Rename the Kickstart file to ks.cfg . Rename the volume as OEMDRV : For ext2 , ext3 , and ext4 file systems: For the XFS file system: Replace /dev/xyz with the path to the volume's block device. Unmount all drive volumes: Add all the volumes to the command, separated by spaces.

Commands:
lsblk -l -p -o name,rm,ro,hotplug,size,type,mountpoint,uuid
umount /dev/xyz
lsblk -l -p
e2label /dev/xyz OEMDRV
xfs_admin -L OEMDRV /dev/xyz
umount /dev/xyz
Chapter 1. Introduction Red Hat's Trusted Artifact Signer (RHTAS) service enhances software supply chain security by simplifying cryptographic signing and verifying of software artifacts, such as container images, binaries, and Git commits. Trusted Artifact Signer provides a production ready deployment of the SecureSign community project . The Trusted Artifact Signer software Release Notes documents new features and enhancements, bug fixes, and known issues for the latest version, 1.1.1. We add the newest items to the top in each chapter, as we build upon the official release notes over the lifecycle of the major, and minor releases. The Red Hat Trusted Artifact Signer documentation is available here .

Commands:
Chapter 2. Patching Existing Server Instances Micro releases for the JBoss Data Grid server are distributed as a patch. This is for your convenience, as the new version will not completely replace the installation. The base version to be patched is the x.y.0 release, and the patches x.y.# (micro release or cumulative patch) may be applied to that instance. The patch can be rolled back (including the configuration) if there is any issue during the patching process, and any subsequent patches may be applied in the same way. This process is similar to the already known procedure in JBoss Enterprise Application Platform (EAP). Note It is strongly recommended to back up your existing installation, including all configuration files, before applying the patch. Procedure 2.1. Applying the JBoss Data Grid 6.6.2 Patch Download the patch from the Red Hat Customer Portal at https://access.redhat.com/downloads/ Connect to the running instance to be patched using the JBoss CLI: Ensure that there are no active connections to the server, and then apply the patch: Restart the server: All other distributions, such as the EAP modules, client's, and standalone library mode are provided as a full release. Due to this there is no possibility to patch existing archives for these distributions. Report a bug

Commands:
USDJDG_HOME/bin/cli.sh --connect=127.0.0.1:9999
patch apply /path/to/jboss-datagrid-6.6.2-server-patch.zip
shutdown --restart=true
4.12.2. Disabling ACPI Soft-Off with the BIOS The preferred method of disabling ACPI Soft-Off is with chkconfig management ( Section 4.12.1, "Disabling ACPI Soft-Off with chkconfig Management" ). However, if the preferred method is not effective for your cluster, follow the procedure in this section. Note Disabling ACPI Soft-Off with the BIOS may not be possible with some computers. You can disable ACPI Soft-Off by configuring the BIOS of each cluster node as follows: Reboot the node and start the BIOS CMOS Setup Utility program. Navigate to the Power menu (or equivalent power management menu). At the Power menu, set the Soft-Off by PWR-BTTN function (or equivalent) to Instant-Off (or the equivalent setting that turns off the node by means of the power button without delay). Example 4.1, " BIOS CMOS Setup Utility : Soft-Off by PWR-BTTN set to Instant-Off " shows a Power menu with ACPI Function set to Enabled and Soft-Off by PWR-BTTN set to Instant-Off . Note The equivalents to ACPI Function , Soft-Off by PWR-BTTN , and Instant-Off may vary among computers. However, the objective of this procedure is to configure the BIOS so that the computer is turned off by means of the power button without delay. Exit the BIOS CMOS Setup Utility program, saving the BIOS configuration. When the cluster is configured and running, verify that the node turns off immediately when fenced. For information on testing a fence device, see How to test fence devices and fencing configuration in a RHEL 5, 6, or 7 High Availability cluster? . Example 4.1. BIOS CMOS Setup Utility : Soft-Off by PWR-BTTN set to Instant-Off This example shows ACPI Function set to Enabled , and Soft-Off by PWR-BTTN set to Instant-Off .

Commands:
+---------------------------------------------|-------------------+ | ACPI Function [Enabled] | Item Help | | ACPI Suspend Type [S1(POS)] |-------------------| | x Run VGABIOS if S3 Resume Auto | Menu Level * | | Suspend Mode [Disabled] | | | HDD Power Down [Disabled] | | | Soft-Off by PWR-BTTN [Instant-Off | | | CPU THRM-Throttling [50.0%] | | | Wake-Up by PCI card [Enabled] | | | Power On by Ring [Enabled] | | | Wake Up On LAN [Enabled] | | | x USB KB Wake-Up From S3 Disabled | | | Resume by Alarm [Disabled] | | | x Date(of Month) Alarm 0 | | | x Time(hh:mm:ss) Alarm 0 : 0 : | | | POWER ON Function [BUTTON ONLY | | | x KB Power ON Password Enter | | | x Hot Key Power ON Ctrl-F1 | | | | | | | | +---------------------------------------------|-------------------+
5.2.8. /proc/execdomains This file lists the execution domains currently supported by the Linux kernel, along with the range of personalities they support. Think of execution domains as the "personality" for an operating system. Because other binary formats, such as Solaris, UnixWare, and FreeBSD, can be used with Linux, programmers can change the way the operating system treats system calls from these binaries by changing the personality of the task. Except for the PER_LINUX execution domain, different personalities can be implemented as dynamically loadable modules.

Commands:
0-0 Linux [kernel]
5.182. make 5.182.1. RHBA-2012:0443 - make bug fix update An updated make package that fixes one bug is now available for Red Hat Enterprise Linux 6. GNU make is a tool for controlling the generation of executables and other non-source files of a program from the program's source files. Users can build and install packages by using make without any significant knowledge about the details of the build process. Bug Fix BZ# 699911 Prior to this update, memory corruption could occur in an "eval" expression if one of its sub-expressions was assigned to the same variable. An upstream patch has been applied to address this issue, and memory corruption no longer appears in the described scenario. All users of make are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 18. What data does the subscriptions service store? The subscriptions service gathers data to track usage by using several tools, including Red Hat Insights, Red Hat Subscription Management, Red Hat Satellite and the Satellite inventory upload plugin, OpenShift Cluster Manager, the Red Hat OpenShift monitoring stack, and others. The number of tools that are helping to gather data for your account depends on your subscription profile and the products in it, because different tools are used to gather data for different products. For more information about the data that is gathered and stored by Red Hat Insights, Red Hat Subscription Management, or other products, see that product's documentation. The subscriptions service uses the data that is gathered in three ways: To make sure that inventory is counted only once. Some data is used for deduplication, in both primary and secondary storage. To link data submissions to the proper account and to log how and from what resource the data was received. Some quality control data is included. To calculate subscription values. Some data indicates the presence of Red Hat software and powers the usage portion of the subscriptions service. The subscriptions service itself stores only a subset of the data that is collected by Red Hat Insights. The primary data that is stored by the subscriptions service includes information related to installed Red Hat products, system size, and other similar system characteristics. Additional resources For more information about the types of data that the subscriptions service stores and uses, see the following article: Data Gathered and Used by Subscription Watch For more information about Insights data governance and security, see the following article: Insights 102

Commands:
Part V. Viewing and understanding the subscriptions service data After you set up the environment for the subscriptions service, such as setting up data collection tools or other data sources, completing any additional required subscriptions service activation steps, and waiting for the initial data ingestion, analysis, and processing to be complete (usually no longer than 24 hours), you can begin viewing subscription usage and capacity data in the subscriptions service. Learn more To learn more about how the subscriptions service displays information about your subscription usage and capacity, see the following information: How does the subscriptions service show my subscription data? To learn more about what data the subscriptions service stores, see the following information: What data does the subscriptions service store? To learn more about how your data gets to the subscriptions service and how frequently this data refreshes, see the following information: How the subscriptions service gets and refreshes data

Commands:
Chapter 12. steps To start deploying your OpenShift Data Foundation, you can use the internal mode within OpenShift Container Platform or use external mode to make available services from a cluster running outside of OpenShift Container Platform. Depending on your requirement, go to the respective deployment guides. Internal mode Deploying OpenShift Data Foundation using Amazon web services Deploying OpenShift Data Foundation using Bare Metal Deploying OpenShift Data Foundation using VMWare vSphere Deploying OpenShift Data Foundation using Microsoft Azure Deploying OpenShift Data Foundation using Google Cloud Deploying OpenShift Data Foundation using Red Hat OpenStack Platform [Technology Preview] Deploying OpenShift Data Foundation on IBM Power Deploying OpenShift Data Foundation on IBM Z Deploying OpenShift Data Foundation on any platform External mode Deploying OpenShift Data Foundation in external mode Internal or external For deploying multiple clusters, see Deploying multiple OpenShift Data Foundation clusters .

Commands: