Adding Instance Storage to an Existing VPC VSI

In a development environment, I deployed three (3) VSIs, installed and configured an application. The initial configuration made use of a VSI profile without instance storage. As I was testing the solution, it became apparent that I should have used a profile with instance storage to benefit from the low-latency and higher disk I/O for some I/O intensive processing of the application. Although the option does exist today to resize a VSI to a different profile, it is not currently possible to resize to a profile that includes instance storage.

An instance with a profile that does not include instance storage cannot be resized to a profile that does include instance storage (IBM Cloud docs).

Maybe, now, there is a way.

The recently introduced feature to create a VSI from an existing volume may just be what I need to be able to move these VSIs without reinstalling my application. I need a small test scenario to confirm I can execute the move without experiencing any data lost and that the installed software will continue to work as expected. I started by making some small changes to a Terraform template I previously used in the “Automate the Configuration of Instance Storage on a Linux-Based VSI” blog post. The changes were to create the VSI using a profile that does not contain the instance storage. The modifications to the repository can be found here. I followed these steps to check against my goal:

1. Modified configuration file env-config-boot-volume.sh to override some of the default variables used by the Terraform template: 
   • TF_VAR_vpc_app_image_profile: I set the value to a profile that does not support instance storage.
   • TF_VAR_boot_volume_auto_delete: I set the value to false to prevent the boot volume from getting deleted when the VSI is deleted

• Ran and then to deploy the environment. As was done previously, a small application is deployed to the VSI that periodically attempts to writes to the instance storage if it is available. However, nothing will get written during the initial deployment. 
• With everything created, I switched to using the VSIs for VPC console UI. From there, I deleted the newly created VSI. As expected, the boot volume was not deleted:

• I selected to create a new VSI. This time, using the UI, I chose to use an existing volume that contained the app and all its configuration:

• I selected to use a profile that contains the instance storage I needed for the application:

• I configured the remainder of the instance create page with critical items, such as configuring the Name, Reserved IP, VPC, Subnet, Security groups, SSH keys, etc. to match the previous configuration of the original VSI.
• Once the VSI was created, the service I had previously deployed as part of the Terraform template in Step 1 above to configure the instance storage took over (i.e. /usr/bin/instance-storage.sh). My app is now making use of the instance storage for its processing. Following this process enabled me to bypass one of the limitations I had previously encountered.

• Using this process, the virtual server instance ID and CRN will change. Keep that in mind if you rely on that information in any of your automation or for logging and monitoring.
• This use case of using the boot from existing volume feature to change the profile is fully supported by the team that delivered this feature.
• There are other interesting use cases for this feature (e.g., moving a VSI from one VPC to another or regaining SSH access to an instance after losing your private key). Consult the product documentation.
• Instance storage is ephemeral storage—only use it for data that is transient.

If you have feedback, suggestions, or questions on this post, please reach out to me on LinkedIn. You can also open GitHub issues on the related code samples for clarifications.