vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You can install specific solutions on your VM instance, and the licenses will be automatically set. If you want to use these licensed programs on your IBM i VM instance, you must order these licenses through Power Systems Virtual Server. You cannot use existing licenses in your VM instance.

Cloud Optical Repository (COR) is a virtual image that can be deployed and used as a Network File Server (NFS) to perform various IBM i tasks that require media. This virtual optical image includes a collection of the media necessary for various IBM i tasks, for all supported IBM i releases. With the COR image deployed, a second Power Systems Virtual Server Instance can be deployed on the same VLAN that is set up as the client and pointed to the COR (target) NFS Server Instance. For more information on COR images, see [Cloud Optical Repository](https://cloud.ibm.com/media/docs/downloads/power-iaas/Cloud_Optical_Repository.pdf).
8. Select your Machine type, the number of Cores, the amount of Memory (GB) and whether you'd like a Dedicated processor, Uncapped shared processor, or Capped shared processor.

There is a core-to-vCPU ratio of 1:1. For shared processors, fractional cores round up to the nearest whole number. For example, 1.25 cores equals 2 vCPUs. For more information on processor types, see [What's the difference between capped and uncapped shared processor performance? How does they compare to dedicated processor performance?](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-power-iaas-faqsprocessor). If the machine type is S922 and operating system is IBM i, IBM i supports maximum of 4 cores per VM.

When using an AIX stock image as the boot volume, a console session is required for the initial setting of the root user password. Without completing this step, SSH login appears as being disabled.
To set up the Monitoring agent in your cluster, see [Viewing cluster and app metrics with IBM Cloud Monitoring](https://cloud.ibm.com/docs/containers?topic=containers-health-monitormonitoring).

Kubernetes dashboard
: The Kubernetes dashboard is an administrative web interface where you can review the health of your worker nodes, find Kubernetes resources, deploy containerized apps, and troubleshoot apps with logging and monitoring information. For more information about how to access your Kubernetes dashboard, see [Launching the Kubernetes dashboard for IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appcli_dashboard).





 Forwarding cluster and app metrics to IBM Cloud Monitoring 

Use the IBM Cloud Kubernetes Service observability plug-in to create a monitoring configuration for IBM Cloud Monitoring in your cluster, and use this monitoring configuration to automatically collect and forward metrics to IBM Cloud Monitoring.

With IBM Cloud Monitoring, you can collect cluster and pod metrics, such as the CPU and memory usage of your worker nodes, incoming and outgoing HTTP traffic for your pods, and data about several infrastructure components. In addition, the agent can collect custom application metrics by using either a Prometheus-compatible scraper or a statsd facade.

Considerations for using the IBM Cloud Kubernetes Service observability plug-in:



* You can have only one monitoring configuration for IBM Cloud Monitoring in your cluster at a time. If you want to use a different IBM Cloud Monitoring service instance to send metrics to, use the [ibmcloud ob monitoring config replace](https://cloud.ibm.com/docs/containers?topic=containers-observability_climonitoring_config_replace) command.
* If you created a Monitoring configuration in your cluster without using the IBM Cloud Kubernetes Service observability plug-in, you can use the [ibmcloud ob monitoring agent discover](https://cloud.ibm.com/docs/containers?topic=containers-observability_climonitoring_agent_discover) command to make the configuration visible to the plug-in.
For more information, see [Kubernetes audit logs](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/). You can access these logs by using IBM Cloud Activity Tracker. For more information, see the [getting started tutorial](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-getting-started).
* Ingress: Logs for an Ingress application load balancer (ALB) that manages inbound network traffic.
* Kubernetes system components: Logs from the kubelet, the kube-proxy, and other components that run in the kube-system namespace.



To access cluster component logs, you can choose to forward your logs to IBM Log Analysis, an external server, or a third-party logging solution. For more information, see [Choosing a logging solution](https://cloud.ibm.com/docs/containers?topic=containers-healthlogging_overview).

How can I monitor the health and performance of my cluster?
: You can verify the health, capacity, and performance of your apps, services, and worker nodes by monitoring your cluster components and compute resources from the IBM Cloud Kubernetes Service console or CLI, such as the CPU and memory usage. To view more in-depth metrics for a standard cluster or your apps, you can configure a monitoring agent in your cluster to send metrics to IBM Cloud Monitoring. You can also install third-party monitoring solutions, such as Prometheus or Weave Scope, or use the metrics that are provided in the Kubernetes dashboard. For more information, see [Choosing a monitoring solution](https://cloud.ibm.com/docs/containers?topic=containers-health-monitorview_metrics).
If the version parameter is not declared in your versions.tf file, the latest version of the provider plug-in is automatically used in Schematics. For more information, refer to [Version constraints for the Terraform providers](https://cloud.ibm.com/docs/schematics?topic=schematics-version-constraintsprovider-version-contraint).





 How can I deploy one resources in two different IBM Cloud account? 

Use alias concept for deploying resource into your different IBM Cloud account as you can target provider with different accounts. For more information, about the configuration, see [Creating multiple provider configurations](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-provider-referencemultiple-providers).





 Can I automate the certificates to the Secrets Manager by using Terraform provider? 

No, currently there is no option for automation for moving the certificates to the Secrets Manager. As part of the workaround you can create a Secrets Manager with [ibm_resource_instance](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/resource_instance).

resource "ibm_resource_instance" "secret_manager" {
name = "test"
service = "secrets-manager"
plan = "trial"
location = "us-south"
resource_group_id = ibm_resource_group.group.id
parameters = {
kms_info = data.ibm_resource_instance.kms.id
kms_key = ibm_kms_key.secrets_manager_root_key.id
}
}
Collecting IPMI device sensor metrics 

In addition to the set of metrics that are automatically collected by the monitoring agent, you might want to collect other metrics such as sensor metrics. You can use the Prometheus IPMI Exporter to perform the collection of Intelligent Platform Management Interface (IPMI) device sensor metrics.



* The Prometheus IPMI Exporter exporter supports local IPMI devices and remote devices that can be accessed by using Remote Management Control Protocol (RMCP).
* When you use RMCP to access remote devices, you can use an IPMI exporter to monitor multiple IPMI devices. You identify each device by passing the target hostname as a parameter.
* The IPMI exporter relies on tools from the FreeIPMI suite.



The following figures shows different configurations that you can use to monitor sensor metrics from hosts that can be available in IBM Cloud or outside the IBM Cloud:

Zoom

![IPMI components](https://cloud.ibm.com/docs-content/v1/content/220cdcbf6f4421bd7fee83fd1028048dba3f16c8/monitoring/exporters/images/ipmi-kube1.svg)

Figure 1. IPMI components: IPMI exporter and Kubernetes agent in different hosts

You can collect the following metrics when you configure the IPMI exporter in a server:



* IPMI admin metrics

The metric ipmi_up {collector="<NAME>"} reports 1 when data from a remote host is collected successfully. It reports 0 for collection of data in a local host.

The metric ipmi_scrape_duration_seconds reports the amount of time that it takes the collector to retrieve the data.
* IPMI System event log (SEL) metrics

The metric ipmi_sel_entries_count reports the number of entries in the system event log.

The metric ipmi_sel_free_space_bytes reports the number of free bytes for new ystem event log entries.
* IPMI sensor data

The IPMI exporter collects 2 metrics per sensor type: state and value.
You can also modify existing file shares to use this profile. For more information, see the [file share profiles overview](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&interface=uifile-storage-profile-overview).







 March 2023 



 31 March 2023 

New network latency dashboard to view latency between zones in a multi-zone region (MZR)
: Not only can you view inter-region latency metrics, but you can now view inter-AZ metrics between all regions and availability zones (AZs) to help you plan the optimal selection for your cloud deployment. To view performance metrics, see the [Network latency dashboards](https://cloud.ibm.com/docs/vpc?topic=vpc-network-latency-dashboard).







 30 March 2023 

Documentation enhancement: Encrypting log messages for Hyper Protect Virtual Servers for VPC
: The newly added [Encrypting log messages tutorial](https://cloud.ibm.com/docs/vpc?topic=vpc-encrypt-log-messages-for-hyper-protect-virtual-servers-for-vpc) walks you through how to encrypt log messages that are generated by your container workload in your Hyper Protect Virtual Server for VPC instance. You can use the tutorial as reference to encrypt log messages if your workload produces sensitive information.



 29 March 2023 

VCPU manufacturer support for instances and dedicated hosts (LA)
: For accounts authorized to preview this functionality, you can now choose between profiles from different processor manufacturers when you provision an instance or dedicated host in the TOR region. For more information, see [x86-64 instance profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles&interface=uibalanced), [Dedicated host profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-dh-profiles&interface=uibalanced-dh-pr).





 28 March 2023 

Private DNS zones for network load balancers
The Monitoring agent includes components that collect metrics via Syscall, StatsD, JMX, and Promscrape.



* The agent extracts information directly from the kernel through server system calls. System calls provide information about the processes that are running, memory allocation, network connections, access to the filesystem, resource usage, and more.
* The agent includes a lightweight Prometheus server known as Promscrape. You can configure the agent to collect Prometheus metrics and send them to a Monitoring instance for storage and processing.



You must configure the Monitoring agent by using Prometheus syntax to configure the scrape_config settings and define the targets, instances and jobs.



* Promscrape is based on the open-source Prometheus server.
* Different Monitoring agent versions include different levels of support for collection of Prometheus metrics For example, Monitoring agent v10.5.0 and above, includes Promscrape v2 and supports Prometheus native service discovery. For more information on the Monitoring agent, see [Monitoring agent release notes](https://docs.sysdig.com/en/docs/release-notes/sysdig-agent-release-notes/).
* For more information about Promscrape versions, see [Migrating from Promscrape V1 to V2](https://docs.sysdig.com/en/docs/sysdig-monitor/monitoring-integrations/custom-integrations/collect-prometheus-metrics/migrating-from-promscrape-v1-to-v2/).







 Collecting custom metrics by using Prometheus remote write 

You can configure Prometheus remote write to collect metrics from environments where a Monitoring agent is not available and send them to a Monitoring instance.

You can collect metrics from:



* An existing Prometheus server.
* Ephemeral or batch jobs that may not exist long enough to be scraped by a Monitoring agent.
* Windows hosts and other operating systems where the Monitoring agent is not available
* Non-x86 based architectures, typically seen on IoT environments or Edge computing.
For more information, about [ibm_access_group_policy resource](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_access_group_policy) and [iam_service_policy resource](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_service_policy).

 {: codeblock}
resource "ibm_iam_access_group" "accgrp" {
name = "rg"
}

resource "ibm_iam_access_group_policy" "policy" {
access_group_id = ibm_iam_access_group.accgrp.id
roles = ["Manager", "Viewer", "Administrator"]
]

resources {
resource_type = "resource-group"
}
}






 How do I configure policy for all services in all the resource groups for an user? 

The sample code block helps to configure the policy for all services in all resource group. But you have to enter all the roles in the list.

 {: codeblock}
resource "ibm_iam_user_policy" "policy" {
ibm_id = "test@in.ibm.com"
roles = ["Viewer"]
}






 How can I configure a target resource to connect from different regions? 

You need to configure the different regions in the provider block by using region parameter, as shown in the code block.

 {: codeblock}
// First code block
provider "ibm" {
ibmcloud_api_key = xxxxxx
region = "eu-de"
}

 {: codeblock}
// Second code block
data "ibm_is_vpc" "vpc1" {
name = "aa-kubecf-a"
}






 How can I connect and retrieve information from multiple region at once in the same template? 

You can connect and retrieve information from a multiple regions by using aliases parameter as shown in the example code block.
For more information, about [ibm_access_group_policy resource](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_access_group_policy) and [iam_service_policy resource](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_service_policy).

 {: codeblock}
resource "ibm_iam_access_group" "accgrp" {
name = "rg"
}

resource "ibm_iam_access_group_policy" "policy" {
access_group_id = ibm_iam_access_group.accgrp.id
roles = ["Manager", "Viewer", "Administrator"]
]

resources {
resource_type = "resource-group"
}
}

* How do I configure policy for all services in all the resource groups for an user?

The sample code block helps to configure the policy for all services in all resource group. But you have to enter all the roles in the list.

 {: codeblock}
resource "ibm_iam_user_policy" "policy" {
ibm_id = "test@in.ibm.com"
roles = ["Viewer"]
}

* How can I configure a target resource to connect from different regions?

You need to configure the different regions in the provider block by using region parameter, as shown in the code block.

 {: codeblock}
// First code block
provider "ibm" {
ibmcloud_api_key = xxxxxx
region = "eu-de"
}

 {: codeblock}
// Second code block
data "ibm_is_vpc" "vpc1" {
name = "aa-kubecf-a"
}

* How can I connect and retrieve information from multiple region at once in the same template?
Monitoring Event Streams metrics by using IBM Cloud Monitoring 

[IBM Cloud® Monitoring](https://cloud.ibm.com/docs/monitoring?topic=monitoring-getting-started) is a third-party cloud-native, and container-intelligence management system that you can include as part of your IBM Cloud architecture. Use it to gain operational visibility into the performance and health of your applications, services, and platforms. It offers administrators, DevOps teams, and developers full stack telemetry with advanced features to monitor and troubleshoot, define alerts, and design custom dashboards.



 Opting in to and enabling Event Streams metrics 

Event Streams metrics can broadly be categorized into two different groups: Default and Enhanced.



 Enabling default Event Streams metrics 

Before you can start to use Event Streams IBM Cloud Monitoring metrics, you must first opt in, and then enable platform metrics by completing the following steps:



1. Enable platform metrics for Event Streams. For more information, see [Enabling platform metrics](https://cloud.ibm.com/docs/monitoring?topic=monitoring-platform_metrics_enabling).

The owner of the account has full access to this metrics data. For more information about managing access for other users, see [Getting started with IBM Cloud Monitoring - manage user access](https://cloud.ibm.com/docs/monitoring?topic=monitoring-getting-startedgetting-started-step1).
2. To navigate from the Event Streams instance page to the Monitoring dashboard, click Actions on the instance page and select Monitoring.

On your first usage, you might see a welcome wizard. To advance to the dashboard selection menu, select Next and then Skip on the Choosing an installation method page. Accept the prompts that follow. You can then select the IBM Event Streams or IBM Event Streams (Enterprise) dashboard, depending on the plan that you use.







 Enabling enhanced Event Streams metrics 

The enhanced Event Streams metrics consist of three groups; topic, partition and consumers. You can opt in to either one, two, or all.
To start the Monitoring UI from the Observability page, complete the following steps:



1. [Start the Monitoring UI](https://cloud.ibm.com/docs/monitoring?topic=monitoring-launch).
2. Select DASHBOARDS.
3. In the Default Dashboards section, expand IBM.
4. Choose the Container Registry dashboard from the list. Available dashboards are Container Registry Usage and Container Registry Quota Usage. For more information about predefined dashboards, see [Predefined dashboards](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_monitorregistry_dashboards_dictionary).



Next, change the scope or make a copy of the Default dashboard so that you can monitor your account in Container Registry. For more information, see [Working with dashboards](https://cloud.ibm.com/docs/monitoring?topic=monitoring-dashboards).







 Predefined dashboards 

The following table outlines the predefined monitoring dashboards that you can use to monitor Container Registry metrics.



Table 7. Predefined dashboards

 Dashboard name Description Default dashboard 

 Container Registry Usage A dashboard that you can use to visualize the traffic usage and storage usage. Traffic usage is the sum of bytes from image pulls from your Container Registry namespaces in the current billing period. Storage usage is the sum of bytes of images in your Container Registry namespaces. Yes 
 Container Registry Quota Usage A dashboard that you can use to visualize the traffic usage and storage usage and compare the data to your quotas, if set. Visible only to those accounts that have finite quotas. The Container Registry Quota Usage dashboard is available only if you enable metrics and you have both a storage and a traffic quota set. 



The predefined dashboards can't be changed. You can copy any predefined dashboard so that you can change it to suit your requirements. For more information, see [Working with dashboards](https://cloud.ibm.com/docs/monitoring?topic=monitoring-dashboards).
For more information, see [Working with access keys](https://cloud.ibm.com/docs/monitoring?topic=monitoring-access_keyaccess_key).

You can configure a monitoring agent for different environments. For example, to configure your Kubernetes cluster to send metrics to your IBM Cloud Monitoring instance, you must install a monitoring-agent pod on each node of your cluster. The monitoring agent collects data from the pod where it is installed, and forwards it to your IBM Cloud Monitoring instance.

Complete one of the following tutorials to learn how to deploy a monitoring agent:



Table 1. Tutorials to get started working with IBM Cloud Monitoring

 Tutorial 

 [Monitoring a Linux VPC server instance](https://cloud.ibm.com/docs/monitoring?topic=monitoring-ubuntuubuntu) 
 [Monitoring a Linux bare metal server](https://cloud.ibm.com/docs/monitoring?topic=monitoring-baremetal_linux) 
 [Monitoring a Windows environment](https://cloud.ibm.com/docs/monitoring?topic=monitoring-windows) 
 [Monitoring a Kubernetes cluster](https://cloud.ibm.com/docs/monitoring?topic=monitoring-kubernetes_cluster) 
 [Monitoring a Red Hat OpenShift cluster](https://cloud.ibm.com/docs/monitoring?topic=monitoring-openshift_cluster) 



After the monitoring agent is deployed, the monitoring agent automatically collects and reports on pre-defined and custom metrics. These metrics are forwarded to the IBM Cloud Monitoring instance. You can configure which metrics are monitored in an environment.







 Step 4. Launch the web UI 

After you provision an instance of the IBM Cloud Monitoring service in the IBM Cloud, and configure a monitoring agent for your node, you can view, monitor, and manage data through the service's web UI.

You launch the web UI within the context of the IBM Cloud Monitoring instance, from the IBM Cloud UI.

Complete the following steps to launch the monitoring UI:



1. Log in to your IBM Cloud account.
For more information, see [Availability and Durability of File Storage for Classic](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-storageavailability).





 Can I get storage performance metrics (IOPS or latency) from the Support teams? 

IBM Cloud® does not provide storage performance IOPS and latency metrics. Customers are expected to monitor their own File Storage for Classic devices by using their choice of third-party monitoring tools.

The following examples are utilities that you might consider to use to check performance statistics.



* [sysstat](https://github.com/sysstat/sysstat/blob/master/README.md) - System performance tools for the Linux® operating system.
* [typeperf](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/typeperf) - Windows® command that writes performance data to the command window or to a log file.
* [esxtop](https://communities.vmware.com/t5/Storage-Performance/Interpreting-esxtop-Statistics/ta-p/2776936) - A command-line tool that gives administrators real-time information about resource usage in a VMware® vSphere environment. It can monitor and collect data for all system resources: CPU, memory, disk, and network.







 What is the difference between a replica volume, a dependent and an independent duplicate volume? 

You can create a replica or a duplicate volume by using a snapshot of your volume. Replication and cloning use one of your snapshots to copy data to a destination volume. However, that is where the similarities end.

Replication keeps your data in sync in two different locations. Only one of the volume pair (primary volume and replica volume) can be active at a time. The replication process automatically copies information from the active volume to the inactive volume based on the replication schedule. For more information about replica volumes, see [Replicating data](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-replication).
The CLI versions match if you can see the same version in GitVersion for the client and the server. You can ignore the +IKS part of the version for the server.
2. If the oc CLI versions on your local machine and your cluster don't match, either update your cluster or [install a different CLI version on your local machine](https://cloud.ibm.com/docs/openshift?topic=openshift-cli-install).







 Updating Helm charts 



1. Find the [latest Helm chart version](https://github.com/IBM/charts/tree/master/community/portworx).
2. List the installed Helm charts in your cluster and compare the version that you installed with the latest version.

helm list --all-namespaces
3. If a more recent version is available, install the new version. For instructions, see [Updating Portworx in your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_update).