mtpti5iD/redhat-docs_dataset huggingface dataset:
15.2. Migration Requirements and Limitations Before using KVM migration, make sure that your system fulfills the migration's requirements, and that you are aware of its limitations. Migration requirements A guest virtual machine installed on shared storage using one of the following protocols: Fibre Channel-based LUNs iSCSI NFS GFS2 SCSI RDMA protocols (SCSI RCP): the block export protocol used in Infiniband and 10GbE iWARP adapters Make sure that the libvirtd service is enabled and running. The ability to migrate effectively is dependant on the parameter setting in the /etc/libvirt/libvirtd.conf file. To edit this file, use the following procedure: Procedure 15.1. Configuring libvirtd.conf Opening the libvirtd.conf requires running the command as root: Change the parameters as needed and save the file. Restart the libvirtd service: The migration platforms and versions should be checked against Table 15.1, "Live Migration Compatibility" Use a separate system exporting the shared storage medium. Storage should not reside on either of the two host physical machines used for the migration. Shared storage must mount at the same location on source and destination systems. The mounted directory names must be identical. Although it is possible to keep the images using different paths, it is not recommended. Note that, if you intend to use virt-manager to perform the migration, the path names must be identical. If you intend to use virsh to perform the migration, different network configurations and mount directories can be used with the help of --xml option or pre-hooks . For more information on pre-hooks, see the libvirt upstream documentation , and for more information on the XML option, see Chapter 23, Manipulating the Domain XML . When migration is attempted on an existing guest virtual machine in a public bridge+tap network, the source and destination host machines must be located on the same network. Otherwise, the guest virtual machine network will not operate after migration. Migration Limitations Guest virtual machine migration has the following limitations when used on Red Hat Enterprise Linux with virtualization technology based on KVM: Point to point migration - must be done manually to designate destination hypervisor from originating hypervisor No validation or roll-back is available Determination of target may only be done manually Storage migration cannot be performed live on Red Hat Enterprise Linux 7 , but you can migrate storage while the guest virtual machine is powered down. Live storage migration is available on Red Hat Virtualization . Call your service representative for details. Note If you are migrating a guest machine that has virtio devices on it, make sure to set the number of vectors on any virtio device on either platform to 32 or fewer. For detailed information, see Section 23.17, "Devices" .

Commands:
systemctl enable libvirtd.service systemctl restart libvirtd.service
vim /etc/libvirt/libvirtd.conf
systemctl restart libvirtd
24.6.2. Running the Net-SNMP Daemon The net-snmp package contains snmpd , the SNMP Agent Daemon. This section provides information on how to start, stop, and restart the snmpd service, and shows how to enable it in a particular runlevel. For more information on the concept of runlevels and how to manage system services in Red Hat Enterprise Linux in general, see Chapter 12, Services and Daemons . 24.6.2.1. Starting the Service To run the snmpd service in the current session, type the following at a shell prompt as root : service snmpd start To configure the service to be automatically started at boot time, use the following command: chkconfig snmpd on This will enable the service in runlevel 2, 3, 4, and 5. Alternatively, you can use the Service Configuration utility as described in Section 12.2.1.1, "Enabling and Disabling a Service" . 24.6.2.2. Stopping the Service To stop the running snmpd service, type the following at a shell prompt as root : service snmpd stop To disable starting the service at boot time, use the following command: chkconfig snmpd off This will disable the service in all runlevels. Alternatively, you can use the Service Configuration utility as described in Section 12.2.1.1, "Enabling and Disabling a Service" . 24.6.2.3. Restarting the Service To restart the running snmpd service, type the following at a shell prompt: service snmpd restart This will stop the service and start it again in quick succession. To only reload the configuration without stopping the service, run the following command instead: service snmpd reload This will cause the running snmpd service to reload the configuration. Alternatively, you can use the Service Configuration utility as described in Section 12.2.1.2, "Starting, Restarting, and Stopping a Service" .

Commands:
Storage Administration Guide Red Hat Enterprise Linux 7 Deploying and configuring single-node storage in RHEL 7 Edited by Marek Suchanek Red Hat Customer Content Services msuchane@redhat.com Edited by Apurva Bhide Red Hat Customer Content Services abhide@redhat.com Milan Navratil Red Hat Customer Content Services Jacquelynn East Red Hat Customer Content Services Don Domingo Red Hat Customer Content Services

