mtpti5iD/redhat-docs_dataset huggingface dataset:
5.5. Hot Plugging vCPUs You can hot plug vCPUs. Hot plugging means enabling or disabling devices while a virtual machine is running. Important Hot unplugging a vCPU is only supported if the vCPU was previously hot plugged. A virtual machine's vCPUs cannot be hot unplugged to less vCPUs than it was originally created with. The following prerequisites apply: The virtual machine's Operating System must be explicitly set in the New Virtual Machine or Edit Virtual Machine window. The virtual machine's operating system must support CPU hot plug. See the table below for support details. Windows virtual machines must have the guest agents installed. See Section 3.3.2, "Installing the Guest Agents, Tools, and Drivers on Windows" . Hot Plugging vCPUs Click Compute Virtual Machines and select a running virtual machine. Click Edit . Click the System tab. Change the value of Virtual Sockets as required. Click OK . Table 5.1. Operating System Support Matrix for vCPU Hot Plug Operating System Version Architecture Hot Plug Supported Hot Unplug Supported Red Hat Enterprise Linux Atomic Host 7 x86 Yes Yes Red Hat Enterprise Linux 6.3+ x86 Yes Yes Red Hat Enterprise Linux 7.0+ x86 Yes Yes Red Hat Enterprise Linux 7.3+ PPC64 Yes Yes Red Hat Enterprise Linux 8.0+ x86 Yes Yes Microsoft Windows Server 2008 All x86 No No Microsoft Windows Server 2008 Standard, Enterprise x64 No No Microsoft Windows Server 2008 Datacenter x64 Yes No Microsoft Windows Server 2008 R2 All x86 No No Microsoft Windows Server 2008 R2 Standard, Enterprise x64 No No Microsoft Windows Server 2008 R2 Datacenter x64 Yes No Microsoft Windows Server 2012 All x64 Yes No Microsoft Windows Server 2012 R2 All x64 Yes No Microsoft Windows Server 2016 Standard, Datacenter x64 Yes No Microsoft Windows 7 All x86 No No Microsoft Windows 7 Starter, Home, Home Premium, Professional x64 No No Microsoft Windows 7 Enterprise, Ultimate x64 Yes No Microsoft Windows 8.x All x86 Yes No Microsoft Windows 8.x All x64 Yes No Microsoft Windows 10 All x86 Yes No Microsoft Windows 10 All x64 Yes No

Commands:
probe::sunrpc.clnt.call_sync Name probe::sunrpc.clnt.call_sync - Make a synchronous RPC call Synopsis sunrpc.clnt.call_sync Values xid current transmission id servername the server machine name flags flags dead whether this client is abandoned prog the RPC program number port the port number prot the IP protocol number progname the RPC program name vers the RPC program version number proc the procedure number in this RPC call procname the procedure name in this RPC call

Commands:
probe::socket.recvmsg.return Name probe::socket.recvmsg.return - Return from Message being received on socket Synopsis socket.recvmsg.return Values family Protocol family value name Name of this probe protocol Protocol value state Socket state value success Was receive successful? (1 = yes, 0 = no) flags Socket flags value type Socket type value size Size of message received (in bytes) or error code if success = 0 Context The message receiver. Description Fires at the conclusion of receiving a message on a socket via the sock_recvmsg function.

Commands:
Release notes OpenShift Container Platform 4.16 Highlights of what is new and what has changed with this OpenShift Container Platform release Red Hat OpenShift Documentation Team

Commands:
featureSet: CustomNoUpgrade featureGates: - ClusterAPIInstall=true
Warning: short name "ex" could also match lower priority resource examples.test.com
- lastTransitionTime: "2024-04-11T05:54:37Z" message: Cluster is configured with OpenShiftSDN, which is not supported in the next version. Please follow the documented steps to migrate from OpenShiftSDN to OVN-Kubernetes in order to be able to upgrade. https://docs.openshift.com/container-platform/4.16/networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.html reason: OpenShiftSDNConfigured status: "False" type: Upgradeable
This pod appears to have created one or more iptables rules. IPTables is deprecated and will no longer be available in RHEL 10 and later. You should consider migrating to another API such as nftables or eBPF.
Platform.BareMetal.externalBridge: Invalid value: "baremetal": could not find interface "baremetal"
apiVersion: v1 kind: ConfigMap metadata: name: mtu namespace: openshift-network-operator data: mtu: "1500" 1
oc adm release info 4.16.37 --pullspecs
oc adm release info 4.16.36 --pullspecs
oc adm release info 4.16.35 --pullspecs
oc adm release info 4.16.34 --pullspecs
oc adm release info 4.16.33 --pullspecs
oc adm release info 4.16.32 --pullspecs
oc adm release info 4.16.30 --pullspecs
oc adm release info 4.16.29 --pullspecs
oc adm release info 4.16.28 --pullspecs
oc adm release info 4.16.27 --pullspecs
oc adm release info 4.16.26 --pullspecs
oc adm release info 4.16.25 --pullspecs
oc adm release info 4.16.24 --pullspecs
oc adm release info 4.16.23 --pullspecs
oc adm release info 4.16.21 --pullspecs
oc adm release info 4.16.20 --pullspecs
oc adm release info 4.16.19 --pullspecs
oc adm release info 4.16.18 --pullspecs
oc adm release info 4.16.17 --pullspecs
oc adm release info 4.16.16 --pullspecs
oc adm release info 4.16.15 --pullspecs
oc adm release info 4.16.14 --pullspecs
oc adm release info 4.16.13 --pullspecs
oc adm release info 4.16.12 --pullspecs
oc adm release info 4.16.11 --pullspecs
oc adm release info 4.16.10 --pullspecs
oc adm release info 4.16.9 --pullspecs
oc adm release info 4.16.8 --pullspecs
oc adm release info 4.16.7 --pullspecs
oc adm release info 4.16.6 --pullspecs
apiVersion: v1 data: enable-nodeip-debug: "true" kind: ConfigMap metadata: name: logging namespace: openshift-vsphere-infra
oc adm release info 4.16.5 --pullspecs
[ERROR]: [ReleaseImageCollector] open USD{FOLDER}/working-dir/hold-release/ocp-release/4.15.17-x86_64/release-manifests/image-references: no such file or directory
VM has a local SSD attached but an undefined value for 'discard-local-ssd' when using A3 instance types
[ERROR]: [ReleaseImageCollector] open USD{FOLDER}/working-dir/hold-release/ocp-release/4.15.17-x86_64/release-manifests/image-references: no such file or directory
oc adm release info 4.16.4 --pullspecs
oc adm release info 4.16.3 --pullspecs
oc adm release info 4.16.2 --pullspecs
oc adm release info 4.16.1 --pullspecs
oc adm release info 4.16.0 --pullspecs
17.9. Changing Recursive Queries Against Forwarders The ipa-client-install script sets a configuration statement in the /etc/named.conf file that allows name resolution against hosts that are outside the IdM DNS domain. (This requires that the IdM server be set up with DNS configured and with forwarders configured.) What this means is that any host is permitted to issue recursive queries against configured forwarders. By default, any host is permitted to issue recursive queries against configured forwarders. The IdM installation script automatically adds a line to the /etc/named.conf file to allow these recursive queries. This behavior can be changed in the allow-recursion statement. Open the /etc/named.conf file. Reset the allow-recursion statement. This is set to any by default, which allows all hosts to resolve names against all forwarders. Restart the named service. The name server documentation has more details on editing configuration statements.

Commands:
forward first; forwarders { 10.16.36.29; }; allow-recursion { any; };
forward first; forwarders { 10.16.36.29; }; allow-recursion { any; };
service named restart
8.8. Additional Resources For more information about various security compliance fields of interest, see the resources below. Installed Documentation oscap (8) - The manual page for the oscap command-line utility provides a complete list of available options and their usage explanation. Guide to the Secure Configuration of Red Hat Enterprise Linux 6 - An HTML document located in the /usr/share/doc/scap-security-guide-0.1.18/ directory that provides a detailed guide for security settings of your system in form of an XCCDF checklist. Online Documentation The OpenSCAP project page - The home page to the OpenSCAP project provides detailed information about the oscap utility and other components and projects related to SCAP. The SCAP Workbench project page - The home page to the SCAP Workbench project provides detailed information about the scap-workbench application. The SCAP Security Guide (SSG) project page - The home page to the SSG project that provides the latest security content for Red Hat Enterprise Linux. National Institute of Standards and Technology (NIST) SCAP page - This page represents a vast collection of SCAP related materials, including SCAP publications, specifications, and the SCAP Validation Program. National Vulnerability Database (NVD) - This page represents the largest repository of SCAP content and other SCAP standards based vulnerability management data. Red Hat OVAL content repository - This is a repository containing OVAL definitions for Red Hat Enterprise Linux systems. MITRE CVE - This is a database of publicly known security vulnerabilities provided by the MITRE corporation. MITRE OVAL - This page represents an OVAL related project provided by the MITRE corporation. Amongst other OVAL related information, these pages contain the latest version of the OVAL language and a huge repository of OVAL content, counting over 22 thousands OVAL definitions. Red Hat Satellite documentation - This set of guides describes, amongst other topics, how to maintain system security on multiple systems by using OpenSCAP.

Commands:
function::usymdata Name function::usymdata - Return the symbol and module offset of an address. Synopsis Arguments addr The address to translate. Description Returns the (function) symbol name associated with the given address in the current task if known, the offset from the start and the size of the symbol, plus the module name (between brackets). If symbol is unknown, but module is known, the offset inside the module, plus the size of the module is added. If any element is not known it will be omitted and if the symbol name is unknown it will return the hex string for the given address.

Commands:
usymdata:string(addr:long)
4.7.3. Configuring a Node with Redundant Power If your cluster is configured with redundant power supplies for your nodes, you must be sure to configure fencing so that your nodes fully shut down when they need to be fenced. If you configure each power supply as a separate fence method, each power supply will be fenced separately; the second power supply will allow the system to continue running when the first power supply is fenced and the system will not be fenced at all. To configure a system with dual power supplies, you must configure your fence devices so that both power supplies are shut off and the system is taken completely down. When configuring your system using Conga , this requires that you configure two instances within a single fencing method. To configure fencing for a node with dual power supplies, follow the steps in this section. Before you can configure fencing for a node with redundant power, you must configure each of the power switches as a fence device for the cluster. For information on configuring fence devices, see Section 4.6, "Configuring Fence Devices" . From the cluster-specific page, click on Nodes along the top of the cluster display. This displays the nodes that constitute the cluster. This is also the default page that appears when you click on the cluster name beneath Manage Clusters from the menu on the left side of the luci Homebase page. Click on a node name. Clicking a link for a node causes a page to be displayed for that link showing how that node is configured. On the node-specific page, click Add Fence Method . Enter a name for the fencing method that you are configuring for this node. Click Submit . This displays the node-specific screen that now displays the method you have just added under Fence Devices . Configure the first power supply as a fence instance for this method by clicking Add Fence Instance . This displays a drop-down menu from which you can select one of the power fencing devices you have previously configured, as described in Section 4.6.1, "Creating a Fence Device" . Select one of the power fence devices for this method and enter the appropriate parameters for this device. Click Submit . This returns you to the node-specific screen with the fence method and fence instance displayed. Under the same fence method for which you have configured the first power fencing device, click Add Fence Instance . This displays a drop-down menu from which you can select the second power fencing devices you have previously configured, as described in Section 4.6.1, "Creating a Fence Device" . Select the second of the power fence devices for this method and enter the appropriate parameters for this device. Click Submit . This returns you to the node-specific screen with the fence methods and fence instances displayed, showing that each device will power the system off in sequence and power the system on in sequence. This is shown in Figure 4.7, "Dual-Power Fencing Configuration" . Figure 4.7. Dual-Power Fencing Configuration

Commands:
2.3. Storage Domain Types Red Hat Virtualization supports the following types of storage domains, as well as the storage types that each storage domain supports. The Data Domain stores the hard disk images of all virtual machines in the Red Hat Virtualization environment. Disk images may contain an installed operating system or data stored or generated by a virtual machine. Data storage domains support NFS, iSCSI, FCP, GlusterFS and POSIX compliant storage. A data domain cannot be shared between multiple data centers. Note GlusterFS Storage is deprecated, and will no longer be supported in future releases. The Export Domain provides transitory storage for hard disk images and virtual machine templates being transferred between data centers. Additionally, export storage domains store backed up copies of virtual machines. Export storage domains support NFS storage. Multiple data centers can access a single export storage domain but only one data center can use it at a time. Note The Export domain is deprecated. Storage data domains can be unattached from a data center and imported to another data center in the same environment, or in a different environment. Virtual machines, floating virtual disks, and templates can then be uploaded from the imported storage domain to the attached data center. The ISO Domain stores ISO files, also called images. ISO files are representations of physical CDs or DVDs. In the Red Hat Virtualization environment the common types of ISO files are operating system installation disks, application installation disks, and guest agent installation disks. These images can be attached to virtual machines and booted in the same way that physical disks are inserted into a disk drive and booted. ISO storage domains allow all hosts within the data center to share ISOs, eliminating the need for physical optical media. Note The ISO domain is a deprecated storage domain type. The ISO Uploader tool has been deprecated. Red Hat recommends uploading ISO images to the data domain with the Administration Portal or with the REST API.

Commands:
3.10. Software Collection logrotate Support With your Software Collection or an application associated with your Software Collection, you can manage log files with the logrotate program. Procedure 3.9. Managing log files with logrotate To manage your log files with logrotate , place a custom logrotate file for your Software Collection in the system directory for the logrotate jobs /etc/logrotate.d/ . For example, create the following file: Ensure that the contents of the logrotate file follow the standard logrotate file format as follows: Add the file to your spec file of the Software Collection package: SOURCE2: %{?scl_prefix}logrotate Install the file into the system directory /etc/logrotate.d/ by adjusting the %install section of the Software Collection package's spec file: %install install -p -c -m 644 %{SOURCE2} USDRPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/logrotate.d/

Commands:
%{?scl_prefix}logrotate
/opt/ provider / software_collection /var/log/ your_application_name .log { missingok notifempty size 30k yearly create 0600 root root }
SOURCE2: %{?scl_prefix}logrotate
%install install -p -c -m 644 %{SOURCE2} USDRPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/logrotate.d/
Chapter 6. Generating build-time network policies The build-time network policy generator is included in the roxctl CLI. For the build-time network policy generation feature, roxctl CLI does not need to communicate with RHACS Central so you can use it in any development environment. 6.1. Using the build-time network policy generator You can generate network policies by using the built-in network policy generator in the roxctl CLI. Prerequisites The build-time network policy generator recursively scans the directory you specify when you run the command. Therefore, before you run the command, you must already have service manifests, config maps, and workload manifests such as Pod , Deployment , ReplicaSet , Job , DaemonSet , and StatefulSet as YAML files in the specified directory. Verify that you can apply these YAML files as-is using the kubectl apply -f command. The build-time network policy generator does not work with files that use Helm-style templating. Verify that the service network addresses are not hard-coded. Every workload that needs to connect to a service must specify the service network address as a variable. You can specify this variable by using the workload's resource environment variable or in a config map. Example 1: using an environment variable Example 2: using a config map Example 3: using a config map Service network addresses must match the following official regular expression pattern: 1 In this pattern, <svc> is the service name. <ns> is the namespace where you defined the service. <portNum> is the exposed service port number. Following are some examples that match the pattern: wordpress-mysql:3306 redis-follower.redis.svc.cluster.local:6379 redis-leader.redis http://rating-service. Procedure Verify that the build-time network policy generation feature is available by running the help command: USD roxctl netpol generate -h Generate the policies by using the netpol generate command: USD roxctl netpol generate <folder-path> 1 1 Specify the path of the folder that has the Kubernetes manifests. The roxctl netpol generate command supports the following options: Option Description -h, --help View the help text for the netpol command. -d, --output-dir <dir> Save the generated policies into a target folder. One file per policy. -f, --output-file <filename> Save and merge the generated policies into a single YAML file. --fail Fail on the first encountered error. The default value is false . --remove Remove the output path if it already exist. --strict Treat warnings as errors. The default value is false . --dnsport Specify the default DNS port to use in the egress rules of the generated policies. The default value is 53 .

Commands:
(http(s)?://)?<svc>(.<ns>(.svc.cluster.local)?)?(:<portNum>)? 1
roxctl netpol generate -h
roxctl netpol generate <folder-path> 1
2.4. Tickless Kernel In versions of Red Hat Enterprise Linux, the kernel used a timer-based mechanism that continuously produced a system interrupt. During each interrupt, the system polled ; that is, it checked to see if there was work to be done. Depending on the setting, this system interrupt or timer tick could occur several hundred or several thousand times per second. This happened every second, regardless of the system's workload. On a lightly loaded system, this impacts power consumption by preventing the processor from effectively using sleep states. The system uses the least power when it is in a sleep state. The most power-efficient way for a system to operate is to do work as quickly as possible, go into the deepest sleep state possible, and sleep as long as possible. To implement this, Red Hat Enterprise Linux 6 uses a tickless kernel . With this, the interrupt timer has been removed from the idle loop, transforming Red Hat Enterprise Linux 6 into a completely interrupt-driven environment. The tickless kernel allows the system to go into deep sleep states during idle times, and respond quickly when there is work to be done. For further information, refer to the Power Management Guide , available from http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ .

Commands:
Chapter 1. Red Hat build of OpenJDK 17 overview OpenJDK (Open Java Development Kit) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). The Red Hat build of OpenJDK is available in four versions: 8u, 11u, 17u, and 21u. Packages for the Red Hat build of OpenJDK are made available on Red Hat Enterprise Linux and Microsoft Windows and shipped as a JDK and JRE in the Red Hat Ecosystem Catalog.

Commands:
Chapter 13. Scoping tokens 13.1. About scoping tokens You can create scoped tokens to delegate some of your permissions to another user or service account. For example, a project administrator might want to delegate the power to create pods. A scoped token is a token that identifies as a given user but is limited to certain actions by its scope. Only a user with the cluster-admin role can create scoped tokens. Scopes are evaluated by converting the set of scopes for a token into a set of PolicyRules . Then, the request is matched against those rules. The request attributes must match at least one of the scope rules to be passed to the "normal" authorizer for further authorization checks. 13.1.1. User scopes User scopes are focused on getting information about a given user. They are intent-based, so the rules are automatically created for you: user:full - Allows full read/write access to the API with all of the user's permissions. user:info - Allows read-only access to information about the user, such as name and groups. user:check-access - Allows access to self-localsubjectaccessreviews and self-subjectaccessreviews . These are the variables where you pass an empty user and groups in your request object. user:list-projects - Allows read-only access to list the projects the user has access to. 13.1.2. Role scope The role scope allows you to have the same level of access as a given role filtered by namespace. role:<cluster-role name>:<namespace or * for all> - Limits the scope to the rules specified by the cluster-role, but only in the specified namespace . Note Caveat: This prevents escalating access. Even if the role allows access to resources like secrets, rolebindings, and roles, this scope will deny access to those resources. This helps prevent unexpected escalations. Many people do not think of a role like edit as being an escalating role, but with access to a secret it is. role:<cluster-role name>:<namespace or * for all>:! - This is similar to the example above, except that including the bang causes this scope to allow escalating access.

Commands:
Chapter 13. The Hello World Quickstart Hello World is a simple quickstart that illustrates how to store and retrieve data from a cache using Red Hat JBoss Data Grid. For this quickstart, users can access the cache in two ways: from a servlet. from a JSF page using request scoped beans. All libraries (JAR files) bundles with the application are deployed to JBoss Enterprise Application Platform 6.x. JBoss Data Grid's Library mode only allows local access to a single node in a distributed cluster. This mode also allows the application to access the data grid functionality within a virtual machine in the target container. Important The Hello World quickstart works only in JBoss Data Grid's Library mode. Location JBoss Data Grid's Hello World quickstart is available at the following location: jboss-datagrid-{VERSION}-quickstarts/ Report a bug 13.1. Quickstart Prerequisites The prerequisites for this quickstart are as follows: Java 6.0 (Java SDK 1.6) or better JBoss Enterprise Application Platform 6.x or JBoss Enterprise Web Server 2.x Maven 3.0 or better Configure the Maven Repository. For details, see Chapter 3, Install and Use the Maven Repositories Report a bug

Commands: