mtpti5iD/redhat-docs_dataset huggingface dataset:
8.11. Controlling teamd with teamdctl In order to query a running instance of teamd for statistics or configuration information, or to make changes, the control tool teamdctl is used. To view the current team state of a team team0 , enter the following command as root : For a more verbose output: For a complete state dump in JSON format (useful for machine processing) of team0 , use the following command: For a configuration dump in JSON format of team0 , use the following command: To view the configuration of a port em1 , that is part of a team team0 , enter the following command: 8.11.1. Add a Port to a Network Team To add a port em1 to a network team team0 , issue the following command as root : Important If using teamdctl directly to add a port, the port must be set to down . Otherwise the teamdctl team0 port add em1 command will fail. 8.11.2. Remove a Port From a Network Team To remove an interface em1 from a network team team0 , issue the following command as root : 8.11.3. Applying a Sticky Setting to a Port in a Network Team You can use the teamdctl command to apply a sticky setting to ensure that a specific port is used as an active link when it is available. Prerequisites You already created a team of network interfaces. As a result, you have a port ( em1 ) that you want to update the configuration of. Procedure To apply a JSON format configuration to a port em1 in a network team team0 , run the following commands: Update the configuration of the sticky setting for em1 : Remove em1 : Add em1 again so that the sticky setting takes effect: Note that the old configuration will be overwritten and that any options omitted will be reset to the default values. See the teamdctl(8) man page for more team daemon control tool command examples. 8.11.4. View the Configuration of a Port in a Network Team To copy the configuration of a port em1 in a network team team0 , issue the following command as root : This will dump the JSON format configuration of the port to standard output.

Commands:
~]# teamdctl team0 state view
~]# teamdctl team0 state view -v
~]# teamdctl team0 state dump
~]# teamdctl team0 config dump
~]# teamdctl team0 port config dump em1
~]# teamdctl team0 port add em1
~]# teamdctl team0 port remove em1
~]# teamdctl team0 port config update em1 '{ "prio": 100, "sticky": true }'
~]# teamdctl team0 port remove em1
~]# teamdctl team0 port add em1
~]# teamdctl team0 port config dump em1
18.5. Isolated Mode When using Isolated mode , guests connected to the virtual switch can communicate with each other, and with the host physical machine, but their traffic will not pass outside of the host physical machine, nor can they receive traffic from outside the host physical machine. Using dnsmasq in this mode is required for basic functionality such as DHCP. However, even if this network is isolated from any physical network, DNS names are still resolved. Therefore a situation can arise when DNS names resolve but ICMP echo request (ping) commands fail. Figure 18.6. Virtual network switch in isolated mode

Commands:
8.4.2. Backup Technologies Red Hat Enterprise Linux comes with several different programs for backing up and restoring data. By themselves, these utility programs do not constitute a complete backup solution. However, they can be used as the nucleus of such a solution. Note As noted in Section 8.2.6.1, "Restoring From Bare Metal" , most computers based on the standard PC architecture do not possess the necessary functionality to boot directly from a backup tape. Consequently, Red Hat Enterprise Linux is not capable of performing a tape boot when running on such hardware. However, it is also possible to use your Red Hat Enterprise Linux CD-ROM as a system recovery environment; for more information see the chapter on basic system recovery in the System Administrators Guide . 8.4.2.1. tar The tar utility is well known among UNIX system administrators. It is the archiving method of choice for sharing ad-hoc bits of source code and files between systems. The tar implementation included with Red Hat Enterprise Linux is GNU tar , one of the more feature-rich tar implementations. Using tar , backing up the contents of a directory can be as simple as issuing a command similar to the following: This command creates an archive file called home-backup.tar in /mnt/backup/ . The archive contains the contents of the /home/ directory. The resulting archive file will be nearly as large as the data being backed up. Depending on the type of data being backed up, compressing the archive file can result in significant size reductions. The archive file can be compressed by adding a single option to the command: The resulting home-backup.tar.gz archive file is now gzip compressed [30] . There are many other options to tar ; to learn more about them, read the tar(1) man page. [30] The .gz extension is traditionally used to signify that the file has been compressed with gzip . Sometimes .tar.gz is shortened to .tgz to keep file names reasonably sized.

Commands:
tar cf /mnt/backup/home-backup.tar /home/
tar czf /mnt/backup/home-backup.tar.gz /home/
30.3. Configure Server Hinting (Library Mode) In Red Hat JBoss Data Grid's Library mode, Server Hinting is configured at the transport level. The following is a Server Hinting sample configuration: Procedure 30.2. Configure Server Hinting for Library Mode The following configuration attributes are used to configure Server Hinting in JBoss Data Grid. The clusterName attribute specifies the name assigned to the cluster. The machineId attribute specifies the JVM instance that contains the original data. This is particularly useful for nodes with multiple JVMs and physical hosts with multiple virtual hosts. The rackId parameter specifies the rack that contains the original data, so that other racks are used for backups. The siteId parameter differentiates between nodes in different data centers replicating to each other. The listed parameters are optional in a JBoss Data Grid configuration. If machineId , rackId , or siteId are included in the configuration, TopologyAwareConsistentHashFactory is selected automatically, enabling Server Hinting. However, if Server Hinting is not configured, JBoss Data Grid's distribution algorithms are allowed to store replications in the same physical machine/rack/data center as the original data. Report a bug

Commands:
<transport clusterName = "MyCluster" machineId = "LinuxServer01" rackId = "Rack01" siteId = "US-WestCoast" />
Chapter 1. New and changed features 1.1. AMQ Python AMQ Python is now supported on Windows with Python 3.8, in addition to Python 3.6. 1.2. AMQ JMS If an AMQ JMS connection is lost, more detailed logging is now produced when the connection is restored. 1.3. AMQ Spring Boot Starter AMQ Spring Boot Starter now supports Spring Boot 2.3. 1.4. AMQ Resource Adapter AMQ Resource Adapter now includes an example using the WildFly application server, replacing the Thorntail example.

Commands:
7.12. Creating a Cloned Virtual Machine Based on a Template Cloned virtual machines are based on templates and inherit the settings of the template. A cloned virtual machine does not depend on the template on which it was based after it has been created. This means the template can be deleted if no other dependencies exist. Note If you clone a virtual machine from a template, the name of the template on which that virtual machine was based is displayed in the General tab of the Edit Virtual Machine window for that virtual machine. If you change the name of that template, the name of the template in the General tab will also be updated. However, if you delete the template from the Manager, the original name of that template will be displayed instead. Cloning a Virtual Machine Based on a Template Click Compute Virtual Machines . Click New . Select the Cluster on which the virtual machine will run. Select a template from the Based on Template drop-down menu. Enter a Name , Description and any Comments . You can accept the default values inherited from the template in the rest of the fields, or change them if required. Click the Resource Allocation tab. Select the Clone radio button in the Storage Allocation area. Select the disk format from the Format drop-down list. This affects the speed of the clone operation and the amount of disk space the new virtual machine initially requires. QCOW2 (Default) Faster clone operation Optimized use of storage capacity Disk space allocated only as required Raw Slower clone operation Optimized virtual machine read and write operations All disk space requested in the template is allocated at the time of the clone operation Use the Target drop-down menu to select the storage domain on which the virtual machine's virtual disk will be stored. Click OK . Note Cloning a virtual machine may take some time. A new copy of the template's disk must be created. During this time, the virtual machine's status is first Image Locked , then Down . The virtual machine is created and displayed in the Virtual Machines tab. You can now assign users to it, and can begin using it when the clone operation is complete.

Commands:
Chapter 5. Downloading deployment files To deploy Streams for Apache Kafka components using YAML files, download and extract the latest release archive ( streams-2.9-ocp-install-examples.zip ) from the Streams for Apache Kafka software downloads page . The release archive contains sample YAML files for deploying Streams for Apache Kafka components to OpenShift using oc . Begin by deploying the Cluster Operator from the install/cluster-operator directory to watch a single namespace, multiple namespaces, or all namespaces. In the install folder, you can also deploy other Streams for Apache Kafka components, including: Streams for Apache Kafka administrator roles ( strimzi-admin ) Standalone Topic Operator ( topic-operator ) Standalone User Operator ( user-operator ) Streams for Apache Kafka Drain Cleaner ( drain-cleaner ) The examples folder provides examples of Streams for Apache Kafka custom resources to help you develop your own Kafka configurations. Note Streams for Apache Kafka container images are available through the Red Hat Ecosystem Catalog , but we recommend using the provided YAML files for deployment. 5.1. Deploying the Streams for Apache Kafka Proxy Streams for Apache Kafka Proxy is an Apache Kafka protocol-aware proxy designed to enhance Kafka-based systems. Through its filter mechanism it allows additional behavior to be introduced into a Kafka-based system without requiring changes to either your applications or the Kafka cluster itself. For more information on connecting to and using the Streams for Apache Kafka Proxy, see the proxy guide in the Streams for Apache Kafka documentation . Important This feature is a technology preview and not intended for a production environment. For more information see the release notes . 5.2. Deploying the Streams for Apache Kafka Console After you have deployed a Kafka cluster that's managed by Streams for Apache Kafka, you can deploy and connect the Streams for Apache Kafka Console to the cluster. The console facilitates the administration of Kafka clusters, providing real-time insights for monitoring, managing, and optimizing each cluster from its user interface. For more information on connecting to and using the Streams for Apache Kafka Console, see the console guide in the Streams for Apache Kafka documentation .

Commands:
Chapter 6. Managing thin pools using the Web Console 6.1. Creating a thin pool using the Web Console Follow these instructions to create a logical thin pool using the Web Console. Log in to the Web Console. Click the hostname Storage . Click the volume group. The Volume Group Overview page opens. Click + Create new Logical Volume . The Create Logical Volume window opens. Specify a Name for your thin pool. Set Purpose to Pool for thinly provisioned volumes . Specify a Size for your thin pool. Click Create . Your new thin pool appears in the list of logical volumes in this volume group. 6.2. Growing a thin pool using the Web Console Follow these instructions to increase the size of a logical thin pool using the Web Console. Log in to the Web Console. Click the hostname Storage . Click the volume group. The Volume Group Overview page opens. Click the thin pool. On the Pool subtab, click Grow . The Grow Logical Volume window opens. Specify the new Size of the thin pool. Click Grow . 6.3. Deactivating a thin pool using the Web Console Follow these instructions to deactivate a logical thin pool using the Web Console. This deactivates all thinly provisioned logical volumes in the pool. Log in to the Web Console. Click the hostname Storage . Click the volume group. The Volume Group Overview page opens. Click the thin pool. Click Deactivate . The thin pool is deactivated. 6.4. Activating a thin pool using the Web Console Follow these instructions to activate a logical thin pool using the Web Console. Log in to the Web Console. Click the hostname Storage . Click the volume group. The Volume Group Overview page opens. Click the thin pool. Click Activate . The thin pool is activated. This does not activate thin provisioned logical volumes in the pool.

Commands:
8.4.2.3. dump/restore: Not Recommended for Mounted File Systems! The dump and restore programs are Linux equivalents to the UNIX programs of the same name. As such, many system administrators with UNIX experience may feel that dump and restore are viable candidates for a good backup program under Red Hat Enterprise Linux. However, one method of using dump can cause problems. Here is Linus Torvald's comment on the subject: Given this problem, the use of dump / restore on mounted file systems is strongly discouraged. However, dump was originally designed to backup unmounted file systems; therefore, in situations where it is possible to take a file system offline with umount , dump remains a viable backup technology.

Commands:
From: Linus Torvalds To: Neil Conway Subject: Re: [PATCH] SMP race in ext2 - metadata corruption. Date: Fri, 27 Apr 2001 09:59:46 -0700 (PDT) Cc: Kernel Mailing List <linux-kernel At vger Dot kernel Dot org> [ linux-kernel added back as a cc ] On Fri, 27 Apr 2001, Neil Conway wrote: > > I'm surprised that dump is deprecated (by you at least ;-)). What to > use instead for backups on machines that can't umount disks regularly? Note that dump simply won't work reliably at all even in 2.4.x: the buffer cache and the page cache (where all the actual data is) are not coherent. This is only going to get even worse in 2.5.x, when the directories are moved into the page cache as well. So anybody who depends on "dump" getting backups right is already playing Russian roulette with their backups. It's not at all guaranteed to get the right results - you may end up having stale data in the buffer cache that ends up being "backed up". Dump was a stupid program in the first place. Leave it behind. > I've always thought "tar" was a bit undesirable (updates atimes or > ctimes for example). Right now, the cpio/tar/xxx solutions are definitely the best ones, and will work on multiple filesystems (another limitation of "dump"). Whatever problems they have, they are still better than the _guaranteed_(*) data corruptions of "dump". However, it may be that in the long run it would be advantageous to have a "filesystem maintenance interface" for doing things like backups and defragmentation.. Linus (*) Dump may work fine for you a thousand times. But it _will_ fail under the right circumstances. And there is nothing you can do about it.
Chapter 12. Trusted Container test The Trusted Container test checks if Red Hat recognizes the Red Hat OpenStack Platform (RHOSP) plugin/driver container. The test also verifies whether the container is provided by Red Hat or you. The certified container image reduces the number of sources a customer must utilize for deployment, and it also ensures all the component included in solution stack are from a trusted source. Working of RHOSP certification testing During RHOSP certification testing, the Trusted Container Test captures information about the installed and running containers. After the information is captured, the test queries the Red Hat certification services to determine if the containers are recognized and certified. Requirements for Partners If your driver is shipped as part of RHOSP (In Tree) then they are expected to only run the Trusted Container Test because container image is already certified. However, if you ship their own container image (Out of Tree), as a prerequisite, the Partner must certify the container images with Red Hat Connect . For more information on container image certification, see Partner Integration guide . In Red Hat connect when a Partner creates a new product request for RHOSP 13, they can only select the Release Category as Tech-Preview. You can execute the Trusted Container Test after the container image is certified on Red Hat Connect . After the Trusted Container Test is completed successfully, the Partner can choose the General Availability(GA) option. Success criteria You have received a container report that shows running and non-running containers on the overcloud controller node. The report shows that the RHOSP services like cinder, manila, and neutron are installed and running. Based on an RHOSP certification testing, the running container can either be an RHOSP certified or Red Hat Certified container.

Commands:
4.2. Deploy JBoss Data Grid in JBoss EAP (Remote Client-Server Mode) Red Hat JBoss Data Grid provides a set of modules for Red Hat JBoss Enterprise Application Platform 6.x. Using these modules means that JBoss Data Grid libraries do not need to be included in the user deployment. To avoid conflicts with the Infinispan modules that are already included with JBoss EAP, the JBoss Data Grid modules are placed within a separate slot and identified by the JBoss Data Grid version ( major . minor ). Note The JBoss EAP modules are not included in JBoss EAP. Instead, navigate to the Customer Support Portal at http://access.redhat.com to download these modules from the Red Hat JBoss Data Grid downloads page. To deploy JBoss Data grid in JBoss EAP, add dependencies from the JBoss Data Grid module to the application's classpath (the JBoss EAP deployer) in one of the following ways: Add a dependency to the jboss-deployment-structure.xml file. Add a dependency to the MANIFEST.MF file. Add a Dependency to the jboss-deployment-structure.xml File Add the following configuration to the jboss-deployment-structure.xml file: Note For details about the jboss-deployment-structure.xml file, see the Red Hat JBoss Enterprise Application Platform documentation. Add a Dependency to the MANIFEST.MF File. Add a dependency to the MANIFEST.MF files as follows: Example 4.2. Example MANIFEST.MF File The first line remains the same as the example. Depending on the dependency required, add one of the following to the second line of the file: Basic Hot Rod client: Hot Rod client with Remote Query functionality: Report a bug 4.2.1. Using Custom Classes with the Hot Rod client Either of the following two methods may be used to use custom classes with the Hot Rod client: Option 1: Reference the deployment's class loader in the configuration builder for the Hot Rod client, as seen in the below example: Example 4.3. Referencing the custom class loader in the ConfigurationBuilder instance Option 2: Install the custom classes as their own module within JBoss EAP, and add a dependency on the newly created module should be added to the JBoss Data Grid module at USD{EAP_HOME}/modules/system/layers/base/org/infinispan/commons/jdg-6.x/module.xml . Report a bug

Commands:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <deployment> <dependencies> <module name="org.infinispan.commons" slot="jdg-6.6" services="export"/> <module name="org.infinispan.client.hotrod" slot="jdg-6.6" services="export"/> </dependencies> </deployment> </jboss-deployment-structure>
Manifest-Version: 1.0 Dependencies: org.infinispan.commons:jdg-6.6 services, org.infinispan.client.hotrod:jdg-6.6 services
org.infinispan.commons:jdg-6.6 services, org.infinispan.client.hotrod:jdg-6.6 services
org.infinispan.commons:jdg-6.6 services, org.infinispan.client.hotrod:jdg-6.6 services, org.infinispan.query.dsl:jdg-6.6 services, org.jboss.remoting3
import org.infinispan.client.hotrod.configuration.ConfigurationBuilder; [...] ConfigurationBuilder config = new ConfigurationBuilder(); config.marshaller(new GenericJBossMarshaller(Thread.currentThread().getContextClassLoader()));
Chapter 5. Editing Virtual Machines 5.1. Editing Virtual Machine Properties Changes to storage, operating system, or networking parameters can adversely affect the virtual machine. Ensure that you have the correct details before attempting to make any changes. Virtual machines can be edited while running, and some changes (listed in the procedure below) will be applied immediately. To apply all other changes, the virtual machine must be shut down and restarted. Note External virtual machines (marked with the prefix external ) cannot be edited through the Red Hat Virtualization Manager. Editing Virtual Machines Click Compute Virtual Machines . Select the virtual machine to be edited. Click Edit . Change settings as required. Changes to the following settings are applied immediately: Name Description Comment Optimized for (Desktop/Server/High Performance) Delete Protection Network Interfaces Memory Size (Edit this field to hot plug virtual memory. See Hot Plugging Virtual Memory .) Virtual Sockets (Edit this field to hot plug CPUs. See CPU hot plug .) Highly Available Priority for Run/Migration queue Disable strict user checking Icon Click OK . If the Start Configuration pop-up window appears, click OK . Some changes are applied immediately. All other changes are applied when you shut down and restart your virtual machine. Until then, the pending changes icon ( ) appears as a reminder to restart the virtual machine.

Commands:
Chapter 35. Configuring a Red Hat High Availability cluster with IBM z/VM instances as cluster members Red Hat provides several articles that may be useful when designing, configuring, and administering a Red Hat High Availability cluster running on z/VM virtual machines. Design Guidance for RHEL High Availability Clusters - IBM z/VM Instances as Cluster Members Administrative Procedures for RHEL High Availability Clusters - Configuring z/VM SMAPI Fencing with fence_zvmip for RHEL 7 or 8 IBM z Systems Cluster Members RHEL High Availability cluster nodes on IBM z Systems experience STONITH-device timeouts around midnight on a nightly basis (Red Hat Knowledgebase) Administrative Procedures for RHEL High Availability Clusters - Preparing a dasd Storage Device for Use by a Cluster of IBM z Systems Members You may also find the following articles useful when designing a Red Hat High Availability cluster in general. Support Policies for RHEL High Availability Clusters Exploring Concepts of RHEL High Availability Clusters - Fencing/STONITH

Commands:
A.3. ss ss is a command-line utility that prints statistical information about sockets, allowing administrators to assess device performance over time. By default, ss lists open non-listening TCP sockets that have established connections, but a number of useful options are provided to help administrators filter out statistics about specific sockets. One commonly used command is ss -tmpie , which displays all TCP sockets ( t , internal TCP information ( i ), socket memory usage ( m ), processes using the socket ( p ), and detailed socket information ( i ). Red Hat recommends ss over netstat in Red Hat Enterprise Linux 7. ss is provided by the iproute package. For more information, see the man page:

Commands:
man ss
Chapter 4. Accessing the overcloud The director generates a script to configure and help authenticate interactions with your overcloud from the undercloud. The director saves this file ( overcloudrc ) in your stack user's home directory. Run the following command to use this file: This loads the necessary environment variables to interact with your overcloud from the undercloud CLI. To return to interacting with the undercloud, run the following command:

Commands:
source ~/overcloudrc
source ~/stackrc