mtpti5iD/redhat-docs_dataset huggingface dataset:
21.5. Guest Virtual Machine Fails to Shutdown Traditionally, executing a virsh shutdown command causes a power button ACPI event to be sent, thus copying the same action as when someone presses a power button on a physical machine. Within every physical machine, it is up to the OS to handle this event. In the past operating systems would just silently shutdown. Today, the most usual action is to show a dialog asking what should be done. Some operating systems even ignore this event completely, especially when no users are logged in. When such operating systems are installed on a guest virtual machine, running virsh shutdown just does not work (it is either ignored or a dialog is shown on a virtual display). However, if a qemu-guest-agent channel is added to a guest virtual machine and this agent is running inside the guest virtual machine's OS, the virsh shutdown command will ask the agent to shutdown the guest OS instead of sending the ACPI event. The agent will call for a shutdown from inside the guest virtual machine OS and everything works as expected. Procedure 21.2. Configuring the guest agent channel in a guest virtual machine Stop the guest virtual machine. Open the Domain XML for the guest virtual machine and add the following snippet: <channel type='unix'> <source mode='bind'/> <target type='virtio' name='org.qemu.guest_agent.0'/> </channel> Figure 21.1. Configuring the guest agent channel Start the guest virtual machine, by running virsh start [domain] . Install qemu-guest-agent on the guest virtual machine ( yum install qemu-guest-agent ) and make it run automatically at every boot as a service (qemu-guest-agent.service). Refer to Chapter 10, QEMU-img and QEMU Guest Agent for more information.

Commands:
<channel type='unix'> <source mode='bind'/> <target type='virtio' name='org.qemu.guest_agent.0'/> </channel>
3.3.2. Converting a remote KVM virtual machine KVM virtual machines can be converted remotely using SSH. Ensure that the host running the virtual machine is accessible using SSH. To convert the virtual machine, run: Where vmhost.example.com is the host running the virtual machine, pool is the local storage pool to hold the image, bridge_name is the name of a local network bridge to connect the converted virtual machine's network to, and guest_name is the name of the Xen virtual machine. You may also use the --network parameter to connect to a locally managed network if your virtual machine only has a single network interface. If your virtual machine has multiple network interfaces, edit /etc/virt-v2v.conf to specify the network mapping for all interfaces. If your virtual machine is Red Hat Enterprise Linux 4 or Red Hat Enterprise Linux 5 and uses a kernel which does not support the KVM VirtIO drivers, virt-v2v will attempt to install a new kernel during the conversion process. You can avoid this requirement by updating the kernel to a recent version of Red Hat Enterprise Linux 6 which supports VirtIO prior to conversion. Note When converting from KVM, virt-v2v requires that the image of the source virtual machine exists within a storage pool. If the image is not currently in a storage pool, you must create one.

Commands:
virt-v2v -ic qemu+ssh://root@vmhost.example.com/system -op pool --bridge bridge_name guest_name
5.320. system-config-date-docs 5.320.1. RHBA-2012:0934 - system-config-date-docs bug fix update Updated system-config-date-docs packages that fix one bug are now available for Red Hat Enterprise Linux 6. The system-config-date-docs packages contain the online documentation for system-config-date, with which you can configure date, time and the use of time servers on your system. Bug Fix BZ# 691572 Prior to this update, the help documentation contained out-of-date screenshots and the text did not correctly reflect the user interface elements. This update contains updated screenshots and documents the user interface correctly. All users are advised to upgrade to these updated packages, which fix this bug.

Commands:
function::sprint_ustack Name function::sprint_ustack - Return stack for the current task from string. Synopsis Arguments stk String with list of hexadecimal addresses for the current task. Description Perform a symbolic lookup of the addresses in the given string, which is assumed to be the result of a prior call to ubacktrace for the current task. Returns a simple backtrace from the given hex string. One line per address. Includes the symbol name (or hex address if symbol couldn't be resolved) and module name (if found). Includes the offset from the start of the function if found, otherwise the offset will be added to the module (if found, between brackets). Returns the backtrace as string (each line terminated by a newline character). Note that the returned stack will be truncated to MAXSTRINGLEN, to print fuller and richer stacks use print_ustack. NOTE it is recommended to use sprint_usyms instead of this function.

Commands:
sprint_ustack:string(stk:string)
Chapter 3. Getting support Windows Container Support for Red Hat OpenShift is provided and available as an optional, installable component. Windows Container Support for Red Hat OpenShift is not part of the OpenShift Container Platform subscription. It requires an additional Red Hat subscription and is supported according to the Scope of coverage and Service level agreements . You must have this separate subscription to receive support for Windows Container Support for Red Hat OpenShift. Without this additional Red Hat subscription, deploying Windows container workloads in production clusters is not supported. You can request support through the Red Hat Customer Portal . For more information, see the Red Hat OpenShift Container Platform Life Cycle Policy document for Red Hat OpenShift support for Windows Containers . If you do not have this additional Red Hat subscription, you can use the Community Windows Machine Config Operator, a distribution that lacks official support.

Commands:
4.4. RHEA-2012:0814 - new package: i2c-tools A new i2c-tools package is now available for Red Hat Enterprise Linux 6. The i2c-tools package contains a set of I2C tools for Linux: a bus probing tool, a chip dumper, register-level SMBus access helpers, EEPROM (Electrically Erasable Programmable Read-Only Memory) decoding scripts, EEPROM programming tools, and a python module for SMBus access. Note EEPROM decoding scripts can render your system unusable. Make sure to use these tools wisely. This enhancement update adds the i2c-tools package to Red Hat Enterprise Linux 6. (BZ# 773267 ) All users who require i2c-tools should install this new package.

Commands:
A.15. taskset The taskset tool is provided by the util-linux package. It allows administrators to retrieve and set the processor affinity of a running process, or launch a process with a specified processor affinity. Important taskset does not guarantee local memory allocation. If you require the additional performance benefits of local memory allocation, Red Hat recommends using numactl instead of taskset. To set the CPU affinity of a running process, run the following command: Replace processors with a comma delimited list of processors or ranges of processors (for example, 1,3,5-7 . Replace pid with the process identifier of the process that you want to reconfigure. To launch a process with a specified affinity, run the following command: Replace processors with a comma delimited list of processors or ranges of processors. Replace application with the command, options and arguments of the application you want to run. For more information about taskset , see the man page:

Commands:
taskset -pc processors pid
taskset -c processors -- application
man taskset
Chapter 1. Building applications overview Using OpenShift Container Platform, you can create, edit, delete, and manage applications using the web console or command line interface (CLI). 1.1. Working on a project Using projects, you can organize and manage applications in isolation. You can manage the entire project lifecycle, including creating, viewing, and deleting a project in OpenShift Container Platform. After you create the project, you can grant or revoke access to a project for the users using the Developer perspective. You can also edit the project configuration resource while creating a project template that is used for automatic provisioning of new projects. Using the CLI, you can create a project as a different user by impersonating a request to the OpenShift Container Platform API. When you make a request to create a new project, the OpenShift Container Platform uses an endpoint to provision the project according to a customizable template. As a cluster administrator, you can choose to prevent an authenticated user group from self-provisioning new projects . 1.2. Working on an application 1.2.1. Creating an application To create applications, you must have created a project or have access to a project with the appropriate roles and permissions. You can create an application by using either the Developer perspective in the web console , installed Operators , or the OpenShift Container Platform CLI . You can source the applications to be added to the project from Git, JAR files, devfiles, or the developer catalog. You can also use components that include source or binary code, images, and templates to create an application by using the OpenShift Container Platform CLI. With the OpenShift Container Platform web console, you can create an application from an Operator installed by a cluster administrator. 1.2.2. Maintaining an application After you create the application you can use the web console to monitor your project or application metrics . You can also edit or delete the application using the web console. When the application is running, not all applications resources are used. As a cluster administrator, you can choose to idle these scalable resources to reduce resource consumption. 1.2.3. Deploying an application You can deploy your application using Deployment or DeploymentConfig objects and manage them from the web console. You can create deployment strategies that help reduce downtime during a change or an upgrade to the application. You can also use Helm , a software package manager that simplifies deployment of applications and services to OpenShift Container Platform clusters. 1.3. Using the Red Hat Marketplace The Red Hat Marketplace is an open cloud marketplace where you can discover and access certified software for container-based environments that run on public clouds and on-premises.

Commands:
Chapter 1. What is simple content access? Simple content access is a set of capabilities that enables a change in the way Red Hat manages its subscription and entitlement enforcement model. This model of content access and consumption results in fewer barriers to content deployment. Note The process of migrating Red Hat accounts and organizations that primarily use Red Hat Subscription Management for subscription management to use simple content access begins on October 25, 2024, and will be complete in November 2024. For Red Hat accounts and organizations that primarily use Satellite, versions 6.15 and earlier can continue to support an entitlement-based workflow for the remainder of the supported lifecycle for those versions. However, Satellite version 6.16 and later versions will support only the simple content access workflow. With simple content access, the enforcement model changes from a per-system requirement, where you must attach a subscription to a system before you can access content, to a per-organization and per-account requirement, where you can access content on a system without attaching a subscription to that system. Because of the added freedom and flexibility to consume content that simple content access provides, and in the absence of strict entitlement enforcement from the classic entitlement-based subscription model, it becomes important for you to keep track of how you are using your subscriptions. With the subscriptions service, Red Hat provides additional tooling to help you with tracking and compliance. The subscriptions service is a reporting solution that provides account-wide visibility of both subscription usage and utilization and aids in self-governance of your entire subscription profile. When simple content access and the subscriptions service are used together, they enable a different and more flexible subscription experience. Overall, this experience removes or improves many of the high-overhead and complicated business processes that are associated with the classic Red Hat entitlement-based enforcement subscription model: Time-consuming processes that require multiple Red Hat tools and many steps for content to be accessed and used. Overly complex and sometimes extremely manual processes that are needed to complete subscription reporting. Processes to resolve problems related to accessing content, under- and over-deployment, renewals, and so on, that resulted in significant business impact to Red Hat customers, including being blocked from content access. You can choose to use neither, either, or both of these services. However, simple content access and the subscriptions service are designed as complementary services and function best when they are used in tandem. To learn more about the subscriptions service and how you can use it with simple content access, see the Getting Started with the Subscriptions Service guide.

Commands:
Chapter 16. Creating assets You can create business processes, rules, DRL files, and other assets in your Business Central projects. Note Migrating business processes is an irreversible process. Procedure In Business Central, go to Menu Design Projects and click the project name. For example, Evaluation . Click Add Asset and select the asset type. In the Create new asset_type window, add the required information and click Ok . Figure 16.1. Define Asset Note If you have not created a project, you can either add a project, use a sample project, or import an existing project. For more information, see Managing projects in Business Central .

Commands:
5.4.2. Creating Striped Volumes For large sequential reads and writes, creating a striped logical volume can improve the efficiency of the data I/O. For general information about striped volumes, see Section 3.3.2, "Striped Logical Volumes" . When you create a striped logical volume, you specify the number of stripes with the -i argument of the lvcreate command. This determines over how many physical volumes the logical volume will be striped. The number of stripes cannot be greater than the number of physical volumes in the volume group (unless the --alloc anywhere argument is used). If the underlying physical devices that make up a striped logical volume are different sizes, the maximum size of the striped volume is determined by the smallest underlying device. For example, in a two-legged stripe, the maximum size is twice the size of the smaller device. In a three-legged stripe, the maximum size is three times the size of the smallest device. The following command creates a striped logical volume across 2 physical volumes with a stripe of 64kB. The logical volume is 50 gigabytes in size, is named gfslv , and is carved out of volume group vg0 . As with linear volumes, you can specify the extents of the physical volume that you are using for the stripe. The following command creates a striped volume 100 extents in size that stripes across two physical volumes, is named stripelv and is in volume group testvg . The stripe will use sectors 0-49 of /dev/sda1 and sectors 50-99 of /dev/sdb1 .

Commands:
lvcreate -L 50G -i2 -I64 -n gfslv vg0
lvcreate -l 100 -i2 -nstripelv testvg /dev/sda1:0-49 /dev/sdb1:50-99 Using default stripesize 64.00 KB Logical volume "stripelv" created
8.2. Types The main permission control method used in SELinux targeted policy to provide advanced process isolation is Type Enforcement. All files and processes are labeled with a type: types define a SELinux domain for processes and a SELinux type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. The following types are used with squid . Different types allow you to configure flexible access: httpd_squid_script_exec_t This type is used for utilities such as cachemgr.cgi , which provides a variety of statistics about squid and its configuration. squid_cache_t Use this type for data that is cached by squid, as defined by the cache_dir directive in /etc/squid/squid.conf . By default, files created in or copied into /var/cache/squid/ and /var/spool/squid/ are labeled with the squid_cache_t type. Files for the squidGuard URL redirector plugin for squid created in or copied to /var/squidGuard/ are also labeled with the squid_cache_t type. Squid is only able to use files and directories that are labeled with this type for its cached data. squid_conf_t This type is used for the directories and files that squid uses for its configuration. Existing files, or those created in or copied to /etc/squid/ and /usr/share/squid/ are labeled with this type, including error messages and icons. squid_exec_t This type is used for the squid binary, /usr/sbin/squid . squid_log_t This type is used for logs. Existing files, or those created in or copied to /var/log/squid/ or /var/log/squidGuard/ must be labeled with this type. squid_initrc_exec_t This type is used for the initialization file required to start squid which is located at /etc/rc.d/init.d/squid . squid_var_run_t This type is used by files in /var/run/ , especially the process id (PID) named /var/run/squid.pid which is created by squid when it runs.

Commands:
Chapter 3. Deploying applications with OpenShift Client You can use OpenShift Client (oc) for application deployment. Procedure Create a new OpenShift project: Add the ASP.NET Core application: Track the progress of the build: View the deployed application once the build is finished: The application is now accessible within the project. Optional: Make the project accessible externally: Obtain the shareable URL:

Commands:
oc new-project sample-project
oc new-app --name= example-app 'dotnet:9.0-ubi8~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnet-9.0' --build-env DOTNET_STARTUP_PROJECT=app
oc logs -f bc/ example-app
oc logs -f dc/ example-app
oc expose svc/ example-app
oc get routes
8.29. device-mapper-persistent-data 8.29.1. RHEA-2013:1696 - device-mapper-persistent-data enhancement update Updated device-mapper-persistent-data packages that add various enhancements are now available for Red Hat Enterprise Linux 6. The device-mapper-persistent-data packages provide device-mapper thin provisioning (thinp) tools. Bug Fix BZ# 814790 , BZ# 960284 , BZ# 1006059 , BZ# 1019217 This enhancement update adds important thin provisioning tools (repair, rmap, and metadata_size) as well as caching tools (check, dump, restore, and repair) to the device-mapper-persistent-data packages in Red Hat Enterprise Linux 6. Users of device-mapper-persistent-data are advised to upgrade to these updated packages, which add these enhancements.

Commands:
33.9. Additional Resources To learn more about printing on Red Hat Enterprise Linux, refer to the following resources. 33.9.1. Installed Documentation map lpr - The manual page for the lpr command that allows you to print files from the command line. man lprm - The manual page for the command line utility to remove print jobs from the print queue. man mpage - The manual page for the command line utility to print multiple pages on one sheet of paper. man cupsd - The manual page for the CUPS printer daemon. man cupsd.conf - The manual page for the CUPS printer daemon configuration file. man classes.conf - The manual page for the class configuration file for CUPS.

Commands:
Chapter 16. The Rapid Stock Market Quickstart The Rapid Stock Market quickstart demonstrates how JBoss Data Grid's compatibility mode works with a Hot Rod client (to store data) and a HTTP client using REST (to retrieve data). This quickstart is only available in JBoss Data Grid's Remote Client-Server mode and does not use any containers. The Rapid Stock Market quickstart includes a server-side and a client-side application. Report a bug 16.1. Build and Run the Rapid Stock Market Quickstart The Rapid Stock Market quickstart requires the following configuration for the server and client sides of the application. Procedure 16.1. Rapid Stock Market Quickstart Server-side Configuration Navigate to the Root Directory Open a command line and navigate to the root directory of this quickstart. Build a server module for the JBoss Data Grid Server by packaging a class that is common for the client and server in a jar file: Place the new jar file in a directory structure that is similar to the server module. Install the server module into the server. Copy the prepared module to the server: Add the new module as a dependency of the org.infinispan.commons module by adding the following into the modules/system/layers/base/org/infinispan/commons/main/module.xml file: Build the application: Configure the JBoss Data Grid to use the appropriate configuration file. Copy the example configuration file for compatibility mode to a location where the JBoss Data Grid Server can locate and use it: Remove the security-domain and auth-method attributes from the rest-connector element to disable REST security. Start the JBoss Data Grid Server in compatibility mode: Procedure 16.2. Rapid Stock Market Quickstart Client-side Configuration In a new command line terminal window, start the client-side application: Use the instructions in the help menu for the client application. Report a bug

Commands:
mvn clean package -Pprepare-server-module
cp -r target/modules USD{JDG_SERVER_HOME}/
<module name="org.infinispan.quickstart.compatibility.common"/>
mvn clean package
cp USD{JDG_SERVER_HOME}/docs/examples/configs/standalone-compatibility-mode.xml USD{JDG_SERVER_HOME}/standalone/configuration
USD{JDG_SERVER_HOME}/bin/standalone.sh -c standalone-compatibility-mode.xml
mvn exec:java -Pclient
Chapter 13. Accessing the RADOS Object Gateway S3 endpoint Users can access the RADOS Object Gateway (RGW) endpoint directly. In versions of Red Hat OpenShift Data Foundation, RGW service needed to be manually exposed to create RGW public route. As of OpenShift Data Foundation version 4.7, the RGW route is created by default and is named rook-ceph-rgw-ocs-storagecluster-cephobjectstore .

Commands:
Chapter 15. Annotating encrypted RBD storage classes Starting with OpenShift Data Foundation 4.14, when the OpenShift console creates a RADOS block device (RBD) storage class with encryption enabled, the annotation is set automatically. However, you need to add the annotation, cdi.kubevirt.io/clone-strategy=copy for any of the encrypted RBD storage classes that were previously created before updating to the OpenShift Data Foundation version 4.14. This enables customer data integration (CDI) to use host-assisted cloning instead of the default smart cloning. The keys used to access an encrypted volume are tied to the namespace where the volume was created. When cloning an encrypted volume to a new namespace, such as, provisioning a new OpenShift Virtualization virtual machine, a new volume must be created and the content of the source volume must then be copied into the new volume. This behavior is triggered automatically if the storage class is properly annotated.

Commands: