mtpti5iD/redhat-docs_dataset huggingface dataset:
8.2. Multi-State Resources: Resources That Have Multiple Modes Multi-state resources are a specialization of Clone resources. They allow the instances to be in one of two operating modes; these are called Master and Slave . The names of the modes do not have specific meanings, except for the limitation that when an instance is started, it must come up in the Slave state. You can create a resource as a master/slave clone with the following single command. The name of the master/slave clone will be resource_id -master . Alternately, you can create a master/slave resource from a previously-created resource or resource group with the following command: When you use this command, you can specify a name for the master/slave clone. If you do not specify a name, the name of the master/slave clone will be resource_id -master or group_name -master . For information on resource options, see Section 5.1, "Resource Creation" . Table 8.2, "Properties of a Multi-State Resource" describes the options you can specify for a multi-state resource. Table 8.2. Properties of a Multi-State Resource Field Description id Your name for the multi-state resource priority , target-role , is-managed See Table 5.3, "Resource Meta Options" . clone-max , clone-node-max , notify , globally-unique , ordered , interleave See Table 8.1, "Resource Clone Options" . master-max How many copies of the resource can be promoted to master status; default 1. master-node-max How many copies of the resource can be promoted to master status on a single node; default 1. 8.2.1. Monitoring Multi-State Resources To add a monitoring operation for the master resource only, you can add an additional monitor operation to the resource. Note, however, that every monitor operation on a resource must have a different interval. The following example configures a monitor operation with an interval of 11 seconds on the master resource for ms_resource . This monitor operation is in addition to the default monitor operation with the default monitor interval of 10 seconds.

Commands:
pcs resource create resource_id standard:provider:type | type [ resource options ] --master [meta master_options ]
pcs resource master master/slave_name resource_id|group_name [ master_options ]
pcs resource op add ms_resource interval=11s role=Master
Preface Providing feedback on Red Hat documentation We appreciate your feedback on our documentation. To provide feedback, highlight text in a document and add comments. Prerequisites You are logged in to the Red Hat Customer Portal. In the Red Hat Customer Portal, the document is in the HTML viewing format. Procedure To provide your feedback, perform the following steps: Click the Feedback button in the top-right corner of the document to see existing feedback. Note The feedback feature is enabled only in the HTML format. Highlight the section of the document where you want to provide feedback. Click the Add Feedback pop-up that appears near the highlighted text. A text box appears in the feedback section on the right side of the page. Enter your feedback in the text box and click Submit . A documentation issue is created. To view the issue, click the issue link in the feedback view.

Commands:
Chapter 6. Virtual Databases 6.1. VDB Definition A VDB or virtual database definition is contained in an XML file. For .vdb archive files created in the design tool, this file is embedded in the archive and most fields can be updated through tooling. The XML schema for this file can be found in the EAP_HOME /docs/teiid/schema directory. Example 6.1. Example VDB XML

Commands:
<vdb name="USD{vdb-name}" version="USD{vdb-version}"> <!-- VDB properties --> <property name="USD{property-name}" value="USD{property-value}" /> <!-- UDF defined in an AS module, see Developers Guide --> <property name ="lib" value ="{module-name}"></property> <import-vdb name="..." version="..." import-data-policies="true|false"/> <!-- define a model fragment for each data source --> <model visible="true" name="USD{model-name}" type="USD{model-type}" > <property name="..." value="..." /> <source name="USD{source-name}" translator-name="USD{translator-name}" connection-jndi-name="USD{deployed-jndi-name}"> <metadata type="USD{repository-type}">raw text</metadata> </model> <!-- define a model with multiple sources - see Multi-Source Models --> <model name="USD{model-name}" path="/Test/Customers.xmi"> <property name="multisource" value="true"/> . . . <source name="USD{source-name}" translator-name="USD{translator-name}" connection-jndi-name="USD{deployed-jndi-name}"/> <source . . . /> <source . . . /> </model> <!-- see Reference Guide - Data Roles --> <data-role name="USD{role-name}"> <description>USD{role-description}</description> . . . </data-role> <!-- create translator instances that override default properties --> <translator name="USD{translator-name}" type="USD{translator-type}" /> <property name="..." value="..." /> </translator> </vdb>
D.3. Supported Language Subtypes Language subtypes can be used by clients to determine specific values for which to search. For more information on using language subtypes, see Section 3.1.9, "Updating an Entry in an Internationalized Directory" . Table D.1, "Supported Language Subtypes" lists the supported language subtypes for Directory Server. Table D.1. Supported Language Subtypes Language Tag Language af Afrikaans be Belarusian bg Bulgarian ca Catalan cs Czech da Danish de German el Greek en English es Spanish eu Basque fi Finnish fo Faroese fr French ga Irish gl Galician hr Croatian hu Hungarian id Indonesian is Icelandic it Italian ja Japanese ko Korean nl Dutch no Norwegian pl Polish pt Portuguese ro Romanian ru Russian sk Slovak sl Slovenian sq Albanian sr Serbian sv Swedish tr Turkish uk Ukrainian zh Chinese

Commands:
7.4. Displaying Constraints There are a several commands you can use to display constraints that have been configured. The following command lists all current location, order, and colocation constraints. The following command lists all current location constraints. If resources is specified, location constraints are displayed per resource. This is the default behavior. If nodes is specified, location constraints are displayed per node. If specific resources or nodes are specified, then only information about those resources or nodes is displayed. The following command lists all current ordering constraints. If the --full option is specified, show the internal constraint IDs. The following command lists all current colocation constraints. If the --full option is specified, show the internal constraint IDs. The following command lists the constraints that reference specific resources.

Commands:
pcs constraint list|show
pcs constraint location [show resources|nodes [ specific nodes | resources ]] [--full]
pcs constraint order show [--full]
pcs constraint colocation show [--full]
pcs constraint ref resource
23.7. Serving PTP Time With NTP The ntpd daemon can be configured to distribute the time from the system clock synchronized by ptp4l or phc2sys by using the LOCAL reference clock driver. To prevent ntpd from adjusting the system clock, the ntp.conf file must not specify any NTP servers. The following is a minimal example of ntp.conf : Note When the DHCP client program, dhclient , receives a list of NTP servers from the DHCP server, it adds them to ntp.conf and restarts the service. To disable that feature, add PEERNTP=no to /etc/sysconfig/network .

Commands:
~]# cat /etc/ntp.conf server 127.127.1.0 fudge 127.127.1.0 stratum 0
19.2. Viewing Password Policies There can be multiple password policies configured in IdM. There is always a global policy, which is set when the server is created. Additional policies can be created for groups in IdM. The UI lists all of the group password policies and the global policy on the Password Policies page. Using the CLI, both global and group-level password policies can be viewed using the pwpolicy-show command. The CLI can also display the password policy in effect for a user. 19.2.1. Viewing the Global Password Policy The global password policy is created as part of the initial IdM server setup. This policy applies to every user until a group-level password policy supersedes it. The default settings for the global password policy are listed in Table 19.2, "Default Global Password Policy" . Table 19.2. Default Global Password Policy Attribute Value Max lifetime 90 (days) Min lifetime 1 (hour) History size 0 (unset) Character classes 0 (unset) Min length 8 Max failures 6 Failure reset interval 60 Lockout duration 600 19.2.1.1. With the Web UI Click the Policy tab, and then click the Password Policies subtab. All of the policies in the UI are listed by group. The global password policy is defined by the global_policy group. Click the group link. The global policy is displayed. 19.2.1.2. With the Command Line To view the global policy, simply run the pwpolicy-show command with no arguments: 19.2.2. Viewing Group-Level Password Policies 19.2.2.1. With the Web UI Click the Policy tab, and then click the Password Policies subtab. All of the policies in the UI are listed by group. Click the name of the group which is assigned the policy. The group policy is displayed. 19.2.2.2. With the Command Line For a group-level password policy, specify the group name with the command: 19.2.3. Viewing the Password Policy in Effect for a User A user may belong to multiple groups, each with their own separate password policies. These policies are not additive. Only one policy is in effect at a time and it applies to all password policy attributes. To see which policy is in effect for a specific user, the pwpolicy-show command can be run for a specific user. The results also show which group policy is in effect for that user.

Commands:
kinit admin ipa pwpolicy-show Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600
kinit admin ipa pwpolicy-show ipausers Group: ipausers Max lifetime (days): 120 Min lifetime (hours): 10 Min length: 10 Priority: 50
kinit admin ipa pwpolicy-show --user=jsmith Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600
2.3. Install OpenJDK on Red Hat Enterprise Linux Procedure 2.1. Install OpenJDK on Red Hat Enterprise Linux Subscribe to the Base Channel Obtain the OpenJDK from the RHN base channel. Your installation of Red Hat Enterprise Linux is subscribed to this channel by default. Install the Package Use the yum utility to install OpenJDK: Verify that OpenJDK is the System Default Ensure that the correct JDK is set as the system default as follows: Log in as a user with root privileges and run the alternatives command: Depending on the OpenJDK version, select /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java or /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java . Use the following command to set javac : Depending on the OpenJDK version used, select /usr/lib/jvm/java-1.6.0-openjdk/bin/java or /usr/lib/jvm/java-1.7.0-openjdk/bin/java . 23154%2C+Getting+Started+Guide-6.608-09-2016+09%3A22%3A31JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
sudo yum install java-1.6.0-openjdk-devel
/usr/sbin/alternatives --config java
/usr/sbin/alternatives --config javac
7.102. kdepim 7.102.1. RHBA-2012:1287 - kdepim bug fix update Updated kdepim packages that fix one bug are now available for Red Hat Enterprise Linux 6. The KDE Personal Information Management (kdepim) suite helps to organize your mail, tasks, appointments, and contacts. Bug Fix BZ# 811125 Prior to this update, the cyrus-sasl-plain package was not a dependency of the kdepim package. As a consequence, Kmail failed to send mail. This update modifies the underlying code to include the cyrus-sasl-plain dependency. All users of kdepim are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 20. Identifying virtual devices with tags 20.1. Overview of virtual device tagging If you launch an instance with multiple network interfaces or block devices, you can use device tagging to communicate the intended role of each device to the instance operating system. Tags are assigned to devices at instance boot time, and are available to the instance operating system through the metadata API and the configuration drive (if enabled). The tags are set using the following parameters: --block-device tag=device metadata --nic tag=device metadata 20.2. Tagging virtual devices To tag virtual devices, use the tag parameters, --block-device and --nic , when creating instances. Here is an example: The resulting tags are added to the existing instance metadata and are available through both the metadata API, and on the configuration drive. In this example, the following devices section populates the metadata: Sample contents of the meta_data.json file: The device tag metadata is available using GET /openstack/latest/meta_data.json from the metadata API. If the configuration drive is enabled, and mounted under /configdrive in the instance operating system, the metadata is also present in /configdrive/openstack/latest/meta_data.json .

Commands:
nova boot test-vm --flavor m1.tiny --image cirros --nic net-id=55411ca3-83dd-4036-9158-bf4a6b8fb5ce,tag=nfv1 --block-device id=b8c9bef7-aa1d-4bf4-a14d-17674b370e13,bus=virtio,tag=database-server NFVappServer
{ "devices": [ { "type": "nic", "bus": "pci", "address": "0030:00:02.0", "mac": "aa:00:00:00:01", "tags": ["nfv1"] }, { "type": "disk", "bus": "pci", "address": "0030:00:07.0", "serial": "disk-vol-227", "tags": ["database-server"] } ] }
8.4.2. Guest Node Resource Options When configuring a virtual machine or LXC resource to act as a guest node, you create a VirtualDomain resource, which manages the virtual machine. For descriptions of the options you can set for a VirtualDomain resource, use the following command. In addition to the VirtualDomain resource options, you can configure metadata options to both enable the resource as a guest node and define the connection parameters. Table 8.4, "Metadata Options for Configuring KVM/LXC Resources as Remote Nodes" describes these metadata options. Table 8.4. Metadata Options for Configuring KVM/LXC Resources as Remote Nodes Field Default Description remote-node <none> The name of the guest node this resource defines. This both enables the resource as a guest node and defines the unique name used to identify the guest node. WARNING : This value cannot overlap with any resource or node IDs. remote-port 3121 Configures a custom port to use for the guest connection to pacemaker_remote . remote-addr remote-node value used as host name The IP address or host name to connect to if remote node's name is not the host name of the guest remote-connect-timeout 60s Amount of time before a pending guest connection will time out

Commands:
pcs resource describe VirtualDomain
Deploying OpenShift Data Foundation using IBM Z Red Hat OpenShift Data Foundation 4.13 Instructions on deploying Red Hat OpenShift Data Foundation to use local storage on IBM Z Red Hat Storage Documentation Team Abstract Read this document for instructions about how to install Red Hat OpenShift Data Foundation to use local storage on IBM Z. Note While this document refers only to IBM Z, all information in it also applies to IBM(R) LinuxONE.

Commands:
Migrating from a standalone Manager to a self-hosted engine Red Hat Virtualization 4.4 How to migrate the Red Hat Virtualization Manager from a standalone server to a self-managed virtual machine Red Hat Virtualization Documentation Team Red Hat Customer Content Services rhev-docs@redhat.com Abstract This document describes how to migrate your Red Hat Virtualization environment from a Manager installed on a physical server (or a virtual machine running in a separate environment) to a Manager installed on a virtual machine running on the same hosts it manages.

Commands:
Appendix B. Understanding the gluster_volume_inventory.yml file The gluster_volume_inventory.yml inventory file is an example file that you can use to create logical volume from the existing volume group if free space is available. You can create this file at /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/gluster_volume_inventory.yml B.1. Configuration parameters for creating logical volumes hosts Backend network FQDN of the hyperconverged hosts. Mention the same set of host names under cluster_nodes section. vgname The name of the existing volume group (VG) on the host. gluster_infra_disktype Disk Aggregation Type. Values taken: RAID6 RAID5 JBOD gluster_infra_diskcount Number of data disks in the RAID set. For JBOD the value is 1. gluster_infra_stripe_unit_size RAID stripe size. Ignore this parameter for JBOD. Example gluster_volume_inventory file

Commands:
hosts: <host1-backend-FQDN>: <host2-backend-FQDN>: <host3-backend-FQDN>:
hc_nodes: hosts: host1-backend.example.com: host2-backend.example.com: host3-backend.example.com: # Common configurations vars: gluster_infra_volume_groups: - vgname: gluster_vg_sdb pvname: /dev/sdb gluster_infra_mount_devices: - path: /gluster_bricks/newengine lvname: gluster_lv_newengine vgname: gluster_vg_sdb gluster_infra_thick_lvs: - vgname: gluster_vg_sdb lvname: gluster_lv_newengine size: 100G gluster_infra_disktype: RAID6 gluster_infra_diskcount: 10 gluster_infra_stripe_unit_size: 256 gluster_features_force_varlogsizecheck: false gluster_set_selinux_labels: true cluster_nodes: - host1-backend.example.com - host2-backend.example.com - host3-backend.example.com gluster_features_hci_cluster: "{{ cluster_nodes }}" gluster_features_hci_volumes: - volname: newengine brick: /gluster_bricks/newengine/newengine arbiter: 0
7.6. Importing Templates 7.6.1. Importing a Template into a Data Center Note The export storage 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. See the Importing Existing Storage Domains section in the Red Hat Virtualization Administration Guide for information on importing storage domains. Import templates from a newly attached export domain. This procedure requires access to the Administration Portal. Importing a Template into a Data Center Click Storage Domains and select the newly attached export domain. Click the domain name to go to the details view. Click the Template Import tab and select a template. Click Import . Use the drop-down lists to select the Target Cluster and CPU Profile . Select the template to view its details, then click the Disks tab and select the Storage Domain to import the template into. Click OK . If the Import Template Conflict window appears, enter a New Name for the template, or select the Apply to all check box and enter a Suffix to add to the cloned Templates . Click OK . Click Close . The template is imported into the destination data center. This can take up to an hour, depending on your storage hardware. You can view the import progress in the Events tab. Once the importing process is complete, the templates will be visible in Compute Templates . The templates can create new virtual machines, or run existing imported virtual machines based on that template. 7.6.2. Importing a Virtual Disk from an OpenStack Image Service as a Template Virtual disks managed by an OpenStack Image Service can be imported into the Red Hat Virtualization Manager if that OpenStack Image Service has been added to the Manager as an external provider. This procedure requires access to the Administration Portal. Click Storage Domains and select the OpenStack Image Service domain. Click the storage domain name to go to the details view. Click the Images tab and select the image to import. Click Import . Note If you are importing an image from a Glance storage domain, you have the option of specifying the template name. Select the Data Center into which the virtual disk will be imported. Select the storage domain in which the virtual disk will be stored from the Domain Name drop-down list. Optionally, select a Quota to apply to the virtual disk. Select the Import as Template check box. Select the Cluster in which the virtual disk will be made available as a template. Click OK . The image is imported as a template and is displayed in the Templates tab. You can now create virtual machines based on the template.

Commands:
5.4. Data Center and Cluster Compatibility Levels Red Hat Virtualization data centers and clusters have a compatibility version. The data center compatibility version indicates the version of Red Hat Virtualization that the data center is intended to be compatible with. All clusters in the data center must support the desired compatibility level. The cluster compatibility version indicates the features of Red Hat Virtualization supported by all of the hosts in the cluster. The cluster compatibility is set according to the version of the least capable host operating system in the cluster. The table below provides a compatibility matrix of RHV versions and the required data center and cluster compatibility levels. Table 5.4. Data center and cluster levels supported with Red Hat Virtualization Compatibility Level RHV Version Description 4.7 4.4 Compatibility Level 4.7 was introduced in RHV 4.4 to support new features introduced by RHEL 8.6 hypervisors. 4.6 4.4.6 Compatibility Level 4.6 was introduced in RHV 4.4.6 to support new features introduced by RHEL 8.4 hypervisors with Advanced Virtualization 8.4 packages. 4.5 4.4.3 Compatibility Level 4.5 was introduced in RHV 4.4.3 to support new features introduced by RHEL 8.3 hypervisors with Advanced Virtualization 8.3 packages. Limitations Virtio NICs are enumerated as a different device after upgrading the cluster compatibility level to 4.6. Therefore, the NICs might need to be reconfigured. Red Hat recommends that you test the virtual machines before you upgrade the cluster by setting the cluster compatibility level to 4.6 on the virtual machine and verifying the network connection. If the network connection for the virtual machine fails, configure the virtual machine with a custom emulated machine that matches the current emulated machine, for example pc-q35-rhel8.3.0 for 4.5 compatibility version, before upgrading the cluster.

Commands:
5.299. servicelog 5.299.1. RHBA-2012:0989 - servicelog bug fix update Updated servicelog packages that fix one bug are now available for Red Hat Enterprise Linux 6. The servicelog packages provide a relational database to help manage errors on IBM eServer System p machines. Firmware and device driver errors are logged and managed using this database, which provides advanced error management capabilities. Bug Fix BZ# 814160 Prior to this update, the "servicelog_manage -help" option returned a Null value instead of a help message. Also, repair actions were not properly deleted. This update modifies the underlying code so that a more informative help message is returned and repair actions are deleted along with regular events. All users of servicelog are advised to upgrade to these updated packages, which fix this bug.

Commands:
6.3. Enabling vhost-net zero-copy In Red Hat Enterprise Linux 7, vhost-net zero-copy is disabled by default. To enable this action on a permanent basis, add a new file vhost-net.conf to /etc/modprobe.d with the following content: If you want to disable this again, you can run the following: The first command removes the old file, the second one makes a new file (like above) and disables zero-copy. You can use this to enable as well but the change will not be permanent. To confirm that this has taken effect, check the output of cat /sys/module/vhost_net/parameters/experimental_zcopytx . It should show:

Commands:
options vhost_net experimental_zcopytx=1
modprobe -r vhost_net
modprobe vhost_net experimental_zcopytx=0
cat /sys/module/vhost_net/parameters/experimental_zcopytx 0