vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"volume": {
"profile": {
"name": "general-purpose"
},
"source_snapshot": {
"id": "eb373975-4171-4d91-81d2-c49efb033753"
}
}
},
.
.
.
}'
Show more

For more information about restoring a volume with the API, see [Restore a volume from a snapshot with the API](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-restore&interface=apisnapshots-vpc-restore-API).







 Creating virtual server instances by using Terraform 

You can create instances by using Terraform. If you would like to use user tags or access management tags to manage your resources, see [Working with tags](https://cloud.ibm.com/docs/account?topic=account-tag&interface=terraform).



 Before you begin 

Make sure that you set up [Terraform for VPC](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest).





 Creating a private catalog 

This step is optional. If you plan to share images from a private catalog, the private catalog must be created first. If you select a catalog image that belongs to a different account, review [Using cross-account image references in a private catalog in Terraform](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images&interface=uiprivate-catalog-image-reference-vpc-terraform) for more considerations and limitations. To create a private catalog, see the tutorial [Onboarding a virtual server image with Terraform](https://cloud.ibm.com/docs/account?topic=account-catalog-vsi-tutorial&interface=ui).





 Gathering information to create an instance by using Terraform 

Ready to create an instance?
: Application load balancers now support [IBM Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-getting-started). With Secrets Manager, you can create, lease, and centrally manage secrets that are used in IBM Cloud® services or your custom-built applications.
: As a reminder, end of support for IBM Cloud Certificate Manager was 31 December 2022. Remaining instances of Certificate Manager have been deleted. If you have any user-provided Ingress secrets stored in Certificate Manager, they are no longer valid.





 17 May 2022 

File storage for VPC
: For accounts authorized to preview this service, you can configure replication for new and existing file shares. Replication creates a read-only copy of your file share data in a different zone. You can fail over to the replica share if the source share becomes damaged or compromised. For more information, see [About file share replication](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-replication).
: You can now add user tags from the UI, CLI, or API when you create a new file share or update file shares. For more information, see [Adding user tags](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-managing&interface=uifs-add-tags-shares-ui).







 April 2022 



 29 April 2022 

Backup for VPC (LA)
: Accounts authorized to preview this service can create backup policies and plans to automatically back up block storage volumes. Backup policies control which source volumes are selected for backup by matching user tags in the volume with tags that are defined in the backup policy. Policies can contain up to four backup plans, which specify how often backup snapshots are taken (daily, weekly, monthly, or by using a cron-spec) and retained (by date or by count). You can also view backup jobs, which show status of backup snapshots that are being created or deleted. This release also provides new functionality for restoring volumes from backup snapshots.
* GET, PATCH, and DELETE for /instance/templates/{id}



POST /instances now supports a source_template.







 23 July 2020 



 For all version dates 

The [flow log collectors API](https://cloud.ibm.com/apidocs/vpclist-flow-log-collectors) is now generally available.







 22 July 2020 



 For all version dates 

This API release supports the following enhancements for customer-managed encryption for block storage boot and data volumes:



* POST /instances -- [Create an instance](https://cloud.ibm.com/apidocs/vpccreate-instance) and new volume, encrypted, using your customer root key (CRK). CRKs are imported to IBM Cloud or created in a key management service.
* POST /volumes -- Create an unattached data [volume](https://cloud.ibm.com/apidocs/vpccreate-volume), encrypted, using your CRK.









 12 May 2020 



 For all version dates 

Configure load balancer pool resources and their health monitors to use the HTTPS protocol. This enhancement enables end-to-end SSL encryption with HTTPS listeners, along with HTTPS health checks for increased availability. See the [load balancers API](https://cloud.ibm.com/apidocs/vpclist-load-balancers).







 1 May 2020 



 For all version dates 

This API release supports the following changes:



* [Flow log collectors](https://cloud.ibm.com/apidocs/vpclist-flow-log-collectors) API is available as beta
* GET /security_groups now supports vpc.crn and vpc.name filters









 17 April 2020 



 For all version dates 

IBM Cloud interprets volume capacity units in gibibytes, but the API documentation used gigabytes. This issue is now resolved in the documentation.







 10 April 2020 



 For all version dates 

Usage recommendations are provided for the following load balancer properties:



* protocol property for load balancer pools
* type property for load balancer pool health monitors
Using the [backup service](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-service-about), you can regularly back up your volume data based on a schedule that you set up. You can create backup snapshots as frequently as 1 hour. You can also create copies of your backup snapshot in other regions. However, the backup service does not provide continual backup with automatic failover. Restoring a volume from a backup or snapshot is a manual operation that takes time. If you require a higher level of service for automatic disaster recovery, see IBM's [Cloud disaster recovery solutions](https://www.ibm.com/cloud/disaster-recovery).





 How many copies of my backup can I create in other regions? 

You can copy a backup snapshot from one region to another region, and later use that snapshot to restore a volume in the new region. Only one copy of the backup snapshot can exist in each region. You can't create a copy of the backup snapshot in the source (local) region.
: Expand the size of new block storage volumes that you create and attach to a virtual server instance on Gen 2 Compute resources. Indicate capacity in GB increments up to 16 TB, depending on your volume profile limits. For more information, see [Expanding block storage volume capacity (Beta)](https://cloud.ibm.com/docs/vpc?topic=vpc-expanding-block-storage-volumes).

Encrypted images (Beta)
: Import an encrypted custom image with beta support for the feature. For more information, see [Creating an encrypted custom image (Beta)](https://cloud.ibm.com/docs/vpc?topic=vpc-create-encrypted-custom-image).

New SDK
: The [Python SDK](https://cloud.ibm.com/apidocs/vpc?code=python) is now generally available.





 23 July 2020 

Customer-managed encryption for block storage for VPC (GA)
: Customer-managed encryption is now available for protecting boot and data volumes on Gen 2 compute resources. Import your own root keys to the cloud or create a key using Key Protect or Hyper Protect Crypto Services. Then, use your key to secure your data. For more information, see [Customer-managed encryption](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutvpc-customer-managed-encryption).

Flow logs for VPC (GA)
: FLow logs for IBM Cloud VPC are now generally available. This service enables the collection, storage, and presentation of information about IP traffic flowing to and from network interfaces within a VPC. For more information, see [About IBM Cloud Flow Logs for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-flow-logs).





 16 July 2020 

New region
: The Tokyo region endpoint is now in service at https://jp-tok.iaas.cloud.ibm.com.
Audit records IBM provides audit records of the VPC resource lifecycle through IBM Cloud Activity Tracker. The Customer uses IBM Cloud Activity Tracker tooling to monitor audit records. 
 Security groups and ACLs IBM provides the ability to restrict access to virtual server instances by using security groups and networks ACLs. The Customer uses security groups and network ACLs to secure their virtual server instances, such as restricting what IP addresses can SSH into the instance. 
 Public Network Access IBM provides options to use a public gateway or floating IP addresses. The Customer chooses how to connect their workload to the public internet, if applicable, either through a public gateway or floating IP. 
 Access restriction IBM provides security measures for customers to restrict access to resources and resource groups. The Customer restricts user access to the appropriate resources and resource groups. 
 Activity tracker IBM provides logging and monitoring tools. The Customer integrates IBM Cloud Activity Tracker and IBM Cloud Monitoring data into their auditing and monitoring processes. 
 Encryption IBM Cloud VPN for VPC supports encrypted traffic by using IKE/IPsec policies. The Customer ensures that their connection is encrypted end-to-end, if required. 







 Disaster recovery 

Disaster recovery includes tasks such as providing dependencies on disaster recovery sites, provision disaster recovery environments, data and configuration backup, replicating data and configuration to the disaster recovery environment, and failover on disaster events.



Table 6. Responsibilities for disaster recovery

 Task IBM Responsibilities Your Responsibilities 

 Load balancer and VPN disaster recovery IBM Cloud Load Balancer and VPN for VPC have off-site storage and replication of configuration data in an out-of-region disaster recovery node with daily backups. This data is fully managed by IBM Cloud and no customer input is required to ensure service recovery, although there can be up to a 24-hour loss of configuration data. The Customer sets up their backup and recovery strategies for workload data.
For more information about the Terraform resources, arguments, and attributes that are used for restoring a volume, see [ibm_is_volume](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/is_volume).





 Performance impact 

The performance of boot and data volumes is initially degraded when data is restored from a snapshot. Performance degradation occurs during the restoration because your data is copied from IBM Cloud® Object Storage to Block Storage for VPC in the background. After the restoration process is complete, you can realize full IOPS on the new volume.



 Performance impact when a bootable backup snapshot is used to provision an instance 

Before you select a backup snapshot of a boot volume to provision an instance, consider the following points.



* Because the bootable backup snapshot is not fully hydrated, initial performance is slower than compared to a regular boot volume. Volumes that are restored from fast restore clones do not require hydration. The data is available when the volume is created.
* To achieve the best performance and efficiency when you provision multiple instances, boot from an existing image. Custom images that you provide are better than stock images for this purpose. Images can have a maximum size of 250 GB.









 Next steps 

After you restore a volume, you can [Manage your backup policies](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-service-manage&interface=api).
End-to-end encryption 

Although IBM Cloud VPC doesn't provide end-to-end encryption, it allows for it. For example, if you have a secure endpoint on a virtual server instance (such as an HTTPS server on port 443), you can attach a floating IP to that instance, and then your connection is end-to-end encrypted from the client to the server on port 443. Nothing in the path forces a decryption. However, if you use an insecure protocol such as HTTP on port 80, your data is not encrypted from end to end.

If your application requires end-to-end encryption, then it is your responsibility to ensure that your connection is encrypted end-to-end.
The [VPC reference architecture for IBM Cloud for Financial Services](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-about) has much more detail on securing workloads in the IBM Cloud.

Some obvious changes to make:



* CIDR blocks were chosen for clarity and ease of explanation. The Availability Zones in the Multi zone Region could be 10.1.0.0/10, 10.64.0.0/10, 10.128.0.0/10 to conserve address space. Similarly the address space for Worker nodes could be expanded at the expense of firewall, DNS and VPE space.
* Security Groups for each of the network interfaces for worker VSIs, Virtual Private Endpoint Gateways, DNS Locations and firewalls should all be carefully considered.
* Network Access Control Lists for each subnet should be carefully considered.
* Floating IPs were attached to all test instances to support connectivity tests via SSH. This is not required or desirable in production.
* [Implement context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create&interface=ui) rules to further control access to all resources.



In this tutorial you created a hub VPC and a set of spoke VPCs. You routed all cross VPC traffic through a transit VPC firewall-router. DNS services were created for each VPC. DNS forwarding rules were created between the services for workloads and a virtual private endpoint gateways.





 Remove resources 

Execute terraform destroy in all directories in reverse order using the ./apply.sh command:

./apply.sh -d : :





 Expand the tutorial 

Your architecture may not be the same as the one presented, but will likely be constructed from the fundamental components discussed here. Ideas to expand this tutorial:



* Integrate incoming public Internet access using [IBM Cloud® Internet Services](https://cloud.ibm.com/docs/cis?topic=cis-getting-started).
Troubleshooting Snapshots for VPC 

When you create or manage Snapshots for VPC, you might encounter issues. Often, you can recover by following a few steps. Issues, symptoms, likely causes, and resolutions are described in the following sections.



 Degraded performance during the restoration of a volume from a snapshot 

 What’s happening 

When you restore a volume from a snapshot, while the data downloads, the API health_state and health_reasons properties indicate that the snapshot is being initialized. Performance is degraded while the volume is being initialized from the snapshot. This performance impact applies to snapshots of unattached volumes and snapshots of volumes that are attached to an instance.

 Why it’s happening 

The data for the snapshot is stored in IBM Cloud® Object Storage. After the volume is created, the data is downloaded from Object Storage bucket to the availability zone where the volume is being created. Depending on the snapshot size, the download can take several minutes, at which time some of the data blocks are read or written directly from Object Storage, but not all data. You might experience less IOPS and bandwidth than what you'd expect when you create a regular volume. The health state show as degraded with health reason initializing_from_snapshot.

 How to fix it 

Wait until the data is fully downloaded from Object Storage to the volume. When the data is fully downloaded, you can expect the normal provisioned IOPS and bandwidth for the volume.





 Restoring a volume from a snapshot fails 

 What’s happening 

A fully restored volume was not created from the snapshot. The API health status shows degraded, with the health reason initializing_from_snapshot and a message indicates that initializing from the snapshot failed.

 Why it’s happening 

Some or all of the data was not downloaded from Object Storage to the volume that's being created. Data blocks were not written.

 How to fix it 

Contact IBM support to determine the root cause of the failure and resolve the problem.





 A snapshot of a volume is in an unusable state during volume restoration 

 What’s happening
You can create a fast restore clone when you [create](https://cloud.ibm.com/apidocs/vpc/latestcreate-snapshot) a new snapshot or [update](https://cloud.ibm.com/apidocs/vpc/latestcreate-snapshot-clone) an existing snapshot by adding one or more zonal clones for a snapshot in the same region as the snapshot. Later, you can restore a volume, and all of its data, from that fast restore snapshot clone. When you no longer need a zonal snapshot clone, you can [delete](https://cloud.ibm.com/apidocs/vpc/latestdelete-snapshot-clone) it. Although the delete operation cannot be reversed, you can create an new, equivalent zonal clone from the snapshot.

When [creating](https://cloud.ibm.com/apidocs/vpc/latestcreate-backup-policy-plan) or [updating](https://cloud.ibm.com/apidocs/vpc/latestupdate-backup-policy-plan) a backup policy plan, you can now specify the clone_policy.zones in which backup service will create snapshot clones.

For more information, see [Restoring a volume using fast restore](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-restore&interface=apisnapshots-vpc-use-fast-restore) or dive into the new [API methods](https://cloud.ibm.com/apidocs/vpc/latestlist-snapshot-clones).







 31 January 2023 



 For all version dates 

Bare metal server secure boot. When you [create](https://cloud.ibm.com/apidocs/vpc/latestcreate-bare-metal-server) or [update](https://cloud.ibm.com/apidocs/vpc/latestupdate-bare-metal-server) a bare metal server, you can now enable secure boot. The default is false (disabled).
Understanding business continuity and disaster recovery for VMware as a Service 

Disaster recoveryinvolves a set of policies, tools, and procedures for returning a system, an application, or an entire data center to full operation after a catastrophic interruption. It includes procedures for copying and storing an installed system's essential data in a secure location, and for recovering that data to restore normalcy of operation.



  Responsibilities 

For more information about responsibility ownership for using IBM Cloud® products between IBM® and the customer, see [Shared responsibilities for IBM Cloud products](https://cloud.ibm.com/docs/overview?topic=overview-shared-responsibilities).

For more information about your responsibilities when using IBM Cloud® for VMware as a Service, see [Understanding your responsibilities when using VMware as a Service](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-vmaas-understand-responsib).





  Disaster recovery strategy 

IBM Cloud has

business continuityplans in place to provide for the recovery of services within hours if a disaster occurs. You are responsible for your data backup and associated recovery of your content.

VMware as a Service provides mechanisms to protect your data and restore service functions. Business continuity plans are in place to achieve targeted

recovery point objective(RPO) andrecovery time objective(RTO) for the service. The following table outlines the targets for VMware as a Service.



Table 1. RPO and RTO for VMware as a Service

 Disaster recovery objective  Target value      Method                                                                                                                                                             

 RPO                          24 h              Use a backup provider such as Veeam® Backup and Recovery to store periodic backups of your workload.                                                               
 RPO                          Minutes           Use a replication provider such as Veeam to replicate your workload to another location.                                                                           
 RTO                          Minutes to hours  The recovery time objective depends on the storage medium that is used for your backups and on how long it takes for your workload to be ready from a cold start.  







  Locations 

For more information about service availability within regions and data centers, see [Service and infrastructure availability by location](https://cloud.ibm.com/docs/overview?topic=overview-services_region).
Troubleshooting Backup for VPC 

When you use the Backup for VPC service, you might encounter issues. Often, you can recover by following a few steps. Issues, symptoms, likely causes, and resolutions are described in the following sections.



 Volume backups were not made according to backup plan 

 What’s happening 

Volumes are not getting backed up on all scheduled times. For example, you created a schedule for backups in a backup plan to create daily backups. However, after the service created backups for a while as defined in the plan, the backups stop.

 Why it’s happening 

The issue can have one of the following causes.



* Your volume might be deattached after the successful backups were made.
* The volume tag that matched the tag for target resources might be deleted.
* The instance might not be running.
* Correct service-to-service authorizations might not be in place.



 How to fix it 

Verify that the volume wasn't detached from a virtual server instance. Search for the instance to which you last attached the volume from the list of all virtual server instances. Verify that the instance is running. Also, look at the backup policy and verify that the tags are present in the volume, in case the tag was inadvertently deleted. Scheduled backups do not occur instantly, so you might need to look again in an hour or so to verify that the backup was made.





 Backup jobs are indicating a failed state 

 What’s happening 

The backup failed, as indicated in the backup job details. When you make a GET /backup_policies/{backup_policy_id}/jobs/{backup_job_id} call, the status property shows failed.

 Why it’s happening 

Look at the reason_codes property in the response. It might be an internal error or the [snapshot limit](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-faqs&interface=uifaq-snapshot-3) is reached.

 How to fix it 

Contact IBM support if you see an internal error.
For more information, see [Encryption in transit - Securing mount connections between file share and host](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-vpc-about&interface=apifs-eit) and [Creating instance identity certificates](https://cloud.ibm.com/docs/vpc?topic=vpc-metadata-beta-api-change-log11-july-2023-metadata-beta).

File share access control modes. For users with accounts that have access to file shares, you can now control the way a share is accessed when [creating](https://cloud.ibm.com/apidocs/vpc-betacreate-share) and [updating](https://cloud.ibm.com/apidocs/vpc-betaupdate-share) a file share. Specifying access_control_mode property value security_group now allows the use of security groups to manage which resources can access the file share. By using security groups, access can now be restricted to specific clients. When you specify access_control_mode property value vpc, all clients in each mount target's VPC will continue to have access to this share.

The default value of access_control_mode depends on the version query parameter date and the profile selected. When making API requests with a version query parameter of 2023-07-11 or later, the default is security_group. For requests that are using a version query parameter of 2023-07-10 or earlier, the default is vpc. File shares must be based on the [dp2 profile](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&interface=uidp2-profile) to use the security_group value. See [2023-07-11 API migration (file shares)](https://cloud.ibm.com/docs/vpc?topic=vpc-2023-07-11-migration-file-shares) for guidance on migrating access_control_mode from vpc to security_group.