mtpti5iD/redhat-docs_dataset huggingface dataset:
B.13. Migration Fails with Error: unable to resolve address Symptom QEMU guest migration fails and this error message appears: For example, if the destination host name is "newyork", the error message will appear as: However, this error looks strange as we did not use "newyork" host name anywhere. Investigation During migration, libvirtd running on the destination host creates a URI from an address and port where it expects to receive migration data and sends it back to libvirtd running on the source host. In this case, the destination host ( 192.168.122.12 ) has its name set to 'newyork' . For some reason, libvirtd running on that host is unable to resolve the name to an IP address that could be sent back and still be useful. For this reason, it returned the 'newyork' host name hoping the source libvirtd would be more successful with resolving the name. This can happen if DNS is not properly configured or /etc/hosts has the host name associated with local loopback address ( 127.0.0.1 ). Note that the address used for migration data cannot be automatically determined from the address used for connecting to destination libvirtd (for example, from qemu+tcp://192.168.122.12/system ). This is because to communicate with the destination libvirtd , the source libvirtd may need to use network infrastructure different from that which virsh (possibly running on a separate machine) requires. Solution The best solution is to configure DNS correctly so that all hosts involved in migration are able to resolve all host names. If DNS cannot be configured to do this, a list of every host used for migration can be added manually to the /etc/hosts file on each of the hosts. However, it is difficult to keep such lists consistent in a dynamic environment. If the host names cannot be made resolvable by any means, virsh migrate supports specifying the migration host: Destination libvirtd will take the tcp://192.168.122.12 URI and append an automatically generated port number. If this is not desirable (because of firewall configuration, for example), the port number can be specified in this command: Another option is to use tunnelled migration. Tunnelled migration does not create a separate connection for migration data, but instead tunnels the data through the connection used for communication with destination libvirtd (for example, qemu+tcp://192.168.122.12/system ):

Commands:
virsh migrate qemu qemu+tcp://192.168.122.12/system error: Unable to resolve address name_of_host service '49155': Name or service not known
virsh migrate qemu qemu+tcp://192.168.122.12/system error: Unable to resolve address 'newyork' service '49155': Name or service not known
virsh migrate qemu qemu+tcp://192.168.122.12/system tcp://192.168.122.12
virsh migrate qemu qemu+tcp://192.168.122.12/system tcp://192.168.122.12:12345
virsh migrate qemu qemu+tcp://192.168.122.12/system --p2p --tunnelled
Appendix D. Revision History Revision History Revision 2-9.402 Fri Oct 25 2013 Rudiger Landmann Rebuild with Publican 4.0.0 Revision 2-9 2012-07-18 Anthony Towns Rebuild for Publican 3.0 Revision 1-0 Wed Sep 17 2008 Don Domingo migrated to new automated build system

Commands:
7.107. libqb 7.107.1. RHBA-2015:1281 - libqb bug fix and enhancement update Updated libqb packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The libqb packages provide a library with the primary purpose of providing high performance client server reusable features, such as high performance logging, tracing, inter-process communication, and polling. Note The libqb packages have been upgraded to upstream version 0.17.1, which provides a number of bug fixes and enhancements over the version. One of the notable changes gives components consuming inter-process communication (IPC) API of libqb more control over IPC buffer sizes. The ability to utilize larger buffer sizes in a consistent way between the IPC client and server allows pacemaker to scale much further in the number of resources the cluster can manage. (BZ# 1110042 ) Users of libqb are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 9. Configuring JBoss EAP for Microsoft Azure This chapter describes the configurations required for JBoss EAP to run in Microsoft Azure. 9.1. Starting JBoss EAP as a service at boot on Red Hat Enterprise Linux If you are starting JBoss EAP as a service on Red Hat Enterprise Linux in Microsoft Azure, you must change the configuration of the JBoss EAP service to ensure that it starts after the Azure virtual machine host name has been initialized. Procedure Update the /etc/systemd/system/multi-user.target.wants/eap8-standalone.service file to add a dependency on waagent.service . Replace the following line: with this line: 9.2. Configuration for load balancing with mod_cluster in Microsoft Azure As a result of mod_cluster advertising not being supported in Azure , if you are configuring a JBoss EAP load balancing environment, you must ensure that all balancers and workers are bound to IP addresses that are accessible on your internal Microsoft Azure virtual network. Note Balancers and workers must be bound to the actual internal Azure virtual IP address, for example 172.28.0.2 , and not 0.0.0.0 . Additionally, because of the unavailability of mod_cluster advertising, if you are using JBoss EAP as an Undertow mod_cluster proxy load balancer, you must configure each worker node to use a proxy list containing each balancer's IP address and port, as shown below: 9.3. Configuration for ActiveMQ Artemis high availability in Microsoft Azure JBoss EAP messaging high availability using Artemis shared stores is not supported in Microsoft Azure. To configure JBoss EAP messaging high availability in Azure, you must use a replicated journal with the AZURE_PING JGroups discovery protocol using a TCP JGroups stack. For more information on using a replicated journal, see Data Replication in Configuring Messaging for JBoss EAP. After configuring the TCP JGroups stack with AZURE_PING, you must add the JGroups stack to the discovery-group and broadcast-group jgroups-cluster configurations in the messaging-activemq subsystem. For details, see Server Discovery in Configuring Messaging for JBoss EAP.

Commands:
After=syslog.target network.target
After=syslog.target network.target waagent.service Requires=waagent.service
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding= proxy-one :add(host=" BALANCER_IP_ADDRESS ", port=" BALANCER_PORT ") /subsystem=modcluster/mod-cluster-config=configuration:list-add(name=proxies,value= proxy-one )
Chapter 15. Post-deployment configuration suggestions Depending on your requirements, you may want to perform some additional configuration on your newly deployed Red Hat Hyperconverged Infrastructure for Virtualization. This section contains suggested steps for additional configuration. Details on these processes are available in Maintaining Red Hat Hyperconverged Infrastructure for Virtualization . 15.1. Configure notifications See Configuring Event Notifications in the Administration Portal to configure email notifications. 15.2. (Optional)Configure Host Power Management The Red Hat Virtualization Manager 4.4 is capable of rebooting hosts that have entered a non-operational or non-responsive state, as well as preparing to power off under-utilized hosts to save power. This functionality depends on a properly configured power management device. See Configuring Host Power Management Settings for further information. 15.3. Configure backup and recovery options Red Hat recommends configuring at least basic disaster recovery capabilities on all production deployments. See Configuring backup and recovery options in Maintaining Red Hat Hyperconverged Infrastructure for Virtualization for more information.

Commands:
9.6. Unlocking User Accounts After Password Failures If a user attempts to log in and uses the wrong password a certain number of times, then that user account is locked. The exact number of failed attempts that locks an account and the duration of the lockout is defined as part of the password policy ( Section 19.6, "Setting Account Lockout Policies" ). A password policy can implicitly define a reset period, where the account unlocks naturally after a certain amount of time lapses. However, if the duration is fairly long or if the deployment requires stronger security checks before unlocking an account, then an administrator can unlock an account manually. An account is unlocked using the user-unlock command. For example:

Commands:
[bjensen@ipaserver ~]USD kinit admin [bjensen@ipaserver ~]USD ipa user-unlock jsmith
Chapter 5. Starting to use Red Hat Quay With Red Hat Quay now running, you can: Select Tutorial from the Quay home page to try the 15-minute tutorial. In the tutorial, you learn to log into Quay, start a container, create images, push repositories, view repositories, and change repository permissions with Quay. Refer to the Use Red Hat Quay for information on working with Red Hat Quay repositories.

Commands:
Chapter 10. Connecting Bluetooth devices You can wirelessly connect Bluetooth devices like keyboards, mouse, headsets, and other Bluetooth supported devices to your Red Hat Enterprise Linux system. Bluetooth settings in the GNOME desktop environment provide an interface to discover, pair, and manage your Bluetooth devices. You can connect Bluetooth devices using the graphical user interface and the bluetoothctl command-line utility. 10.1. Connecting Bluetooth devices with GUI Connect your Bluetooth devices from the Settings application in the GNOME desktop environment. Prerequisite The bluetooth.service unit is enabled. Procedure On your Red Hat Enterprise Linux, go to Settings > Bluetooth . Toggle the button at the top-right corner to switch ON the Bluetooth. Your system automatically starts scanning for nearby discoverable devices. Put the device you want to connect within range of your system into pairing mode. When your device is discovered, click on it and follow the on-screen instructions to pair. Optional : Verify the PIN between your Bluetooth device and your system. Click Confirm . Note The devices you previously paired might connect automatically when they are turned on and within range. Verification When your device is connected, click on it. You can verify connection status, device type, physical address, and other information of your device. 10.2. Connecting Bluetooth devices with bluetoothctl bluetoothctl is a command-line utility to scan for, pair, connect, and manage connections without relying on a graphical user interface. Prerequisite The bluetooth.service unit is enabled. Procedure Enter into the bluetoothctl interactive prompt: Check the status of Bluetooth on your system: If bluetoothctl is not powered on, enter: Set the device you want to connect within range of your system into pairing mode and make your system discoverable and pairable: Start scanning for Bluetooth devices: The list of discovered devices is displayed with their MAC addresses and names (if available). When you find your device, stop scanning: Note the MAC address of the device you want to connect. Pair the device: You might be prompted to confirm a pairing code on your system. Trust the device you paired: Optional : If you want this device to automatically connect in the future, you can set it as the default: Quit bluetoothctl when you are done: Verification Verify the status of device you connected:

Commands:
bluetoothctl
show Powered: no Discoverable: no DiscoverableTimeout: 0x000000b4 Pairable: no
power on
discoverable on
pairable on
scan on
scan off
pair XX:XX:XX:XX:XX:XX
trust XX:XX:XX:XX:XX:XX
default XX:XX:XX:XX:XX:XX
quit
devices Device AA:BB:CC:DD:EE:FF Headphones (Connected: yes) Device 11:22:33:44:55:66 Keyboard (Connected: no)
info AA:BB:CC:DD:EE:FF <device information> Connected: yes
Chapter 2. Logging in to OpenShift AI After you install OpenShift AI, log in to the OpenShift AI dashboard so that you can set up your development and deployment environment. Prerequisites You know the OpenShift AI identity provider and your login credentials. If you are a data scientist, data engineer, or ML engineer, your administrator must provide you with the OpenShift AI instance URL, for example: You have the latest version of one of the following supported browsers: Google Chrome Mozilla Firefox Safari Procedure Browse to the OpenShift AI instance URL and click Log in with OpenShift . If you have access to OpenShift, you can browse to the OpenShift web console and click the Application Launcher ( ) Red Hat OpenShift AI . Click the name of your identity provider, for example, GitHub , Google , or your company's single sign-on method. Enter your credentials and click Log in (or equivalent for your identity provider). Verification The OpenShift AI dashboard opens on the Home page.

Commands:
https://rhoai-dashboard-redhat-oai-applications.apps.example.abc1.p1.openshiftapps.com/
Chapter 3. Role-Based Parameters You can modify the bevavior of specific overcloud composable roles with overcloud role-based parameters. Substitute _ROLE_ with the name of the role. For example, for _ROLE_Count use ControllerCount . Parameter Description _ROLE_AnyErrorsFatal Sets the any_errors_fatal value when running config-download Ansible playbooks. The default value is True . _ROLE_ControlPlaneSubnet Name of the subnet on ctlplane network for this role. The default value is ctlplane-subnet . _ROLE_Count The number of nodes to deploy in a role. The default value is 1 . _ROLE_ExtraConfig Role specific additional hiera configuration to inject into the cluster. _ROLE_ExtraGroupVars Optional extra Ansible group vars. _ROLE_HostnameFormat Format for node hostnames. Note that %index% is translated into the index of the node (e.g 0/1/2) and %stackname% is replaced with the stack name (e.g overcloud ). The default value is %stackname%-_role_-%index% . _ROLE_MaxFailPercentage Sets the max_fail_percentage value when running config-download Ansible playbooks. The default value is 0 . _ROLE_NetworkDeploymentActions OpenStack Orchestration (heat) action when to apply network configuration changes. _ROLE_Parameters Optional Role Specific parameters to be provided to service. _ROLE_RemovalPolicies List of resources to be removed from the role's ResourceGroup when doing an update that requires removal of specific resources. _ROLE_RemovalPoliciesMode How to handle change to RemovalPolicies for ROLE ResourceGroup when doing an update. Default mode append will append to the existing blocklist and update would replace the blocklist. The default value is append . _ROLE_SchedulerHints Optional scheduler hints to pass to OpenStack Compute (nova). _ROLE_ServiceNetMap Role specific ServiceNetMap overrides, the map provided will be merged with the global ServiceNetMap when passing the ServiceNetMap to the ROLE_ServiceChain resource and the _ROLE resource group. For example: _ROLE_ServiceNetMap: NovaLibvirtNetwork: internal_api_leaf2. _ROLE_Services A list of service resources (configured in the OpenStack Orchestration (heat) resource_registry) which represent nested stacks for each service that should get installed on the ROLE role.

Commands:
Chapter 4. Configuration This chapter provides the necessary information about the Camel Subsystem and Deployment Configuration. Camel Subsystem Configuration The Camel Subsystem Configuration may contain static system routes. However, the system starts the route automatically. <subsystem xmlns="urn:jboss:domain:camel:1.0"> <camelContext id="system-context-1"> <![CDATA[ <route> <from uri="direct:start"/> <transform> <simple>Hello #{body}</simple> </transform> </route> ]]> </camelContext> </subsystem> Camel Deployment Configuration If you want to modify the default configuration of your Camel deployment, you can edit either the WEB-INF/jboss-all.xml or META-INF/jboss-all.xml configuration file in your deployment. Use a <jboss-camel> XML element within the jboss-all.xml file to control the camel configuration. Disabling the Camel Subsystem If you do not want to add the camel subsystem into your deployment, set the enabled="false" attribute on the jboss-camel XML element. Example jboss-all.xml file: <jboss umlns="urn:jboss:1.0"> <jboss-camel xmlns="urn:jboss:jboss-camel:1.0" enabled="false"/> </jboss> Selecting Components If you add nested <component> or <component-module> XML elements, then instead of adding the default list of Camel components to your deployment, only the specified components will be added to your deployment. Example jboss-all.xml file: <jboss umlns="urn:jboss:1.0"> <jboss-camel xmlns="urn:jboss:jboss-camel:1.0"> <component name="camel-ftp"/> <component-module name="org.apache.camel.component.rss"/> </jboss-camel> </jboss>

Commands:
<subsystem xmlns="urn:jboss:domain:camel:1.0"> <camelContext id="system-context-1"> <![CDATA[ <route> <from uri="direct:start"/> <transform> <simple>Hello #{body}</simple> </transform> </route> ]]> </camelContext> </subsystem>
<jboss umlns="urn:jboss:1.0"> <jboss-camel xmlns="urn:jboss:jboss-camel:1.0" enabled="false"/> </jboss>
<jboss umlns="urn:jboss:1.0"> <jboss-camel xmlns="urn:jboss:jboss-camel:1.0"> <component name="camel-ftp"/> <component-module name="org.apache.camel.component.rss"/> </jboss-camel> </jboss>
Chapter 4. Technology previews This section provides an overview of Technology Preview features introduced or updated in this release of Red Hat Ceph Storage. Important Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information on Red Hat Technology Preview features support scope, see the Technology Preview Features Support Scope HA backed NFS for improved availability of NFS deployments With this release, NFS is backed by HA to improve availability of NFS deployments. You can deploy NFS backed by haproxy and keepalived . If the placement specifies more hosts, but limits the number of hosts being used with the count property, NFS daemons are deployed on other hosts when an NFS host goes offline. See Management of NFS Ganesha gateway using the Ceph orchestrator for more details. 4.1. Ceph Object Gateway Ceph Object Gateway technology preview support for S3 transparent encryption With this release, Ceph Object Gateway provides technology preview support for S3 transparent encryption using SSE-S3 and S3 PutBucketEncryption APIs. 4.2. RADOS Block Device librbd plugin named persistent write log cache to reduce latency With this release, the new librbd plugin named Persistent Write Log Cache (PWL) provides a persistent, fault-tolerant write-back cache targeted with SSD devices. It greatly reduces latency and also improves performance at low io_depths . This cache uses a log-ordered write-back design which maintains checkpoints internally, so that writes that get flushed back to the cluster are always crash consistent. Even if the client cache is lost entirely, the disk image is still consistent; but the data will appear to be stale.

Commands:
1.6. Data Centers A data center is the highest level of abstraction in Red Hat Virtualization. A data center contains three types of information: Storage This includes storage types, storage domains, and connectivity information for storage domains. Storage is defined for a data center, and available to all clusters in the data center. All host clusters within a data center have access to the same storage domains. Logical networks This includes details such as network addresses, VLAN tags and STP support. You can define logical networks for a data center and apply them to clusters. Clusters Clusters are groups of hosts with compatible processor cores, either AMD or Intel processors. Clusters are migration domains; virtual machines can be live-migrated to any host within a cluster, and not to other clusters. One data center can hold multiple clusters, and each cluster can contain multiple hosts.

Commands:
3.15. Software Collection SELinux Support Because Software Collections are designed to install the Software Collection packages in an alternate directory, set up the necessary SELinux labels so that SELinux is aware of the alternate directory. If the file system hierarchy of your Software Collection package imitates the file system hierarchy of the corresponding conventional package, you can run the semanage fcontext and restorecon commands to set up the SELinux labels. For example, if the /opt/provider/software_collection_1/root/usr/ directory in your Software Collection package imitates the /usr/ directory of your conventional package, set up the SELinux labels as follows: semanage fcontext -a -e /usr /opt/provider/software_collection_1/root/usr restorecon -R -v /opt/provider/software_collection_1/root/usr The commands above ensure that all directories and files in the /opt/provider/software_collection_1/root/usr/ directory are labeled by SELinux as if they were located in the /usr/ directory. 3.15.1. SELinux Support in Red Hat Enterprise Linux 7 When packaging a Software Collection for Red Hat Enterprise Linux 7, add the following commands to the %post section in the Software Collection metapackage to set up the SELinux labels: semanage fcontext -a -e /usr /opt/provider/software_collection_1/root/usr restorecon -R -v /opt/provider/software_collection_1/root/usr selinuxenabled && load_policy || : The last command ensures that the newly created SELinux policy is properly loaded, and that the files installed by a package in the Software Collection are created with the correct SELinux context. By using this command in the metapackage, you do not need to include the restorecon command in all packages in the Software Collection. Note that the semanage fcontext command is provided by the policycoreutils-python package, therefore it is important that you include policycoreutils-python in Requires for the Software Collection metapackage. Note The SELinux aspect of starting services has changed significantly in Red Hat Enterprise Linux 7. Most importantly, using the scl enable ... wrapper in a systemd service file will cause the service to be run as an unconfined process using the unconfined_service_t context. As this context has no transition rules by design, the service will not be able to transition into the target SELinux context indicated by the SELinux policy, which means scl enable ... cannot be used on Red Hat Enterprise Linux 7 if the service being started is supposed to be confined using SELinux.

Commands: