vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* --rip: ID or name of the existing reserved IP.
* --address: The IP address to reserve, which must not already be reserved on the subnet.
* --auto-delete: If set to true, this reserved IP automatically deletes when the target is deleted. One of: true, false. (default: true).
* --ip-name: The user-defined name for this reserved IP. Names must be unique within the subnet that the reserved IP resides in. Names beginning with ibm- are reserved for provider-owned resources.
* --sgs: Comma-separated security group IDs or names for primary network interface.
* --allow-ip-spoofing: Disables the source and destination checks on this interface. If false, source IP spoofing is not allowed on this interface. One of: false, true.
* --primary-network-interface: PRIMARY_NETWORK_INTERFACE_JSON|@PRIMARY_NETWORK_INTERFACE_JSON_FILE, primary network interface in JSON or JSON file. For the data schema, see the primary_network_interface property in the [API documentation](https://cloud.ibm.com/apidocs/vpccreate-instance).
* --network-interface: NETWORK_INTERFACE_JSON|@NETWORK_INTERFACE_JSON_FILE, network interface attachment in JSON or JSON file. For the data schema, see the network_interfaces property in the [API documentation](https://cloud.ibm.com/apidocs/vpccreate-instance).
* --metadata-service, --ms: Enable or disable the Instance Metadata Service. One of: true, false.
* --metadata-service-protocol, --msp: The communication protocol for the metadata service endpoint. Applies only when the metadata service is enabled. One of: http, https. (default: http).
* --metadata-service-response-hop-limit, --msrhl: The hop limit (IP time to live) for IP response packets from the metadata service.
: The Schematics announces the timeline for the [deprecation of Terraform versions](https://cloud.ibm.com/docs/schematics?topic=schematics-deprecate-tf-versiondeprecate-timeline).





 6 April 2023 

Release Schematics command-line plug-in
: The Schematics [command-line plug-in v1.12.9](https://cloud.ibm.com/docs/schematics?topic=schematics-cli_version-releases) released.







 March 2023 

Review the release notes for March 2023.



 30 March 2023 

Release configuring Kubernetes cluster for an agent.
: The Schematics releases documentation on [configuring Kubernetes cluster for an agent](https://cloud.ibm.com/docs/schematics?topic=schematics-configure-k8s-cluster) related to network policies, Terraform and Ansible runtime-job, agent sandbox allowlist, agent job-runner configuration, agent runtime configuration for Ansible, and agent runtime configuration for Terraform.

Enhancement of Schematics worker runtime.
: The Schematics releases documentation on [Schematics worker runtime](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-utilities) for runtime-terraform-job, and runtime-ansible-job images.

IAM allowed IP addresses replaced with context based restrictions.
: Access to Schematics using IAM allowed IP addresses has been replaced with [context based restrictions](https://cloud.ibm.com/docs/schematics?topic=schematics-access-control-cbr).

The terraform.tfstate state file size maximum limit is less than 2 MB.
: The Schematics Workspace creation by using terraform.tfstate file fails due to the limitation in state file size.
df -vh
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 99G 3.7G 90G 4% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 1.7M 3.9G 1% /dev/shm
tmpfs 3.9G 25M 3.8G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/xvda1 240M 148M 80M 65% /boot
fsf-sjc0401b-fz.adn.networklayer.com:/SL02SV1160157_8/data01 40G 1.1G 39G 3% /SL02SV1160157_8
tmpfs 782M 0 782M 0% /run/user/0 /dev/mapper/3600a098038304338415d4b4159487669p1 99G 1.1G 93G 2% /SL02SEL1160157-73





* Non-LVM - xfs



1. Mount the xfs file system back to its mount point. See /etc/fstab if you're not sure what the old mount point is for the xfs partition.

 mount /dev/sdb1 /mnt
2. Extend the file system. Substitute the mount point of the file system.

 xfs_growfs -d </mnt>













 Why do I see two disks in Disk Management when I add a single storage device? 

Seeing two disks in Disk Management can occur if MPIO is not installed or is disabled for ISCSI.
Vdisk-data1 0738-fd146b1f-e1bb-4eab-ba78-3109e6bc3a2d data true
Instance Name Instance ID
vsi-test1 0738-8b56da93-7990-4ccf-9dc5-5aee6a5f08f9





 Adjust IOPS by specifying a different IOPS tier profile 

From the CLI, use the volume-update command with the --profile parameter and indicate the name or href of the IOPS tier profile.

This example changes a 3 IOPS/GB profile to 5 IOPS/GB profile. In this case, the volume can't exceed 9,600 GB to move to the higher profile.

ibmcloud is volume-update {volume-id} --profile 5iops-tier

$ ibmcloud is volume-update demo-volume-update --profile 5iops-tier
Updating volume demo-volume-update under account Test Account as user test.user@ibm.com...

ID r014-dee9736d-08ee-4992-ba8d-3b64a4f0baac
Name demo-volume-update
CRN crn:v1:bluemix:public:is:us-east-1:a/a10d63fa66daffc9b9b5286ce1533080::volume:r014-dee9736d-08ee-4992-ba8d-3b64a4f0baac
Status available
Attachment state attached
Capacity 100
IOPS 3000
Bandwidth(Mbps) 393
Profile 5iops-tier
Encryption key -
Encryption provider_managed
Resource group defaults
Created 2023-06-29T16:14:59+00:00
Zone us-east-1
Health State ok
Volume Attachment Instance Reference Attachment type Instance ID Instance name Auto delete Attachment ID Attachment name
Yes, ISO templates must be in the same data center as a virtual server to boot from the image. If the ISO template isn't in the same data center, the ISO template must be copied to the appropriate data center. If this situation occurs, a warning appears about the transaction. When an ISO template is copied to a different data center, a small fee is charged to the account as they are for copying other types of image templates.
* What is the difference between physical data and volume size?

Volume is the disk space that is available for storing files, while physical data consists of the actual files that are stored on the disk.
* What is the image import export feature?

The image import export feature converts VHDs and ISOs that are stored on an Object Storage account to convert into image templates, and vice versa. When you import an image, a specific file (either VHD or ISO) is sourced from a specified [Object Storage] Account's Container and is converted into an image template. The image template can then be used to start or load a device. When you export an image, the image template is converted into a file (or several files if the template has multiple disks). The image template is then stored in a specified location on an Object Storage Account's Container.
* How do I create an image template for my entire server and not just my primary drive?

To create an image template for your entire server, see the instructions in [Creating an image template](https://cloud.ibm.com/docs/image-templates?topic=image-templates-creating-an-image-templatecreating-an-image-template).

If you choose to export an image template to IBM Cloud Object Storage, each block device (or disk) has its own associated file. For example, if your image file is named image.vhd, the first block device is exported as image-0.vhd. The second block device is exported as image-1.vhd, and so on.
* How do I boot my virtual server instance from an image?

Go to the Device List. Click the virtual server that you want to start from an ISO template. On the Device Details page, select Actions > Boot from Image.
* Update file share and mount target name.
* Create replication between the source file share and a replica file share.
* Fail over to a replica file share when the source share is compromised. Fall back to the original share when the issue is resolved.
* Add, manage, and delete file share user tags. Create and manage access management tags.







 Who do I contact to help with any issues? What information do I need to provide? 

For more information about who to contact, see [Getting help and support](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-help). Provide as much information as you can, including error messages, screen captures, and API error codes and responses. Include any messages from the VPC and the file storage service.







 File share management questions 



 Can I mount the same file share in different zones in my region? 

Yes, you can mount file shares across different zones in your region.





 Can I mount file shares for my Kube containers? 

Yes. You can mount file shares by using the NFSv4.1 protocol.





 Can I mount same file shares between two virtual server instances? 

Yes, when the virtual server instances are in the same region.





 I use a load balancer across zones. Is there a way to copy the file share? 

No.





 Are there any options for backup for data retention? 

No. As a best practice, independently back up your data. When your file share data is deleted, it can't be restored.





 Are file shares elastic? 

File shares are not elastic. Currently, you can provision minimum of 10 GB to maximum of 32,000 GB file shares, depending on the [file share profile](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles).





 Can I change the size of a file share? 

You can increase the size of a file share from its original capacity in GB increments up to 32,000 GB capacity, depending on your [file share profile](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles).
You can also update these file shares to use the dp2 profile or switch back to a previous profile. However, you cannot use the previous profiles when you create a new file share.

Table 1 shows the dp2 profile performance levels compared to the earlier profiles. [Table 2](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profilesdp2-profile) presents the IOPS and capacity ranges for the dp2 profile. For more information about the earlier IOPS tiers and custom profiles, see [previous version file storage profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profilesfs-v2-profiles).



Table 1. Comparison of file share profiles and performance levels

 Profile Family IOPS IOPS per share Max throughput (MB/s) Share size (GB) Block size (KB) 

 dp2 defined_performance 1-100 IOPS/GB 100-96,000 1024 10-32,000 256 
 tier-3iops tiered 3 IOPS/GB 3,000-48,000 670 10-16,000 16 
 tier-5iops tiered 5 IOPS/GB 3,000-48,000 768 10-9,600 16 
 tier-10iops tiered 10 IOPS/GB 3,000-48,000 1024 10-4,800 256 
 custom custom 1-100 IOPS/GB 3,000-48,000 1024 10-16,000 256 







 dp2 file storage profile 

By using the dp2 profile, you can specify the total IOPS for the file share within the range for a specific file share size, 10 GB (default minimum) to 32,000 GB. You can provision shares with IOPS performance from 100 IOPS (default minimum) to 96,000 IOPS, based on share size. The dp2 profile is based on a block size of 256 KB. Maximum throughput is 1024 MB/s. This profile is backed by solid-state drives (SSDs).

Table 2 shows the available IOPS ranges, based on share size.



Table 2.
You can also update these file shares to use the dp2 profile or switch back to a previous profile. However, you cannot use the previous profiles when you create a new file share.

Table 1 shows the dp2 profile performance levels compared to the earlier profiles. [Table 2](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&nterface=uidp2-profile) presents the IOPS and capacity ranges for the dp2 profile. For more information about the earlier IOPS tiers and custom profiles, see [previous version file storage profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&nterface=uifs-v2-profiles).



Table 1. Comparison of file share profiles and performance levels

 Profile Family IOPS IOPS per share Max throughput (MB/s) Share size (GB) Block size (KB) 

 dp2 defined_performance 1-100 IOPS/GB 100-96,000 1024 10-32,000 256 
 tier-3iops tiered 3 IOPS/GB 3,000-48,000 670 10-16,000 16 
 tier-5iops tiered 5 IOPS/GB 3,000-48,000 768 10-9,600 16 
 tier-10iops tiered 10 IOPS/GB 3,000-48,000 1024 10-4,800 256 
 custom custom 1-100 IOPS/GB 3,000-48,000 1024 10-16,000 256 







 dp2 file storage profile 

By using the dp2 profile, you can specify the total IOPS for the file share within the range for a specific file share size, 10 GB (default minimum) to 32,000 GB. You can provision shares with IOPS performance from 100 IOPS (default minimum) to 96,000 IOPS, based on share size. The dp2 profile is based on a block size of 256 KB. Maximum throughput is 1024 MB/s. This profile is backed by solid-state drives (SSDs).

Table 2 shows the available IOPS ranges, based on share size.
You can select from three predefined [IOPS tiers](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-profilestiers) that offer reliable IOPS performance for your workload requirements. You can also define [custom IOPS](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-profilescustom) and specify a range of IOPS for a volume size that you choose. Custom IOPS is a good option when you have well-defined performance requirements that do not fall within a predefined IOPS tier. If you choose a custom IOPS profile, also define a minimum and maximum range for the volume size.

Maximum IOPS for data volumes varies based on volume size and the type of profile you select.

IOPS is measured based on a load profile of 16-KB blocks with random 50% read and 50% writes. Workloads that differ from this profile might experience reduced performance. If you use a smaller block size, maximum IOPS can be obtained, but throughput is less. For more information, see [How block size affects performance](https://cloud.ibm.com/docs/vpc?topic=vpc-capacity-performancehow-block-size-affects-performance).





 What typical network performance might I expect between my compute instances and the Block Storage for VPC service? 

Block Storage for VPC is connected to compute instances on a shared network, so the exact performance latency depends on the network traffic within a specific timeframe. Target latency for a 16-KB block size volume is under 1 millisecond for random reads and under 2 milliseconds for writes.





 What mechanisms are used to avoid data storage contention? 

Data storage contention is a common issue when multiple instances compete for access to the same Block Storage for VPC volume. Block Storage for VPC uses Rate Limiting at the hypervisor for optimal bandwidth between the hypervisor and Block Storage for VPC service. As a result, latency is guaranteed to be less than 1 millisecond for random reads and under 2 milliseconds for writes for a typical 16-KB block size.
You can also update these file shares to use the dp2 profile or switch back to a previous profile. However, you cannot use the previous profiles when you create a new file share.

Table 1 shows the dp2 profile performance levels compared to the earlier profiles. [Table 2](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&interface=apidp2-profile) presents the IOPS and capacity ranges for the dp2 profile. For more information about the earlier IOPS tiers and custom profiles, see [previous version file storage profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&interface=apifs-v2-profiles).



Table 1. Comparison of file share profiles and performance levels

 Profile Family IOPS IOPS per share Max throughput (MB/s) Share size (GB) Block size (KB) 

 dp2 defined_performance 1-100 IOPS/GB 100-96,000 1024 10-32,000 256 
 tier-3iops tiered 3 IOPS/GB 3,000-48,000 670 10-16,000 16 
 tier-5iops tiered 5 IOPS/GB 3,000-48,000 768 10-9,600 16 
 tier-10iops tiered 10 IOPS/GB 3,000-48,000 1024 10-4,800 256 
 custom custom 1-100 IOPS/GB 3,000-48,000 1024 10-16,000 256 







 dp2 file storage profile 

By using the dp2 profile, you can specify the total IOPS for the file share within the range for a specific file share size, 10 GB (default minimum) to 32,000 GB. You can provision shares with IOPS performance from 100 IOPS (default minimum) to 96,000 IOPS, based on share size. The dp2 profile is based on a block size of 256 KB. Maximum throughput is 1024 MB/s. This profile is backed by solid-state drives (SSDs).

Table 2 shows the available IOPS ranges, based on share size.



Table 2.
You can also update these file shares to use the dp2 profile or switch back to a previous profile. However, you cannot use the previous profiles when you create a new file share.

Table 1 shows the dp2 profile performance levels compared to the earlier profiles. [Table 2](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&interface=uidp2-profile) presents the IOPS and capacity ranges for the dp2 profile. For more information about the earlier IOPS tiers and custom profiles, see [previous version file storage profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&interface=uifs-v2-profiles).



Table 1. Comparison of file share profiles and performance levels

 Profile Family IOPS IOPS per share Max throughput (MB/s) Share size (GB) Block size (KB) 

 dp2 defined_performance 1-100 IOPS/GB 100-96,000 1024 10-32,000 256 
 tier-3iops tiered 3 IOPS/GB 3,000-48,000 670 10-16,000 16 
 tier-5iops tiered 5 IOPS/GB 3,000-48,000 768 10-9,600 16 
 tier-10iops tiered 10 IOPS/GB 3,000-48,000 1024 10-4,800 256 
 custom custom 1-100 IOPS/GB 3,000-48,000 1024 10-16,000 256 







 dp2 file storage profile 

By using the dp2 profile, you can specify the total IOPS for the file share within the range for a specific file share size, 10 GB (default minimum) to 32,000 GB. You can provision shares with IOPS performance from 100 IOPS (default minimum) to 96,000 IOPS, based on share size. The dp2 profile is based on a block size of 256 KB. Maximum throughput is 1024 MB/s. This profile is backed by solid-state drives (SSDs).

Table 2 shows the available IOPS ranges, based on share size.



Table 2.
For the data schema, see the primary_network_interface property in the [API documentation](https://cloud.ibm.com/apidocs/vpccreate-instance).
* --network-interface: NETWORK_INTERFACE_JSON|@NETWORK_INTERFACE_JSON_FILE, network interface attachment in JSON or JSON file. For the data schema, see the network_interfaces property in the [API documentation](https://cloud.ibm.com/apidocs/vpccreate-instance).
* --default-trusted-profile: ID or name of the trusted profile.
* --default-trusted-profile-auto-link: If set to true, the system creates a link to the specified target trusted profile during instance creation. Regardless of whether a link is created by the system or manually by using the IAM Identity service, it automatically deletes when the instance is deleted. One of: true,false. (default: true).
* --metadata-service, --ms: Enable or disable the Instance Metadata Service. One of: true, false.
* --metadata-service-protocol, --msp: The communication protocol for the metadata service endpoint. Applies only when the metadata service is enabled. One of: http, https. (default: http).
* --metadata-service-response-hop-limit, --msrhl: The hop limit (IP time to live) for IP response packets from the metadata service.
* --host-failure-policy: The action to perform if the compute host experiences a failure. One of: restart, stop.
* --resource-group-id: ID of the resource group. This ID is mutually exclusive with --resource-group-name.
* --resource-group-name: Name of the resource group. This name is mutually exclusive with --resource-group-id.
* --output: Specify output format, only JSON is supported. One of: JSON.
* -q, --quiet: Suppress verbose output.



--------------------
volume_ID
: The unique ID that is assigned to your Block Storage for Classic volume. You can retrieve a list of your Block Storage for Classic volumes by running ibmcloud is volumes.

volume_attachment_ID
: The unique ID that is assigned to your volume attachment. You can retrieve this ID by running ibmcloud is volume <volume_ID>.







 Reviewing volume attachment details for a VPC worker node by using the API 

You can use a GET request to retrieve volume attachment details for a VPC worker node.



1. Retrieve your IAM token.

ibmcloud iam oauth-tokens
2. Retrieve the ID of the resource group where your cluster is deployed.

ibmcloud oc cluster get <cluster_name_or_ID> | grep "Resource Group ID"
3. Retrieve the ID of the worker node for which you want to see volume attachment details. Make sure to select a worker node that is located in the same zone as your Block Storage for Classic instance.

ibmcloud oc worker ls --cluster <cluster_name_or_ID>
4. Review a list of existing volume attachments on a worker node.

curl -X GET "https://containers.cloud.ibm.com/v2/storage/getAttachments?cluster=<cluster_ID>&worker=<worker_ID>" --header "X-Auth-Resource-Group-ID: <resource_group_ID>" --header "Authorization: <IAM_token>"
5. Retrieve the details for a specific attachment.

curl -X GET "https://containers.cloud.ibm.com/v2/storage/getAttachment?cluster=<cluster_ID>&worker=<worker_ID>&volumeAttachmentID=<volume_attachment_ID>" --header "X-Auth-Resource-Group-ID: <resource_group_ID>" --header "Authorization: <IAM_token>"

IAM_token
: The IAM OAuth token for your current session. You can retrieve this value by running ibmcloud iam oauth-tokens.
For every project that you have in the cluster, make sure to set up proper [RBAC policies](https://cloud.ibm.com/docs/openshift?topic=openshift-usersrbac) to limit access to this project, control what gets deployed, and to set proper [resource quotas and limit ranges](https://docs.openshift.com/enterprise/3.2/dev_guide/compute_resources.html).



 Should I set up a single-tenant or a multi-tenant cluster? 

In a single-tenant cluster, you create one cluster for every group of people that must run workloads in a cluster. Usually, this team is responsible to manage the cluster and to properly configure and secure it. Multi-tenant clusters use multiple projects to isolate tenants and their workloads.

Zoom

![Deciding between a single tenant or a multi-tenant cluster.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cs_single_multitenant.png)

Figure 1. Single tenant versus multi-tenant cluster

Deciding between single-tenant and multi-tenant clusters depends on the number of teams that must run workloads in a cluster, their service requirements, the size of the service, and the level of isolation that you want to achieve for your workloads.

A single-tenant cluster might be your option if you have many teams with complex services that each must have control over the lifecycle of the cluster. This includes having the freedom to decide when a cluster is updated or what resources can be deployed to the cluster. You can also configure a single-tenant cluster to allow privileged pods without putting other tenants at risk of being compromised. Keep in mind that managing a cluster requires in-depth Kubernetes, Red Hat OpenShift, and infrastructure knowledge to ensure cluster capacity and security for your deployments.

Multi-tenant clusters use Red Hat OpenShift projects to isolate tenants and are usually managed by a separate team that does not belong to one of the tenants.