Commands:
18.8. Managing a Virtual Network To configure a virtual network on your system: From the Edit menu, select Connection Details . Figure 18.10. Selecting a host physical machine's details This will open the Connection Details menu. Click the Virtual Networks tab. Figure 18.11. Virtual network configuration All available virtual networks are listed on the left-hand box of the menu. You can edit the configuration of a virtual network by selecting it from this box and editing as you see fit.

Commands:
Chapter 16. Set Up Isolation Levels 16.1. About Isolation Levels Isolation levels determine when readers can view a concurrent write. READ_COMMITTED and REPEATABLE_READ are the two isolation modes offered in Red Hat JBoss Data Grid. READ_COMMITTED . This isolation level is applicable to a wide variety of requirements. This is the default value in Remote Client-Server and Library modes. REPEATABLE_READ . Important The only valid value for locks in Remote Client-Server mode is the default READ_COMMITTED value. The value explicitly specified with the isolation value is ignored. If the locking element is not present in the configuration, the default isolation value is READ_COMMITTED . For isolation mode configuration examples in JBoss Data Grid, see the lock striping configuration samples: See Section 15.2, "Configure Lock Striping (Remote Client-Server Mode)" for a Remote Client-Server mode configuration sample. See Section 15.3, "Configure Lock Striping (Library Mode)" for a Library mode configuration sample. Report a bug

Commands:
Chapter 22. Manually configuring the /etc/resolv.conf file By default, NetworkManager dynamically updates the /etc/resolv.conf file with the DNS settings from active NetworkManager connection profiles. However, you can disable this behavior and manually configure DNS settings in /etc/resolv.conf . Note Alternatively, if you require a specific order of DNS servers in /etc/resolv.conf , see Configuring the order of DNS servers . 22.1. Disabling DNS processing in the NetworkManager configuration By default, NetworkManager manages DNS settings in the /etc/resolv.conf file, and you can configure the order of DNS servers. Alternatively, you can disable DNS processing in NetworkManager if you prefer to manually configure DNS settings in /etc/resolv.conf . Procedure As the root user, create the /etc/NetworkManager/conf.d/90-dns-none.conf file with the following content by using a text editor: Reload the NetworkManager service: Note After you reload the service, NetworkManager no longer updates the /etc/resolv.conf file. However, the last contents of the file are preserved. Optional: Remove the Generated by NetworkManager comment from /etc/resolv.conf to avoid confusion. Verification Edit the /etc/resolv.conf file and manually update the configuration. Reload the NetworkManager service: Display the /etc/resolv.conf file: If you successfully disabled DNS processing, NetworkManager did not override the manually configured settings. Troubleshooting Display the NetworkManager configuration to ensure that no other configuration file with a higher priority overrode the setting: Additional resources NetworkManager.conf(5) man page on your system Configuring the order of DNS servers using NetworkManager 22.2. Replacing /etc/resolv.conf with a symbolic link to manually configure DNS settings By default, NetworkManager manages DNS settings in the /etc/resolv.conf file, and you can configure the order of DNS servers. Alternatively, you can disable DNS processing in NetworkManager if you prefer to manually configure DNS settings in /etc/resolv.conf . For example, NetworkManager does not automatically update the DNS configuration if /etc/resolv.conf is a symbolic link. Prerequisites The NetworkManager rc-manager configuration option is not set to file . To verify, use the NetworkManager --print-config command. Procedure Create a file, such as /etc/resolv.conf.manually-configured , and add the DNS configuration for your environment to it. Use the same parameters and syntax as in the original /etc/resolv.conf . Remove the /etc/resolv.conf file: Create a symbolic link named /etc/resolv.conf that refers to /etc/resolv.conf.manually-configured : Additional resources resolv.conf(5) and NetworkManager.conf(5) man pages on your system Configuring the order of DNS servers using NetworkManager

Commands:
[main] dns=none
systemctl reload NetworkManager
systemctl reload NetworkManager
cat /etc/resolv.conf
NetworkManager --print-config dns=none
rm /etc/resolv.conf
ln -s /etc/resolv.conf.manually-configured /etc/resolv.conf
Chapter 1. Overview .NET images are added to OpenShift by importing image stream definitions from s2i-dotnetcore . The image stream definitions include the dotnet image stream which contains sdk images for different supported versions of .NET. Life Cycle and Support Policies for the .NET Program provides an up-to-date overview of supported versions. Version Tag Alias .NET 8.0 dotnet:8.0-ubi8 dotnet:8.0 .NET 9.0 dotnet:9.0-ubi8 dotnet:9.0 The sdk images have corresponding runtime images which are defined under the dotnet-runtime image stream. The container images work across different versions of Red Hat Enterprise Linux and OpenShift. The UBI-8 based images (suffix -ubi8) are hosted on the registry.access.redhat.com and do not require authentication.

Commands:
8.204. rsh 8.204.1. RHBA-2014:0795 - rsh bug fix update Updated rsh packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The rsh packages contain programs which allow users to run commands on remote machines, log in to other machines, copy files between machines (rsh, rlogin and rcp), and provide an alternate method of executing remote commands (rexec). All of these programs are run by the xinetd daemon and can be configured using the Pluggable Authentication Modules (PAM) system and configuration files in the /etc/xinetd.d/ directory. Bug Fixes BZ# 749283 Previously, the rshd daemon performed redundant calls of the setpwent() and endpwent() functions. As a consequence, rshd queried Network Information Security (NIS) servers on every remote shell (rsh) access. With this update, these redundant calls have been removed and rshd no longer contacts NIS servers unnecessarily. BZ# 802367 Prior to this update, the maximum number of command line arguments for the rsh application was not limited. However, the volume of data buffer allocated to the arguments is always finite. Consequently, rshd terminated unexpectedly when it attempted to allocate the buffer to commands with a vast number of arguments. This update implements a limit for command-line arguments in rsh, and the described rshd crash no longer occurs. BZ# 1098955 Previously, the pam_close_session() function was not called when a remote copy (rcp) connection completed. As a consequence, the PAM session did not terminate correctly. With this update, pam_close_session() is called and the PAM session terminates as intended. BZ# 1094360 Prior to this update, the rsh application was optimized through strict aliasing rules, even though it is not a performance-sensitive application. As a consequence, the GNU compiler collection (GCC) generated warning messages about breaking the strict-aliasing rules, despite correct functionality being the priority for rsh. With this update, strict aliasing has been disabled for rsh. Therefore, GCC now ignores the strict aliasing rules and no longer interrupts rsh processes with warning messages. However, this may also lead to a slight decrease in performance. Users of rsh are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 2. Installation This chapter guides you through the steps to install AMQ Spring Boot Starter in your environment. 2.1. Prerequisites You must have a subscription to access AMQ release files and repositories. To build programs with AMQ Spring Boot Starter, you must install Apache Maven . To use AMQ Spring Boot Starter, you must install Java. 2.2. Using the Red Hat Maven repository Configure your Maven environment to download the client library from the Red Hat Maven repository. Procedure Add the Red Hat repository to your Maven settings or POM file. For example configuration files, see Section B.1, "Using the online repository" . <repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository> Add the library dependency to your POM file. <dependency> <groupId>org.amqphub.spring</groupId> <artifactId>amqp-10-jms-spring-boot-starter</artifactId> <version>2.5.0.redhat-00001</version> </dependency> The client is now available in your Maven project. 2.3. Installing a local Maven repository As an alternative to the online repository, AMQ Spring Boot Starter can be installed to your local filesystem as a file-based Maven repository. Procedure Use your subscription to download the AMQ Clients 2.10.0 Spring Boot Starter Maven repository .zip file. Extract the file contents into a directory of your choosing. On Linux or UNIX, use the unzip command to extract the file contents. USD unzip amq-clients-2.10.0-spring-boot-starter-maven-repository.zip On Windows, right-click the .zip file and select Extract All . Configure Maven to use the repository in the maven-repository directory inside the extracted install directory. For more information, see Section B.2, "Using a local repository" .

Commands:
<repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository>
<dependency> <groupId>org.amqphub.spring</groupId> <artifactId>amqp-10-jms-spring-boot-starter</artifactId> <version>2.5.0.redhat-00001</version> </dependency>
unzip amq-clients-2.10.0-spring-boot-starter-maven-repository.zip
Appendix B. Revision History Note that revision numbers relate to the edition of this manual, not to version numbers of Red Hat Enterprise Linux. Revision History Revision 7.0-31 Wed Nov 11 2020 Florian Delehaye Updated with minor fixes for 7.9 GA publication. Revision 7.0-30 Tue Aug 06 2019 Marc Muehlfeld Document version for 7.7 GA publication. Revision 7.0-29 Tue Apr 08 2019 Marc Muehlfeld Added Configuring the Files Provider for SSSD and Displaying User Data . Minor fixes and updates. Revision 7.0-28 Fri Oct 26 2018 Filip Hanzelka Preparing document for 7.6 GA publication. Revision 7.0-27 Mon Jun 25 2018 Filip Hanzelka Updated Working with certmonger . Revision 7.0-26 Tue Apr 10 2018 Filip Hanzelka Preparing document for 7.5 GA publication. Revision 7.0-25 Mon Mar 19 2018 Lucie Manaskova Minor updates. Revision 7.0-24 Mon Feb 12 2018 Aneta Steflova Petrova Minor fixes and updates. Revision 7.0-23 Mon Jan 29 2018 Aneta Steflova Petrova Minor fixes. Revision 7.0-22 Mon Dec 4 2017 Aneta Steflova Petrova Updated Smart cards . Revision 7.0-21 Mon Nov 20 2017 Aneta Steflova Petrova Minor fixes. Revision 7.0-20 Mon Nov 6 2017 Aneta Steflova Petrova Minor fixes. Revision 7.0-19 Mon Aug 14 2017 Aneta Steflova Petrova Updated sections that referred to the coolkey package. Revision 7.0-18 Tue Jul 18 2017 Aneta Steflova Petrova Document version for 7.4 GA publication. Revision 7.0-17 Mon Mar 27 2017 Aneta Steflova Petrova Fixed broken links. Revision 7.0-16 Mon Feb 27 2017 Aneta Steflova Petrova Updated Kerberos KDC proxy. Other minor updates. Revision 7.0-15 Wed Dec 7 2016 Aneta Steflova Petrova Added SSSD client-side views. Other minor updates. Revision 7.0-14 Tue Oct 18 2016 Aneta Steflova Petrova Version for 7.3 GA publication. Revision 7.0-13 Wed Jul 27 2016 Marc Muehlfeld Added Kerberos over HTTP (kdcproxy), requesting a certificate through SCEP, other minor updates. Revision 7.0-11 Thu Mar 03 2016 Aneta Petrova Added restricting domains for PAM services. Revision 7.0-10 Tue Feb 09 2016 Aneta Petrova Split authconfig chapter into smaller chapters, other minor updates. Revision 7.0-9 Thu Nov 12 2015 Aneta Petrova Version for 7.2 GA release. Revision 7.0-8 Fri Mar 13 2015 Tomas Capek Async update with last-minute edits for 7.1. Revision 7.0-6 Wed Feb 25 2015 Tomas Capek Version for 7.1 GA release. Revision 7.0-4 Fri Dec 05 2014 Tomas Capek Rebuild to update the sort order on the splash page. Revision 7.0-1 July 16, 2014 Ella Deon Ballard Initial draft for RHEL 7.0.

Commands:
Chapter 5. Cluster overview page The Cluster overview page shows the status of a Kafka cluster. Here, you can assess the readiness of Kafka brokers, identify any cluster errors or warnings, and gain crucial insights into the cluster's health. At a glance, the page provides information on the number of topics and partitions within the cluster, along with their replication status. Explore cluster metrics through charts displaying used disk space, CPU utilization, and memory usage. Additionally, topic metrics offer a comprehensive view of total incoming and outgoing byte rates for all topics in the Kafka cluster. 5.1. Accessing cluster connection details for client access When connecting a client to a Kafka cluster, retrieve the necessary connection details from the Cluster overview page by following these steps. Procedure From the Streams for Apache Kafka Console, click the name of the Kafka cluster that you want to connect to, then click Cluster overview and Cluster connection details . Copy and add bootstrap address and connection properties to your Kafka client configuration to establish a connection with the Kafka cluster. Note Ensure that the authentication type used by the client matches the authentication type configured for the Kafka cluster.

Commands:
Chapter 1. Introduction 1.1. Virtualized and Non-Virtualized Environments A virtualized environment presents opportunities for both the discovery of new attack vectors and the refinement of existing exploits that may not previously have presented value to an attacker. Therefore, it is important to take steps to ensure the security of both the physical hosts and the guests running on them when creating and maintaining virtual machines. Non-Virtualized Environment In a non-virtualized environment, hosts are separated from each other physically and each host has a self-contained environment, which consists of services such as a web server, or a DNS server. These services communicate directly to their own user space, host kernel and physical host, offering their services directly to the network. Figure 1.1. Non-Virtualized Environment Virtualized Environment In a virtualized environment, several operating systems can be housed (as guest virtual machines) within a single host kernel and physical host. Figure 1.2. Virtualized Environment When services are not virtualized, machines are physically separated. Any exploit is, therefore, usually contained to the affected machine, with the exception of network attacks. When services are grouped together in a virtualized environment, extra vulnerabilities emerge in the system. If a security flaw exists in the hypervisor that can be exploited by a guest instance, this guest may be able to attack the host, as well as other guests running on that host.

Commands:
4.3. Configuring Redundant Ring Protocol (RRP) Note Red Hat supports the configuration of Redundant Ring Protocol (RRP) in clusters subject to the conditions described in the "Redundant Ring Protocol (RRP)" section of Support Policies for RHEL High Availability Clusters - Cluster Interconnect Network Interfaces . When you create a cluster with the pcs cluster setup command, you can configure a cluster with Redundant Ring Protocol by specifying both interfaces for each node. When using the default udpu transport, when you specify the cluster nodes you specify the ring 0 address followed by a ',', then the ring 1 address. For example, the following command configures a cluster named my_rrp_clusterM with two nodes, node A and node B. Node A has two interfaces, nodeA-0 and nodeA-1 . Node B has two interfaces, nodeB-0 and nodeB-1 . To configure these nodes as a cluster using RRP, execute the following command. For information on configuring RRP in a cluster that uses udp transport, see the help screen for the pcs cluster setup command.

Commands:
pcs cluster setup --name my_rrp_cluster nodeA-0,nodeA-1 nodeB-0,nodeB-1
Chapter 3. Upgrading from a Streams version before 1.7 The v1beta2 API version for all custom resources was introduced with Streams for Apache Kafka 1.7. For Streams for Apache Kafka 1.8, v1alpha1 and v1beta1 API versions were removed from all Streams for Apache Kafka custom resources apart from KafkaTopic and KafkaUser . Upgrade of the custom resources to v1beta2 prepares Streams for Apache Kafka for a move to Kubernetes CRD v1 , which is required for Kubernetes 1.22. If you are upgrading from a Streams for Apache Kafka version prior to version 1.7: Upgrade to Streams for Apache Kafka 1.7 Convert the custom resources to v1beta2 Upgrade to Streams for Apache Kafka 1.8 Important You must upgrade your custom resources to use API version v1beta2 before upgrading to Streams for Apache Kafka version 2.9. 3.1. Upgrading custom resources to v1beta2 To support the upgrade of custom resources to v1beta2 , Streams for Apache Kafka provides an API conversion tool , which you can download from the Streams for Apache Kafka 1.8 software downloads page . You perform the custom resources upgrades in two steps. Step one: Convert the format of custom resources Using the API conversion tool, you can convert the format of your custom resources into a format applicable to v1beta2 in one of two ways: Converting the YAML files that describe the configuration for Streams for Apache Kafka custom resources Converting Streams for Apache Kafka custom resources directly in the cluster Alternatively, you can manually convert each custom resource into a format applicable to v1beta2 . Instructions for manually converting custom resources are included in the documentation. Step two: Upgrade CRDs to v1beta2 , using the API conversion tool with the crd-upgrade command, you must set v1beta2 as the storage API version in your CRDs. You cannot perform this step manually. For more information, see Upgrading from a Streams for Apache Kafka version earlier than 1.7 .

Commands: