mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Overview of NFV Network Functions Virtualization (NFV) is a software solution that virtualizes a network function, such as a network switch, on general purpose, cloud-based infrastructure. NFV allows the Communication Service Provider to move away from traditional or proprietary hardware. For a high-level overview of NFV concepts, see the Network Functions Virtualization Product Guide . Note OVS-DPDK and SR-IOV configuration depends on your hardware and topology. This guide provides examples for CPU assignments, memory allocation, and NIC configurations that might vary from your topology and use case. Use Red Hat OpenStack Platform director to isolate specific network types, for example, external, project, internal API, and so on. You can deploy a network on a single network interface, or distributed over a multiple-host network interface. With Open vSwitch you can create bonds by assigning multiple interfaces to a single bridge. Configure network isolation in a Red Hat OpenStack Platform installation with template files. If you do not provide template files, the service networks deploy on the provisioning network. There are two types of template configuration files: network-environment.yaml - this file contains network details, such as subnets and IP address ranges, for the overcloud nodes. This file also contains the different settings that override the default parameter values for various scenarios. Host network templates, for example, compute.yaml and controller.yaml - define the network interface configuration for the overcloud nodes. The values of the network details are provided by the network-environment.yaml file. These heat template files are located at /usr/share/openstack-tripleo-heat-templates/ on the undercloud node. The Hardware requirements and Software requirements sections provide more details on how to plan and configure the heat template files for NFV using the Red Hat OpenStack Platform director. Note You can edit YAML files to configure NFV. For an introduction to the YAML file format, see: YAML in a Nutshell .

Commands:
Chapter 6. Observability 6.1. Health & liveness checks Health & liveness checks are supported via the MicroProfile Health extension. They can be configured via the Camel Health API or via Quarkus MicroProfile Health . All configured checks are available on the standard MicroProfile Health endpoint URLs: http://localhost:8080/q/health http://localhost:8080/q/health/live http://localhost:8080/q/health/ready 6.2. Metrics We provide MicroProfile Metrics for exposing metrics. Some basic Camel metrics are provided for you out of the box, and these can be supplemented by configuring additional metrics in your routes. Metrics are available on the standard Quarkus metrics endpoint: http://localhost:8080/q/metrics

Commands:
8.85. hplip 8.85.1. RHBA-2014:0767 - hplip bug fix update Updated hplip packages that fix one bug are now available for Red Hat Enterprise Linux 6. The hplip packages contain the Hewlett-Packard Linux Imaging and Printing Project (HPLIP), which provides drivers for Hewlett-Packard printers and multi-function peripherals. Bug Fix BZ# 905143 Previously, the udev rules files were not in the correct location on the file system. As a consequence, permissions on the device node after connecting a device were insufficient. This update moves the udev rules files to the correct location, and udev rules now work correctly in the described situation. Users of hplip are advised to upgrade to these updated packages, which fix this bug.

Commands:
3.10. RHEA-2011:1725 - new package: python-configshell A new python-configshell package is now available for Red Hat Enterprise Linux 6. The python-configshell package provides a library for implementing configuration command line interfaces for the Python programming environment. This enhancement update adds the python-configshell package to Red Hat Enterprise Linux 6 as part of the Technology Preview of Fibre Channel over Ethernet (FCoE) target mode. (BZ# 726774 ) Important This package is provided as a dependency of the fcoe-target-utils package. It is recommended to install it only as a prerequisite for running fcoe-target-utils, and not to use it independently. All users who want to use the Technology Preview of Fibre Channel over Ethernet target mode should install this newly-released package, which adds this enhancement.

Commands:
Chapter 2. The Batching API The Batching API is used when the Red Hat JBoss Data Grid cluster is the sole participant in a transaction. However, Java Transaction API ( JTA ) transactions (which use the Transaction Manager) are used when multiple systems are participants in the transaction. Note The Batching API cannot be used in JBoss Data Grid's Remote Client-Server mode. Report a bug 2.1. About Java Transaction API Red Hat JBoss Data Grid supports configuring, use of, and participation in Java Transaction API (JTA) compliant transactions. JBoss Data Grid does the following for each cache operation: First, it retrieves the transactions currently associated with the thread. If not already done, it registers an XAResource with the transaction manager to receive notifications when a transaction is committed or rolled back. Report a bug

Commands:
Chapter 7. Known issues This section lists known issues in Red Hat Developer Hub 1.4. 7.1. Multi-Attached error for Volume (PVC) Currently, when deploying Developer Hub using the Helm Chart, two replicas cannot run on different cluster nodes. This might also affect the upgrade from 1.3 to 1.4.0 if the new pod is scheduled on a different node. A possible workaround for the upgrade is to manually scale down the number of replicas to 0 before upgrading your Helm release. Or manually remove the old Developer Hub pod after upgrading the Helm release. However, this would imply some application downtime. You can also leverage a Pod Affinity rule to force the cluster scheduler to run your Developer Hub pods on the same node. Additional resources RHIDP-5344 7.2. Topology plugin permission is not displayed in the RBAC front-end UI Permissions associated only with front-end plugins do not appear in the UI because they require a backend plugin to expose the permission framework's well-known endpoint. As a workaround, you can apply these permissions by using a CSV file or directly calling the REST API of the RBAC backend plugin. Affected plugins include Topology ( topology.view.read ), Tekton ( tekton.view.read ), ArgoCD ( argocd.view.read ), and Quay ( quay.view.read ). Additional resources RHIDP-3396

Commands:
5.342. usbredir 5.342.1. RHBA-2012:1435 - usbredir bug fix update Updated usbredir packages that fix a bug are now available for Red Hat Enterprise Linux 6. The usbredir packages provide a network protocol for sending USB device traffic over a network connection and a number of libraries to help implement support for this protocol. Bug Fix BZ# 858776 Due to a bug in the libusbredirhost library, handling of timeouts for bulk transfers did not work correctly. Consequently, traffic of USB ACM serial port devices, such as PSTN modems and SmartCard readers, could not be properly redirected. With this update, no timeout is set on the usb-host side for these devices and the traffic redirection works as expected. Users who use USB redirection for Spice are advised to upgrade to these updated packages, which fix this bug.

Commands:
4.3. Clustering and High Availability luci support for fence_sanlock The luci tool now supports the sanlock fence agent as a Technology Preview. The agent is available in the luci's list of agents. Package: luci-0.26.0-48 Recovering a node via a hardware watchdog device New fence_sanlock agent and checkquorum.wdmd, included in Red Hat Enterprise Linux 6.4 as a Technology Preview, provide new mechanisms to trigger the recovery of a node via a hardware watchdog device. Tutorials on how to enable this Technology Preview will be available at https://fedorahosted.org/cluster/wiki/HomePage Note that SELinux in enforcing mode is currently not supported. Package: cluster-3.0.12.1-59

Commands:
14.8.7. Save a Guest Virtual Machine Save the current state of a guest virtual machine to a file using the virsh command: This stops the guest virtual machine you specify and saves the data to a file, which may take some time given the amount of memory in use by your guest virtual machine. You can restore the state of the guest virtual machine with the restore ( Section 14.8.11, "Restore a Guest Virtual Machine" ) option. Save is similar to pause, instead of just pausing a guest virtual machine the present state of the guest virtual machine is saved. The virsh save command can take the following options: --bypass-cache - causes the restore to avoid the file system cache but note that using this option may slow down the restore operation. --xml - this option must be used with an XML file name. Although this option is usually omitted, it can be used to supply an alternative XML file for use on a restored guest virtual machine with changes only in the host-specific portions of the domain XML. For example, it can be used to account for the file naming differences in underlying storage due to disk snapshots taken after the guest was saved. --running - overrides the state recorded in the save image to start the domain as running. --paused - overrides the state recorded in the save image to start the domain as paused. --verbose - displays the progress of the save. If you want to restore the guest virtual machine directly from the XML file, the virsh restore command will do just that. You can monitor the process with the domjobinfo and cancel it with the domjobabort .

Commands:
virsh save {domain-name|domain-id|domain-uuid} state-file --bypass-cache --xml --running --paused --verbose
Chapter 19. qemu-kvm Commands, Flags, and Arguments 19.1. Introduction Note The primary objective of this chapter is to provide a list of the qemu-kvm utility commands, flags, and arguments that are used as an emulator and a hypervisor in Red Hat Enterprise Linux 6. This is a comprehensive summary of the options that are known to work but are to be used at your own risk. Red Hat Enterprise Linux 6 uses KVM as an underlying virtualization technology. The machine emulator and hypervisor used is a modified version of QEMU called qemu-kvm. This version does not support all configuration options of the original QEMU and it also adds some additional options. Options not listed here should not be performed. Whitelist Format <name> - When used in a syntax description, this string should be replaced by user-defined value. [a|b|c] - When used in a syntax description, only one of the strings separated by | is used. When no comment is present, an option is supported with all possible values.

Commands:
Chapter 16. Impersonating the system:admin user 16.1. API impersonation You can configure a request to the OpenShift Container Platform API to act as though it originated from another user. For more information, see User impersonation in the Kubernetes documentation. 16.2. Impersonating the system:admin user You can grant a user permission to impersonate system:admin , which grants them cluster administrator permissions. Procedure To grant a user permission to impersonate system:admin , run the following command: USD oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username> 16.3. Impersonating the system:admin group When a system:admin user is granted cluster administration permissions through a group, you must include the --as=<user> --as-group=<group1> --as-group=<group2> parameters in the command to impersonate the associated groups. Procedure To grant a user permission to impersonate a system:admin by impersonating the associated cluster administration groups, run the following command: USD oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --as=<user> \ --as-group=<group1> --as-group=<group2>

Commands:
oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username>
oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --as=<user> --as-group=<group1> --as-group=<group2>
Chapter 62. Test scenarios Test scenarios in Red Hat Decision Manager enable you to validate the functionality of business rules and business rule data (for rules-based test scenarios) or of DMN models (for DMN-based test scenarios) before deploying them into a production environment. With a test scenario, you use data from your project to set given conditions and expected results based on one or more defined business rules. When you run the scenario, the expected results and actual results of the rule instance are compared. If the expected results match the actual results, the test is successful. If the expected results do not match the actual results, then the test fails. Red Hat Decision Manager includes both the new Test Scenarios designer and the former Test Scenarios (Legacy) designer. The default designer is the new test scenarios designer, which supports the testing of both rules and DMN models and provides an enhanced overall user experience with test scenarios. If required, you can continue to use the legacy test scenarios designer, which supports rule-based test scenarios only. Important The legacy test scenarios designer is deprecated from Red Hat Decision Manager version 7.3.0. It will be removed in a future Red Hat Decision Manager release. Use the new test scenarios designer instead. You can run the defined test scenarios in a number of ways, for example, you can run available test scenarios at the project level or inside a specific test scenario asset. Test scenarios are independent and cannot affect or modify other test scenarios. You can run test scenarios at any time during project development in Business Central. You do not have to compile or deploy your decision service to run test scenarios. You can import data objects from different packages to the same project package as the test scenario. Assets in the same package are imported by default. After you create the necessary data objects and the test scenario, you can use the Data Objects tab of the test scenarios designer to verify that all required data objects are listed or to import other existing data objects by adding a New item . Important Throughout the test scenarios documentation, all references to test scenarios and the test scenarios designer are for the new version, unless explicitly noted as the legacy version.

Commands:
8.3.2. Memory Tuning with virsh 8.3.2.1. memtune The optional <memtune> element in the guest XML configuration allows administrators to configure guest virtual machine memory settings manually. If <memtune> is omitted, default memory settings apply. Display or set memory parameters in the <memtune> element in a virtual machine with the virsh memtune command, replacing values according to your environment: Available parameters include: hard-limit The maximum memory the virtual machine can use, in kibibytes (blocks of 1024 bytes). Warning Setting this limit too low can result in the virtual machine being killed by the kernel. soft-limit The memory limit to enforce during memory contention, in kibibytes (blocks of 1024 bytes). swap-hard-limit The maximum memory plus swap the virtual machine can use, in kibibytes (blocks of 1024 bytes). The swap-hard-limit value must be more than the hard-limit value. min-guarantee The guaranteed minimum memory allocation for the virtual machine, in kibibytes (blocks of 1024 bytes). Note See # virsh help memtune for more information on using the virsh # memtune command.

Commands:
virsh # memtune virtual_machine --parameter size
15.4. Additional Resources For more information about TigerVNC, see the resources listed below. Installed Documentation vncserver(1) - The manual page for the VNC server utility. vncviewer(1) - The manual page for the VNC viewer. vncpasswd(1) - The manual page for the VNC password command. Xvnc(1) - The manual page for the Xvnc server configuration options. x0vncserver(1) - The manual page for the TigerVNC server for sharing existing X servers.

Commands:
Chapter 36. Legacy network scripts support in RHEL By default, RHEL uses NetworkManager to configure and manage network connections, and the /usr/sbin/ifup and /usr/sbin/ifdown scripts use NetworkManager to process ifcfg files in the /etc/sysconfig/network-scripts/ directory. Important The legacy scripts are deprecated in RHEL 8 and will be removed in a future major version of RHEL. If you still use the legacy network scripts, for example, because you upgraded from an earlier version to RHEL 8, Red Hat recommends that you migrate your configuration to NetworkManager. 36.1. Installing the legacy network scripts If you require the deprecated network scripts that processes the network configuration without using NetworkManager, you can install them. In this case, the /usr/sbin/ifup and /usr/sbin/ifdown scripts link to the deprecated shell scripts that manage the network configuration. Procedure Install the network-scripts package:

Commands:
yum install network-scripts
12.3. Booting from the Network Using an Installation Server For network boot, you need a properly configured server, and a network interface in your computer that can support an installation server. For information on how to configure an installation server, see Section 24.1.3, "Configuring Network Boot for IBM Power Systems Using GRUB2" . Configure the computer to boot from the network interface by selecting Select Boot Options in the SMS menu, then Select Boot/Install Device . Finally, select your network device from the list of available devices. Once you properly configure booting from an installation server, the computer can boot the Red Hat Enterprise Linux installation system without any other media. To boot a computer from a server: Procedure 12.1. How to Start the Installation Program from the Network Ensure that the network cable is attached. The link indicator light on the network socket should be lit, even if the computer is not switched on. Switch on the computer. Networking setup and diagnostic information usually appears before your computer connects to the server, although this depends on the hardware in use. Then you will see a menu with options specifying how the network boot server is setup. Press the number key that corresponds to the desired option. In case you are not sure which option you should select, ask your server administrator. If your system does not boot from the network installation server, ensure that the SMS is configured to boot first from the correct network interface. See your hardware's documentation for more information. Important Use the vmlinuz and initrd.img images to boot your system over a network. You cannot use the ppc64.img image to boot over a network; the file is too large for TFTP.

Commands:
B.56. NetworkManager B.56.1. RHBA-2010:0836 - NetworkManager bug fix and enhancement update Updated NetworkManager packages that fix a bug and add various enhancements are now available for Red Hat Enterprise Linux 6. NetworkManager is a system network service that manages network devices and connections, attempting to keep active network connectivity when available. It manages Ethernet, wireless, mobile broadband (WWAN), and PPPoE devices, and provides VPN integration with a variety of different VPN services. Bug Fix BZ# 638598 Under certain circumstances, the "Enable Networking" and "Enable Wireless" menu items in the panel applet may have been insensitive. This error no longer occurs, and both options are now available as expected. Enhancements BZ# In enterprise wireless networks, the proactive key caching can now be used along with the PEAP-GTC authentication mechanism. BZ# Punjabi translation of the network applet has been updated. Users are advised to upgrade to these updated packages, which fix this bug and add these enhancements.

Commands:
7.206. rdesktop 7.206.1. RHBA-2012:1276 - rdesktop bug fix update Updated rdesktop packages that fix multiple bugs are now available for Red Hat Enterprise Linux 6. The rdesktop packages provide a client for the Remote Desktop Server in Microsoft Windows. The rdesktop client uses the Remote Desktop Protocol (RDP) to remotely present a user's desktop. Bug Fixes BZ# 680917 , BZ#772020 Prior to this update, redundant conversions functions did not handle the PC/SC (Personal Computer/Smart Card) integration correctly. As a consequence, the rdesktop on AMD64 and Intel 64 platforms failed to connect and incorrectly. This update removes these redundant functions. This update also adds smart card reader support for AMD64 and Intel 64 platforms. Now, the rdesktop connects as expected. BZ#680926 Prior to this update, the rdesktop code for smart card integration with PC/SC caused a buffer overflow on AMD64 and Intel 64 platforms. As a consequence, the glibc function "free()" was aborted with a segmentation fault. This update uses the correct structure and the glibc function "free()" works now as expected. BZ# 782494 Prior to this update, the server generated a cursor-related command that the rdesktop client did not support when using rdesktop to connect to Windows Server 2008 R2 platforms. As a consequence, the mouse pointer was all black. With this update, the mouse pointer is drawn correctly when connecting to Windows Server 2008 R2. BZ#820008 Prior to this update, the specification file incorrectly listed the libao-devel package as an install dependency for rdesktop. This update removes the libao-devel dependency from the specification file. BZ#831095 Prior to this update, the rdesktop client did not handle the licenses correctly, As a consequence, certain Terminal Services failed to connect after the first connection with the error message "disconnect: Internal licensing error". This update modifies the underlying code to handle licenses as expected. Now, Terminal Services connect as expected. All users of rdesktop are advised to upgrade to these updated packages, which fix these bugs.

Commands:
function::kernel_string_n Name function::kernel_string_n - Retrieves string of given length from kernel memory. Synopsis Arguments addr The kernel address to retrieve the string from. n The maximum length of the string (if not null terminated). General Syntax kernel_string_n:string(addr:long, n:long) Description Returns the C string of a maximum given length from a given kernel memory address. Reports an error on string copy fault.

Commands:
function kernel_string_n:string(addr:long,n:long)
Appendix C. Revision History Revision History Revision 0.5-45 Fri Mar 10 2017 Jiri Herrmann Updates for the 6.9 GA release Revision 0.5-43 Mon Jan 02 2017 Jiri Herrmann Updates for the 6.9 Beta release Revision 0.5-42 Mon May 02 2016 Jiri Herrmann Multiple updates for the 6.8 GA release Revision 0.5-41 Tue Mar 01 2016 Jiri Herrmann Multiple updates for the 6.8 beta release Revision 0.5-40 Thu Oct 08 2015 Jiri Herrmann Cleaned up the Revision History Revision 0.5-39 Wed Apr 29 2015 Dayle Parker Republishing for 6.7 Beta.

Commands:
Chapter 5. Knative CLI for use with OpenShift Serverless The Knative ( kn ) CLI enables simple interaction with Knative components on OpenShift Container Platform. 5.1. Key features The Knative ( kn ) CLI is designed to make serverless computing tasks simple and concise. Key features of the Knative CLI include: Deploy serverless applications from the command line. Manage features of Knative Serving, such as services, revisions, and traffic-splitting. Create and manage Knative Eventing components, such as event sources and triggers. Create sink bindings to connect existing Kubernetes applications and Knative services. Extend the Knative CLI with flexible plug-in architecture, similar to the kubectl CLI. Configure autoscaling parameters for Knative services. Scripted usage, such as waiting for the results of an operation, or deploying custom rollout and rollback strategies. 5.2. Installing the Knative CLI See Installing the Knative CLI .

Commands: