vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Delete a volume-clone request

When a volumes-clone request is not required any longer, you can call the volumes-clone delete API to remove the data. You can delete a volumes-clone request only when the request status is in one of the finalized statuses: Completed, Failed, or Cancelled state.











 Restoring a snapshot 

The restore operation restores all of the volumes that are part of a VM snapshot back to the source disks. While it restores the VM, the Power Systems Virtual Server creates a backup snapshot, which can be used if the restore operation fails. If the restore operation succeeds, the backup snapshots are deleted. If the restore operation fails, you can pass in the restore_fail_action query parameter with a value of retry to retry the restore operation. To roll back a previous disk state, you can pass in the restore_fail_action query parameter with a value of rollback. When the restore operation fails, the VM enters an Error state.



 Best practices 

During the restore operation, it is critical that your source disks be quiesced. Your source disks cannot be in use. Shut down all of your applications, including file systems and volume managers. If you are running an AIX VM, make sure that the disks are freed from the LVM by varying it off.

If you plan to restore the boot disks, your VM must be shut down. If the VM has volumes that are hosting external database applications, quiesce all of your applications and ensure that there are no active IO transactions on the disk. Failure to do so can lead to data corruption and put the VM in maintenance mode.





 Use cases 



* Restoring all of the volumes that are part of a VM snapshot
* Running multiple VM restore operations
* Retrying a VM restore operation if it originally failed
* Rolling back a VM to its original volume state







 Restrictions and considerations 



* If the restore operation fails, reach out to your storage support administrator. A failed restore operation can leave behind incomplete states, which might require a cleanup initiative from an IBM operation's team.
System.out.println("Directory download is in progress: " + asperaTransaction.progress());

//pause for 3 seconds
Thread.sleep(1000 * 3);
}

Every transfer by default will have a TransferProgress attached to it. The TransferProgress will report the number of bytes transferred and the percentage transferred of the total bytes to transfer. To access a transfer’s TransferProgress use the getProgress method in AsperaTransaction.

Future<AsperaTransaction> asperaTransactionFuture = asperaTransferMgr.downloadDirectory(bucketName, directoryPrefix, outputDirectory, includeSubDirectories);
AsperaTransaction asperaTransaction = asperaTransactionFuture.get();

while (!asperaTransaction.isDone()) {
TransferProgress transferProgress = asperaTransaction.getProgress();

//pause for 3 seconds
Thread.sleep(1000 * 3);
}

To report the number of bytes transferred call the getBytesTransferred method on TransferProgress. To report the percentage transferred of the total bytes to transfer call the getPercentTransferred method on TransferProgress.

Future<AsperaTransaction> asperaTransactionFuture = asperaTransferMgr.downloadDirectory(bucketName, directoryPrefix, outputDirectory, includeSubDirectories);
AsperaTransaction asperaTransaction = asperaTransactionFuture.get();

while (!asperaTransaction.isDone()) {
TransferProgress transferProgress = asperaTransaction.getProgress();

System.out.println("Bytes transferred: " + transferProgress.getBytesTransferred());
Whenever you are ready, go ahead and click start replication (the play/arrow head icon on the left top). This will start the actual migration. If you expand the replication record, it displays actual steps being executed in summary with necessary information.
3. Whether the operation is successful or whether it failed, you can see the job history in the replication record.
4. In case of failure, you can retrieve the log and review detailed information.



To improve data transfer rate, adjust bandwidth allocation of RMM server. To know how to change bandwidth allocation, see [Adjusting bandwidth allocation using the UI](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-virtual-server-instances&interface=uiadjusting-bandwidth-allocation-ui).





 Step 6: Validate your migration 

After your migration, validate or update the following:



1. Access the target server.
2. Check partitions and volumes.
3. Check applications.
4. Install any test application in the target server.
5. Check networking routes.
6. Check or update application or operating system licenses.
7. Remove RMM SSH key.







 Help and support 



* [RackWare Cloud Migration](https://www.rackwareinc.com/cloud-migration)
* [RackWare RMM user guide for IBM Cloud](https://www.rackwareinc.com/rackware-rmm-users-guide-for-ibm-cloud)
* [FAQS for classic bare metal to classic bare metal](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-bare-metal-faqs)
* [Creating a native OAuth provider](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/oauth_native_apim.html)
* [Creating a third-party OAuth provider](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/oauth_thirdparty_apim.html)







 Managing product lifecycles 

A product is a set of APIs and the plans that specify usage rules such as rate limits. You publish a product to your organization's developer portal where customers can subscribe to use the APIs contained in each product. Every product has a lifecycle spanning its initial publication through its removal from the Developer Portal. You can manage the stages in the product lifecycle in API Connect. For information on working with products, see the following topics in the extended V10 Reserved documentation:



 Publishing a product 



* [Publish a new product](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/task_publishing_a_product.html)
* [Replace a product](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/task_replacing_a_product.html)
* [Supercede a product](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/task_superseding_a_product.html)







 Changing product availability 

Restrict a product to specific consumers or endpoints, or remove a product from the developer portal.



* [Approve product requests](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/task_accessrequests_product.html)
Create a volumes-clone request and initiate the Prepare action 



* Requirements



* Minimum of two volumes
* Minimum of one volume to be in the in-use state
* A unique volumes-clone name



* Status change When the preparatory actions are initiated, the initial status of the volumes clone request is set to Preparing. When the preparatory actions are completed successfully, the status changes to Prepared. If an error occurs during the preparatory actions, the status changes to Failed. You can view the reasons for the failure by using the [get volumes-clone detail](https://cloud.ibm.com/apidocs/power-cloudpcloud-v2-volumesclone-get) request or the [get volumes-clone list](https://cloud.ibm.com/apidocs/power-cloudpcloud-v2-volumesclone-getall) request.

If you cancel the volumes-clone request, the status is changed to Cancelling. You can cancel a volumes-clone request only when the volumes-clone request status is changed to Prepared state.
* Output A new volumes-clone ID is generated along with the volumes-clone object.







 2. Start the volumes-clone request 

This step allows the consistency group to initiate the FlashCopy operation. As a best practice, you must manually quiesce the VM before initiating the start action of a volumes-clone request.



* Requirements The volumes-clone request must be in the Prepared state.
* Status change You can view the latest volumes-clone request status by using the [get volumes-clone detail](https://cloud.ibm.com/apidocs/power-cloudpcloud-v2-volumesclone-get) request or the [get volumes-clone list](https://cloud.ibm.com/apidocs/power-cloudpcloud-v2-volumesclone-getall) request. When the volumes-clone request is initiated, the initial status is set to Starting. When the group snapshot is created, the request status changes to Available. The start action of the volumes-clone request is synchronous and when the API call returns to the client, the volumes-clone request status changes to Available unless an error occurs.
* Successful authentication: The connection between App ID and the Identity Provider is working correctly. The page displays valid [access and identity tokens](https://cloud.ibm.com/docs/appid?topic=appid-tokenstokens).
* Failed authentication: The connection is broken. The page displays the errors and the SAML response XML file.





The SAML framework supports multiple profiles, flows, and configurations, which means that your identity provider must be configured correctly. If you run into issues, check out some common reasons why your [authentication request might fail](https://cloud.ibm.com/docs/appid?topic=appid-ts-saml) or review the [SAML specification](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html) for detailed error codes.
curl: (6) Could not resolve host: <URL>.com; Unknown error
tar -xvf bootstrap.tar
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
[ -n ‘’ ]]
echo ‘Failed to untar bootstrap.tar’
Failed to untar bootstrap.tar n + rm -rf /tmp/bootstrap

The machine cannot be reached on the network. Check that your machine meets the [minimum requirements for network connectivity](https://cloud.ibm.com/docs/satellite?topic=satellite-host-reqs), [remove the host](https://cloud.ibm.com/docs/satellite?topic=satellite-host-remove), and try to [add](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hosts) and [assign](https://cloud.ibm.com/docs/satellite?topic=satellite-assigning-hostshost-assign-manual) the host again. Alternatively, the infrastructure provider network might have issues, such as a failed connection. Consult the infrastructure provider documentation for further debugging steps.





 Host is attempting to register with the location 

You receive output similar to the following message.

kubectl --kubeconfig=/tmp/bootstrap/priveledgedcertdir/privledged-kubeconfig

The host is attempting to register with the location.



1. Find the Satellite control plane endpoint.

ibmcloud sat location get --location <LOCATION_ID>
2. Find the Public Service Endpoint URL field, for example, https://c103-e.containers.cloud.ibm.com:12345.
3. Confirm your connection exists by running nc -z -v <ENDPOINT> from your host. For example,

nc -z -v c103-e.containers.cloud.ibm.com 12345
4.
Audit logging of application provider events and SIEM 

In addition, to [audit logging of IBM Cloud events](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-logging-audit), you also need to consider auditing of events your applications might generate. Auditable events from all sources need to be consolidated into a security information and event management (SIEM) system.



 Auditable events 

You should audit the following events that occur within the system (in all environments, such as dev, test, prod):



* Access, downloading, revisions to Confidential information
* Access to or update to any financial transaction data
* Any changes to customer accounts
* Login or logoff event, success or failure
* Changes to a system that impact business logic or work flow, examples include but are not limited to, changing call routing, interest rates that are offered for a class of customer, a website flow a customer uses
* Any changes to customer systems that include but not limited to: software install or uninstall, configuration changes, directory or file moves, adds, or deletes, configuration changes, port turn ups, MAC’s, routing changes, and so on.
* Each command action taken, both successful and unsuccessful, by a privileged account that includes but not limited to:



* All changes, additions, or deletions to any account such as lock, unlock, password reset, permission changes,
* Modification to system time / time-synchronization configuration,
* Log files: access to logs files; initialization, stopping or pausing of logging, log modification, changes to access permission on log files,
* Files and system level objects creation and deletion,
* Attempts to perform unauthorized functions or access data that the user is not authorized to access,
* Modification of security rules,
* Application and related systems start-ups and shut-downs



* For privileged accounts:



* Attempts to execute privilege elevation
* System errors relevant to security events, including but not limited to SQL errors that indicate an SQL injection, fuzzing, multiple failed logins, failed configuration change, failed/disabled anti-virus software, service failures
* Web access events in extended log format
journalctl -u ibm-host-agent --no-pager

journalctl -u ibm-firstboot-ignition --no-pager
4. Review the logs for errors. See the following section for more details.





 Machine cannot be reached on the network 

You receive output similar to the following messages.

curl: (6) Could not resolve host

The machine cannot be reached on the network. Check that your machine meets the [minimum requirements for network connectivity](https://cloud.ibm.com/docs/satellite?topic=satellite-host-reqs), [remove the host](https://cloud.ibm.com/docs/satellite?topic=satellite-host-remove), and try to [add](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hosts) and [assign](https://cloud.ibm.com/docs/satellite?topic=satellite-assigning-hostshost-assign-manual) the host again.

Alternatively, the infrastructure provider network might have issues, such as a failed connection. Consult the infrastructure provider documentation for further debugging steps.
Then the instance generates a LUKS passphrase with the seed (unwrapped first) and the two seeds from the contract to encrypt the second partition. 
 2 No encrypted seed Has kms details (one entry) LUKS encrypted Similar flow as the previous one to re-encrypt the second partition. The old LUKS passphrase is replaced. Note that the two seeds from env and workload need to be the same as before; otherwise the re-encryption fails and the instance shuts down. Provide the correct seeds and retry. 
 2 No encrypted seed Has kms details (multiple entries) Not LUKS encrypted Similar flow as the previous scenarios to wrap the third seed and encrypt the second partition. Only the configuration in the first entry is used to wrap the third seed. 
 2 Has an encrypted seed Has kms details (one entry) Not LUKS encrypted It's possible that you used the volume in previous provisioning but the encryption was unsuccessful, or you provided the volume with two partitions and manually created a random value as the third seed, wrapped it, and stored it in the metadata partition. In either case, the instance checks if the partitioning is correct. If not, the instance shuts down. If the partitioning is correct, the instance calls Hyper Protect Crypto Services to unwrap the encrypted seed and generates a LUKS passphrase with the seed and the two seeds from the contract to encrypt the second partition. 
 2 Has an encrypted seed Has kms details (one entry) LUKS encrypted The instance calls Hyper Protect Crypto Services to unwrap the encrypted seed and opens the LUKS layer on the data partition. 
 2 Has an encrypted seed Has kms details (multiple entries) The instance calls Hyper Protect Crypto Services to unwrap the encrypted seed with the first kms entry. If it fails, it uses the next entry. When it succeeds, it uses the first configuration to rewrap the seed. If all the entries don't work, the instance shuts down.
Potential failure point 1: Container or pod availability
: Containers and pods are, by design, short-lived and can fail unexpectedly. For example, a container or pod might crash if an error occurs in your app. To make your app highly available, you must ensure that you have enough instances of your app to handle the workload plus additional instances in the case of a failure. Ideally, these instances are distributed across multiple worker nodes to protect your app from a worker node failure. For more information, see [Deploying highly available apps](https://cloud.ibm.com/docs/containers?topic=containers-plan_deployhighly_available_apps).

Potential failure point 2: Worker node availability
: A worker node is a VM that runs on physical hardware. Worker node failures include hardware outages, such as power, cooling, or networking, and issues on the VM itself. You can account for a worker node failure by setting up multiple worker nodes in your cluster. For more information, see [Creating clusters with multiple worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_create).

Worker nodes in one zone are not guaranteed to be on separate physical compute hosts. For example, you might have a cluster with three worker nodes, but all three worker nodes were created on the same physical compute host in the IBM zone. If this physical compute host goes down, all your worker nodes are down. To protect against this failure, you must [set up a multizone cluster to spread worker nodes across three zones, or create multiple single zone clusters](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersha_clusters) in different zones.

Potential failure point 3: Cluster availability
: The Kubernetes master is the main component that keeps your cluster up and running. The master stores cluster resources and their configurations in the etcd database that serves as the single point of truth for your cluster. The Kubernetes API server is the main entry point for all cluster management requests from the worker nodes to the master, or when you want to interact with your cluster resources.
When publishing an Microsoft Teams notification, issues such as network errors and application glitches can cause the requests to fail. A retry is used to provide resiliency to external requests. Attempt to retry the requests in such situations by using the following values:



* Limit = 60 seconds: total time that the service retries.
* Step = 5 seconds: after each failure, the service waits 5 seconds before retrying. This delay prevents bombarding of the external services (webhook).



In addition, the following timeout conditions cause the Microsoft Teams call to fail:



* A connection timeout of 10 seconds
* A response timeout of 60 seconds



If a call to the Microsoft Teams webhook URL fails even after retry attempts, the notification is lost.
IBM Aspera can help transfer data to the IBM Cloud for later retrieval from the Power Systems Virtual Server environment. For more information, see [IBM Aspera on Cloud](https://www.ibm.com/products/aspera).





 Replication 

You can use various replication mechanisms to migrate and sync environments between your on-premises environment and the Power Systems Virtual Server.

Storage area network (SAN) and hardware-based replication is not currently a migration option.



 Host and OS-based logical replication 

IBM recommends that you use PowerHA SystemMirror (Enterprise Edition) with Geographic Mirroring (Geomirroring) and Geographic Logical Volume Manager (GLVM). The following host and os-based logical replication options exist depending on your OS:



* AIX - GLVM
* IBM i - Geomirroring







 Application-specific replication 

Applications might have replication mechanisms that can sync multiple environments. These options are commonly used for application-specific replication:



* Db2 HADR
* Oracle Data Guard
* Oracle Goldengate
* iCluster
* MIMIX from Syncsort
* Maxava HA









 Backup and restore 

You can back up your on-premises environment and restore it to Power Systems Virtual Server. In most cases, COS, and NFS servers serve as an intermediary to back up and restore data. The [AIX migration strategies](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-migration-strategies-powermigration-aix) and [IBM i migration strategies](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-migration-strategies-powermigration-ibmi) sections provide information on OS-specific migration strategies.





 Third-party vendors and tools 

Customers can use third-party tools to perform data migration. The following third-party tools are commonly used for data migration:



* [Falconstor StorSafe VTL](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-migration-strategies-powerfalconstor-storsafe-vtl)
* iCluster
When you use Terraform or the API to create or update a Key Protect, Secrets Manager, or App Configuration tool integration, the configuration fails with the There was a problem with the provided service parameters, please check that they are valid error message.

 Why it’s happening 

The tool integration is configured with the name or ID of a Key Protect, Secrets Manager, or App Configuration service instance that cannot be found or accessed. If you are using Terraform to manage both the service instance and the tool integration, Terraform might attempt to create, or update the tool integration before it creates the service instance.

 How to fix it 

If you are using Terraform, check your Terraform configuration to make sure that the [ibm_cd_toolchain_tool_keyprotect](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cd_toolchain_tool_keyprotect), [ibm_cd_toolchain_tool_secretsmanager](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cd_toolchain_tool_secretsmanager), or [ibm_cd_toolchain_tool_appconfig](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cd_toolchain_tool_appconfig) tool integration resource depends on the Key Protect, Secrets Manager, or App Configuration [ibm_resource_instance](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/resource_instance) resource that the tool integration represents. You can specify this dependency within the tool integration resource by referring to attributes of the service instance resource, or by specifying a depends_on meta-argument that refers to the service instance resource. You can refer directly to the service instance resource, or indirectly through other intermediate resources. By declaring dependencies between resources correctly, you can coerce Terraform into creating, updating, and deleting resources in the correct sequence.