mtpti5iD/redhat-docs_dataset huggingface dataset:
10.5. Using KVM virtio Drivers for New Devices This procedure covers creating new devices using the KVM virtio drivers with virt-manager . Alternatively, the virsh attach-disk or virsh attach-interface commands can be used to attach devices using the virtio drivers. Important Ensure the drivers have been installed on the Windows guest before proceeding to install new devices. If the drivers are unavailable the device will not be recognized and will not work. Procedure 10.5. Adding a storage device using the virtio storage driver Open the guest virtual machine by double clicking on the name of the guest in virt-manager . Open the Show virtual hardware details tab by clicking the lightbulb button. Figure 10.27. The Show virtual hardware details tab In the Show virtual hardware details tab, click on the Add Hardware button. Select hardware type Select Storage as the Hardware type . Figure 10.28. The Add new virtual hardware wizard Select the storage device and driver Create a new disk image or select a storage pool volume. Set the Device type to Virtio disk to use the virtio drivers. Figure 10.29. The Add new virtual hardware wizard Click Finish to complete the procedure. Procedure 10.6. Adding a network device using the virtio network driver Open the guest virtual machine by double clicking on the name of the guest in virt-manager . Open the Show virtual hardware details tab by clicking the lightbulb button. Figure 10.30. The Show virtual hardware details tab In the Show virtual hardware details tab, click on the Add Hardware button. Select hardware type Select Network as the Hardware type . Figure 10.31. The Add new virtual hardware wizard Select the network device and driver Set the Device model to virtio to use the virtio drivers. Choose the desired Host device . Figure 10.32. The Add new virtual hardware wizard Click Finish to complete the procedure. Once all new devices are added, reboot the virtual machine. Windows virtual machines may not recognize the devices until the guest is rebooted.

Commands:
2.2.8.2. NFS and Sendmail Never put the mail spool directory, /var/spool/mail/ , on an NFS shared volume. Because NFSv2 and NFSv3 do not maintain control over user and group IDs, two or more users can have the same UID, and receive and read each other's mail. Note With NFSv4 using Kerberos, this is not the case, since the SECRPC_GSS kernel module does not utilize UID-based authentication. However, it is still considered good practice not to put the mail spool directory on NFS shared volumes.

Commands:
31.5. Hot Rod Cross Site Cluster Failover Besides in-cluster failover, Hot Rod clients can failover to different clusters each representing independent sites. Hot Rod Cross Site cluster failover is available in both automatic and manual modes. Automatic Cross Site Cluster Failover If the main/primary cluster nodes are unavailable, the client application checks for alternatively defined clusters and will attempt to failover to them. Upon successful failover, the client will remain connected to the alternative cluster until it becomes unavailable. After that, the client will try to failover to other defined clusters and finally switch over to the main/primary cluster with the original server settings if the connectivity is restored. To configure an alternative cluster in the Hot Rod client, provide details of at least one host/port pair for each of the clusters configured as shown in the following example. Example 31.5. Configure Alternate Cluster Note Regardless of the cluster definitions, the initial server(s) configuration must be provided unless the initial servers can be resolved using the default server host and port details. Manual Cross Site Cluster Failover For manual site cluster switchover, call RemoteCacheManager's switchToCluster(clusterName) or switchToDefaultCluster() . Using switchToCluster(clusterName) , users can force a client to switch to one of the clusters pre-defined in the Hot Rod client configuration. To switch to the initial servers defined in the client configuration, call switchToDefaultCluster() . Report a bug

Commands:
org.infinispan.client.hotrod.configuration.ConfigurationBuilder cb = new org.infinispan.client.hotrod.configuration.ConfigurationBuilder(); cb.addCluster("remote-cluster").addClusterNode("remote-cluster-host", 11222); RemoteCacheManager rcm = new RemoteCacheManager(cb.build());
Chapter 1. Introduction Red Hat Virtualization Manager provides a Representational State Transfer (REST) API. The API provides software developers and system administrators with control over their Red Hat Virtualization environment outside of the standard web interface. The REST API is useful for developers and administrators who aim to integrate the functionality of a Red Hat Virtualization environment with custom scripts or external applications that access the API via the standard Hypertext Transfer Protocol (HTTP). The benefits of the REST API are: Broad client support - Any programming language, framework, or system with support for HTTP protocol can use the API; Self descriptive - Client applications require minimal knowledge of the virtualization infrastructure as many details are discovered at runtime; Resource-based model - The resource-based REST model provides a natural way to manage a virtualization platform. This provides developers and administrators with the ability to: Integrate with enterprise IT systems. Integrate with third-party virtualization software. Perform automated maintenance or error checking tasks. Automate repetitive tasks in a Red Hat Virtualization environment with scripts. This documentation acts as a reference to the Red Hat Virtualization Manager REST API. It aims to provide developers and administrators with instructions and examples to help harness the functionality of their Red Hat Virtualization environment through the REST API either directly or using the provided Python libraries. 1.1. Representational State Transfer Representational State Transfer (REST) is a design architecture that focuses on resources for a specific service and their representations. A resource representation is a key abstraction of information that corresponds to one specific managed element on a server. A client sends a request to a server element located at a Uniform Resource Identifier (URI) and performs operations with standard HTTP methods, such as GET , POST , PUT , and DELETE . This provides a stateless communication between the client and server where each request acts independent of any other request and contains all necessary information to complete the request.

Commands:
5.3. Securing NIS NIS stands for Network Information Service . It is an RPC service, called ypserv , which is used in conjunction with portmap and other related services to distribute maps of usernames, passwords, and other sensitive information to any computer claiming to be within its domain. An NIS server is comprised of several applications. They include the following: /usr/sbin/rpc.yppasswdd - Also called the yppasswdd service, this daemon allows users to change their NIS passwords. /usr/sbin/rpc.ypxfrd - Also called the ypxfrd service, this daemon is responsible for NIS map transfers over the network. /usr/sbin/yppush - This application propagates changed NIS databases to multiple NIS servers. /usr/sbin/ypserv - This is the NIS server daemon. NIS is rather insecure by todays standards. It has no host authentication mechanisms and passes all of its information over the network unencrypted, including password hashes. As a result, extreme care must be taken to set up a network that uses NIS. Further complicating the situation, the default configuration of NIS is inherently insecure. It is recommended that anyone planning to implement an NIS server first secure the portmap service as outlined in Section 5.2, "Securing Portmap" , then address the following issues, such as network planning. 5.3.1. Carefully Plan the Network Because NIS passes sensitive information unencrypted over the network, it is important the service be run behind a firewall and on a segmented and secure network. Any time NIS information is passed over an insecure network, it risks being intercepted. Careful network design in these regards can help prevent severe security breaches.

Commands:
Chapter 13. File-based configuration AMQ Python can read the configuration options used to establish connections from a local file named connect.json . This enables you to configure connections in your application at the time of deployment. The library attempts to read the file when the application calls the container connect method without supplying any connection options. 13.1. File locations If set, AMQ Python uses the value of the MESSAGING_CONNECT_FILE environment variable to locate the configuration file. If MESSAGING_CONNECT_FILE is not set, AMQ Python searches for a file named connect.json at the following locations and in the order shown. It stops at the first match it encounters. On Linux: USDPWD/connect.json , where USDPWD is the current working directory of the client process USDHOME/.config/messaging/connect.json , where USDHOME is the current user home directory /etc/messaging/connect.json On Windows: %cd%/connect.json , where %cd% is the current working directory of the client process If no connect.json file is found, the library uses default values for all options. 13.2. The file format The connect.json file contains JSON data, with additional support for JavaScript comments. All of the configuration attributes are optional or have default values, so a simple example need only provide a few details: Example: A simple connect.json file { "host": "example.com", "user": "alice", "password": "secret" } SASL and SSL/TLS options are nested under "sasl" and "tls" namespaces: Example: A connect.json file with SASL and SSL/TLS options { "host": "example.com", "user": "ortega", "password": "secret", "sasl": { "mechanisms": ["SCRAM-SHA-1", "SCRAM-SHA-256"] }, "tls": { "cert": "/home/ortega/cert.pem", "key": "/home/ortega/key.pem" } } 13.3. Configuration options The option keys containing a dot (.) represent attributes nested inside a namespace. Table 13.1. Configuration options in connect.json Key Value type Default value Description scheme string "amqps" "amqp" for cleartext or "amqps" for SSL/TLS host string "localhost" The hostname or IP address of the remote host port string or number "amqps" A port number or port literal user string None The user name for authentication password string None The password for authentication sasl.mechanisms list or string None (system defaults) A JSON list of enabled SASL mechanisms. A bare string represents one mechanism. If none are specified, the client uses the default mechanisms provided by the system. sasl.allow_insecure boolean false Enable mechanisms that send cleartext passwords tls.cert string None The filename or database ID of the client certificate tls.key string None The filename or database ID of the private key for the client certificate tls.ca string None The filename, directory, or database ID of the CA certificate tls.verify boolean true Require a valid server certificate with a matching hostname

Commands:
host: example.com
user: alice
password: secret
{ "host": "example.com", "user": "ortega", "password": "secret", "sasl": { "mechanisms": ["SCRAM-SHA-1", "SCRAM-SHA-256"] }, "tls": { "cert": "/home/ortega/cert.pem", "key": "/home/ortega/key.pem" } }
Chapter 1. Overview This book covers the updates from the following CDN channels: Atomic Host - delivers the cumulative, image-based updates for the Atomic Host - the OSTree, as well as updates to the individual RPMs that contain tooling used to build and manage ostrees, and to the OSTree components which enable the use of container applications, for example cockpit-ostree and openscap . However, such RPMs cannot be downloaded and used on Red Hat Enterprise Linux. Extras-7 - delivers updates on container-related RPMs, most of which as also available as part of the OSTree for RHEL Atomic Host. The packages marked with an asterisk (*) are only available for Red Hat Enterprise Linux, and are not part of the Atomic Host OSTree. This channel also delivers updates on the official Container Images based on Red Hat Enterprise Linux. For detailed information on the Red Hat Enterprise Linux Atomic Host cycle, see https://access.redhat.com/support/policy/updates/extras/ . All official Red Hat container images are available from Red Hat Registry . To update you RHEL Atomic Host to the latest OSTree, run the atomic host upgrade command. 1.1. Red Hat Enterprise Linux Atomic Host Red Hat Enterprise Linux Atomic Host is a secure, lightweight, and minimal-footprint operating system optimized to run Linux containers. It is pre-installed with the following tools to support Linux containers: docker - an open source engine that automates the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere atomic - defines the entrypoint for Atomic hosts etcd - provides a highly-available key value store for shared configuration flannel - contains an etcd-driven address management agent, which manages IP addresses of overlay networks between systems running containers that need to communicate with one another Red Hat Enterprise Linux Atomic Host makes use of the following technologies: OSTree and rpm-OSTree - These projects provide atomic upgrades and rollback capability systemd - a new init system for Linux that enables faster boot times and easier orchestration SELinux - enabled by default to provide complete multi-tenant security Also, Cockpit is available on Red Hat Enterprise Linux as a separate Extras package and on Red Hat Enterprise Linux Atomic Host, as the cockpit-ws Container Image. Cockpit is a server administration interface that makes it easy to administer Red Hat Enterprise Linux servers through a web browser.

Commands:
Chapter 7. Block I/O This chapter covers optimizing I/O settings in virtualized environments. 7.1. Block I/O Tuning The virsh blkiotune command allows administrators to set or display a guest virtual machine's block I/O parameters manually in the <blkio> element in the guest XML configuration. To display current <blkio> parameters for a virtual machine: To set a virtual machine's <blkio> parameters, use the virsh blkiotune command and replace option values according to your environment: Parameters include: weight The I/O weight, within the range 100 to 1000. Increasing the I/O weight of a device increases its priority for I/O bandwidth, and therefore provides it with more host resources. Similarly, reducing a device's weight makes it consume less host resources. device-weights A single string listing one or more device/weight pairs, in the format of /path/to/device ,weight, /path/to/device ,weight . Each weight must be within the range 100-1000, or the value 0 to remove that device from per-device listings. Only the devices listed in the string are modified; any existing per-device weights for other devices remain unchanged. config Add the --config option for changes to take effect at boot. live Add the --live option to apply the changes to the running virtual machine. Note The --live option requires the hypervisor to support this action. Not all hypervisors allow live changes of the maximum memory limit. current Add the --current option to apply the changes to the current virtual machine. For example, the following changes the weight of the /dev/sda device in the liftbrul VM to 500. Note Use the virsh help blkiotune command for more information on using the virsh blkiotune command.

Commands:
virsh blkiotune virtual_machine
virsh blkiotune virtual_machine [--weight number ] [--device-weights string ] [--config] [--live] [--current]
virsh blkiotune liftbrul --device-weights /dev/sda, 500
18.6. Configuring RAID Sets Most RAID sets are configured during creation, typically through the firmware menu or from the installer. In some cases, you may need to create or modify RAID sets after installing the system, preferably without having to reboot the machine and enter the firmware menu to do so. Some hardware RAID controllers allow you to configure RAID sets on-the-fly or even define completely new sets after adding extra disks. This requires the use of driver-specific utilities, as there is no standard API for this. For more information, see your hardware RAID controller's driver documentation for information on this. mdadm The mdadm command-line tool is used to manage software RAID in Linux, i.e. mdraid . For information on the different mdadm modes and options, see man mdadm . The man page also contains useful examples for common operations like creating, monitoring, and assembling software RAID arrays. dmraid As the name suggests, dmraid is used to manage device-mapper RAID sets. The dmraid tool finds ATARAID devices using multiple metadata format handlers, each supporting various formats. For a complete list of supported formats, run dmraid -l . As mentioned earlier in Section 18.3, "Linux RAID Subsystems" , the dmraid tool cannot configure RAID sets after creation. For more information about using dmraid , see man dmraid .

Commands:
Chapter 4. Certification testing The certification testing briefs about the prerequisites for testing, understanding the certification process, and its requirements. 4.1. Prerequistes for certification testing Assisted installer component certification The corresponding RHEL server certification is successfully completed and posted. The corresponding Red Hat OpenShift Container Platform certification is successfully completed and posted. IPI component certification The corresponding RHEL server certification is successfully completed and posted. The corresponding Red Hat OpenShift Container Platform certification is successfully completed and posted. The corresponding bare metal driver is on the Supported Drivers List for the corresponding Red Hat OpenShift Container Platform release. 4.2. Certification workflow The Red Hat Bare Metal Hardware certification process includes the following requirements and steps: Figure 4.1. Red Hat OpenShift Container Platform Bare Metal Hardware Certification Process 4.3. Certification requirements Ensure you follow the respective Red Hat OpenShift Container Platform bare metal hardware Workflow Guide . Additional details for the certification requirements include: The Host Under Test (HUT) must already be RHEL certified. Additionally, the tests must run on a previously certified server, and all the tests prescribed in the test plan must be executed in a single run. If you have a failed test, take the corrective action and execute all the tests in a single run . Open a support case if necessary for guidance.

Commands:
Chapter 9. Known issues This section lists the known issues for Streams for Apache Kafka 2.9 on RHEL. 9.1. JMX authentication when running in FIPS mode When running Streams for Apache Kafka in FIPS mode with JMX authentication enabled, clients may fail authentication. To work around this issue, do not enable JMX authentication while running in FIPS mode. We are investigating the issue and working to resolve it in a future release.

Commands:
Appendix A. Using your subscription Streams for Apache Kafka is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Streams for Apache Kafka for Apache Kafka entries in the INTEGRATION AND AUTOMATION category. Select the desired Streams for Apache Kafka product. The Software Downloads page opens. Click the Download link for your component. Installing packages with DNF To install a package and all the package dependencies, use: dnf install <package_name> To install a previously-downloaded package from a local directory, use: dnf install <path_to_download_package> Revised on 2025-03-19 12:54:27 UTC

Commands:
dnf install <package_name>
dnf install <path_to_download_package>
Chapter 1. Overview of load balancing in Satellite You can configure your Satellite environment to use a load balancer to distribute host requests and network load across multiple Capsule Servers. This results in an improved performance on Capsule Servers and improved performance and stability for host connections to Satellite. In a load-balanced setup, Capsule functionality supported for load balancing continues to work as expected when one Capsule Server is down for planned or unplanned maintenance. 1.1. Components of a load-balanced setup A load-balanced setup in a Satellite environment consists of the following components: Satellite Server Two or more Capsule Servers A load balancer Multiple hosts A host sends a request to the TCP load balancer. The load balancer receives the request and determines which Capsule Server will handle the request to ensure optimal performance and availability. Figure 1.1. Components of a load-balanced setup 1.2. Services and features supported in a load-balanced setup A load balancer in Satellite distributes load only for the following services and features: Registering hosts Providing content to hosts Configuring hosts by using Puppet Other Satellite services, such as provisioning, virt-who , or remote execution, go directly through the individual Capsules on which these services are running. 1.3. Additional maintenance required for load balancing Configuring Capsules to use a load balancer results in a more complex environment and requires additional maintenance. The following additional steps are required for load balancing: You must ensure that all Capsules have the same content. If you publish a content view version on Satellite, synchronize it to all Capsule Servers. You must upgrade each Capsule in sequence.

Commands: