mtpti5iD/redhat-docs_dataset huggingface dataset:
3.3. Modeling Your View Metadata When you create View Metadata, you are not describing the nature of your physical data storage. Instead, you describe the way your enterprise uses the information in its day to day operations. View Metadata derives its classes and attributes from other metadata. You can derive View Metadata from Source Metadata that describes the ultimate sources for the metadata or even from other View Metadata. However, when you model View Metadata, you create special views on your existing enterprise information systems that you can tailor to your business use or application expectations. This View Metadata offers many benefits: You can expose only the information relevant to an application. The application uses this View Metadata to resolve its queries to the ultimate physical data storage. You can add content to existing applications that require different views of the data by adding the View Metadata to the existing View Metadata that application uses. You save time and effort since you do not have to create new models nor modify your existing applications. Your applications do not need to refer to specific physical enterprise information systems, offering flexibility and interchangeability. As you change sources for information, you do not have to change your end applications. The View Metadata models document the various ways your enterprise uses the information and the different terminology that refers to that information. They do so in a central location. Our example enterprise information sources, the address book database, and the vendor supplied comma-delimited text file, reside in two different native storage formats and therefore have two Source Metadata models. However, they can represent one business need: a pool of addresses for a mass mailing. By creating a View Metadata model, we could accurately show that this single View Table, the AddressPool, contains information from the two enterprise information systems. The View Metadata model not only shows from where it gets the information, but also the SQL operations it performs to select its information from its source models. This View Metadata can not only reflect and describe how your organization uses that information, but, if your enterprise uses the JBoss Data Virtualization Server, your applications can use the View Metadata to resolve queries. To create this View Metadata, you create a view and define a transformation for that view, a special query that enables you to select information from the source (or even other view) metadata models.

Commands:
Part I. File Systems The File Systems section provides information on the file system structure and maintenance, the Btrfs Technology Preview, and file systems that Red Hat fully supports: ext3, ext4, GFS2, XFS, NFS, and FS-Cache. Note Btrfs is available as a Technology Preview feature in Red Hat Enterprise Linux 7 but has been deprecated since the Red Hat Enterprise Linux 7.4 release. It will be removed in a future major release of Red Hat Enterprise Linux. For more information, see Deprecated Functionality in the Red Hat Enterprise Linux 7.4 Release Notes. For an overview of Red Hat Enterprise Linux file systems and storage limits, see Red Hat Enterprise Linux technology capabilities and limits at Red Hat Knowledgebase. XFS is the default file system in Red Hat Enterprise Linux 7 and Red Hat, and Red Hat recommends you to use XFS unless you have a strong reason to use another file system. For general information on common file systems and their properties, see the following Red Hat Knowledgebase article: How to Choose your Red Hat Enterprise Linux File System .

Commands:
B.6. Storing Information in Multiple Languages If the directory contains a single language, it is not necessary to do anything special to add a new entry to the directory. However, if an organization is multinational, it may be necessary to store information in multiple languages so that users in different locales can view directory information in their own language. When information in the directory is represented in multiple languages, the server associates language tags with attribute values. When a new entry is added, the attribute values used in the RDN (relative distinguished name, the naming attribute) must be provided without any language codes. Multiple languages can be stored for a single attribute. In this case, the attribute types are the same, but each value has a different language code. For a list of the languages supported by Directory Server and their associated language tags, see Section D.2, "Supported Locales" . Note The language tag has no effect on how the string is stored within the directory. All object class and attribute strings are stored using UTF-8. The user is responsible for converting the data used in the LDIF to UTF-8. The iconv or uconv command provided by most operating systems can be used to convert data from the native characterset into UTF-8. For example, Example Corporation has offices in the United States and France and wants employees to be able to view directory information in their native language. When adding directory entries, the directory administrator chooses to provide attribute values in both English and French. When adding a directory entry for a new employee, Babs Jensen, the administrator does the following: The administrator creates a file, street.txt , with the French street address value: The file contents are then converted to UTF-8: The following LDIF entry is created using the UTF-8 value of the street address value for streetAddress;lang-fr . The double colons after the attribute name and subtype indicate that the value is binary base-64 encoded. Users accessing this directory entry with an LDAP client with the preferred language set to English will see the address 1 University Street . Users accessing the directory with an LDAP client with the preferred language set to French will see the address 1 rue de l'Universite .

Commands:
1 rue de l'Universite
iconv -t UTF-8 -o output.txt street.txt
dn: uid=bjensen,ou=people,dc=example,dc=com objectclass: top objectclass: person objectclass: organizationalPerson name: Babs Jensen cn: Babs Jensen sn: Jensen uid: bjensen streetAddress: 1 University Street streetAddress;lang-en: 1 University Street streetAddress;lang-fr :: AasljdoaAJASI023909jaASJaonasd0ADS preferredLanguage: fr
7.8.3. Duplicate Warnings for Multipath Maps The following examples show a duplicate PV warning for two devices that are both multipath maps. In these examples we are not looking at two different paths, but two different devices. This situation is more serious than duplicate warnings for devices that are both single paths to the same device, since these warnings often mean that the machine has been presented devices which it should not be seeing (for example, LUN clones or mirrors). In this case, unless you have a clear idea of what devices should be removed from the machine, the situation could be unrecoverable. It is recommended that you contact Red Hat Technical Support to address this issue.

Commands:
Found duplicate PV GDjTZf7Y03GJHjteqOwrye2dcSCjdaUi: using **/dev/mapper/mpatha** not **/dev/mapper/mpathc**
Found duplicate PV GDjTZf7Y03GJHjteqOwrye2dcSCjdaUi: using **/dev/emcpowera** not **/dev/emcpowerh**
Chapter 9. Hardware Drivers and Devices 9.1. Virtualized Hardware Red Hat Virtualization presents three distinct types of system devices to virtualized guests. These hardware devices all appear as physically attached hardware devices to the virtualized guest but the device drivers work in different ways. Emulated devices Emulated devices, sometimes referred to as virtual devices, exist entirely in software. Emulated device drivers are a translation layer between the operating system running on the host (which manages the source device) and the operating systems running on the guests. The device level instructions directed to and from the emulated device are intercepted and translated by the hypervisor. Any device of the same type as that being emulated and recognized by the Linux kernel is able to be used as the backing source device for the emulated drivers. Para-virtualized Devices Para-virtualized devices require the installation of device drivers on the guest operating system providing it with an interface to communicate with the hypervisor on the host machine. This interface is used to allow traditionally intensive tasks such as disk I/O to be performed outside of the virtualized environment. Lowering the overhead inherent in virtualization in this manner is intended to allow guest operating system performance closer to that expected when running directly on physical hardware. Physically shared devices Certain hardware platforms allow virtualized guests to directly access various hardware devices and components. This process in virtualization is known as passthrough or device assignment. Passthrough allows devices to appear and behave as if they were physically attached to the guest operating system.

Commands:
8.3. Configure a Node with No Endpoints A standard configuration, such as a standalone high availability configuration, can be changed into a configuration for a node with no endpoints using the following steps: Remove the datagrid subsystem. Remove the modcluster subsystem. Remove the datasource definition. Remove socket-bindings for mod_cluster , Hot Rod and memcached . Removing the listed items ensure that all endpoints are removed from the configuration and that clustering is not possible. The resulting configuration is a node with no endpoints. Report a bug

Commands:
Release Notes for Streams for Apache Kafka 2.7 on RHEL Red Hat Streams for Apache Kafka 2.7 Highlights of what's new and what's changed with this release of Streams for Apache Kafka on Red Hat Enterprise Linux

Commands:
./bin/kafka-features.sh --bootstrap-server <broker_host>:<port> upgrade --metadata 3.7
client.quota.callback.class= io.strimzi.kafka.quotas.StaticQuotaCallback client.quota.callback.static.produce= 1000000 client.quota.callback.static.fetch= 1000000 client.quota.callback.static.storage.soft= 400000000000 client.quota.callback.static.storage.hard= 500000000000 client.quota.callback.static.storage.check-interval= 5
7.174. qemu-kvm 7.174.1. RHBA-2015:1275 - qemu-kvm bug fix and enhancement update Updated qemu-kvm packages that fix one bug and add various enhancements are now available for Red Hat Enterprise Linux 6. KVM (Kernel-based Virtual Machine) is a full virtualization solution for Linux on AMD64 and Intel 64 systems. The qemu-kvm packages provide the user-space component for running virtual machines using KVM. Bug Fix BZ# 1115340 When a KVM virtual machine (VM) running on a Red Hat Enterprise Linux 6 host was suspended to disk and then restored, the system time on the VM in some cases did not correctly synchronize with the system time on the host. With this update, the kvm-clock utility has been modified to reliably read the system time on the host, and the described problem no longer happens. Enhancements BZ# 1149120 Support has been added for qemu-kvm trace events during the system shutdown process, which allows users to get detailed diagnostics about systems shutdown requests issued by the "virsh shutdown" command or the virt-manager application. This provides users with enhanced capabilities for debugging KVM guest problems during shutdown. BZ# 1040220 The qemu-img tool now uses the fallocate() system call when the "preallocation=full" option is specified. This makes the preallocation operation significantly faster if "preallocation=full" is used, and thus shortens the time necessary to prepare a new guest. BZ# 1186914 With this update, qemu-kvm supports the "cache=directsync" option in the host file, which enables the use of the directsync cache mode on virtual disks. When "cache=directsync" is used, write operations on the guest are only completed when data is safely present on the disk, which increases data security during file transactions between guests. Users of qemu-kvm are advised to upgrade to these updated packages, which fix this bug and add these enhancements. After installing this update, shut down all running virtual machines. Once all virtual machines have shut down, start them again for this update to take effect.

Commands:
Chapter 9. Backing up data 9.1. Backing up storage data It is a best practice to back up the data on your persistent volume claims (PVCs) regularly. Backing up your data is particularly important before you delete a user and before you uninstall OpenShift AI, as all PVCs are deleted when OpenShift AI is uninstalled. See the documentation for your cluster platform for more information about backing up your PVCs. Additional resources Understanding persistent storage

Commands:
4.22. IF-MIB Table 4.23, "IF MIB" lists the fence device parameters used by fence_ifmib , the fence agent for IF-MIB devices. Table 4.23. IF MIB luci Field cluster.conf Attribute Description Name name A name for the IF MIB device connected to the cluster. IP Address or Hostname ipaddr The IP address or host name assigned to the device. UDP/TCP Port (optional) udpport The UDP/TCP port to use for connection with the device; the default value is 161. Login login The login name used to access the device. Password passwd The password used to authenticate the connection to the device. Password Script (optional) passwd_script The script that supplies a password for access to the fence device. Using this supersedes the Password parameter. SNMP Version snmp_version The SNMP version to use (1, 2c, 3); the default value is 1. SNMP Community community The SNMP community string. SNMP Security Level snmp_sec_level The SNMP security level (noAuthNoPriv, authNoPriv, authPriv). SNMP Authentication Protocol snmp_auth_prot The SNMP authentication protocol (MD5, SHA). SNMP Privacy Protocol snmp_priv_prot The SNMP privacy protocol (DES, AES). SNMP Privacy Protocol Password snmp_priv_passwd The SNMP privacy protocol password. SNMP Privacy Protocol Script snmp_priv_passwd_script The script that supplies a password for SNMP privacy protocol. Using this supersedes the SNMP privacy protocol password parameter. Power Wait (seconds) power_wait Number of seconds to wait after issuing a power off or power on command. Power Timeout (seconds) power_timeout Number of seconds to continue testing for a status change after issuing a power off or power on command. The default value is 20. Shell Timeout (seconds) shell_timeout Number of seconds to wait for a command prompt after issuing a command. The default value is 3. Login Timeout (seconds) login_timeout Number of seconds to wait for a command prompt after login. The default value is 5. Times to Retry Power On Operation retry_on Number of attempts to retry a power on operation. The default value is 1. Port (Outlet) Number port Physical plug number or name of virtual machine. Delay (optional) delay The number of seconds to wait before fencing is started. The default value is 0. Figure 4.17, "IF-MIB" shows the configuration screen for adding an IF-MIB fence device. Figure 4.17. IF-MIB The following command creates a fence device instance for an IF-MIB device: The following is the cluster.conf entry for the fence_ifmib device:

Commands:
ccs -f cluster.conf --addfencedev ifmib1 agent=fence_ifmib community=private ipaddr=192.168.0.1 login=root passwd=password123 snmp_priv_passwd=snmpasswd123 power_wait=60 udpport=161
<fencedevices> <fencedevice agent="fence_ifmib" community="private" ipaddr="192.168.0.1" login="root" name="ifmib1" passwd="password123" power_wait="60" snmp_priv_passwd="snmpasswd123" udpport="161"/> </fencedevices>
Chapter 6. OSD removal tool 6.1. Removing object storage devices using an automated tool OpenShift Data Foundation provides a tool to automate the process of object storage device (OSD) removal. This tool helps to avoid the possible data loss while removing OSDs. Prerequisites Install the OpenShift Data Foundation binary from the Download RedHat OpenShift Data Foundation page . Note Choose the correct Product Variant according to your architecture. Make the downloaded binary executable using chmod+x . Procedure Identify the OSD that needs to be removed. The OSD that needs removal is in CrashLoopBackOff or Error state. Example output: Run the following command to remove OSD 0 : [Optional] If removal of the OSD affects placement group (PG) status, enter yes-force-destroy-osd . Verify that the last line of the command output contains cephosd: completed removal of OSD 0 . Verify the corresponding deployment is removed:

Commands:
oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide
rook-ceph-osd-0-6d77d6c7c6-m8xj6 0/1 CrashLoopBackOff 0 24h 10.129.0.16 compute-2 <none> <none>
odf purge-osd 0
oc get deployment rook-ceph-osd-0
Chapter 11. GNOME Shell Extensions This chapter introduces system-wide configuration of GNOME Shell Extensions. You will learn how to view the extensions, how to enable them, how to lock a list of enabled extensions or how to set up several extensions as mandatory for the users of the system. You will be using dconf when configuring GNOME Shell Extensions, setting the following two GSettings keys: org.gnome.shell.enabled-extensions org.gnome.shell.development-tools For more information on dconf and GSettings , see Chapter 9, Configuring Desktop with GSettings and dconf . 11.1. What Are GNOME Shell Extensions? GNOME Shell extensions allow for the customization of the default GNOME Shell interface and its parts, such as window management and application launching. Each GNOME Shell extension is identified by a unique identifier, the uuid. The uuid is also used for the name of the directory where an extension is installed. You can either install the extension per-user in ~/.local/share/gnome-shell/extensions/ uuid , or machine-wide in /usr/share/gnome-shell/extensions/ uuid . The uuid identifier is globally-unique. When choosing it, remember that the uuid must possess the following properties to prevent certain attacks: Your uuid must not contain Unicode characters. Your uuid must not contain the gnome.org ending as it must not appear to be affiliated with the GNOME Project. Your uuid must contain only alphanumerical characters, the period (.), the at symbol (@), and the underscore (_). Important Before deploying third-party GNOME Shell extensions on Red Hat Enterprise Linux, make sure to read the following document to learn about the Red Hat support policy for third-party software: How does Red Hat Global Support Services handle third-party software, drivers, and/or uncertified hardware/hypervisors? To view installed extensions, you can use Looking Glass , GNOME Shell's integrated debugger and inspector tool. Procedure 11.1. View installed extensions Press Alt + F2 . Type in lg and press Enter to open Looking Glass . On the top bar of Looking Glass , click Extensions to open the list of installed extensions. Figure 11.1. Viewing Installed extensions with Looking Glass

Commands:
34.2.5. Controlling Access to At and Batch The /etc/at.allow and /etc/at.deny files can be used to restrict access to the at and batch commands. The format of both access control files is one username on each line. Whitespace is not permitted in either file. The at daemon ( atd ) does not have to be restarted if the access control files are modified. The access control files are read each time a user tries to execute the at or batch commands. The root user can always execute at and batch commands, regardless of the access control files. If the file at.allow exists, only users listed in it are allowed to use at or batch , and the at.deny file is ignored. If at.allow does not exist, users listed in at.deny are not allowed to use at or batch .

Commands:
Chapter 7. Checking for Local Storage Operator deployments Red Hat OpenShift Data Foundation clusters with Local Storage Operator are deployed using local storage devices. To find out if your existing cluster with OpenShift Data Foundation was deployed using local storage devices, use the following procedure: Prerequisites OpenShift Data Foundation is installed and running in the openshift-storage namespace. Procedure By checking the storage class associated with your OpenShift Data Foundation cluster's persistent volume claims (PVCs), you can tell if your cluster was deployed using local storage devices. Check the storage class associated with OpenShift Data Foundation cluster's PVCs with the following command: Check the output. For clusters with Local Storage Operator, the PVCs associated with ocs-deviceset use the storage class localblock . The output looks similar to the following: Additional Resources Deploying OpenShift Data Foundation using local storage devices on VMware Deploying OpenShift Data Foundation using local storage devices on Red Hat Virtualization Deploying OpenShift Data Foundation using local storage devices on bare metal Deploying OpenShift Data Foundation using local storage devices on IBM Power

Commands:
oc get pvc -n openshift-storage
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE db-noobaa-db-0 Bound pvc-d96c747b-2ab5-47e2-b07e-1079623748d8 50Gi RWO ocs-storagecluster-ceph-rbd 114s ocs-deviceset-0-0-lzfrd Bound local-pv-7e70c77c 1769Gi RWO localblock 2m10s ocs-deviceset-1-0-7rggl Bound local-pv-b19b3d48 1769Gi RWO localblock 2m10s ocs-deviceset-2-0-znhk8 Bound local-pv-e9f22cdc 1769Gi RWO localblock 2m10s
14.5.16. Using blockpull to Shorten a Backing Chain blockpull can be used in in the following applications: Flattens an image by populating it with data from its backing image chain. This makes the image file self-contained so that it no longer depends on backing images and looks like this: Before: base.img <- Active After: base.img is no longer used by the guest and Active contains all of the data. Flattens part of the backing image chain. This can be used to flatten snapshots into the top-level image and looks like this: Before: base <- sn1 <-sn2 <- active After: base.img <- active. Note that active now contains all data from sn1 and sn2 and neither sn1 nor sn2 are used by the guest. Moves the disk image to a new file system on the host. This is allows image files to be moved while the guest is running and looks like this: Before (The original image file): /fs1/base.vm.img After: /fs2/active.vm.qcow2 is now the new file system and /fs1/base.vm.img is no longer used. Useful in live migration with post-copy storage migration. The disk image is copied from the source host to the destination host after live migration completes. In short this is what happens: Before: /source-host/base.vm.img After: /destination-host/active.vm.qcow2 . /source-host/base.vm.img is no longer used. Procedure 14.3. Using blockpull to Shorten a Backing Chain It may be helpful to run this command prior to running blockpull : If the chain looks like this: base <- snap1 <- snap2 <- active run the following: This command makes 'snap1' the backing file of active, by pulling data from snap2 into active resulting in: base <- snap1 <- active. Once the blockpull is complete, the libvirt tracking of the snapshot that created the extra image in the chain is no longer useful. Delete the tracking on the outdated snapshot with this command: Additional applications of blockpull can be done as follows: To flatten a single image and populate it with data from its backing image chain: # virsh blockpull example-domain vda - wait To flatten part of the backing image chain: # virsh blockpull example-domain vda - base /path/to/base.img - wait To move the disk image to a new file system on the host: # virsh snapshot-create example-domain e - xmlfile /path/to/new.xml - disk-only followed by # virsh blockpull example-domain vda - wait To use live migration with post-copy storage migration: On the destination run: On the source run: On the destination run:

Commands:
virsh snapshot-create-as USDdom USDname - disk-only
virsh blockpull USDdom USDdisk snap1
virsh snapshot-delete USDdom USDname - metadata
qemu-img create -f qcow2 -o backing_file=/source-host/vm.img /destination-host/vm.qcow2
virsh migrate example-domain
virsh blockpull example-domain vda - wait